Procedure consigliate per l'affidabilità

Questo articolo illustra le pratiche consigliate per l'affidabilità, organizzate in base ai principi architetturali elencati nelle sezioni seguenti.

1. Progettazione per gli errori

Utilizzare un formato dati che supporti le transazioni ACID

Le transazioni ACID sono una funzionalità critica per mantenere l'integrità e la coerenza dei dati. La scelta di un formato dati che supporti le transazioni ACID consente di creare pipeline più semplici e molto più affidabili.

Delta Lake è un framework di archiviazione open source che fornisce transazioni ACID nonché l'imposizione dello schema, la gestione scalabile dei metadati e unifica l'elaborazione dei dati in streaming e batch. Delta Lake è completamente compatibile con le API Apache Spark ed è progettato per una stretta integrazione con lo streaming strutturato, consentendo di usare facilmente una singola copia di dati per le operazioni batch e di streaming e fornire l'elaborazione incrementale su larga scala.

Usare un motore dati distribuito resiliente per tutti i carichi di lavoro

Apache Spark, in qualità di motore di calcolo di Azure Databricks Lakehouse, si basa sull'elaborazione resiliente dei dati distribuiti. Se un task Spark interna non restituisce un risultato come previsto, Apache Spark riprogramma automaticamente i task mancanti e continua a eseguire l'intero processo. Questo è utile per gli errori out-of-code, ad esempio un breve problema di rete o una VM spot revocata. L'uso dell'API SQL e dell'API DataFrame Spark consente di integrare questa resilienza nel motore.

In Databricks lakehouse, Photon, un motore vettorializzato nativo interamente scritto in C++, è un ambiente di calcolo ad alte prestazioni compatibile con le API Apache Spark.

Salvataggio automatico di dati non validi o non conformi

I dati non validi o non conformi possono causare l'arresto anomalo dei carichi di lavoro che si basano su un formato di dati stabilito. Per aumentare la resilienza end-to-end dell'intero processo, è consigliabile escludere dati non validi e non conformi all'inserimento. Il supporto per i dati recuperati garantisce che non si perdano mai i dati durante l'inserimento o l'ETL. La colonna di dati salvata contiene tutti i dati che non sono stati analizzati, perché mancavano dallo schema specificato, perché si verificava una mancata corrispondenza del tipo o perché il corpo della colonna nel record o nel file non corrispondeva a quello nello schema.

• Caricatore automatico di Databricks: il Caricatore Automatico è lo strumento ideale per l'inserimento dei file in streaming. Supporta i dati recuperati per JSON e CSV. Ad esempio, per JSON, la colonna di dati salvata contiene eventuali dati che non sono stati analizzati, probabilmente perché erano assenti dallo schema fornito, perché c'era una mancata corrispondenza del tipo o perché il formato delle lettere della colonna non corrispondeva. La colonna di dati salvata fa parte dello schema restituito da Auto Loader come _rescued_data per impostazione predefinita quando lo schema viene dedotto automaticamente.
• DLT: Un'altra opzione per creare flussi di lavoro per la resilienza consiste nell'usare DLT con vincoli di qualità. Vedi Gestisci la qualità dei dati con le aspettative della pipeline. DLT supporta tre modalità per impostazione predefinita: mantieni, elimina e fallisce in caso di record non validi. Per mettere in quarantena i record non validi identificati, le regole di attesa possono essere definite in modo specifico in modo che i record non validi vengano archiviati ("messi in quarantena") in un'altra tabella. Visualizza Mettere in quarantena i record non validi.

Configurare i processi per i tentativi automatici e l'interruzione

I sistemi distribuiti sono complessi e un errore in un punto può potenzialmente propagarsi in tutto il sistema.

