I tuoi dati (finalmente) sono nel cloud. Ora smetti di comportarti come se fossi in locale.

I tuoi dati sono nel cloud. Non agire come se fossi in locale.

I moderni stack di dati ti permettono di fare le cose in modo diverso, non solo su una scala maggiore. Approfittane.

Foto di Massimo Botturi su Unsplash

Immagina di aver costruito case con un martello e chiodi per la maggior parte della tua carriera, e io ti do una pistola sparachiodi. Ma invece di premere il grilletto sul legno, la giri di lato e colpisci il chiodo come faresti con un martello.

Probabilmente penseresti che sia costoso e non particolarmente efficace, mentre l’ispettore del cantiere lo considererebbe giustamente un pericolo per la sicurezza.

Ecco, questo perché stai usando strumenti moderni, ma con un pensiero e processi obsoleti. E sebbene questa analogia non sia una perfetta rappresentazione di come alcune squadre di dati operano dopo il passaggio da un ambiente locale a un moderno stack di dati, è vicina.

Le squadre capiscono rapidamente come i servizi di calcolo e archiviazione iperelastici possano consentire loro di gestire tipi di dati più diversi a un volume e una velocità precedentemente impensabili, ma non sempre comprendono l’impatto del cloud sui loro flussi di lavoro.

Quindi forse un’analogia migliore per queste squadre di dati recentemente migrati sarebbe se ti dessi 1.000 pistole sparachiodi… e poi ti vedessi girarle tutte di lato per colpire 1.000 chiodi contemporaneamente.

In ogni caso, la cosa importante da capire è che il moderno stack di dati non solo ti permette di archiviare e elaborare dati in modo più grande e veloce, ma ti consente di gestire i dati in modo fondamentalmente diverso per raggiungere nuovi obiettivi ed estrarre tipi di valore diversi.

Ciò è in parte dovuto all’aumento di scala e velocità, ma anche al maggior numero di metadati e alle integrazioni più fluide nell’ecosistema.

Immagine cortesia di Shane Murray e dell'autore.

In questo post, metto in evidenza tre dei modi più comuni in cui vedo le squadre di dati cambiare il loro comportamento nel cloud e cinque modi in cui non lo fanno (ma dovrebbero). Approfondiamo.

3 Modi in cui le Squadre di Dati sono Cambiate con il Cloud

Ci sono ragioni per cui le squadre di dati passano a un moderno stack di dati (oltre al fatto che il CFO finalmente libera il budget). Questi casi d’uso sono tipicamente il primo e il più semplice cambiamento di comportamento per le squadre di dati una volta che entrano nel cloud. Sono:

Passare da ETL a ELT per accelerare il tempo per ottenere insight

Non puoi semplicemente caricare qualsiasi cosa nel tuo database in locale, soprattutto se vuoi che una query restituisca prima del weekend. Di conseguenza, queste squadre di dati devono valutare attentamente quali dati e come trasformarli nel loro stato finale, spesso tramite un flusso di lavoro codificato in Python.

È come preparare pasti specifici su ordinazione per ogni consumatore di dati anziché mettere a disposizione un buffet, e come chiunque abbia viaggiato in nave da crociera sa, quando devi soddisfare una domanda insaziabile di dati in tutta l’organizzazione, il buffet è la scelta giusta.

Questo è stato il caso di Edward Kent, responsabile tecnico di AutoTrader UK, che ha parlato con il mio team l’anno scorso di fiducia nei dati e della domanda di analisi self-service.

“Vogliamo dare potere ad AutoTrader e ai suoi clienti per prendere decisioni basate sui dati e democratizzare l’accesso ai dati attraverso una piattaforma self-service… Mentre stiamo migrando sistemi affidabili in locale verso il cloud, gli utenti di quei vecchi sistemi devono avere fiducia che le nuove tecnologie basate su cloud siano affidabili come i vecchi sistemi che hanno usato in passato”, ha detto.

Quando le squadre di dati migrano al moderno stack di dati, adottano con entusiasmo strumenti di ingestione automatizzati come Fivetran o strumenti di trasformazione come dbt e Spark insieme a strategie di curatela dei dati più sofisticate. L’analisi self-service apre un nuovo mondo di possibilità, e non è sempre chiaro chi dovrebbe gestire la modellazione dei dati, ma nel complesso è un modo molto più efficiente per affrontare casi d’uso analitici (e non solo!).

Dati in tempo reale per la presa di decisioni operative

Nello stack dati moderno, i dati possono muoversi abbastanza velocemente da non necessitare più di essere riservati solo per il controllo giornaliero delle metriche. I team di dati possono approfittare di tabelle live di Delta, Snowpark, Kafka, Kinesis, micro-batching e altro ancora.

Non tutte le squadre hanno un caso d’uso per i dati in tempo reale, ma quelle che lo hanno sono generalmente ben consapevoli. Di solito si tratta di aziende con significative esigenze logistiche che necessitano di supporto operativo o aziende tecnologiche con un forte reporting integrato nei loro prodotti (anche se una buona parte di queste sono nate nel cloud).

Le sfide esistono ancora, ovviamente. Queste possono comportare a volte l’esecuzione di architetture parallele (batches analitici e flussi in tempo reale) e cercare di raggiungere un livello di controllo qualitativo che non è possibile al grado desiderato. Ma la maggior parte dei leader dei dati capisce rapidamente il valore che deriva dal poter supportare più direttamente la presa di decisioni operative in tempo reale.

AI generativa e machine learning

I team di dati sono perfettamente consapevoli dell’onda di GenAI, e molti osservatori del settore sospettano che questa tecnologia emergente stia guidando una grande ondata di modernizzazione e utilizzo delle infrastrutture.

Ma prima che ChatGPT generasse il suo primo saggio, le applicazioni di machine learning si erano lentamente spostate dal taglio dell’avanguardia alle migliori pratiche standard in diversi settori intensivi di dati, tra cui media, e-commerce e pubblicità.

Oggi, molti team di dati iniziano immediatamente ad esaminare questi casi d’uso non appena dispongono di archiviazione e calcolo scalabili (anche se alcuni trarrebbero vantaggio nel costruire una base migliore).

Se di recente ti sei spostato nel cloud e non hai chiesto all’azienda come questi casi d’uso potrebbero supportare meglio l’attività, mettilo in agenda. Per questa settimana. O per oggi. Mi ringrazierai dopo.

5 Modi in cui i team di dati agiscono ancora come se fossero on-premises

Ora, diamo un’occhiata a alcune delle opportunità non realizzate che i team di dati precedentemente on-premises possono essere più lenti a sfruttare.

Nota: Voglio essere chiaro che mentre la mia analogia precedente era un po’ umoristica, non sto prendendo in giro i team che operano ancora on-premises o che operano nel cloud utilizzando i processi descritti di seguito. Il cambiamento è difficile. Lo è ancora di più quando si affronta un backlog costante e una domanda sempre crescente.

Test dei dati

I team di dati che operano on-premises non hanno la scala o i metadati completi dai registri di query centrali o dai moderni formati delle tabelle per eseguire facilmente la rilevazione delle anomalie basata sull’apprendimento automatico (in altre parole, l’osservabilità dei dati).

Invece, lavorano con i team di dominio per comprendere i requisiti di qualità dei dati e tradurli in regole SQL o test dei dati. Ad esempio, customer_id non dovrebbe mai essere NULL o currency_conversion non dovrebbe mai avere un valore negativo. Esistono strumenti basati su on-premise progettati per aiutare ad accelerare e gestire questo processo.

Quando questi team di dati passano al cloud, il loro primo pensiero non è quello di affrontare la qualità dei dati in modo diverso, ma di eseguire test dei dati su scala cloud. È quello che conoscono.

Ho visto studi di casi che sembravano storie dell’orrore (e no, non dirò nomi) in cui un team di ingegneria dei dati sta eseguendo milioni di attività su migliaia di DAG per monitorare la qualità dei dati su centinaia di pipeline. Wow!

