Nell'era del Modern Data Stack, molte organizzazioni si trovano intrappolate tra due estremi: la gestione manuale dei dati, soggetta a errori, o piattaforme ETL (Extract, Transform, Load) proibitivamente costose che richiedono elevati costi fissi mensili. La sfida per i team di ingegneria è costruire un sistema robusto e scalabile che fornisca business intelligence senza pagare per server inattivi.
L'architettura seguente mostra come sfruttare Google Cloud Platform (GCP) per creare una pipeline di dati completamente automatizzata e serverless. Combinando l'ingestione guidata dagli eventi (event-driven) con la trasformazione pianificata, questo sistema garantisce che i costi vengano sostenuti principalmente durante l'elaborazione attiva, riducendo di fatto il sovraccarico operativo a quasi zero per carichi di lavoro di volume medio-basso.
1. Ingestione dei dati senza infrastruttura sempre attiva
Il punto di ingresso della pipeline è progettato intorno alle due fonti più comuni di dati aziendali: le piattaforme esterne (come social network, CRM e strumenti di analisi) e i file caricati manualmente per dataset ad-hoc:
- Piattaforme esterne: Per estrarre dati strutturati da piattaforme come HubSpot, Facebook Ads e Google Analytics, utilizziamo Airbyte, uno strumento ETL moderno dotato di un'ampia gamma di connettori per l'integrazione con piattaforme esterne. Ogni sincronizzazione genera un nuovo file AVRO in GCS, in modo da poter essere archiviato nel data lake senza ulteriori passaggi di normalizzazione. I connettori vengono eseguiti tramite cron job giornalieri, mantenendo le metriche aziendali aggiornate ogni 24 ore senza richiedere un processo di estrazione persistente e sempre attivo.
- File: Per file come CSV legacy o file Excel, evitiamo strumenti ETL pesanti. Utilizziamo invece un servizio Cloud Run basato su Python per eseguire l'immediata pulizia e normalizzazione. Questo ci consente di convalidare gli schemi dei dati "all'edge" (al limite del sistema) prima ancora che i dati tocchino il nostro livello di archiviazione.
Atterraggio dei dati nel Lake
Entrambi i percorsi di ingestione terminano in Cloud Storage (GCS). Airbyte scrive file AVRO pronti all'uso direttamente nel lake, mentre i file caricati manualmente vengono puliti e normalizzati da Cloud Run prima di essere archiviati. A questo punto, GCS diventa il livello di atterraggio (landing layer) e la fonte di verità (source of truth) per il resto della pipeline.
2. Orchestrazione della pipeline tramite eventi
Una volta che i dati atterrano in Cloud Storage, il flusso di lavoro di ingestione diventa guidato dagli eventi. Eventarc si mette in ascolto per intercettare i nuovi file e attiva il flusso di lavoro che li carica in BigQuery:
- Eventarc: Questo servizio ascolta la creazione di nuovi file in GCS. Nel momento in cui un file viene caricato da Airbyte o Cloud Run, Eventarc attiva il flusso di lavoro di ingestione.
- Google Cloud Workflows: Questo è il cervello dell'operazione. Gestisce la sequenza delle operazioni, i tentativi automatici (retries) e la logica condizionale. Essendo un servizio serverless gestito, si paga solo per il numero di passaggi eseguiti e non per il tempo di attività (uptime).
- Cloud Run Ingestion: Workflows chiama un ultimo servizio Cloud Run per caricare i dati convalidati dal Lake all'interno del Data Warehouse.
3. Dai dati grezzi ai modelli pronti per il business
Una volta ingeriti, i dati si muovono attraverso un modello a tre livelli all'interno di BigQuery per garantire qualità, tracciabilità e prestazioni del dato stesso.
Il modello di Data Warehouse Bronze-Silver-Gold
- Bronze - Staging: I dati vengono inizialmente caricati nelle tabelle di staging di BigQuery. Qui rimangono in uno stato molto vicino a quello grezzo originario, preservando la tracciabilità a livello di sorgente e permettendoci di rielaborarli in caso di modifiche alla logica di business, senza doverli recuperare nuovamente dal sistema originale.
- Silver - Intermediate: Dataform applica la pulizia, le join, la deduplicazione e le regole di business utilizzando principalmente delle viste (views). In questo livello, le strutture tecniche sorgenti vengono tradotte in entità analitiche coerenti, come clienti, campagne, ordini o sessioni. Poiché i risultati intermedi non vengono consumati direttamente dagli utenti BI, evitiamo quando possibile di materializzarli in tabelle, risparmiando spazio di archiviazione e mantenendo la logica di trasformazione riutilizzabile per i data mart di presentazione.
- Gold - Presentation: L'ultimo livello contiene tabelle aggregate e pronte per la presentazione, ottimizzate per dashboard e utenti aziendali. A differenza del livello Silver, in questo caso vale la pena materializzare i dati in tabelle anziché in viste: nel tempo, questo riduce i costi delle query perché BigQuery non deve ricalcolare l'intera logica di trasformazione del livello Silver ogni volta che una dashboard si aggiorna. Questi data mart nascondono la complessità della pipeline agli strumenti di reporting ed espongono dataset stabili e documentati a Data Studio e altri consumatori di analytics.
Trasformazione SQL versionata con Dataform
Invece di utilizzare motori di trasformazione esterni, utilizziamo Dataform. Questo ci consente di trattare le nostre trasformazioni di dati come codice software utilizzando SQLX, con tutta la logica di trasformazione archiviata in un repository Git e versionata nel tempo. Dataform gestisce le dipendenze e l'esecuzione degli script SQL che muovono i dati da Bronze a Silver e infine a Gold. In questa configurazione, Dataform viene attivato da un cron job un'ora dopo la sincronizzazione di Airbyte, dando al processo di ingestione il tempo sufficiente per completarsi prima dell'inizio delle trasformazioni.
4. Semplicità operativa per design
Oltre alla riduzione dei costi, questa architettura è progettata per ridurre il carico operativo legato alla gestione di una piattaforma dati. Non c'è alcun cluster Airflow da dimensionare, aggiornare o monitorare, e non ci sono risorse di calcolo inattive in attesa della successiva finestra di ingestione. Ogni responsabilità è isolata in un servizio gestito: Cloud Run gestisce la pre-elaborazione personalizzata e la logica di ingestione, Eventarc reagisce ai nuovi file, Workflows coordina i passaggi di esecuzione, BigQuery archivia ed elabora i dati analitici, e Dataform gestisce le dipendenze SQL.
Questa separazione migliora anche la resilienza e la manutenibilità. Cloud Storage funge da fonte di verità riproducibile, quindi i caricamenti falliti o le regole di business modificate possono essere rielaborati senza dover chiamare nuovamente le API originali. Le trasformazioni sono versionate in Git, rendendo le modifiche revisionabili e verificabili. La struttura Bronze-Silver-Gold crea un confine chiaro tra dati grezzi, logica di business riutilizzabile e data mart pronti per le dashboard; ciò mantiene semplici gli strumenti di BI e protegge gli utenti aziendali dalla complessità dei processi a monte.
5. Perché il costo rimane vicino allo zero
Il fattore principale alla base di questa architettura è l'efficienza dei costi. Scegliendo questi componenti specifici, massimizziamo l'uso dei livelli gratuiti (free tier) di GCP e dei modelli "pay-as-you-go":
il principio chiave è che ogni componente principale scala a zero o addebita costi solo quando viene effettivamente svolto del lavoro. Cloud Run viene eseguito solo durante le richieste di pre-elaborazione e ingestione. Eventarc addebita i costi in base agli eventi anziché per i listener inattivi. Workflows tariffa in base ai passaggi eseguiti anziché al tempo di attività del server. Dataform viene eseguito su pianificazione invece di richiedere un worker di trasformazione permanente. BigQuery separa l'archiviazione dal calcolo e addebita l'elaborazione delle query in base alla quantità di dati scansionati. Per carichi di lavoro di volume medio-basso, questo significa che la piattaforma può rimanere completamente automatizzata senza sostenere il costo fisso mensile di un'infrastruttura sempre attiva.