• I processi di Azure Databricks supportano i criteri di ripetizione per i task che determinano quando e quante volte vengono ripetute le esecuzioni non riuscite. Vedere Impostare un criterio di ripetizione dei tentativi.
• È possibile configurare soglie di durata facoltative per un task, inclusi un tempo di completamento previsto e un tempo di completamento massimo.
• DLT automatizza anche il ripristino dai guasti tramite tentativi incrementali per bilanciare la velocità e l'affidabilità. Vedere Sviluppo e modalità di produzione.

D'altra parte, un'attività in sospeso può impedire il completamento dell'intero processo, causando costi elevati. I processi di Databricks supportano la configurazione del timeout per terminare i processi che richiedono più tempo del previsto.

Usare un'infrastruttura di gestione dei modelli scalabile e di livello di produzione

Per l'elaborazione batch e di streaming, usare i processi di Azure Databricks e MLflow per implementare modelli come funzioni definite dall'utente di Apache Spark per sfruttare la pianificazione dei processi, i riavvii, l'autoscalabilità e così via. Consulta Distribuire modelli per l'inferenza e la previsione batch.

Model Serving offre un'infrastruttura scalabile e di livello di produzione per la gestione dei modelli in tempo reale. Elabora i modelli di Machine Learning usando MLflow e li espone come endpoint dell'API REST. Questa funzionalità usa l'elaborazione serverless, ovvero gli endpoint e le risorse di calcolo associate vengono gestiti ed eseguiti nell'account cloud di Azure Databricks.

Usare i servizi gestiti laddove possibile

Sfrutta i servizi gestiti (calcolo serverless) dalla Piattaforma di Intelligenza dei Dati di Databricks, ad esempio:

• Warehouse SQL serverless
• Gestione dei modelli
• Attività serverless
• Calcolo serverless per notebook
• DLT

Questi servizi vengono gestiti da Databricks in modo affidabile e scalabile senza costi aggiuntivi per il cliente, rendendo i carichi di lavoro più affidabili.

2. Gestire la qualità dei dati

Usare un'architettura di archiviazione a più livelli

Curare i dati creando un'architettura a più livelli e assicurando che la qualità dei dati aumenti man mano che i dati si spostano attraverso i livelli. Un approccio di layering comune è:

• Livello non elaborato (bronzo): i dati di origine vengono inseriti nel lakehouse nel primo livello e devono essere salvati lì in modo permanente. Quando tutti i dati downstream vengono creati dal livello non elaborato, è possibile ricompilare i livelli successivi da questo livello in base alle esigenze.
• Livello curato (argento): lo scopo del secondo livello è quello di contenere dati puliti, perfezionati, filtrati e aggregati. L'obiettivo di questo livello è fornire una solida base affidabile per l'analisi e la creazione di report in tutti i ruoli e le funzioni.
• Livello finale (oro): il terzo livello è costruito in base alle esigenze aziendali o di progetto. Offre una visualizzazione diversa sotto forma di prodotti dati per altre unità aziendali o progetti, preparando i dati in base alle esigenze di sicurezza (ad esempio, dati anonimi) o ottimizzando per le prestazioni (ad esempio, con le viste preaggregate). I prodotti di dati in questo livello sono considerati la verità per l'azienda.

Il livello finale deve contenere solo dati di alta qualità e deve essere completamente attendibile dal punto di vista aziendale.

Migliorare l'integrità dei dati riducendo la ridondanza dei dati

La copia o la duplicazione dei dati crea ridondanza dei dati e comporta la perdita di integrità, la perdita di derivazione dei dati e spesso autorizzazioni di accesso diverse. In questo modo si riduce la qualità dei dati nel lakehouse.

Una copia provvisoria o monouso dei dati non è dannosa in se stessa: a volte è necessario aumentare agilità, sperimentazione e innovazione. Tuttavia, quando queste copie diventano operative e vengono usate regolarmente per prendere decisioni aziendali, diventano silo di dati. Quando questi silo di dati non sono più sincronizzati, ha un impatto negativo significativo sull'integrità e sulla qualità dei dati, generando domande come "Quale set di dati è il principale?" o «Il set di dati è aggiornato?»

Gestire attivamente gli schemi

