Für viele Unternehmen ist Power BI der Dreh- und Angelpunkt, wenn es um Zahlen, Fakten und Entscheidungen geht. Dort wird die Bedeutung der Daten beschrieben, sie werden transformiert und ihre Zusammenhänge modelliert. Diese Informationen bleiben allerdings oft isoliert im Microsoft-Universum. Möchte man Agenten nutzen, um Insights zu generieren, muss man sie erst aufwändig für den Agenten bereitstellen. Häufig wird die Semantik dafür von Hand nachgebaut.

Ich habe deshalb ein kleines Werkzeug geschrieben: https://github.com/s6nlbeck/tmdl2ossie. Es liest ein Power-BI-Semantikmodell ein und überführt es in das herstellerneutrale Format „Apache Ossie“. Von dort exportiert es nach Snowflake, Databricks, Cube und Honeydew.

Das Problem: Jeder Semantic Layer spricht seine eigene Sprache

Semantische Schichten sind gerade überall. Snowflake hat semantische Modelle für Cortex Analyst, Databricks hat Metric Views, dazu kommen Cube, Honeydew, dbt und andere. Alle beschreiben im Kern dasselbe: Tabellen, Felder, Beziehungen und Kennzahlen. Und jede Plattform nutzt dafür ihr eigenes Format.

Das ist besonders ärgerlich, weil KI-Agenten genau diese Semantik brauchen, um Halluzinationen zu reduzieren und zuverlässige Antworten zu den Daten zu geben. Ohne sie wissen sie nicht, dass „Umsatz“ aus der Verkaufstabelle kommt und über die Kunden-ID mit der Region verbunden ist.

Apache Ossie als gemeinsame Sprache

Apache Ossie ist ein herstellerneutrales YAML-Format für genau diese Beschreibung. Die Idee ist einfach: einmal nach Ossie übersetzen oder direkt in Ossie modellieren, dann überallhin exportieren. Für den Export gibt es bereits eine Reihe fertiger Konverter.

Das Problem dabei: Für viele Unternehmen ist Power BI das Semantik-Werkzeug schlechthin. Die Semantik doppelt zu pflegen, ist keine Lösung. Power BI in den Ruhestand zu schicken, aber leider auch nicht. Die Datenanalysten kennen und schätzen ihr Power BI und ein Umstieg ist mit großem Aufwand verbunden.

Da Power BI selbst kein Ossie exportiert, musste eine Lösung her, die Power BI weiter nutzt, aber dafür sorgt, dass die Semantik nicht aufwändig nachgebaut werden muss. Mein Ziel: Die Semantik wird in Power BI gepflegt und lässt sich ohne großen Aufwand auch in Snowflake und Co. nutzen.

So sieht es aus

Die Oberfläche ist eine kleine Web-App mit vier Tabs: Power-BI-Projekt als ZIP hochladen, die übersetzte Semantik prüfen und bearbeiten, das Datenmodell als Graph ansehen und für die Zielplattform exportieren. Alles läuft lokal; es braucht keine Verbindung zu Power BI oder einem Data Warehouse.

Unter der Haube

Mein Werkzeug nutzt die TMDL-Dateien, die Power BI beim Speichern als Projekt (.pbip) anlegt. Im ersten Schritt liest ein eigens entwickelter TMDL-Parser dieses Microsoft-eigene Format ein – reines Python, keine Abhängigkeiten.

Anschließend werden die Objekte aus den TMDL-Dateien auf die Ossie-Semantik abgebildet. Das Ganze funktioniert statisch und deterministisch: Dasselbe Modell ergibt immer dasselbe Ergebnis.

Das Ossie-Modell kann nun mit einem der fertigen Konverter weiterverarbeitet werden. Die für Snowflake, Cube und Honeydew habe ich direkt in mein Projekt integriert. Der Databricks-Konverter ist leider in Java geschrieben. Damit das Werkzeug ohne Java auskommt, habe ich ihn nach Python portiert. Die Tests des Originals laufen auch gegen den Port, und die Ausgabe ist identisch mit der des Java-Konverters.

Grenzen von dem Ganzen

Das Werkzeug ist bisher mit einem kleinen Beispielmodell und den Testsuiten der Konverter geprüft, nicht mit großen Produktivmodellen. Ein offener Punkt ist vor allem die Übersetzung von DAX nach SQL. Kennzahlen in DAX werden zwar mitgenommen, SQL-basierte Ziele wie Snowflake oder Databricks überspringen sie aber. Die naheliegende Lösung wäre ein KI-Agent, der DAX nach SQL übersetzt. Dabei bliebe allerdings der Determinismus auf der Strecke.

Wer ein größeres Modell hat und es ausprobiert: Ich freue mich über Rückmeldungen und Issues auf GitHub.

Lizenz

tmdl2ossie ist frei für private Nutzung, Forschung, Lehre und gemeinnützige Organisationen (PolyForm Noncommercial 1.0.0). Für den Einsatz in Unternehmen gibt es eine kommerzielle Lizenz; Anfragen gerne an mail(at)nils-becker.org.