DataOps per il data warehouse moderno

Questo articolo descrive in che modo un ufficio urbanistico di una città fittizia può usare questa soluzione. La soluzione fornisce una pipeline di dati end-to-end che segue il modello architetturale MDW, insieme ai processi DevOps e DataOps corrispondenti, per valutare l'uso dei parcheggi e prendere decisioni aziendali più informate.

Architecture

Il diagramma seguente illustra l'architettura complessiva della soluzione.

Scaricare un file Visio di questa architettura.

Flusso di dati

Azure Data Factory orchestra e Azure Data Lake Storage Gen2 archivia i dati.

Il flusso di dati seguente corrisponde al diagramma precedente:

1. L'API del servizio Web di parcheggio della città di Contoso è disponibile per trasferire i dati dai posti auto.

2. Esiste un processo di copia in Data Factory che trasferisce i dati nello schema di atterraggio.

3. Successivamente, Azure Databricks pulisce e standardizza i dati. Accetta i dati non elaborati e le condizioni in modo che i data scientist possano usarli.

4. Se la convalida rivela dati danneggiati, vengono trasferiti nello schema malformato.

   Important

   Gli utenti hanno chiesto perché i dati non vengono convalidati prima che vengano archiviati in Data Lake Storage. Il motivo è che la convalida potrebbe introdurre un bug che danneggia il set di dati. Se si introduce un bug in questo passaggio, è possibile correggerlo e riprodurre la pipeline. Se è stato eseguito il dump dei dati non valido prima di aggiungerli a Data Lake Storage, i dati danneggiati sono inutili perché non è possibile riprodurre la pipeline.

5. Esiste un secondo passaggio di trasformazione Azure Databricks che converte i dati in un formato che è possibile archiviare nel data warehouse.

6. Infine, la pipeline fornisce i dati in due modi diversi:

   1. Databricks rende disponibili i dati al data scientist in modo che possa eseguire il training dei modelli.

   2. Polybase sposta i dati dal data lake in Azure Synapse Analytics e Power BI accede ai dati e lo presenta all'utente aziendale.

Components

• Azure Data Factory è un servizio di integrazione dei dati basato sul cloud che consente lo spostamento e l'orchestrazione dei dati. In questa architettura, avvia la pipeline copiando i dati dall'API del web service di parcheggio cittadino di Contoso nella zona di atterraggio del data lake.

• Azure Data Lake Storage Gen2 è un data lake scalabile e sicuro basato su Archiviazione BLOB di Azure che supporta l'archiviazione a livelli e le pipeline riproducibili. Nell'ambito di questa architettura, funge da repository centrale per i dati sia grezzi che elaborati nelle zone di atterraggio, errori di formato, e zone di dati convalidati.

• Azure Databricks è una piattaforma di analisi basata su Apache Spark progettata per Big Data e Machine Learning. In questa architettura esegue due passaggi di trasformazione critici. Prima di tutto, pulisce e standardizza i dati non elaborati, filtrando i record malformati in uno schema separato. Converte quindi i dati convalidati in un formato adatto per l'archiviazione del data warehouse e rende disponibili ai data scientist i dati elaborati per il training del modello.

• Azure Key Vault è un servizio cloud sicuro per la gestione di segreti, chiavi e certificati. In questa architettura archivia le impostazioni di configurazione sensibili e le credenziali usate in tutta la pipeline, fornendo una gestione centralizzata e sicura della configurazione.

• Azure Synapse Analytics è un servizio di analisi integrato che combina funzionalità di Big Data e data warehousing. In questa architettura funge da data warehouse che inserisce dati trasformati da Data Lake Storage tramite PolyBase per l'esecuzione di query e la creazione di report.

• Power BI è uno strumento di analisi aziendale che offre visualizzazioni e dashboard interattivi. In questa architettura, si connette a Azure Synapse Analytics per presentare informazioni dettagliate sull'utilizzo del parcheggio ai pianificatori urbani per il processo decisionale informato.

Dettagli dello scenario

