Høj samtidighedsunderstøttelse i Fabric Livy API'en

Høj samtidighed (HC) i Fabric Livy API'en muliggør skalerbar, parallel Spark-udførelse for automatiseringsbaserede arbejdsbelastninger. Klientapplikationer kan køre flere Spark-statements samtidigt, mens Fabric håndterer genbrug af sessioner, isolering, overvågning og fakturering.

Eksisterende Livy session- og batcharbejdsbelastninger fortsætter med at fungere uden ændringer.

Hvornår skal man bruge høj samtidighed

Standard Livius-brug er optimeret til sekventiel eller lav-samtidighedsudførelse. Efterhånden som automatiseringsscenarier vokser, har du brug for:

  • Parallel Spark-udførelse.
  • Forudsigeligt ressourceforbrug.
  • Isolation mellem samtidige arbejdsbelastninger.
  • En styret samtidighedsmodel, der integreres med Fabric-sikkerhed, overvågning og fakturering.

Uden HC-support skal du manuelt oprette og administrere flere Livy-sessioner på klientsiden. Dette øger kompleksiteten og reducerer observerbarheden.

Høj-samtidighedsudførelsesmodel

HC-eksekveringsmodellen fungerer som følger:

  1. En klient får en HC-session.
  2. Systemet opretter eller genbruger en underliggende Livy-session og opretter en Spark REPL (Read-Eval-Print Loop).
  3. Klienten udfører Spark-statements inden for HC-sessionen.
  4. Flere HC-sessioner kan udføre sætninger samtidig.
  5. Klienten kan uafhængigt hente, annullere eller slette HC-sessioner.

Hver HC-session:

  • Kort til en Spark REPL.
  • Kan udføre Spark-sætninger uafhængigt.
  • Er isoleret fra fejl eller aflysninger i andre HC-sessioner.

Genbrug af sessioner og sessionTag

Når du får en HC-session, kan du valgfrit give en sessionTag.

Det sessionTag muliggør server-side sessionspakning:

  • Hvis der findes en aktiv Livy-session sessionTag og har tilgængelig kapacitet, opretter tjenesten en ny Spark REPL inden for den session.
  • Hvis der ikke findes en egnet session, opretter tjenesten en ny underliggende Livy-session.

Bemærk følgende vigtige karakteristika:

  • HC-sessionsoptagelse er ikke idempotent.
  • Flere acquir-anmodninger med samme sessionTag returnerer forskellige HC-sessions-ID'er.
  • Den samme underliggende Livy-session kan stadig støtte flere HC-sessioner.

Nøglekoncepter

Følgende liste beskriver nøgleparametrene:

  • HC ID: Fabric identifikator for en REPL-niveau høj samtidighedssession. API'et returnerer en systemgenereret GUID.
  • Livy-sessions-ID: Den underliggende Spark/Livy-session, der kan huse flere REPLs.
  • REPL ID: Identifikatoren for REPL inden for en Livy-session. Hvert REPL-ID svarer til et HC-ID.
  • sessionTag (valgfrit): Et hint brugt til at pakke REPLs ind i eksisterende Livy-sessioner, når det er muligt.
  • Grænser: Tjenesten understøtter i øjeblikket op til fem REPL'er pr. Livy-session. Hurtige samtidige kald til HC-sessionsanskaffelses-API'en kan skabe flere Livy-sessioner.

Få en høj samtidighed Spark-session

Hvis der allerede findes en aktiv Livy-session for og sessionTag har ledige REPL-pladser, opretter tjenesten en REPL inden for den session. Ellers opretter tjenesten en ny Livy-session med en REPL indeni.

Anmodningspayload (HighConcurrencySessionRequest)

Anmodningsorganet for at opnå en session med høj samtidighed inkluderer følgende parametre:

{
  "artifactName": "string",
  "sessionTag": "string",
  "tags": { "key": "value" },
  "name": "string",
  "file": "string",
  "className": "string",
  "args": ["string"],
  "jars": ["string"],
  "files": ["string"],
  "pyFiles": ["string"],
  "archives": ["string"],
  "conf": { "spark.some.config": "value" },
  "driverMemory": "string",
  "driverCores": 1,
  "executorMemory": "string",
  "executorCores": 1,
  "numExecutors": 2
}

Bemærk følgende om anmodningsparametrene:

  • ( artifactName Lakehouse) bruges til at fremvise HC-opgaver i overvågningshubben som HC_<LakehouseName>_<LIVY_SESSION_ID>.
  • Det sessionTag er et tip til pakning. Det er ikke en streng lås. Hurtige samtidige POST-anmodninger med samme sessionTag kan skabe flere Livy-sessioner.
  • API'et er som standard ikke-idempotent. Flere POST-anmodninger kan give forskellige HC-ID'er og REPL'er.

Responspayload (HighConcurrencySessionResponse)

Responskroppen omfatter følgende felter:

{
  "id": "string",
  "state": "string",
  "fabricSessionStateInfo": { "state": "string", "errorMessage": null },
  "sessionId": "string | null",
  "workspaceId": "string",
  "artifactId": "string | null",
  "creatorId": "string",
  "createdAt": "ISO 8601",
  "replId": "string | null",
  "sessionTag": "string | null"
}

Mulige HTTP-svarkoder: 200, 400, 401, 404, 409, 500.

For den fulde OpenAPI-specifikation, se Livy API swagger definition i Fabric samples repository.

Monitoring

HC-job vises i overvågningshubben med navnet HC_<LakehouseName>_<LivySessionId> for at opretholde konsistens med andre jobtyper. Dette navngivningsformat giver overordnet synlighed, men begrænser annullering af REPL-niveau fra Fabric-portalen.

Bedste praksis

Overvej følgende bedste praksis, når du bruger sessioner med høj samtidighed:

  • Jeg plejede sessionTag at pakke relaterede opgaver ind i fælles Livy-sessioner, når det var acceptabelt.
  • Poll HC-sessionens GET-endpoint for at afgøre, hvornår er stateIdle og begge sessionId og replId er fyldt ud.

Relateret indhold

  • Last updated on