🥇Überblick über agile DWH-Designmethodologien

Die Entwicklung eines Data Warehouses ist eine langwierige und ernsthafte Angelegenheit.

Vieles im Leben eines Projekts hängt davon ab, wie gut das objektspezifische Modell und die Datenbankstruktur zu Beginn durchdacht sind.

Allgemein wurden und werden verschiedene Varianten der Kombination des "Sternschemas" mit der dritten Normalform verwendet. In der Regel nach dem Prinzip: Ausgangsdaten — 3NF, Data Marts — Stern. Dieser Ansatz, der sich über die Zeit bewährt hat und durch zahlreiche Studien untermauert wird, ist das Erste (und manchmal das Einzige), was einem erfahrenen DWH-Entwickler in den Sinn kommt, wenn es darum geht, wie ein analytisches Data Warehouse aussehen sollte.

Auf der anderen Seite neigt das Geschäft insgesamt und die Anforderungen der Kunden im Besonderen dazu, sich schnell zu ändern, während die Daten sowohl "in die Tiefe" als auch "in die Breite" wachsen. Und hier zeigt sich der Hauptnachteil des Sternschemas: die begrenzte Flexibilität.

Und wenn plötzlich in Ihrem ruhigen und gemütlichen Leben als DWH-Entwickler:

die Aufgabe auftaucht, "schnell irgendetwas zu machen, und dann schauen wir weiter";
ein rasant wachsendes Projekt mit der Anbindung neuer Quellen und der Umgestaltung des Geschäftsmodells mindestens einmal pro Woche erscheint;
ein Kunde auftritt, der sich nicht vorstellen kann, wie das System aussehen und welche Funktionen es letztendlich ausführen sollte, aber bereit ist, mit Experimenten zu arbeiten und schrittweise den gewünschten Erfolg konkret zu präzisieren;
ein Projektmanager mit der frohen Botschaft vorbeischaut: "Und jetzt haben wir Agile!".

Oder wenn Sie einfach nur neugierig sind, wie man Data Warehouses sonst noch bauen kann — willkommen unter dem Cut!

Was bedeutet "Flexibilität"

Zunächst sollten wir klären, über welche Eigenschaften ein System verfügen muss, damit man es als "flexibel" bezeichnen kann.

Es ist wichtig zu betonen, dass die beschriebenen Eigenschaften sich gerade auf das System, und nicht auf den Prozess seiner Entwicklung beziehen. Daher, wenn Sie darüber lesen wollten, wie Agile als Entwicklungsmethodik funktioniert, ist es besser, sich mit anderen Artikeln vertraut zu machen. Zum Beispiel gibt es auf Habr eine Vielzahl interessanter Materialien (sowohl übersichtlicher und praktischer, als auch problemorientierter Art).).

Das bedeutet jedoch nicht, dass der Entwicklungsprozess und die Struktur des DWH überhaupt nicht miteinander verbunden sind. Im Allgemeinen sollte die Entwicklung eines flexiblen Architektur-Data Warehouses nach Agile erheblich einfacher sein. In der Praxis treten jedoch häufiger Varianten auf, bei denen ein klassisches DWH nach Kimball und Data Vault nach dem Wasserfallmodell entwickelt wird, als glückliche Zufälle der Flexibilität in ihren beiden Ausprägungen in einem Projekt zu finden.

Welche Möglichkeiten sollte ein flexibles Data Warehouse also bieten? Hier können drei Punkte hervorgehoben werden:

Frühe Lieferung und schnelle Nachbearbeitung — das bedeutet, dass im Idealfall das erste Geschäftsergebnis (zum Beispiel die ersten funktionierenden Berichte) so früh wie möglich erzielt werden sollte, also noch bevor das gesamte System vollständig konzipiert und implementiert ist. Dabei sollte auch jede nachfolgende Nachbearbeitung möglichst wenig Zeit in Anspruch nehmen.
Iterative Nachbearbeitung — das bedeutet, dass jede nachfolgende Nachbearbeitung idealerweise nicht den bereits funktionierenden Funktionsumfang beeinträchtigen sollte. Genau dieser Punkt wird häufig zum größten Albtraum bei großen Projekten — früh oder spät beginnen einzelne Objekte eine solche Vielzahl von Beziehungen zu entwickeln, dass es einfacher wird, die Logik in einer Kopie daneben vollständig zu wiederholen, als ein Feld in eine bestehende Tabelle hinzuzufügen. Und wenn Sie überrascht sind, dass die Analyse der Auswirkungen einer Nachbearbeitung auf bestehende Objekte mehr Zeit in Anspruch nehmen kann als die Nachbearbeitung selbst — dann haben Sie wahrscheinlich noch nicht mit großen DWHs in der Banken- oder Telekommunikationsbranche gearbeitet.
Ständige Anpassung an sich ändernde Geschäftsanforderungen — die gesamte objektorientierte Struktur sollte nicht nur mit Blick auf eine mögliche Erweiterung entworfen werden, sondern so, dass die Richtung dieser nächsten Erweiterung einem während der Planungsphase nicht einmal in den Sinn kommen konnte.

Und ja, die Einhaltung all dieser Anforderungen in einem System ist möglich (natürlich in bestimmten Fällen und mit einigen Vorbehalten).

Im Folgenden werde ich die zwei beliebtesten Methodiken für die flexible Gestaltung von DWH betrachten — Anchor Model und Data Vault. Hinter den Kulissen bleiben so schöne Ansätze wie zum Beispiel EAV, 6NF (im reinen Sinne) und alles, was mit NoSQL-Lösungen zu tun hat — nicht weil sie in irgendeiner Weise schlechter wären, und auch nicht weil dieser Artikel sonst das Volumen einer durchschnittlichen Dissertation angenommen hätte. Es handelt sich einfach um Lösungen einer etwas anderen Klasse — entweder um Ansätze, die Sie in spezifischen Fällen anwenden können, unabhängig von der Gesamtarchitektur Ihres Projekts (wie EAV), oder um grundlegend andere Paradigmen zur Speicherung von Informationen (wie etwa Graphdatenbanken und andere NoSQL-Varianten).

Die Probleme des „klassischen“ Ansatzes und ihre Lösungen in flexiblen Methoden

Unter dem „klassischen“ Ansatz verstehe ich den guten alten Stern (unabhängig von der konkreten Implementierung der darunterliegenden Schichten, mögen mir die Anhänger von Kimball, Inmon und CDM verzeihen).

1. Strenge Kardinalität von Beziehungen

Der Grundlage eines solchen Modells liegt eine klare Trennung der Daten zugrunde in Dimensionen (Dimension) und Fakten (Fact). Und das ist, verdammtes noch mal, logisch — denn die Datenanalyse beschränkt sich in überwiegendem Maße именно auf die Analyse bestimmter quantitativer Indikatoren (Fakten) in bestimmten Dimensionen.

Dabei werden die Beziehungen zwischen den Objekten in Form von Verbindungen zwischen Tabellen über einen Fremdschlüssel angelegt. Das sieht ganz natürlich aus, führt aber sofort zur ersten Einschränkung der Flexibilität — der strengen Definition der Kardinalität von Beziehungen..

Das bedeutet, dass Sie in der Entwurfsphase der Tabellen genau festlegen müssen, ob jede Paarung von verbundenen Objekten eine n:m- oder eine 1:n-Beziehung und in „welcher Richtung“ hat. Dies hängt direkt davon ab, in welcher der Tabellen der Primärschlüssel und in welcher der Fremdschlüssel sein wird. Eine Änderung dieser Beziehung bei neuen Anforderungen wird mit hoher Wahrscheinlichkeit eine Überarbeitung der Datenbank nach sich ziehen.

Zum Beispiel haben Sie beim Entwurf des Objekts „Kassenzettel“ basierend auf den feierlichen Versprechungen der Verkaufsabteilung die Möglichkeit einer einzelnen Werbeaktion auf mehrere Kassenzettelposten (aber nicht umgekehrt) eingeplant:

Nach einiger Zeit hat das Team eine neue Marketingstrategie eingeführt, bei der mehrere Werbeaktionen gleichzeitig auf denselben Artikel wirken können. . Und jetzt müssen Sie die Tabellen nachbearbeiten, indem Sie die Beziehung in ein separates Objekt auslagern..

(Alle abgeleiteten Objekte, in denen ein Join-Check für die Promotion stattfindet, müssen jetzt ebenfalls überarbeitet werden).

