Business users expect their data warehouse systems to load and prepare more and more data, regarding the variety, volume, and velocity of data. Also, the workload that is put on typical data warehouse environments is increasing more and more, especially if the initial version of the warehouse has become a success with its first users. Therefore, scalability has multiple dimensions. Last month we talked about Satellitesdie im Hinblick auf die Skalierbarkeit eine wichtige Rolle spielen. Wir erklären nun, wie man strukturierte und unstrukturierte Daten mit einer hybriden Architektur kombinieren kann.
In diesem Artikel:
Logical Data Vault 2.0 Architecture
Die Data Vault 2.0 Architektur is based on three layers: the staging area which collects the raw data from the source systems, the Enterprise Data Warehouse layer, modeled as a Data Vault 2.0 model, and the information delivery layer with Informationskataloge wie Sternschemata und andere Strukturen. Die Architektur unterstützt sowohl das Batch-Laden von Quellsystemen als auch das Laden in Echtzeit aus dem Enterprise Service Bus (ESB) oder einer anderen serviceorientierten Architektur (SOA).
The following diagram shows the most basic logical Data Vault 2.0 architecture:
In diesem Fall werden die strukturierten Daten aus den Quellsystemen zunächst in den Staging-Bereich geladen, um die Betriebs-/Leistungsbelastung durch die operativen Quellsysteme zu verringern. Sie werden dann unverändert in das Raw Data Vault geladen, das die Enterprise Data Warehouse-Schicht darstellt. Nachdem die Daten in dieses Data Vault-Modell (mit Hubs, Links und Satelliten) geladen wurden, werden die Geschäftsregeln im Business Vault auf die Daten im Raw Data Vault angewendet. Sobald die Geschäftslogik angewendet wurde, werden sowohl das Raw Data Vault als auch das Business Vault zusammengeführt und in das Geschäftsmodell für die Informationsbereitstellung in den Information Marts umstrukturiert. Der Geschäftsanwender verwendet Dashboard-Anwendungen (oder Berichtsanwendungen) für den Zugriff auf die Informationen in den Information Marts.
Die Architektur erlaubt es, die Geschäftsregeln im Business Vault mit einer Mischung aus verschiedenen Technologien zu implementieren, wie z.B. SQL-basierte Virtualisierung (typischerweise unter Verwendung von SQL-Views) und externe Tools, wie z.B. Business Rule Management Systeme (BRMS).
But it is also possible to integrate unstructured NoSQL database systems using a hybrid architecture. Due to the platform independence of Data Vault 2.0, NoSQL can be used for every data warehouse layer, including the stage area, the enterprise data warehouse layer, and information delivery. Therefore, the NoSQL database could be used as a staging area and load data into the relational Data Vault layer. However it could also be integrated both ways with the Data Vault layer via a gehashter Business Key. In this case, it would become a hybrid architecture solution and information marts would consume data from both environments.
Hybride Architektur
The standard Data Vault 2.0 architecture in figure 1 focuses on structured data. Because more and more enterprise data is semi-structured or unstructured, the recommended best practice for a new enterprise data warehouse is to use a hybrid architecture based on a Hadoop cluster, as shown in the next figure:
In this hybrid architecture modification, the relational staging area is replaced by a HDFS based staging area which captures all unstructured and structured data. While capturing structured data on the HDFS appears as overhead at first glance, this strategy actually reduces the burden of the source system by making sure that the source data is always being extracted, regardless of any structural changes. The data is then extracted using Apache Drill, Hive External or similar technologies.
Es ist auch möglich, das Raw Data Vault und den Business Vault (die strukturierten Daten im Data Vault-Modell) auf Bienenstock Intern.