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.
Die Data-Warehouse-Automationsplattform, der Datenteams aus vielen Branchen vertrauen
Kommt Ihnen das bekannt vor?
- Der nächtliche Refresh scheitert, und Sie hören es von der Person, die den Report um 08:00 Uhr geöffnet hat.
- Power Query meldet "nicht genügend Arbeitsspeicher" oder das Gateway läuft in einen Timeout, aber nie beim Testen.
- Ein Refresh, der im Januar vier Minuten brauchte, braucht im Oktober fünfzig. Am Report hat sich nichts geändert.
- Sie aktualisieren vor wichtigen Terminen manuell, weil Sie dem Zeitplan nicht mehr trauen.
Der Refresh scheitert nicht an fehlendem Arbeitsspeicher. Er scheitert, weil er Arbeit erledigt, die niemals zur Refresh-Zeit hätte stattfinden sollen.
Was bricht: Query Folding
- Wenn Query Folding für Ihren M-Code greift, schreibt Power Query ein einziges SQL-Statement und die Datenbank erledigt die Arbeit. Power BI empfängt nur das Ergebnis.
- Bricht das Query Folding ab, wird Power Query selbst zur Engine. Sie zieht Rohtabellen über das Netzwerk in den Arbeitsspeicher und rechnet dort.
- Der Bruch geschieht unbemerkt: ein Merge, eine berechnete Spalte, ein Fuzzy-Match, eine Indexspalte. Ohne Warnung.
- Es besteht jeden Test, weil Ihr Rechner nur eine kleine Tabelle abfragt. Dann wächst die Tabelle.
Warum es zu Ihrem Problem wird
- Diese Schritte existieren, weil ein Report geliefert werden musste. Die benötigte Dimension gab es nicht, oder eine zusätzliche Spalte bedeutete Wartezeit in Monaten.
- Die Logik steckt in der
.pbix-Datei, unsichtbar für alle weiter oben in der Kette. - Sie können den Report ändern. Das Data Warehouse können Sie nicht ändern.
Die Arbeit passiert am falschen Ort
- Merges, berechnete Spalten und Fuzzy-Matches sind Integrationsarbeit. In Power Query laufen sie bei jedem Refresh erneut.
- 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 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.
- Ihr M-Code wird zu
SELECT * FROM dim_kundeund ermöglicht damit per Definition Query Folding. - Kein Merge, kein Parsen, kein Fuzzy-Match. Diese Arbeit ist aus dem Report verschwunden.
- Refreshes laufen in Sekunden durch, und zwar planbar.
- Historisierung übernimmt das Warehouse als Vault-Satelliten, statt sie nur näherungsweise abzubilden.
- Die Logik erhält eine nachvollziehbare Lineage. “Woher kommt diese Zahl” hat damit eine sichtbare Antwort.
Worum Sie bitten sollten
Nicht “der Refresh scheitert dauernd”, sondern:
“In unseren Power-Query-Schritten greift das Query Folding nicht mehr, deshalb zieht der Refresh jede Nacht Rohtabellen in den Speicher. Können wir diese Daten als konforme Dimensionen und Faktentabelle im Warehouse bekommen, damit der Report sie nur noch liest?”
Falls die Antwort lautet, dass eine saubere Modellierung ein Quartal Entwicklungszeit kostet: genau diesen Einwand räumt Datavault Builder aus.
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
-
Bestehende Logik herauslösen
Sammeln Sie Berechnungen, Joins und Filter, die heute in Ihren Reports stecken.
-
An einem Ort zentralisieren
Die Logik kommt einmal ins Warehouse-Modell, und jeder Report liest dieselbe Definition.
-
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
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
Sales Director
Perfekt, wählen Sie einen passenden Termin:
Weitere Probleme in dieser Serie
-
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.
-
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.
-
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.