Procedure consigliate per le trasformazioni dati batch

Pianificazione e test prima della pianificazione in produzione

Convalidare la progettazione prima della distribuzione e aggiornare le trasformazioni dopo modifiche importanti.

• Iniziare con volumi di dati più piccoli. Convalidare la logica di trasformazione in un sottoinsieme rappresentativo prima di aumentare la scala.
• Test su scala di produzione in un Sandbox. Prima di eseguire la pianificazione in produzione, testare prima la trasformazione in un Sandbox, soprattutto quando si stanno avvicinando i limiti consigliati per i join o i nodi totali.
• Rivedere le trasformazioni dopo modifiche importanti. La crescita dei dati, nuove fonti, aggiornamenti dello schema o modifiche delle regole di corrispondenza possono spingere la trasformazione oltre i presupposti di progettazione originali.
• Mantenere attiva ogni trasformazione. Suddividere le trasformazioni di grandi dimensioni in trasformazioni più piccole ed eseguirle in sequenza, con l'output di ogni trasformazione che alimenta la trasformazione successiva. Diverse trasformazioni più piccole in genere funzionano meglio di una trasformazione monolitica con molti join, record ampi e aggregazioni di grandi dimensioni.

Mantenere stretti i dati

L'elaborazione dei soli dati necessari riduce al minimo l'utilizzo delle risorse e velocizza le trasformazioni.

• Selezionare solo le colonne necessarie in ogni nodo di input. È sempre possibile aggiungerne altri in seguito. Minore è il numero di colonne elaborate dalla trasformazione, più veloce sarà l'esecuzione.
• Passare solo i campi obbligatori in join e aggregazioni. Rilasciare le colonne non utilizzate il più presto possibile nella pipeline.
• Evitare gli output molto ampi. Inviare solo i campi effettivamente necessari al DLO o DMO di destinazione.

Filtraggio precoce e aggressivo

I filtri riducono il volume di dati che fluiscono in operazioni costose come join e aggregazioni.

• Aggiungere filtri prima dei join. Subito prima di ogni nodo join, aggiungere un nodo filter per rimuovere i record con chiavi join nulle o vuote. Vedere l'esempio seguente.
• Aggiungere filtri prima delle aggregazioni. Prima di un nodo di aggregazione, aggiungere un nodo filtro che rimuove i record non validi o fuori intervallo, ad esempio date non valide, stati imprevisti o importi impossibili.

Esempio di espressione filter per escludere chiavi join vuote:

trim(customer_id__c) != '' AND customer_id__c IS NOT NULL

Gestione coerente di valori nulli e vuoti

Un trattamento incoerente di stringhe vuote, spazi vuoti e valori sentinella come 'N/D' o 'UNKNOWN' può causare un comportamento di join imprevedibile.

• Rappresentare le informazioni mancanti in un modo. Null è il più comune. Convertire altre varianti nella rappresentazione scelta prima di unire i nodi.
• Utilizzare i valori predefiniti quando necessario. Sostituire impostazioni predefinite come 0 o '' solo quando ciò è semanticamente significativo per i dati. In caso contrario, lasciare i valori nulli ed escluderli con i filtri.

Capire quali nodi svolgono più lavoro

Alcuni nodi svolgono un lavoro notevolmente maggiore rispetto ad altri. La riduzione del numero di nodi pesanti utilizzati e della quantità di dati che li attraversa ha il maggiore impatto sulle prestazioni.

Utilizzo di chiavi join ben definite

Chiavi join mal definite sono una delle cause più comuni di trasformazioni lente e errori di memoria.

• Utilizzare chiavi complete. Applicare chiavi complete a tutti i campi chiave principale ed esterna coinvolti nei join, in modo che le chiavi vengano interpretate in modo coerente nelle fonti.
• Prestare attenzione ai duplicati sulle chiavi principali. Quando la stessa chiave appare più volte su entrambi i lati di un join, il risultato cresce in modo moltiplicativo. Se una chiave appare 100 volte su ogni lato, un inner join produce 10.000 righe solo per quella chiave. Questo è noto come join exploding.
• Annullare la duplicazione o l'aggregazione prima di entrare. Quando non è possibile garantire l'univocità all'origine, annullare la duplicazione o aggregare prima di entrare.

Occhio a Data Skew

Lo sfasamento dei dati si verifica quando un singolo valore della chiave appare molto più spesso di altri. Gli esempi comuni includono un account "tutto compreso", un segmento 'Sconosciuto' o un ID predefinito come 000000. I record si accumulano in modo non uniforme durante l'elaborazione, il che può esaurire la memoria e causare l'errore della trasformazione.

Regola generale: Se un singolo valore della chiave di join rappresenta più del 5-10% delle righe, trattarlo come un caso speciale.

Mitigazioni:

• Elaborare le chiavi anomale in una trasformazione separata. Ad esempio, gestire gli ID 'SCONOSCIUTO' nella propria trasformazione.
• Riepilogare i dati a volume elevato fino al livello di dettaglio effettivamente necessario prima di unirli a tabelle di riferimento o di ricerca più piccole.

Limiti consigliati per trasformazione

Queste sono linee guida, non limiti rigidi. Le trasformazioni possono superarle, ma ciò dovrebbe richiedere ulteriori test delle prestazioni.

Se sono necessari più join di quelli consigliati, valutare la possibilità di pre-unire piccole serie di dati di riferimento a monte o di mantenere risultati intermedi a un DLO.

Considerazioni sulle fonti esterne

Le fonti esterne si comportano in modo diverso sotto carico a seconda del tipo.

• Le fonti esterne accelerate si comportano come DLO locali. I dati possono essere elaborati in parallelo, il che si adatta bene a grandi volumi.
• Le sorgenti esterne live vengono elaborate come stream singolo anziché in parallelo, il che può causare problemi di memoria con volumi elevati.

Se si utilizzano serie di dati di grandi dimensioni provenienti da una fonte esterna live, valutare se una fonte accelerata è più adatta.