Beziehungen im Data Vault und im Anchor Model

Es stellte sich als recht einfach heraus, eine solche Situation zu vermeiden: Man muss der Verkaufsabteilung dafür nicht vertrauen. Alle Beziehungen sollten ursprünglich in separaten Tabellen gespeichert werden und als viele-zu-viele verarbeitet werden.

Dieser Ansatz wurde vorgeschlagen von Dan Linstedt als Teil der Paradigmen Data Vault und wurde vollständig unterstützt von Lars Rönnbäck in des Anchor Models.

Am Ende erhalten wir das erste Unterscheidungsmerkmal flexibler Methoden:

Die Beziehungen zwischen den Objekten werden nicht in den Attributen der übergeordneten Entitäten gespeichert, sondern stellen einen eigenen Objekttyp dar.

Im Data Vault Solche Verknüpfungstabellen werden genannt Link, sondern in Anchor Model — Tie. Auf den ersten Blick sehen sie sehr ähnlich aus, obwohl ihre Unterschiede nicht nur im Namen bestehen (worüber später die Rede sein wird). In beiden Architekturen können Verknüpfungstabellen beliebige Anzahl von Entitäten (nicht zwingend 2) verbinden.

Diese vermeintliche Redundanz bietet erhebliche Flexibilität bei der Überarbeitung. Diese Struktur wird nicht nur tolerant gegenüber Änderungen der Kardinalitäten bestehender Beziehungen, sondern auch gegenüber der Hinzufügung neuer — wenn jetzt ein zu verknüpfender Artikel auch einen Bezug zu dem Kassierer hat, der ihn erstellt hat, wird diese Verknüpfung einfach eine Erweiterung der bestehenden Tabellen sein, ohne Einfluss auf bestehende Objekte und Prozesse zu nehmen.

2. Daten-Duplikation

Das zweite Problem, das durch flexible Architekturen gelöst wird, ist weniger offensichtlich und betrifft in erster Linie Dimensionen des Typs SCD2 (langsam ändernde Dimensionen zweiter Art), obwohl nicht nur diese.

In einem klassischen Data Warehouse stellt eine Dimension normalerweise eine Tabelle dar, die einen Surrogatschlüssel (als PK) sowie eine Reihe von Geschäftsschlüsseln und Attributen in separaten Spalten enthält.

Wenn die Dimension Versionierung unterstützt, werden zu dem Standardfeldsatz Zeitgrenzen für die Gültigkeit der Version hinzugefügt, und für jede Zeile in der Quelle gibt es mehrere Versionen im Data Warehouse (eine für jede Änderung der versionierten Attribute).

Wenn eine Dimension mindestens ein häufig sich änderndes versioniertes Attribut enthält, wird die Anzahl der Versionen dieser Dimension erheblich sein (selbst wenn die anderen Attribute nicht versioniert sind oder sich nie ändern). Wenn es solch mehrere Attribute gibt, kann die Anzahl der Versionen geometrisch mit ihrer Anzahl wachsen. Eine solche Dimension kann erheblichen Speicherplatz in Anspruch nehmen, obwohl der Großteil der darin gespeicherten Daten einfach Duplikate von Werten unveränderlicher Attribute aus anderen Zeilen sind.

Dabei wird sehr oft auch noch Denormalisierung — Teile der Attribute werden absichtlich als Werte gespeichert, anstatt als Verweis auf ein Verzeichnis oder eine andere Dimension. Dieser Ansatz beschleunigt den Datenzugriff, indem die Anzahl der Joins beim Zugriff auf die Dimension verringert wird.

In der Regel führt dies dazu, dass die gleichen Informationen gleichzeitig an mehreren Orten gespeichert werden. Beispielsweise können Informationen über den Wohnort und die Zugehörigkeit zur Kundenkategorie gleichzeitig in den Dimensionen "Kunde" sowie in den Fakten "Kauf", "Lieferung" und "Anrufe beim Callcenter" gespeichert werden, ebenso wie in der Verknüpfungstabelle "Kunde — Kundenbetreuer".

