Ottimizzazione delle prestazioni del runtime di integrazione di Azure
I flussi di dati vengono eseguiti in cluster Spark attivati in fase di esecuzione. La configurazione per il cluster usato è definita nel runtime di integrazione dell'attività. Quando si definisce il runtime di integrazione, è necessario tenere presenti tre considerazioni sulle prestazioni: tipo di cluster, dimensioni del cluster e durata.
Per altre informazioni su come creare un runtime di integrazione, vedere Integration Runtime.
Il modo più semplice per iniziare a usare i runtime di integrazione del flusso di dati consiste nel scegliere la selezione di dimensioni di calcolo di piccole, medie o grandi dimensioni. Vedere i mapping alle configurazioni del cluster per tali dimensioni di seguito.
Dimensioni del cluster
I flussi di dati distribuiscono l'elaborazione dei dati su core diversi in un cluster Spark per eseguire operazioni in parallelo. Un cluster Spark con più core aumenta il numero di core nell'ambiente di calcolo. Più core aumentano la potenza di elaborazione del flusso di dati. L'aumento delle dimensioni del cluster è spesso un modo semplice per ridurre il tempo di elaborazione.
Le dimensioni predefinite del cluster sono quattro core driver e quattro core di lavoro (piccole). Man mano che si elaborano più dati, sono consigliati cluster di dimensioni maggiori. Di seguito sono riportate le possibili opzioni di ridimensionamento:
| Core di lavoro | Core driver | Core totali | Note |
|---|---|---|---|
| 4 | 4 | 8 | Piccola |
| 8 | 8 | 16 | Medio |
| 16 | 16 | 32 | Grande |
| 32 | 16 | 48 | |
| 64 | 16 | 80 | |
| 128 | 16 | 144 | |
| 256 | 16 | 272 |
I flussi di dati hanno un prezzo a ore vcore, ovvero le dimensioni del cluster e il fattore di tempo di esecuzione in questo modo. Quando si aumentano le prestazioni, il costo del cluster al minuto aumenta, ma il tempo complessivo diminuisce.
Suggerimento
La dimensione di un cluster influisce sulle prestazioni di un flusso di dati. A seconda delle dimensioni dei dati, esiste un punto in cui l'aumento delle dimensioni di un cluster smetterà di migliorare le prestazioni. Ad esempio, se si dispone di più core rispetto alle partizioni di dati, l'aggiunta di core aggiuntivi non sarà utile. Una procedura consigliata consiste nell'avviare piccole dimensioni e aumentare le prestazioni per soddisfare le esigenze di prestazioni.
Partizione casuale personalizzata
Il flusso di dati divide i dati in partizioni e lo trasforma usando processi diversi. Se le dimensioni dei dati in una partizione sono superiori a quelle che il processo può contenere in memoria, il processo ha esito negativo con errori di memoria insufficiente. Se il flusso di dati contiene grandi quantità di dati con join/aggregazioni, è possibile provare a modificare le partizioni casuali in modo incrementale. È possibile impostarlo da 50 a 2000, per evitare errori OOM. Calcolare le proprietà personalizzate nel runtime del flusso di dati è un modo per controllare i requisiti di calcolo. Il nome della proprietà è Le partizioni shuffle ed è di tipo integer. Questa personalizzazione deve essere usata solo in scenari noti. In caso contrario, può causare errori di flusso di dati non necessari.
Durante l'aumento delle partizioni casuali, assicurarsi che i dati vengano distribuiti correttamente. Un numero approssimativo deve avere circa 1,5 GB di dati per partizione. Se i dati sono asimmetrici, l'aumento delle "partizioni casuali" non sarà utile. Ad esempio, se si dispone di 500 GB di dati, il valore deve essere compreso tra 400 e 500. Il limite predefinito per le partizioni casuali è di 200, che rappresenta un buon limite per circa 300 GB di dati.
- Nel portale di Azure Data Factory in Gestisci selezionare un'ora di esecuzione dell'integrazione personalizzata e passare alla modalità di modifica.
- Nella scheda dataflow run time (DataFlow Run Time) passare alla sezione Compute Custom Properties (Calcolo proprietà personalizzate).
- Selezionare Partizioni casuali in Nome proprietà, valore di input preferito, ad esempio 250, 500 e così via.
È possibile eseguire la stessa operazione modificando il file JSON di runtime aggiungendo una matrice con nome di proprietà e valore dopo una proprietà esistente, ad esempio la proprietà cleanup .
Durata (TTL)
Per impostazione predefinita, ogni attività del flusso di dati attiva un nuovo cluster Spark basato sulla configurazione del runtime di integrazione di Azure. L'avvio a freddo del cluster richiede alcuni minuti e l'elaborazione dei dati non può essere avviata fino al completamento. Se le pipeline contengono più flussi di dati sequenziali , è possibile abilitare un valore TTL (Time To Live). Se si specifica un valore time-to-live, un cluster rimane attivo per un determinato periodo di tempo dopo il completamento dell'esecuzione. Se un nuovo processo inizia a usare il runtime di integrazione durante l'ora TTL, riutilicherà il cluster esistente e l'ora di avvio verrà notevolmente ridotta. Al termine del secondo processo, il cluster rimarrà attivo per il tempo TTL.
Tuttavia, se la maggior parte dei flussi di dati viene eseguita in parallelo, non è consigliabile abilitare TTL per il runtime di integrazione usato per tali attività. Un solo processo può essere eseguito in un singolo cluster alla volta. Se è presente un cluster disponibile, ma si avviano due flussi di dati, ne verrà usato solo uno. Il secondo processo attiverà il proprio cluster isolato.
Nota
La durata non è disponibile quando si usa il runtime di integrazione di risoluzione automatica (impostazione predefinita).
Contenuto correlato
Sono disponibili altri articoli relativi alle prestazioni dei flussi di dati: