CiAgICA8IS0tIExpbmtlZEluIC0tPgogICAgPHNjcmlwdCB0eXBlPSJ0ZXh0L2phdmFzY3JpcHQiPgogICAgICAgIF9saW5rZWRpbl9wYXJ0bmVyX2lkID0gIjEyMzUwNzMiOwogICAgICAgIHdpbmRvdy5fbGlua2VkaW5fZGF0YV9wYXJ0bmVyX2lkcyA9IHdpbmRvdy5fbGlua2VkaW5fZGF0YV9wYXJ0bmVyX2lkcyB8fCBbXTsKICAgICAgICB3aW5kb3cuX2xpbmtlZGluX2RhdGFfcGFydG5lcl9pZHMucHVzaChfbGlua2VkaW5fcGFydG5lcl9pZCk7CiAgICA8L3NjcmlwdD48c2NyaXB0IHR5cGU9InRleHQvamF2YXNjcmlwdCI+CiAgICAgICAgKGZ1bmN0aW9uKCl7dmFyIHMgPSBkb2N1bWVudC5nZXRFbGVtZW50c0J5VGFnTmFtZSgic2NyaXB0IilbMF07CiAgICAgICAgICAgIHZhciBiID0gZG9jdW1lbnQuY3JlYXRlRWxlbWVudCgic2NyaXB0Iik7CiAgICAgICAgICAgIGIudHlwZSA9ICJ0ZXh0L2phdmFzY3JpcHQiO2IuYXN5bmMgPSB0cnVlOwogICAgICAgICAgICBiLnNyYyA9ICJodHRwczovL3NuYXAubGljZG4uY29tL2xpLmxtcy1hbmFseXRpY3MvaW5zaWdodC5taW4uanMiOwogICAgICAgICAgICBzLnBhcmVudE5vZGUuaW5zZXJ0QmVmb3JlKGIsIHMpO30pKCk7CiAgICA8L3NjcmlwdD4KICAgIDxub3NjcmlwdD4KICAgICAgICA8aW1nIGhlaWdodD0iMSIgd2lkdGg9IjEiIHN0eWxlPSJkaXNwbGF5Om5vbmU7IiBhbHQ9IiIgc3JjPSJodHRwczovL3B4LmFkcy5saW5rZWRpbi5jb20vY29sbGVjdC8/cGlkPTEyMzUwNzMmZm10PWdpZiIgLz4KICAgIDwvbm9zY3JpcHQ+CiAgICA8IS0tIEVuZCBMaW5rZWRJbiAtLT4KICAgIA==
Generic filters
Exact matches only
Search in title
Search in excerpt
Search in content

Dynamische Partitionierung

Bei großen Datenmengen und daraus resultierenden langen Ladevorgängen, empfiehlt es sich, Partitionen zu nutzen. Ein typisches Vorgehen ist z. B. die Partitionierung nach Jahren. Dabei werden täglich nur die Daten des aktuellen Jahres neu geladen. Dieser Ladevorgang kann jedoch im Laufe des Jahres verlängern, obwohl die Daten der vergangenen Monate sich kaum ändern. Außerdem kann es sein, dass die Anzahl der Partitionen durch die eingesetzte SQL Server Version (SQL Server Standard Edition) begrenzt ist. Wenn im System mehr als drei Jahre vorhanden sind, ist somit keine Partitionierung pro Jahr mehr möglich. Eine dynamische Partitionierung kann für die oben genannten Fälle die Lösung sein. Hierbei wird eine feste Anzahl von Partitionen definiert, deren Zeiträume aber dynamisch sind.

