Condividi tramite

Zone di destinazione dei dati

  • Articolo

Le zone di destinazione dei dati sono connesse alla zona di destinazione di gestione dei dati tramite peering di rete virtuale o endpoint privati. Ogni zona di destinazione dei dati viene considerata una zona di destinazione correlata all'architettura della zona di destinazione di Azure.

Importante

Prima di effettuare il provisioning di una zona di destinazione dei dati, verificare che il modello operativo DevOps e CI/CD sia installato e che venga distribuita una zona di destinazione per la gestione dei dati.

Ogni zona di destinazione dei dati ha diversi livelli che consentono l'agilità per le integrazioni dei dati del servizio e le applicazioni dati contenute. È possibile distribuire una nuova zona di destinazione dei dati con un set standard di servizi che consentono all'area di destinazione dei dati di iniziare l'inserimento e l'analisi dei dati.

Una tipica sottoscrizione di Azure associata a una zona di destinazione dei dati ha la struttura seguente:

Strato Obbligatorio Gruppi di risorse
livello dei servizi della piattaforma Sì
Servizi di base Sì
Applicazione dei dati Opzionale
Reportistica e visualizzazione dei dati Opzionale

Nota

Anche se il livello Servizi di base è contrassegnato come obbligatorio, non tutti i gruppi di risorse e i servizi inclusi in questo articolo potrebbero essere necessari per la zona di destinazione dei dati.

Architettura della zona di destinazione dei dati

L'architettura della zona di destinazione dei dati illustra i livelli, i relativi gruppi di risorse e i servizi contenuti in ogni gruppo di risorse. L'architettura offre una panoramica di tutti i gruppi e i ruoli associati alla zona di destinazione dei dati e l'estensione dell'accesso ai piani dati e di controllo. L'architettura illustra anche come ogni livello sia allineato alle responsabilità del modello operativo.

Diagramma dell'architettura della zona di destinazione dei dati.

Consiglio

Prima di distribuire una zona di destinazione dei dati, assicurarsi di considerare il numero di zone di destinazione dei dati iniziali da distribuire.

Servizi della piattaforma

Il livello dei servizi della piattaforma include i servizi necessari per abilitare la connettività e l'osservabilità alla zona di destinazione dei dati nel contesto dell'analisi su scala cloud. Nella tabella seguente sono elencati i gruppi di risorse consigliati.

Gruppo di risorse Obbligatorio Descrizione
network-rg Sì Reti
security-rg Sì Sicurezza e monitoraggio

Networking

Il gruppo di risorse di rete include i servizi di connettività, tra cui le reti virtuali di Azure, i gruppi di sicurezza di rete (NSG) e le tabelle di instradamento . Tutti questi servizi vengono distribuiti in un singolo gruppo di risorse.

La rete virtuale della zona di destinazione dei dati viene eseguito automaticamente il peering con la rete virtuale della zona di destinazione della gestione dei dati e la rete virtuale della sottoscrizione di connettività .

Sicurezza e monitoraggio

Il gruppo di risorse di sicurezza e monitoraggio include Azure Monitor e Microsoft Defender for Cloud per raccogliere i dati di telemetria del servizio, definire criteri e avvisi di monitoraggio e applicare criteri e analisi ai servizi.

Servizi di base

Il livello di servizi di base include i servizi fondamentali necessari per abilitare la zona di destinazione dei dati all'interno del contesto dell'analisi su scala cloud. La tabella seguente elenca i gruppi di risorse che forniscono la suite standard di servizi disponibili in ogni zona di destinazione dei dati distribuita.

Gruppo di risorse Obbligatorio Descrizione
storage-rg Sì Servizi Data Lake
runtimes-rg Sì Runtime di integrazione condivisa
mgmt-rg Sì Agenti CI/CD
external-data-rg Sì Archiviazione dati esterna
data-ingestion-rg Opzionale Servizi di inserimento dati condivisi
shared-applications-rg Opzionale Applicazioni condivise (Synapse o Databricks)

Immagazzinamento

Come illustrato nel diagramma, sono provvisti tre account Azure Data Lake Storage Gen2 in un singolo gruppo di risorse di servizi Data Lake. I dati trasformati in fasi diverse vengono salvati in uno dei data lake della zona di destinazione dei dati. I dati sono disponibili per l'utilizzo da parte dei team di analisi, data science e visualizzazione.

I livelli data lake usano terminologia diversa a seconda della tecnologia e del fornitore. Questa tabella fornisce indicazioni su come applicare le condizioni per l'analisi su scala cloud:

