Pipeline ETL vs ELT în Fintech: Ghid Complet despre BigQuery și dbt

În peisajul ingineriei datelor din 2026, alegerea arhitecturii corecte pentru mișcarea datelor nu este doar o chestiune de performanță, ci de conformitate normativă, în special în sectorul financiar. Când se proiectează un pipeline etl vs elt pentru o instituție Fintech, miza include precizia zecimală, auditabilitatea completă (Lineage) și capacitatea de a calcula riscul aproape în timp real. Acest ghid tehnic explorează motivul pentru care abordarea ELT (Extract, Load, Transform) a devenit standardul de facto față de tradiționalul ETL, utilizând o stivă modernă compusă din Google BigQuery, dbt (data build tool) și Apache Airflow.

ETL vs ELT: Schimbarea de Paradigmă în Fintech

Timp de ani de zile, abordarea ETL (Extract, Transform, Load) a fost dominantă. Datele erau extrase din sistemele tranzacționale (ex. baze de date de credite ipotecare), transformate pe un server intermediar (staging area) și în final încărcate în Data Warehouse. Această abordare, deși sigură, prezenta blocaje semnificative: puterea de calcul a serverului de transformare limita viteza, iar fiecare modificare a logicii de business necesita actualizări complexe ale pipeline-ului înainte ca datele să ajungă în warehouse.

Odată cu apariția Cloud Data Warehouses precum Google BigQuery și AWS Redshift, paradigma s-a mutat către ELT (Extract, Load, Transform). În acest model:

• Extract: Datele sunt extrase din sistemele sursă (CRM, Core Banking).
• Load: Datele sunt încărcate imediat în Data Warehouse în format brut (Raw Data).
• Transform: Transformările au loc direct în interiorul Warehouse-ului, exploatând puterea sa masivă de calcul (MPP).

Pentru Fintech, ELT oferă un avantaj crucial: auditabilitatea. Deoarece datele brute sunt mereu disponibile în Warehouse, este posibilă reconstruirea istoricului oricărei tranzacții sau recalcularea retroactivă a KPI-urilor fără a fi necesară reexecutarea extragerii.

Arhitectura Soluției: Stiva Modernă

Pentru a construi un pipeline robust pentru gestionarea creditelor ipotecare, vom utiliza următoarea stivă tehnologică, considerată best-practice în 2026:

• Storage & Compute: Google BigQuery (pentru scalabilitatea serverless).
• Transformation: dbt (pentru gestionarea transformărilor SQL, documentație și testare).
• Orchestration: Apache Airflow (pentru programarea și monitorizarea job-urilor).

Faza 1: Ingestie și Orchestrare cu Apache Airflow

Primul pas este aducerea datelor în Data Lake/Warehouse. Într-un context Fintech, promptitudinea este fundamentală. Utilizăm Apache Airflow pentru a orchestra extragerea din bazele de date operaționale (ex. PostgreSQL) către BigQuery.

Exemplu de DAG Airflow pentru Ingestie

Următorul fragment conceptual arată cum se configurează un task pentru a încărca datele creditelor ipotecare în modul “append-only” pentru a menține istoricul complet.

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', # Crucial pentru istoric
        source_format='NEWLINE_DELIMITED_JSON',
    )

    extract_mortgages >> load_to_bq

Faza 2: Transformare și Modelare cu dbt

Odată ce datele sunt în BigQuery, intră în joc dbt. Spre deosebire de procedurile stocate tradiționale, dbt permite tratarea transformărilor de date ca și cod software (software engineering best practices), incluzând versionare (Git), testare și CI/CD.

Structura Proiectului dbt

Organizzăm modelele în trei straturi logice:

1. Staging (src): Curățare ușoară, redenumire coloane, casting tipuri de date.
2. Intermediate (int): Logică de business complexă, join între tabele.
3. Marts (fct/dim): Tabele finale pregătite pentru BI și raportare de reglementare.

