Ratgeber & Vergleiche · Stand: 18. Oktober 2026

Snowflake mit Power BI verbinden: Datenweg, SSO und Rechte prüfen

Sie verbinden Power BI über den nativen Snowflake-Connector mit Ihrem Datenbestand. Dabei entscheiden Sie getrennt über den Datenmodus und die Identität: Import lädt Daten in das Semantikmodell; DirectQuery greift bei Bedarf auf Snowflake zu. Soll Snowflake die Rechte des jeweiligen Berichtsbetrachters anwenden, richten Sie den unterstützten DirectQuery-Weg mit Microsoft-Entra-SSO ein und prüfen anschließend die tatsächliche Datensicht.

Für eine tragfähige Verbindung brauchen Sie mehr als eine erfolgreiche Anmeldung. Der richtige Nutzer muss die richtigen Zeilen und Spalten sehen; der angezeigte Datenstand muss zur Aufgabe passen. Die folgenden Schritte verbinden diese Fragen mit der konkreten Einrichtung. SQL- und M-Beispiele verwenden Platzhalter und fiktive Objektnamen. Sie sind ein Ausgangspunkt für eine freigegebene Testumgebung und wurden hier nicht in einem produktiven Konto ausgeführt.

Import oder DirectQuery: Wo wird gearbeitet?

Snowflake stellt die freigegebenen Daten und die nötige Rechenressource bereit. Power BI beschreibt im Semantikmodell Tabellen, Beziehungen und Kennzahlen. Der Bericht verwendet dieses Modell für seine Darstellungen. Diese Ebenen haben unterschiedliche Einstellungen und Verantwortliche.

DirectQuery bedeutet weder garantierte Echtzeit noch die vollständige Abwesenheit zwischengespeicherter Ergebnisse. Composite-Modelle und Hybridtabellen können verschiedene Wege kombinieren. Dann müssen Sie Datenstand und Rechte für jeden tatsächlich genutzten Pfad prüfen. Microsoft erläutert diese Grenzen in seiner DirectQuery-Dokumentation.

Die folgende Grafik zeigt die beiden Grundwege. Die gemeinsame Abnahme am Ende ist entscheidend: Datenmodus und Endnutzeridentität sind eigenständige Entscheidungen.

Daten, Rollen und Connectorstand vorbereiten

Benennen Sie das Snowflake-Konto, den Servernamen, das Warehouse, die Datenbank, das Schema und die freigegebenen Tabellen oder Views. Halten Sie fest, welche Rolle diese Objekte lesen darf und welche Identität verwendet werden soll. Datenaufbereitung und Berichtskonsum benötigen unterschiedliche Rechte: Ein Betrachter braucht keine Anlege- oder Administrationsrechte für die Aufbereitung.

Lassen Sie für den vorgesehenen Lesekontext insbesondere USAGE auf Warehouse, Datenbank und Schema sowie SELECT auf die freigegebenen Objekte prüfen. Die Snowflake-Privilegienreferenz unterscheidet diese Nutzungs- und Leserechte von Verwaltungsrechten. Geben Sie nur den vereinbarten Bestand frei. Die Zuständigen für Snowflake, Microsoft Entra, den Power-BI-Tenant und den Workspace sollten vor dem ersten Verbindungsversuch feststehen. Klären Sie außerdem Desktop-/Servicezugang, benötigte Benutzerlizenzen beziehungsweise Kapazität und den erreichbaren Netzwerkweg.

Den späteren Bericht schon an den Quelldaten prüfen

Als eigenes Beispiel dient ein Ersatzteilbericht: Eine Faktzeile beschreibt genau eine Bestellposition. Der Schlüssel besteht aus Bestell- und Positionsnummer. Datum und Region liefern den fachlichen Kontext. Eine Kontaktadresse ist nur für eine ausdrücklich berechtigte Prüfgruppe sichtbar.

Prüfen Sie vor dem Import beziehungsweise der Verbindung doppelte Positionsschlüssel, fehlende Regionsschlüssel, Nullwerte und Datentypen. Vergleichen Sie Zeilenzahl und Positionssumme vor und nach einem Join. Zwei passende Regionszeilen für denselben Schlüssel würden Beträge vervielfachen. Eine nicht gefundene Region darf nicht unbemerkt aus der Kennzahl verschwinden. Dieses kleine Profiling klärt Fehler, die ein korrekt eingerichteter Connector nicht behebt.

