Enterprise Data Warehouse (EDW) Systeme zielen darauf ab, echte Business Intelligence (BI) für das datengesteuerte Unternehmen bereitzustellen. Unternehmen müssen sich mit kritischen Metriken befassen, die in diesen vitalen, lebendigen Daten enthalten sind. Ein wesentliches Ziel dieser Enterprise Data Warehouse-Systeme ist die Bereitstellung eines grundlegenden Datenintegrationsprozesses, der letztendlich eine Vielzahl von Berichtsanforderungen unterstützt. Der Aufbau dieser Systeme ist mit erheblichem Aufwand für Design, Entwicklung, Verwaltung und Betrieb verbunden. Wenn sich vorgelagerte Geschäftssysteme, Strukturen oder Regeln ändern, keine konsistenten Daten liefern oder neue Systemintegrationslösungen erfordern, stellen die Mindestanforderungen an das Reengineering uns vor das Problem Nr. 1: Die einzige Konstante ist der Wandel; wie gut kann sich also eine EDW/BI-Lösung anpassen?
„Es ist nicht die stärkste Spezies, die überlebt, noch die intelligenteste, die überlebt. Es ist diejenige, die sich am besten an Veränderungen anpassen kann.“ Charles Darwin
Die Nutzung und Analyse von Geschäftsdaten durch verschiedene Nutzergruppen ist zu einer kritischen Realität geworden, um einen Wettbewerbsvorteil aufrechtzuerhalten, doch die heutigen technologischen Realitäten erfordern oft hochqualifizierte Endnutzer. Das Erfassen, Verarbeiten, Umwandeln, Bereinigen und Erstellen von Berichten über diese Daten mag verständlich sein, aber in den meisten Fällen kann die schiere Datenmenge überwältigend sein; Yup, Problem Nr. 2: Really Big Data; oft charakterisiert als: Volume, Velocity, Variety, Variability, Veracity, Visualization, & Value!
Die Entwicklung effektiver und effizienter EDW/BI-Systeme, die für die Nutzbarkeit und die Berichterstattung über diese Daten vereinfacht sind, wird selbst für erfahrene Ingenieurteams schnell zu einer entmutigenden und oft schwierigen technischen Tortur. Es sind mehrere integrierte Technologien erforderlich, von Datenbanksystemen, Datenverarbeitungswerkzeugen (ETL) wie Talend, verschiedenen Programmiersprachen, Verwaltungs-, Berichts- und interaktiver Grafiksoftware bis hin zu Hochleistungsnetzwerken und leistungsstarken Computern mit sehr großen Speicherkapazitäten. Das Design, die Erstellung, die Bereitstellung und der Support von robusten, mühelosen EDW/BI-Systemen für eine vereinfachte, intelligente Nutzung sind, Sie haben es erraten, Problem Nr. 3: Komplexität!
Oft sehen wir umfassende und elegante Lösungen, die dem Geschäftsanwender geliefert werden, ohne die wahren Bedürfnisse des Unternehmens zu verstehen. Man sagt uns, dass dies aufgrund von technischen Anforderungen (Einschränkungen; zwinker, zwinker) und/oder Designparametern (Mangel an Funktionen; zwinker, zwinker) einfach so ist. Daher Problem Nr. 4: Der Unternehmensbereich: Passen Sie die Daten an die Anforderungen des Unternehmens an, nicht umgekehrt!
Wenn sich die vorgelagerten Systeme ändern (und das werden sie), wenn die EDW/BI-Technologie voranschreitet (und das muss sie), wenn die dynamische Komplexität der Daten vorherrscht (und das wird sie unweigerlich), müssen immer wieder neue Datenquellen in den Mix aufgenommen werden. Diese sind in der Regel nicht vorhersehbar und nicht geplant. Die Auswirkungen der Integration können enorm sein und erfordern oft eine vollständige Erneuerung der aggregierten Daten; daher Problem Nr. 5: Flexibilität; oder das Fehlen davon!
Wie lösen wir also diese Probleme? Nun …
Bill Inmon, der weithin als der Vater des Data Warehousing gilt, definiert ein Data Warehouse als:
„Eine themenorientierte, nicht flüchtige, zeitvariable Sammlung von Daten zur Unterstützung von Managemententscheidungen“
(http://en.wikipedia.org/wiki/Bill_Inmon)
Ralph Kimball (http://en.wikipedia.org/wiki/Ralph_Kimball), ein bahnbrechender Data-Warehousing-Architekt, entwickelte die Methode der „dimensionalen Modellierung“, die heute als De-facto-Standard im Bereich der Entscheidungsunterstützung gilt. Das dimensionale Modell (auch „Sternschema“ genannt) unterscheidet sich von der Methodik der „normalisierten Modellierung“ von Inman (manchmal auch „Schneeflockenschema“ genannt). In Kimballs Sternschema werden Transaktionsdaten in aggregierte „Fakten“ partitioniert, die von referenziellen „Dimensionen“ umgeben sind, die Deskriptoren enthalten, die die Fakten definieren. Das normalisierte Modell (3NF oder „dritte Normalform“) speichert Daten in zusammenhängenden „Tabellen“ und folgt dabei den von E. F. Codd und Raymond F. Boyce in den frühen 1970er Jahren aufgestellten Regeln für das Design relationaler Datenbanken, die Datenredundanz ausschließen. Beide Methoden, die unter EDW/BI-Architekten heftig diskutiert werden, weisen Schwächen auf, wenn es um unvermeidliche Änderungen in den Systemen geht, die das Data Warehouse speisen, und um die Bereinigung von Daten, um den strengen Anforderungen der Methode zu entsprechen.
Der OLAP-Würfel (für „online analytical processing“) ist eine Datenstruktur, die eine schnelle Analyse von Daten aus verschiedenen Perspektiven ermöglicht. Die Würfelstruktur wird entweder aus einem Star- oder einem Snowflake-Schema erstellt, das als Metadaten gespeichert wird, aus denen man die Daten auf verschiedene Weise betrachten oder „drehen“ kann. Im Allgemeinen haben Würfel eine zeitbasierte Dimension, die eine historische Darstellung der Daten unterstützt. Die Erstellung von OLAP-Würfeln kann sehr kostspielig sein und erzeugt oft eine beträchtliche Menge an Daten, die wenig oder gar nicht von Nutzen sind. Die 80/20-Regel scheint in vielen Fällen zuzutreffen (nur 20 % der OLAP-Würfeldaten erweisen sich als nützlich), was die Frage aufwirft: Bietet ein OLAP-Würfel, der auf einer traditionellen Architektur aufbaut, wirklich einen ausreichenden ROI? Oft ist die Antwort ein klares NEIN! Langlebige EDW/BI-Systeme müssen einen echten Wert liefern.
Erfahren Sie, wie Talend Tipico dabei geholfen hat, riesige Datenmengen in hochmoderne Business Intelligence zu verwandeln.
Ein frischer Ansatz
Der Data Vault ist eine hybride Datenmodellierungsmethode, die historische Daten aus verschiedenen Quellen darstellt und so konzipiert ist, dass sie gegenüber Umweltveränderungen widerstandsfähig ist. Dan Linstedt, der Schöpfer der Methode, die ursprünglich 1990 entwickelt und im Jahr 2000 als öffentliche Modellierungsmethode veröffentlicht wurde, beschreibt eine daraus resultierende Data Vault-Datenbank wie folgt:
„Ein detailorientierter, historisch nachverfolgbarer und eindeutig verknüpfter Satz normalisierter Tabellen, die einen oder mehrere Funktionsbereiche des Unternehmens unterstützen. Es handelt sich um einen hybriden Ansatz, der die besten Eigenschaften von 3NF und Star Schemas umfasst. Das Design ist flexibel, skalierbar, konsistent und an die Bedürfnisse des Unternehmens anpassbar.“
(http://en.wikipedia.org/wiki/Data_Vault_Modeling)
Der Data Vault ist auf den Geschäftsprozess ausgerichtet und verfügt als Datenintegrationsarchitektur über robuste Standards und Definitionsmethoden, die Informationen zusammenführen, um sie sinnvoll zu nutzen. Das Data Vault-Modell besteht aus drei grundlegenden Tabellentypen:
HUB (blau): enthält eine Liste von eindeutigen Geschäftsschlüsseln mit einem eigenen Ersatzschlüssel. Metadaten, die den Ursprung des Geschäftsschlüssels oder die „Quelle“ des Datensatzes beschreiben, werden ebenfalls gespeichert, um zu verfolgen, wo und wann die Daten entstanden sind.
LNK (rot): stellt Beziehungen zwischen Geschäftsschlüsseln her (typischerweise Hubs, aber Links können auf andere Links verweisen); beschreibt im Wesentlichen eine Beziehung von vielen zu vielen. Links werden häufig verwendet, um Änderungen in der Datengranularität zu bewältigen und die Auswirkungen des Hinzufügens eines neuen Geschäftsschlüssels zu einem verknüpften Hub zu verringern.
SAT (gelb): enthält beschreibende Attribute, die sich im Laufe der Zeit ändern können (ähnlich einer sich langsam ändernden Dimension vom Typ Kimball II). Während Hubs und Links die Struktur des Datenmodells bilden, enthalten Satelliten zeitliche und beschreibende Attribute einschließlich Metadaten, die sie mit ihren übergeordneten Hub- oder Link-Tabellen verbinden. Metadatenattribute innerhalb einer Satellitentabelle, die ein Datum enthalten, an dem der Datensatz gültig wurde und ein Datum, an dem er ablief, bieten leistungsstarke historische Fähigkeiten, die Abfragen ermöglichen, die „zurück in die Zeit“ gehen können.
Der Data Vault-Ansatz bietet mehrere entscheidende Vorteile:
– Vereinfacht den Dateneingabeprozess
– Entfernt die Bereinigungsanforderung eines Star-Schemas
– Bietet sofortige Auditierbarkeit für HIPPA und andere Vorschriften
– Konzentriert sich auf das eigentliche Problem, anstatt es zu umprogrammieren
– Erlaubt das einfache Hinzufügen neuer Datenquellen ohne Unterbrechung des bestehenden Schemas
Einfach gesagt, der Data Vault ist sowohl eine Datenmodellierungstechnik als auch eine Methodik, die historische Daten, Audits und die Nachverfolgung von Daten ermöglicht.
„Der Data Vault ist die optimale Wahl für die Modellierung des EDW im Rahmen des DW 2.0“
Bill Inmon
Anpassungsfähig
Durch die Trennung von Geschäftsschlüsseln (da sie im Allgemeinen statisch sind) und den Assoziationen zwischen ihnen und ihren beschreibenden Attributen begegnet ein Data Vault dem Problem der Veränderung der Umgebung. Mit diesen Schlüsseln als strukturellem Rückgrat eines Data Warehouse können alle verwandten Daten um sie herum organisiert werden. Diese Hubs (Business Keys), Links (Assoziationen) und SAT (beschreibende Attribute) unterstützen eine hochgradig anpassungsfähige Datenstruktur bei gleichzeitiger Wahrung eines hohen Maßes an Datenintegrität. Dan Linstedt vergleicht den Data Vault oft mit einer vereinfachten Ansicht des Gehirns, in der Neuronen mit Hubs und Satelliten verbunden sind und Dendriten Links (Informationsvektoren) darstellen. Einige Links sind wie Synapsen (Vektoren in die entgegengesetzte Richtung). Sie können spontan erstellt oder gelöscht werden, wenn sich die Geschäftsbeziehungen ändern, wodurch das Datenmodell bei Bedarf automatisch umgestaltet wird, ohne dass die bestehenden Datenstrukturen beeinträchtigt werden. Problem Nr. 1 gelöst!
Big Data
Data Vault v2.0 kam 2013 auf den Markt und beinhaltet eine nahtlose Integration von Big-Data-Technologien zusammen mit Methodik, Architektur und Best-Practice-Implementierungen. Durch diese Anpassung können sehr große Datenmengen problemlos in einen Data Vault integriert werden, der für die Speicherung mit Produkten wie Hadoop, Infobright, MongoDB und vielen anderen NoSQL-Optionen ausgelegt ist. Durch die Eliminierung der Bereinigungsanforderungen eines Star-Schema-Designs zeichnet sich der Data Vault beim Umgang mit riesigen Datensätzen aus, indem er die Ingestionszeiten verkürzt und parallele Einfügungen ermöglicht, die die Leistung von Big-Data-Systemen nutzen. Problem Nr. 2 gelöst!
Vereinfachung
Die Erstellung eines effektiven und effizienten Data Vault-Modells ist schnell erledigt, wenn Sie die Grundlagen der drei Tabellentypen verstehen: Hub, Satellite und Link! Die Identifizierung der Geschäftsschlüssel und die Definition der Hubs ist immer der beste Ausgangspunkt. Die Hub-Satellites stellen dann die Spalten der Quelltabelle dar, die sich ändern können, und die Link-Tabellen verbinden alles miteinander. Denken Sie daran, dass es auch möglich ist, Link-Satellite-Tabellen zu haben. Sobald Sie diese Konzepte verstanden haben, ist es ganz einfach. Nachdem Sie Ihr Data Vault-Modell fertiggestellt haben, müssen Sie als Nächstes den ETL-Datenintegrationsprozess erstellen, um es zu befüllen. Ein Data Vault Datenmodell ist zwar nicht auf EDW/BI Lösungen beschränkt, aber immer wenn Sie Daten aus einer Datenquelle in ein Zielsystem übertragen müssen, ist ein Datenintegrationsprozess erforderlich. Talend hat es sich zur Aufgabe gemacht, das datengesteuerte Unternehmen zu verbinden.
Mit seiner Suite von Integrationssoftware vereinfacht Talend den Entwicklungsprozess, reduziert die Lernkurve und senkt die Gesamtbetriebskosten mit einer einheitlichen, offenen und berechenbaren ETL-Plattform. Talend ist eine bewährte ETL-Technologie und kann mit Sicherheit dazu verwendet werden, ein robustes EDW/BI-System, das auf einem Data Vault-Datenmodell aufbaut, zu befüllen und zu pflegen. Problem Nr. 3 gelöst!
Ihr Geschäft
Der Data Vault definiert im Wesentlichen die Ontologie eines Unternehmens, indem er die Geschäftsdomäne und die Beziehungen darin beschreibt. Die Verarbeitung von Geschäftsregeln muss vor dem Auffüllen eines Star-Schemas erfolgen. Mit einem Data Vault können Sie diese nach der EDW-Ingestion nachgelagert einfügen. Eine weitere Data Vault-Philosophie ist, dass alle Daten relevant sind, auch wenn sie falsch sind. Dan Linstedt meint, dass falsche Daten ein geschäftliches Problem sind, kein technisches. Ich stimme ihm zu! Ein EDW ist wirklich nicht der richtige Ort, um schlechte Daten zu bereinigen (cleanse). Die einfache Prämisse des Data Vault ist es, 100 % der Quelldaten zu 100 % der Zeit aufzunehmen, egal ob gut, schlecht oder hässlich. In der heutigen Welt ist die Nachvollziehbarkeit und Rückverfolgbarkeit aller Daten im Data Warehouse daher eine Standardanforderung. Dieses Datenmodell wurde speziell für die Anforderungen der heutigen EDW/BI-Systeme entwickelt. Problem Nr. 4 gelöst!
„Wer den Data Vault versteht, versteht das Geschäft“
(http://danlinstedt.com)
Flexibel
Die Data Vault-Methodik basiert auf den Best Practices von SEI/CMMI Level 5 und umfasst viele ihrer Komponenten, die mit den Best Practices von Six Sigma, TQM und SDLC (Agile) kombiniert werden. Data Vault-Projekte haben kurze, kontrollierte Release-Zyklen und können aus einem Produktions-Release alle 2 oder 3 Wochen bestehen, wodurch automatisch die wiederholbaren, konsistenten und messbaren Projekte übernommen werden, die bei CMMI Level 5 erwartet werden. Wenn neue Datenquellen hinzugefügt werden müssen, sind ähnliche Geschäftsschlüssel wahrscheinlich, neue Hubs-Satelliten-Links können hinzugefügt und dann weiter mit bestehenden Data Vault-Strukturen verknüpft werden, ohne dass das bestehende Datenmodell geändert wird. Problem #5 Gelöst!
Abschluss
Zusammenfassend lässt sich sagen, dass die Data Vault-Modellierung und -Methodik die Elemente der oben genannten Probleme löst:
– Es passt sich an eine sich ändernde Geschäftsumgebung an
– Es unterstützt sehr große Datensätze
– Es vereinfacht die Komplexität des EDW/BI-Designs
– Es erhöht die Benutzerfreundlichkeit für Geschäftsanwender, da es nach der Geschäftsdomäne modelliert ist
– neue Datenquellen hinzugefügt werden können, ohne das bestehende Design zu beeinträchtigen
Dieser technologische Fortschritt erweist sich bereits als äußerst effektiv und effizient. Der Data Vault ist einfach zu entwerfen, zu erstellen, zu befüllen und zu ändern und ist ein klarer Gewinner. Sehr cool! Möchten Sie einen?
Besuchen Sie http://learndatavault.com oder http://www.keyldv.com/lms, um mehr über die Modellierung und Methodik von Data Vault zu erfahren.
Wenn Sie schon dabei sind, laden Sie eine kostenlose Testversion von Talend Cloud Integration Platform herunter, um zu sehen, was Ihre Daten wirklich leisten können.