Calcul KPI Complecși: Loan-to-Value (LTV) în SQL

În sectorul creditelor ipotecare, LTV este un indicator de risc critic. Iată cum arată un model dbt (fișier .sql) care calculează LTV-ul actualizat și clasifică riscul, unind date anagrafice și evaluări imobiliare.

-- models/marts/risk/fct_mortgage_risk.sql

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

appraisals AS (
    -- Preluăm ultima evaluare disponibilă pentru imobil
    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,
    -- Calcul LTV: (Sold Rezidual / Valoare Imobil) * 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 și Auditabilitate: Inima Fintech-ului

În domeniul financiar, o dată eronată poate duce la sancțiuni. Abordarea ELT cu dbt excelează în Data Quality datorită testelor integrate.

Implementarea Testelor Automate

În fișierul schema.yml din dbt, definim aserțiunile pe care datele trebuie să le satisfacă. Dacă un test eșuează, pipeline-ul se blochează sau trimite o alertă, prevenind propagarea datelor corupte.

version: 2

models:
  - name: fct_mortgage_risk
    description: "Tabel de fapte pentru riscul creditelor ipotecare"
    columns:
      - name: mortgage_id
        tests:
          - unique
          - not_null
      - name: loan_to_value_ratio
        tests:
          - not_null
          # Custom test: LTV nu poate fi negativ sau absurd de mare (>200%)
          - dbt_utils.expression_is_true:
              expression: ">= 0 AND <= 200"

Data Lineage

dbt generează automat un graf de dependențe (DAG). Pentru un auditor, acest lucru înseamnă posibilitatea de a vizualiza grafic cum a fost derivată data “Risc Înalt” a unui client: de la tabelul raw, prin transformările intermediare, până la raportul final. Acest nivel de transparență este adesea obligatoriu în inspecțiile bancare.

Gestionarea Infrastructurii și Versionare

Spre deosebire de pipeline-urile ETL legacy bazate pe GUI (interfețe grafice drag-and-drop), abordarea modernă este Code-First.

• Version Control (Git): Fiecare modificare a logicii de calcul a LTV este un commit în Git. Putem ști cine a schimbat formula, când și de ce (prin Pull Request).
• Medii Izolate: Datorită dbt, fiecare dezvoltator poate executa pipeline-ul într-un mediu sandbox (ex. dbt run --target dev) pe un subset de date BigQuery, fără a impacta producția.

Troubleshooting Comun

1. Schema Drift (Schimbarea schemei sursă)

Problemă: Core Banking adaugă o coloană la tabelul de credite ipotecare și pipeline-ul se strică.
Soluție: În BigQuery, utilizați opțiunea schema_update_options=['ALLOW_FIELD_ADDITION'] în timpul încărcării. În dbt, utilizați pachete precum dbt_utils.star pentru a selecta dinamic coloanele sau implementați teste de schemă riguroase care avertizează asupra schimbării fără a rupe fluxul critic.

2. Latența Datelor

Problemă: Datele evaluărilor imobiliare ajung cu întârziere față de soldurile creditelor.
Soluție: Implementați logica de “Late Arriving Facts”. Utilizați Window Functions din SQL (așa cum s-a văzut în exemplul de mai sus cu ROW_NUMBER) pentru a prelua întotdeauna ultima dată validă disponibilă la momentul execuției, sau modelați tabele snapshot pentru a istoriza starea exactă la sfârșitul lunii.

Concluzii

Tranziția de la un pipeline etl vs elt în sectorul Fintech nu este o modă, ci o necesitate operațională. Utilizarea BigQuery pentru stocare la cost redus și capacitate computațională ridicată, combinată cu dbt pentru guvernanța transformărilor, permite companiilor financiare să aibă date fiabile, auditabile și prompte. Implementarea acestei arhitecturi necesită competențe de software engineering aplicate datelor, dar randamentul investiției în termeni de conformitate și agilitate de business este incalculabil.

Întrebări frecvente