Die konkrete Implementierung dokumentieren

Microsofts Snowflake-Connectorreferenz beschreibt die Implementierung 2.0 mit ADBC. Halten Sie Desktopversion, Gatewayversion bei dessen Einsatz und tatsächlich verwendete Implementierung fest. Prüfen Sie auch relevante Datentypen und Kennzahlen gegen die Quelle.

Zum hier geprüften Stand vom 18. Oktober 2026 nennt die Referenz unter bekannten Problemen falsche Ergebnisse bei bestimmter count distinct-Logik und erhöhten Speicherbedarf. Das bedeutet keinen pauschalen Fehler jeder Installation. Es ist ein konkreter Anlass, etwa Ihre Zahl eindeutiger Bestellungen und große Ladevorgänge mit einem bestätigten Quellergebnis zu vergleichen. Prüfen Sie vor einer späteren Einrichtung den aktuellen Problem- und Versionsstand erneut. Ein dauerhafter Rückweg zum alten ODBC-Treiber lässt sich daraus nicht allgemein ableiten.

Wessen Identität kommt bei Snowflake an?

Bei einer gespeicherten Verbindungsidentität greift Power BI mit deren Rechten auf Snowflake zu. Eine auf diese Identität begrenzte Quellsicht reicht die Identität jedes späteren Berichtsbetrachters nicht automatisch weiter. Beim Import legt sie zunächst fest, welche Daten überhaupt in das Modell gelangen. Die anschließende Betrachtersicht braucht ein passendes Power-BI-Rechtekonzept.

Beim dokumentierten Entra-Endnutzer-SSO für DirectQuery meldet sich der Nutzer am Power-BI-Service an. Power BI fordert bei Microsoft Entra ein Token für Snowflake an und übergibt es über den Treiber. Snowflake validiert das Token, ordnet das enthaltene Identitätsmerkmal einem Snowflake-Nutzer zu und erstellt die Sitzung im vorgesehenen Rollenkontext. Eine gültige Identität erhält damit noch nicht beliebige Datenrechte.

Wählen Sie das Verfahren passend zur verwendeten Oberfläche. Die aktuelle Connectorreferenz nennt neben Entra unter anderem Schlüsselpaarauthentifizierung über ADBC und, in unterstützten Power-BI-/Fabric-Szenarien, Service Principals oder eine Workspace Identity. Die Unterstützung ist hostabhängig. Eine verwaltete Workspaceidentität ist ebenfalls keine automatische Weitergabe des einzelnen Betrachters. Das ältere Benutzername-/Passwortverfahren wird laut Microsoft eingestellt und ist keine geeignete allgemeine Vorlage für eine neue Einrichtung.

Den Netzwerkweg vor dem SSO-Test klären

Der folgende SSO-Ablauf bezieht sich auf den dokumentierten direkten Servicepfad. Dort verwendet Power BI einen eingebetteten Snowflake-Treiber, sodass kein lokales Datengateway erforderlich ist. Für private Snowflake-Konnektivität beschreibt Snowflakes Anleitung dagegen einen Gatewaypfad. Prüfen Sie dessen konkrete Authentifizierung und Einrichtung gesondert; die Aussage gilt nicht pauschal für jede Fabric- oder Netzwerkkonstellation.

Falls Network Policies verwendet werden, müssen die passenden Power-BI-/Azure-IP-Bereiche und betroffenen Regionen zugelassen sein. Verwenden Sie die aktuellen Microsoft-Listen und lassen Sie die Auswahl vom Netzwerkverantwortlichen prüfen. Ein erfolgreicher Desktopzugriff bestätigt den Serviceweg noch nicht.

Nach der aktuellen Snowflake-SSO-Referenz lässt sich keine eigene Network Policy an genau diese External-OAuth-Integration hängen. Eine Accountpolicy hat einen breiteren Wirkungsbereich. Änderungen daran müssen deshalb auch die übrigen betroffenen Zugänge berücksichtigen. Testen Sie Desktop, Service und gegebenenfalls Gateway jeweils aus ihrem tatsächlichen Netzpfad.