Cosa succede quando si eseguono mezzo milione di test dati? Te lo dirò. Anche se la grande maggioranza supera il test, ce ne sono ancora decine di migliaia che falliranno. E falliranno di nuovo domani, perché non c’è contesto per accelerare l’analisi delle cause principali o anche iniziare a triare per capire da dove iniziare.

Hai in qualche modo affaticato il tuo team con allarmi e non hai ancora raggiunto il livello di copertura di cui hai bisogno. Senza considerare che i test dati su larga scala richiedono tempo e costi.

Immagine cortesia dell'autore. Fonte.

Invece, i team di dati dovrebbero sfruttare tecnologie che possono rilevare, triare e aiutare a individuare potenziali problemi, riservando i test dei dati (o i monitor personalizzati) ai limiti più chiari sui valori più importanti all’interno delle tabelle più utilizzate.

Modellazione dei dati per la genealogia dei dati

Ci sono molte ragioni legittime per supportare un modello di dati centrale, e probabilmente le hai già lette tutte in un fantastico post di Chad Sanderson.

Tuttavia, ogni tanto mi imbatto in team di dati nel cloud che investono tempo considerevole e risorse nella gestione dei modelli di dati per il solo motivo di mantenere e comprendere la genealogia dei dati. Quando sei in loco, quella è essenzialmente la tua migliore opzione a meno che tu non voglia leggere lunghi blocchi di codice SQL e creare una bacheca così piena di flashcard e lana che il tuo partner comincerà a chiederti se stai bene.

Foto di Jason Goodman su Unsplash

(“No Lior! Non sto bene, sto cercando di capire come questa clausola WHERE cambia quali colonne sono in questo JOIN!”)

Diversi strumenti all’interno dello stack dati moderno, inclusi cataloghi dati, piattaforme di osservabilità dei dati e repository di dati, possono sfruttare i metadati per creare la genealogia automatica dei dati. È solo una questione di scegliere un gusto.

Segmentazione dei clienti

Nel vecchio mondo, la vista del cliente è piatta mentre sappiamo che dovrebbe essere una visione globale a 360 gradi.

Questa visione limitata del cliente è il risultato dei dati premodellati (ETL), dei vincoli sperimentali e della durata necessaria ai database in loco per calcolare query più sofisticate (conteggi univoci, valori distinti) su set di dati più grandi.

Purtroppo, i team di dati non sempre rimuovono i paraocchi dalla loro lente del cliente una volta che questi vincoli sono stati rimossi nel cloud. Spesso ci sono diverse ragioni per questo, ma i maggiori colpevoli sono i vecchi e buoni silos di dati.

La piattaforma dati dei clienti che il team di marketing gestisce è ancora viva e vegeta. Quel team potrebbe trarre vantaggio dall’arricchire la loro visione di prospetti e clienti con dati di altri domini memorizzati nel data warehouse/lakehouse, ma le abitudini e il senso di proprietà costruiti anni di gestione delle campagne sono difficili da rompere.

Quindi, invece di puntare a prospetti in base al valore a vita stimato più alto, sarà il costo per lead o il costo per click. Questa è una mancata opportunità per i team di dati di contribuire in modo diretto e altamente visibile all’organizzazione.

Esportazione e condivisione di dati esterni

Copiare ed esportare i dati è la cosa peggiore. Richiede tempo, aggiunge costi, crea problemi di versioning e rende praticamente impossibile il controllo degli accessi.

Invece di sfruttare il tuo stack dati moderno per creare un flusso di dati per esportare i dati ai tuoi partner abituali a velocità fulminee, più team di dati nel cloud dovrebbero sfruttare la condivisione di dati senza copie. Proprio come gestire i permessi di un file cloud ha in gran parte sostituito l’allegato di posta elettronica, la condivisione di dati senza copie consente l’accesso ai dati senza doverli spostare dall’ambiente host.

Sia Snowflake che Databricks hanno annunciato e presentato ampiamente le loro tecnologie di condivisione dei dati alle loro conferenze annuali negli ultimi due anni, e più team di dati dovrebbero iniziare a sfruttarle.

