Partitionen in tabellarischen Modellen

Gilt für: SQL Server Analysis Services Azure Analysis Services Fabric/Power BI Premium

Partitionen trennen Teile der Daten, die Sie häufig verarbeiten (aktualisieren) müssen, von Daten, die weniger häufig verarbeitet werden können. Beispielsweise kann eine Faktentabelle bestimmte Zeilensätze enthalten, die Daten enthalten, die sich selten ändern, aber andere Zeilensätze weisen Daten auf, die sich häufig ändern. Es ist nicht erforderlich, alle Daten zu verarbeiten, wenn nur ein Teil davon verarbeitet werden muss.

Bei Partitionen wird eine Tabelle in logische Partitionsobjekte unterteilt. Einzelne individuelle Partitionen können dann unabhängig von anderen Partitionen inkrementell nacheinander oder parallel verarbeitet oder ganz von der Verarbeitung ausgeschlossen werden.

Granularität

Standardmäßig verfügt jede Tabelle in einem Modell über eine einzelne Partition. In vielen Fällen, z. B. bei Faktentabellen, kann die Aufteilung der einzelnen Partition einer Tabelle in mehrere Partitionen die verfügbaren Ressourcen für die Verarbeitung besser nutzen.

Bei einer effektiven Modellentwurfs- und Verarbeitungsstrategie werden Partitionen verwendet, um unnötige Prozessorauslastung und Arbeitsspeicherverbrauch zu vermeiden, während gleichzeitig dafür sorgt, dass die Daten häufig genug aktualisiert werden, um die neuesten Daten aus Datenquellen widerzuspiegeln. Ein tabellarisches Modell kann beispielsweise über eine Tabelle Sales verfügen, die Umsatzdaten für das aktuelle Geschäftsjahr und jedes der vorherigen Geschäftsjahre enthält. Die Tabelle Sales des Modells enthält die folgenden Partitionen:

Da neue Umsatzdaten für das aktuelle Geschäftsjahr 2020 hinzugefügt werden, müssen diese Daten täglich verarbeitet werden, um in der Umsatzdatenanalyse des aktuellen Geschäftsjahrs genau widergespiegelt zu werden. Daher wird die Partition Sales2020 jeden Abend verarbeitet.

Es ist nicht erforderlich, die Daten in der Partition Sales2019-2010 nachts zu verarbeiten. Da sich die Umsatzdaten für die letzten zehn Geschäftsjahre aufgrund von Produktrückgängen und anderen Anpassungen jedoch noch ändern können, müssen sie weiterhin regelmäßig verarbeitet werden, daher werden die Daten in der Partition Sales2019-2010 monatlich verarbeitet. Daten in der SalesOld-Partition ändern sich selten, daher werden sie nur jährlich verarbeitet.

Beim Eintritt in das Geschäftsjahr 2021 wird der Tabelle Sales des Modells eine neue Sales2021-Partition hinzugefügt. Die Sales2020-Partition kann dann mit der Partition Sales2019-2010 zusammengeführt und in Sales2020-2011 umbenannt werden. Daten aus dem Geschäftsjahr 2010 werden aus der Partition Sales2020-2011 entfernt und in die Partition SalesOld verschoben. Alle Partitionen werden daraufhin verarbeitet, damit die Änderungen berücksichtigt werden. Dies wird allgemein als rollierendes Fenstermuster bezeichnet. Die Daten in jeder Partition liegen innerhalb eines vordefinierten Datumsbereichs und werden bei Bedarf erhöht, wodurch die Speicher- und Verarbeitungsressourcennutzung im Laufe der Zeit in einem vorhersagbaren Bereich bleibt.

Die Granularität wird von verschiedenen Faktoren beeinflusst, z. B., wie viele Daten innerhalb eines akzeptablen Zeitraums inkrementell verarbeitet werden müssen. Wenn beispielsweise nur der letzte ganze Tag täglich verarbeitet werden muss, kann es vorteilhaft sein, die tägliche Granularität zu verwenden. Die gemischte Granularität kann für Szenarien wie eine Nahezu-Echtzeit-Aktualisierung mit geringer Körnung in Verbindung mit historischen, statischen Partitionen mit höherer Granularität konfiguriert werden. Dies führt zu weniger Partitionen, erhöht aber auch den Verwaltungsaufwand, um sicherzustellen, dass Partitionsbereiche ordnungsgemäß definiert sind.