Insgesamt trifft das oben Beschriebene auch auf gewöhnliche (nicht versionierte) Dimensionen zu, jedoch kann dies bei versionierten Dimensionen einen anderen Umfang haben: Das Erscheinen einer neuen Version eines Objekts (insbesondere rückblickend) führt nicht nur zur Aktualisierung aller verbundenen Tabellen, sondern zu einer kaskadenartigen Erstellung neuer Versionen verbundener Objekte — wenn Tabelle 1 beim Erstellen von Tabelle 2 verwendet wird und Tabelle 2 beim Erstellen von Tabelle 3, usw. Selbst wenn kein Attribut aus Tabelle 1 beim Erstellen von Tabelle 3 verwendet wird (sondern andere Attribute aus Tabelle 2, die aus anderen Quellen stammen), führt das versionierte Update dieser Struktur zumindest zu zusätzlichen Overheadkosten und möglicherweise zu unnötigen Versionen in Tabelle 3, die in diesem Fall völlig "unbeteiligt" ist, und weiter entlang der Kette.

3. Nichtlineare Komplexität der Überarbeitung

Dabei erhöht jede neue Sicht, die auf der Grundlage einer anderen erstellt wird, die Anzahl der Stellen, an denen sich die Daten bei Änderungen im ETL "auseinanderentwickeln" können. Dies wiederum führt zu einer steigenden Komplexität (und Dauer) jeder nachfolgenden Überarbeitung.

Wenn das oben Beschriebene Systeme mit selten überarbeiteten ETL-Prozessen betrifft, ist es möglich, in solch einem Paradigma zu leben – es reicht aus, einfach sicherzustellen, dass neue Anpassungen korrekt in alle damit verbundenen Objekte eingearbeitet werden. Wenn jedoch häufig Anpassungen stattfinden, steigt die Wahrscheinlichkeit, versehentlich mehrere Verbindungen zu "übersehen", erheblich.

Berücksichtigt man außerdem, dass "versionsbasierte" ETL erheblich komplizierter ist als "nicht versionsbasierte", wird es ziemlich schwierig, Fehler bei der häufigen Anpassung all dieser Komponenten zu vermeiden.

Speicherung von Objekten und Attributen im Data Vault und im Anchor Model

Der von den Autoren flexibler Architekturen vorgeschlagene Ansatz kann wie folgt formuliert werden:

Es ist notwendig, das, was sich ändert, von dem, was unverändert bleibt, zu trennen. Das heißt, Schlüssel getrennt von Attributen zu speichern.

Dabei sollte man nicht verwechseln nicht versionsbasiert Attribut mit unverändert: Erstes speichert nicht die Historie seiner Veränderungen, kann sich aber ändern (zum Beispiel bei der Korrektur eines Eingabefehlers oder bei Erhalt neuer Daten), letzteres – ändert sich niemals.

Die Meinungen darüber, was genau im Data Vault und im Anchor Model als unveränderlich angesehen werden kann, gehen auseinander.

Aus der Sicht der Architektur Data Vault, kann man als unveränderlich betrachten das gesamte Set von Schlüsseln – natürliche (Steuernummer des Unternehmens, Produktcode im Quellsystem usw.) und surrogate. Dabei können die anderen Attribute in Gruppen entsprechend der Quelle und/or Häufigkeit der Änderungen unterteilt werden und für jede Gruppe eine separate Tabelle führen mit einem unabhängigen Satz von Versionen.

Im Paradigma Anchor Model gilt als unveränderlich nur der surrogate Schlüssel der Entität. Alles andere (einschließlich der natürlichen Schlüssel) ist einfach ein Sonderfall seiner Attribute. Dabei sind alle Attribute standardmäßig unabhängig voneinander, deshalb sollte für jedes Attribut eine separate Tabelle erstellt werden.

Im Data Vault Tabellen, die die Schlüsseldaten enthalten, werden genannt Hubs. Hubs enthalten immer eine feste Anzahl von Feldern:

Natürliche Schlüssel der Entität
Surrogate Schlüssel
Verweis auf die Quelle
Zeitpunkt der Hinzufügung des Datensatzes

