In der Data-Engineering-Landschaft des Jahres 2026 ist die Wahl der richtigen Architektur für die Datenbewegung nicht nur eine Frage der Leistung, sondern auch der regulatorischen Compliance, insbesondere im Finanzsektor. Bei der Planung einer ETL- vs. ELT-Pipeline für ein Fintech-Institut stehen die Dezimalgenauigkeit, die vollständige Auditierbarkeit (Lineage) und die Fähigkeit zur Risikoberechnung in nahezu Echtzeit auf dem Spiel. Dieser technische Leitfaden untersucht, warum der ELT-Ansatz (Extract, Load, Transform) im Vergleich zum traditionellen ETL zum De-facto-Standard geworden ist, und verwendet dabei einen modernen Stack bestehend aus Google BigQuery, dbt (data build tool) und Apache Airflow.

ETL vs. ELT: Der Paradigmenwechsel im Fintech

Jahrelang war der ETL-Ansatz (Extract, Transform, Load) vorherrschend. Daten wurden aus Transaktionssystemen (z. B. Hypothekendatenbanken) extrahiert, auf einem Zwischenserver (Staging Area) transformiert und schließlich in das Data Warehouse geladen. Dieser Ansatz war zwar sicher, wies jedoch erhebliche Engpässe auf: Die Rechenleistung des Transformationsservers begrenzte die Geschwindigkeit, und jede Änderung der Geschäftslogik erforderte komplexe Aktualisierungen der Pipeline, noch bevor die Daten im Warehouse landeten.

Mit dem Aufkommen von Cloud Data Warehouses wie Google BigQuery und AWS Redshift hat sich das Paradigma hin zu ELT (Extract, Load, Transform) verschoben. In diesem Modell:

• Extract: Die Daten werden aus den Quellsystemen (CRM, Core Banking) extrahiert.
• Load: Die Daten werden sofort im Rohformat (Raw Data) in das Data Warehouse geladen.
• Transform: Die Transformationen finden direkt im Warehouse statt, wobei dessen massive Rechenleistung (MPP) genutzt wird.

Für Fintechs bietet ELT einen entscheidenden Vorteil: Auditierbarkeit. Da die Rohdaten immer im Warehouse verfügbar sind, kann die Historie jeder Transaktion rekonstruiert oder KPIs rückwirkend neu berechnet werden, ohne die Extraktion erneut durchführen zu müssen.

Lösungsarchitektur: Der moderne Stack

Um eine robuste Pipeline für das Hypothekenmanagement aufzubauen, verwenden wir den folgenden Technologie-Stack, der 2026 als Best Practice gilt:

• Storage & Compute: Google BigQuery (für serverlose Skalierbarkeit).
• Transformation: dbt (zur Verwaltung von SQL-Transformationen, Dokumentation und Tests).
• Orchestration: Apache Airflow (zum Planen und Überwachen von Jobs).

Phase 1: Ingestion und Orchestrierung mit Apache Airflow

Der erste Schritt besteht darin, die Daten in den Data Lake bzw. das Warehouse zu bringen. Im Fintech-Kontext ist Aktualität entscheidend. Wir verwenden Apache Airflow, um die Extraktion aus operativen Datenbanken (z. B. PostgreSQL) nach BigQuery zu orchestrieren.

Beispiel eines Airflow-DAGs für die Ingestion

Das folgende konzeptionelle Snippet zeigt, wie ein Task konfiguriert wird, um Hypothekendaten im „Append-only“-Modus zu laden, um die vollständige Historie zu bewahren.

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', # Entscheidend für die Historie
        source_format='NEWLINE_DELIMITED_JSON',
    )

    extract_mortgages >> load_to_bq

Phase 2: Transformation und Modellierung mit dbt

Sobald die Daten in BigQuery sind, kommt dbt ins Spiel. Im Gegensatz zu herkömmlichen Stored Procedures ermöglicht dbt die Behandlung von Datentransformationen als Softwarecode (Software Engineering Best Practices), einschließlich Versionierung (Git), Tests und CI/CD.

Struktur des dbt-Projekts

Wir organisieren die Modelle in drei logischen Schichten:

1. Staging (src): Leichte Bereinigung, Umbenennung von Spalten, Casting von Datentypen.
2. Intermediate (int): Komplexe Geschäftslogik, Joins zwischen Tabellen.
3. Marts (fct/dim): Finale Tabellen, bereit für BI und regulatorisches Reporting.

Berechnung komplexer KPIs: Loan-to-Value (LTV) in SQL

