Warum berechnete Spalten in Power BI die Berichtsleistung beeinträchtigen und den Modellspeicher aufblähen

Von Mirko Peters · 2026-10-29

Erfahren Sie, warum die übermäßige Nutzung berechneter Spalten in Power BI den Speicherbedarf des Modells aufbläht und die Berichtsleistung beeinträchtigt. Lernen Sie, wie Sie Ihre Datenmodellarchitektur optimieren.

Automatisch mit KI aus dem Originalbeitrag übersetzt. Englisches Original lesen

Eine falsche Verwendung berechneter Spalten in Power BI kann den Speicher Ihres Datenmodells unbemerkt aufblähen und die Renderingzeiten von Berichten verlängern. Anders als dynamische Measures werten berechnete Spalten bei jeder Datenaktualisierung jede einzelne Zeile aus und speichern sie. Dadurch verbrauchen sie wertvollen Arbeitsspeicher und erhöhen den Verarbeitungsaufwand in Ihrer Architektur im Arbeitsbereich.

Das Wichtigste in Kürze

• Berechnete Spalten ermitteln Werte zeilenweise bei der Datenaktualisierung und speichern sie dauerhaft im Speicher.
• Die übermäßige Nutzung berechneter Spalten verschlechtert das Komprimierungsverhältnis der VertiPaq-Engine erheblich und führt zu einer massiven Vergrößerung der Dateigröße.
• Der Zeilenkontext zwingt Berechnungen zu einer statischen Ausführung, wodurch Filterauswahlen von Benutzern auf Visualisierungen vollständig ignoriert werden.
• Datenmodelle mit übermäßig vielen Spalten lassen sich schlecht skalieren, insbesondere wenn sie in große Microsoft Fabric-Umgebungen eingebunden sind.
• Die Verlagerung der Logik von speicherintensiven Spalten zu Measures zur Abfragezeit schont den Arbeitsspeicher des Systems und optimiert die Berichtsleistung.

Die versteckten Speicherkosten der zeilenweisen Auswertung

Beim Erstellen eines neuen Berichts in Power BI verfällt man leicht in die Gewohnheit, für jeden neuen Datenpunkt eine berechnete Spalte anzulegen. Wenn Sie eine Gewinnmarge, einen zusammengefügten vollständigen Namen oder eine kategorisierte Gruppe für Ihre Verkaufszahlen benötigen, wirkt es intuitiv, direkt in der Tabelle eine Spalte anzulegen. Schließlich sehen Sie die Ergebnisse sofort in der Datenansicht, genau wie in einer Excel-Tabelle.

Power BI ist jedoch eine analytische Engine und keine Tabellenkalkulation. Jedes Mal, wenn Sie eine berechnete Spalte erstellen, weisen Sie die VertiPaq-Datenbank-Engine an, diesen Wert während der Datenaktualisierung für jede einzelne Zeile der Tabelle zu berechnen. Hat Ihre Verkaufstabelle fünf Millionen Zeilen, fügt Ihre neue berechnete Spalte dem semantischen Modell fünf Millionen einzelne Einträge hinzu.

Noch gravierender: Berechnete Spalten beeinträchtigen die Komprimierungsalgorithmen der Engine. VertiPaq stützt sich auf Spalten mit niedriger Kardinalität, also Spalten mit sich wiederholenden, doppelten Werten, um Daten effizient zu komprimieren. Eine eindeutige berechnete Spalte zerstört diese Effizienz häufig und vervielfacht den Arbeitsspeicher, der benötigt wird, um das Modell im Speicher zu halten. Mit wachsendem Modell kann dieser Speicherbedarf schnell die Kapazitätsgrenzen Ihres Arbeitsbereichs in der Microsoft-Cloud überschreiten.

Wie statischer Kontext Ihre Flexibilität bei der Berichterstellung einschränkt

Neben dem Speicherverbrauch bringen berechnete Spalten aufgrund ihrer Auswertungslogik erhebliche funktionale Einschränkungen mit sich. Eine berechnete Spalte arbeitet strikt innerhalb eines Zeilenkontexts. Sie wertet die aktuellen Zeilenwerte unabhängig von Benutzerinteraktionen, Datenschnitten oder gegenseitigen Filterungen auf Ihrer Berichtsfläche aus.

Wenn Sie eine berechnete Spalte anlegen, die Großkunden anhand eines festen Schwellenwerts markiert, wird diese Klassifizierung in der Speicherebene fest verankert. Wechselt ein Benutzer später einen Datenschnitt, um die Daten nach Region anzuzeigen, oder ändert er einen Datumsbereich, bleibt die berechnete Spalte von diesen Filtern unbeeindruckt. Sie kann sich nicht dynamisch an veränderte Aggregationszustände anpassen, weil ihr Wert bereits bei der letzten Aktualisierung gespeichert wurde.