Ottimizzazione dei costi e delle prestazioni

All’interno di molti sistemi in loco, spetta all’amministratore del database supervisionare tutte le variabili che potrebbero influire sulle prestazioni complessive e regolarle se necessario.

All’interno dello stack dati moderno, d’altra parte, spesso si vedono due estremi.

In alcuni casi, il ruolo di DBA rimane o viene affidato a un team centrale di piattaforma dati, il che può creare colli di bottiglia se non gestito correttamente. Più comune, però, è che l’ottimizzazione dei costi o delle prestazioni diventa il far west fino a quando una fattura particolarmente salata arriva sulla scrivania del CFO.

Questo accade spesso quando i team di dati non hanno i monitoraggi dei costi giusti in atto e si verifica un evento particolarmente aggressivo (forse un codice errato o JOIN esplosivi).

Inoltre, alcuni team di dati non sfruttano appieno il modello “paghi per quello che usi” e optano invece per impegnarsi in una quantità predeterminata di crediti (di solito con uno sconto)… per poi superarli. Sebbene non ci sia nulla di intrinsecamente sbagliato nei contratti di impegno di credito, avere quella flessibilità può creare alcune cattive abitudini che possono accumularsi nel tempo se non si è attenti.

Il cloud abilita ed incoraggia un approccio più continuo, collaborativo e integrato per DevOps/DataOps, e lo stesso vale per FinOps. I team che vedo avere più successo nell’ottimizzazione dei costi all’interno dello stack dati moderno sono quelli che lo incorporano nelle loro attività quotidiane e incentivano coloro che sono più vicini ai costi.

“L’adozione di un modello di pricing basato sul consumo rende questo ancora più critico poiché il rilascio di una nuova funzionalità potrebbe potenzialmente far aumentare i costi in modo esponenziale”, ha detto Tom Milner di Tenable. “In qualità di responsabile del mio team, controllo i costi di Snowflake quotidianamente e rendo ogni picco una priorità nel nostro backlog”.

Questo crea cicli di feedback, apprendimenti condivisi e migliaia di piccole correzioni rapide che producono grandi risultati.

“Abbiamo impostato allarmi quando qualcuno effettua una query che ci costerebbe più di $1. Questa è una soglia piuttosto bassa, ma abbiamo scoperto che non è necessario che costi di più. Abbiamo trovato che questo è un buon ciclo di feedback. [Quando si verifica questo allarme] spesso è qualcuno che ha dimenticato un filtro su una colonna partizionata o raggruppata e può imparare rapidamente”, ha detto Stijn Zanders di Aiven.

Infine, implementare modelli di ripartizione dei costi tra i team, una volta impensabili nei giorni pre-cloud, è un’impresa complicata, ma alla fine vale la pena che mi piacerebbe vedere valutare di più dalle squadre di dati.

Essere un apprendista di tutto

Il CEO di Microsoft, Satya Nadella, ha parlato di come ha intenzionalmente cambiato la cultura organizzativa dell’azienda da “sapientoni” a “apprendisti di tutto”. Questo sarebbe il mio miglior consiglio per i leader dei dati, che abbiano appena migrato o siano stati all’avanguardia della modernizzazione dei dati da anni.

Capisco quanto possa essere travolgente. Le nuove tecnologie arrivano veloci e furiose, così come le chiamate dei fornitori che le spacciano. Alla fine, non si tratterà di avere lo stack di dati “più moderno” nel proprio settore, ma di creare un allineamento tra strumenti moderni, talento di alto livello e migliori pratiche.

Per fare ciò, siate sempre pronti a imparare da come i vostri colleghi affrontano molte delle sfide che state affrontando. Coinvolgetevi sui social media, leggete VoAGI, seguite gli analisti e partecipate alle conferenze. Ci vediamo lì!

Cosa pensate delle altre attività di ingegneria dei dati in loco che non hanno più senso nel cloud? Contattate Barr su LinkedIn con eventuali commenti o domande.