Un data warehouse moderno (MDW) consente di raggruppare facilmente tutti i dati su qualsiasi scala. Non è importante se si tratti di dati strutturati, non strutturati o semistrutturati. È possibile ottenere informazioni dettagliate su un data warehouse moderno tramite dashboard analitici, report operativi o analisi avanzate per tutti gli utenti.

La configurazione di un ambiente MDW sia per gli ambienti di sviluppo (dev) che per gli ambienti di produzione (prod) è complessa. L'automazione del processo è fondamentale. Consente di aumentare la produttività riducendo al minimo il rischio di errori.

Questo articolo descrive in che modo un ufficio urbanistico di una città fittizia può usare questa soluzione. La soluzione fornisce una pipeline di dati end-to-end che segue il modello architetturale MDW, insieme ai processi DevOps e DataOps corrispondenti, per valutare l'uso dei parcheggi e prendere decisioni aziendali più informate.

Requisiti della soluzione

• Possibilità di raccogliere dati da origini o sistemi diversi.

• Infrastruttura come codice: distribuire nuovi ambienti di sviluppo e staging (stg) in modo automatizzato.

• Distribuire le modifiche alle applicazioni in ambienti diversi in modo automatico:

  • Implementare pipeline di integrazione continua e distribuzione continua (CI/CD).

  • Usare le barriere di implementazione per le approvazioni manuali.

• Pipeline come codice: verificare che le definizioni della pipeline CI/CD siano nel controllo del codice sorgente.

• Eseguire test di integrazione sulle modifiche usando un set di dati di esempio.

• Eseguire le pipeline in base a una pianificazione.

• Supportare lo sviluppo agile futuro, inclusa l'aggiunta di carichi di lavoro di data science.

• Supporto per la sicurezza sia a livello di riga che a livello di oggetto:

  • La funzionalità di sicurezza è disponibile nel database SQL.

  • È anche possibile trovarlo in Azure Synapse Analytics, Azure Analysis Services e Power BI.

• Supporto per 10 utenti simultanei del dashboard e 20 utenti esperti simultanei.

• La pipeline di dati deve eseguire la convalida dei dati e filtrare i record non validi in un'area di storage specificata.

• Supportare il monitoraggio.

Potenziali casi d'uso

Questo articolo usa la città fittizia di Contoso per descrivere lo scenario del caso d'uso. Nella narrazione Contoso è proprietaria e responsabile della gestione dei sensori di parcheggio per la città. È anche proprietaria delle API che si connettono ai sensori per recuperarne i dati. È necessaria una piattaforma in grado di raccogliere dati da molte origini diverse. I dati devono quindi essere convalidati, puliti e trasformati in uno schema noto. I pianificatori urbani di Contoso possono quindi esplorare e valutare i dati dei report sull'uso del parcheggio con strumenti di visualizzazione dei dati, ad esempio Power BI, per determinare se hanno bisogno di più parcheggio o risorse correlate.

Considerations

Queste considerazioni implementano i pilastri di Azure Well-Architected Framework, ovvero un set di set di principi guida che possono essere usati per migliorare la qualità di un carico di lavoro. Per altre informazioni, vedere Microsoft Azure Well-Architected Framework.

Le considerazioni contenute in questa sezione riepilogano le procedure consigliate e le apprendimento principali illustrate da questa soluzione:

• Usa il tiering dei dati nel tuo data lake. Conservare i dati di origine non modificati nella landing zone, instradare i record che non superano la convalida nell’area dei dati non validi e trasformare i dati convalidati in un formato pronto per il data warehouse. La conservazione dei dati di origine consente di rielaborarla senza tornare al sistema di origine. Per l'analogo schema lakehouse bronzo, argento e oro, consulta l'architettura a medaglioni.

• Rendere le pipeline di dati riproducibili e idempotenti. Progettare i passaggi di trasformazione in modo che la riesecuzione degli stessi input produca lo stesso risultato. La riproduzione di una pipeline consente di correggere un difetto nella logica di trasformazione e di rielaborare i dati cronologici anziché eliminarli.