Entra-SSO auf beiden Seiten einrichten

1. Tokenweitergabe im Tenant erlauben

Ein Fabric-Administrator öffnet im Power-BI-Verwaltungsportal Mandanteneinstellungen → Integrationseinstellungen → Snowflake SSO, aktiviert die Einstellung und übernimmt sie. Damit wird die Weitergabe der Entra-Authentifizierungstoken an Snowflake erlaubt. Microsoft nennt bis zu eine Stunde, bis die Änderung wirksam ist. Diese Freigabe ersetzt die spätere Einstellung des einzelnen Semantikmodells nicht. Der Ablauf steht in der Power-BI-Serviceanleitung.

2. Die passende Security Integration erstellen

Für den gatewayfreien External-OAuth-Weg erstellt ein berechtigter Snowflake-Administrator die Integration. Er benötigt die entsprechende Verwaltungsrolle beziehungsweise die globale Berechtigung CREATE INTEGRATION. Dieses Modell zeigt die Parameter für die kommerzielle Microsoft-Cloud:

CREATE SECURITY INTEGRATION DEMO_POWERBI_SSO
  TYPE = EXTERNAL_OAUTH
  ENABLED = TRUE
  EXTERNAL_OAUTH_TYPE = AZURE
  EXTERNAL_OAUTH_ISSUER = 'https://sts.windows.net/<ENTRA_TENANT_ID>/'
  EXTERNAL_OAUTH_JWS_KEYS_URL = 'https://login.windows.net/common/discovery/keys'
  EXTERNAL_OAUTH_AUDIENCE_LIST = (
    'https://analysis.windows.net/powerbi/connector/Snowflake',
    'https://analysis.windows.net/powerbi/connector/snowflake'
  )
  EXTERNAL_OAUTH_TOKEN_USER_MAPPING_CLAIM = 'upn'
  EXTERNAL_OAUTH_SNOWFLAKE_USER_MAPPING_ATTRIBUTE = 'login_name';

Ersetzen Sie den Tenantplatzhalter durch den bestätigten Wert Ihrer Umgebung. Der Issuer endet mit einem Schrägstrich /. Audience und übrige Werte müssen einschließlich Groß-/Kleinschreibung zum erwarteten Token passen; Snowflake dokumentiert beide gezeigten Audience-Schreibweisen. Für Microsoft Azure Government gelten andere Audiences unter analysis.usgovcloudapi.net; diese Umgebung braucht ihre passende Variante.

Prüfen Sie bestehende Integrationen vor einer Änderung. Verwenden Sie für eine gezielte Anpassung ALTER SECURITY INTEGRATION und nehmen Sie den betroffenen Zugang danach erneut ab. Die Beispielintegration enthält keine echten Tokens, Zugangsdaten oder Personenidentitäten.

3. Identitätsmapping und Gastnutzer prüfen

Im Beispiel wird der Entra-Claim upn auf login_name abgebildet. Ist kein Loginname definiert, nennt Snowflake den Nutzernamen name als Rückfall. Passt in Ihrer Umgebung stattdessen das E-Mail-Attribut, kann bewusst email_address als Mappingattribut gewählt werden. Ähnlich aussehende E-Mail-Adressen sind kein Beweis einer korrekten Zuordnung.

Für Entra-B2B-Gastnutzer dokumentiert Snowflake den gesonderten Claim unique_name. Prüfen Sie das tatsächlich gelieferte Merkmal zusammen mit dem Identitätsverantwortlichen und einem freigegebenen Gasttestnutzer. Übertragen Sie ein internes UPN-Mapping nicht ungeprüft auf Gäste.

4. Die tatsächlich aktive Rolle bestätigen

Die konfigurierte Standardrolle muss dem Snowflake-Nutzer auch zugewiesen sein. Eine im Connector angeforderte Rolle muss zu dessen erlaubtem Rollenkontext passen. Kontrollieren Sie nach dem Verbindungsversuch die tatsächlich aktive Rolle in der Query History.

