Uno scenario di un'istituzione finanziaria per il Data Mesh
Questo scenario è destinato ai clienti che vogliono usare l'analisi su scala cloud per la scalabilità e architetture di mesh di dati. Illustra uno scenario complesso con zone di destinazione, integrazioni di dati e prodotti dati.
Profilo cliente
Un'impresa fittizia, Woodgrove Bank, è una grande società di servizi finanziari con un footprint mondiale. I dati di Woodgrove Bank sono ospitati in sistemi di distribuzione locali e cloud. All'interno dell'architettura di Woodgrove Bank sono disponibili diversi sistemi di data warehouse per il marketing consolidato e la creazione di report integrati. Questa architettura include diversi data lake per l'analisi non pianificata e l'individuazione dei dati. Le applicazioni Woodgrove Bank sono interconnesse tramite modelli di integrazione delle applicazioni, che sono principalmente basati su API o basati su eventi.
La situazione attuale
È difficile per Woodgrove Bank distribuire i dati in posizioni diverse a causa della complessità del data warehousing. L'integrazione di nuovi dati richiede molto tempo ed è facile cedere alla tentazione di duplicare i dati. Woodgrove Bank trova difficile gestire l'ambiente dati end-to-end a causa della connettività da punto a punto. La banca ha sottovalutato la domanda di utilizzo intensivo dei dati. I nuovi casi d'uso vengono introdotti rapidamente, uno dopo l'altro. La governance dei dati, ad esempio la proprietà e la qualità dei dati, e i costi sono difficili da controllare. Mantenere aggiornati i regolamenti è difficile perché Woodgrove Bank non sa esattamente dove risiedono i dati.
Soluzione di architettura: Data Mesh
Negli ultimi anni, le organizzazioni riconoscono che i dati sono al centro di tutto. I dati apre nuove efficienze, guida l'innovazione, sblocca nuovi modelli di business e aumenta la soddisfazione dei clienti. È una priorità assoluta per le aziende usare metodi basati sui dati, ad esempio i dati su larga scala.
Raggiungere una fase in cui il valore più profondo dei dati è accessibile a tutti i membri dell'organizzazione è difficile. I sistemi legacy e strettamente interconnessi, le piattaforme monolitiche centralizzate e la governance complessa possono essere ostacoli significativi alla generazione di valore dai dati.
Informazioni su Data Mesh
Il concetto di data mesh, un termine coniato da Zhamak Dehghani, comprende dati, tecnologia, processi e organizzazione. Concettualmente, si tratta di un approccio accessibile alla gestione dei dati in cui i vari domini usano i propri dati. Il data mesh sfida l'idea della centralizzazione convenzionale dei dati. Anziché esaminare i dati come un enorme archivio, il data mesh considera la scomposizione di prodotti dati indipendenti. Questo passaggio, dalla proprietà centralizzata alla proprietà federata, è supportato da una moderna piattaforma dati self-service in genere progettata usando tecnologie native del cloud.
Quando si suddivide il concetto di data mesh in blocchi costitutivi, ecco alcuni punti chiave da considerare:
- Data as a Product: Ogni dominio organizzativo gestisce i propri dati in modo completo. La responsabilità risiede nel proprietario dei dati all'interno del dominio. Le pipeline diventano un problema di prima classe dei domini stessi.
- Federated Computed Data Governance: per assicurarsi che ogni proprietario dei dati possa considerare attendibili gli altri e condividere i propri prodotti dati, è necessario stabilire un organismo di governance dei dati aziendale. Il corpo di governance implementa la qualità dei dati, la visibilità centrale della proprietà dei dati, la gestione degli accessi ai dati e le politiche sulla privacy dei dati.
- Domain-Oriented Proprietà dei dati: idealmente, l'organizzazione dovrebbe definire e modellare ogni nodo di dominio-dati nella mesh applicando i principi della progettazione orientata al dominio.
- Self-Serve Data Platform: una mesh di dati richiede una piattaforma dati self-service che consente agli utenti di rimuovere la complessità tecnica e concentrarsi sui singoli casi d'uso dei dati.
Cloud-Scale Analytics
Il pensiero dei dati come prodotto e un modello di piattaforma self-service non sono una novità di Microsoft. Microsoft ha osservato le procedure consigliate per piattaforme distribuite, pipeline tra domini, proprietà federata e dati autoesplicativi per molti anni.
Woodgrove Bank può effettuare la transizione verso un'architettura mesh dati utilizzando l'analisi su larga scala nel cloud. L'analisi su scala cloud è un progetto open source e prescrittivo per la progettazione e la distribuzione rapida di piattaforme dati moderne. È associato alle procedure consigliate e ai principi di progettazione di Azure ed è allineato all'Azure Well-Architected Framework. L'analisi su scala cloud offre alle aziende un punto di vista previsto dell'80% e il 20% rimanente è personalizzabile.
L'analisi su scala cloud offre alle aziende un percorso di progettazione strategico verso la mesh di dati e può essere usato per configurare rapidamente tale architettura. Offre uno schema, inclusi i servizi principali della piattaforma dati per la gestione dei dati.
Al livello più alto, l'analisi su scala cloud usa una funzionalità di gestione dei dati, abilitata tramite la zona di destinazione di gestione dei dati. Questa zona è responsabile della governance dei dati federata di un'organizzazione di una piattaforma (self-service) e dei domini dati che guidano il valore aziendale attraverso i prodotti dati. Il vantaggio di questo approccio è che rimuove la complessità tecnica rispettando gli stessi standard. Garantisce che non vi sia alcuna proliferazione di tecnologie. Consente anche alle aziende di iniziare in modo modulare, con un ingombro ridotto, e quindi crescere nel tempo.
La zona di destinazione di gestione dei dati, come si può vedere nel diagramma seguente, racchiude tutti i domini dati. Associa tutti i domini insieme e fornisce la supervisione che Woodgrove Bank sta cercando.
L'analisi su scala cloud sostiene anche l'applicazione di governance coerente che usa un'architettura comune quando i prodotti dati vengono distribuiti. Il framework consente la comunicazione diretta tra domini. Mantiene il controllo ponendo l'accento sulla catalogazione centrale e sulla classificazione per proteggere i dati e consentire ai gruppi di individuare i dati. Posiziona un ombrello sulla proprietà dei dati.
Domini dei dati
Quando si usa l'analisi su scala cloud come percorso strategico, è necessario considerare la scomposizione dell'architettura e la granularità risultante. La mesh dei dati scompone i dati senza seguire i confini delle tecnologie. Applica invece i principi della progettazione basata su dominio (DDD), un approccio allo sviluppo di software che coinvolge sistemi complessi per organizzazioni di grandi dimensioni. DDD è popolare a causa del suo effetto sulle moderne procedure di sviluppo di software e applicazioni, ad esempio microservizi.
Uno dei modelli della progettazione basata su dominio è noto come contesto delimitato. I contesti delimitati impostano i limiti logici dello spazio della soluzione di un dominio per gestire meglio la complessità. È importante che i team comprendano quali aspetti, inclusi i dati, possono cambiare e quali sono dipendenze condivise che richiedono il coordinamento con altri utenti. L'architettura a griglia di dati integra il contesto delimitato. Usa questo modello per descrivere come le organizzazioni possono coordinare i domini dati e concentrarsi sulla distribuzione di dati come prodotto. Ogni dominio dati è proprietario e gestisce più prodotti dati con il proprio stack di tecnologie, indipendentemente dagli altri.
Prodotti dati
Quando si esegue lo zoom avanti sull'architettura interna di un dominio dati di questo tipo, si prevede di trovare i prodotti dati al suo interno.
I prodotti dati soddisfano un'esigenza specifica all'interno delle aziende che usano i dati. I prodotti dati gestiscono, organizzano e interpretano i dati attraverso domini e successivamente presentano le intuizioni acquisite. Un prodotto dati deriva dai dati provenienti da una o più integrazioni di dati o da altri prodotti dati. I prodotti dati sono strettamente allineati ai domini dati e ereditano lo stesso linguaggio costruito e formalizzato concordato dagli stakeholder e dai progettisti. Ogni dominio che genera dati è responsabile della disponibilità di questi prodotti dati agli altri domini.
Per offrire rapidamente prodotti dati, l'analisi su scala cloud offre modelli per la distribuzione dei dati e i modelli di integrazione. Il framework fornisce elaborazione batch dei dati, streaming e analisi per soddisfare le esigenze di consumatori diversi.
Un aspetto importante dell'analisi su scala cloud è il modo in cui i domini e i prodotti dati sono organizzati. Ogni dominio dati è allineato a una zona di destinazione dei dati, ovvero un costrutto logico e un'unità di scalabilità nell'architettura di analisi su scala cloud. Consente la conservazione dei dati e l'esecuzione di carichi di lavoro sui dati, che generano informazioni e valore. Ogni prodotto dati è allineato con un gruppo di risorse all'interno della zona di destinazione dei dati e tutte le zone di destinazione dei dati e le zone di gestione sono allineate alle sottoscrizioni. Questo approccio semplifica l'implementazione e la gestione.
Tutti i modelli di analisi su scala cloud ereditano lo stesso set di criteri dalla zona di destinazione di gestione dei dati. I modelli forniscono automaticamente i metadati necessari per l'individuazione dei dati, la governance, la sicurezza, la gestione dei costi e l'eccellenza operativa. È possibile eseguire rapidamente l'onboarding di nuovi domini dati senza la necessità di onboarding, integrazione e test complessi.
Il diagramma seguente illustra l'aspetto di un prodotto di dati:
Un approccio pragmatico alla creazione di prodotti dati consiste nell'allinearsi all'origine, alla provenienza dei dati o al caso d'uso utilizzato. In entrambi i casi, è necessario fornire una visualizzazione astratta del modello di dati dell'applicazione sottostante (complesso). È necessario provare a nascondere i dettagli tecnici e ottimizzare l'utilizzo intensivo dei dati. Una vista di Azure Synapse o un file Parquet, che raggruppa logicamente i dati, è un esempio di come un prodotto di dati può essere condiviso tra vari domini di dati.
Successivamente, è necessario lavorare sull'individuabilità, la provenienza, l'utilizzo e la derivazione dei dati. Un approccio collaudato consiste nell'usare un servizio di governance dei dati, ad esempio Microsoft Purview, per registrare tutti i dati. L'integrazione dei dati nell'analisi su scala cloud connette perfettamente i punti perché consente di creare questi prodotti dati man mano che esegue simultaneamente la registrazione dei metadati.
Allineando i domini dati e le raccolte di Microsoft Purview, si acquisisce automaticamente tutte le informazioni sull'origine dati, sulla derivazione, sulla qualità dei dati e sulle informazioni sull'utilizzo dai singoli domini. Con questo approccio, è possibile connettere più domini dati e prodotti a una soluzione di governance centralizzata, che archivia tutti i metadati di ogni ambiente. Il vantaggio è che integra centralmente tutti i metadati e lo rende facilmente accessibile ai vari consumer. È possibile estendere questa architettura per registrare nuovi prodotti dati.
Il diagramma seguente illustra un'architettura mesh di dati tra domini che usa l'analisi su scala cloud.
La progettazione di rete consente di condividere i prodotti dati tra domini usando costi minimi ed eliminando un singolo punto di guasto e limitazioni della larghezza di banda. Per garantire la sicurezza, è possibile usare il modello di sicurezza Microsoft Zero Trust. L'analisi su scala cloud propone l'uso dell'isolamento della rete tramite endpoint privati e comunicazioni di rete privata, un modello di accesso ai dati basato sulle identità che usa MI, UMI e gruppi di sicurezza annidati, seguendo il principio dei privilegi minimi.
È possibile usare le identità gestite per assicurarsi che venga seguito un modello di accesso con privilegi minimi. Le applicazioni e i servizi in questo modello hanno accesso limitato ai prodotti dati. I criteri di Azure, insieme alle prossime politiche sui dati, vengono utilizzati per consentire la modalità self-service e garantire la conformità delle risorse all'interno di tutti i prodotti di dati su larga scala. Con questo design, è possibile avere un accesso uniforme ai dati mantenendo il controllo completo tramite la governance centralizzata dei dati e l'auditing.
Evolvere verso il futuro
L'analisi su scala cloud è progettata tenendo presente la mesh dei dati. L'analisi su scala cloud offre un approccio collaudato da cui le organizzazioni possono condividere i dati in molti domini dati. Questo framework consente ai domini di avere l'autonomia di effettuare scelte e di gestire l'architettura tramite l'isolamento con i servizi di gestione dei dati.
Quando implementi la rete di dati, raggruppa e organizza logicamente i tuoi domini. Questo approccio richiede una visione aziendale ed è probabilmente un cambiamento culturale per l'organizzazione. Il passaggio richiede di federare la proprietà dei dati tra domini di dati e i proprietari che sono responsabili di fornire i loro dati come prodotti. Richiede anche che i team siano conformi alle funzionalità centralizzate offerte dalla zona di destinazione di gestione dei dati. Questo nuovo approccio potrebbe richiedere ai singoli team di rinunciare ai propri mandati correnti, che probabilmente generano resistenza. Potrebbe essere necessario fare determinate scelte politiche e trovare un equilibrio tra approcci centralizzati e decentralizzati.
È possibile ampliare un'architettura mesh di dati aggiungendo altre zone di destinazione per i singoli domini. Queste zone di destinazione usano il peering di rete virtuale per connettersi alla zona di destinazione di gestione dei dati e a tutte le altre zone di destinazione. Questo modello consente di condividere i prodotti dati e le risorse tra le zone. Quando si divide in zone separate, è possibile distribuire i carichi di lavoro tra sottoscrizioni e risorse di Azure. Questo approccio consente di implementare il data mesh in modo organico.
Ulteriori informazioni
Risorse Microsoft:
Articolo del fondatore di Data Mesh Zhamak Dehghani: