Cosa facciamo
Portiamo i dati in un posto solo. Scegliamo le fonti che contano, come il database del prodotto, la fatturazione, il CRM e le piattaforme pubblicitarie, e le carichiamo in un data warehouse o in un database Postgres per l’analisi. I dati grezzi arrivano per primi e restano disponibili. Usiamo connettori gestiti dove costano meno che scrivere codice, e loader su misura dove no.
Li modelliamo una volta, in SQL. Le trasformazioni vivono come modelli SQL sotto controllo di versione, con una struttura in stile dbt: staging, poi tabelle di business pulite, poi le poche tabelle che leggono le dashboard. Ogni modello ha i suoi test e una breve descrizione. Quando una definizione cambia, cambia in un solo file e tutti vedono il numero nuovo.
La gestiamo come la produzione. Le pipeline hanno un orchestratore, i retry e un obiettivo di freschezza per ogni tabella. I controlli di qualità intercettano duplicati, valori nulli e cali improvvisi nel numero di righe. Quando qualcosa si rompe, l’alert arriva a qualcuno che può sistemarlo, con il runbook allegato. È la stessa pratica SRE che applichiamo ai sistemi rivolti ai clienti, perché anche un numero sbagliato in consiglio di amministrazione è un disservizio.
Teniamo i costi sotto controllo. Sui data warehouse si spende troppo con facilità. Guardiamo quali query e quali job costano di più, impostiamo partizioni e schedulazioni in base a come i dati vengono usati e ti diamo una vista dei costi per fonte e per job.
Una piattaforma su misura dell’azienda. Un team di dieci persone non ha bisogno dello stack di una banca. Partiamo dal setup più piccolo che risponde alle tue domande, spesso un Postgres gestito e uno scheduler, e passiamo a un data warehouse in cloud solo quando volumi o numero di utenti lo giustificano. Tutto è definito come codice, quindi il passo successivo è una modifica, non una ricostruzione.
Come lavoriamo di solito
Quasi sempre si parte dal check-up dei dati di due settimane. Seguiamo i numeri chiave dalla fonte alla dashboard e troviamo dove si discostano o si perdono. Ne esce un elenco chiaro di cosa la piattaforma deve sistemare per prima cosa.
Poi costruiamo per iterazioni di due settimane, poche fonti alla volta. Lo stesso team imposta l’infrastruttura e scrive l’analisi sopra, quindi non c’è passaggio di mano tra un fornitore di piattaforma e un fornitore di dati. Quando ce ne andiamo, codice, configurazioni e runbook sono del tuo team.
Fa per te se
- I report leggono direttamente dai database di produzione e li rallentano.
- Due team danno due numeri diversi per la stessa cosa.
- Il mese scorso si è rotta una pipeline e nessuno lo ha saputo per una settimana.
- Stai per assumere il tuo primo analista e vuoi dargli un posto pulito in cui lavorare.