Analisi a scala cloud Delta Lake Altri termini Descrizione
Crudo Bronzo Atterraggio e conformità Tabelle di acquisizione
Arricchito Argento Zona di standardizzazione Tabelle perfezionate. Entità completa archiviata, recordset pronti per l'utilizzo dai sistemi di record.
Selezionato Oro Area prodotto Funzionalità o tabelle aggregate. Zona primaria per applicazioni, team e utenti per l'utilizzo di prodotti dati.
Sviluppo -- Area di sviluppo Luogo per ingegneri dei dati e scienziati dei dati, che comprende sia un'area di analisi sia una zona di sviluppo prodotti.

Nota

Nel diagramma precedente ogni zona di destinazione dei dati ha tre account di archiviazione data lake. Tuttavia, a seconda dei requisiti, è possibile scegliere di consolidare i livelli non elaborati, arricchiti e curati in un account di archiviazione e mantenere un altro account di archiviazione denominato "area di lavoro" per consentire agli utenti dei dati di inserire altri prodotti di dati utili.

Per altre informazioni, vedere:

Runtime di integrazione condivisa

Le pipeline di Azure Data Factory e Azure Synapse Analytics utilizzano i runtime di integrazione (IR) per accedere in maniera sicura alle origini dati in reti con peering o isolate. Gli IR condivisi devono essere distribuiti in una macchina virtuale (o nei set di scalabilità delle macchine virtuali di Azure) nel gruppo di risorse del runtime di integrazione condiviso.

Per abilitare il gruppo di risorse condivise:

Nota

La distribuzione descrive una singola distribuzione di macchine virtuali con un runtime di integrazione self-hosted. È possibile associare un runtime di integrazione self-hosted a più macchine virtuali locali o in Azure. Questi computer sono denominati nodi ed è possibile avere fino a quattro nodi associati a un runtime di integrazione self-hosted. I vantaggi della presenza di più nodi sono i seguenti:

  • Aumentata disponibilità del runtime di integrazione self-hosted in modo che non sia più il punto singolo di errore nell'applicazione dati o nell'orchestrazione dell'integrazione dei dati cloud.
  • Miglioramento delle prestazioni e della velocità effettiva durante lo spostamento dei dati tra i servizi dati locali e cloud. Ottieni ulteriori informazioni sui confronti delle prestazioni .

È possibile associare più nodi installando il software di runtime di integrazione autogestito dal Download Center. Registrarlo usando una delle chiavi di autenticazione ottenute dal cmdlet New-AzDataFactoryV2IntegrationRuntimeKey, come descritto nell'esercitazione .

Altre informazioni sono dettagliate in disponibilità elevata e scalabilità di Azure Data Factory.

Importante

Distribuire i runtime di integrazione condivisa il più vicino possibile all'origine dati. È possibile distribuire i runtime di integrazione in una zona di destinazione dei dati, in cloud di terze parti o in un cloud privato, purché la macchina virtuale disponga della connettività alle origini dati necessarie.

Gestione

Gli agenti CI/CD vengono eseguiti in macchine virtuali e consentono di distribuire elementi dal repository del codice sorgente, incluse le applicazioni dati e le modifiche apportate alla zona di destinazione dei dati.

Per altre informazioni, vedere agenti di Azure Pipeline.

Archiviazione esterna

Gli editori di dati dei partner devono trasferire i dati nella piattaforma in modo che i team delle applicazioni di dati possano prelevarli nei data lake. È anche possibile avere origini dati interne o esterne che non possono supportare i requisiti di connettività o autenticazione applicati tra il resto delle zone di destinazione dei dati. L'uso di un account di archiviazione separato è l'approccio consigliato per ricevere i dati, quindi un runtime di integrazione condiviso o un processo di inserimento simile per inserirli nella pipeline di elaborazione. Come illustrato nel diagramma seguente, il gruppo di risorse di inserimento di caricamento consente di effettuare il provisioning degli archivi BLOB per questi casi d'uso.

I team delle applicazioni di dati richiedono i blob di archiviazione. Queste richieste vengono approvate dal team operativo della zona di destinazione dei dati. I dati devono essere eliminati dal blob di archiviazione di origine dopo essere stati inseriti nell'archiviazione dei dati grezzi.

Importante

Poiché viene effettuato il provisioning dei BLOB di Archiviazione di Azure in base alle esigenze , è consigliabile distribuire inizialmente un gruppo di risorse dei servizi di archiviazione vuoto in ogni zona di destinazione dei dati.

Inserimento dati

Questo gruppo di risorse è facoltativo e non impedisce la distribuzione della zona di atterraggio. È applicabile se si ha o si sta sviluppando un motore di inserimento indipendente dai dati che inserisce automaticamente i dati in base ai metadati registrati, incluse stringhe di connessione, percorsi per il trasferimento dei dati e pianificazioni di inserimento.

