Analytics engineering
Il processo di modellare i dati per l'usabilità, portando nella pipeline le pratiche del software engineering; reso popolare da dbt.
L’analytics engineering è il processo di modellare i dati per l’usabilità, oltre che per la velocità del motore, portando nella pipeline dati le pratiche del software engineering: modularità, testing, documentazione, version control. Il termine è stato reso popolare da dbt, la piattaforma di data transformation fondata da Tristan Handy, che secondo lo stesso Handy non è un breakthrough tecnologico ma “a workflow and best-practice breakthrough”: un prodotto che codifica un insieme di buone pratiche. Lo si pratica ogni volta che si prepara un dataset curato, una metrica o un dashboard per qualcun altro.1
Perché esiste
Il data modeling tradizionale del data warehouse enfatizza la velocità: indici, pre-aggregazioni, partizioni. L’analytics engineering aggiunge la seconda metà dell’obiettivo, formulata esplicitamente nel tutorial di Metabase sulle fact table: il dato deve essere veloce per il motore e facile per chi scrive le query. Le pratiche mutuate dal software engineering, SQL modulare, review in git, test, documentazione, rendono sicuro far scrivere codice di produzione agli analyst, che arrivano da background diversi (product, finance, marketing, operations); dbt ha dato a quel lavoro convenzioni, testing, lineage, “l’operating system attorno al SQL”.2
Nell’era degli agenti
In un’intervista del luglio 2026 sul Data Analysis Journal di Olga Berezovsky, Handy sostiene che l’AI rende il ruolo contemporaneamente meno e più rilevante: scrivere SQL complesso a mano perde valore, perché gli LLM lo fanno, ma i principi dell’analytics engineering (definire la business logic, testarla, documentarla, versionarla) diventano più importanti, perché gli agenti AI ne hanno bisogno per lavorare in modo affidabile. Il lavoro si sposta dallo scrivere codice al costruire il contesto che umani e agenti devono capire: “the scarce part is knowing what the query should mean”. È il ponte verso il context layer.1
Il limite che Handy stesso indica: la qualità dell’output resta legata alla chiarezza delle definizioni di business. L’AI scrive query migliori, ma non sa quale campo di revenue sia quello di cui la finanza si fida.1
Il rapporto con il date stamping
Nel cluster questa voce vive in tensione produttiva con la prescrizione di Sahar Massachi: il date stamping è una regola sulla fisica delle tabelle, l’analytics engineering è un processo sul modo di lavorare. Il tutorial di Metabase mostra il punto d’incontro: la progettazione di una fact table self-serve, con pattern come is_first_record/is_latest_record e carico incrementale schedulato con strumenti come dbt, è analytics engineering applicato al tipo di tabella che Massachi datestampa.2
Voci correlate
- Context layer — il passo successivo: organizzare la conoscenza di business per umani e agenti
- Fact table — il tipo di tabella che l’analytics engineering modella per il self-service
- Data engineer come product owner — lo stesso spostamento di valore visto dal lato del ruolo
- Date stamping — la prescrizione operativa complementare
- Pipeline (data engineering) — il codice a cui le pratiche si applicano
- The post-literate engineer — il rischio dell’era in cui produrre è facile e capire è scarso
- Portale: Data engineering
Bibliografia e sitografia
- Olga Berezovsky, When AI Builds the Data Models, What Happens to Analytics Engineering? (intervista a Tristan Handy), Data Analysis Journal, numero 326, 29 luglio 2026.
- Metabase, Analytics engineering for fact tables, Metabase Learn. metabase.com