Power BI und Snowflake: Kennzahlen einmal definieren, überall nutzen

Über den Snowflake-Connector in Power BI Desktop: Daten abrufen → Datenbank → Snowflake, dann Server-URL und Warehouse eintragen und Import oder DirectQuery wählen. Die Verbindung steht in wenigen Minuten. Der Aufwand liegt woanders: in der Logik, die danach in jedem Report entsteht.

Neue Verbindungen nutzen seit Juli 2025 standardmäßig die Connector-Implementierung 2.0 auf Basis des ADBC-Treibers. Microsoft empfiehlt die Anmeldung über Microsoft Entra ID. Daneben gibt es Schlüsselpaar-Authentifizierung, Service Principal und in Fabric die Workspace Identity. Benutzername und Passwort laufen aus, weil Snowflake die Anmeldung mit nur einem Faktor abschaltet.

Single Sign-on über Entra ID funktioniert nur mit DirectQuery. Dann gelten die Row Access Policies in Snowflake für jeden Betrachter einzeln. Ob die Aktualisierung im Power BI Service ein Gateway braucht, hängt von den Netzwerkregeln Ihres Snowflake-Kontos ab.

Stand: November 2026, geprüft gegen die Microsoft-Learn-Dokumentation zum Snowflake-Connector.

Weil jede Kennzahl dort definiert wird, wo sie gebraucht wird: im Report. Jedes Power-BI-Modell rechnet Umsatz, Marge oder Pipeline mit eigenem DAX, eigenen Power-Query-Schritten und eigenen Filtern. Snowflake liefert dieselben Tabellen, die Reports machen daraus verschiedene Zahlen.

Kennzahlen zentralisieren heißt: eine Definition je Kennzahl, gepflegt in Snowflake und von allen Reports gelesen. Dafür muss zuerst sichtbar sein, wo welche Variante steckt. Das zeigt nur eine Data Lineage über alle Schichten, vom Quellsystem über dbt und die Views bis zum Measure im Visual.

Was mehrere Reports brauchen, kommt als View auf die bestehenden Tabellen nach Snowflake: Kennzahl-Definitionen, Mappings, Hierarchien und Schlüssel. In DAX bleibt, was vom Filterkontext abhängt, etwa Time Intelligence oder Anteile an der aktuellen Auswahl.

So wird Snowflake zum Data Warehouse für Power BI im eigentlichen Sinn. Die Views enthalten nur die Spalten, die Reports tatsächlich lesen, mit kanonischen Namen und Einheiten. Die Datenprodukte hängen nicht mehr an einzelnen Reports, und mehrere Teams bauen darauf eigene Reports, ohne Logik zu kopieren.

dbt erweitern wir nur, wenn die Tabellen die Logik nicht tragen: bei fehlenden Attributen, fehlender Historie oder zu langsamen Abfragen. Das hält die Änderung klein und den bestehenden Ladeprozess unangetastet.

Snowflake liest ein Power-BI-Modell als .pbix oder .pbit ein und erzeugt daraus eine Semantic View für Cortex Analyst. Tabellen, Beziehungen und die meisten Measures kommen mit, Measures werden zu Metriken. Time Intelligence, SELECTEDVALUE, Calculation Groups und berechnete Tabellen übernimmt Snowflake nicht.

Die Datei darf höchstens 250 MB groß sein. Snowflake liest das ganze Semantikmodell ein, nicht nur die Tabellen eines Reports. Measures, die im Report statt im Modell liegen, fehlen danach. Tabellen aus anderen Quellen als Snowflake oder mit leeren Parametern werden verworfen.

Wer auf Semantic Views umsteigen will, muss vorher wissen, welcher Teil seiner Logik übertragbar ist. Das beantwortet die Bestandsaufnahme: Sie ordnet jedes Measure zu, ob Snowflake es übernimmt, ob es als View besser aufgehoben ist oder ob es in DAX bleibt.

