Che cos’è la modellazione dei dati basata su query?

Cos'è la modellazione dei dati basata su query?

Se te lo sei perso, ho fatto uno spettacolo dal vivo qualche settimana fa con uno dei co-autori di Fondamenti dell’Ingegneria dei Dati che ha definito il concetto di modellazione dei dati guidata dalla query.

Ora si riferiva ai concetti standard di modellazione dei dati che sono:

1. Concettuale
2. Logico
3. Fisico
4. ma aggiungendo il quarto – Modellazione guidata dalla query

Secondo Reis, molte aziende non svolgono più le prime due e spesso passano direttamente allo sviluppo di query per supportare una richiesta singola. Pertanto, è probabile che non stiamo utilizzando alcuna forma di schema a stella o nemmeno ci stiamo chiedendo se stiamo costruendo undata mart o un data warehouse.

• Competenze trasversali che ogni data scientist deve avere
• La IA sostituirà l’umanità?
• Questo articolo sull’IA introduce Sub-Sentence Encoder un modello di intelligenza artificiale di embedding contestuale appreso in modo contrastivo per una rappresentazione semantica dettagliata del testo.

Invece, probabilmente stiamo solo costruendo tabelle per supportare una singola richiesta. O, ancora una volta, come lo chiama Joe, Modellazione guidata dalla query.

Ma cos’è la modellazione guidata dalla query e ha un posto nel mondo dei dati?

Modellazione guidata dalla query

Fonte: Autore

Ora, non c’è una definizione ufficiale per QDM o modelli JIT-data, anche se in passato abbiamo avuto il termine “schema on read“, che è in qualche modo simile.

Ma penso che molti di noi sappiano di cosa si tratta.

È la creazione di tabelle o set di dati come reazione alla richiesta di un singolo stakeholder. Potrebbe esserci una forma di raccolta dei requisiti, ma solo per l’unico stakeholder.

Vantaggi della modellazione guidata dalla query

Ora, come ogni scelta che fai come ingegnere, ci sono vantaggi e svantaggi.

• Velocità per ottenere le prime intuizioni: Il vantaggio più evidente dello sviluppo con un approccio guidato dalla query è il tempo necessario per ottenere le intuizioni (almeno nel breve termine).
• Self-Service – Strumenti come dbt sono stati una grande porta di accesso ai dati per molti team. Hanno anche aiutato ad accelerare la capacità degli analisti e di coloro che sono esperti di SQL di passare dalla query alla tabella. A sua volta, ciò ha anche permesso ai team di raggiungere “l’Obiettivo Sacro” del self-service più rapidamente. Quando ho iniziato nel mondo dei dati, ricordo di aver contattato il team dell’EDW con una query che avevo costruito e che doveva essere implementata. Ho dovuto aspettare 3-4 mesi per vederla implementata… come vista. Questo non era nulla di eccezionale. Molte squadre di analisi probabilmente non riescono a operare efficacemente in quell’ambiente e, di conseguenza, probabilmente creeranno comunque unteam di IT in ombra e un data warehouse.
• Gli stakeholder saranno soddisfatti nel breve periodo: Molti team di dati rimangono bloccati in loop di sviluppo costante JIT perché gli stakeholder spesso subiscono una pressione per farlo. I manager e i direttori hanno bisogno di numeri da fornire ai loro vicepresidenti, i vicepresidenti hanno bisogno di numeri da fornire al comitato esecutivo e l’alto dirigente ha bisogno di numeri da fornire al consiglio di amministrazione. E la costante pressione verso il basso fa sì che gli analisti appena formati o gli ingegneri di dati sovraccarichi vogliano/diano per forza di cose ciò che i loro manager chiedono.

Pertanto, utilizzare la modellazione guidata dalla query è la risposta. Puoi fare delle query dai set di dati grezzi, eseguire alcuni controlli sui dati e boom.

Risposte.

Tutti sono felici.

Svantaggi della modellazione guidata dalla query

C’è sempre un costo per le squadre che decidono di utilizzare un approccio JIT ai loro modelli di dati. E per essere chiari, che questa sia una decisione consapevole o meno, viene presa. Ci sono chiari compromessi.

• Ridotta agilità quando sono necessari cambiamenti – Sebbene il tempo di sviluppo sia più veloce, la capacità di pivotare e cambiare ciò che un sistema sta facendo peggiorerà man mano che si accumulano modelli, dipendenze e debiti tecnologici. Ogni nuovo punto debole nel sistema complesso che viene sviluppato porta a un possibile punto di fallimento di cui potrebbe non essere a conoscenza nessuno.
• Mancanza di metriche coerenti – Quando le squadre dei dati adottano un approccio JIT, c’è una buona possibilità che le stesse metriche vengano sviluppate da diverse squadre utilizzando metodologie leggermente diverse, portando al classico problema dei numeri della squadra che non corrispondono. Molte aziende che ho visto, inclusa FB, creano a loro volta una sorta di livello o portale di metriche che aiuta a definire le metriche chiave e a indicare dove vengono utilizzate.
• Pipeline a spaghetti – Quando si fa un uso intensivo del JIT, i sistemi di pipeline dei dati che vengono creati possono diventare rapidamente pipeline a spaghetti. Vi troverete ad affrontare 18 DAG solo per capire che il campo “customer_category” che pensavate provenisse dalla fonte A era in realtà popolato dalla destinazione B e alla fine è tornato alla fonte A (l’ho visto).
• Set di dati meno robusti – Oltre al rischio di dipendenza da sé, un altro problema è il fatto che anche una modifica che potrebbe essere percepita come piccola su una pipeline potrebbe avere conseguenze significative. Poiché nessuna tabella è definita come nucleo essenziale e la governance è minima, sarà difficile capire appieno il peso di un cambiamento. Ora creiamo soluzioni per questo, come tracciabilità dei dati; ma in certa misura, se ti affidi eccessivamente alla tracciabilità dei dati per capire quanto sia importante un set di dati, probabilmente hai già un problema.
• Costi – Quando ho iniziato nel mondo dei dati, i miei stakeholder mi hanno detto che volevano dati in tempo reale per i loro dashboard. Quindi ho selezionato “dati in diretta” sui miei dashboard di Tableau e li ho pubblicati.

