Ist Ihr Power-BI-DirectQuery-Report bei jedem Klick langsam?

DirectQuery und Direct Lake versprechen Live-Daten. Was ankommt, ist ein Visual nach dreißig Sekunden und eine Compute-Rechnung, die niemand erklären möchte. Nicht der Modus ist das Problem, sondern das Schema darunter.

Ist Ihr Power-BI-DirectQuery-Report bei jedem Klick langsam?

Die Data-Warehouse-Automationsplattform, der Datenteams aus vielen Branchen vertrauen

Kommt Ihnen das bekannt vor?

  • Jeder Filterklick löst eine neue Abfragewelle aus und die Visuals kriechen.
  • Die Compute-Kosten in Synapse oder Fabric sind in dem Monat gestiegen, in dem das Dashboard live ging.
  • Direct Lake fällt auf DirectQuery zurück und niemand kann genau sagen, warum.
  • Derselbe Report ist im Import-Modus schnell, also nutzen Sie Import und verlieren die Live-Daten.

DirectQuery tut genau das, was der Name sagt: Es übersetzt jede Interaktion in SQL gegen Ihre Datenbank. Ob das schnell ist, hängt vollständig davon ab, worauf es trifft.

Was DirectQuery erzeugt

  • Gegen ein Star-Schema: eine Faktentabelle, ein paar Dimensions-Joins auf echten Schlüsseln. Die Datenbank antwortet in Millisekunden.
  • Gegen 3NF oder rohe Lake-Tabellen: tief verschachtelte Joins über ein Dutzend Tabellen, neu gebaut für jedes Visual und jeden Klick.
  • Kein Pushdown, auf den man sich stützen kann. Ohne Partitionierung und Indizes bedeutet jede Abfrage einen vollen Scan.
  • Der Fallback geschieht unbemerkt. Direct Lake wechselt stillschweigend zu DirectQuery, sobald die Quelle nicht die erwartete Struktur hat. Genau dann entstehen die Kosten.

Multipliziert mit den Visuals einer Seite, dann mit gleichzeitigen Nutzern. Das ist die Rechnung.

Warum es zu Ihrem Problem wird

  • Das Warehouse hat bereitgestellt, was vorhanden war: operative Tabellen, keine analytischen.
  • Der Import-Modus ist der Workaround, und er kostet genau die Live-Daten, wegen derer Sie DirectQuery gewählt haben.
  • Sie können Visuals optimieren. Die Quelle neu partitionieren können Sie nicht.

Die Arbeit passiert am falschen Ort

  • Tabellen für die Analyse zu strukturieren ist Warehouse-Arbeit. DirectQuery kann das nicht, also bezahlt jeder Klick für die fehlende Struktur.
  • Sie gehört an einen zentralen Ort: ein Data Warehouse oder einen Data Hub, einmal gebaut und von jedem Report gelesen.
  • Wenn das teuer klingt, geht die Schätzung vermutlich von handgebauten Pipelines aus. Eine spezialisierte Automatisierungsplattform generiert sie aus einem Modell. Das ändert sowohl die Kosten als auch die Dauer.

Was sich ändert, wenn das Modell fertig geliefert wird

Datavault Builder erzeugt dimensionale Modelle nativ in der Zielplattform, materialisiert oder virtualisiert, gebaut für analytischen Pushdown statt für transaktionalen Zugriff.

  • Eine Faktentabelle, echte Dimensionen. Das erzeugte SQL ist schon von der Struktur her kurz.
  • Partitioniert und geclustert nach den Spalten, nach denen tatsächlich gefiltert wird.
  • Direct Lake bleibt Direct Lake, weil die Tabellen bereits die passende Struktur haben.
  • Der Compute-Verbrauch sinkt, weil jeder Klick ein schlankes Modell scannt statt der Rohschicht.
  • Live-Daten sind kein Handel mehr gegen Geschwindigkeit.

Worum Sie bitten sollten

