Wird Ihr Power BI DAX zu lang, um es 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.
Die Data Warehouse Automation Plattform, der Datenteams aus vielen Branchen vertrauen
Kommt Ihnen das bekannt vor?
- Eine einzelne Kennzahl ist über hundert Zeilen lang und nur eine Person versteht sie.
- Visuals brauchen fünfzehn bis fünfundvierzig Sekunden, und es sind immer dieselben drei Kennzahlen.
- Eine Änderung an einer Kennzahl zerlegt still vier Visuals auf einer anderen Seite.
- Sie schreiben DAX, um herauszufinden, was ein Wert im März war, nicht was er heute ist.
Langes DAX ist selten ein DAX Problem. Es ist Struktur, die weiter oben gefehlt hat und nun zur Abfragezeit neu gebaut wird, bei jedem Klick.
Was die langen Kennzahlen tatsächlich tun
- Historie rekonstruieren.
CALCULATEmit Datumsfiltern als Ersatz für eine langsam veränderliche Dimension, die das Warehouse nie historisiert hat. - Many to many überbrücken. Iteratoren lösen eine Beziehung auf, für die es keine Bridge Tabelle gibt.
- Schlüssel nachbauen.
LOOKUPVALUEund zusammengesetzte Textspalten, weil es keinen Surrogatschlüssel zum Verknüpfen gibt. - Granularität korrigieren.
SUMXüber eine gefilterte Tabelle, weil die Faktentabelle zwei Granularitäten gleichzeitig enthält.
Alle vier laufen pro Visual, pro Filter, pro Nutzer. Das sind die fünfzehn bis fünfundvierzig Sekunden.
Warum es bei Ihnen landet
- Niemand hat das so gewollt. Jede Kennzahl war der kürzeste Weg zu einem funktionierenden Visual in dieser Woche.
- Außerhalb der
.pbixDatei ist die Logik unsichtbar, also weder prüfbar noch wiederverwendbar. - Sie können die Kennzahl umschreiben. Die fehlende Dimension können Sie nicht ergänzen.
Die Arbeit passiert am falschen Ort
- Historie, Schlüssel, Bridges und Granularität sind Warehouse Arbeit. In DAX werden sie bei jedem Klick neu gebaut.
- 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 Kosten und Dauer.
Was sich ändert, wenn das Modell fertig ankommt
Datavault Builder erzeugt Schlüssel, Historie und Granularität im Warehouse selbst, auf SQL Server, Azure SQL, Synapse, Fabric, Snowflake, Databricks oder BigQuery.
- Surrogatschlüssel sind explizit, Beziehungen damit echt, und
LOOKUPVALUEentfällt. - Point in Time Tabellen beantworten “wie sah es im März aus” als Join, nicht als Kennzahl.
- Bridge Tabellen lösen many to many auf, bevor Power BI davon erfährt.
- Eine Granularität pro Faktentabelle, damit
SUMbedeutet, was dort steht. - Kennzahlen schrumpfen auf
SUM,AVERAGE,COUNT. Kurz genug, dass eine Kollegin sie prüfen kann.
Worum Sie bitten sollten
“Diese Kennzahl baut die Historie zur Abfragezeit nach, weil die Dimension nicht historisiert ist. Können wir eine Point in Time Tabelle und echte Surrogatschlüssel im Warehouse bekommen, damit daraus ein einfaches SUM wird?”
Das benennt, was fehlt, statt nur einen schnelleren Report zu fordern.
Sehen Sie es 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 dasselbe?
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.
-
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.