Supporto per l'elevata concorrenza nell'API Livy di Fabric

La concorrenza elevata (HC) nell'API Fabric Livy consente l'esecuzione scalabile e parallela di Spark per carichi di lavoro di automazione.High concurrency (HC) nella Fabric API Livy abilita l'esecuzione scalabile e parallela di Spark per carichi di lavoro di automazione. Le applicazioni client possono eseguire più istruzioni Spark simultaneamente, mentre Fabric gestisce il riutilizzo della sessione, l'isolamento, il monitoraggio e la fatturazione.

I carichi di lavoro esistenti di Livy, sia batch che di sessione, continuano a funzionare senza modifiche.

Quando usare la concorrenza elevata

L'utilizzo standard di Livy è ottimizzato per l'esecuzione sequenziale o a bassa concorrenza. Man mano che gli scenari di automazione aumentano, è necessario:

  • Esecuzione di Spark parallela.
  • Utilizzo prevedibile delle risorse.
  • Isolamento tra carichi di lavoro simultanei.
  • Modello di concorrenza gestito che si integra con Fabric sicurezza, monitoraggio e fatturazione.

Senza il supporto di HC, è necessario creare e gestire manualmente più sessioni Livy sul lato client. Ciò aumenta la complessità e riduce l'osservabilità.

Modello di esecuzione a concorrenza elevata

Il modello di esecuzione HC funziona come segue:

  1. Un client acquisisce una sessione HC.
  2. Il sistema crea o riutilizza una sessione Livy sottostante e crea uno Spark REPL (Read-Eval-Print Loop).
  3. Il client esegue istruzioni Spark all'interno della sessione HC.
  4. Diverse sessioni HC possono eseguire istruzioni contemporaneamente.
  5. Il client può recuperare, annullare o eliminare sessioni HC in modo indipendente.

Ogni sessione HC:

  • Mappa a un REPL Spark.
  • Può eseguire istruzioni Spark in modo indipendente.
  • È isolato da errori o annullamenti in altre sessioni HC.

Riutilizzo della sessione e sessionTag

Quando si acquisisce una sessione HC, è possibile facoltativamente specificare un sessionTag.

sessionTag Abilita la compressione della sessione sul lato server:

  • Se esiste una sessione Livy attiva per sessionTag e ha capacità disponibile, il servizio crea un nuovo REPL di Spark all'interno di quella sessione.
  • Se non esiste alcuna sessione appropriata, il servizio crea una nuova sessione Livy sottostante.

Si notino le caratteristiche importanti seguenti:

  • L'acquisizione della sessione HC non è idempotente.
  • Più richieste di acquisizione con lo stesso sessionTag restituiscono diversi ID sessione HC.
  • La stessa sessione Livy sottostante potrebbe comunque supportare più sessioni HC.

Concetti chiave

L'elenco seguente descrive i parametri chiave:

  • HC ID: identificatore Fabric per una sessione di concorrenza elevata di livello REPL. L'API restituisce un GUID generato dal sistema.
  • ID sessione Livy: la sessione Spark/Livy sottostante che può gestire più REPL.
  • ID REPL: identificatore del REPL all'interno di una sessione Livy. Ogni ID REPL viene mappato a un ID HC.
  • sessionTag (facoltativo): Un suggerimento utilizzato per comprimere i REPL in sessioni Livy esistenti, quando possibile.
  • Limiti: il servizio supporta attualmente fino a cinque REPLs per sessione Livy. Le chiamate simultanee rapide all'API di acquisizione di sessioni HC possono creare più sessioni Livy.

Acquisire una sessione Spark ad alta concorrenza

Se esiste già una sessione Livy attiva per sessionTag e dispone di slot REPL disponibili, il servizio crea un REPL all'interno di tale sessione. In caso contrario, il servizio crea una nuova sessione Livy con un REPL al suo interno.

Payload della richiesta (HighConcurrencySessionRequest)

Il corpo della richiesta per acquisire una sessione ad alta concorrenza include i seguenti parametri:

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

Tenere presente quanto segue sui parametri della richiesta:

  • Il artifactName (lakehouse) viene utilizzato per far emergere i lavori HC nell'hub di monitoraggio come HC_<LakehouseName>_<LIVY_SESSION_ID>.
  • sessionTag è un suggerimento per l'imballaggio. Non è un blocco rigoroso. Le richieste POST simultanee rapide con lo stesso sessionTag potrebbero creare più sessioni Livy.
  • L'API è nonidempotente per impostazione predefinita. Più richieste POST possono produrre ID HC e REPLs distinti.

Payload della risposta (HighConcurrencySessionResponse)

Il corpo della risposta include i campi seguenti:

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

Possibili codici di risposta HTTP: 200, 400, 401, 404, 409, 500.

Per la specifica OpenAPI completa, vedere la definizione swagger dell'API Livy API nel repository degli esempi di Fabric.

Monitoraggio

I job HC vengono visualizzati nell'hub di monitoraggio con il nome HC_<LakehouseName>_<LivySessionId> per mantenere la coerenza con altri tipi di job. Questo formato di denominazione offre visibilità di primo livello, ma limita l'annullamento a livello REPL dal portale di Fabric.

Procedure consigliate

Quando si usano sessioni di concorrenza elevate, considerare le procedure consigliate seguenti:

  • Usare sessionTag per comprimere i processi correlati in sessioni Livy condivise, se accettabili.
  • Eseguire il polling dell'endpoint GET della sessione HC per determinare quando state è Idle e sessionId e replId sono popolati.

Contenuti correlati

  • Last updated on