ACCOUNTADMIN, ORGADMIN, GLOBALORGADMIN und SECURITYADMIN sind für diesen OAuth-Zugang standardmäßig gesperrt. Eine hoch privilegierte Rolle ist kein Reparaturmittel für einen fehlenden Berichtszugriff. Auch Standard-Sekundärrollen werden in diesem External-OAuth-Weg nicht automatisch aktiviert. Eine Änderung von EXTERNAL_OAUTH_ANY_ROLE_MODE gehört in das bewusst festgelegte Rollenmodell; sie kann den wirksamen Berechtigungsumfang verändern.

Im Desktop verbinden und im Service konfigurieren

Öffnen Sie in Power BI Desktop Daten abrufen → Datenbank → Snowflake. Tragen Sie den bestätigten Servernamen und das Warehouse ein. Prüfen Sie die erweiterten Optionen, insbesondere die vorgesehene Rolle. Wählen Sie die freigegebene Anmeldung, etwa Microsoft-Konto für den eingerichteten Entra-Weg.

Im Navigator wählen Sie Datenbank, Schema und die freigegebenen Objekte. Entscheiden Sie sich für Import oder DirectQuery und prüfen Sie die anschließenden Modellbeziehungen. Der Connector kann beispielsweise so im Power-Query-Editor angesprochen werden:

let
    Quelle = Snowflake.Databases(
        "<IHR_SNOWFLAKE_SERVER>",
        "DEMO_BI_WH",
        [Role = "DEMO_BI_LESEN", Implementation = "2.0"]
    )
in
    Quelle

Der Serverplatzhalter steht für Ihren vollständigen Snowflake-Hostnamen. Warehouse und Rolle sind fiktiv und müssen durch freigegebene Werte ersetzt werden. Dieser M-Ausdruck legt die Verbindungsparameter fest; Anmeldung, Moduswahl und Endnutzer-SSO werden damit nicht automatisch eingerichtet. Wählen Sie nur die benötigten Spalten und Objekte, statt den gesamten verfügbaren Bestand zu übernehmen.

Veröffentlichen Sie danach Bericht und Semantikmodell in den vorgesehenen Workspace. Öffnen Sie dort die Einstellungen des Semantikmodells und richten Sie Verbindung beziehungsweise Datenquellen-Anmeldeinformationen ein. Für den Entra-DirectQuery-Weg aktivieren Sie zusätzlich die Option, dass Endnutzer beim DirectQuery-Zugriff ihre eigenen OAuth2-Anmeldeinformationen verwenden. Prüfen Sie bei einem Gateway dessen passende Zuordnung. Eine Veröffentlichung allein aktiviert diese Weitergabe nicht.

Führen Sie zunächst einen Verbindungs- und Lesetest mit dem vorgesehenen Nutzer durch. Prüfen Sie dieselbe Probe anschließend im Service. So unterscheiden Sie einen funktionierenden Desktopzugang von einer tatsächlich betriebsfähigen Berichtskonfiguration.

Aus Quelldaten ein prüfbares Modell machen

Für den Ersatzteilbericht bleibt die Körnung, also das Grain, eine Bestellposition pro Faktzeile. Die Regionsdimension enthält jeden verwendeten Regionsschlüssel genau einmal. Die Datumsdimension liefert die benötigten Zeitmerkmale. Eine Eins-zu-viele-Beziehung führt von der Dimension zu den zugehörigen Faktzeilen. Microsoft erklärt diese Trennung von Filter-/Gruppierungstabellen und Fakten im Sternschema-Leitfaden.

Prüfen Sie Beziehungen mit fehlenden Schlüsseln, Nullwerten und Dubletten. Eine Kennzahl für Positionssumme beantwortet eine andere Frage als die Zahl eindeutiger Bestellungen. Eine vorgerechnete Tages-/Regionssumme besitzt wiederum eine gröbere Körnung als die Detailtabelle. Verwenden Sie sie nur für Fragen, deren benötigte Merkmale sie tatsächlich enthält. Blenden Sie technische Schlüssel sinnvoll aus und halten Sie benötigte Detailspalten verfügbar.

Transformationen nach Wiederverwendung zuordnen