Datensätze in Hubs werden niemals geändert und haben keine Versionen.. Äußerlich ähneln Hubs sehr den ID-Map-Tabellen, die in einigen Systemen zur Generierung von Surrogaten verwendet werden. Im Data Vault wird jedoch empfohlen, anstelle einer Ganzzahl-Sequenz einen Hash des Satzes von Geschäftsschlüsseln als Surrogate zu verwenden. Dieser Ansatz vereinfacht das Laden von Beziehungen und Attributen aus Quellen (es ist nicht erforderlich, sich mit dem Hub zu verbinden, um ein Surrogat zu erhalten, es genügt, einfach den Hash des natürlichen Schlüssels zu berechnen), kann jedoch andere Probleme verursachen (z. B. Kollisionen, Groß- und Kleinschreibung und nicht druckbare Zeichen in stringbasierten Schlüsseln usw.), weshalb er nicht allgemein anerkannt ist.

Alle anderen Attribute der Entitäten werden in speziellen Tabellen gespeichert, die Satelliten (Satellit). Ein Hub kann mehrere Satelliten haben, die unterschiedliche Sätze von Attributen speichern.

Die Verteilung der Attribute auf Satelliten erfolgt nach dem Prinzip gemeinsamer Änderung — in einem Satelliten können nicht versionierte Attribute (z. B. Geburtsdatum und SNILS für natürliche Personen) gespeichert werden, in einem anderen — selten geänderte versionierte Attribute (z. B. Nachname und Reisepassnummer), in einem dritten — häufig geänderte (z. B. Lieferadresse, Kategorie, Datum der letzten Bestellung usw.). Die Versionierung erfolgt dabei auf Ebene einzelner Satelliten und nicht der Entität insgesamt, weshalb die Verteilung der Attribute so erfolgen sollte, dass die Überlappung von Versionen innerhalb eines Satelliten minimal ist (was die Gesamtanzahl der gespeicherten Versionen reduziert).

Außerdem werden zur Optimierung des Datenladeprozesses häufig Attribute, die aus verschiedenen Quellen stammen, in separate Satelliten ausgelagert.

Satelliten sind mit dem Hub über einen Fremdschlüssel verbunden (was der Kardinalität 1 zu vielen entspricht). Das bedeutet, dass multiple Attributwerte (z. B. mehrere Telefonnummern eines Kunden) von dieser Architektur „standardmäßig“ unterstützt werden.

Im Anker-Modell (Anchor Model) Tabellen, die Schlüssel speichern, werden Ankern (Anchor). Und sie speichern:

Nur surrogate Schlüssel
Verweis auf die Quelle
Zeitpunkt der Hinzufügung des Datensatzes

Natürliche Schlüssel gelten im Rahmen des Anker-Modells als normale Attribute. Diese Variante mag komplexer erscheinen, bietet jedoch viel mehr Spielraum für die Identifikation des Objekts.

Zum Beispiel, wenn Daten zu demselben Wesen aus verschiedenen Systemen stammen, wobei jedes System seinen eigenen natürlichen Schlüssel verwendet. In Data Vault kann dies zu ziemlich komplexen Konstruktionen aus mehreren Hubs führen (einer pro Quelle + eine zusammenführende Master-Version), während im Anker-Modell der natürliche Schlüssel jeder Quelle in ein eigenes Attribut gelangt und unabhängig von allen anderen bei der Ladung verwendet werden kann.

Aber hier steckt ein tückischer Punkt: Wenn in einem Wesen Attribute aus verschiedenen Systemen zusammengeführt werden, gibt es wahrscheinlich einige Regeln zur "Zusammenführung", nach denen das System verstehen muss, dass Datensätze aus verschiedenen Quellen einem einzigen Exemplar des Wesens entsprechen.

Im Data Vault Diese Regeln werden wahrscheinlich die Bildung von "surrogaten Hubs" der Master-Entität bestimmen und keinen Einfluss auf die Hubs haben, die die natürlichen Schlüssel der Quellen und deren ursprüngliche Attribute speichern. Wenn sich die Regeln zur Zusammenführung zu irgendeinem Zeitpunkt ändern (oder ein Update der Attribute, nach denen sie erfolgt, kommt), reicht es aus, die surrogate Hubs neu zu generieren.

