Kurz gesagt (TL;DR)
Die Einführung des ELT-Modells garantiert Fintech-Instituten vollständige Auditierbarkeit und Rechengeschwindigkeit, die für die regulatorische Compliance unerlässlich sind.
Die Integration von Google BigQuery und Apache Airflow gewährleistet eine skalierbare Datenaufnahme unter Beibehaltung der unveränderten Historie der Finanztransaktionen.
Der Einsatz von dbt hebt Datentransformationen auf die Ebene von Softwarecode und optimiert so die Governance und die Präzision bei der KPI-Berechnung.
Der Teufel steckt im Detail. 👇 Lesen Sie weiter, um die kritischen Schritte und praktischen Tipps zu entdecken, um keine Fehler zu machen.
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:
- Staging (src): Leichte Bereinigung, Umbenennung von Spalten, Casting von Datentypen.
- Intermediate (int): Komplexe Geschäftslogik, Joins zwischen Tabellen.
- 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
Der Hauptunterschied liegt im Zeitpunkt der Datentransformation. Beim ETL-Modell werden die Daten vor dem Laden verarbeitet, während beim ELT-Paradigma die Rohdaten sofort in das Data Warehouse geladen und anschließend transformiert werden. Im Fintech wird die ELT-Methode bevorzugt, da sie eine vollständige Auditierbarkeit gewährleistet und es ermöglicht, historische KPIs neu zu berechnen, ohne die Extraktion aus den Quellsystemen erneut durchzuführen.
Diese Kombination stellt dank der serverlosen Skalierbarkeit von Google BigQuery und der Fähigkeit von dbt, SQL-Transformationen als Softwarecode zu verwalten, den aktuellen Standard dar. Ihre gemeinsame Nutzung ermöglicht es, die Rechenleistung der Cloud für die Verarbeitung massiver Finanzdatenmengen zu nutzen und gleichzeitig Versionierung, automatische Tests und eine klare Dokumentation der Geschäftslogik sicherzustellen.
Das ELT-Modell erleichtert die Compliance, indem die ursprünglichen Rohdaten im Data Warehouse aufbewahrt werden, wodurch die Historie jeder Transaktion jederzeit rekonstruiert werden kann. Darüber hinaus generieren Tools wie dbt automatisch einen Abhängigkeitsgraphen, bekannt als Data Lineage, der es Prüfern ermöglicht, bei regulatorischen Inspektionen genau zu visualisieren, wie ein finales Datum aus der Quelle abgeleitet wurde.
Die Integrität der Daten wird durch automatische Tests sichergestellt, die in den Transformationscode integriert sind und die Einzigartigkeit sowie Konsistenz der Werte überprüfen. Durch die Definition spezifischer Regeln in der Konfigurationsdatei kann die Pipeline den Prozess blockieren oder sofortige Warnungen senden, wenn Anomalien festgestellt werden, wodurch die Verbreitung von Fehlern in Entscheidungs- oder Regulierungsberichten verhindert wird.
Die Berechnung von Risikoindikatoren erfolgt über modulare SQL-Modelle innerhalb des Data Warehouse, wobei Stammdaten und Immobilienbewertungen zusammengeführt werden. Dank der ELT-Methode können Logiken implementiert werden, die das Risiko historisieren und Datenverzögerungen verwalten, um sicherzustellen, dass die Berechnung immer die valideste und aktuellste Information widerspiegelt, die zum Zeitpunkt der Ausführung verfügbar ist.
Fanden Sie diesen Artikel hilfreich? Gibt es ein anderes Thema, das Sie von mir behandelt sehen möchten?
Schreiben Sie es in die Kommentare unten! Ich lasse mich direkt von Ihren Vorschlägen inspirieren.