Nel panorama dell’ingegneria dei dati del 2026, la scelta dell’architettura corretta per la movimentazione dei dati non è solo una questione di performance, ma di conformità normativa, specialmente nel settore finanziario. Quando si progetta una pipeline etl vs elt per un’istituzione Fintech, la posta in gioco include la precisione decimale, l’auditabilità completa (Lineage) e la capacità di calcolare il rischio in tempo quasi reale. Questa guida tecnica esplora perché l’approccio ELT (Extract, Load, Transform) è diventato lo standard de facto rispetto al tradizionale ETL, utilizzando uno stack moderno composto da Google BigQuery, dbt (data build tool) e Apache Airflow.

ETL vs ELT: Il Cambio di Paradigma nel Fintech

Per anni, l’approccio ETL (Extract, Transform, Load) è stato dominante. I dati venivano estratti dai sistemi transazionali (es. database dei mutui), trasformati in un server intermedio (staging area) e infine caricati nel Data Warehouse. Questo approccio, sebbene sicuro, presentava colli di bottiglia significativi: la potenza di calcolo del server di trasformazione limitava la velocità e ogni modifica alla logica di business richiedeva complessi aggiornamenti della pipeline prima ancora che il dato atterrasse nel warehouse.

Con l’avvento dei Cloud Data Warehouse come Google BigQuery e AWS Redshift, il paradigma si è spostato verso l’ELT (Extract, Load, Transform). In questo modello:

• Extract: I dati vengono estratti dai sistemi sorgente (CRM, Core Banking).
• Load: I dati vengono caricati immediatamente nel Data Warehouse in formato grezzo (Raw Data).
• Transform: Le trasformazioni avvengono direttamente all’interno del Warehouse sfruttando la sua potenza di calcolo massiva (MPP).

Per il Fintech, l’ELT offre un vantaggio cruciale: l’auditabilità. Poiché i dati grezzi sono sempre disponibili nel Warehouse, è possibile ricostruire la storia di qualsiasi transazione o ricalcolare i KPI retroattivamente senza dover rieseguire l’estrazione.

Architettura della Soluzione: Lo Stack Moderno

Per costruire una pipeline robusta per la gestione dei mutui, utilizzeremo il seguente stack tecnologico, considerato best-practice nel 2026:

• Storage & Compute: Google BigQuery (per la scalabilità serverless).
• Transformation: dbt (per gestire le trasformazioni SQL, la documentazione e il testing).
• Orchestration: Apache Airflow (per schedulare e monitorare i job).

Fase 1: Ingestion e Orchestrazione con Apache Airflow

Il primo passo è portare i dati nel Data Lake/Warehouse. In un contesto Fintech, la tempestività è fondamentale. Utilizziamo Apache Airflow per orchestrare l’estrazione dai database operazionali (es. PostgreSQL) verso BigQuery.

Esempio di DAG Airflow per l’Ingestion

Il seguente snippet concettuale mostra come configurare un task per caricare i dati dei mutui in modalità “append-only” per mantenere lo storico completo.

from airflow import DAG
from airflow.providers.google.cloud.transfers.postgres_to_gcs import PostgresToGCSOperator
from airflow.providers.google.cloud.transfers.gcs_to_bigquery import GCSToBigQueryOperator
from airflow.utils.dates import days_ago

with DAG('fintech_mortgage_ingestion', start_date=days_ago(1), schedule_interval='@hourly') as dag:

    extract_mortgages = PostgresToGCSOperator(
        task_id='extract_mortgages_raw',
        postgres_conn_id='core_banking_db',
        sql='SELECT * FROM mortgages WHERE updated_at > {{ prev_execution_date }}',
        bucket='fintech-datalake-raw',
        filename='mortgages/{{ ds }}/mortgages.json',
    )

    load_to_bq = GCSToBigQueryOperator(
        task_id='load_mortgages_bq',
        bucket='fintech-datalake-raw',
        source_objects=['mortgages/{{ ds }}/mortgages.json'],
        destination_project_dataset_table='fintech_warehouse.raw_mortgages',
        write_disposition='WRITE_APPEND', # Cruciale per lo storico
        source_format='NEWLINE_DELIMITED_JSON',
    )

    extract_mortgages >> load_to_bq

Fase 2: Trasformazione e Modellazione con dbt

Una volta che i dati sono in BigQuery, entra in gioco dbt. A differenza delle stored procedure tradizionali, dbt permette di trattare le trasformazioni dati come codice software (software engineering best practices), includendo versionamento (Git), testing e CI/CD.

Struttura del Progetto dbt

Organizziamo i modelli in tre layer logici:

1. Staging (src): Pulizia leggera, rinomina colonne, casting dei tipi dati.
2. Intermediate (int): Logica di business complessa, join tra tabelle.
3. Marts (fct/dim): Tabelle finali pronte per la BI e il reporting regolatorio.

Calcolo KPI Complessi: Loan-to-Value (LTV) in SQL