Security

La sicurezza offre garanzie contro attacchi intenzionali e l'abuso di dati e sistemi preziosi. Per maggiori informazioni, consultare la sezione Elenco di controllo per la revisione della progettazione per la sicurezza.

• Configurazione sicura e centralizzata. Archiviare stringhe di connessione, chiavi e altri segreti in Key Vault anziché in notebook, definizioni di pipeline o controllo del codice sorgente. Farvi riferimento dai servizi collegati di Data Factory e dagli ambiti dei segreti Azure Databricks in modo che ogni ambiente risolva i propri valori.

Eccellenza operativa

L'eccellenza operativa copre i processi operativi che distribuiscono un'applicazione e la mantengono in esecuzione nell'ambiente di produzione. Per ulteriori informazioni, vedere Lista di controllo per la revisione del design per l'Eccellenza Operativa.

• Convalidare i dati nelle prime fasi della pipeline. Applica i controlli dello schema e di qualità nel primo passaggio di trasformazione e instrada i record che non li superano nello schema non valido. La validazione precoce impedisce ai record difettosi di raggiungere i livelli successivi e fornisce una traccia di ciò che è stato rifiutato e del motivo.

• Verificare che il codice di trasformazione dei dati sia testabile. Logica di trasformazione del fattore in funzioni e moduli eseguiti all'esterno di un notebook in modo da poterli coprire con unit test nella pipeline di convalida delle richieste pull.

• Disporre di una pipeline CI/CD. Compilare e rilasciare ogni ambiente dal controllo del codice sorgente invece di mano. Per i meccanismi specifici della tecnologia, vedere CI/CD in Azure Data Factory e CI/CD su Azure Databricks.

• Monitorare l'infrastruttura, le pipeline e i dati. Raccogliere metriche e log da ogni livello in modo che un errore venga visualizzato come avviso anziché come report non aggiornato. Per altre informazioni, vedere Monitor Data Factory.

Distribuire questo scenario

L'elenco seguente contiene i passaggi generali necessari per configurare questa soluzione con le pipeline di compilazione e versione corrispondenti.

Installazione e distribuzione

1. Installazione iniziale: installare tutti i prerequisiti, creare il repository Git che contiene l'infrastruttura, il notebook e il codice della pipeline e impostare le variabili di ambiente necessarie.

2. Distribuire le risorse di Azure: usare una distribuzione basata su Infrastructure as Code, ad esempio Bicep o Terraform, per distribuire le risorse di Azure e le entità servizio di Microsoft Entra per ciascun ambiente. Configurare separatamente le definizioni di Azure Pipelines, i gruppi di variabili e le connessioni al servizio che richiamano la distribuzione dell'infrastruttura.

3. Configurare l'integrazione Git nella Data Factory di sviluppo: Configurare l'integrazione Git in modo che la data factory di sviluppo esegua il commit nel repository.

4. Eseguire una compilazione e una versione iniziali: creare una modifica di esempio in Data Factory, ad esempio l'abilitazione di un trigger di pianificazione, quindi controllare la distribuzione automatica delle modifiche tra gli ambienti.

Integrazione continua e recapito continuo (CI/CD)

Il diagramma seguente illustra il processo e la sequenza CI/CD per le pipeline di compilazione e versione.

Scaricare un file Visio di questa architettura.

1. Gli sviluppatori lavorano nei propri ambienti sandbox all'interno del gruppo di risorse di sviluppo e fanno commit delle modifiche nei propri rami Git temporanei. Ad esempio: <developer_name>/<branch_name>.

2. Al termine delle modifiche, gli sviluppatori generano una richiesta pull al ramo principale per la revisione. In questo modo viene avviata automaticamente la pipeline di convalida della richiesta pull, che esegue i test unitari, il linting e la compilazione dei pacchetti applicativi di livello dati (DACPAC).

