Abilitazione dello sviluppo rapido dei dati da grandi sistemi operativi
Per un ingegnere dei dati che costruisce analisi da sistemi transazionali come ERP (pianificazione delle risorse aziendali) e CRM (gestione delle relazioni con i clienti), la sfida principale risiede nel colmare il divario tra dati operativi grezzi e conoscenza del dominio. I sistemi ERP e CRM sono progettati e realizzati per soddisfare un’ampia gamma di processi e funzioni aziendali. Questa generalizzazione rende i loro modelli di dati complessi e criptici e richiedono competenze nel settore.
Ancora più difficile da gestire, una configurazione comune all’interno delle grandi organizzazioni prevede la presenza di diverse istanze di questi sistemi con alcuni processi sottostanti incaricati di trasmettere dati tra di loro, il che potrebbe portare a duplicazioni, incoerenze e opacità.
La disconnessione tra i team operativi impegnati nelle funzioni quotidiane e quelli che estraggono valore aziendale dai dati generati nei processi operativi rimane ancora un punto di attrito significativo.
Immagina di essere un ingegnere/analista dei dati incaricato di identificare i prodotti più venduti all’interno della tua azienda. Il tuo primo passo potrebbe essere quello di individuare gli ordini. Quindi inizi a ricercare gli oggetti del database e trovi un paio di visualizzazioni, ma ci sono alcune incoerenze tra loro, quindi non sai quale utilizzare. Inoltre, è davvero difficile identificare i proprietari, uno di loro ha addirittura recentemente lasciato l’azienda. Poiché non vuoi iniziare il tuo sviluppo con incertezza, decidi di utilizzare direttamente i dati grezzi operativi. Ti suona familiare?
Mi connettevo alle visualizzazioni nei database transazionali o alle API offerte dai sistemi operativi per richiedere i dati grezzi.
Per evitare che le mie estrazioni influenzino le prestazioni dal punto di vista operativo, ho interrogato regolarmente questi dati e li ho archiviati in un’area di staging persistente (PSA) all’interno del mio data warehouse. Ciò mi ha consentito di eseguire query complesse e pipeline di dati utilizzando queste istantanee senza consumare alcuna risorsa dai sistemi operativi, ma potrebbe comportare un’inutile duplicazione dei dati nel caso in cui non fossi a conoscenza di altri team che eseguivano la stessa estrazione.
Una volta disponibili i dati operativi grezzi, dovevo affrontare la sfida successiva: decifrare tutti gli oggetti e le proprietà criptiche e affrontare il labirinto di dozzine di relazioni tra loro (ovvero i dati materiali generali in SAP documentati https://leanx.eu/it/sap/table/mara.html)
Anche se gli oggetti standard all’interno dei sistemi ERP o CRM sono ben documentati, Dovevo occuparmi di numerosi oggetti e proprietà personalizzati che richiedevano competenze nel settore poiché questi oggetti non possono essere trovati nei modelli di dati standard. La maggior parte delle volte mi sono ritrovato a lanciare query di “prova ed errore” nel tentativo di allineare le chiavi tra oggetti operativi, interpretando il significato delle proprietà in base ai loro valori e verificando con gli screenshot dell’interfaccia utente operativa le mie ipotesi.
Un’implementazione di Data Mesh ha migliorato la mia esperienza in questi aspetti:
- Conoscenza: Ho potuto identificare rapidamente i proprietari dei dati esposti. La distanza tra il proprietario e il dominio che ha generato i dati è fondamentale per accelerare l’ulteriore sviluppo analitico.
- Rilevabilità: Una piattaforma dati condivisa fornisce un catalogo di set di dati operativi sotto forma di prodotti di dati allineati alla fonte che mi hanno aiutato a comprendere lo stato e la natura dei dati esposti.
- Accessibilità: Potrei facilmente richiedere l’accesso a questi prodotti dati. Poiché questi dati sono archiviati nella piattaforma dati condivisa e non nei sistemi operativi, non ho avuto bisogno di allinearmi con i team operativi per le finestre disponibili per eseguire la mia estrazione dei dati senza influire sulle prestazioni operative.
Secondo la tassonomia Data Mesh, i prodotti dati basati su fonti operative sono denominati prodotti dati allineati alla fonte:
I set di dati del dominio di origine rappresentano fedelmente i dati grezzi al momento della creazione e non sono adattati o modellati per un particolare consumatore — Zhamak Dehghani
I prodotti di dati allineati alla fonte mirano a rappresentare le fonti operative all’interno di una piattaforma dati condivisa in una relazione uno a uno con le entità operative e non dovrebbero contenere alcuna logica aziendale che potrebbe alterare le loro proprietà.
Proprietà
In un’implementazione Data Mesh, questi prodotti di dati dovrebbero
rigorosamente essere di proprietà del dominio aziendale che genera i dati grezzi. Il proprietario è responsabile della qualità, dell’affidabilità e dell’accessibilità dei propri dati e i dati vengono trattati come un prodotto che può essere utilizzato dallo stesso team e da altri team dati in altre parti dell’organizzazione.
Questa proprietà garantisce che la conoscenza del dominio sia vicina ai dati esposti. Ciò è fondamentale per consentire il rapido sviluppo di prodotti di dati analitici, poiché qualsiasi chiarimento necessario ad altri team di dati può essere gestito in modo rapido ed efficace.
Implementazione
Seguendo questo approccio, il dominio Vendite è responsabile della pubblicazione di un prodotto dati “sales_orders” e di renderlo disponibile in un catalogo dati condiviso.
La pipeline di dati responsabile della manutenzione del prodotto dati potrebbe essere definita in questo modo:
Estrazione dati
Il primo passo per creare prodotti di dati allineati alla fonte è estrarre i dati che vogliamo esporre da fonti operative. Esistono numerosi strumenti di integrazione dei dati che offrono un’interfaccia utente per semplificare l’acquisizione. I team dati possono creare lì un lavoro per estrarre dati grezzi da fonti operative utilizzando connessioni o API JDBC. Per evitare sprechi di lavoro computazionale e, quando possibile, solo i dati grezzi aggiornati dall’ultima estrazione dovrebbero essere aggiunti in modo incrementale al prodotto dati.
Pulizia dei dati
Ora che abbiamo ottenuto i dati desiderati, il passo successivo prevede una certa cura, in modo che i consumatori non debbano occuparsi delle incoerenze esistenti nelle fonti reali. Sebbene non debba essere implementata alcuna logica aziendale durante la creazione di prodotti di dati allineati alla fonte, sono consentite la pulizia e la standardizzazione di base.
-- Example of property standardisation in a sql query used to extract data
case
when lower(SalesDocumentCategory) = 'invoice' then 'Invoice'
when lower(SalesDocumentCategory) = 'invoicing' then 'Invoice'
else SalesDocumentCategory
end as SALES_DOCUMENT_CATEGORY
Aggiornamento dati
Una volta che i dati operativi estratti sono stati preparati per il consumo, il set di dati interno del prodotto dati viene aggiornato in modo incrementale con lo snapshot più recente.
Uno dei requisiti per un prodotto dati è essere interoperabile. Ciò significa che dobbiamo esporre identificatori globali in modo che il nostro prodotto dati possa essere utilizzato universalmente in altri domini.
Aggiornamento dei metadati
I prodotti dati devono esserlo comprensibile. I produttori devono incorporare metadati significativi per le entità e le proprietà contenute. Questi metadati dovrebbero coprire questi aspetti per ciascuna proprietà:
- Descrizione dell’attività: cosa rappresenta ciascuna proprietà per l’azienda. Per esempio, “Categoria aziendale per l’ordine cliente”.
- Sistema di origine: stabilire una mappatura con la proprietà originale nel dominio operativo. Ad esempio, “Fonte originale: ERP | Tavolo MARA-MTART proprietà BIC/MARACAT”.
- Caratteristiche dei dati: caratteristiche specifiche dei dati, come enumerazioni e opzioni. Per esempio, “È un’enumerazione con queste opzioni: Fattura, Pagamento, Reclamo”.
Anche i prodotti dati devono esserlo scopribile. I produttori devono pubblicarli in un catalogo di dati condiviso e indicare come i dati devono essere consumati definendo le risorse delle porte di output che fungono da interfacce a cui sono esposti i dati.
E i prodotti dati devono esserlo osservabile. I produttori devono distribuire una serie di monitor che possono essere visualizzati nel catalogo. Quando un potenziale consumatore scopre un prodotto dati nel catalogo, può comprendere rapidamente lo stato dei dati contenuti.
Ora, ancora una volta, immagina di essere un ingegnere dei dati incaricato di identificare i prodotti più venduti all’interno della tua azienda. Ma questa volta, immagina di avere accesso a un catalogo di dati che offre prodotti di dati che rappresentano la verità di ciascun dominio che plasma il business. Basta inserire “ordini” nel catalogo dei prodotti dati e trovare la voce pubblicata dal team dei dati sulle vendite. E, a colpo d’occhio, puoi valutare la qualità e l’aggiornamento dei dati e leggere una descrizione dettagliata dei suoi contenuti.
Questa esperienza aggiornata elimina le incertezze del rilevamento tradizionale, consentendoti di iniziare subito a lavorare con i dati. Ma soprattutto, sai chi è responsabile dei dati nel caso in cui siano necessarie ulteriori informazioni. E ogni volta che si verifica un problema con il prodotto Dati sugli ordini di vendita, riceverai una notifica in modo da poter intraprendere azioni in anticipo.
Abbiamo identificato diversi vantaggi derivanti dall’abilitazione dei dati operativi attraverso prodotti di dati allineati alla fonte, soprattutto quando sono di proprietà dei produttori di dati:
- Accessibilità curata dei dati operativi: Nelle grandi organizzazioni, i prodotti dati allineati alla fonte rappresentano un ponte tra il piano operativo e quello analitico.
- Riduzione delle collisioni con il lavoro operativo: gli accessi ai sistemi operativi sono isolati all’interno di pipeline di prodotti dati allineati alla fonte.
- Fonte della verità: un catalogo di dati comune con un elenco di oggetti aziendali operativi curati che riducono le duplicazioni e le incoerenze all’interno dell’organizzazione.
- Cancella la proprietà dei dati: I prodotti dati allineati alla fonte dovrebbero esserlo di proprietà del dominio che genera i dati operativi per garantire la conoscenza del dominio è vicino ai dati esposti.
In base alla mia esperienza, questo approccio funziona eccezionalmente bene in scenari in cui le grandi organizzazioni lottano con incoerenze di dati tra diversi domini e attriti quando costruiscono le proprie analisi sui dati operativi. Data Mesh incoraggia ciascun dominio a costruire la “fonte della verità” per le entità principali che genera e renderli disponibili in un catalogo condiviso consentendo ad altri team di accedervi e creare metriche coerenti in tutta l’organizzazione. Ciò consente ai team che si occupano di dati analitici di accelerare il proprio lavoro nella generazione di analisi che generano un reale valore aziendale.
https://www.oreilly.com/library/view/data-mesh/9781492092384/
Grazie ai miei colleghi di Thoughtworks Arne (due volte!), Pablo, Ayush e Samvardhan per aver dedicato del tempo a rivedere le prime versioni di questo articolo
Fonte: towardsdatascience.com
