Die automatisierte, Kein Code Datenstapel
Erfahren Sie, wie Astera Data Stack kann die Datenverwaltung Ihres Unternehmens vereinfachen und rationalisieren.
Daten in Fakten und Dimensionen laden – ein Kinderspiel?
Kimball-artige dimensionale Modellierung war in den letzten Jahrzehnten die bevorzugte Architektur für die meisten Data-Warehouse-Entwickler. Die denormalisierte Natur dieser Schemas in Verbindung mit der Optimierung für die Verlaufsverwaltung macht das dimensionale Modell zu einem idealen Werkzeug für das Data-Warehousing-Arsenal, insbesondere für die Berichterstellung Business Intelligence (BI)-Tools.
Auf den ersten Blick ist die Idee einfach: Faktentabellen enthalten Transaktionsinformationen, und Dimensionen stellen diese Fakten durch Fremdschlüsselbeziehungen in einen Kontext. Es stellen sich jedoch folgende Fragen: Wie einfach lassen sich Daten in Fakten- und Dimensionstabellen laden und pflegen? Und lohnt sich der Aufwand?
Nehmen wir ein Szenario, in dem Sie eine Architektur für Ihre eingerichtet haben Data Warehouse — ein einfaches Sternschema, bestehend aus Verkaufsinformationen in der Faktentabelle, umgeben von einigen Dimensionen wie Kunden, Lieferanten usw. Die anfänglich aus unterschiedlichen Systemen eingehenden Quelldaten wurden in eine einheitliche Staging-Schicht geladen.
Ziel ist es, einen Lade- und Pflegeprozess für Ihre Dimensions- und Faktentabellen einzurichten. Das Laden von Daten in Dimensionstabellen kann einfach sein, da Sie den Verlauf nicht pflegen möchten. In einem solchen Fall möchten Sie nur die Zieldatensätze aktualisieren, was über durchgeführt werden kann Abmessungen langsam ändern Typ 1 (SCD1). Hier ist ein Ausschnitt davon, wie diese Abfrage aussehen würde:
Es ist jedoch unwahrscheinlich, dass dies in einem praktischen Geschäftsszenario ausreichen würde. Es ist wichtig, zumindest einen gewissen Verlauf in einem Data Warehouse zu pflegen, um Trends und Muster zu erkennen. Hier kommen andere, kompliziertere SCD-Typen ins Spiel, wie SCD 2, 3 und 6.
Wenn Sie beabsichtigen, SCD 2 oder 6 für bestimmte Felder zu verwenden, muss die Tabelle auch Datensatzkennungen enthalten, um die aktive Zeile für jeden Datensatz zu erkennen. Dies könnte ein Wahr/Falsch-Flag, ein gültiger Ablaufdatumsbereich oder einfach eine Versionsnummer für jeden Datensatz sein, um nur einige Beispiele zu nennen.
Falls Sie SCD 3 oder 6 verwenden möchten, benötigen Sie ein zusätzliches Feld, um den vorherigen Wert des betreffenden Felds zu speichern.
So könnte ein Teil der Abfrage aussehen, wenn Sie SCD 2 oder 6 verwenden würden, um den Verlauf zu verwalten:
Fängt es an, etwas kompliziert auszusehen? Wir haben nur die Spitze des Eisbergs berührt.
Sie würden wahrscheinlich unterschiedliche Verlaufsebenen für verschiedene Felder benötigen. Nehmen wir beispielsweise an, dass Sie eine Mitarbeiterdimension haben, die die Gehaltsinformationen und Telefonnummern der Mitarbeiter enthält. Hier möchten Sie vielleicht verfolgen, wie sich das Gehalt eines Mitarbeiters ändert, aber aktualisieren Sie einfach die Telefonnummer.
In solchen Fällen würden Sie mehrere SCD-Typen verwenden; SCD 1 für die Felder, die lediglich Aktualisierungen erfordern, und SCD 2, 3 oder 6 für die Felder, für die ein gewisses Maß an Verlauf beibehalten werden muss. Bei so vielen zu berücksichtigenden Dingen können Sie sich vorstellen, wie komplex die Abfrage werden würde!
Bisher haben wir uns auf das Auffüllen und Pflegen von Dimensionstabellen konzentriert. Diese Dimensionen bieten Kontext zu den in Faktentabellen gespeicherten Informationen. Daher wird jede Änderung in einer Dimensionstabelle auch in die Faktentabelle übertragen; Sicherzustellen, dass diese Ausbreitung genau erfolgt, kann eine Herausforderung darstellen.
Einige der Informationen, die Sie in die Faktentabelle laden müssen, sind in der Quelle nicht verfügbar. Die Ersatzschlüssel, die zum Herstellen von Beziehungen zwischen Dimensions- und Faktentabellen verwendet werden, sind in der Staging-Schicht nicht vorhanden – sie wurden als vom System generierte Schlüssel in jeder Dimension erstellt.
Daher müssten Sie einen Mechanismus entwerfen, der Dimensionssuchen verwendet, um jeden eingehenden (natürlichen) Geschäftsschlüssel von der Staging-Schicht zur relevanten Dimension zu bringen und den aktiven Ersatzschlüssel für diesen Datensatz abzurufen. Darüber hinaus würden die Feinheiten beim Abrufen dieser Ersatzschlüssel je nach dem für jedes Feld verwendeten SCD-Typ und der in der Dimensionstabelle vorhandenen Zeilenkennung variieren.
Als ob dieser Prozess nicht komplex genug wäre, hier ist ein weiterer Curveball für Sie: Was ist, wenn Sie einige fehlende Einträge in der Faktentabelle haben, die nicht den aktuellsten Ersatzschlüssel erfordern? Sie könnten einen Transaktionsdatumsschlüssel verwenden, um den aktiven Ersatzschlüssel zu bestimmen, vorausgesetzt, Sie haben eine zeitstempelspezifische aktive Zeilenkennung verwendet, z. B. den Bereich des effektiven Ablaufdatums.
Die Situation könnte auch umgekehrt sein: Möglicherweise haben Sie einige Einträge in der Faktentabelle, die auf einen Dimensionsdatensatz verweisen, der noch nicht zur Dimensionstabelle hinzugefügt wurde. Dies ist ein häufiges Data-Warehousing-Problem – spät eintreffende Dimensionen und früh eintreffende Fakten. Um dieses Problem zu lösen, könnten Sie zur Laufzeit einen Dummy-Datensatz in der Dimensionstabelle erstellen.
Dieser Datensatz würde schließlich durch den entsprechenden (verzögerten) Dimensionsdatensatz ersetzt, der von der Quelle eingeht. Aber es würde zumindest ermöglichen, dass die Dimensionssuche zum richtigen Zeitpunkt ohne unnötige Schluckauf erfolgt.
Alles in allem kann das Laden von Daten in die Faktentabelle ein langwieriger und fehleranfälliger Prozess sein. Wenn die oben hervorgehobenen Probleme nicht behoben werden. Beispielsweise könnten Ihre Pipelines abstürzen oder Ihr Lager könnte am Ende ungenaue Daten enthalten.
Hier ist eine Beispielabfrage, die Daten in eine Faktentabelle laden könnte:
Nehmen wir an, Sie bekommen alles erledigt. Sie haben erfolgreich alle erforderlichen Abfragen eingegeben, und sie sind perfekt. Ihre Arbeit ist noch nicht ganz abgeschlossen. Ein Data-Warehousing-Prozess ist nie vollständig abgeschlossen, da die Pflege des Ökosystems genauso wichtig ist wie dessen Gestaltung. Um die Leistung zu maximieren, müssten Sie sicherstellen, dass die Daten inkrementell geladen werden, was die Implementierung des Change Data Capture (CDC)-Mechanismus erfordert.
Darüber hinaus müssten diese komplexen Abfragen abhängig von den Anforderungen des Unternehmens häufig aktualisiert werden. Möglicherweise müssen Sie Felder hinzufügen oder entfernen, bestimmte Datentypen ändern, den auf ein Feld angewendeten SCD-Typ ändern usw. Das Vornehmen dieser Änderungen an den Abfragen ist nicht nur zeitaufwändig, sondern auch äußerst fehleranfällig. Bevor Sie es wissen, haben Sie möglicherweise eine vorhandene Pipeline durcheinander gebracht, während Sie eine geringfügige Änderung im Lademechanismus implementiert haben.
Trotz dieser potenziellen Wartungsprobleme haben Sie immer noch das Gefühl, dass die meiste harte Arbeit erledigt ist. Unternehmen sind jedoch ständig bestrebt, ihre Datenprozesse zu modernisieren und zu verbessern. Der Tag könnte kommen, an dem Ihr Unternehmen beschließt, die Data-Warehouse-Plattform zu wechseln. Angenommen, sie haben sich entschieden, von einem lokalen SQL Server auf eine Cloud-Plattform wie z Schneeflocke or Amazon RedShift.
Ist dir klar, was das erfordern würde? Zuerst müssen Sie eine neue Architektur auf der neuen Plattform erstellen. Schreiben Sie dann alle Abfragen neu, um native Pipelines für die neuen Zieltabellen einzurichten. Sie müssten im Grunde den gesamten Prozess erneut durchführen – von Grund auf neu! Basierend auf allem, was wir entfaltet haben, kann man mit Sicherheit zu dem Schluss kommen, dass das Laden von Daten in Fakten- und Dimensionstabellen möglich ist NICHT ein Stück Kuchen. Selbst für technische Anwender kann die damit verbundene Komplexität zu hoch werden.
Aber was wäre, wenn ich Ihnen sagen würde, dass es einen viel einfacheren Weg gibt, dasselbe Ergebnis zu erzielen?
Mit der Astera Data Warehouse Builder, können Sie eine Architektur für Ihre erstellen dimensionales Modell mit dem intuitiven Datenmodell-Designer. Darüber hinaus können Sie über die Click-and-Point-Oberfläche Rollen wie SCD-Typen, aktive Zeilenkennungen, Transaktionsdatumsschlüssel usw. den Feldern in Fakten und Dimensionstabellen zuweisen.
Am wichtigsten ist, dass Sie die Informationen in Ihren Modellen in der Drag-and-Drop-basierten ETL/ELT-Komponente des Tools nutzen können, um die mühsamen und zeitaufwändigen Aufgaben zu automatisieren, die mit dem Laden von Fakten- und Dimensionstabellen verbunden sind – von der Pflege von SCDs in Dimensionen bis hin zur Durchführung Dimensionssuche in Faktentabellen. Der komplizierte Code, den wir zuvor gesehen haben, wird automatisch vom Tool generiert.
Warum so viel Zeit und Mühe auf das Schreiben riesiger Abfragen verschwenden, wenn Sie dasselbe Ergebnis mit einer einfachen visuellen Oberfläche erzielen können? Auch wenn das Laden von Daten in Fakten und Dimensionen normalerweise kein Kinderspiel ist, mit Astera Data Warehouse Builder, das kann sein!
Wenn Sie den agilen Weg zum Aufbau Ihres Data Warehouse erkunden möchten, erreichen Sie uns unter [E-Mail geschützt] heute oder laden Sie eine herunter 14-Tage kostenlose Testversion.
