DataOps per il data warehouse moderno

Azure Data Factory

Azure Databricks

Azure DevOps

Azure Key Vault

Azure Synapse Analytics

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 di Visio di questa architettura.

Dataflow

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

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 della data factory che trasferisce i dati nello schema di destinazione.

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 non validi, viene eseguito il dump nello schema in formato non valido.

   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 di 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 ad Azure Synapse Analytics e Power BI accede ai dati e li 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 servizio Web di parcheggio città contoso nella zona di destinazione 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. In questa architettura funge da repository centrale per i dati non elaborati e elaborati nelle zone dati di destinazione, in formato non valido e convalidato.

• 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 durante il filtro dei record in formato non valido 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 ad Azure Synapse Analytics per presentare informazioni dettagliate sull'utilizzo del parcheggio ai progettisti di città 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 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.

• 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. 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.

Considerations

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:

Note

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.

• Usare la suddivisione in livelli dati in Data Lake.

• Rendere riproducibili e idempotenti le pipeline di dati.

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.

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.

• Convalidare i dati nelle prime fasi della pipeline.

• Verificare che il codice di trasformazione dei dati sia testabile.

• Creare una pipeline CI/CD.

• Monitorare l'infrastruttura, le pipeline e i dati.

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

1. Installazione iniziale: installare tutti i prerequisiti, importare il repository GitHub di Esempi di Azure nel proprio repository e impostare le variabili di ambiente necessarie.

2. 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.

3. Configurare l'integrazione git in Dev Data Factory: configurare l'integrazione git per l'uso con il repository GitHub importato.

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.

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 Risorse distribuite di DataOps - Parking Sensor Demo README.For a detailed list of all resources, see the Deployed Resources section of the DataOps - Parking Sensor Demo README.For a detailed list of all resources, see the Deployed Resources section of the DataOps - Parking Sensor Demo README.

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 di Visio di questa architettura.

1. 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>.

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 le compilazioni di unit test, linting e pacchetto applicazione livello dati ( DACPAC).

3. Al termine della convalida della richiesta pull, il commit in main attiverà una pipeline di compilazione che pubblica tutti gli artefatti di compilazione necessari.

4. 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_publish ramo .

5. 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.

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

7. 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 ) di README.

Testing

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 README.

Osservabilità e monitoraggio

La soluzione supporta l'osservabilità e il monitoraggio per Databricks e Data Factory. Per altre informazioni, vedere la sezione Observability/Monitoring di README.

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

• Visitare la pagina del progetto in GitHub

Observability/monitoring

Azure Databricks

• 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

Azure Storage

• Monitorare Archiviazione di Azure

Resilienza e ripristino di emergenza

Azure Databricks

• Ripristino di emergenza a livello di area per 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

Azure Storage

• 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

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 di Visio di questa architettura.

Dataflow

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

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 della data factory che trasferisce i dati nello schema di destinazione.

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 non validi, viene eseguito il dump nello schema in formato non valido.

   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 di 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 ad Azure Synapse Analytics e Power BI accede ai dati e li 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 servizio Web di parcheggio città contoso nella zona di destinazione 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. In questa architettura funge da repository centrale per i dati non elaborati e elaborati nelle zone dati di destinazione, in formato non valido e convalidato.

• 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 durante il filtro dei record in formato non valido 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 ad Azure Synapse Analytics per presentare informazioni dettagliate sull'utilizzo del parcheggio ai progettisti di città 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 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.

• 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. 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.

Considerations

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:

Note

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.

• Usare la suddivisione in livelli dati in Data Lake.

• Rendere riproducibili e idempotenti le pipeline di dati.

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.

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.

• Convalidare i dati nelle prime fasi della pipeline.

• Verificare che il codice di trasformazione dei dati sia testabile.

• Creare una pipeline CI/CD.

• Monitorare l'infrastruttura, le pipeline e i dati.

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

1. Installazione iniziale: installare tutti i prerequisiti, importare il repository GitHub di Esempi di Azure nel proprio repository e impostare le variabili di ambiente necessarie.

2. 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.

3. Configurare l'integrazione git in Dev Data Factory: configurare l'integrazione git per l'uso con il repository GitHub importato.

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.

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 Risorse distribuite di DataOps - Parking Sensor Demo README.For a detailed list of all resources, see the Deployed Resources section of the DataOps - Parking Sensor Demo README.For a detailed list of all resources, see the Deployed Resources section of the DataOps - Parking Sensor Demo README.

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 di Visio di questa architettura.

1. 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>.

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 le compilazioni di unit test, linting e pacchetto applicazione livello dati ( DACPAC).

3. Al termine della convalida della richiesta pull, il commit in main attiverà una pipeline di compilazione che pubblica tutti gli artefatti di compilazione necessari.

4. 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_publish ramo .

5. 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.

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

7. 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 ) di README.

Testing

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 README.

Osservabilità e monitoraggio

La soluzione supporta l'osservabilità e il monitoraggio per Databricks e Data Factory. Per altre informazioni, vedere la sezione Observability/Monitoring di README.

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

• Visitare la pagina del progetto in GitHub

Observability/monitoring

Azure Databricks

• 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

Azure Storage

• Monitorare Archiviazione di Azure

Resilienza e ripristino di emergenza

Azure Databricks

• Ripristino di emergenza a livello di area per 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

Azure Storage

• 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