Bei großen Datenmengen und daraus resultierenden langen Ladevorgängen, empfiehlt es sich, Partitionen zu nutzen. Ein typisches Vorgehen ist z. B. die Partitionierung nach Jahren. Dabei werden täglich nur die Daten des aktuellen Jahres neu geladen. Dieser Ladevorgang kann sich jedoch im Laufe des Jahres verlängern, obwohl die Daten der vergangenen Monate sich kaum ändern. Außerdem kann es sein, dass die Anzahl der Partitionen durch die eingesetzte SQL Server Version (SQL Server Standard Edition) begrenzt ist. Wenn im System mehr als drei Jahre vorhanden sind, ist somit keine Partitionierung pro Jahr mehr möglich. Eine dynamische Partitionierung kann für die oben genannten Fälle die Lösung sein. Hierbei wird eine feste Anzahl von Partitionen definiert, deren Zeiträume aber dynamisch sind.
Die Umsetzung einer dynamischen Partitionierung wird anhand des folgenden Szenarios erklärt.

Szenario

Als erstes wird eine MeasureGroup mit drei Partitionen definiert, welche die Daten von folgenden Zeiträumen enthält:

  • Partition 1: Daten der vergangenen Jahre
  • Partition 2: Daten der vergangenen Monate im aktuellen Jahr
  • Partition 3: Daten des aktuellen Monats

Abbildung 1: Partitionen

Die Befüllung der Partitionen wird durch die DeltaMaster ETL- Flags DoDeleteTable und DoFillTable gesteuert. Es ist bei unserem Szenario definiert, dass sich die Daten bei jedem Jahres- und Monatsanfang von einer Partition zu anderen bewegen müssen. Hier wäre ein manuelles Setzen der Flags unpraktikabel.

Aktivierung/Deaktivierung der Partitionen

Die Aktivierung bzw. Deaktivierung der Partitionen wird durch das Setzen der Flags DoDeleteTable und DoFillTable realisiert. Dieses soll automatisch in Abhängigkeit des Datenladedatums erfolgen. Die Logik dafür wird zunächst dargestellt:

1)  Initialisierung: Hier werden alle Partitionen zuerst deaktiviert. Dazu werden die Flags für alle Partitionen auf „0“ gesetzt.

2)  Variablen: Für weitere Schritte werden das Datum des letzten Datensatzes aus der ersten und zweiten Partition in Variablen gespeichert.

3)  Prüfung erste Partition: Wenn der letzte Datensatz nicht zum letzten Jahr gehört, müssen alle Partitionen geladen werden.

4)  Prüfung zweite Partition: Wenn der letzte Datensatz nicht zum letzten Monat gehört, müssen die zweite und dritte Partition geladen werden.

5)  Aktivierung dritte Partition: In allen anderen Fällen soll nur die dritte Partition geladen werden.

Alle Schritte werden in einer Prozedur zusammengefasst, die wiederum in der PreProcess Prozedur aufgerufen wird. Optional kann noch ein zusätzlicher Schritt für einen kompletten Ladevorgang am Wochenende hinzugefügt werden. Damit werden zum Beispiel Korrekturen in vergangenen Jahren bzw. Monaten übernommen. Dafür kann folgender Code verwendet werden:

Weitere Szenarien

Die dynamische Partitionierung kann auch ohne die Beschränkung auf drei Partitionen genutzt wer-den.
Liegen z. B. Daten ab dem Jahr 2014 vor, werden die Daten von 2014 bis 2016 in jeweils eigenen Partitionen gespeichert. Das aktuelle Jahr 2017 wird aber über zwei Partitionen verteilt.

  • Partition 1: Daten von 2014
  • Partition 2: Daten von 2015
  • Partition 3: Daten von 2016
  • Partition 4: Daten von 2017 ohne den aktuellen Monat
  • Partition 5: Daten des aktuellen Monats

In diesem Fall sollen für die dynamische Aktivierung/Deaktivierung der Partitionen nur die Partitionen 4 und 5 berücksichtigt werden. Ein vollständiges Laden der Daten von 2017 kann ebenso am Wochenende erfolgen.
Mit diesem Ansatz erreichen wir, dass die Dauer der täglichen Ladevorgänge im Laufe des Jahres konstant bleibt.