Eine fachliche Regionszuordnung, die mehrere Berichte verwenden, sollte einen gemeinsamen Verantwortlichen und eine wiederverwendbare Definition haben. SQL beziehungsweise Python in der Aufbereitung können dafür passend sein. Power Query dient geeigneten Aufbereitungsschritten am Modell; DAX bildet semantische Berechnungen wie Kennzahlen ab. Eine einmalige Darstellungsanforderung muss nicht denselben Ort haben wie eine unternehmensweit verwendete Umsatzdefinition. Entscheiden Sie nach Wiederverwendung, Wartbarkeit und Teamkompetenz, statt eine Technologie pauschal auszuschließen.

Bei Dynamic Tables den tatsächlichen Datenstand ansehen

Dynamic Tables können eine deklarativ beschriebene Transformation materialisieren. Ein zugeordnetes Refresh-Warehouse führt die Aktualisierung aus. TARGET_LAG beschreibt dabei ein angestrebtes Datenalter, keinen festen Aktualisierungsrhythmus und keine zugesicherte Ende-zu-Ende-Latenz.

Prüfen Sie im passenden Datenbank-/Schemakontext mit SHOW DYNAMIC TABLES den Zustand und den tatsächlichen Refreshmodus. Sehen Sie danach in der Refresh History nach erfolgreichen beziehungsweise fehlgeschlagenen Läufen und dem Datenzeitpunkt. Für Metadaten und Refresh History benötigt die untersuchende Rolle MONITOR oder eine dieses Recht einschließende Berechtigung; reines SELECT macht nicht alle Prüffelder sichtbar. Snowflakes Einrichtungsanleitung für Dynamic Tables zeigt diese beiden Prüfungen.

Bei TARGET_LAG = DOWNSTREAM hat die Tabelle keinen eigenen Zeitplan. Ein nachgelagerter Dynamic-Table-Verbraucher muss die Aktualisierung anstoßen; ohne einen solchen Verbraucher erfolgt kein automatischer Refresh. Eine gewöhnliche Berichtsabfrage ist kein Ersatz für diesen Scheduler. Die Target-Lag-Referenz erläutert auch, warum das Frischeziel überschritten werden kann.

Fremddaten nur mit bestätigtem Umfang ergänzen

Im Snowflake Marketplace können Listings zusätzliche Daten bereitstellen. Prüfen Sie beim konkreten Angebot Verfügbarkeit, Preis, Nutzungsbedingungen und die Rolle, die zugreifen darf. Ein gefundenes Listing ist noch keine Freigabe zur Nutzung.

Für den Modellfall genügt zunächst eine kleine, freigegebene Lookup-Tabelle, etwa eine Zuordnung von Regionsschlüsseln zu Gebietsnamen. Prüfen Sie Herkunft, Datenstand und eindeutige Schlüssel. Vergleichen Sie nach dem Join Menge und Kennzahlen erneut. Zusätzlicher Speicher, Abfragen und mögliche Listinggebühren gehören zur Entscheidung. Dieses Beispiel setzt weder einen Kauf noch ein tatsächlich abgeschlossenes Abonnement voraus.

Vertrauliche Spalten und regionale Zeilen schützen

Klassifikation und Tags beschreiben zunächst den Bestand

Kennzeichnen Sie die Kontaktspalte fachlich als vertraulich. Klassifikation kann sensible Spalten erkennen und passende Metadaten zuordnen; ein Tag speichert eine solche Einordnung. Ein Tag allein sperrt oder maskiert keinen Wert. Erst die zugeordnete Schutzregel und ihr tatsächlicher Auswertungskontext bestimmen die Ausgabe.

Beachten Sie die Editionsgrenzen: Laut aktueller Tagging-Dokumentation ist grundlegendes Erstellen und Setzen von Tags für alle Accounts verfügbar. Erweiterungen wie tagbasierte Maskierung erfordern Enterprise oder höher. Diese Voraussetzung gilt auch für Sensitive Data Classification, Dynamic Data Masking und Row Access Policies.

Maskierung verändert die Ausgabe