“DirectQuery führt bei jedem Klick Joins über normalisierte Tabellen aus, deshalb skalieren die Compute-Kosten mit der Nutzerzahl. Können wir für diesen Report ein partitioniertes Star-Schema bereitstellen, das er stattdessen abfragt?”

Konkret genug, um es zu schätzen, und es zeigt auf die Schicht, in die der Fix gehört.

Erleben Sie es live mit Ihren eigenen Daten

Buchen Sie eine kostenlose Demo und bringen Sie den Report mit, der Ihnen die meisten Probleme macht.

In drei Schritten zu Zahlen, die aufgehen

  1. Bestehende Logik herauslösen

    Sammeln Sie Berechnungen, Joins und Filter, die heute in Ihren Reports stecken.

  2. An einem Ort zentralisieren

    Die Logik kommt einmal ins Warehouse-Modell, und jeder Report liest dieselbe Definition.

  3. Zahlen, die aufgehen

    Jeder Report zeigt dieselbe Zahl, und “Woher kommt diese Zahl” hat eine sichtbare Antwort.

Wie Datavault Builder Ihrem Report ein fertiges Modell liefert

  • Das Modell kommt fertig an

    Datavault Builder generiert Vault und Star-Schema so, dass sie nativ in der Datenbank laufen, die Sie bereits haben: SQL Server, Azure SQL, Synapse, Fabric, Snowflake, Databricks oder BigQuery.

  • Die Arbeit verlässt den Report

    Kein Merge, kein Parsen, kein Fuzzy Match. Diese Arbeit ist aus dem Report verschwunden.

  • Quellen kommen integriert an

    Kunden aus ERP, CRM und Webshop werden zu einem Satz konformer Dimensionen zusammengeführt. Der Join passiert einmal im Warehouse, nicht erneut in jedem Report.

  • Historie, die abfragbar ist

    Jede Änderung wird so festgehalten, wie sie eintrifft. Sie können den Stand von damals genauso auswerten wie den von heute, auch wenn das Quellsystem seine eigenen Sätze überschreibt.

  • Jede Zahl hat Lineage

    Die Logik bekommt Lineage. “Woher kommt diese Zahl” hat damit eine sichtbare Antwort.

  • Historisierung im Warehouse

    Historisierung übernimmt das Warehouse als Vault-Satelliten, statt sie zu approximieren.

Kundengeschichte: Porta

Next Generation BI — ein Single Point of Truth auf Snowflake. Bis zu 200 KPIs pro Abteilung in Power BI bereitgestellt.
Case Study lesen

Ausgezeichnet von BARC im Data Fabric Survey 26

Sprechen Sie mit unserem Experten

Zwanzig Minuten mit unserem Sales Director und eine ehrliche Antwort, ob das zu Ihrer Situation passt.

Matt Collett

Matt Collett

Sales Director

Was suchen Sie?

Mit dem Absenden stimmen Sie unserer Datenschutzerklärung.

Weitere Probleme in dieser Serie

  • Dataset-Wildwuchs

    Zeigen Ihre Power-BI-Reports unterschiedliche Zahlen für denselben Sachverhalt?

    Finance, Sales und Operations haben jeweils ihr eigenes semantisches Modell gebaut, und jedes ist in sich stimmig. Die Definitionen waren nirgends falsch. Sie wurden nirgends abgestimmt.

  • DAX-Komplexität

    Wird Ihr Power-BI-DAX zu lang, um ihn noch zu pflegen?

    Zweihundert Zeilen CALCULATE und FILTER sind kein Zeichen für fortgeschrittenes DAX. Meist sind sie ein Zeichen dafür, dass das Warehouse nie die Schlüssel, die Historie oder die Granularität geliefert hat.

  • Fehlgeschlagene Refreshes

    Scheitert Ihr Power-BI-Refresh nachts immer wieder?

    Der geplante Refresh läuft in einen Timeout, Power Query geht der Speicher aus, und Sie erfahren davon, wenn jemand das Dashboard öffnet. Die Ursache ist fast nie Power BI. Es ist das, was Power BI tun soll.