Im Im Anker-Modell wird ein solches Wesen wahrscheinlich in einem einzigen Ankergespeichert. Das bedeutet, dass alle Attribute, unabhängig von der Quelle, aus der sie stammen, an denselben Surrogat gebunden sind. Die fälschlicherweise zusammengeführten Datensätze zu trennen und insgesamt die Aktualität der Zusammenführung in einem solchen System zu überwachen, könnte sich als deutlich schwieriger erweisen, insbesondere wenn die Regeln ziemlich komplex sind und sich häufig ändern, während dasselbe Attribut aus verschiedenen Quellen stammen kann (obwohl es möglich ist, da jede Attribut-Version einen Verweis auf ihre Quelle speichert).

In jedem Fall, wenn in Ihrem System die Implementierung von Funktionen zur Dublettenbeseitigung, zur Zusammenführung von Datensätzen und anderen MDM-Elementenvorgesehen ist, sollten Sie besonders sorgfältig die Aspekte der Speicherung natürlicher Schlüssel in flexiblen Methodologien betrachten. Wahrscheinlich wird die komplexere Struktur von Data Vault plötzlich als sicherer hinsichtlich Zusammenführungsfehler erscheinen.

Das Anker-Modell sieht auch einen zusätzlichen Objekttyp vor, der als Knoten (Knot) bezeichnet wird, der im Wesentlichen eine spezielle Form des Ankers ist., der nur ein Attribut enthalten kann. Knoten sollen zum Speichern von flachen Verzeichnissen verwendet werden (zum Beispiel Geschlecht, Familienstand, Kundenkategorie usw.). Im Gegensatz zum Anker hat der Knoten keine verknüpften Attributtabellen, und sein einziges Attribut (Name) wird immer in einer Tabelle mit dem Schlüssel gespeichert. Knoten werden mit Ankern durch Beziehungstabellen (Tie) verbunden, ähnlich wie Anker untereinander.

Es gibt keine eindeutige Meinung zur Verwendung von Knoten. Zum Beispiel Nikolai Golow, der aktiv die Anwendung des Anker-Modells in Russland vorantreibt, ist der Meinung (nicht ohne Grundlage), dass für kein Verzeichnis genau behauptet werden kann, dass es immer statisch und einadrig sein wird, weshalb es für alle Objekte besser ist, sofort einen vollständigen Anker zu verwenden.

Ein weiterer wichtiger Unterschied zwischen Data Vault und dem Anker-Modell besteht darin, dass es Attribute bei Beziehungen gibt.:

Im Data Vault Beziehungen sind ebenso vollständige Objekte wie Hubs und können eigene Attribute haben.. In Im Anker-Modell Beziehungen werden nur zur Verbindung von Ankern verwendet und können keine eigenen Attribute haben.. Dieser Unterschied führt zu grundsätzlich unterschiedlichen Ansätzen bei der Modellierung von Fakten, worüber weiter unten gesprochen wird.

Ablage von Fakten

Bis jetzt haben wir hauptsächlich über die Modellierung von Dimensionen gesprochen. Bei Fakten ist die Situation etwas weniger eindeutig.

Im Data Vault Ein typisches Objekt zur Speicherung von Fakten ist die Beziehung (Link), in deren Satelliten sich reale Kennzahlen ansammeln.

Dieser Ansatz erscheint intuitiv verständlich. Er bietet einfachen Zugang zu den zu analysierenden Kennzahlen und ähnelt im Allgemeinen einer traditionellen Faktentabelle (nur dass die Kennzahlen nicht in der Tabelle selbst, sondern in der "benachbarten" gespeichert werden). Aber es gibt auch Haken: Eine der typischen Anpassungen des Modells — die Erweiterung des Faktenschlüssels — erfordert die Hinzufügung eines neuen Fremdschlüssels in den Link.Dies "bricht" wiederum die Modularität und könnte potenziell Anpassungen bei anderen Objekten erforderlich machen.

Im Im Anker-Modell Die Beziehung kann keine eigenen Attribute haben, daher wird dieser Ansatz nicht funktionieren — alle Attribute und Kennzahlen müssen an einen bestimmten Anker gebunden sein. Die Schlussfolgerung ist einfach — jeder Fakt benötigt ebenfalls seinen eigenen Anker.. Für einen Teil dessen, was wir als Fakten betrachten, mag es natürlich erscheinen – zum Beispiel lässt sich die Tatsache eines Kaufs gut auf das Objekt “Bestellung” oder “Quittung” reduzieren, der Besuch einer Website auf eine Sitzung usw. Aber es gibt auch Fakten, für die es nicht so einfach ist, ein solches natürliches “Träger-Objekt” zu finden – zum Beispiel die Bestände von Waren in Lagern zu Beginn eines jeden Tages.

