5 Segnali Che La Tua Dati Siano Modellati Male

5 signs your data is poorly modeled.

Le sfide comuni nell’era del Cloud

Con l’espansione della tecnologia del cloud e i costi di archiviazione a buon mercato nel decennio passato, molte organizzazioni hanno accumulato volumi di dati significativamente più grandi di quanto fosse immaginabile in precedenza. Il modello pay-as-you go offerto da molti fornitori di data warehouse cloud (AWS, GCP, Azure) ha ridotto la necessità di risorse di capitale iniziale e di considerazione dell’infrastruttura digitale.

La buona notizia è che questo rende gli sforzi di data science accessibili alla maggior parte delle organizzazioni.

La cattiva notizia è che i Data Lake stanno diventando più simili a delle paludi di dati.

Cos’è il Data Modeling? E quali sono le sfide che lo circondano?

Spesso è difficile per gli ingegneri dei dati comunicare il valore di un ecosistema ben modellato alla dirigenza. Questo perché tutto ciò che è visibile agli stakeholder sono gli strumenti BI e i modelli predittivi che vengono presentati. Tuttavia, i dati mal modellati causano gravi ritardi alle squadre di analisi dal punto di vista della governance dei dati. Ciò rallenta inevitabilmente il flusso di lavoro, introduce attività ripetitive, diminuisce l’accuratezza della reportistica, oltre ad altri effetti negativi.

• La guida essenziale dell’analisi esplorativa dei dati per un Data Scientist
• Serie AI Frontiers Risorse Umane
• Grafici a ragnatela e paralleli in R con il pacchetto ggvanced.

Definire i dati “ben modellati” è un argomento a sé stante. Ma si può pensare ai seguenti concetti nel tuo Data Warehouse:

• Esiste un chiaro schema su come trovare le tabelle dei dati che si riferiscono alle entità commerciali.
• Viene utilizzata una tecnica di modellazione intenzionale / nota, come un modello dimensionale, un modello di relazione tra entità, un data vault, ecc.
• Le convenzioni di denominazione delle tabelle e dei campi sono coerenti, ben documentate e hanno valore commerciale.

Vale anche la pena notare che c’è un approccio olistico e multi-sistema alla modellazione dei dati. Inizia nel tuo sistema OLTP (elaborazione delle transazioni online), dove i dati vengono registrati inizialmente. Ecco alcuni esempi:

• Sistemi CRM come Salesforce
• Sistemi punto vendita come Stripe
• Piattaforme di e-commerce come Amazon

Ideale sarebbe che i tuoi dati fossero normalizzati nella terza forma normale quando raccolti attraverso un sistema di origine. Quindi dovrebbero essere inglobati in un ambiente di analisi, altrimenti noto come sistema OLAP (elaborazione analitica online) dove viene applicata una tecnica di modellizzazione analitica. Nel contesto di questo articolo, il sistema OLAP è sinonimo di un data warehouse cloud. Ma i sistemi OLAP possono includere anche strumenti ospitati in modo indipendente come SQL Server, MySQL o PostgreSQL.

Mentre gli analisti dei dati e gli scienziati dei dati interagiscono solo con il sistema OLAP, la strategia di modellazione dei dati di un’organizzazione deve tener conto sia di OLTP che di OLAP per essere sostenibile.

Ecco 5 segnali chiave che illustrano che il tuo ambiente di analisi è mal modellato.

1.) Serve Conoscenza Tribale per Capire Dove Trovare i Dati

Perché un nuovo analista abbia successo quando viene assunto, ha bisogno di una mappa chiara di quali dati sono disponibili nel Data Warehouse, da dove provengono e quale è il loro contesto commerciale. Tuttavia, le squadre con dati mal modellati spesso faticano ad accogliere i nuovi candidati, non capendo perché ci vuole tanto tempo ai nuovi assunti per rispondere alle domande commerciali di base. Senza una giusta guida, le squadre di analisi possono sperimentare elevati tassi di rotazione perché ai nuovi membri non vengono forniti gli strumenti necessari per avere successo.