Diese Starrheit steht im scharfen Gegensatz zu Measures, die Ergebnisse dynamisch berechnen, und zwar ausschließlich auf Basis des Filterkontexts, den der Benutzer genau in diesem Moment anwendet. Interagiert ein Benutzer mit einer Visualisierung, berechnet ein Measure die Werte neu und liefert präzise, kontextbezogene Erkenntnisse. Eine berechnete Spalte hingegen gibt lediglich die statischen Daten wieder, die im RAM gespeichert sind.

Schlankere Modelle für Microsoft Fabric und Azure entwerfen

Cloudbasiertes Reporting im Unternehmen erfordert hohe Effizienz, besonders bei der Skalierung über Microsoft Fabric, Azure und komplexe Microsoft 365-Datenbestände hinweg. Überladene semantische Modelle belasten die Infrastruktur, verlangsamen die Antwortzeiten von Abfragen und frustrieren Fachanwender, die auf das Laden von Dashboards warten.

Damit Ihre Berichte mit Höchstgeschwindigkeit laufen, beschränken Sie berechnete Spalten strikt auf Szenarien, in denen Werte auf Zeilenebene unbedingt erforderlich sind. Eine berechnete Spalte kann sich beispielsweise anbieten, wenn Sie einen Beziehungsschlüssel zwischen Tabellen auf Basis mehrerer Parameter festlegen müssen oder wenn der Wert in einem Datenschnitt oder in einer Regel für die zeilenbasierte Sicherheit (RLS) verwendet werden muss, wo Measures nicht zulässig sind.

Verlagern Sie alle übrigen analytischen Berechnungen – etwa Summen, Durchschnittswerte, Verhältnisse und bedingte Aggregationen – in Measures. Measures benötigen keinen Speicherplatz, weil sie keine Werte im Modell persistieren. Stattdessen liegen sie nur als Code im Arbeitsspeicher und werden erst ausgeführt, wenn eine Visualisierung die Daten anfordert. Dieser Ansatz schont den RAM, maximiert die Komprimierung und sorgt dafür, dass Ihre Cloud-Infrastruktur reibungslos läuft.

Fazit

Die grundlegenden Unterschiede zwischen Speicherung auf Zeilenebene und dynamischer Abfrageausführung zu verstehen, ist für alle wichtig, die skalierbare Analyselösungen entwickeln. Wenn Sie unnötige berechnete Spalten vermeiden und stattdessen auf die Leistungsfähigkeit dynamischer Measures setzen, verbessern Sie die Berichtsgeschwindigkeit deutlich und senken den Speicherverbrauch.

Um dieses Thema zu vertiefen und eine vollständige, verständliche Erklärung zu hören, wie die Engine Ihre Formeln verarbeitet, hören Sie sich die komplette Folge an. Bleiben Sie mit den Expertenbeiträgen im M365 FM Podcast auf dem Laufenden, wenn es um Ihre Strategie für Cloud-Analysen geht.

Häufige Fragen

Warum verbrauchen berechnete Spalten in Power BI so viel Speicher?

Berechnete Spalten werten bei jeder Datenaktualisierung jede einzelne Zeile aus und speichern diese Werte dauerhaft im RAM des Modells. Dadurch kann die VertiPaq-Engine die Daten nicht effektiv komprimieren, was schnell zu einem aufgeblähten Modell führt.

Benötigen Measures Speicherplatz in einem semantischen Power BI-Modell?

Nein, Measures benötigen keinen Speicherplatz. Sie werden lediglich als Formeldefinitionen in den Metadaten gespeichert und erst dann dynamisch berechnet, wenn eine Visualisierung oder eine Benutzerinteraktion die Berechnung anfordert.

Wann ist der Einsatz einer berechneten Spalte tatsächlich sinnvoll?

Berechnete Spalten sollten für Szenarien reserviert bleiben, in denen ein Zeilenkontext zwingend erforderlich ist, etwa zum Erstellen zusammengesetzter Schlüssel für Beziehungen, zum Anwenden von Regeln für die zeilenbasierte Sicherheit (RLS) oder zum Bereitstellen von Elementen, die als statische Datenschnittwerte erscheinen müssen.

Wie wirken sich berechnete Spalten auf die Leistung beim Rendern von Berichten aus?

Übermäßig viele berechnete Spalten vergrößern das gesamte semantische Modell und verschlechtern die Datenkomprimierung. Größere Modelle benötigen mehr Speicher und Rechenleistung, was letztlich die Abfrageausführung und die Ladezeiten der Berichte in Ihrem gesamten Arbeitsbereich verlangsamt.