Hohe Parallelitätsunterstützung in der Fabric Livy-API

Hohe Gleichzeitigkeit (HC) in der Fabric Livy-API ermöglicht skalierbare, parallele Spark-Ausführung für automatisierungszentrierte Workloads. Clientanwendungen können mehrere Spark-Anweisungen gleichzeitig ausführen, während Fabric die Wiederverwendung, Isolierung, Überwachung und Abrechnung der Sitzung verwaltet.

Bestehende Livy-Sitzungs- und Batcharbeitslasten funktionieren weiterhin ohne Änderung.

Wann hohe Parallelität verwendet werden soll

Die Standardmäßige Livy-Verwendung ist für sequenzielle oder niedrige Parallelitätsausführung optimiert. Wenn Automatisierungsszenarien wachsen, benötigen Sie Folgendes:

  • Parallele Spark-Ausführung.
  • Vorhersehbare Ressourcennutzung.
  • Isolation zwischen konkurrierenden Workloads.
  • Ein verwaltetes Parallelitätsmodell, das mit Fabric in die Bereiche Sicherheit, Überwachung und Abrechnung integriert ist.

Ohne HC-Unterstützung müssen Sie mehrere Livy-Sitzungen auf der Clientseite manuell erstellen und verwalten. Dies erhöht die Komplexität und reduziert die Observierbarkeit.

Modell für hohe Gleichzeitigkeit der Ausführung

Das HC-Ausführungsmodell funktioniert wie folgt:

  1. Ein Client erwirbt eine HC-Sitzung.
  2. Das System erstellt oder verwendet eine zugrunde liegende Livy-Sitzung und erstellt eine Spark REPL (Read-Eval-Print Loop).
  3. Der Client führt Spark-Anweisungen innerhalb der HC-Sitzung aus.
  4. Mehrere HC-Sitzungen können Befehle gleichzeitig ausführen.
  5. Der Client kann HC-Sitzungen unabhängig abrufen, abbrechen oder löschen .

Jede HC-Sitzung:

  • Weist einem Spark-REPL zu.
  • Kann Spark-Anweisungen unabhängig ausführen.
  • Ist von Fehlern oder Absagen in anderen HC-Sitzungen isoliert.

Sitzungswiederverwendung und sessionTag

Wenn Sie eine HC-Sitzung erwerben, können Sie optional eine sessionTag.

Dies sessionTag ermöglicht das serverseitige Packen von Sitzungen:

  • Wenn eine aktive Livy-Sitzung sessionTag vorhanden ist und über verfügbare Kapazität verfügt, erstellt der Dienst innerhalb dieser Sitzung eine neue Spark-REPL.
  • Wenn keine passende Sitzung vorhanden ist, erstellt der Dienst eine neue zugrunde liegende Livy Sitzung.

Beachten Sie die folgenden wichtigen Merkmale:

  • Die HC-Sitzungsakquise ist nicht idempotent.
  • Mehrere Abrufanforderungen mit derselben sessionTag Rückgabe unterschiedlicher HC-Sitzungs-IDs.
  • Die gleiche zugrunde liegende Livy-Sitzung kann immer noch mehrere HC-Sitzungen unterstützen.

Wichtige Konzepte

In der folgenden Liste werden die wichtigsten Parameter beschrieben:

  • HC ID: Fabric-Kennzeichner für eine Hochparallelitätssitzung auf REPL-Ebene. Die API gibt eine vom System generierte GUID zurück.
  • Livy Session ID: Die zugrunde liegende Spark/Livy-Sitzung, die mehrere REPLs hosten kann.
  • REPL-ID: Der Bezeichner der REPL innerhalb einer Livy-Sitzung. Jede REPL-ID wird einer HC-ID zugeordnet.
  • sessionTag (optional): Ein Hinweis, der verwendet wird, um REPLs wenn möglich in bestehende Livy-Sitzungen zu integrieren.
  • Grenzwerte: Der Dienst unterstützt derzeit bis zu fünf REPLs pro Livy-Sitzung. Schnelle gleichzeitige Aufrufe der HC-Sitzungsakquisitions-API können mehrere Livy-Sitzungen erstellen.

Abrufen einer spark-Sitzung mit hoher Parallelität

Wenn eine aktive Livy-Sitzung für die sessionTag bereits existiert und verfügbare REPL-Slots hat, erstellt der Dienst eine REPL in dieser Sitzung. Andernfalls erstellt der Dienst eine neue Livy-Sitzung mit einer REPL darin.

Anforderungsnutzlast (HighConcurrencySessionRequest)

Der Anforderungstext zum Abrufen einer Sitzung mit hoher Parallelität umfasst die folgenden Parameter:

{
  "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
}

Beachten Sie Folgendes zu den Anforderungsparametern:

  • Das artifactName (Lakehouse) wird verwendet, um HC-Aufträge im Überwachungszentrum als HC_<LakehouseName>_<LIVY_SESSION_ID>zu erfassen.
  • Dies sessionTag ist ein Hinweis für die Verpackung. Es handelt sich nicht um eine strenge Sperre. Schnelle gleichzeitige POST-Anfragen mit demselben sessionTag können mehrere Livy-Sitzungen erstellen.
  • Die API ist standardmäßig nichtidempotent. Mehrere POST-Anforderungen können unterschiedliche HC-IDs und REPLs liefern.

Antwortnutzlast (HighConcurrencySessionResponse)

Der Antworttext enthält die folgenden Felder:

{
  "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"
}

Mögliche HTTP-Antwortcodes: 200, 400, 401, 404, 409, 500.

Die vollständige OpenAPI-Spezifikation finden Sie in der Livy API Swagger-Definition im Fabric-Beispiele-Repository.

Überwachung

HC-Aufträge werden im Überwachungshub mit dem Namen HC_<LakehouseName>_<LivySessionId> angezeigt, um die Konsistenz mit anderen Auftragstypen aufrechtzuerhalten. Dieses Benennungsformat bietet Sichtbarkeit auf höchster Ebene, schränkt jedoch die Möglichkeit zum Abbruch auf REPL-Ebene über das Fabric-Portal ein.

Bewährte Methoden

Beachten Sie bei der Verwendung von Sitzungen mit hoher Parallelität die folgenden bewährten Methoden:

  • Verwenden Sie sessionTag, um verwandte Aufgaben in freigegebene Livy-Sitzungen zu packen, wenn dies akzeptabel ist.
  • Rufen Sie den GET-Endpunkt der HC-Sitzung ab, um zu bestimmen, wann stateIdle ist und sowohl sessionId als auch replId gefüllt sind.

Verwandte Inhalte

  • Last updated on