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.
Architettura
Il diagramma seguente illustra l'architettura complessiva della soluzione.
Scaricare un file di Visio di questa architettura.
Flusso di dati
Azure Data Factory orchestra e Azure Data Lake Storage Gen2 archivia i dati:
L'API del servizio Web di parcheggio della città di Contoso è disponibile per trasferire i dati dai posti auto.
Esiste un processo di copia della data factory che trasferisce i dati nello schema di destinazione.
Successivamente, Azure Databricks pulisce e standardizza i dati. Accetta i dati non elaborati e le condizioni in modo che i data scientist possano usarli.
Se la convalida rivela dati non validi, viene eseguito il dump nello schema in formato non valido.
Importante
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.
Esiste un secondo passaggio di trasformazione di Azure Databricks che converte i dati in un formato che è possibile archiviare nel data warehouse.
Infine, la pipeline fornisce i dati in due modi diversi:
Databricks rende disponibili i dati al data scientist in modo che possa eseguire il training dei modelli.
Polybase sposta i dati dal data lake ad Azure Synapse Analytics e Power BI accede ai dati e li presenta all'utente aziendale.
Componenti
La soluzione usa i componenti seguenti:
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 automatico.
Distribuire le modifiche alle applicazioni in ambienti diversi in modo automatico:
Implementare pipeline di integrazione continua e recapito continuo (CI/CD).
Usare i gate di distribuzione 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 trovarla 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 in formato non valido in un archivio specificato.
Supporto di monitoraggio.
Configurazione centralizzata in un archivio sicuro come Azure Key Vault.
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. Gli addetti all’urbanistica di Contoso possono quindi esplorare e valutare i dati dei report sull'uso dei parcheggi con strumenti di visualizzazione dei dati, ad esempio Power BI, per determinare se sono necessari più posti auto o risorse correlate.
Considerazioni
Queste considerazioni implementano i pilastri di Azure Well-Architected Framework, che è un 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:
Nota
Ogni considerazione in questa sezione è collegata alla sezione Relativa all'apprendimento delle chiavi nella documentazione relativa all'esempio di soluzione del sensore di parcheggio in GitHub.
Sicurezza
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.
Eccellenza operativa
L'eccellenza operativa copre i processi operativi che distribuiscono un'applicazione e la mantengono in esecuzione nell'ambiente di produzione. Per maggiori informazioni, consultare la sezione Elenco di controllo per la revisione della progettazione per l'eccellenza operativa.
Distribuire lo scenario
L'elenco seguente contiene i passaggi di alto livello obbligatori per configurare la soluzione dei sensori di parcheggio con le corrispondenti pipeline di versione e compilazione. I passaggi di configurazione e i prerequisiti dettagliati sono disponibili in questo repository di esempi di Azure.
Installazione e distribuzione
Configurazione iniziale: installare tutti i prerequisiti, importare il repository di esempi GitHub Azure nel proprio repository e impostare le variabili di ambiente obbligatorie.
Distribuire le risorse di Azure: la soluzione include uno script di distribuzione automatizzato. Distribuisce tutte le risorse di Azure necessarie e le entità servizio Microsoft Entra per ogni ambiente. Lo script distribuisce anche Azure Pipelines, gruppi di variabili e connessioni al servizio.
Configurare l'integrazione git in Dev Data Factory: configurare l'integrazione git per l'uso con il repository GitHub importato.
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.
Risorse distribuite
Se la distribuzione ha esito positivo, in Azure devono essere presenti tre gruppi di risorse che rappresentano tre ambienti: dev, stg e prod. In Azure DevOps devono essere presenti anche pipeline di compilazione e versione end-to-end che possono distribuire automaticamente le modifiche in questi tre ambienti.
Per un elenco dettagliato di tutte le risorse, vedere la sezione Deployed Resources (Risorse distribuite) del file LEGGIMI DataOps - Parking Sensor Demo (Demo del sensore di parcheggio).
Integrazione continua e recapito continuo (CI/CD)
Il diagramma seguente illustra il processo e la sequenza di CI/CD per le pipeline di compilazione e versione.
Scaricare un file di Visio di questa architettura.
Gli sviluppatori sviluppano nei propri ambienti sandbox all'interno del gruppo di risorse di sviluppo ed eseguono il commit delle modifiche nei propri rami Git di breve durata. Ad esempio:
<developer_name>/<branch_name>.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 le compilazioni di unit test, linting e pacchetto applicazione livello dati ( DACPAC).
Al termine della convalida della richiesta pull, il commit in main attiverà una pipeline di compilazione che pubblica tutti gli artefatti di compilazione necessari.
Il completamento di una pipeline di compilazione riuscita attiverà la prima fase della pipeline di versione. In questo modo, gli artefatti di compilazione di pubblicazione vengono distribuiti 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
adf_publishramo .Il completamento corretto della prima fase attiva un controllo di approvazione manuale.
In Approvazione la pipeline di versione continua con la seconda fase, distribuendo le modifiche nell'ambiente stg.
Eseguire test di integrazione per testare le modifiche nell'ambiente stg.
Al completamento della seconda fase, la pipeline attiva un secondo controllo di approvazione manuale.
In Approvazione la pipeline di versione continua con la terza fase, distribuendo le modifiche nell'ambiente prod.
Per altre informazioni, vedere la sezione Build and Release Pipeline (Pipeline di compilazione e versione) del file LEGGIMI.
Test
La soluzione include il supporto sia per gli unit test che per i test di integrazione. Usa pytest-Data Factory e nutter Testing Framework. Per altre informazioni, vedere la sezione Test del file LEGGIMI.
Osservabilità e monitoraggio
La soluzione supporta l'osservabilità e il monitoraggio per Databricks e Data Factory. Per altre informazioni, vedere la sezione Osservabilità/monitoraggio del file LEGGIMI.
Passaggi successivi
Se si desidera distribuire la soluzione, seguire la procedura descritta nella sezione How to use the sample (Come utilizzare l’esempio) del file README Demo dataOps - Parking Sensor.
Esempi di codice della soluzione su GitHub
Osservabilità/monitoraggio
Azure Databricks
- Monitoraggio di Azure Databricks con Monitoraggio di Azure
- Monitoraggio dei processi Azure Databricks con Application Insights
Data Factory
- Monitorare Azure Data Factory con Monitoraggio di Azure
- Creare avvisi per monitorare in modo proattivo le pipeline di data factory
Azure Synapse Analytics
- Monitoraggio dell'attività di query e dell'utilizzo delle risorse in Azure Synapse Analytics
- Monitorare il carico di lavoro del pool SQL Azure Synapse Analytics tramite DMV
Archiviazione di Azure
Resilienza e ripristino di emergenza
Azure Databricks
Data Factory
Azure Synapse Analytics
Archiviazione di Azure
- Ripristino di emergenza e failover dell'account di archiviazione
- Procedure consigliate per l'uso di Azure Data Lake Storage Gen2: disponibilità elevata e ripristino di emergenza
- Ridondanza di Archiviazione di Azure
Procedura dettagliata
Per una procedura dettagliata della soluzione e dei concetti chiave, guardare la registrazione video seguente: DataDevOps for the Modern Data Warehouse on Microsoft Azure