Im Hypothekensektor ist der LTV ein kritischer Risikoindikator. So sieht ein dbt-Modell (.sql-Datei) aus, das den aktuellen LTV berechnet und das Risiko klassifiziert, indem es Stammdaten und Immobilienbewertungen zusammenführt.

-- models/marts/risk/fct_mortgage_risk.sql

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

appraisals AS (
    -- Wir nehmen die letzte verfügbare Bewertung für die Immobilie
    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,
    -- LTV-Berechnung: (Restbetrag / Immobilienwert) * 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'

Datenqualität und Auditierbarkeit: Das Herz des Fintech

Im Finanzbereich können fehlerhafte Daten zu Sanktionen führen. Der ELT-Ansatz mit dbt zeichnet sich dank integrierter Tests durch hohe Datenqualität aus.

Implementierung automatischer Tests

In der Datei schema.yml von dbt definieren wir die Zusicherungen (Assertions), die die Daten erfüllen müssen. Wenn ein Test fehlschlägt, stoppt die Pipeline oder sendet einen Alarm, wodurch die Verbreitung korrupter Daten verhindert wird.

version: 2

models:
  - name: fct_mortgage_risk
    description: "Faktentabelle für das Hypothekenrisiko"
    columns:
      - name: mortgage_id
        tests:
          - unique
          - not_null
      - name: loan_to_value_ratio
        tests:
          - not_null
          # Benutzerdefinierter Test: LTV darf nicht negativ oder absurd hoch sein (>200%)
          - dbt_utils.expression_is_true:
              expression: ">= 0 AND <= 200"

Data Lineage

dbt generiert automatisch einen Abhängigkeitsgraphen (DAG). Für einen Prüfer bedeutet dies, dass er grafisch visualisieren kann, wie der Status „Hohes Risiko“ eines Kunden abgeleitet wurde: von der Raw-Tabelle über die Zwischentransformationen bis hin zum finalen Bericht. Dieses Maß an Transparenz ist bei Bankinspektionen oft obligatorisch.

Infrastrukturmanagement und Versionierung

Im Gegensatz zu alten ETL-Pipelines, die auf GUIs (grafischen Drag-and-Drop-Oberflächen) basieren, ist der moderne Ansatz Code-First.

• Version Control (Git): Jede Änderung an der LTV-Berechnungslogik ist ein Commit in Git. Wir können nachvollziehen, wer die Formel geändert hat, wann und warum (über den Pull Request).
• Isolierte Umgebungen: Dank dbt kann jeder Entwickler die Pipeline in einer Sandbox-Umgebung (z. B. dbt run --target dev) auf einer Teilmenge der BigQuery-Daten ausführen, ohne die Produktion zu beeinträchtigen.

Häufiges Troubleshooting

1. Schema Drift (Änderung des Quellschemas)

Problem: Das Core-Banking-System fügt der Hypothekentabelle eine Spalte hinzu und die Pipeline bricht ab.
Lösung: In BigQuery die Option schema_update_options=['ALLOW_FIELD_ADDITION'] während des Ladens verwenden. In dbt Pakete wie dbt_utils.star nutzen, um Spalten dynamisch auszuwählen, oder strenge Schema-Tests implementieren, die vor der Änderung warnen, ohne den kritischen Fluss zu unterbrechen.

2. Datenlatenz

Problem: Die Daten der Immobilienbewertungen kommen verzögert im Vergleich zu den Hypothekensalden an.
Lösung: Implementierung der Logik für „Late Arriving Facts“. Verwendung von SQL-Window-Functions (wie im obigen Beispiel mit ROW_NUMBER), um immer den letzten gültigen Datensatz zum Zeitpunkt der Ausführung zu nehmen, oder Modellierung von Snapshot-Tabellen, um den genauen Status am Monatsende zu historisieren.

Fazit

Der Übergang von einer ETL- zu einer ELT-Pipeline im Fintech-Sektor ist kein Trend, sondern eine operative Notwendigkeit. Die Nutzung von BigQuery für kostengünstigen Speicher und hohe Rechenkapazität, kombiniert mit dbt für die Governance der Transformationen, ermöglicht es Finanzunternehmen, zuverlässige, auditierbare und zeitnahe Daten zu erhalten. Die Implementierung dieser Architektur erfordert auf Daten angewandte Software-Engineering-Kompetenzen, aber der Return on Investment in Bezug auf Compliance und geschäftliche Agilität ist unschätzbar.

Häufig gestellte Fragen