Nel settore mutui, il LTV è un indicatore di rischio critico. Ecco come appare un modello dbt (file .sql) che calcola il LTV aggiornato e classifica il rischio, unendo dati anagrafici e valutazioni immobiliari.

-- models/marts/risk/fct_mortgage_risk.sql

WITH mortgages AS (
    SELECT * FROM {{ ref('stg_core_mortgages') }}
),

appraisals AS (
    -- Prendiamo l'ultima valutazione disponibile per l'immobile
    SELECT 
        property_id,
        appraisal_amount,
        appraisal_date,
        ROW_NUMBER() OVER (PARTITION BY property_id ORDER BY appraisal_date DESC) as rn
    FROM {{ ref('stg_external_appraisals') }}
)

SELECT
    m.mortgage_id,
    m.customer_id,
    m.outstanding_balance,
    a.appraisal_amount,
    -- Calcolo LTV: (Saldo Residuo / Valore Immobile) * 100
    ROUND((m.outstanding_balance / NULLIF(a.appraisal_amount, 0)) * 100, 2) as loan_to_value_ratio,
    CASE
        WHEN (m.outstanding_balance / NULLIF(a.appraisal_amount, 0)) > 0.80 THEN 'HIGH_RISK'
        WHEN (m.outstanding_balance / NULLIF(a.appraisal_amount, 0)) BETWEEN 0.50 AND 0.80 THEN 'MEDIUM_RISK'
        ELSE 'LOW_RISK'
    END as risk_category,
    CURRENT_TIMESTAMP() as calculated_at
FROM mortgages m
LEFT JOIN appraisals a ON m.property_id = a.property_id AND a.rn = 1
WHERE m.status = 'ACTIVE'

Data Quality e Auditabilità: Il Cuore del Fintech

In ambito finanziario, un dato errato può portare a sanzioni. L’approccio ELT con dbt eccelle nella Data Quality grazie ai test integrati.

Implementazione dei Test Automatici

Nel file schema.yml di dbt, definiamo le asserzioni che i dati devono soddisfare. Se un test fallisce, la pipeline si blocca o invia un alert, prevenendo la propagazione di dati corrotti.

version: 2

models:
  - name: fct_mortgage_risk
    description: "Tabella dei fatti per il rischio mutui"
    columns:
      - name: mortgage_id
        tests:
          - unique
          - not_null
      - name: loan_to_value_ratio
        tests:
          - not_null
          # Custom test: LTV non può essere negativo o assurdamente alto (>200%)
          - dbt_utils.expression_is_true:
              expression: ">= 0 AND <= 200"

Data Lineage

dbt genera automaticamente un grafo di dipendenze (DAG). Per un auditor, questo significa poter visualizzare graficamente come il dato “Rischio Alto” di un cliente sia stato derivato: dalla tabella raw, attraverso le trasformazioni intermedie, fino al report finale. Questo livello di trasparenza è spesso obbligatorio nelle ispezioni bancarie.

Gestione dell’Infrastruttura e Versionamento

A differenza delle pipeline ETL legacy basate su GUI (interfacce grafiche drag-and-drop), l’approccio moderno è Code-First.

• Version Control (Git): Ogni modifica alla logica di calcolo del LTV è un commit su Git. Possiamo sapere chi ha cambiato la formula, quando e perché (tramite la Pull Request).
• Ambienti Isolati: Grazie a dbt, ogni sviluppatore può eseguire la pipeline in un ambiente sandbox (es. dbt run --target dev) su un sottoinsieme di dati BigQuery, senza impattare la produzione.

Troubleshooting Comune

1. Schema Drift (Cambiamento dello schema sorgente)

Problema: Il Core Banking aggiunge una colonna alla tabella mutui e la pipeline si rompe.
Soluzione: In BigQuery, utilizzare l’opzione schema_update_options=['ALLOW_FIELD_ADDITION'] durante il caricamento. In dbt, utilizzare pacchetti come dbt_utils.star per selezionare dinamicamente le colonne o implementare test di schema rigorosi che avvisano del cambiamento senza rompere il flusso critico.

2. Latenza dei Dati

Problema: I dati delle valutazioni immobiliari arrivano in ritardo rispetto ai saldi dei mutui.
Soluzione: Implementare la logica di “Late Arriving Facts”. Utilizzare le Window Functions di SQL (come visto nell’esempio sopra con ROW_NUMBER) per prendere sempre l’ultimo dato valido disponibile al momento dell’esecuzione, oppure modellare tabelle snapshot per storicizzare lo stato esatto a fine mese.

Conclusioni

La transizione da una pipeline etl vs elt nel settore Fintech non è una moda, ma una necessità operativa. L’utilizzo di BigQuery per lo storage a basso costo e l’alta capacità computazionale, combinato con dbt per la governance delle trasformazioni, permette alle aziende finanziarie di avere dati affidabili, auditabili e tempestivi. Implementare questa architettura richiede competenze di software engineering applicate ai dati, ma il ritorno sull’investimento in termini di compliance e agilità di business è incalcolabile.

Domande frequenti