Moderner Data-Engineering-Stack — Von ETL bis Real-Time Analytics

Wenn ich für jede ETL-Pipeline, die auf Stored Procedures in Oracle aufgebaut ist, eine Krone bekommen hätte… Der moderne Data-Engineering-Stack hat sich in den letzten Jahren dramatisch verändert. dbt, Airflow, Snowflake — Werkzeuge, die unsere Arbeit mit Daten transformieren. Hier ist unser Stack und warum wir ihn gewählt haben.

Die alte Welt: ETL in Oracle¶

Typisches tschechisches Enterprise: Oracle DB, Stored Procedures für Transformationen, Scheduling über Oracle Scheduler oder Cron. Funktioniert es? Ja. Ist es wartbar? Kaum. Versionskontrolle? Keine. Tests? Nicht vorhanden. Dokumentation? Kommentare in PL/SQL (vielleicht).

ELT statt ETL¶

Paradigmenwechsel: Statt vor dem Laden zu transformieren (ETL), laden Sie Rohdaten und transformieren im Zielsystem (ELT). Warum? Weil moderne Warehouses (Snowflake, BigQuery) genügend Compute für Transformationen haben. Und Rohdaten in einer Landing Zone geben Ihnen die Möglichkeit, bei Logikänderungen erneut zu verarbeiten.

Unser Stack¶

Ingestion: Airbyte für Standardquellen (Datenbanken, APIs, SaaS), benutzerdefinierte Python-Skripte für spezifische Quellen. Data Landing Zone in Azure Blob Storage.

Warehouse: Snowflake. Ja, es ist teuer. Aber: Trennung von Storage und Compute, Auto-Scaling, Time Travel, Zero-Copy Cloning für Dev/Test-Umgebungen. Für Enterprise mit vielen Data Consumers ist es ein Game Changer.

Transformation: dbt (data build tool). SQL-Transformationen versioniert in Git, Datentests (not null, unique, referentielle Integrität), aus Code generierte Dokumentation. Für SQL-native Analysten ist es eine Revolution.

Orchestrierung: Apache Airflow. DAGs in Python, reichhaltiges Operator-Ökosystem, UI für Monitoring. Auf Kubernetes (KubernetesExecutor) für Skalierung.

BI: Metabase für Self-Service Analytics (einfach, Free Tier), Looker für Power Users. Metabase auf Snowflake funktioniert überraschend gut für 90 % der analytischen Abfragen.

dbt — Warum es ein Game Changer ist¶

dbt verwandelt SQL-Transformationen in ein Software-Engineering-Projekt: Versionen in Git, Pull Requests, Code Review, CI/CD, Tests, Dokumentation. Der Analyst schreibt SELECT, dbt kümmert sich um die Materialization (View, Table, Incremental).

-- models/marts/finance/monthly_revenue.sql
SELECT
    date_trunc('month', order_date) AS month,
    SUM(amount) AS revenue,
    COUNT(DISTINCT customer_id) AS customers
FROM {{ ref('stg_orders') }}
WHERE status = 'completed'
GROUP BY 1

Real-Time: Kafka¶

Für Batch reichen Airflow + dbt. Für Real-Time-Events (Transaktionen, IoT-Daten, Clickstream) Apache Kafka. Kafka → Snowflake (Snowpipe) für Near-Real-Time Analytics. Kafka → Custom Consumer für Real-Time Alerting.

Data Governance¶

GDPR in der Tschechischen Republik ist nicht optional. Datenkatalog (DataHub), Column-Level Masking in Snowflake, Audit-Logging wer was wann abgefragt hat. Für regulierte Branchen (Banken) ist es eine Betriebsvoraussetzung.

Daten als Produkt¶

Der moderne Data Stack dreht sich nicht nur um Tools — sondern um den Ansatz. Daten als Produkt, versionskontrollierte Transformationen, automatisiertes Testen. Wenn Sie immer noch Stored Procedures ohne Versionskontrolle und Tests schreiben, ist es Zeit für ein Upgrade.