Ridimensionare l'analisi su scala cloud in Azure
Una piattaforma dati scalabile è fondamentale per soddisfare la rapida crescita dei dati. Grandi quantità di dati vengono generate ogni secondo in tutto il mondo. La quantità di dati disponibili dovrebbe continuare a crescere in modo esponenziale nei prossimi anni. Con l'aumentare della velocità di generazione dei dati, aumenta anche la velocità di spostamento dei dati.
Indipendentemente dalla quantità di dati disponibili, gli utenti richiedono risposte rapide alle query. Si aspettano minuti di attesa, non ore, per i risultati. Questo articolo illustra come ridimensionare la soluzione di analisi su scala cloud di Azure e continuare a soddisfare le esigenze degli utenti per la velocità.
Introduzione
Molte aziende hanno monoliti della piattaforma dati di grandi dimensioni. Questi monoliti sono costruiti attorno a un singolo account Azure Data Lake Gen2 e, a volte, a un singolo contenitore di archiviazione. Una singola sottoscrizione di Azure viene spesso usata per tutte le attività correlate alla piattaforma dati. Il ridimensionamento a livello di sottoscrizione è assente nella maggior parte delle piattaforme di architettura, che può ostacolare l'adozione continua di Azure se gli utenti riscontrano una delle limitazioni sottoscrizione di Azure o a livello di servizio. Anche se alcuni dei vincoli sono limiti flessibili, il raggiungimento di tali vincoli può comunque avere un effetto negativo significativo sulla piattaforma dati.
Quando strutturate la vostra piattaforma di dati, considerate la struttura della vostra organizzazione. Prendere nota della proprietà dei dati e delle responsabilità funzionali dei vostri team. Se l'organizzazione offre ai team grandi gradi di autonomia e proprietà distribuita, un'architettura mesh di dati è l'opzione migliore.
Evitare situazioni in cui team diversi sono responsabili di diversi compiti all'interno di una soluzione, ad esempio, acquisizione dei dati, pulizia, aggregazione e erogazione. Dipendere da più team può portare a una perdita drammatica di velocità. Ad esempio, se i consumer di dati nel livello di servizio devono integrare nuovi asset di dati o implementare modifiche funzionali per un determinato asset di dati, devono seguire un processo a più fasi. Per questo esempio, i passaggi sono:
- Il consumatore di dati invia un ticket a ogni team responsabile di una fase del flusso di dati.
- I team devono collaborare in modo sincronizzato perché i livelli sono interconnessi. I nuovi servizi richiedono modifiche al livello di pulizia dei dati, che comporta modifiche nel livello di aggregazione dei dati, che comporta modifiche al livello di gestione. Le modifiche possono influire su ogni fase della pipeline.
- È difficile per i team percepire i potenziali effetti dei cambiamenti nei processi, poiché non dispongono di una visione complessiva dell'intero ciclo di vita completo. Devono collaborare per progettare un piano di rilascio ben definito che riduce al minimo gli effetti sui consumer e sulle pipeline esistenti. Questa gestione delle dipendenze aumenta il sovraccarico di gestione.
- Di norma, i team non sono esperti della risorsa di dati richiesta dall'utilizzatore dei dati. Per comprendere le nuove funzionalità del set di dati o i valori dei parametri, è necessario consultare un esperto.
- Dopo l'implementazione di tutte le modifiche, il consumer di dati riceve una notifica che indica che il nuovo asset di dati è pronto per l'uso.
Ogni grande organizzazione ha migliaia di consumatori di dati. Un processo complesso, come quello descritto, riduce notevolmente la velocità nelle architetture di grandi dimensioni, poiché i team centralizzati diventano un collo di bottiglia per le business unit. Il risultato è meno innovazione ed efficacia limitata. Potenzialmente, le business unit possono decidere di lasciare il servizio e creare invece la propria piattaforma dati.
Metodi per la scalabilità
L'analisi su scala cloud risolve i problemi di ridimensionamento usando due concetti di base:
- Zone di destinazione dei dati per il ridimensionamento
- Prodotti dati o integrazioni di dati per il ridimensionamento, per rendere possibile la proprietà dei dati distribuita e decentralizzata
È possibile distribuire una singola zona di atterraggio dei dati o più zone. Le zone di destinazione dei dati consentono di individuare e gestire i dati connettendosi a una zona di destinazione di gestione dei dati. Ogni zona di destinazione per la gestione dei dati si trova all'interno di una singola sottoscrizione di Azure.
Le sottoscrizioni sono unità di gestione, fatturazione e scalabilità di Azure. Svolgono un ruolo fondamentale nel piano di adozione di Azure su larga scala.
Scalabilità con zone di atterraggio dei dati
I concetti centrali delle analisi su scala cloud sono Microsoft Purview, Azure Databricks Unity Catalog, se si utilizza Azure Databricks, una zona di atterraggio per la gestione dei dati e la zona di atterraggio dei dati. È consigliabile inserire ciascuno nella propria sottoscrizione di Azure. Separarli consente di separare chiaramente i compiti, seguire il principio dei privilegi minimi e risolvere parzialmente i problemi di scalabilità delle sottoscrizioni menzionati in precedenza. Una configurazione minima dell'analisi su scala cloud include una singola zona di destinazione dei dati e una singola zona di destinazione per la gestione dei dati.
Tuttavia, una configurazione minima non è sufficiente per le distribuzioni di piattaforme dati su larga scala. Le aziende creano piattaforme su larga scala e effettuano investimenti per ridimensionare in modo coerente ed efficiente i dati e le attività di analisi nel tempo. Per superare le limitazioni a livello di sottoscrizione, l'analisi su scala cloud utilizza le sottoscrizioni come unità di scalabilità, come discusso nelle zone di atterraggio di Azure. Questa tecnica consente di aumentare il footprint della piattaforma dati aggiungendo altre zone di destinazione dei dati all'architettura. L'adozione di questa tecnica risolve anche il problema dell'uso di azure Data Lake Gen2 per un'intera organizzazione perché ogni zona di destinazione dei dati include tre data lake. I progetti e le attività di più domini possono essere distribuiti in più sottoscrizioni di Azure, garantendo così una maggiore scalabilità.
Decidere il numero di zone di destinazione dei dati necessarie per l'organizzazione prima di implementare un'architettura di analisi su scala cloud. La scelta della soluzione giusta stabilisce le basi per una piattaforma dati efficace ed efficiente.
Il numero di zone di destinazione dei dati necessarie dipende da molti fattori, in particolare:
- Allineamento dell'organizzazione, ad esempio il numero di business unit che richiedono la propria zona di destinazione dei dati
- Considerazioni operative, ad esempio il modo in cui l'organizzazione allinea le risorse operative e le risorse specifiche di una business unit.
L'uso del modello di zona di destinazione dei dati corretto riduce al minimo le attività future per spostare i prodotti dati e gli asset di dati da una zona di destinazione a un'altra. Consente inoltre di ridimensionare in modo efficace e coerente i big data e le attività di analisi in futuro.
Quando si decide il numero di zone di destinazione dei dati da distribuire, prendere in considerazione i fattori seguenti.
| Fattore | Descrizione |
|---|---|
| Struttura organizzativa e proprietà dei dati | Valutare la struttura dell'organizzazione e il modo in cui i dati sono di proprietà dell'organizzazione. |
| Area geografica e località | Se si esegue la distribuzione in più aree, decidere quali aree devono ospitare le zone dati. Assicurarsi di rispettare tutti i requisiti di residenza dei dati. |
| Quote | Le quote di sottoscrizione non sono garanzie di capacità e vengono applicate per ogni area. |
| Sovranità dei dati | A causa delle normative sulla sovranità dei dati, i dati devono essere archiviati in un'area specifica e seguire i criteri specifici dell'area. |
| Criteri di Azure | Le zone di destinazione dei dati devono rispettare i requisiti dei vari criteri di Azure. |
| Limite di gestione | Le sottoscrizioni forniscono un limite di gestione per la governance e l'isolamento che separa chiaramente le preoccupazioni. |
| Rete | Ogni zona di destinazione ha una rete virtuale. Poiché una rete virtuale si trova in una singola area, ogni nuova area richiede una nuova zona di destinazione. Le reti virtuali devono essere reti virtuali peer per abilitare la comunicazione tra domini. |
| Limiti | Una sottoscrizione ha limiti. Con diverse sottoscrizioni, è possibile attenuare i pericoli di raggiungere questi limiti. |
| Allocazione dei costi | Valutare se i servizi condivisi, ad esempio gli account di archiviazione a pagamento, devono essere suddivisi in base a business unit o dominio. L'uso di una sottoscrizione separata crea un limite per l'allocazione dei costi. È possibile ottenere la stessa funzionalità usando i tag. |
| Classificazioni dei dati e dati estremamente riservati | I meccanismi di sicurezza possono influire sullo sviluppo dei prodotti dati e sull'usabilità di una piattaforma dati. Prendere in considerazione le classificazioni dei dati e decidere se i set di dati estremamente riservati richiedono un trattamento speciale, come l'accesso just-in-time, le chiavi gestite dal cliente (CMK), controlli di rete dettagliati o maggiore crittografia. |
| Altre implicazioni legali o di sicurezza | Valutare se esistono altri requisiti legali o di sicurezza che richiedono la separazione logica o fisica dei dati. |
Se si implementa un'architettura data mesh, considerare i seguenti fattori quando si decide come distribuire le zone di atterraggio dei dati e i domini di dati.
| Fattore | Descrizione |
|---|---|
| Domini di dati | Considerare i domini di dati utilizzati dall'organizzazione e decidere i domini dei dati per la piattaforma dati. Prendere in considerazione le dimensioni dei singoli domini dati. Per altre informazioni, vedere Che cosa sono i domini dati? |
| Latenza | I domini che collaborano su grandi quantità di dati possono trasferire una grande quantità di dati tra zone di destinazione. Valutare la possibilità di allocare i domini nella stessa zona o nella stessa area di destinazione. La separazione aumenta la latenza e può aumentare i costi nei domini tra aree. |
| Sicurezza | Alcune distribuzioni o configurazioni del servizio richiedono privilegi elevati in una sottoscrizione. Assegnando questi privilegi a un utente in un dominio in modo implicito, l'utente concede gli stessi privilegi in altri domini all'interno della stessa sottoscrizione. |
È possibile trovare ulteriori considerazioni nelle linee guida del framework di adozione del cloud per le sottoscrizioni .
Molte organizzazioni vogliono un ridimensionamento efficiente della piattaforma dati aziendale. Le business unit devono essere in grado di creare soluzioni e applicazioni dati personalizzate per soddisfare i requisiti specifici. Fornire questa capacità può essere una sfida perché molte piattaforme dati esistenti non sono basate sui concetti di scalabilità e proprietà decentralizzata. Questo problema è chiaramente visibile nell'architettura, nella struttura del team e nel modello operativo di queste piattaforme dati.
Le zone di destinazione dei dati non creano silo di dati all'interno dell'organizzazione. La configurazione di rete consigliata per l'analisi su scala cloud consente la condivisione dei dati sicura e sul posto tra le zone di destinazione, che a sua volta consente l'innovazione tra domini dati e business unit. Per altre informazioni, vedere considerazioni sull'architettura di rete .
Lo stesso vale per il livello di identità. Quando si usa un singolo tenant di Microsoft Entra, è possibile concedere alle identità l'accesso agli asset di dati in più zone di destinazione dei dati. Per altre informazioni sul processo di autorizzazione dell'utente e dell'identità, vedere Gestione degli accessi ai dati.
Nota
Se sono presenti più zone di destinazione dei dati, ogni zona può connettersi ai dati ospitati in altre zone. In questo modo i gruppi possono collaborare in tutta l'azienda.
L'analisi su scala cloud usa un'architettura comune per promuovere la governance coerente. L'architettura definisce funzionalità e criteri di base. Tutte le zone di atterraggio dei dati rispettano gli stessi audit e controlli. I tuoi team possono creare pipeline di dati, acquisire dati dalle origini e creare prodotti di dati come report e dashboard. Teams può anche eseguire analisi Spark/SQL in base alle esigenze. È possibile aumentare la capacità della zona di atterraggio dei dati aggiungendo servizi alla capacità nelle politiche. Ad esempio, un team può aggiungere un motore a grafo di terze parti per soddisfare un requisito aziendale.
L'analisi su scala cloud pone un forte accento sulla catalogazione centrale e sulla classificazione per proteggere i dati e consentire a vari gruppi di individuare i prodotti dati.
Attenzione
Sconsigliamo di eseguire query sui dati tra regioni. Assicurarsi invece che i dati siano vicini all'elaborazione che ne fa uso, rispettando al tempo stesso i confini regionali.
L'architettura di analisi su scala cloud e il concetto di zone di destinazione dei dati consentono all'organizzazione di aumentare facilmente le dimensioni della piattaforma dati nel tempo. È possibile aggiungere altre zone di destinazione dei dati in un approccio in più fasi. I clienti non hanno bisogno di avere più zone di destinazione inizialmente. Quando si adotta questa architettura, classificare in ordine di priorità alcune zone di destinazione dei dati e i prodotti dati che contengono. La definizione delle priorità appropriata consente di garantire il successo della distribuzione dell'analisi su scala cloud.
Ridimensionamento con applicazioni dati
All'interno di ogni zona di atterraggio, l'organizzazione può scalare utilizzando applicazioni di dati. Le applicazioni dati sono unità o componenti dell'architettura dei dati che incapsulano funzionalità che forniscono prodotti dati ottimizzati per la lettura per l'utilizzo da parte di altre applicazioni dati. In Azure le applicazioni dati sono ambienti sotto forma di gruppi di risorse che consentono ai team interfunzionali di implementare soluzioni dati e carichi di lavoro. Un team specializzato si occupa del ciclo di vita end-to-end della soluzione dei dati, che include l'ingestione, la pulizia, l'aggregazione e la distribuzione.
L'analisi su scala cloud risolve i problemi di integrazione e responsabilità dei dati illustrati in precedenza. Anziché le responsabilità funzionali monolitiche per l'inserimento di tabelle e l'integrazione del sistema di origine, la progettazione di riferimento fornisce un'architettura distribuita guidata dai domini dati. I team interfunzionali assumono la responsabilità funzionale end-to-end e la proprietà per l'ambito dei dati.
Invece di avere uno stack tecnico centralizzato e un team responsabile di tutte le attività del flusso di lavoro di elaborazione dei dati, è possibile distribuire la responsabilità end-to-end in più team di integrazione dei dati interfunzionali autonomi. Ogni team è proprietario di un dominio o sotto-dominio ed è incoraggiato a fornire i set di dati in base alle esigenze dei consumatori di dati.
Queste differenze architetturali portano a una maggiore velocità sulla piattaforma dati. I consumatori di dati non devono più affidarsi a un insieme di team centralizzati o lottare affinché le loro richieste di modifica vengano prioritizzate. Man mano che i team più piccoli assumono la responsabilità del processo di integrazione end-to-end, il ciclo di feedback tra fornitori di dati e utilizzatori di dati è più breve. Questo approccio comporta una definizione delle priorità più rapida, cicli di sviluppo più veloci e un processo di sviluppo più agile. I team non devono più sincronizzare i processi e i piani di rilascio tra loro perché il team di integrazione dei dati interfunzionali ha piena consapevolezza dello stack tecnico end-to-end e delle implicazioni delle modifiche. Può usare pratiche di ingegneria del software per eseguire unit test e test di integrazione per ridurre al minimo l'effetto complessivo sui consumatori.
Idealmente, il team proprietario dei sistemi di integrazione dei dati possiede anche i sistemi di origine. Questo team deve essere costituito da data engineer che lavorano sui sistemi di origine, esperti in materia (PMI) per i set di dati, ingegneri cloud e proprietari di prodotti dati. La creazione di questo tipo di team interfunzionale riduce la quantità di comunicazione necessaria con i team esterni ed è essenziale durante lo sviluppo dello stack completo dall'infrastruttura alle pipeline di dati effettive.
La base della piattaforma dati è costituita dai set di dati integrati dai sistemi di origine. Questi set di dati consentono ai team dei prodotti dati di innovare sulle tabelle dei fatti aziendali e di migliorare i processi decisionali e aziendali. I team di integrazione dei dati e i team dei prodotti dati devono offrire Accordi sul livello del servizio ai consumatori e assicurarsi che tutti gli accordi siano rispettati. Gli SLA offerti possono essere correlati alla qualità dei dati, alla tempestività, ai tassi di errore, alla disponibilità e ad altre attività.
Sommario
L'uso dei meccanismi di ridimensionamento dell'architettura di analisi su scala cloud consente all'organizzazione di espandere il proprio patrimonio di dati in Azure nel corso del tempo evitando limitazioni tecniche comuni. Entrambi i metodi di ridimensionamento descritti in questo articolo consentono di superare diverse complessità tecniche e possono essere usati in modo semplice ed efficiente.