Stand: November 2026, geprüft gegen die Snowflake-Dokumentation zum Power-BI-Import.

In fünf Phasen: Zugänge klären, Assets erfassen, Lineage-Graph bauen, Thesen prüfen, Maßnahmen ableiten. Jeder Befund aus Dokumentation oder Fachbereich ist zunächst eine These. Zur Maßnahme wird er erst, wenn Code, Metadaten oder Konfiguration ihn belegen.

Der Lineage-Graph reicht von den Quellsystemen über dbt und die Snowflake-Views bis zu jedem Measure, jeder berechneten Spalte und jedem Visual in Power BI. Jedes Objekt ist ein Knoten mit Herkunft und Beleg. Darauf prüfen wir: Welche Kennzahlen sind doppelt definiert, welche View-Spalten liest kein Report, welche Reports greifen an den Datenprodukten vorbei?

Den Graphen bauen wir in ABIS, unserem Werkzeug für agentische BI-Governance. KI-Agenten beantworten darauf Herkunftsfragen wie „Woher kommt Umsatz EUR?“ und schlagen vor, welche Logik in welche View wandert. Regeln auf dem Graphen prüfen nach jeder Änderung, ob das Modell noch stimmt. So arbeiten die Agenten schnell, aber innerhalb geprüfter Grenzen.

Scan und Erhebung bauen wir als Programm, nicht als Handarbeit. Jeder Lauf liefert dieselben Strukturen und lässt sich für weitere Datenprodukte oder nach Änderungen wiederholen, mit Differenz zum letzten Stand.

Die Reports müssen auf Snowflake umgestellt werden: Verbindungen, M-Abfragen und eingebettetes SQL. DAX bleibt in den meisten Fällen unverändert, weil es auf dem Semantikmodell rechnet und nicht auf der Datenbank. Der Wechsel ist trotzdem der beste Zeitpunkt, Logik nach Snowflake zu verlagern.

Snowflake bietet dafür SnowConvert AI. Das Werkzeug stellt Power-BI-Reports im Format .pbit von SQL Server, Azure Synapse, Oracle, Teradata, Redshift oder PostgreSQL auf Snowflake um: Tabellen, Views und eingebettete SQL-Abfragen. Die übrigen M-Schritte bleiben erhalten. DAX und Geschäftslogik erwähnt die Dokumentation nicht, komplexe SQL-Abfragen brauchen Nacharbeit.

Wer nur umstellt, nimmt doppelte Kennzahlen, hartkodierte Mappings und Power-Query-Joins mit auf die neue Plattform. Die Bestandsaufnahme zeigt vor dem Umzug, welche Logik in Views wandert und welche Reports danach dieselbe Kennzahl lesen.

Sie lösen kein Data Warehouse ab, sondern Tableau, Cognos, SSRS oder einen Power-BI-Tenant? Diese Wege beschreibt unsere Seite zur Power BI Migration.

Ein Datenprodukt in Snowflake mit seinen dbt-Modellen und 2 bis 4 Power-BI-Reports, in 2 bis 3 Wochen zum Festpreis von 9.980 €. Wir lesen ausschließlich Metadaten: Objekte, Spalten, Abhängigkeiten und Konfiguration. Geschäftsdaten sehen wir nicht, Prüfabfragen liefern nur Kennzahlen.

Die Bestandsaufnahme ist ein bezahltes Audit und geht tiefer als die kostenfreie Fabric-Analyse. Die Fabric-Analyse zählt Ihren Bestand für eine Migration nach Microsoft Fabric. Die Bestandsaufnahme prüft die Logik eines Datenprodukts bis zur einzelnen Kennzahl und belegt jede Aussage.

Nicht im Festpreis enthalten ist die Bereinigung selbst: Logik in Views verlagern, Compliance-Regeln einrichten, Reports umstellen. Diese Pakete schätzen wir im Maßnahmenkatalog und beginnen sie erst nach Ihrer Freigabe.