Die Speicherentwicklung ist ein langwieriges und ernstes Geschäft.
Vieles im Leben eines Projekts hängt davon ab, wie gut das Objektmodell und die Grundstruktur zu Beginn durchdacht sind.
Der allgemein akzeptierte Ansatz waren und sind verschiedene Kombinationen des Sternschemas mit der dritten Normalform. In der Regel nach dem Prinzip: Ausgangsdaten – 3NF, Vitrinen – ein Stern. Dieser bewährte und durch zahlreiche Untersuchungen untermauerte Ansatz ist das Erste (und manchmal auch das Einzige), was einem erfahrenen DWH-Spezialisten in den Sinn kommt, wenn er darüber nachdenkt, wie ein analytisches Repository aussehen sollte.
Andererseits neigen Unternehmen im Allgemeinen und Kundenanforderungen im Besonderen dazu, sich schnell zu ändern, während die Daten sowohl „in der Tiefe“ als auch „in der Breite“ wachsen. Und hier zeigt sich der Hauptnachteil des Sterns – begrenzt Flexibilität.
Und wenn in Ihrem ruhigen und komfortablen Leben als DWH-Entwickler plötzlich:
- Es stellte sich die Aufgabe, „zumindest schnell etwas zu tun, und dann werden wir sehen“;
- Es entstand ein sich schnell entwickelndes Projekt, bei dem mindestens einmal pro Woche neue Quellen angeschlossen und das Geschäftsmodell geändert wurden.
- Es erschien ein Kunde, der keine Ahnung hat, wie das System aussehen und welche Funktionen es am Ende erfüllen soll, aber bereit ist für Experimente und die konsequente Verfeinerung des gewünschten Ergebnisses mit einer konsequenten Herangehensweise daran;
- Der Projektleiter meldete sich mit der guten Nachricht: „Und jetzt haben wir Agile!“.
Oder wenn Sie einfach nur daran interessiert sind, zu erfahren, wie Sie sonst noch Speicher bauen können – willkommen bei der Katze!
Was bedeutet „Flexibilität“?
Definieren wir zunächst, welche Eigenschaften ein System haben muss, um als „flexibel“ bezeichnet zu werden.
Unabhängig davon ist zu erwähnen, dass auf die beschriebenen Eigenschaften konkret Bezug genommen werden sollte System, nicht zu Verfahren seine Entwicklung. Wenn Sie mehr über Agile als Entwicklungsmethodik erfahren möchten, ist es daher besser, andere Artikel zu lesen. Genau dort, auf Habré, gibt es zum Beispiel viele interessante Materialien (wie и Und ).
Dies bedeutet nicht, dass der Entwicklungsprozess und die Struktur des Data Warehouse völlig unabhängig voneinander sind. Im Allgemeinen sollte die agile Entwicklung eines agilen Speichers viel einfacher sein. In der Praxis gibt es jedoch bei der agilen Entwicklung des klassischen DWH nach Kimbal und DataVault – nach Wasserfall – mehr Optionen als glückliche Zufälle von Flexibilität in ihren beiden Formen in einem Projekt.
Welche Funktionen sollte flexibler Speicher also haben? Hier gibt es drei Punkte:
- Frühzeitige Lieferung und schnelle Fertigstellung - Dies bedeutet, dass das erste Geschäftsergebnis (z. B. die ersten Arbeitsberichte) idealerweise so früh wie möglich eingeholt werden sollte, d. h. noch bevor das gesamte System konzipiert und implementiert ist. Gleichzeitig sollte jede weitere Überarbeitung möglichst wenig Zeit in Anspruch nehmen.
- Iterative Verfeinerung - Dies bedeutet, dass jede nachfolgende Überarbeitung im Idealfall keinen Einfluss auf die bereits funktionierende Funktionalität haben sollte. Dieser Moment wird bei großen Projekten oft zum größten Albtraum – früher oder später beginnen einzelne Objekte so viele Beziehungen aufzubauen, dass es einfacher wird, die Logik in einer Kopie vollständig nebeneinander zu wiederholen, als ein Feld zu einer vorhandenen Tabelle hinzuzufügen. Und wenn Sie überrascht sind, dass die Analyse der Auswirkungen von Verbesserungen auf bestehende Objekte länger dauern kann als die Überarbeitung selbst, haben Sie höchstwahrscheinlich noch nicht mit großen Data Warehouses im Banken- oder Telekommunikationsbereich gearbeitet.
- Ständige Anpassung an sich ändernde Geschäftsanforderungen - Die allgemeine Objektstruktur sollte nicht nur unter Berücksichtigung der möglichen Erweiterung entworfen werden, sondern auch mit der Erwartung, dass die Richtung dieser nächsten Erweiterung in der Entwurfsphase noch nicht einmal im Entferntesten vorhergesehen werden konnte.
Und ja, die Erfüllung all dieser Anforderungen in einem System ist möglich (natürlich in bestimmten Fällen und mit einigen Vorbehalten).
Im Folgenden werde ich zwei der beliebtesten agilen Designmethoden für HD besprechen Ankermodell и Datentresor. Außerhalb der Klammern stehen so wunderbare Tricks wie zum Beispiel EAV, 6NF (in reiner Form) und alles rund um NoSQL-Lösungen – nicht weil sie irgendwie schlechter wären, und auch nicht, weil der Artikel in diesem Fall den Umfang einer durchschnittlichen Dissertation anzunehmen drohen würde. Das alles bezieht sich nur auf Lösungen einer etwas anderen Klasse – entweder auf Techniken, die Sie in bestimmten Fällen anwenden können, unabhängig von der allgemeinen Architektur Ihres Projekts (wie EAV), oder auf global unterschiedliche Informationsspeicherparadigmen (wie zum Beispiel Graphdatenbanken und andere NoSQL-Varianten).
Probleme des „klassischen“ Ansatzes und ihre Lösungen in flexiblen Methoden
Mit dem „klassischen“ Ansatz meine ich den guten alten Stern (unabhängig von der konkreten Implementierung der darunter liegenden Schichten, verzeihen Sie mir die Anhänger von Kimball, Inmon und CDM).
1. Starre Kardinalität der Verbindungen
Dieses Modell basiert auf einer klaren Aufteilung der Daten in Maße (Dimension) и Fakten (Tatsache). Und das ist verdammt noch mal logisch – schließlich läuft die Datenanalyse in den allermeisten Fällen auf die Analyse bestimmter numerischer Indikatoren (Fakten) in bestimmten Abschnitten (Dimensionen) hinaus.
Gleichzeitig werden Verknüpfungen zwischen Objekten in Form von Verknüpfungen zwischen Tabellen durch einen Fremdschlüssel gelegt. Das sieht ganz natürlich aus, führt aber sofort zur ersten Einschränkung der Flexibilität − strenge Definition der Kardinalität von Beziehungen.
Das bedeutet, dass Sie in der Entwurfsphase von Tabellen für jedes Paar verwandter Objekte angeben müssen, ob sie viele-zu-viele oder nur 1-zu-viele in Beziehung stehen können und „in welche Richtung“. Es hängt direkt davon ab, welche der Tabellen einen Primärschlüssel und welche einen Fremdschlüssel hat. Eine Änderung dieses Verhältnisses bei neuen Anforderungen wird höchstwahrscheinlich zu einer Überarbeitung der Basis führen.
Beispielsweise legten Sie bei der Gestaltung des Objekts „Kassenbon“ unter Berufung auf die eidesstattlichen Zusicherungen des Vertriebs die Handlungsmöglichkeit fest eine Beförderung für mehrere Kontrollpositionen (aber nicht umgekehrt):
Und nach einer Weile stellten die Kollegen eine neue Marketingstrategie vor, in der mehrere Aktionen gleichzeitig. Und jetzt müssen Sie die Tabellen fertigstellen, indem Sie die Beziehung in einem separaten Objekt hervorheben.
(Alle abgeleiteten Objekte, in die der Promo-Check eingebunden wird, müssen nun ebenfalls verbessert werden.)
Links im Datentresor und im Ankermodell
Es stellte sich heraus, dass es ganz einfach war, eine solche Situation zu vermeiden: Man muss der Verkaufsabteilung nicht vertrauen, es reicht aus Alle Beziehungen werden zunächst in separaten Tabellen gespeichert und soviele-zu-viele verarbeiten.
Dieser Ansatz wurde vorgeschlagen Dan Linstedt als Teil des Paradigmas Datentresor und voll unterstützt Lars Rönnbäck в Ankermodell.
Als Ergebnis erhalten wir das erste Unterscheidungsmerkmal flexibler Methoden:
Beziehungen zwischen Objekten werden nicht in den Attributen übergeordneter Entitäten gespeichert, sondern sind ein separater Objekttyp.
В Datentresor solche Tabellen heißen LinkUnd in Ankermodell - Krawatte. Auf den ersten Blick sind sie sich sehr ähnlich, ihre Unterschiede erschöpfen sich jedoch nicht im Namen (auf den weiter unten eingegangen wird). In beiden Architekturen können Linktabellen verknüpft werden beliebig viele Entitäten (nicht unbedingt 2).
Diese auf den ersten Blick Redundanz bietet wesentliche Flexibilität bei der Fertigstellung. Eine solche Struktur wird nicht nur tolerant gegenüber der Änderung der Kardinalitäten bestehender Verknüpfungen, sondern auch gegenüber dem Hinzufügen neuer Verknüpfungen. Wenn nun eine Scheckposition auch eine Verknüpfung zu dem Kassierer hat, der sie unterbrochen hat, wird das Erscheinen einer solchen Verknüpfung lediglich ein Überbau über vorhandenen Tabellen sein, ohne dass sich dies auf vorhandene Objekte und Prozesse auswirkt.
2. Datenduplizierung
Das zweite durch flexible Architekturen gelöste Problem ist weniger offensichtlich und von vornherein inhärent. Messungen Typ SCD2 (sich langsam ändernde Messungen der zweiten Art), wenn auch nicht nur sie.
Im klassischen Speicher ist eine Dimension normalerweise eine Tabelle, die einen Ersatzschlüssel (als PK) und eine Reihe von Geschäftsschlüsseln und Attributen in separaten Spalten enthält.
Wenn die Dimension die Versionierung unterstützt, werden dem Standardfeldsatz Versionszeitlimits hinzugefügt und im Repository werden pro Zeile in der Quelle mehrere Versionen angezeigt (eine für jede Änderung an versionierten Attributen).
Wenn eine Dimension mindestens ein versioniertes Attribut enthält, das sich häufig ändert, ist die Anzahl der Versionen einer solchen Dimension beeindruckend (auch wenn die anderen Attribute nicht versioniert sind oder sich nie ändern), und wenn mehrere solcher Attribute vorhanden sind, kann die Anzahl der Versionen exponentiell von ihrer Anzahl an wachsen. Eine solche Dimension kann viel Speicherplatz beanspruchen, obwohl die meisten darin gespeicherten Daten lediglich Duplikate unveränderlicher Attributwerte aus anderen Zeilen sind.
Gleichzeitig wird es auch häufig verwendet Denormalisierung - Einige der Attribute werden absichtlich als Wert gespeichert und nicht als Verweis auf ein Nachschlagewerk oder eine andere Dimension. Dieser Ansatz beschleunigt den Datenzugriff, indem die Anzahl der Verknüpfungen beim Zugriff auf eine Dimension reduziert wird.
Typischerweise führt dies dazu Dieselben Informationen werden gleichzeitig an mehreren Orten gespeichert. Beispielsweise können in den Dimensionen „Kunde“ und den Fakten „Kauf“, „Lieferung“ und „Kontakte zum Callcenter“ sowie in der Verknüpfungstabelle „Kunde – Kundenmanager“ gleichzeitig Informationen über die Wohnregion und die Zugehörigkeit zur Kundenkategorie hinterlegt werden.
Im Allgemeinen gilt das oben Gesagte auch für reguläre (nicht versionierte) Messungen, aber in versionierten Messungen können sie einen anderen Maßstab haben: Das Erscheinen einer neuen Version eines Objekts (insbesondere im Nachhinein) führt nicht nur zur Aktualisierung aller zugehörigen Tabellen, sondern auch zu einem kaskadenartigen Erscheinen neuer Versionen verwandter Objekte – wenn Tabelle 1 beim Erstellen von Tabelle 2 und Tabelle 2 beim Erstellen von Tabelle 3 usw. verwendet wird. Selbst wenn kein einziges Attribut von Tabelle 1 an der Konstruktion von Tabelle 3 beteiligt ist (und andere Attribute von Tabelle 2, die aus anderen Quellen stammen, beteiligt sind), führt die Versionierung dieser Konstruktion zumindest zu zusätzlichen Gemeinkosten und höchstens zu zusätzlichen Versionen in Tabelle 3, die überhaupt nichts damit zu tun haben und weiter unten in der Kette liegen.
3. Nichtlineare Komplexität der Verfeinerung
Gleichzeitig erhöht jede neue Storefront, die übereinander aufgebaut wird, die Anzahl der Stellen, an denen Daten „auseinanderlaufen“ können, wenn Änderungen am ETL vorgenommen werden. Dies wiederum führt zu einer Zunahme der Komplexität (und Dauer) jeder nachfolgenden Überarbeitung.
Wenn das oben Gesagte auf Systeme mit selten geänderten ETL-Prozessen zutrifft, können Sie in einem solchen Paradigma leben – stellen Sie einfach sicher, dass neue Verbesserungen korrekt an allen zugehörigen Objekten vorgenommen werden. Kommt es zu häufigen Überarbeitungen, erhöht sich die Wahrscheinlichkeit, versehentlich mehrere Links zu „übersehen“, deutlich.
Wenn wir außerdem berücksichtigen, dass das „versionierte“ ETL viel komplizierter ist als das „nicht versionierte“, wird es ziemlich schwierig, Fehler bei der häufigen Verfeinerung dieser gesamten Wirtschaft zu vermeiden.
Speichern von Objekten und Attributen im Datentresor und im Ankermodell
Der von den Autoren flexibler Architekturen vorgeschlagene Ansatz lässt sich wie folgt formulieren:
Es ist notwendig, das, was sich verändert, von dem, was unverändert bleibt, zu trennen. Das heißt, Schlüssel getrennt von Attributen zu speichern.
Lassen Sie sich jedoch nicht verwirren nicht versioniert Attribut mit unverändert: Der erste speichert nicht den Verlauf seiner Änderung, kann sich aber ändern (z. B. beim Korrigieren eines Eingabefehlers oder beim Empfang neuer Daten), der zweite ändert sich nie.
Die Ansichten darüber, was genau im Data Vault- und im Anchor-Modell als unverändert gelten kann, gehen auseinander.
In Sachen Architektur Datentresor, kann als unverändert betrachtet werden der ganze Schlüsselbund — natürlich (TIN der Organisation, Produktcode im Quellsystem usw.) und Ersatz. Gleichzeitig können die übrigen Attribute nach Quelle und/oder Häufigkeit der Änderungen in Gruppen eingeteilt werden Führen Sie für jede Gruppe eine separate Tabelle mit einem unabhängigen Satz von Versionen.
Im gleichen Paradigma Ankermodell als unverändert angesehen Nur Ersatzschlüssel Entitäten. Alles andere (einschließlich natürlicher Schlüssel) ist nur ein Sonderfall seiner Attribute. Dabei Alle Attribute sind standardmäßig unabhängig voneinander, also muss für jedes Attribut erstellt werden separater Tisch.
В Datentresor Es werden Tabellen aufgerufen, die Entitätsschlüssel enthalten Hubami (Hub). Hubs enthalten immer einen festen Satz an Feldern:
- Schlüssel für natürliche Entitäten
- Ersatzschlüssel
- Link zur Quelle
- Aufnahmezeit
Einträge in Hubs ändern sich nie und haben keine Versionen. Äußerlich ähneln Hubs stark den ID-Map-Tabellen, die in manchen Systemen zum Generieren von Surrogaten verwendet werden. Es wird jedoch empfohlen, in Data Vault keine Ganzzahlsequenz, sondern einen Hash aus einem Satz von Geschäftsschlüsseln als Surrogate zu verwenden. Dieser Ansatz vereinfacht das Laden von Links und Attributen aus Quellen (kein Beitritt zum Hub erforderlich, um einen Ersatz zu erhalten, sondern nur die Berechnung des Hashs aus dem natürlichen Schlüssel), er kann jedoch andere Probleme verursachen (z. B. Kollisionen, Groß- und Kleinschreibung und nicht druckbare Zeichen in Zeichenfolgenschlüsseln usw.) und wird daher nicht allgemein akzeptiert.
Alle anderen Entitätsattribute werden in speziellen Tabellen namens gespeichert Satelliten (Satellit). Ein Hub kann über mehrere Satelliten verfügen, die unterschiedliche Sätze von Attributen speichern.
Die Verteilung der Attribute auf die Satelliten erfolgt nach dem Prinzip gemeinsame Veränderung - Ein Satellit kann nicht versionierte Attribute speichern (z. B. Geburtsdatum und SNILS für eine Person), im anderen - sich selten ändernde versionierte Attribute (z. B. Nachname und Passnummer), im dritten - sich häufig ändernde (z. B. Lieferadresse, Kategorie, Datum der letzten Bestellung usw.). Die Versionierung erfolgt in diesem Fall auf der Ebene einzelner Satelliten und nicht der Entität als Ganzes. Daher ist es ratsam, die Attribute so zu verteilen, dass die Überschneidung der Versionen innerhalb eines Satelliten minimal ist (was die Gesamtzahl der gespeicherten Versionen verringert).
Um den Prozess des Ladens von Daten zu optimieren, werden außerdem aus verschiedenen Quellen erhaltene Attribute häufig in separaten Satelliten platziert.
Satelliten kommunizieren mit dem Hub Unbekannter Schlüssel (was einer 1-zu-vielen-Kardinalität entspricht). Dies bedeutet, dass mehrere Attributwerte (z. B. mehrere Kontakttelefonnummern für denselben Kunden) von dieser „Standard“-Architektur unterstützt werden.
В Ankermodell Tabellen, die Schlüssel speichern, werden aufgerufen Anker. Und sie behalten:
- Nur Ersatzschlüssel
- Link zur Quelle
- Aufnahmezeit
Es werden natürliche Schlüssel aus Sicht des Ankermodells betrachtet gewöhnliche Attribute. Diese Option scheint zwar schwieriger zu verstehen, bietet aber viel mehr Möglichkeiten zur Identifizierung eines Objekts.
Wenn beispielsweise Daten über dieselbe Entität aus verschiedenen Systemen stammen können, verwendet jedes System seinen eigenen natürlichen Schlüssel. Im Data Vault kann dies zu recht umständlichen Konstruktionen mehrerer Hubs führen (einer pro Quelle + zusammenführende Master-Version), während im Anchor-Modell der natürliche Schlüssel jeder Quelle in ein eigenes Attribut fällt und beim Laden unabhängig von allen anderen verwendet werden kann.
Aber hier liegt ein heimtückischer Moment: Wenn Attribute aus verschiedenen Systemen in einer Entität kombiniert werden, sind es höchstwahrscheinlich welche Kleberegeln, wobei das System verstehen muss, dass Datensätze aus verschiedenen Quellen einer Instanz der Entität entsprechen.
В Datentresor Diese Regeln dürften die Formation bestimmen „Ersatz-Hub“ der Master-Entität und haben keinerlei Auswirkungen auf die Hubs, die die natürlichen Schlüssel der Quellen und ihre Originalattribute speichern. Wenn sich irgendwann die Regeln für die Zusammenführung ändern (oder die Attribute, die für die Zusammenführung verwendet werden, aktualisiert werden), reicht es aus, die Ersatz-Hubs neu zu bilden.
В Ankermodell Eine solche Entität wird wahrscheinlich darin gespeichert Einzelanker. Das bedeutet, dass alle Attribute, egal aus welcher Quelle sie stammen, an dasselbe Surrogat gebunden werden. Es kann viel schwieriger sein, fehlerhaft zusammengeführte Datensätze zu trennen und im Allgemeinen die Relevanz der Zusammenführung in einem solchen System im Auge zu behalten, insbesondere wenn die Regeln recht komplex sind und sich häufig ändern und das gleiche Attribut aus verschiedenen Quellen bezogen werden kann (obwohl dies durchaus möglich ist, da jede Version des Attributs einen Link zu seiner Quelle beibehält).
Auf jeden Fall, wenn Ihr System die Funktionalität umsetzen soll Deduplizierung, Zusammenführung von Datensätzen und anderen MDM-Elementen, sollten Sie die Aspekte der Speicherung natürlicher Schlüssel in flexiblen Methoden besonders sorgfältig lesen. Vielleicht ist das unhandlichere Design des Datentresors plötzlich sicherer im Hinblick auf Zusammenführungsfehler.
Ankermodell stellt außerdem einen zusätzlichen Objekttyp namens bereit Knoten Tatsächlich ist es etwas Besonderes entarteter Ankertyp, das nur ein Attribut enthalten kann. Die Knoten sollen zum Speichern flacher Verzeichnisse (z. B. Geschlecht, Familienstand, Kundendienstkategorie usw.) verwendet werden. Im Gegensatz zu Anchor, Knot hat keine zugehörigen Attributtabellen, und sein einziges Attribut (Name) wird immer in derselben Tabelle mit dem Schlüssel gespeichert. Knoten werden durch Verbindungstabellen (Tie) mit Ankern verknüpft, genauso wie Anker untereinander verbunden sind.
Über den Einsatz von Nodes gibt es keine eindeutige Meinung. Zum Beispiel, , der sich aktiv für die Verwendung des Ankermodells in Russland einsetzt, glaubt (nicht ungerechtfertigterweise), dass es unmöglich ist, für ein einziges Nachschlagewerk zu sagen, dass er immer wird statisch und einstufig sein, daher ist es besser, einen vollwertigen Anker für alle Objekte gleichzeitig zu verwenden.
Ein weiterer wichtiger Unterschied zwischen Data Vault und Anchor Model ist die Präsenz Attribute für Links:
В Datentresor Links sind die gleichen vollwertigen Objekte wie Hubs und können auch solche haben eigene Attribute. In Ankermodell Links werden nur zum Verbinden von Ankern und verwendet können keine eigenen Attribute haben. Dieser Unterschied führt zu deutlich unterschiedlichen Modellierungsansätzen. von Fakten, was als nächstes besprochen wird.
Faktenspeicherung
Bisher haben wir hauptsächlich über Modellierungsmessungen gesprochen. Die Fakten sind etwas weniger eindeutig.
В Datentresor ein typisches Objekt zum Speichern von Fakten − Verknüpfung, in deren Satelliten echte Indikatoren hinzugefügt werden.
Dieser Ansatz scheint intuitiv zu sein. Sie ermöglicht einen einfachen Zugriff auf die analysierten Indikatoren und ähnelt im Allgemeinen einer herkömmlichen Faktentabelle (nur die Indikatoren werden nicht in der Tabelle selbst, sondern in der „nebenstehenden Tabelle“ gespeichert). Doch es gibt auch Fallstricke: Eine der typischen Verfeinerungen des Modells – die Erweiterung des Faktenschlüssels – macht es notwendig Hinzufügen eines neuen Fremdschlüssels zum Link. Und dies wiederum „bricht“ die Modularität und führt möglicherweise dazu, dass Verbesserungen an anderen Objekten erforderlich werden.
В Ankermodell Ein Link kann keine eigenen Attribute haben, daher wird dieser Ansatz nicht funktionieren – absolut alle Attribute und Indikatoren müssen mit einem bestimmten Anker verknüpft sein. Die Schlussfolgerung daraus ist einfach: Jede Tatsache braucht auch ihren eigenen Anker. Bei manchen Dingen, die wir normalerweise als Tatsachen wahrnehmen, mag dies natürlich erscheinen – zum Beispiel wird die Tatsache eines Kaufs perfekt auf das Objekt „Bestellung“ oder „Quittung“ reduziert, der Besuch einer Website wird auf eine Sitzung reduziert usw. Es gibt aber auch Tatsachen, für die es nicht so einfach ist, ein solches natürliches „Trägerobjekt“ zu finden – zum Beispiel die Warenbilanz in Lagerhäusern zu Beginn eines jeden Tages.
Dementsprechend gibt es keine Probleme mit der Modularität, wenn der Faktenschlüssel im Ankermodell erweitert wird (es reicht aus, nur eine neue Beziehung zum entsprechenden Anker hinzuzufügen), aber das Entwerfen des Modells zur Anzeige von Fakten ist weniger einfach, es können „künstliche“ Anker erscheinen, die das Objektmodell des Unternehmens widerspiegeln, was nicht offensichtlich ist.
Wie Flexibilität erreicht wird
Die resultierende Konstruktion enthält in beiden Fällen deutlich mehr Tischeals herkömmliche Messungen. Aber es kann dauern deutlich weniger Speicherplatz mit dem gleichen Satz versionierter Attribute wie die traditionelle Dimension. Natürlich gibt es hier keine Zauberei, es geht um Normalisierung. Durch die Verteilung von Attributen auf Satelliten (im Data Vault) oder einzelne Tabellen (Anchor-Modell) reduzieren wir (oder eliminieren) Duplizieren der Werte einiger Attribute beim Ändern anderer.
für Datentresor Der Gewinn hängt von der Verteilung der Attribute unter den Satelliten ab und z Ankermodell – ist fast direkt proportional zur durchschnittlichen Anzahl der Versionen pro Messobjekt.
Der Platzbedarf ist jedoch ein wichtiger, aber nicht der Hauptvorteil der separaten Speicherung von Attributen. Zusammen mit der separaten Speicherung von Links ermöglicht dieser Ansatz die Speicherung modulares Design. Dies bedeutet, dass in einem solchen Modell sowohl einzelne Attribute als auch ganz neue Themenbereiche hinzugefügt werden können Überbau über einen vorhandenen Satz von Objekten, ohne sie zu ändern. Und genau das macht die beschriebenen Methoden flexibel.
Es ähnelt auch dem Übergang von der Einzelproduktion zur Massenproduktion – wenn im traditionellen Ansatz jeder Modelltisch einzigartig ist und gesonderte Aufmerksamkeit erfordert, dann handelt es sich bei flexiblen Methoden bereits um eine Reihe typischer „Details“. Einerseits gibt es mehr Tabellen, die Prozesse des Ladens und Abrufens von Daten dürften komplizierter aussehen. Andererseits werden sie typisch. Dies bedeutet, dass dies der Fall sein kann automatisiert und durch Metadaten verwaltet. Die Frage „Wie legen wir es hin?“, deren Beantwortung einen erheblichen Teil der Arbeit zur Gestaltung von Verbesserungen in Anspruch nehmen könnte, lohnt sich jetzt einfach nicht mehr (ebenso wie die Frage nach den Auswirkungen einer Modelländerung auf Arbeitsprozesse).
Dies bedeutet nicht, dass Analysten in einem solchen System überhaupt nicht benötigt werden – jemand muss immer noch eine Reihe von Objekten mit Attributen ausarbeiten und herausfinden, wo und wie alles geladen wird. Doch der Arbeitsaufwand sowie die Wahrscheinlichkeit und Kosten eines Fehlers werden deutlich reduziert. Sowohl in der Analysephase als auch während der Entwicklung von ETL, die sich zu einem wesentlichen Teil auf die Bearbeitung von Metadaten reduzieren lässt.
Die dunkle Seite
All dies macht beide Ansätze wirklich flexibel, herstellbar und für die iterative Verfeinerung geeignet. Natürlich gibt es auch ein „Fass Teer“, das Sie, glaube ich, bereits kennen.
Die der Modularität flexibler Architekturen zugrunde liegende Datenzerlegung führt zu einer Erhöhung der Anzahl der Tabellen und dementsprechend zu Overhead für Joins beim Abrufen. Um einfach alle Attribute einer Dimension zu erhalten, reicht im klassischen Speicher ein einziger Select aus, und eine flexible Architektur erfordert eine Reihe von Joins. Wenn außerdem für Berichte alle diese Verknüpfungen im Voraus geschrieben werden können, werden Analysten, die es gewohnt sind, SQL von Hand zu schreiben, doppelt leiden.
Es gibt mehrere Fakten, die diese Situation erleichtern:
Bei der Arbeit mit großen Dimensionen werden fast nie alle Attribute gleichzeitig verwendet. Dies bedeutet, dass möglicherweise weniger Verknüpfungen vorhanden sind, als es auf den ersten Blick auf das Modell scheint. In Data Vault können Sie bei der Zuweisung von Attributen zu Satelliten auch die erwartete Häufigkeit der Freigabe berücksichtigen. Gleichzeitig werden Hubs oder Anker selbst hauptsächlich zum Generieren und Zuordnen von Surrogaten in der Ladephase benötigt und selten in Abfragen verwendet (dies gilt insbesondere für Anker).
Alle Verknüpfungen erfolgen nach Schlüssel. Darüber hinaus reduziert eine „komprimiertere“ Art der Datenspeicherung den Overhead beim Tabellenscannen dort, wo er benötigt wird (z. B. beim Filtern nach einem Attributwert). Dies kann dazu führen, dass das Abrufen aus einer normalisierten Datenbank mit einer Reihe von Verknüpfungen noch schneller ist als das Scannen einer umfangreichen Dimension mit vielen Versionen pro Zeile.
Zum Beispiel hier in In diesem Artikel finden Sie einen detaillierten vergleichenden Leistungstest des Anchor-Modells mit einer Auswahl aus einer Tabelle.
Viel hängt vom Motor ab. Viele moderne Plattformen verfügen über interne Mechanismen zur Optimierung von Joins. Beispielsweise können MS SQL und Oracle Joins zu Tabellen „überspringen“, wenn deren Daten außer für andere Joins nirgendwo verwendet werden und keinen Einfluss auf die endgültige Auswahl haben (Tabellen-/Join-Eliminierung), während MPP Vertica erwies sich mit einigen manuellen Optimierungen des Abfrageplans als hervorragende Engine für das Ankermodell. Andererseits scheint es noch keine gute Idee zu sein, das Ankermodell beispielsweise auf Click House zu speichern, das nur begrenzte Unterstützung für Join bietet.
Darüber hinaus gibt es für beide Architekturen besondere Tricks, die den Zugriff auf Daten erleichtern (sowohl im Hinblick auf die Abfrageleistung als auch für Endbenutzer). Zum Beispiel, Zeitpunkttabellen im Datentresor oder spezielle Tabellenfunktionen im Ankermodell.
Insgesamt
Das Wesentliche der betrachteten flexiblen Architekturen ist die Modularität ihres „Designs“.
Diese Eigenschaft ermöglicht:
- Nach einigen ersten Vorbereitungen im Zusammenhang mit der Bereitstellung von Metadaten und dem Schreiben grundlegender ETL-Algorithmen, dem Kunden schnell das erste Ergebnis liefern in Form einiger Berichte, die Daten von nur wenigen Quellobjekten enthalten. Hierzu ist es nicht erforderlich, das gesamte Objektmodell vollständig zu durchdenken (auch nicht auf oberster Ebene).
- Ein Datenmodell kann mit nur 2-3 Objekten funktionieren (und nützlich sein) und dann wachsen allmählich (bezüglich des Ankermodells Nikolai schöner Vergleich mit Myzel).
- Die meisten Verbesserungen, einschließlich der Erweiterung des Themenbereichs und der Hinzufügung neuer Quellen Beeinträchtigt nicht die vorhandene Funktionalität und birgt nicht die Gefahr, dass etwas kaputt geht, das bereits funktioniert.
- Dank der Zerlegung in Standardelemente sehen ETL-Prozesse in solchen Systemen gleich aus, ihre Schreibweise eignet sich für die Algorithmisierung und letztendlich Automatisierung.
Der Preis für diese Flexibilität beträgt производительность. Dies bedeutet nicht, dass es unmöglich ist, mit solchen Modellen eine akzeptable Leistung zu erzielen. In den meisten Fällen benötigen Sie einfach mehr Aufwand und Liebe zum Detail, um die gewünschten Kennzahlen zu erreichen.
Apps
Entitätstypen Datentresor
Mehr über Data Vault:
Entitätstypen Ankermodell
Mehr zum Ankermodell:
Übersichtstabelle mit Gemeinsamkeiten und Unterschieden der betrachteten Ansätze:
Source: habr.com