Entsprechend gibt es bei der Modularität beim Erweitern des Faktenschlüssels im Anker-Modell keine Probleme (es reicht aus, einfach eine neue Beziehung zu dem entsprechenden Anker hinzuzufügen), aber das Design des Modells zur Darstellung von Fakten ist weniger eindeutig, es könnten “künstliche” Anker entstehen, die das Geschäftsobjektmodell nicht offensichtlich darstellen.

Wie Flexibilität erreicht wird

Die resultierende Konstruktion enthält in beiden Fällen deutlich mehr Tabellen, als eine traditionelle Dimension. Sie kann aber deutlich weniger Speicherplatz benötigen bei demselben Satz von Versionsattributen wie bei einer traditionellen Dimension. Es gibt hier natürlich keine Magie – alles hängt von der Normalisierung ab. Wenn wir Attribute auf Satelliten (im Data Vault) oder separate Tabellen (im Anker-Modell) verteilen, reduzieren wir (oder schließen ganz aus) die Duplizierung von Werten einiger Attribute bei der Änderung anderer.

Für Data Vault der Gewinn hängt von der Verteilung der Attribute auf Satelliten ab, und für Im Anker-Modell ist er praktisch direkt proportional zur durchschnittlichen Anzahl von Versionen eines Messobjekts.

Der Gewinn bei dem benötigten Platz ist jedoch ein wichtiges, aber nicht das Hauptargument für die separate Speicherung von Attributen. Zusammen mit der getrennten Speicherung von Beziehungen macht dieser Ansatz das Speicherformat modular. Das bedeutet, dass das Hinzufügen sowohl einzelner Attribute als auch ganzer neuer Fachbereiche in einem solchen Modell wie eine Erweiterung über die bestehende Sammlung von Objekten ohne deren Änderung aussieht. Und genau das macht die beschriebenen Methodologien flexibel.

Das erinnert auch an den Übergang von Einzelproduktion zu Massenproduktion – während im traditionellen Ansatz jede Tabelle des Modells einzigartig ist und besondere Aufmerksamkeit erfordert, handelt es sich in flexiblen Methodologien bereits um eine Reihe typischer “Teile”. Einerseits gibt es mehr Tabellen, die Prozesse zum Laden und Abfragen von Daten erscheinen komplizierter. Andererseits werden sie typisch. Das bedeutet, sie können sein automatisiert und werden von Metadaten gesteuert. Die Frage "Wie werden wir es umsetzen?", deren Antwort einen erheblichen Teil der Entwicklungsarbeiten für Verbesserungen ausmachen konnte, stellt sich jetzt einfach nicht mehr (wie auch die Frage nach den Auswirkungen einer Modelländerung auf die laufenden Prozesse).

Das bedeutet nicht, dass Analysten in einem solchen System völlig überflüssig sind – jemand muss immer noch eine Reihe von Objekten mit Attributen bearbeiten und herausfinden, woher und wie all das geladen werden kann. Aber der Arbeitsaufwand sowie die Wahrscheinlichkeit und die Kosten eines Fehlers werden erheblich reduziert. Sowohl in der Analysephase als auch bei der Entwicklung von ETL, die zu einem erheblichen Teil auf die Bearbeitung von Metadaten hinauslaufen kann.

Die dunkle Seite

Alles, was oben beschrieben wurde, macht beide Ansätze tatsächlich flexibel, technologisch fortschrittlich und geeignet für iterative Anpassungen. Natürlich gibt es auch "ein Fass voll Teer", von dem Sie, denke ich, bereits eine Ahnung haben.

Die Dekomposition von Daten, die der Modularität flexibler Architekturen zugrunde liegt, führt zu einer erhöhten Anzahl von Tabellen und somit Überheadkosten bei Joins während der Abfrage. Um einfach alle Attribute einer Dimension zu erhalten, ist in einem klassischen Warehouse nur ein Select erforderlich, während eine flexible Architektur eine ganze Reihe von Joins erfordert. Dabei können für Berichte all diese Joins im Voraus geschrieben werden, doch Analysten, die es gewohnt sind, SQL von Hand zu schreiben, werden doppelt leiden.