Le modifiche dello schema non controllate possono causare dati non validi e processi con errori che usano questi set di dati. Azure Databricks offre diversi metodi per convalidare e applicare lo schema:

• Delta Lake supporta la convalida dello schema e l'applicazione dello schema gestendo automaticamente le variazioni dello schema per impedire l'inserimento di record non validi durante l'acquisizione. Vedi Applicazione dello schema.
• Caricatore Automatico rileva l'aggiunta di nuove colonne durante l'elaborazione dei tuoi dati. Per impostazione predefinita, l'aggiunta di una nuova colonna fa sì che i flussi si arrestino con un UnknownFieldException. Auto Loader supporta diverse modalità per l'evoluzione dello schema .

Usare vincoli e aspettative sui dati

Le tabelle Delta supportano clausole di gestione dei vincoli SQL standard che assicurano che la qualità e l'integrità dei dati aggiunti a una tabella vengano controllate automaticamente. Quando viene violato un vincolo, Delta Lake genera un errore di InvariantViolationException per segnalare che i nuovi dati non possono essere aggiunti. Vedere Vincoli in Azure Databricks.

Per migliorare ulteriormente questa gestione, DLT supporta le aspettative: le aspettative definiscono vincoli di qualità dei dati sul contenuto di un set di dati. Un'aspettativa consiste in una descrizione, un invariante e un'azione da intraprendere se un record viola l'invariante. Le aspettative sulle query fanno uso di decorator Python o clausole di vincolo SQL. Vedi Gestire la qualità dei dati con le aspettative della pipeline.

Adottare un approccio incentrato sui dati per l'apprendimento automatico

Un principio guida che rimane alla base della visione dell'IA per Databricks Data Intelligence Platform è un approccio incentrato sui dati per l'apprendimento automatico. Man mano che l'IA generativa diventa più diffusa, questa prospettiva rimane altrettanto importante.

I componenti principali di qualsiasi progetto ML possono essere semplicemente considerati come pipeline di dati: ingegneria delle funzionalità, training, distribuzione di modelli, inferenza e pipeline di monitoraggio sono tutte pipeline di dati. Di conseguenza, l'operazionalizzazione di una soluzione ml richiede l'unione di dati da tabelle di stima, monitoraggio e funzionalità con altri dati pertinenti. Fondamentalmente, il modo più semplice per ottenere questo risultato consiste nello sviluppare soluzioni basate sull'IA nella stessa piattaforma usata per gestire i dati di produzione. Vedere MLOps e LLMOps incentrati sui dati

3. Progettare per la scalabilità automatica

Abilitare la scalabilità automatica per i carichi di lavoro ETL

La scalabilità automatica consente ai cluster di ridimensionarsi automaticamente in base ai carichi di lavoro. La scalabilità automatica può trarre vantaggio da molti casi d'uso e scenari sia dal punto di vista dei costi che delle prestazioni. La documentazione fornisce considerazioni per determinare se usare la scalabilità automatica e come ottenere il massimo vantaggio.

Per i carichi di lavoro di streaming, Databricks consiglia di usare DLT con scalabilità automatica. La scalabilità automatica avanzata di Databricks ottimizza l'utilizzo del cluster assegnando automaticamente le risorse del cluster in base al volume del carico di lavoro, con un impatto minimo sulla latenza di elaborazione dati delle pipeline.

Abilitare la scalabilità automatica per SQL Warehouse

Il parametro di ridimensionamento di un'istanza di SQL Warehouse imposta il numero minimo e massimo di cluster su cui vengono distribuite le query inviate al warehouse. Il valore predefinito è un singolo cluster senza scalabilità automatica.

Per gestire più utenti simultanei per un determinato magazzino, aumentare il numero di cluster. Per informazioni su come Azure Databricks aggiunge e rimuove cluster da un magazzino dati, vedere Dimensionamento, ridimensionamento e comportamento di accodamento per SQL Warehouse.