Die Partitionierung ist auch für Tabellen wirksam, die Daten aus mehr als einer Datenquelle enthalten. Verschiedene Datenquellen können Daten zu unterschiedlichen Zeiten aktualisieren, wodurch unterschiedliche Granularitäts- und Verarbeitungsanforderungen für die Tabellendaten des Modells bestimmt werden können. Beispielsweise enthält eine Orders-Tabelle in einem Modell Ordertransaktionen aus zwei verschiedenen Faktentabellen: factInternetOrders und factRetailOrders. An der Datenquelle wird factInternetOrders stündlich aktualisiert. factRetailOrders hingegen wird nur einmal täglich aktualisiert, nachdem alle Einzelhandelsgeschäfte geschlossen sind. Durch das Erstellen separater Partitionen mit unterschiedlichen Granularitäten in der Orders-Modelltabelle für Daten, die aus factInternetOrders und factRetailOrders importiert wurden, können Verarbeitungsvorgänge in der Tabelle Orders getrennt und inline mit Den Auftragsdaten in den Datenquellen ausgeführt werden.

Jedes Szenario ist eindeutig. Stellen Sie sicher, dass Sie eine Granularität für Ihr Datenmodell definieren, die Daten am effektivsten in Partitionen aufteilt, die häufig verarbeitet werden müssen, im Vergleich zu Partitionen, die nicht verarbeitet werden müssen.

Hub-Partitionen und Limits pro Partition

Unabhängig von der Plattform gibt es keine feste Beschränkung für die Anzahl von Partitionsobjekten in einem Modell. Jede Partition verfügt jedoch über mindestens ein Datensegment mit einem Speicherbedarf. Zu viele kleine Partitionen können zu übermäßig vielen kleinen Segmenten führen. Die Abfrageleistung kann beeinträchtigt werden, wenn die Speicher-Engine eine übermäßige Anzahl von Segmenten durchsuchen muss. Die Geschwindigkeit von Vorgängen mit Metadaten über zu viele Partitionen kann sich auch negativ auf die Ressourcen auswirken.

Erstellen Sie die Mindestanzahl von Partitionen, während Sie Ihre Partitionierungsziele effektiv erreichen. Es ist wichtiger, sich auf eine effektive Partitionierungsstrategie zu konzentrieren, die auf der Granularität basiert, und nur die Partitionen mit den relevantesten sich ändernden Daten innerhalb der verfügbaren Verarbeitungs- und Arbeitsspeicherressourcen zu Zeiten verarbeiten, in denen Benutzerabfragen gering sind.

Es gibt auch keine Beschränkung für die Datenmenge in einer Partition. Obwohl es unwahrscheinlich ist, könnte ein Modell über eine einzelne Tabelle mit einer einzelnen Standardpartition verfügen, und diese Tabelle könnte alle Daten im Modell enthalten. Die Datenmenge in der Partition wird nur durch verfügbare Speicherressourcen für den Dienstplan oder die Hardware begrenzt.

Erstellen und Verwalten von Partitionen

Beim Erstellen von Modellen mit dem Designer für tabellarische Modelle in Visual Studio erstellen Sie mithilfe des Partitions-Managers neue Partitionen, bearbeiten, zusammenführen oder löschen Partitionen in der Modellarbeitsbereichsdatenbank. Abhängig vom Kompatibilitätsgrad des Modells, das Sie erstellen, stellt der Partitions-Manager zwei Modi für die Auswahl von Daten bereit, die in einer Partition enthalten sein sollen: Für tabellarische Modelle mit 1400 und höher mit strukturierten Datenquellen werden Partitionen mithilfe eines Power Query M-Ausdrucks definiert. Die folgende Abfrage definiert beispielsweise eine Partition für das Kalenderjahr 2019:

let
    Source = #"SQL/sqlserver database windows net;Contoso",
    dbo_Sales = Source{[Schema="dbo",Item="Sales"]}[Data],
    #"Filtered Rows" = Table.SelectRows(dbo_Sales, each [OrderDateKey] >= 20190101 and [OrderDateKey] <= 20191231)
in
    #"Filtered Rows"

Für Anbieterdatenquellen werden Partitionen mithilfe einer SQL-Abfrage definiert. Beispiel:

SELECT [dbo].[Sales].* FROM [dbo].[Sales]
WHERE (([OrderDateKey] >= '20190101') AND ([OrderDateKey] <= '20191231'))

Beachten Sie, dass das Argument Gefilterte Zeilen im Power Query M-Ausdruck und die WHERE-Klausel in der SQL-Anweisung genau ein Kalenderjahr definieren, indem sie die Operatoren größer als (>), kleiner als (<) und gleich (=) verwenden. Beim Definieren von Partitionen ist es wichtig, dass die Abfrage jeder Partition einen eindeutigen Datenbereich definiert, der keine Datenduplizierung mit anderen Partitionen verursachen kann.

SQL Server Management Studio (SSMS)

Nach der Bereitstellung des Modells werden Partitionen als Objekte in SQL Server Management Studio (SSMS) angezeigt. Erstellen, bearbeiten, zusammenführen und löschen Sie Partitionen für ein bereitgestelltes Modell mithilfe des Dialogfelds Partitionen in SSMS, durch Ausführen eines TMSL-Skripts (Tabular Model Scripting Language) oder programmgesteuert mithilfe des tabellarischen Objektmodells (Tabular Object Model, TOM).

TMSL-Referenz (Tabular Model Scripting Language)

Partitionen für ein Modell werden im Partitions-Objekt definiert. Im folgenden Beispiel ist die Sales2019-Partition wie folgt definiert:

"partition": {
      "name": "Sales2019",
      "mode": "import",
      "source": {
        "type": "m",
        "expression": [
          "let",
          "    Source = #\"SQL/sqlserver database windows net;Contoso\",",
          "    dbo_Sales = Source{[Schema=\"dbo\",Item=\"Sales\"]}[Data],",
          "    #\"Filtered Rows\" = Table.SelectRows(dbo_Sales, each [OrderDateKey] >= 20190101 and [OrderDateKey] <= 20191231)",
          "in",
          "    #\"Filtered Rows\""
        ]
      },

Aktionen für das Partitions-Objekt können in den folgenden TMSL-Befehlen angegeben werden:

• Erstellen
• CreateOrReplace
• Ändern
• Löschen
• MergePartitions
• Aktualisieren

TMSL-Skripts können in SQL Server Management Studio ausgeführt werden, mit PowerShell, indem sie den Befehl Invoke-ASCmd oder einen SSIS-Skripttask (SQLServer Integration Services) ausführen.

Für Modelle mit Kompatibilitätsgraden 1100 und 1103 wird bei TMSL stattdessen die Analysis Services Scripting Language (ASSL) verwendet.

Tabellenobjektmodell (TOM)

Im tabellarischen Objektmodell werden Partitionen durch eine Partitionsklasse im Microsoft.AnalysisServices.Tabular-Namespace definiert. Weitere Informationen zu programmgesteuerten Lösungen, die TOM als API verwenden, finden Sie weiter unten in diesem Artikel unter Erstellen von Tabellen, Partitionen und Spalten (TOM) und Erweiterte Partitionierungsstrategien .

Verwenden Sie für Modelle mit den Kompatibilitätsgraden 1100 und 1103 Analysis Management Objects (AMO).

Verarbeitung von Partitionen

Wenn Tabellendaten partitioniert werden, können diese Partitionen zu einem Zeitpunkt und einem für Ihre Lösung geeigneten Rhythmus verarbeitet werden. Wenn ein Prozessvorgang (Aktualisierungsvorgang) ausgeführt wird, wird über die Datenquellenverbindung eine Verbindung mit der Datenquelle hergestellt. Analysis Services verwendet die für jede Partition angegebenen Abfragen, um die Datenquelle abzufragen. Neue und aktualisierte Daten werden in die Modelltabellen geladen, Beziehungen und Hierarchien werden neu erstellt und berechnete Spalten neu berechnet.

Beim Erstellen von Modellen in Visual Studio können Sie Prozessvorgänge für Arbeitsbereichsdatenbankpartitionen über das Menü oder die Symbolleiste manuell ausführen. Bei bereitgestellten Modellen werden Verarbeitungsvorgänge manuell mithilfe des Dialogfelds Tabellen verarbeiten in SSMS, durch Ausführen eines Skripts, das den Befehl Aktualisieren (TMSL) enthält, oder programmgesteuert mithilfe des Tabular Object Model (TOM) aufgerufen.

Parallelverarbeitung

Analysis Services nutzt die parallele Verarbeitung für zwei oder mehr Partitionen, wodurch die Verarbeitungsleistung erhöht wird. Für die Parallelverarbeitung gibt es keine Konfigurationseinstellungen. Die Parallelverarbeitung erfolgt standardmäßig, wenn Sie Die Tabelle verarbeiten oder mehrere Partitionen für dieselbe Tabelle und Prozess auswählen. Es gibt jedoch Einstellungen, die parallele Verarbeitungsvorgänge einschränken.

MaxConnections

Standardmäßig stellt jeder Verarbeitungsvorgang eine Verbindung mit einer Datenquelle für jede Partition her und fragt sie ab. Die standardmäßige maximale Anzahl von Verbindungen, die als MaxConnections-Eigenschaft für eine einzelne Datenquelle angegeben wird, beträgt 10. Analysis Services bestimmt die Anzahl der gleichzeitig auszuführenden Verarbeitungsvorgänge basierend auf der Anzahl der Kerne und verfügbaren Threads. Diese Threads werden auf dem serverübergreifenden instance gemeinsam genutzt. Ein einzelner Befehl wie ein Prozess empfängt möglicherweise nicht alle verfügbaren Threads. Die Threads, die für die Verarbeitung gestartet werden, einer für jeden parallelen Verarbeitungsvorgang, können verzögert werden, um innerhalb des MaxConnections-Grenzwerts zu bleiben.

MaxParallelism

Verarbeitungsvorgänge werden standardmäßig so weit wie möglich parallel ausgeführt. Sie können Partitionen jedoch sequenziell oder parallel verarbeiten, indem Sie die Option maxParallism-Eigenschaft mit dem Sequence-Befehl (TMSL) angeben. Das Festlegen des Werts auf 1 bedeutet nicht parallel – ein Thread wird für die Verarbeitung verwendet. Wenn Sie den Wert auf 2 oder mehr festlegen, wird eine feste Anzahl von Threads angegeben, die für parallele Verarbeitungsvorgänge verwendet werden können.

Monitor

Um die effektive Verwendung verfügbarer Threads während Prozessvorgängen zu ermitteln, verwenden Sie für Azure Analysis Services Azure Metrics Explorer, um CommandPoolIdleThreads und CommandPoolBusyThreads zu überwachen. Weitere Informationen finden Sie unter Überwachen von Servermetriken. Verwenden Sie für SQL Server Analysis Services Leistungsmonitor, um nicht E/A-Nicht-E/A-Threads im Verarbeitungspool im Leerlauf und nicht E/A-Nicht-E/A-Threads zu überwachen. Weitere Informationen finden Sie unter Leistungsindikatoren (SSAS).

Erweiterte Partitionierungsstrategien

Der Artikel Automatisierte Partitionsverwaltung für Analysis Services Tabular Models .pdf Artikel zusammen mit dem zugehörigen Codebeispiel AsPartitionProcessing in GitHub bietet sowohl ausführliche Informationen als auch ein Lösungsbeispiel für das fiktive Unternehmen Advenure Works, indem das tabellarische Objektmodell (TOM) zum Erstellen und Verwalten von Partitionen verwendet wird. Die in diesem Artikel und projekt beschriebenen Konzepte gelten für alle Analysis Services-Plattformen.

Weitere Informationen

Erstellen und Verwalten von Tabellenmodellpartitionen
Partitions-Objekt (TMSL)
Erstellen von Tabellen, Partitionen und Spalten mit dem tabellarischen Objektmodell (TOM)
Erstellen von Partitionen (Tutoriallektion)