Es gibt einige Fakten, die diese Situation erleichtern:

Bei der Arbeit mit großen Dimensionen werden fast nie alle ihre Attribute gleichzeitig verwendet. Das bedeutet, dass die Anzahl der Joins geringer sein kann, als es auf den ersten Blick beim Betrachten des Modells erscheint. Im Data Vault kann zudem die voraussichtliche Häufigkeit der gemeinsamen Nutzung bei der Verteilung von Attributen auf Satelliten berücksichtigt werden. Dabei sind die Hubs oder Anker in erster Linie zur Generierung und Zuordnung von Surrogaten während des Ladevorgangs erforderlich und werden selten in Abfragen verwendet (insbesondere gilt dies für die Anker).

Alle Joins erfolgen nach Schlüssel. Darüber hinaus reduziert eine „kompaktere“ Methode zur Datenspeicherung die Kosten für das Scannen von Tabellen, wo dies erforderlich ist (zum Beispiel beim Filtern nach Attributwerten). Dies kann dazu führen, dass die Abfrage aus einer normalisierten Datenbank mit vielen Joins sogar schneller ist als das Scannen einer einzigen schweren Dimension mit vielen Versionen pro Zeile.

Zum Beispiel, hier in dieser dem Artikel gibt es einen detaillierten Vergleichstest der Leistung des Anchor-Modells mit einer Abfrage aus einer einzigen Tabelle.

Vieles hängt vom Engine ab. Viele moderne Plattformen haben interne Mechanismen zur Optimierung von Joins. Zum Beispiel können MS SQL und Oracle Joins zu Tabellen "überspringen", wenn ihre Daten nirgendwo verwendet werden, außer in anderen Joins, und keinen Einfluss auf die finale Abfrage haben (table/join elimination), während MPP Vertica laut den Erfahrungen von Kollegen bei Avitosich als hervorragende Engine für das Anchor-Modell bewährt hat, vorausgesetzt, es wird eine gewisse manuelle Optimierung des Abfrageplans vorgenommen. Andererseits scheint es nicht die beste Idee zu sein, das Anchor-Modell beispielsweise auf Click House zu speichern, das eine eingeschränkte Unterstützung für Joins hat.

Darüber hinaus gibt es für beide Architekturen spezielle Techniken, die den Zugang zu Daten erleichtern (sowohl hinsichtlich der Abfrageleistung als auch für die Endbenutzer). Zum Beispiel, Point-In-Time-Tabellen im Data Vault oder spezielle Tabellenfunktionen im Anchor-Modell.

Insgesamt

Der Kern der besprochenen flexiblen Architekturen besteht in der Modularität ihrer „Konstruktion“.

Genau diese Eigenschaft ermöglicht es:

Nach einer gewissen anfänglichen Vorbereitung, die mit der Bereitstellung von Metadaten und dem Schreiben grundlegender ETL-Algorithmen verbunden ist, dem Kunden schnell ein erstes Ergebnis zur Verfügung zu stellen in Form von einigen Berichten, die die Daten nur weniger Quellobjekte enthalten. Es ist nicht notwendig, das gesamte Objektmodell (sogar auf hoher Ebene) vollständig zu durchdenken.
Das Datenmodell kann bereits mit 2-3 Objekten arbeiten (und Nutzen bringen), und dann stufenweise wachsen (in Bezug auf das Anchor-Modell hat Nikolai eine schöne Analogie zur Myzelstruktur gemacht).
Die meisten Anpassungen, einschließlich der Erweiterung des Themenbereichs und der Hinzufügung neuer Quellen, berühren die vorhandene Funktionalität nicht und stellen keine Gefahr dar, etwas, das bereits funktioniert, zu brechen..
Durch die Dekonstruktion in standardisierte Elemente erscheinen ETL-Prozesse in solchen Systemen einheitlich, ihre Erstellung lässt sich algorithmisieren und letztendlich automatisieren.

Der Preis für diese Flexibilität ist die Leistung. Das bedeutet jedoch nicht, dass es unmöglich ist, in solchen Modellen akzeptable Leistungen zu erreichen. Häufig kann es einfach mehr Aufwand und Aufmerksamkeit für Details erfordern, um die gewünschten Metriken zu erreichen.