Eine häufige Anforderung an data warehousing in Unternehmen ist die Bereitstellung eines Analysemodells für die Bereitstellung von Informationen, z. B. in einer Dashboard- oder Berichtslösung. Eine Herausforderung in diesem Szenario besteht darin, dass das erforderliche Zielmodell, oft ein dimensionales Stern- oder Schneeflockenschema oder einfach eine denormalisierte flache und breite Entität, nicht mit der Quelldatenstruktur übereinstimmt. Stattdessen definiert der Endnutzer der analytischen Daten direkt oder indirekt die Zielstruktur gemäß der Informationsanforderungen.
Eine weitere Herausforderung sind die Daten selbst, unabhängig von ihrer Struktur.
In vielen, wenn nicht gar den meisten Fällen entsprechen die Quelldaten nicht den inhaltlichen Informationsanforderungen des Nutzers. In vielen Fällen müssen die Daten bereinigt und umgewandelt werden, bevor sie dem Nutzer präsentiert werden können.
Anstatt die Daten einfach in eine MongoDB Sammlung und deren Bearbeitung, bis sie den Bedürfnissen des Endnutzers entspricht, die Data Vault 2.0 Architektur schlägt einen Ansatz vor, der die Wiederverwendung von Daten und Geschäftsregeln, die neben der Transformation auch für die Datenbereinigung verwendet werden, durch viele Nutzer ermöglicht. Um dies zu erreichen, besteht es aus einer mehrschichtigen Architektur, die die folgenden Schichten enthält:
Diese Architektur folgt dem hybride Architektur in Data Vault 2.0, da es sowohl integriert ist als auch auf einem Data Lake bei dem die Quelldaten zunächst aufbereitet und unstrukturierte Daten gelagert werden.
Alle unten beschriebenen Schichten werden in einer einzigen MongoDB-Datenbank implementiert, so dass das gesamte Enterprise Document Warehouse nur eine einzige Datenbank verwendet. Der Grund für diese Designentscheidung ist die Tatsache, dass es nicht möglich ist, datenbankübergreifende Lookups durchzuführen, die für eine effiziente Verarbeitung der Dokumente erforderlich sind. Daher muss der Datenbank zusätzliche Bedeutung beigemessen werden. Benennungskonventionen von Dokumentensammlungen in den einzelnen EDW-Ebenen. Als Alternative zu Lookups kann der Integrationsprozess die notwendigen Joins zwischen Datensätzen durchführen.
Die erste Schicht in MongoDB repliziert die Daten aus der Data Lake die für die Informationsbereitstellung erforderlich sind. Sobald eine Informationsanforderung für ein Dashboard oder einen Bericht für die Entwicklung ausgewählt wurde, werden die Quelldaten im Data Lake identifiziert und ohne weitere Änderung der eingehenden Daten in die Staging-Sammlung gesourct. Das kürzlich veröffentlichte MongoDB Data Lake ermöglicht die Abfrage von S3-basierten Data Lakes direkt über die MongoDB Query Language. Nachdem die Daten direkt MongoDB zur Verfügung gestellt wurden, werden die Daten nachgelagert weiterverarbeitet.
Die zweite Schicht in MongoDB ist die Enterprise Document Warehouse (EDW)-Schicht, die nach dem Data Vault-Konzept aufgebaut ist. Beim Laden der EDW-Schicht wird zwischen unmodifizierten Rohdaten aus der Quellensammlung und der Implementierung der Geschäftslogik unterschieden. Die unmodifizierten Rohdaten werden in die Schicht Raw Data Vault eingespeist. Sobald die eingehenden Daten gespeichert wurden, werden in einem weiteren Schritt beim Laden sowie bei der Implementierung des Business Vault Geschäftsregeln angewendet.
Nachdem die Geschäftsregeln auf die Rohdaten in Raw Data Vault angewendet wurden, wird das Zielschema aus dem Data Vault-Modell, Raw Data Vault und Business Vault, in die Informationsmarkt Schicht in der Architektur.
Aufgrund der Architektur von MongoDB bestehen alle Schichten aus Sets von Dokumentensammlungen. Daher müssen Data Vault-Entitäten in Raw Data Vault und Business Vault sowie information mart-Entitäten, häufig Dimensionen und Fakten, in Dokumentensammlungen modelliert werden.
Viele Business-Intelligence-Tools für Dashboards oder Berichte bevorzugen jedoch eine relationale Struktur anstelle von Dokumentensammlungen, da viele Business-Intelligence-Tools keine Dokumentensammlungen verstehen. Um dieses Problem zu lösen, bietet MongoDB einen BI-Connector, der die Dokumentensammlung in relationale Strukturen umwandeln kann. Dies wird sich später im Prozess als nützlich erweisen, sollte aber bei der Gestaltung der Dokumente im information mart in Betracht gezogen werden.
Diese Architektur hat viele Vorteile: Erstens trennt sie die data warehousing von der Informationsverarbeitung. Dies vereinfacht den Aufbau eines revisionssicheren Unternehmensdokumentenlagers, das erweitert und verändert werden kann. wendig Mode.
Es hilft uns auch, die Daten in MongoDB für viele Informationsanforderungen wiederzuverwenden und so verschiedene Informationsabonnenten zu bedienen. Einer der Vorteile des Data Vault-Modells ist außerdem, dass es Muster gibt, um jedes beliebige Zielmodell direkt aus einem Data Vault-Modell abzuleiten, einschließlich der ursprünglichen Struktur, falls erforderlich, Sternschemata, Schneeflockenschemata, vollständig denormalisierte Schemata, normalisierte Schemata, die oft für Ad-hoc-Berichte verwendet werden, und jede andere Struktur.
Die Dokumente werden mit Hilfe von MongoDBs Aggregationspipelines, der bevorzugten Methode zur Dokumentenverarbeitung in MongoDB, von Schicht zu Schicht geladen. In den folgenden Artikeln unserer Reihe werden wir die Modellierungsentscheidungen für die einzelnen Ebenen und die geeigneten Aggregationspipelines zum Laden der Sammlungen jeder Ebene erörtern.
Kommentare? Anregungen? Fragen?
Wir würden uns freuen, von Ihnen im Kommentarbereich unten zu hören!
Wie Sie Updates und Support erhalten
Bitte senden Sie Anfragen und Funktionswünsche an [email protected].
Für Anfragen zu Data Vault-Schulungen und Schulungen vor Ort wenden Sie sich bitte an [email protected] oder registrieren Sie sich unter www.scalefree.com.
Zur Unterstützung bei der Erstellung von Visual Data Vault-Zeichnungen in Microsoft Visio wurde eine Schablone entwickelt, mit der Data Vault-Modelle gezeichnet werden können. Die Schablone ist erhältlich bei www.visualdatavault.com.
