L’adozione di dbt raccontata da un analyst di N26 è utile proprio perché non è un caso di studio patinato: mostra i benefici concreti e i limiti che emergono quando un progetto cresce in fretta. N26 è una neobank tedesca con licenza bancaria completa, e il suo team di Data Analytics ha portato dbt dentro un’architettura in piena iperscrescita.
Perché dbt
Prima, quasi tutte le pipeline erano gestite dal team Data Warehouse Engineering. Gli analyst potevano costruire modelli solo tramite un microservizio ETL interno, poco standardizzato e macchinoso da estendere. dbt core, che permette di costruire pipeline con statement SELECT, ha spostato la proprietà dei modelli verso gli analyst: chi conosce SQL può creare pipeline production-grade senza SQL “amministrativo”. Il team usa la versione open source, self-hosted, mentre esiste anche dbt Cloud con IDE browser-based.
Cosa è servito per partire
La migrazione non è stata gratuita. Hanno dovuto creare centinaia di file markdown per documentare le tabelle esistenti nel DWH, condizione necessaria per usare le funzioni ref e source alla base del lineage graph, e imparare il templating jinja. Poi hanno convertito i modelli esistenti in logica dbt e introdotto esecuzioni on-demand via Jenkins, con logging integrato nello stack Elasticsearch/Kibana.
Dove si accumula il debito
Oggi N26 esegue sei progetti dbt con oltre 800 modelli, in un’applicazione containerizzata su Kubernetes. Il rovescio della medaglia è istruttivo: non avendo imposto da subito linee guida di sviluppo rigorose, la rete di dipendenze si è fatta fitta. Il DAG giornaliero, il più grande, è pesante e fragile per sovraccarico di modelli, e a volte i job vengono eseguiti due volte perché i pod k8s non si spengono correttamente. Il concetto di “status” di una run dbt, inoltre, non è pienamente sfruttabile durante l’esecuzione.
La direzione presa: assumere analytics engineer dedicati, separare l’analisi di business dallo sviluppo dei modelli e valutare un orchestratore come Airflow per gestire le dipendenze tra servizi. La lezione per chi adotta dbt oggi è chiara: la parte facile è iniziare, quella difficile è tenere sane la modellazione e le dipendenze mentre il progetto scala.
In sintesi
- dbt ha democratizzato la creazione di pipeline in N26, spostandola sugli analyst via SQL.
- Con oltre 800 modelli su sei progetti, la mancanza di guideline iniziali ha reso il DAG giornaliero fragile.
- Il piano è aggiungere analytics engineer e un orchestratore per governare le dipendenze.
Fonte: Analytics Engineering with dbt: A FinTech application — https://www.fivetran.com/blog/analytics-engineering-with-dbt-a-fintech-application
Hai qualcosa da aggiungere? Unisciti alla discussione.