ETL-Architektur: asapBI, Trino, Spark, Airflow für Data Engineers

# ETL-Architektur: So vereint asapBI Trino, Spark und Airflow in einer Oberfläche

Die asapBI-Plattform bietet einen schlanken Ansatz, um ETL-Prozesse über eine einzige Oberfläche zu gestalten, die Tools wie Trino, Spark und Airflow orchestriert – ohne dich an einen Anbieter zu binden. Sie erzeugt Code für Routineaufgaben automatisch, erlaubt aber manuelle Anpassungen für knifflige Fälle und unterstützt lokale Entwicklung mit nahtloser Synchronisation.

So funktioniert die einheitliche Oberfläche von asapBI

Das Kernkonzept von asapBI ist eine zentrale Steuerung für Assets, die über Systeme verteilt sind. So werden Datenmodelle und ETL-Prozesse verknüpft, die sonst isoliert blieben. Die Oberfläche ist optional: Ohne sie läuft alles weiter, aber der Aufbau wird umständlicher. Die Architektur der Plattform dreht sich um Orchestrierung, mit asapBI als zentralem Knotenpunkt, der mit externen Clustern und Datenbanken kommuniziert.

Wichtige Anforderungen, die das System erfüllt:

• Für einfache Prozesse (z. B. Datenverschiebung zwischen Tabellen) sorgt eine Drag-and-Drop-Feldzuordnung, die ca. 90 % der Alltagsaufgaben abdeckt.
• Komplexe Workflows erfordern handgeschriebenen Code in SQL, Python, Java, Scala oder R.
• Rechenintensive Aufgaben laufen auf externen Clustern wie Trino, Spark oder Impala – Speicher und Rechenleistung bleiben getrennt.
• Alle Ladevorgänge werden zentral gesteuert, was die Überwachung vereinfacht.
• Offline-Entwicklung ist möglich: Arbeite lokal ohne Internet, dann synchronisiere Änderungen.
• Nur Open-Source-Komponenten, um Vendor-Lock-in zu vermeiden und Wartung zu erleichtern.

Erstellen und Konfigurieren von Datenübertragungsprozessen (DTPs)

Der Grundbaustein für ETL in asapBI ist der DTP (Data Transfer Process) – ein Algorithmus, der eine Tabelle aus anderen füllt, ggf. über verschiedene Datenbanken hinweg. Du erstellst einen DTP und legst Feldzuordnungen über die grafische Oberfläche fest. Er bewegt Daten zwischen DBMS wie Greenplum und ClickHouse, mit Trino oder Spark als Ausführungsengine.

Nach der Konfiguration deployest du den DTP zum Airflow-Orchestrator. asapBI verbindet sich mit Airflow, das Tasks an einen Spark-Cluster weiterleiten kann. Wähle deine Implementierungssprache: SQL oder Python für Spark. Der generierte Code ist im Code-Tab einsehbar und editierbar – volle Transparenz.

Beispiel für automatisch generierten Python-Code für Spark:

# Beispiel für generierten Code für DTP in Spark
from pyspark.sql import SparkSession
spark = SparkSession.builder.appName("DTP_Example").getOrCreate()
df_source = spark.read.format("jdbc").option("url", "jdbc:postgresql://host/db").option("dbtable", "source_table").load()
df_target = df_source.selectExpr("col1", "col2", "col3")
df_target.write.format("jdbc").option("url", "jdbc:clickhouse://host/db").option("dbtable", "target_table").mode("overwrite").save()

Ein DTP in Airflow speichern erzeugt automatisch einen einsatzbereiten DAG. Starte und debugge diese DAGs über die Airflow-UI oder asapBI, das auch Laufprotokolle trackt.

Orchestrierung von Ladeketten und Workflow-Management

Kette DTPs zu Workflows zusammen, die zu DAGs in Airflow werden. Einfache Ketten baust du, indem du DTPs in einen Task-Baum einfügst. Für Bedingungen, Schleifen oder fortgeschrittene Logik bearbeitest du den generierten DAG-Code manuell.

Airflows Stärke liegt im parallelen Ausführen mehrerer DAGs, was ermöglicht:

• Schnellere Ladevorgänge durch Parallelisierung unabhängiger Schritte.
• Automatische oder manuelle Wiederholungen fehlgeschlagener Tasks, ohne die gesamte Kette zu stoppen.
• Wahre Prozessunabhängigkeit.

Kein Orchestrator wie Airflow oder Dagster? asapBI deployt in eine Datenbank deiner Wahl und erzeugt eine Funktion zum Ausführen des DTP. Auch diesen Code kannst du anpassen.

Wichtige Erkenntnisse

• asapBI bietet eine benutzerfreundliche Oberfläche zur Orchestrierung von ETL mit Open-Source-Tools – ohne Vendor-Lock-in.
• Automatische Code-Generierung für Routineaufgaben, manuelle Edits für knifflige Szenarien.
• Offline-Entwicklung und lokales Testen synchronisieren reibungslos.
• Alles von einem Dashboard überwachen und steuern.
• Keine Blackbox: Generierten Code jederzeit einsehen und anpassen.

Die Zukunft von ETL und die Rolle von KI im Data Engineering

Mit fortschreitender KI tauchen Fragen zu klassischem ETL und Datenmodellen auf. Theoretisch alles in einem Data-Lakehouse speichern und KI direkt analysieren lassen – ohne Dashboards. Doch asapBI konzentriert sich derzeit auf die Automatisierung von Routinearbeiten wie Feld-Throughputs, während komplexe Logik bei Ingenieuren bleibt. Solange KI keine Datenverarbeitung autonom übernimmt, bleiben Tools wie asapBI essenziell für Strukturierung und Orchestrierung von ETL.

— Editorial Team