Bidirektionale SAP-HANA-Warehouse-Engine
Eine spec-getriebene Engine, die SAP-HANA-Warehouse-Objekte aus YAML generiert und bestehende zurückparst — gebunden durch eine gemeinsame Zwischenrepräsentation und byte-stabile Roundtrip-Tests.
Eine ~24k-LOC-Engine (453 Tests), in der Spec → Generieren → Parsen byte-für-byte roundtrippt. Die Staging- und Core-Schichten sind gebaut und getestet; die Data-Mart-Schicht ist als Nächstes auf der Roadmap.
SAP-HANA-Data-Warehouse-Objekte von Hand zu erstellen ist repetitiv, und mit der Zeit driftet die Spezifikation, über die nachgedacht wird, vom Code weg, der tatsächlich deployt ist. Diese Engine macht Spezifikation und Code zu zwei Sichten auf eine Repräsentation — generiere in die eine Richtung, parse in die andere — sodass sie nicht driften können. Sie ist deterministisch von Konstruktion: dieselbe Spezifikation erzeugt immer dieselben Bytes.
Diese Seite behandelt die Architektur und die Engineering-Entscheidungen, nicht die Implementierung. Die Staging- und Core-Schichten sind gebaut und getestet; die Data-Mart-Schicht ist auf der Roadmap.
Read-Write-Symmetrie: eine YAML-Spezifikation und die generierten HANA-Objekte binden beide an eine gemeinsame Zwischenrepräsentation. Generieren geht Spec → Objekte; Parsen geht Objekte → Spec; Roundtrips sind byte-identisch.
Hintergrund
SAP-HANA-Warehouse-Entwicklung ist weitgehend manuell — CDS-Entities, SQLScript-Prozeduren und Calculation-Views, von Hand über Staging-, Core- und Data-Mart-Schichten erstellt. Zwei Fehlermodi verstärken sich über die Zeit: die Arbeit ist repetitiv und fehleranfällig, und die Spezifikation driftet vom deployten Code weg. Das Ziel war eine Engine, die die Spezifikation als Single Source of Truth behandelt und Generieren und Parsen strukturell synchron hält.
Design-Entscheidungen
Lesen und Schreiben teilen eine Zwischenrepräsentation. Parser (Lesen) und Code-Generatoren (Schreiben) operieren auf derselben typisierten IR, sodass ein neues Spec-Feld nicht hinzugefügt werden kann, ohne seinen Typ, seinen Parser, seinen Generator und einen Roundtrip-Test gemeinsam anzufassen. Die Symmetrie ist eine erzwungene Invariante, keine Konvention.
Determinismus wird verifiziert, nicht angenommen. Die Output-Reihenfolge ist erzwungen (sortiert, hash-seed-unabhängig), und Golden-Master- plus byte-stabile Roundtrip-Tests stellen sicher, dass dieselbe Spezifikation bei jedem Lauf identische Bytes erzeugt — die Eigenschaft, die die Engine in einer change-kontrollierten Umgebung vertrauenswürdig macht.
Die Engine ist bewusst gescopt. Sie generiert und parst Warehouse-Objekte; sie rät keine Business-Logik, plant keine Jobs, schreibt keine Dokumentation und berührt nicht die Produktion. Das System dadurch zu definieren, was es nicht tun wird, hält es vorhersagbar.
Operative Überlegungen
~24k Zeilen Python mit 453 Tests. Der Kern (Staging- + Core-Schichten) ist gebaut und getestet; die Data-Mart-Schicht ist auf der Roadmap. Der Wert ist die Architektur und die erzwungenen Invarianten, demonstriert an den fertigen Schichten.
Der Parser-Kern wurde wiederverwendet, nicht neu gebaut: er wuchs aus einem separaten plattformweiten Lineage-Extraktions-Tool heraus, das viele bestehende Repositories end-to-end parst. Eine bewährte Komponente über Repository-Grenzen hinweg wiederzuverwenden ist Teil des Designs, kein Nachgedanke.
Möchten Sie das vollständige Bild hinter diesem System? Nehmen Sie Kontakt auf — oder sehen Sie sich die Engineering-Prinzipien an, die durch alle laufen.