Bene, come puoi immaginare, se sei nel mondo dei dati da due o tre anni, non è passato molto tempo prima che due consulenti siano venuti giù e abbiano definito ciò come causa di un significativo aumento dei carichi sui server. La verità è che strumenti come Tableau e dbt risolvono problemi, ma possono anche crearne di nuovi. Sono così facili da usare che spesso aumentano non solo la velocità delle informazioni ma anche la velocità delle decisioni sbagliate e dell’utilizzo del computer, con conseguenti maggiori costi.

Con tutti questi svantaggi, i modelli basati su query hanno un posto nel mondo dei dati?

I Modelli Basati su Query Hanno un Posto nel Mondo dei Dati

Credo che ci siano situazioni in cui un approccio JIT alla creazione di set di dati abbia senso. Questo è il punto in cui il ruolo di un Ingegnere Analitico ha davvero senso per alcune squadre.

Quando le aziende hanno team di dati più grandi e obiettivi chiari per dipartimento riguardo a come vogliono utilizzare i dati, utilizzare un approccio JIT combinato con un modello di dati centralizzato più tradizionale ha senso.

Questo è quello che abbiamo essenzialmente avuto su Facebook.

Il team in cui ho lavorato ha creato ciò che ho considerato “Data As Infra”, cioè le tabelle che abbiamo costruito erano affidabili per molti altri team di Facebook. Altri ingegneri dei dati stavano creando le loro analisi e analisi basandosi su ciò che avevamo costruito.

Si è arrivati al punto in cui non potevamo più andare manualmente e capire l’impatto di apportare piccoli cambiamenti. Ciò significava che dovevamo trattare i nostri dati più come infrastruttura, non solo come una tabella che si può modificare a causa di una richiesta di un singolo stakeholder.

Tuttavia, se si andava una squadra oltre la nostra, si trovava una combinazione di analisti molto tecnici o ingegneri dei dati orientati al business che avevano bisogno di creare set di dati occasionali per soddisfare richieste aziendali chiare (Ora, a volte era difficile indicare direttamente il nostro impatto poiché era tutto così globale). Ma trattare le tabelle centrali più come infrastrutture, con politiche e governance in atto per assicurarsi che un piccolo cambiamento non rompa tutte le dipendenze, ha senso. Ovviamente, questo non è un modello perfetto, e ho visto molte piccole organizzazioni funzionare bene con il modellizzazione JIT e altre che utilizzano OBT, ma nessuna che discuta davvero la modellizzazione concettuale.

Ma in generale, prima o poi dovrai pagare il debito tecnico, che sia con una riscrittura del codice o continuando lungo questa strada e scoprendo che arrivi a un punto in cui questo meme diventa realtà.

Fonte: Chad Sanderson

Se ti trovi in una situazione in cui hai bisogno di aiuto nell’analisi della tua infrastruttura dati o nella strategia dati, allora fissa una consulenza oggi stesso!

Questo accade spesso in molti team di dati moderni, spesso perché gli analisti e gli scienziati dei dati sono costretti a sviluppare le proprie pipeline di dati. Si concentrano generalmente nel rispondere a un insieme specifico di richieste.

Non sviluppare set di dati robusti può supportare più casi d’uso.

Il Design è un Dopo Pensiero

Creare set di dati e flussi di lavoro esattamente quando necessario, con poca o nessuna raccolta di requisiti, ha dei benefici allo stesso modo in cui c’è benefici nell’estremo prototyping. Ma per ogni beneficio, ci sono compromessi.

I set di dati diventano parte di complesse gerarchie di dipendenze, le richieste aziendali richiedono costanti cambiamenti e, di conseguenza, le query si deteriorano continuamente fino a raggiungere il punto in cui si sta probabilmente mantenendo molto di più rispetto a quanto inizialmente testato.

Prendiamo ad esempio un trave sottoposto a nuovi sforzi in un edificio.

Prima o poi crollerà e probabilmente trascinerà con sé diversi altri travi.

La modellazione basata su query è un tipo di modellazione dei dati? Certo.

Ma meglio conoscere i rischi.

Articolo originariamente pubblicato qui. Ripubblicato con il permesso dell’autore.