Cloud-First ist heute das Mantra vieler Data Engineers. Snowflake, BigQuery, Databricks – die Tools sind mächtig. Aber was passiert, wenn man diese Tools nicht nutzen darf? In unserem aktuellen Projekt bewegen wir uns im Bereich Abrechnungsdienstleistungen im Gesundheitswesen. Das bedeutet: Sensible Daten und strikte Regularien. Die Cloud ist hier keine Option, „On-Premise“ ist das Gesetz. Unsere Aufgabe war es, in diesem restriktiven Umfeld eine moderne, agile und vor allem wartbare Data-Warehouse-Lösung zu entwerfen. Wie wir das mit einem MS SQL Server, einem bestehenden Oracle-Monolithen und dbt Core gelöst haben, erzählen wir in diesem Use Case.
Unser Kunde nutzt für das bisherige Reporting die Produktive Datenbank ihres ERP Systems – das Rückgrat des Unternehmens. Dieses wird von von einem anderen verpartnerten Abrechnungsdienstleister zur Verfügung gestellt und von mehreren Unternehmen verwendet. Es ist extrem stabil – aber genau da lag das Problem.
Die Anforderungen an das Reporting änderten sich schneller, als die zentrale IT neue Features liefern konnte. Unsere Ansprechpartnerin (die selbst SQL beherrscht) brauchte Freiheit für Analysen, ohne auf Release-Zyklen warten zu müssen.
• Quelle: Oracle Produktive Datenbank (ReadOnly Zugriff).
• Ziel: MS SQL Server (vorhanden und von den Gremien freigegeben, volle Kontrolle).
• Tooling: dbt Core (Open Source).
• Netzwerk: Alles lokal, keine Cloud-Dienste.
Anstatt gegen Windmühlen zu kämpfen und das Oracle-System ändern zu wollen, haben wir uns für den Aufbau eines eigenständigen Data Warehouse entschieden. Wir lösen die Datenanalyse vom operativen System, indem wir die relevanten Daten aus Oracle in den MS SQL Server überführen und dort eine unabhängige Datenplattform aufbauen.
Die Transformation und Orchestrierung übernimmt dabei komplett dbt (data build tool). Viele denken bei dbt sofort an die Cloud, aber es ist (in der Core-Version) auch ein fantastisches Werkzeug für On-Prem-Szenarien.
Der erste Schritt war die Brücke zwischen den Welten. Wir haben im MS SQL Server einen Linked Server zur Oracle-Datenbank eingerichtet.Tech-Note: Das klingt einfacher, als es war. Die Treiber-Konfiguration war hakelig. Der Durchbruch gelang, als wir auf dem SQL Server einen System DSN (Data Source Name) anlegten und den Linked Server darüber verbanden. Seitdem läuft die Verbindung stabil.
Wir nutzen dbt nicht nur für die Modellierung, sondern auch zur Steuerung der Datentransfers (ELT). Da wir riesige Tabellen nicht täglich voll laden können, setzen wir auf inkrementelle Strategien:
• Updates & Inserts: Wir nutzen die Oracle-Pseudospalte ORA_ROWSCN. Damit identifizieren wir Datensätze, die sich seit dem letzten Lauf geändert haben.
• Deletes: Das ist der knifflige Teil bei ORA_ROWSCN. Gelöschte Daten haben keinen Timestamp mehr. Wir lösen das über dbt Post-Hooks: In einem separaten Schritt vergleichen wir die Primärschlüssel in der Quelle mit unserer Kopie und löschen im MS SQL Server alles, was in Oracle nicht mehr existiert. Der initiale Load dauert zwar ca. 2¾ Stunden, aber die täglichen Inkremente sind in gut einer Stunde durch. Für ein System, das über Nacht läuft, ist das völlig im Rahmen.
Unsere dbt-Struktur folgt einem klaren Muster:
1. Raw: Hier landen die gespiegelten Daten 1:1.
2. Staging: Aktuell sind das reine select * Views auf die Raw-Daten. Das klingt banal, ist aber unsere Versicherung. Sollten wir später „schmutzige“ Rohdaten bereinigen müssen, können wir das hier tun, ohne die Downstream-Modelle zu verändern.
3. Data Marts: Hier entsteht der Mehrwert. Wir modellieren aktuell Use-Case-basiert. Das heißt: Ein Dashboard in Tableau bekommt genau eine, performante Tabelle.
Wie entwickelt man so etwas ohne Cloud-IDE? Ganz klassisch:
• Entwicklung: Visual Studio Code via RDP-Session auf dem Server.
• Versionierung: Git läuft lokal. Nicht nur die Daten, sondern auch der Code verlässt niemals das Firmennetz.
• Orchestrierung: Hier haben wir uns bewusst für „Keep it Simple“ entschieden. Kein Airflow, kein Kubernetes. Ein PowerShell-Skript, das vom Windows Task Scheduler aufgerufen wird. Das Skript startet dbt build und prüft das Ergebnis. Im Fehlerfall startet es ein dbt retry. Für den Fall, dass auch das fehlschlägt, ist eine Benachrichtigung an die Verantwortlichen vorgesehen.
Das Projekt steht zwar noch relativ am Anfang, aber der Nutzen wurde schnell sichtbar:
• Performance: Die Tableau-Dashboards greifen nun auf optimierte Data Marts zu, statt komplexe Joins zur Laufzeit auszuführen.
• Dokumentation: Oracle-Spaltennamen sind oft kryptisch. Wir haben die Spalten zwar nicht umbenannt, weil die Namen im Team schon etabliert sind. Allerdings haben wir sie in den dbt-Schemata mit der entsprechenden Dokumentation versehen. Das Wissen über die Daten ist nun im Code und nicht mehr nur in den Köpfen.
• Selbstständigkeit: Da alles in SQL und dbt definiert ist, kann unsere Kundin nun selbst neue Spalten hinzufügen oder Logiken anpassen. Das Ziel, ein DWH zu haben, das „mitwächst“, ist erreicht.
Das Projekt wurde von unserem Team – Core Data Analysten und DSC Data Analysten – erfolgreich realisiert.
Fazit: Data Stack, die wirktDieses Projekt zeigt, dass man für einen modernen Data Stack keine Cloud braucht. Mit dbt Core und einem soliden SQL Server lässt sich auch in streng regulierten On-Premise-Umgebungen eine flexible, versionierte und automatisierte Datenplattform aufbauen – selbst wenn man dafür manchmal den guten alten Windows Task Scheduler bemühen muss. Wir freuen uns, dass wir diesen Weg mitgestalten durften.
|
Wir unterstützen Dich bei der Konzeption und Umsetzung moderner Reportinglösungen – von der KPI-Definition bis zur Data NAalyse Tools-Implementierung. Gerne beraten wir Dich persönlich und zeigen, wie sich auch in Deinem Unternehmen datenbasierte Strukturen und Abläufe nachhaltig verbessern lassen. Als führender BI-Partner im DACH-Raum sind wir Ihr Experte für BI; Data Analyse & Visualisierung. Spreche uns an!