Eine Masking Policy kann je nach Rollen- und Abfragekontext den Originalwert, einen Teilwert oder eine maskierte Darstellung liefern. Für das Modell könnte die Prüfgruppe die synthetische Kontaktadresse sehen, während regionale Betrachter eine festgelegte Ersatzdarstellung erhalten.

Diese Ausgaberegel ersetzt weder die Verschlüsselung gespeicherter Daten noch eine gegebenenfalls benötigte Tokenisierung vor der Speicherung. Prüfen Sie die Policy an der tatsächlich abgefragten Spalte und am tatsächlich veröffentlichten Objekt. Eine andere Detailview ohne denselben Schutz würde den erwarteten Berichtsweg umgehen.

Zeilenschutz muss zum Datenmodus passen

Eine Snowflake Row Access Policy bestimmt bei der Abfrage, welche Zeilen zurückgegeben werden. Im Modell lässt sie beispielsweise einen regionalen Nutzer nur die ihm zugeordneten Regionen sehen. Sie ist kein allgemeiner Schreibschutz.

Mit korrekt eingerichtetem DirectQuery-SSO kann dabei der Quellkontext des Endnutzers wirken. Mit gespeicherter Verbindungsidentität wird dagegen deren Quellkontext verwendet. Beim Import begrenzt die Quellpolicy zunächst den übernommenen Bestand. Sie erzeugt anschließend keine neue Snowflake-Sitzung für jeden Betrachter der Datenkopie. Dafür müssen die Bereitstellungsrechte und gegebenenfalls Power-BI-RLS im Semantikmodell stimmen.

Power-BI-RLS beschränkt im Workspace Viewer. Admins, Members und Contributors sind wegen ihrer Bearbeitungsrechte keine geeigneten eingeschränkten Betrachter für diesen Test. Das erläutert Microsoft unter Row-Level Security mit Power BI.

Die Rechte mit zwei Betrachtern abnehmen

Die folgende Solltabelle gilt für DirectQuery mit korrekt eingerichtetem Endnutzer-SSO: Snowflake wertet Zeilen- und Maskierungsregeln im jeweiligen Quellkontext aus. Nutzen Sie zwei echte, freigegebene Pilotidentitäten. Im eigenen Testmodell besitzt eine Identität ausschließlich regionale Rechte für Nord und sieht die Kontaktadresse maskiert. Die zweite gehört zur ausdrücklich berechtigten Prüfgruppe und darf beide Regionen sowie die synthetischen Kontaktwerte sehen. Keine der Identitäten erhält für den Test eine Workspace-Administratorrolle.

Bei Import wird die Kontaktspalte dagegen im Kontext der Import-/Refreshidentität übernommen. Snowflakes Masking Policy wird für die spätere Betrachtung dieser Datenkopie nicht erneut je Viewer ausgewertet. Die unten erwartete unterschiedliche Spaltensicht lässt sich daher nicht allein durch die Quellpolicy auf einen Importbericht übertragen; dessen Bereitstellungs- und Spaltenrechte brauchen eine eigene Prüfung.

Legen Sie zwei leicht wiedererkennbare künstliche Proben fest: PROBE-NORD und PROBE-SUED, jeweils eine Bestellposition mit einem synthetischen Kontaktwert. Die folgende Tabelle beschreibt erwartete Ergebnisse, keinen hier durchgeführten Test:

Prüfen Sie die Quelle zunächst mit dem jeweiligen Identitäts-/Rollenkontext. Wiederholen Sie die fachlichen Proben im Desktop und vor allem im veröffentlichten Servicebericht. Halten Sie für jeden Weg Identität, erwartete Rolle, Sollwert, tatsächliches Ergebnis und Zeitpunkt fest. Kontrollieren Sie auch alte Anmeldeinformationen, damit eine vermeintliche zweite Anmeldung nicht noch den ersten Kontext verwendet.

Für DirectQuery-Modelle mit aktiviertem SSO unterstützt Power BI Test as role nicht. Verwenden Sie dafür echte Vieweranmeldungen. Ein Rollenwechsel in einem einzigen Demoaccount kann eine Policy demonstrieren, belegt aber nicht die Identitätsweitergabe zweier Benutzer. Erst die positiven und negativen Proben bestätigen die beabsichtigte Sicht. Prüfen Sie nur Export- und Analysewege, die für die spätere Nutzergruppe tatsächlich erlaubt sind.

