DI2 generiert wartbare, lesbare und auditierbare ETL-Prozesse in reinem SQL — automatisch aus den Metadaten deines Quellsystems. Kein proprietärer Pipeline-Editor. Keine Black Box. Nur SQL, das dein Team versteht, reviewen und testen kann.
Welche Plattform, welche Engine, welcher Cloud-Anbieter. Dabei ist die eigentliche Frage eine andere: verstehst du die Daten, mit denen du arbeitest?
Die Pipeline entsteht im UI einer proprietären Plattform. Logik liegt in Konnektoren, Transformationen werden per Drag&Drop zusammengeklickt, Code existiert nur als Export. Reviews, Tests und Auditierbarkeit bleiben auf der Strecke — und mit jedem Tool-Wechsel beginnt die Arbeit neu.
Der Prozess entsteht aus den Metadaten des Quellsystems: Tabellen, Spalten, Datentypen, Beziehungen. Daraus wird reines SQL erzeugt — versioniert, review-fähig, testbar. Das Ergebnis läuft in jeder SQL-Engine deiner Wahl, nicht in unserem Lock-in.
Ein ETL-Prozess ist kein Einmalprojekt. Er muss ein Jahr später noch verstanden, erweitert und überprüft werden können — auch von jemandem, der nicht dabei war.
Jede Prozedur ist eine eigene, klar benannte SQL-Datei. Änderungen an einer Tabelle ziehen keinen UI-Klick-Marathon nach sich — sie sind ein Diff im Git-Repo.
Kein Custom-DSL, kein Drag&Drop-Artefakt. Reines SQL, das Data-Engineers und Analysten ohne Einarbeitung nachvollziehen können.
Drei Protokoll-Ebenen — vom Gesamtlauf bis zum vollständigen Stacktrace. Ausführungsdauer, Schritt-Typ, Tabelle, verarbeitete Zeilen: jeder Lauf ist in SQL-Tabellen belegbar.
Read-only-Zugriff auf das Schema des Quellsystems — Tabellen, Spalten, Typen, Keys.
DI2 liest information_schema und baut daraus ein vollständiges Modell der Quelle.
Du ergänzt, was das DBMS nicht weiß: zulässige Werte, Wertebereiche, Business und Alternate Keys, Historisierungsregeln. Fachwissen wird zu Metadaten — nicht zu Kommentaren im Code.
Drei Stages: Extraktion, Historisierung, Transformation. Die ersten beiden werden vollständig automatisch aus den Metadaten erzeugt. Die Transformationslogik in die Zielstruktur — DWH oder OLTP — bleibt bewusst Handarbeit: DI2 liefert das Gerüst, ihr schreibt die fachliche Logik.
Zwei Modi, ein Ergebnis: synchron direkt in SQL für einfache Ketten, asynchron über Python für parallele oder zeitgesteuerte Läufe.
Datenqualität entsteht nicht durch ein Dashboard am Ende. Sie entsteht, wenn jeder Schritt eines ETL-Prozesses belegbar, reproduzierbar und auswertbar ist — und wenn fachliche Regeln (zulässige Werte, Wertebereiche, Business Keys) als Metadaten im Modell leben, nicht als Kommentare im Code.
DI2 protokolliert jeden Lauf auf drei Ebenen: vom Gesamtprozess bis zum vollständigen Stacktrace. Ausführungsdauer, Schritt-Typ, betroffene Tabelle, Anzahl verarbeiteter Datensätze — alles landet direkt in SQL-Tabellen. Reviewbar im Pull Request. Auswertbar per SELECT.
Ein dynamischer Prüfprozess validiert sämtliche extrahierten Daten gegen deine fachlichen Regeln — als WHERE-Klauseln, die wie alle anderen Regeln als Metadaten hinterlegt sind. Verletzt ein Datensatz eine Regel, landet er in einer Fehler-Tabelle — les- und auswertbar wie jede andere Tabelle — und wird aus der weiteren Verarbeitung ausgeschlossen. Kein stilles Durchreichen. Keine Überraschungen im DWH.
Gesamtlauf: Start, Ende, Status, Dauer, Run-ID, Auslöser.
Pro Prozedur: Typ (Extract / Historize / Transform), Zieltabelle, Zeilen gelesen & geschrieben, Dauer, Rückgabewert.
Bei Fehlern: vollständiger SQL- und Prozeduraufruf-Stack, SQLSTATE, Meldung, Kontextvariablen — ohne Zugriff auf externe Logs.
Wir schauen uns dein Quellsystem an — eine erste lauffähige Pipeline in PostgreSQL.