Gli analisti dei dati e gli scienziati dei dati dovrebbero concentrarsi sulla risoluzione dei problemi commerciali e non sprecare tempo per trovare dove si trovano le entità commerciali. Più velocemente le squadre diventano familiari con quali dati sono disponibili, più velocemente possono essere completati i dashboard e i modelli predittivi. Ciò aumenta la produttività della squadra.

Se solo una manciata di analisti sa come rispondere alle domande commerciali di base, questo è un problema. Lavorare in un approccio così isolato non è scalabile e limiterà solo il numero di problemi che la squadra può risolvere.

2.) Diversi Analisti Producono Risultati Diversi per le Stesse Metriche

Se non esiste una singola fonte di verità, può essere facile per i diversi membri del team calcolare la stessa metrica in modi diversi. Ad esempio, come viene definito il fatturato? E quali tabelle vengono utilizzate per calcolarlo? Deve esserci un percorso chiaro per definire la logica aziendale, che inizia tutte con un modello di dati intenzionale.

Ho lavorato in ambienti in cui c’erano 3 diverse tabelle che rappresentavano la stessa entità aziendale, che utilizzavano tutte diverse logiche SQL per arrivare ad un risultato simile, ma non identico. Accoppiato a una coda di richieste di reporting mal gestita, ciò comporta che due diversi analisti rispondano alla stessa domanda con risultati diversi. Questo non solo fa perdere fiducia agli stakeholder nei dati, ma richiede anche un lavoro di riconciliazione noioso e non necessario tra i team.

3.) I team devono riutilizzare i blocchi di codice ridondanti per la logica aziendale

Ho visto team che hanno un foglio di Google di dichiarazioni SQL CASE che delineano specifiche metriche aziendali. Questi erano di lunghezza notevole e difficili da leggere. Sebbene tenti di offrire coerenza tra i team, il problema di questo è che viola i principi DRY (Don’t Repeat Yourself) all’interno dell’organizzazione.

Per molti team con questo tipo di problema, l’uso di uno strumento di trasformazione come DBT consente agli ingegneri di analisi di definire la logica aziendale in un unico punto e quindi far riferimento ad essa in molti posti.

Pensa all’esempio seguente: se sei un’azienda di e-commerce e c’è un modo complesso per calcolare le visualizzazioni di pagina (che va bene), perché stai distribuendo e duplicando quella logica aziendale nel tuo strumento di BI? Non solo questo è rischioso nel caso in cui la logica non sia copiata e incollata nello stesso modo ogni volta, ma è uno spreco di computazione, che è il più grande costo della maggior parte dei provider cloud.

Per risolvere questo problema, considera di mappare le aggregazioni e la logica aziendale comuni che devono avere luogo, eseguire un lavoro di trasformazione giornaliero (o con la frequenza necessaria) e scriverlo su una tabella. Poi fai sedere il tuo livello di BI sopra di esso.

4.) Il tuo Data Warehouse si comporta male

Come indicato sopra, i dati mal modellati introducono ridondanza. Ma crea anche una complessità inutile. L’eccesso di risorse di calcolo è un biprodotto di questo, e tutti i data warehouse cloud hanno limiti fino a una determinata soglia di prezzo. Una volta raggiunto quel limite, l’esecuzione di nuove query potrebbe diventare estremamente lenta e in alcuni casi non fattibile.

Ogni ingegnere di dati ti dirà che l’acquisto di risorse aggiuntive non è una soluzione sostenibile a questo problema.