Il gruppo di risorse di inserimento ed elaborazione dispone di servizi chiave per questo tipo di framework.

Distribuire un'istanza di Azure SQL Database per contenere i metadati usati da Azure Data Factory. Provisionare un Azure Key Vault per archiviare i segreti relativi ai servizi di raccolta automatizzata. Questi segreti possono includere:

  • Credenziali del metastore di Azure Data Factory
  • Credenziali del principale del servizio per il processo di acquisizione automatizzata

Per altre informazioni, vedere Come i framework di inserimento automatizzato supportano l'analisi su scala cloud in Azure.

I servizi inclusi in questo gruppo di risorse includono:

Servizio Obbligatorio Istruzioni
Azure Data Factory Sì Azure Data Factory è il motore di orchestrazione per l'inserimento agnostico rispetto ai dati.
Database SQL di Azure Sì Il database SQL di Azure è il metastore per Azure Data Factory.
Hub eventi o hub IoT Opzionale Gli Hub eventi o gli hub IoT possono fornire flussi di dati in tempo reale agli Hub eventi, oltre a consentire l'elaborazione batch e streaming tramite una workspace di ingegneria Databricks.
Azure Databricks Opzionale È possibile distribuire Azure Databricks o Azure Synapse Spark per utilizzare il motore di inserimento indipendente dai dati.
Azure Synapse Opzionale È possibile distribuire Azure Databricks o Azure Synapse Spark per l'utilizzo con il motore di inserimento indipendente dai dati.

Applicazioni condivise

Questo gruppo di risorse facoltativo viene usato quando è necessario disporre di un set di servizi condivisi resi disponibili a tutti i team che creano applicazioni dati in questa zona di destinazione dei dati. Gli usi di esempio includono:

  • Un'area di lavoro di Azure Databricks usata come metastore condiviso per tutte le altre aree di lavoro di Databricks create nella stessa zona di destinazione dei dati (o area)
  • Un'istanza condivisa di Azure Synapse Analytics usando pool SQL serverless per consentire agli utenti di eseguire query tra account di archiviazione isolati.

Nota

Azure Databricks usa Unity Catalog per gestire l'accesso e la visibilità dei metastore tra i Workspace di Databricks. Il catalogo Unity è abilitato a livello di tenant, ma i metastore sono allineati alle aree di Azure. In pratica, ciò significa che tutte le aree di lavoro di Databricks abilitate per Unity Catalog in una determinata area di Azure dovranno essere registrate allo stesso metastore. Per maggiori informazioni, vedere Best Practices di Unity Catalog.

Seguire le procedure consigliate per l'analisi su scala cloud per integrare Azure Databricks:

Applicazione di dati

Ogni zona di destinazione dei dati può avere più applicazioni di dati. È possibile creare queste applicazioni inserendo dati da varie origini. È anche possibile creare applicazioni dati da altre applicazioni dati all'interno della stessa zona di destinazione dei dati o da altre zone di destinazione dei dati. La creazione delle applicazioni dati è soggetta all'approvazione dell'amministratore dei dati.

Gruppo di risorse per applicazioni dati

Il gruppo di risorse per l'applicazione dati include tutti i servizi necessari per costruire tale applicazione dati. Ad esempio, per MySQL è necessario un database di Azure, usato da uno strumento di visualizzazione. I dati devono essere inseriti e trasformati prima che vengano inseriti nel database MySQL. In questo caso, è possibile distribuire Azure Database per MySQL e Azure Data Factory nel gruppo di risorse per applicazioni dati.

Suggerimento

Se si sceglie di non implementare un motore agnostico rispetto ai dati per eseguire l'inserimento una sola volta dalle fonti operative, o se le connessioni complesse non sono facilitate nel motore agnostico rispetto ai dati, si dovrebbe creare un'applicazione dati allineata alla fonte. Per altre informazioni, vedere Applicazioni dati (allineate con la fonte).

Per ulteriori informazioni su come integrare i prodotti di dati, vedere applicazioni di analisi dei dati su scala cloud in Azure.

Creazione di report e visualizzazione

È possibile usare gli strumenti di visualizzazione e creazione di report all'interno delle aree di lavoro di Fabric, che hanno molte analogie con le aree di lavoro di Power BI, senza dover distribuire risorse univoche all'interno della zona di atterraggio dei dati. È possibile includere un gruppo di risorse per fornire capacità Fabric, macchine virtuali per i gateway dati o altri servizi dati necessari per erogare la vostra applicazione dati all'utente finale.

Passaggi successivi