3. Al termine della convalida della richiesta pull, il commit su main attiverà una pipeline di build che rilascerà tutti gli artefatti di build necessari.

4. Il completamento di una pipeline di build riuscita attiverà la prima fase della pipeline di rilascio. Distribuendo in questo modo gli artefatti di compilazione pubblicati nell'ambiente di sviluppo, ad eccezione di Data Factory.

   Gli sviluppatori pubblicano manualmente in Dev Data Factory dal ramo di collaborazione (main). La pubblicazione manuale aggiorna i modelli di Azure Resource Manager nel ramo adf_publish.

5. Il completamento con successo della prima fase attiva una barriera di approvazione manuale.

   All'approvazione, la pipeline di rilascio continua con la seconda fase, distribuendo le modifiche nell'ambiente di staging.

6. Eseguire test di integrazione per testare le modifiche nell'ambiente stg.

7. Al completamento della seconda fase, la pipeline attiva un secondo passaggio di approvazione manuale.

   All'approvazione, la pipeline di distribuzione continua con la terza fase, distribuendo le modifiche nell'ambiente di produzione.

Per altre informazioni sull'implementazione di queste fasi, vedere CI/CD in Azure Data Factory.

Testing

La soluzione include il supporto sia per gli unit test che per i test di integrazione. Gli unit test riguardano i moduli di trasformazione Python e i test di integrazione attivano una pipeline di Data Factory e ne verificano l'output come parte della versione nell'ambiente di gestione temporanea. Per ulteriori informazioni, vedi Test unitari per i notebook.

Osservabilità e monitoraggio

La soluzione supporta l'osservabilità e il monitoraggio per Databricks e Data Factory. Per Databricks, usa il logging di controllo integrato della piattaforma (la tabella system.access.audit) e il monitoraggio delle esecuzioni dei processi anziché esportare tutti i dati diagnostici per impostazione predefinita. Se è necessario distribuire i log di diagnostica di Databricks a un'area di lavoro Log Analytics per gli avvisi centralizzati, tale funzionalità richiede il piano Premium, si applica ai log anziché alle metriche e richiede un controllo di accesso attento perché i log di controllo possono contenere dettagli sensibili sulla distribuzione. Per Data Factory, instradare i log di diagnostica e le metriche a un'area di lavoro Log Analytics e configurare avvisi in caso di errori della pipeline e latenza dei processi. Per altre informazioni, vedere Monitor Data Factory.

Passaggi successivi

Le risorse seguenti consentono di implementare le procedure di DataOps descritte in questo articolo.

Integrazione continua e distribuzione continua

• CI/CD in Azure Data Factory
• CI/CD in Azure Databricks

Observability/monitoring

Azure Databricks

• Monitoraggio dei processi di Azure Databricks con Application Insights

Data Factory

• Monitor Azure Data Factory con Monitoraggio di Azure
• Creare avvisi per monitorare proattivamente le pipeline di Data Factory

Azure Synapse Analytics

• Monitoraggio dell'utilizzo delle risorse e dell'attività di query in Azure Synapse Analytics
• Monitora il carico di lavoro del pool SQL Azure Synapse Analytics usando DMV

Archiviazione di Azure

• Monitoraggio di Archiviazione di Azure

Resilienza e ripristino di emergenza

Azure Databricks

• Ripristino di emergenza regionale per i cluster di Azure Databricks

Data Factory

• Creare e configurare un runtime di integrazione self-hosted - Disponibilità e scalabilità elevate

Azure Synapse Analytics

• Backup geografico e ripristino di emergenza
• Ripristino geografico per pool SQL

Archiviazione di Azure

• Ripristino di emergenza e failover dell'account di archiviazione
• Migliori pratiche per l'uso di Azure Data Lake Storage Gen2 – alta disponibilità e disaster recovery
• ridondanza Archiviazione di Azure

Panoramica dettagliata

Per una panoramica dettagliata dei concetti chiave e della soluzione, guardare la registrazione video seguente: DataDevOps for the Modern Data Warehouse on Microsoft Azure