Le query lunghe e complesse non solo richiedono tempo per essere eseguite da sole, ma riducono le risorse disponibili nel tuo ambiente. Consideriamo un esempio in cui è necessario eseguire una query che coinvolge 20 join. Ci sono pochissimi scenari in cui questa è una soluzione ideale, poiché mostra che i dati necessari per rispondere a un problema aziendale non sono archiviati in un formato facilmente accessibile. Questi molti join possono essere computazionalmente costosi, soprattutto quando le tabelle correlate sono di grande volume o se la clausola ON coinvolge più colonne. Se stai implementando un modello dimensionale, il tuo team potrebbe voler considerare la creazione di una nuova tabella di fatti nel tuo database in questi scenari.

Le risorse sono misurate in modi diversi a seconda del provider cloud che stai utilizzando, ma seguono tutti lo stesso concetto di utilizzare un numero dedicato di CPU virtuali. Ad esempio, BigQuery utilizza il concetto di slot, che effettivamente è il numero di risorse di calcolo disponibili utilizzate per eseguire una query. Le organizzazioni con prezzi on demand ricevono 2.000 slot da utilizzare in qualsiasi momento. Quindi, se una query è altamente complessa e richiede più del numero disponibile di slot, altre query si siederanno in coda prima di poter essere eseguite.

5.) Spesso devi codificare valori nell’SQL

I valori codificati duramente sono spesso un segnale che mancano dati necessari nel tuo Data Warehouse. Nel contesto di un modello dimensionale, ciò significa di solito che è necessario creare una nuova tabella di dimensione per ottenere colonne aggiuntive.

Zach Quinn ha scritto un articolo che illustra molto bene questo concetto, dimostrando come eliminare le lunghe dichiarazioni CASE con una tabella di ricerca. Mettendo questo esempio nel contesto di un modello dimensionale – supponiamo che la tua organizzazione abbia bisogno di fare molte analisi geospaziali. Hai una tabella di customer_dimension che dà l’abbreviazione dello stato, ma vuoi visualizzarlo come il nome completo dello stato. Potresti scrivere qualcosa come questo:

SELECT customer_id, customer_name, address, city, state AS state_abrevaition, CASE    WHEN state = 'NJ' THEN 'New Jersey'    WHEN state = 'NY' THEN 'New York'    WHEN state = 'PA' THEN 'Pennsylvania'    ..............  END AS state_full_name, zip_codeFROM customer_dimension

Ma questo tipo di istruzione CASE non è sostenibile. Se vogliamo migliorare questa soluzione in maggior dettaglio, dobbiamo unire una tabella di dimensione del codice postale alla tabella delle dimensioni del cliente. Vedrai qui sotto che una tabella di dimensione del codice postale ci darà una granularità ancora maggiore in un’analisi. La tabella potrebbe assomigliare a questa:

Quindi con questa nuova tabella, immagina di poter eseguire invece questa query:

SELECTc.customer_id, c.customer_name, c.address, c.state AS state_abreviation, z.state_name, c.zip_code, z.county_name, z.country_name, z.timezone, z.lat, z.lngFROM customer_dimension cLEFT JOIN zip_code_dimension z  ON c.zip_code = z.zip_code

Non solo questa è una query più elegante e leggibile per produrre il nome completo dello stato, ma ci consente di rispondere a più domande. Con la tabella delle dimensioni del codice postale, possiamo ora aggiungere la latitudine e la longitudine di quel codice postale per creare visualizzazioni della mappa in un formato più pulito. Inoltre, ci sono un paio di altri campi dimensionali che avrebbero potuto richiedere centinaia di righe per codificarli se volessimo includerli nell’output (paese, fuso orario, eccetera).

Conclusione

Se hai trovato pertinenti alcuni dei punti sopra esposti nel tuo ambiente, potrebbe essere il momento di guardare in modo olistico alle tue pipeline di dati e capire dove le squadre di analisti hanno bisogno di colmare il divario. Per poter modellare correttamente i dati delle tue squadre, devi essere in grado di concepire entità aziendali pertinenti e organizzarle in modo da favorire le domande comuni poste all’interno della tua organizzazione. Non esiste un approccio universale, ma deve essere chiaro a tutti i membri del team e creato in modo coerente.