Datenstand, Antwortzeit und Kosten gemeinsam prüfen

Aktualität über den gesamten Weg verfolgen

Verfolgen Sie ein eindeutig erkennbares fachliches Testereignis mit Zeitstempel: Entstehung in der Quelle, Aufnahme in Snowflake, erfolgreiche Transformation beziehungsweise Dynamic-Table-Aktualisierung, Importrefresh oder erneute DirectQuery-Abfrage und zuletzt die Anzeige im Bericht.

Wenn Sie beispielsweise höchstens 15 Minuten Datenalter verlangen, ist das eine eigene Beispielanforderung. Ein entsprechender Target-Lag-Wert erfüllt sie nicht automatisch. Auch ein DirectQuery-Bericht kann eine verspätete Pipeline abfragen oder ein älteres Ergebnis anzeigen. Messen Sie den tatsächlichen Weg unter normaler Last und bei Fehlern. Benennen Sie für jede stockende Stufe einen Verantwortlichen und eine Reaktion, statt Aktualisierungsintervalle zu einer garantierten Gesamtlatenz zu addieren.

Caches und Aggregationen unterscheiden

Der Warehouse-Datencache hält gelesene Tabellendaten und wird beim Suspendieren verworfen. Davon getrennt können persistierte Snowflake-Abfrageergebnisse unter bestimmten Bedingungen wiederverwendet werden; eine Wiederverwendung ist nicht für jede Anfrage garantiert. Hinzu kommen Power-BI-Caches und modellabhängige Aggregationen. Nicht jeder Klick führt deshalb zu einer neuen vollständig berechneten Snowflake-Abfrage.

Eine wichtige SSO-Grenze nennt Microsoft bei benutzerdefinierten Aggregationen: Bei SSO-aktivierten Datenquellen ignoriert Power BI Import-Aggregationstabellen wegen möglicher Sicherheitsrisiken. Planen Sie diese Kombination nicht als gesicherte Beschleunigung ein. Quellseitige Aggregate und andere Modellpfade sind gesondert zu bewerten. Überall müssen Aggregat- und Detailweg dieselben vorgesehenen Zeilengrenzen einhalten; ein bloß ausgeblendetes Feld ist keine Schutzregel.

Testen Sie die erzeugten Abfragen und die tatsächliche Parallelität. Prüfen Sie Query Folding, also welche Power-Query-Schritte zur Quelle weitergereicht werden, Beziehungen, Aggregationskörnung und die Zahl der Visuals je Seite. In Snowflakes QUERY_HISTORY helfen Nutzer, aktive Rolle, Warehouse und Query Tag bei der Zuordnung. Laufzeit sowie Wartezeiten wegen Bereitstellung oder Überlast zeigen unterschiedliche Engpässe. Vergleichen Sie diese Werte mit der Zeit, bis ein Betrachter den fertigen Bericht sieht.

Beide Plattformen in die Kosten aufnehmen

Auf Snowflake-Seite zählen die benötigten Warehouses, genutzte Serverless-Dienste und Speicher. Auf Power-BI-Seite hängen Benutzerlizenzen und Kapazität von der Bereitstellung und Nutzung ab. Microsoft beschreibt diese Unterscheidung in den Fabric-Lizenzgrundlagen. Eine funktionierende Connectorverbindung enthält keine pauschale Freigabe zum beliebigen Teilen von Berichten.

Kalkulieren Sie Nutzungsfrequenz, Refreshs, parallele Betrachter, Modellgröße und den Engineering-/Betriebsaufwand. DirectQuery ist nicht grundsätzlich günstiger als Import. Für den Abruf von Query-Ergebnissen durch Snowflake-Clients oder -Treiber nennt Snowflake zudem eine Egress-Ausnahme auch über Regions- oder Cloudgrenzen. Übertragen Sie Regeln für Exporte und Replikation deshalb nicht pauschal auf diesen Ergebnisabruf. Andere Datenwege und mögliche Fremdgebühren sind getrennt zu prüfen.

