Sigma betreibt Semantic Layer mit 2.883 Modellen als Code auf dbt und Dagster

27. Oktober 2026, 19:51Quelle: dbt Labs

Sigma Computing betreibt seinen eigenen Semantic Layer als versionierten Code in einem dbt-Projekt, orchestriert von Dagster über 2.883 dbt-Modelle und 6 Datenregionen hinweg. Matt Senick, Lead Data Platform Engineer des Unternehmens, beschrieb den Aufbau in einer Session auf dem dbt Summit 2026, wie aus einem Blogbeitrag von dbt Labs hervorgeht.

Das Wichtigste in Kürze

Sigma Computing betreibt seinen eigenen Semantic Layer als versionierten Code in einem dbt-Projekt, orchestriert von Dagster.
63 Dagster-Jobs bauen und deployen über 2.883 dbt-Modelle und 6 Datenregionen hinweg.
Die dbt-Pakete dbt-sigma-data-model, dbt-semantic-view und dbt-cortex-agent kompilieren Definitionen zu Sigma-Datenmodellen, Snowflake Semantic Views und Cortex-Agenten.
Senick stellte Open Semantic Interchange (Ossie) vor, das die Konvertierung zwischen Formaten verschiedener Anbieter ermöglichen soll.

Warum ein Semantic Layer für KI wichtig ist

Senick zufolge hat der Semantic Layer im Zeitalter der LLMs drei Aufgaben. Erstens soll er KI-Anwendungen Leitplanken geben, etwa PII-Beschränkungen und SQL-Formatierungsregeln, die direkt in die Anweisungen auf Modellebene eingebaut sind. Zweitens soll er sicherstellen, dass alle KI-Oberflächen im Unternehmen für eine bestimmte Kennzahl dieselben Definitionen verwenden und sich nie widersprechen. Drittens soll er Agenten genug Modellkontext, Synonyme und verifizierte Abfragen liefern, damit sie über generisches Text-to-SQL-Raten hinauskommen.

In Anlehnung an eine Darstellung aus Anthropics veröffentlichter Forschung zum Thema argumentierte Senick, dass ein Agent, sobald eine Frage eindeutig auf eine definierte Kennzahl abgebildet ist, eine Funktion aufrufen und genau die eine Zahl zurückerhalten können sollte, auf die sich alle anderen Oberflächen im Unternehmen bereits geeinigt haben.

Semantische Objekte in SQL und Jinja definiert

Im eigenen dbt-Projekt von Sigma werden semantische Objekte direkt in SQL und Jinja definiert und versioniert. Sie sind bestimmten Tabellen im Warehouse zugeordnet, mit expliziter Kontrolle auf Spaltenebene darüber, was Fachanwendern zugänglich gemacht wird. Denselben Typ von Semantic Layer verkauft Sigma laut dem Beitrag auch an seine Kunden.

Das Unternehmen gliedert seine semantischen Modelle nach Geschäftsbereichen, darunter Vertrieb, Marketing, Customer Success und Produkt. Zum Kompilieren dieser Definitionen setzt es auf eine kleine Zahl von dbt-Paketen:

dbt-sigma-data-model erzeugt Sigma-Datenmodelle.
dbt-semantic-view erzeugt Snowflake Semantic Views.
dbt-cortex-agent erzeugt Cortex-Agenten.

Alle diese Artefakte werden wie gewöhnliche dbt-Knoten behandelt.

Dagster steuert den Build- und Deploy-Zyklus

Dagster orchestriert das gesamte System. Laut dem Beitrag bauen und deployen 63 Jobs fortlaufend über die 2.883 dbt-Modelle und 6 Datenregionen hinweg. Jeder Lauf lädt das dbt-Manifest aus S3 herunter und führt einen zustandsbasierten (state-aware) dbt-Build aus. Die entstandenen Sigma-Datenmodelle werden anschließend über die API von Sigma zurücksynchronisiert, und das Manifest wird für den nächsten Lauf erneut hochgeladen.

Auf dem Weg zu portablen semantischen Definitionen

Senick gab außerdem einen Ausblick auf Open Semantic Interchange, eine Initiative mit dem Spitznamen Ossie. Sie soll es Teams ermöglichen, zwischen einer Snowflake Semantic View, einer dbt-Metrik und einem Sigma-Datenmodell zu konvertieren, ohne sich an das Format eines einzelnen Anbieters zu binden.

Für Datenteams liefert die Session ein konkretes Beispiel dafür, semantische Definitionen als geprüften, versionierten Code zu behandeln, wobei ein einziger Satz von Kennzahldefinitionen BI-Modelle, Warehouse-Views und KI-Agenten speist. Aufzeichnungen der Keynotes und Breakout-Sessions des dbt Summit 2026 sind laut dbt Labs auf Abruf verfügbar.