4. Test delle procedure di ripristino

Recupero dalle interruzioni delle query di Structured Streaming

Structured Streaming offre tolleranza di errore e coerenza dei dati per le query di streaming. Usando i processi di Databricks, è possibile configurare facilmente le query Structured Streaming per il riavvio automatico in caso di errore. Abilitando il checkpoint per una query di streaming, è possibile riavviare la query dopo un errore. La query riavviata continuerà da dove la query non riuscita è stata interrotta. Consulta Checkpoint di Structured Streaming e Considerazioni produttive per Structured Streaming.

Recuperare i lavori ETL usando le funzionalità di time travel dei dati

Nonostante test accurati, un processo potrebbe non riuscire nell'ambiente di produzione o potrebbe generare dati imprevisti, anche non validi. A volte questo problema può essere risolto con un processo aggiuntivo dopo aver compreso l'origine del problema e corretto la pipeline che ha causato il problema all'origine. Tuttavia, spesso questo non è semplice e il processo in questione dovrebbe essere annullato. Usando il Delta Time, gli utenti possono eseguire facilmente il rollback delle modifiche a una versione o a un timestamp precedente, ripristinare la pipeline e riavviare il sistema corretto.

Un modo pratico per eseguire questa operazione è il comando RESTORE.

Sfruttare un framework di automazione con ripristino integrato

I Jobs Databricks sono progettati per il ripristino. Quando un'attività in un processo con più attività ha esito negativo (e, di conseguenza, tutte le attività dipendenti), i processi di Azure Databricks forniscono una visualizzazione matrice delle esecuzioni che consentono di analizzare il problema che ha causato l'errore, vedere Visualizzazione esecuzioni per un singolo processo. Se si tratta di un problema di rete breve o di un problema reale nei dati, è possibile risolverlo e avviare un'esecuzione di ripristino nei processi di Azure Databricks. Verranno eseguiti solo i task non riusciti e quelli dipendenti, mentre i risultati corretti di esecuzioni precedenti verranno mantenuti, risparmiando tempo e denaro. Vedere Risoluzione dei problemi e riparazione degli errori dei processi.

Configurare un modello di ripristino di emergenza

Per una piattaforma di analisi dei dati nativa del cloud come Azure Databricks, un modello di ripristino di emergenza chiaro è fondamentale. È fondamentale che i team di dati possano usare la piattaforma Azure Databricks anche in rari casi di interruzione a livello di servizio a livello di area di un provider di servizi cloud, a causa di un'emergenza a livello di area, ad esempio un uragano, un terremoto o un'altra origine.

Azure Databricks è spesso una parte fondamentale di un ecosistema di dati complessivo che include molti servizi, tra cui servizi di inserimento dati upstream (batch/streaming), archiviazione nativa del cloud, ad esempio Azure Data Lake Storage Gen2, strumenti downstream e servizi come app di business intelligence e strumenti di orchestrazione. Alcuni casi d'uso possono essere particolarmente sensibili a un'interruzione del servizio a livello locale.

Disaster recovery comporta un insieme di politiche, strumenti e procedure che consentono il ripristino o la continuazione di infrastrutture e sistemi tecnologici vitali in seguito a un disastro naturale o provocato dall'uomo. Un servizio cloud di grandi dimensioni, ad esempio Azure, serve molti clienti e offre protezioni predefinite per un singolo errore. Ad esempio, un'area è un gruppo di edifici collegati a diverse fonti di alimentazione per garantire che un'unica interruzione dell'alimentazione non metta in difficoltà un'area. Tuttavia, gli errori dell'area cloud possono verificarsi e la gravità dell'errore e il relativo impatto sull'azienda possono variare.

5. Automatizzare distribuzioni e carichi di lavoro

Vedere Eccellenza operativa - Automatizzare distribuzioni e carichi di lavoro.

6. Monitorare sistemi e carichi di lavoro

Consulta Operational Excellence - Configurare il monitoraggio, gli avvisi e i log.