Verbindungsfehler nach Schichten eingrenzen

Beginnen Sie mit dem konkreten fehlschlagenden Schritt: Desktopanmeldung, Serviceverbindung, Nutzeranmeldung oder Datenabfrage. Halten Sie Zeitpunkt und Fehlercode fest. Schreiben Sie keine vollständigen Zugriffstoken oder Geheimnisse in Tickets und Diagnoseprotokolle.

Bei der Nutzersperre ist ein Detail wichtig: DISABLED = TRUE sperrt den Nutzer. Es beendet außerdem dessen laufende beziehungsweise geplante Statements. Es aktiviert den Zugang nicht. Maßgeblich ist die ALTER-USER-Referenz; eine Aufhebung gehört zur ausdrücklich berechtigten administrativen Entscheidung.

Für Anmeldeversuche kann ein berechtigter Untersucher die Information-Schema-Funktion verwenden. Der Datenbankname ist im folgenden Diagnosebeispiel fiktiv:

SELECT EVENT_TIMESTAMP, USER_NAME, FIRST_AUTHENTICATION_FACTOR,
       IS_SUCCESS, ERROR_CODE, ERROR_MESSAGE
FROM TABLE(DEMO_ANALYTICS.INFORMATION_SCHEMA.LOGIN_HISTORY(
    TIME_RANGE_START => DATEADD('hour', -1, CURRENT_TIMESTAMP()),
    TIME_RANGE_END => CURRENT_TIMESTAMP(),
    RESULT_LIMIT => 1000
))
ORDER BY EVENT_TIMESTAMP DESC;

LOGIN_HISTORY enthält Anmeldeversuche mit Erfolgs- und Fehlerfeldern, nicht nur erfolgreiche Logins. Die Funktion betrachtet die letzten sieben Tage und liefert nur die für die aktuelle Rolle sichtbaren Ereignisse. Ein Ergebnislimit kann bei viel Aktivität Treffer abschneiden; grenzen Sie den Zeitraum dann sinnvoll ein. Kein sichtbarer Eintrag allein beweist nicht, dass kein Versuch stattgefunden hat. Vergleichen Sie Nutzer, Authentifizierungsfaktor, Erfolg und Fehler mit dem betroffenen Power-BI-Vorgang.

Betrieb und Wiederanlauf übergeben

Vor breiter Nutzung sollten Tenant-/Identitätsverantwortliche, Snowflake-Team und Model Owner gemeinsam die positiven und negativen Rechteproben, Kennzahlen, Aktualität und Lastbefunde freigeben. Benennen Sie außerdem die Verantwortlichen für den fachlichen Datenstand und für die laufende Kostenbeobachtung beider Plattformen. Halten Sie fest, wer Fehler erkennt, wer reagiert und wer eine geänderte Verbindung veröffentlicht. Schulen Sie die Nutzergruppe zu Datenstand, erlaubten Detail- und Exportwegen und der Meldung unerwarteter Sichten.

Dokumentieren Sie auch den Wechsel von Schlüsseln oder technischen Identitäten sowie einen Rückfallweg: Welcher letzte bestätigte Modell-/Verbindungsstand kann wieder bereitgestellt werden, wer entscheidet darüber, und wie erkennen Nutzer zwischenzeitlich veraltete Daten? Eine neue Veröffentlichung ohne erneute Rechteprüfung ist kein ausreichender Wiederanlauf.

Snowflake unterstützt Client Redirect sowie Replikation und Failover/Failback einer External-OAuth-Security-Integration. Für einen geplanten Accountwechsel müssen dennoch Zielaccount, Datenobjekte, Rollen, Mapping, Netzwerk und Power-BI-Verbindung zusammen geprüft werden. Die Unterstützung der Integration allein belegt keine vollständige Ausfallsicherheit des Berichts.

Mit einer bestätigten Datenquelle, einem geklärten Identitätsweg und dokumentierten Sollsichten ist der nächste Umsetzungsschritt konkret. Die Snowflake-Beratung von eBiz kann Sie dabei unterstützen, Snowflake und die Microsoft-Integration in Ihre vorhandene Daten- und Betriebslandschaft einzuordnen.