Ein leben ohne ETL ist möglich!

In diesem Artikel erkläre ich Ihnen, wie Sie den mit ETL verbundenen finanziellen und zeitlichen Aufwand beträchtlich reduzieren können. Dazu stelle ich Ihnen den Ansatz von MarkLogic vor. Tatsächlich heißt das Ziel mit MarkLogic nicht wirklich „Weg mit ETL“, sondern es wird ein neuer, moderner Ansatz verfolgt, bei dem Sie Daten in jedem Format, laden, durchsuchen, harmonisieren und anreichern können. Diesen Ansatz nennen wir den „E-L-T-Ansatz“ — Extrahieren, Laden und dann Transformieren. Unsere Kunden arbeiten regelmäßig mit diesem MarkLogic-Ansatz, da er schneller und flexibler ist. Das heißt: Bis zum Produktivstart dauert es statt Jahren nur Wochen oder Monate.

Aber ich greife voraus. Betrachten wir zunächst, wie die Integration von Daten bisher vonstatten gegangen ist: Extrahieren, Transformieren, Laden.

  • Extrahieren: der Prozess des Herausholens von Daten aus den Quelldatenbanken. Bei diesem Schritt wird in der Regel auch überprüft, ob die Extrahierung wie erwartet ausgeführt wurde.
  • Transformieren: der Prozess der Änderung des Datenschemas, um es mit anderen Datenquellen zu vereinheitlichen und an das Zielschema anzupassen, bevor Daten in die Zieldatenbank geladen werden. Hierbei kann es sich um einfache Formatierungsarbeiten wie das Aktualisieren eines Datenformats oder das Auswählen der aufzunehmenden Spalten handeln. Oft ist der Prozess jedoch komplexer und umfasst das Pivotieren, Aggregation, Disaggregation, Übersetzung, Verschlüsselung und so manches mehr.
  • Laden: der Prozess des Ladens oder Aufnehmens von Daten in die endgültige Zieldatenbank. Dabei sind strategische Entscheidungen zu treffen über den Zeitpunkt, Häufigkeit von Ladevorgängen und darüber, ob vorhandene Daten durch die neu geladenen überschrieben oder ergänzt werden sollen.

Der ETL-Prozess mag zunächst wie eine einfache Abfolge von 3 Schritten erscheinen. In Wirklichkeit ist er jedoch sehr kostspielig und zeitaufwendig.

ETL-Software ist teuer

Zur besseren Bewältigung des Prozesses werden vielerlei Tools angeboten. Beispiele für Anbieter von ETL-Software sind: Informatica (PowerCenter, PowerExchange, Data Services und 15 weitere Produkte), IBM (Infosphere-Produkt-Suite), SAP (Data Services, Process Orchestration, Hana Cloud Integration usw.), Oracle (Data Integrator, GoldenGate, Data Service Integrator usw.), SAS (Data Management, Federation Server, SAS/ACCESS, Data Loader für Hadoop, Event Stream Processing) und der Open-Source-Anbieter Talend (Open Studio, Data Fabric usw.). Natürlich gibt es viele Anbieter, die sich gerne ein Stück vom ETL-Kuchen abschneiden möchten, und ich bin immer wieder überrascht, wie viele ETL-Tools sich Unternehmen leisten.

Insgesamt geben Unternehmen jedes Jahr 3,5 Mrd. US-Dollar für ETL-Software zur Datenintegration aus (Gartner. Prognose: Weltweite Märkte für Unternehmenssoftware), 2013-2020, Update 1Q16. 17. März 2016). All diese Tools dienen dazu, Daten für das Laden in eine operationale Datenbank oder in ein Data Warehouse vorzubereiten. Die ETL-Arbeit nimmt jedoch einen überproportionalen Teil der Projektkosten und des Budgets in Anspruch. Tatsächlich können 60 bis 80 Prozent der Gesamtkosten eines Data-Warehouse-Projekts auf ETL-Software und -Prozesse (TDWI, Evaluating ETL and Data Integration Platforms (TDWI, Bewertung von ETL- und Datenintegrations-Plattformen)) entfallen.

ETL erfordert einen großen Zeit- und Arbeitsaufwand

Schon die Beschaffung der Tools ist kostspielig – aber das ist noch lange nicht alles. Die Einrichtung, Nutzung und Verwaltung der ETL-Tools und Datenbankverbindungen erfordert einen großen Arbeitsaufwand. Nach der Einrichtung des Tools müssen die Datenquellen zusammengestellt und dann die Datenmodelle erarbeitet werden. Außerdem sind die im Laufe des Prozesses auftretenden Änderungen zu verwalten. Die Zahlen zeigen, dass große Datenintegrationsprojekte bei Fortune-500-Unternehmen zwei bis fünf Jahre dauern. Dies versteht sich vom Projektstart bis zum Produktivstart der Anwendung! So summieren sich die Gesamtkosten von ETL- und Datenintegrationsprojekten auf ungefähr 600 Mrd. US-Dollar pro Jahr (Schätzung von MuleSoft). Diese Schätzung scheint mir sehr hoch angesetzt, aber ich glaube, wir stimmen alle darin überein, dass ETL ein wirklich teures Unterfangen ist.


Reduzierung des Kosten- und Zeitaufwands für ETL

MarkLogic verfolgt einen anderen Ansatz bei der Datenintegration. Aber worin unterscheidet sich dieser Ansatz?

Erstens kann MarkLogic mehrere Schemas in der gleichen Datenbank verwalten, was bedeutet, dass Sie Daten in jedem Format laden können, ohne im Vorfeld ein einziges „Über-Schema“ definieren und vereinbaren zu müssen. Damit können Sie schneller beginnen. Außerdem erübrigt sich eine Menge mühsamer Nacharbeit, wie sie bei relationalen Datenbanken in der Regel anfällt, wenn eine Änderung erforderlich wird oder eine neue Datenquelle hinzukommt.

Zweitens ermöglicht MarkLogic die Harmonisierung und Anreicherung der Daten innerhalb von MarkLogic. Sie können also nach dem Laden die gesamte Transformationsarbeit (das „T“ in ETL) direkt in MarkLogic ausführen – genau so zuverlässig wie bei einer Transaktionsdatenbank. Und Sie brauchen dafür kein separates Tool.

Sie möchten wissen, wie viel Geld und Zeit dadurch eingespart wird?

Ein typisches MarkLogic-Datenintegrationsprojekt lässt sich viermal schneller abwickeln als dies bei Einsatz herkömmlicher Methoden der Datenintegration mit einer relationalen Datenbank und ETL-Tools der Fall wäre. Kunden, die MarkLogic verwenden, haben mit vielen großen Projekten in unterschiedlichen Branchen den Beweis geliefert. Und es geht nicht nur um Geschwindigkeit – es wird auch eine bessere Datenqualität erzielt. Darauf gehen wir später noch genauer ein. Betrachten wir zunächst die Datenintegration nach herkömmlichem Ansatz.


Herausforderungen bei relationalen Datenbanken und ETL Prozessen

Bei der Integration von Daten aus Datensilos arbeiten die meisten Unternehmen mit mehreren relationalen Datenbanken. Sie versuchen, die Daten aus diesen bereits vorhandenen Datenbanken effizient in eine andere Datenbank zu überführen.

Die häufigsten Gründe für die Integration von Daten sind:

  • Einführung einer neuen Anwendung, die auch auf bereits vorhandene Daten zugreifen soll
  • Entwicklung einer einheitlichen 360-Grad-Sicht auf Datenbestände in einem analytischen Data Warehouse
  • Entwicklung eines neuen Systems für das Master Data Management (MDM)
  • Migration von Daten zwischen operativen Systemen zu internen oder unternehmensübergreifenden Zwecken
  • Unterstützung von Governance, Audits oder Monitoring-Aufgaben
  • Fusionen und Übernahmen
  • dauerhafte Speicherung von Daten, die aufbewahrt werden sollen

In jedem Szenario gestaltet sich der Prozess zur Integration von Daten etwas anders. Dies hängt vom Umfang des Projekts, der Art der Datenquellen und den verwendeten Tools ab. Der allgemeine Prozess erfordert stets umfangreiche ETL-Prozesse, um heterogene Daten für ein einzelnes Schema in homogene umzuwandeln. Dies ist unabhängig vom Use Case oder Muster. Wenn Sie diesen Prozess ausführen, sieht dies gewöhnlich etwa so aus:

ETL mit RDBMS

1. Alle Schemata zusammenstellen

Zuerst müssen Sie wissen, welche Daten Sie besitzen und wie diese organisiert sind. Dazu müssen Sie alle Schemas zusammenbringen, die beschreiben, wie Ihre Datenbestände in einem „Superset“ gespeichert sind. Diese Informationen sind in der Regel nicht in der Datenbank selbst enthalten. Schemata werden gewöhnlich in Form von Entity-Relationship-Diagrammen (ERD) dargestellt, die ausgedruckt und ausgehängt werden oder irgendwo in einem Ordner abgelegt sind. Bei meiner Consulting-Arbeit für andere Unternehmen habe ich festgestellt, dass dieser Ordner meist bei dem Datenbankadministrator zu finden ist, der schon am längsten für die Firma arbeitet.

2. Schemata analysieren

Wenn Ihnen alle Schemata vorliegen, müssen Sie einen Blick darauf werfen und herausfinden, was sie bedeuten, wie sie funktionieren und was sie gemeinsam haben. Sie müssen Ihre Daten (und in manchen Fällen auch den Code) ggf. näher untersuchen, um sie richtig zu verstehen. Wenn Sie zum Beispiel eine Entität „Kunde“ haben, müssen Sie sich vielleicht verschiedene Zeilen in verschiedenen Tabellen ansehen, um herauszufinden, was in der jeweiligen Datenbank unter „Kunde“ zu verstehen ist.

3. Bestimmen, was weggelassen werden kann

Wenn Sie versuchen, alle Ihre Schemata zu integrieren UND alle Daten zu behalten, werden Sie nie fertig. Sie entscheiden also, welche Daten nicht so wichtig sind, und übernehmen nur die Daten, die für das Projekt, an dem Sie arbeiten, wirklich benötigt werden. Nehmen wir an, Sie stehen vor einem Datenintegrationsprojekt mit 30 Schemas. Hier werden Sie sich ganz bestimmt überlegen, ob Sie einige Daten mit niedriger Priorität weglassen können, damit Sie die Modellierung nicht 30-mal vornehmen müssen. Vielleicht ist ja der Transaktionsstatus aus dem ersten Modell für die Anwendung, die Sie mit den kombinierten Daten erstellen, nicht unbedingt erforderlich. Vielleicht kommen Sie auch ohne die Lieferadresse aus und könnten das Modell beträchtlich vereinfachen, indem Sie nur eine Telefonnummer pro Kunde übernehmen … Sie wissen, was ich meine.

4. „Über-Schema“ entwickeln

Nun müssen Sie ein Schema entwickeln, das „über alles herrscht” – also ein Schema, in dem alle Daten einen Platz finden, die Sie aus den verschiedenen Quellsystemen übernehmen möchten. Neben der Planung des neuen Schemas müssen Sie auch entscheiden, wie die verschiedenen Fehler (zum Beispiel ungültige Daten in einem Eingabefeld) zu behandeln sind, wie die Metadaten über die Quelle jedes Datenelements beibehalten werden können und welche Transformationen vorgenommen wurden, damit sie in das neue Schema passen. Und wenn Sie Änderungen an Ihren Daten und Schemas erfassen möchten, müssen Sie sich auch Gedanken über die Versionierung machen.

5. ETL-Jobs schreiben und Daten laden

Nehmen wir an, Sie haben es bis hierher geschafft. Nun können Sie sich dem Verschieben der Daten zuwenden. Hierzu müssen Sie zunächst dafür sorgen, dass alle erforderlichen Transformationen durchgeführt werden. Danach können Sie mit dem Massenladen der transformierten Daten in Ihre neue Datenbank beginnen.

6. Bei Änderungen von vorne beginnen

Wenn eine neue Datenquelle hinzukommt oder während des Prozesses eine weitere Änderung vorgenommen wird, die sich auf das Schema auswirkt, müssen Sie ab Schritt 1 von Neuem beginnen – außer, Sie haben Glück und die neue Datenquelle lässt sich in das vorhandene Über-Schema einpassen. Aber oft wird in der neuen Datenquelle eine neue Viele-zu-Viele-Beziehung oder ein anderes Konzept der Daten eingeführt, was eine Änderung erfordert, was sich wiederum auf die vorhandenen Anwendungen auswirkt. Auch Sie kennen bestimmt Fälle, in denen eine Person plötzlich viele Adressen hat, wenn Sie nur eine erwarten, oder in denen die VARCHARs in einer Tabelle zum Problem werden.


Der Ansatz von MarkLogic im Hinblick auf „ETL“

Mit MarkLogic funktioniert die Datenintegration viel einfacher und schneller:

ETL mit MarkLogic

1. Daten in jedem Format laden

Sie laden zunächst Datenquellen in jedem Format in MarkLogic und verwenden vom 1. Tag an die integrierte MarkLogic-Suchfunktion (den Universalindex „Ask Anything“), um den Daten auf den Grund zu gehen. Sie brauchen kein allem übergeordnetes Schema zu erstellen. Sie können jederzeit weitere Daten laden, auch wenn diese einem anderen Schema unterliegen. MarkLogic kann problemlos in der gleichen Datenbank mit mehreren Schemata arbeiten, und alle Daten sind sofort durchsuchbar.

2. Daten harmonisieren

Dies entspricht ungefähr dem „T“ in ETL, unterscheidet sich jedoch vom herkömmlichen ETL-Prozess in zwei wichtigen Punkten. Erstens brauchen Sie keine Daten wegzulassen. Zweitens brauchen Sie nicht ALLE Daten zu transformieren. Wenn zum Beispiel in einem Schema „Postleitzahl“ und in einem anderen „PLZ“ verwendet wird, brauchen Sie nur die davon betroffenen Elemente in den Daten zu transformieren, um einheitlich nach „PLZ“ suchen zu können. Dabei nehmen Sie die Harmonisierung so vor, dass die ursprünglichen Daten unter „Postleitzahl“ nicht verloren gehen. Wir werden später näher darauf eingehen, wie dies in MarkLogic gehandhabt wird.

3. Daten anreichern

Zusätzlich zur Harmonisierung können Sie die Daten auch anreichern. Sie können ihnen zusätzlichen Kontext geben, damit ihre Bedeutung im Rahmen Ihres Geschäfts besser ersichtlich wird. Sie erweitern die Rohdaten aus Ihren Silos durch neue oder erweiterte Daten, um neue Anwendungen, Funktionen oder Analysen zu ermöglichen. Angenommen, Sie haben einen Datensatz mit einer Adresse. Diese Daten können Sie dann zum Beispiel durch GPS-Koordinaten anreichern – das ist eine Schemaänderung, die mit dem Dokumentenmodell von MarkLogic problemlos vorgenommen werden kann.

4. Weitere Daten laden

Da die Datenintegration mit MarkLogic iterativ und nicht in Form eines „Big Bang“ vonstatten geht, können Sie immer wieder neue Daten laden und Ihr Datenmodell nach Bedarf anpassen.

Ein Vorteil für Kunden besteht darin, dass sie bei diesem Prozess zur Datenintegration keine ETL-Tools benötigen. Sie können alle erforderlichen Arbeiten innerhalb von MarkLogic ausführen. Dies vereinfacht den Prozess, und die Kunden sparen viel Geld.

Außerdem geht alles viel schneller – und zwar etwa 4-mal schneller. Ein direkter Vergleich zwischen MarkLogic und dem herkömmlichen Ansatz mit relationaler Datenbank + ETL bei einer Reihe von Fortune-500-Unternehmen hat gezeigt, dass große MarkLogic-Projekte in der Regel nach 6 Monaten statt nach 2 Jahren betriebsbereit waren. Das Diagramm unten zeigt, wo typischerweise am meisten Zeit gespart wird:

MarkLogic data integration timeline

*Basiert auf einem Vergleich der Ist-Daten bei einem Fortune-500-Unternehmen und den durchschnittlichen Projektabwicklungszeiten bei anderen Kunden aus verschiedenen Branchen.

Zusätzlich zur schnelleren Projektabwicklung wird auch ein hochwertigeres Ergebnis erzielt. Statt ein weiteres Datensilo zu schaffen, können Sie nun Ihre Daten zentral und auf Schema-agnostische Weise verwalten, zueinander in Beziehung setzen und auf zuverlässige und transaktionsorientierte Art speichern. Im Gegensatz zu anderen NoSQL-Datenbanken kann MarkLogic dokumentübergreifende Transaktionen ausführen, die zu 100 % ACID-konform sind.

Sie können MarkLogic sowohl zum Betrieb als auch zur Analyse einsetzen, ohne endlose ETL-Zyklen in Kauf nehmen zu müssen. Ihre Daten können immer weiter wachsen, und Sie brauchen keine Zeit und Energie mehr dafür aufzuwenden, sie von Silo zu Silo zu transportieren. Die Überführung von Daten zwischen Silos ist nicht wertschöpfend und sollte daher auf ein Minimum reduziert werden.


Genauere Betrachtung

Schauen wir uns die einzelnen Schritte des Prozesses nun etwas gründlicher an, um zu sehen, wie MarkLogic diese Resultate bei der Integration von Daten aus Silos erzielt.


Schritt 1: Laden von Daten egal in welchem Format

laden in jedem Format mit MarkLogic

MarkLogic ist Schema-agnostisch und verwendet ein flexibles Datenmodell, bei dem Daten in Form von JSON- und XML-Dokumenten gespeichert werden. (Es ist auch eine Speicherung als RDF-Tripel möglich, aber wir konzentrieren uns zunächst auf Dokumente.) Dokumente sind flexible, hierarchische Datenstrukturen und unterscheiden sich dadurch vom strikten Zeilen- und Spaltenformat. MarkLogic kann Dokumente unterschiedlicher Formate verwalten. Das heißt, MarkLogic kann mit mehreren Schemata in der gleichen Datenbank arbeiten, und Sie können Ihre Daten ganz einfach in jedem Format laden. Das wiederum bedeutet:

  • Sie brauchen kein „Über-Schema“ zu erstellen, für das Sie alle Daten transformieren müssen, bevor Sie sie in die Datenbank laden können.
  • Sie brauchen sich nicht zu viel auf einmal vorzunehmen und können einen Teil Ihrer Daten sofort und andere erst später laden.
  • Sie benötigen kein ETL-Tool, um die zu ladenden Daten vorzubereiten und zu transformieren.

Zum Laden großer Mengen von Daten verwenden Kunden in der Regel ein Tool namens MarkLogic Content Pump (MLCP). MLCP ist ein effizientes und leistungsfähiges Tool, das die Transformation der Daten auf Wunsch gleich bei ihrer Aufnahme vornimmt. Sie haben aber auch die Möglichkeit, die Daten erst später in MarkLogic zu transformieren und zu harmonisieren. (Zu diesem Thema gibt es ein kurzes On-Demand-Tutorial-Video der MarkLogic University). Wenn Sie ohne MLCP arbeiten möchten, können Sie die Daten auch unter Nutzung anderer Methoden laden, zum Beispiel mit REST API, Java Client API, der Node.js- Client-API oder nativen Java- / .NET-Connectors.

Sobald die Daten geladen wurden, können Sie sie gleich durchsuchen, da sie sofort mit dem Universalindex „Ask Anything“ von MarkLogic indiziert werden. Dies funktioniert ähnlich wie eine Google-Suche in der Datenbank – Sie suchen nach einem Stichwort und sehen, in welchen Dokumenten es enthalten ist.

Die integrierte Suchfunktion ist für die Datenintegration außerordentlich wichtig. Denken Sie noch einmal an das Beispiel von weiter oben: Nehmen wir an, Sie haben Dokumente zu Kundendatensätzen geladen, die Informationen über Postleitzahlen enthalten. In einigen Datensätzen sind diese unter „PLZ“, in anderen unter „Postleitzahl“ aufgeführt. Mit MarkLogic können Sie nach „94111“ suchen und alle Datensätze mit der entsprechenden Postleitzahl finden. Bei einem relationalen Datenintegrationsprojekt müssten Sie alle Datensätze vor dem Laden harmonisieren. Die einzige andere Möglichkeit wäre, die Postleitzahl wegzulassen und nicht zu übernehmen. Sie würden eine Menge Zeit für die Harmonisierung aller Attribute von allen Entitäten in allen Quellschemata aufwenden, unabhängig davon, ob sie für die Abfragen benötigt werden. Die einzige andere Möglichkeit wäre, sie zurückzulassen.

enn Sie sich für die Phase des Ladens von Daten in jedem Format näher interessieren, lesen Sie in diesen Blog-Artikel: „What Load As Is Really Means“ (Was das Laden von Daten in jedem Format wirklich bedeutet).


Schritt 2: Harmonisieren der Daten

Datenharmonisierung mit MarkLogic

Wenn Sie die Daten geladen und das Ergebnis geprüft haben, stellt sich die Frage: Welchen Teil Ihrer Daten müssen Sie wirklich harmonisieren, um einheitliche Abfragen zu ermöglichen? Sie sollten Ihre idiomatischen (d. h. nativen, rohen) Daten einbeziehen – auch die ziemlich kuriosen – und als Ausgabe klare, kanonische Darstellungen erhalten.

Die Postleitzahl ist wahrscheinlich ein wichtiges Element, das harmonisiert werden muss, da Sie sie für Ihre Anwendung benötigen.

Wenn Sie sich entschieden haben, welche Daten Sie harmonisieren möchten, können Sie nach dem Umschlagprinzip ein mitwachsendes kanonisches Modell aufbauen (d. h. ein einfaches Muster zur Verwaltung vereinbarter Datendefinitionen). Das Umschlagprinzip ist eine Best-Practice-Methode zur Datenintegration in MarkLogic. Hierbei wird ein Umschlag erstellt, der nur die kanonischen Elemente enthält, die in allen Datenquellen einheitlich abgefragt werden sollen. Wenn Sie also meinen, dass Sie die Postleitzahl brauchen, können Sie dieses Element in den Umschlag stecken. Wenn Sie dann später noch „Ort“, „Bundesland“, „Lieblings-Fußballmannschaft“ oder ein anderes Element hinzufügen möchten, ist das problemlos möglich.

Hier ist ein Beispiel für das Umschlagprinzip, bei dem die ursprünglichen Quelldaten in jedem JSON-Dokument einem neuen Stamm mit der Eigenschaft „source“ hinzugefügt wurden:

// Document 1:
{	"envelope" : { "Zip" : [ 94111 ] } ,
	"source" : { "ID" : 1001 ,
		"Fname" : "Paul" ,
		"Lname" : "Jackson" ,
		"Phone" : "415-555-1212 | 415-555-1234" ,
		"SSN" : "123-45-6789" ,
		"Addr" : "123 Avenue Road" ,
		"City" : "San Francisco" ,
		"State" : "CA" ,
		"Zip" : 94111 } 
}

// Document 2:
{ 	"envelope" : { "Zip" : [ 94111 , 94070 ] } ,
	"source" : { "Customer_ID" : 2001 ,
		"Given_Name" : "Karen" ,
		"Family_Name" : "Bender" ,
		"Shipping_Address" : {
			"Street" : "324 Some Road" ,
			"City" : "San Francisco" ,
			"State" : "CA" ,
			"Postal" : "94111" ,
			"Country" : "USA" } ,
		"Billing_Address" : {
			"Street" : "847 Another Ave" ,
			"City" : "San Carlos" ,
			"State" : "CA" ,
			"Postal" : "94070" ,
			"Country" : "USA" } ,
		"Phone" : [ 
			{ "Type" : "Home" , "Number" : "415-555-6789" } ,
			{ "Type" : "Mobile" , "Number" : "415-555-6789" } ] } 
}

Bei diesem Beispiel könnte es wichtig sein, nach Postleitzahl („Zip“) zu harmonisieren, weil Sie eine Anwendung entwickeln, die zeigt, wie viele Kunden Sie in jeder Region haben und was diese gekauft haben. Außerdem soll ein weiterer Drilldown zu den Produktkategorien und -arten und zu den Produktbeschreibungstexten möglich sein. Ihre Regionen sind nach Postleitzahl definiert, daher müssen Sie konsistent nach „Zip“ abfragen.

Tatsächlich ist es ziemlich einfach, in MarkLogic einen Umschlag hinzuzufügen. Das folgende Beispiel soll dies veranschaulichen. Es handelt sich um eine Aktualisierungsabfrage, die Sie ausführen würden, um den Umschlag als JSON-Eigenschaft hinzuzufügen:

declareUpdate (); //get all documents from the “transform” collection
var docs = fn.collection(“transform”);
for (var doc of docs) {
	var transformed = {};  //add a property as an empty object to add further data the original document
	transformed.envelope = {};  //save the original document in a new property called “source”
	transformed.source = doc;
	xdmp.nodeReplace(doc, transformed);
}

Mit dem Umschlagmuster können Sie Ihr kanonisches Datenmodell auf flexible Weise von unten nach oben aufbauen. Ihr Modell kann die kombinierten Anforderungen aller Anwendungen und Dienste erfüllen, die diese Daten verwenden. Die einzelnen Anwendungen brauchen aber nur die von ihnen verwendeten Teile des Modells zu verstehen. Und weil jeder Datensatz ein konsistentes kanonisches Format enthält, können die Daten aus MarkLogic von allen verwendet werden, auch ohne die Quellschemas aus den vorgeordneten Systemen zu verstehen.


Schritt 3: Anreichern der Daten

Und wenn Sie Ihre Daten nicht nur transformieren und harmonisieren, sondern auch ergänzen und aufwerten möchten? Dann können Sie die Daten anreichern. Dieser optionale Schritt ist äußerst nützlich, da er dafür sorgt, dass wichtige Informationen direkt mit den Daten verknüpft werden, auf die sich sich beziehen. In anderen Datenbanken fehlen diese oft ganz oder sind nur schwer zu finden.

Im Beispiel unten werden dem Dokument über „metadata“ Metadaten hinzugefügt, die Informationen über die Quelle der Daten, das Datum ihrer Aufnahme und ihre Herkunft enthalten.

{	"metadata" : {
		"Source" : "Finance" ,
		"Date" : "2016-04-17" ,
		"Lineage" : "v01 transform" } ,
	"canonical" : { "Zip" : [ 94111 ] } ,
	"source" : { "ID" : 1001 ,
		"Fname" : "Paul" ,
		"Lname" : "Jackson" ,
		"Phone" : "415-555-1212 | 415-555-1234" ,
		"SSN" : "123-45-6789" ,
		"Addr" : "123 Avenue Road" ,
		"City" : "San Francisco" ,
		"State" : "CA" ,
		"Zip" : 94111 } 
}

Vielleicht möchten Sie auch wichtige Informationen wie die geografischen Koordinaten hinzufügen. Schemaänderungen dieser Art gestalten sich bei relationalen Datenbanken recht schwierig, sind beim Dokumentenmodell jedoch außerordentlich einfach zu bewerkstelligen:

{	"metadata" : {
		"Source" : "Finance" ,
		"Date" : "2016-04-17" ,
		"Lineage" : "v01 transform"
		"location" : "37.52 -122.25", } ,
	"canonical" : { "Zip" : [ 94111 ] } ,
	"source" : { "ID" : 1001 ,
		"Fname" : "Paul" ,
		"Lname" : "Jackson" ,
		"Phone" : "415-555-1212 | 415-555-1234" ,
		"SSN" : "123-45-6789" ,
		"Addr" : "123 Avenue Road" ,
		"City" : "San Francisco" ,
		"State" : "CA" ,
		"Zip" : 94111 } 
}

Ein weiterer optionaler Schritt: Hinzufügen von Semantik

Weiter oben habe ich beschrieben, wie Sie das Dokumentenmodell von MarkLogic nutzen können. Das ist aber noch nicht alles. Neben der bereits beschriebenen einfachen Transformation bieten sich Ihnen beim Hinzufügen von semantischen Tripeln mit den Multi-Modell-Funktionen von MarkLogic noch viele weitere Möglichkeiten. Sie können zum Beispiel Tripel-Metadaten hinzufügen, um Beziehungen zwischen Dokumenten herzustellen, die den Umgang mit Joins erleichtern und das Erstellen von Abfragen über die Vielzahl der Beziehungen in Ihren Daten hinweg erleichtern. Ein Beispiel: Kunde 1001 hat die Bestellung 8001 aufgegeben, und die Bestellung 8001 enthält das Produkt 7001. Mit Tripeln kann die Datenbank daraus ableiten, dass Kunde 1001 das Produkt 7001 bestellt hat. Das sind drei einfache Fakten, die relevante Beziehungen beschreiben und für die sich die Modellierung als Tripel anbietet. Und da Daten und Abfragen in MarkLogic zusammengesetzt werden können, können Sie Dokumente und Tripel in die gleiche Abfrage einbeziehen. Dies ist eine einzigartige Funktion, die in anderen Datenbanken nicht zu finden ist.

data integration with triples in MarkLogic

In einer relationalen Datenbank sind die Beziehungen an sich recht schwach. Die Semantik liefert Ihnen jedoch ein aussagekräftiges Diagramm, das Sie sich zunutze machen können. Über das Hinzufügen von Semantik für die Datenintegration wäre noch viel mehr zu sagen. Ich möchte hier jedoch darauf nicht näher eingehen und diesem Thema einen anderen Artikel widmen.

Wenn Sie gerne mehr über die Harmonisierung und die Nutzung von Semantik erfahren möchten, dann sehen Sie sich doch unseren neuen On-Demand-Schulungskurs Progressive Transformation Using Semantics (Progressive Transformation mit Semantik) an, der von der MarkLogic University angeboten wird.


Schritt 4: Laden weiterer Daten

Anstatt Ihr Schema bereits im Vorfeld zu definieren und alle Daten nach diesem festen Schema zu laden, können Sie mit MarkLogic immer neue Datenquellen laden – unabhängig davon, ob sie mit dem kanonischen Schema übereinstimmen, das Sie bereits verwenden.

So können Sie also für jede neue Datenquelle mit dem Laden von Daten in jedem Format fortfahren. Dann überlegen Sie sich, welche Elemente der neuen Daten Sie in Ihren Umschlag stecken möchten. Wenn das Quellschema nichts enthält, was sich Ihrem kanonischen Schema zuordnen lässt (z. B. keine Postleitzahl), dann kommt auch nichts in den Umschlag. Wenn die Daten etwas Neues enthalten, das im kanonischen Modell enthalten sein soll, fügen Sie es einfach hinzu. Sie brauchen nicht die ganze Datenbank neu zu erstellen, denn eine Änderung am kanonischen Modell, die durch die Integration eines neuen Schemas bedingt ist, wirkt sich nicht auf Ihre vorhandenen Daten oder die Anwendungen oder Dienste aus, die Ihre Daten nutzen.


Das Ergebnis mit MarkLogic

Einer der großen Vorteile von MarkLogic besteht darin, dass der Prozess der Datenintegration bis aufs Vierfache beschleunigt werden kann. Die Tatsache, dass ein Projekt innerhalb von 6 Monaten statt 2 Jahren abgeschlossen werden kann, ist ein wichtiger Faktor. Mit MarkLogic wird es einfacher, Daten aus Silos zu holen, und ihre Transformation kann direkt innerhalb von MarkLogic erfolgen. So können Sie Ihren Operational Data Hub mit einem flexiblen Prozess entwickeln, der besser und schneller ist als das Verfahren mit relationalen Datenbanken und herkömmlichen ETL-Prozessen. Fassen wir zusammen, warum der „ELT“-Ansatz mit MarkLogic – Laden der Daten in jedem Format und anschließendes Harmonisieren – besser und einfacher ist als die herkömmliche ETL-Methode:

  • Quelldaten laden – in jedem Format
  • Herkunft und andere Metadaten beibehalten
  • Nur das Benötigte harmonisieren
  • Das Modell später ohne erneuten Aufnahmeprozess aktualisieren
  • Neue Schemata wirken sich nicht auf vorhandene Daten/Anwendungen aus

Ein weiterer wichtiger Vorteil des MarkLogic-Ansatzes besteht darin, dass er auch für bessere Data Governance sorgt. Das ist wichtig, weil für die Integration von Daten in den meisten Fällen nicht nur eine Anwendung ausschlaggebend ist. Sie beginnen vielleicht mit einem bestimmten Use Case. Letztendlich soll jedoch dem Zyklus der Erstellung immer neuer Silos ein Ende gesetzt werden. Ihre Daten sollen zentralisiert, vereinheitlicht und so strukturiert und organisiert werden können, dass sie vielen verschiedenen Use Cases gerecht werden.

Um nicht immer wieder neue Silos zu schaffen, müssen Sie sich über die Data-Governance-Aspekte Ihres neuen Data Hubs Gedanken machen. Hierzu gehören Sicherheit, Datenschutz, Lebenszyklus, Aufbewahrung, Compliance und andere Richtlinien und Regeln, die es unabhängig von den jeweiligen Anwendungen gibt.

Welche Rolle spielen Abstammung und Herkunft bei der Data Governance? Bei MarktLogic wissen Sie, wo jedes Attribut herkommt, wann es extrahiert wurde, welchen Transformationen es unterzogen wurde und wie es vorher aussah. Im ETL-Prozess geht nichts verloren. Das Schema-agnostische Konzept von MarkLogic bringt Ihre Quelldaten, die in eine kanonische Form umgewandelten (transformierten) Daten und alle Metadaten im gleichen Datensatz unter, und alle können zusammen abgefragt werden. Mit diesem Ansatz verbringen Sie weniger Zeit damit, Daten im Unternehmen zu verschieben und Fehler im Transformationscode zu beheben und haben so mehr Zeit zur Entwicklung von Anwendungen und wertschöpfenden Nutzung Ihrer Daten. Ähnliche Vorteile ergeben sich für Sicherheit, Vertraulichkeit und Compliance, wenn alle Daten in einem vereinheitlichten, zentralisierten Hub vorliegen und verfolgt werden können.


Die nächsten Schritte

Zu diesem Thema gibt es viel zu lernen, und dieser Artikel sollte anhand von detaillierten Beispielen aufzeigen, warum MarkLogic für die Datenintegration so gut geeignet ist. Wenn Sie sich näher mit diesem Thema befassen möchten, empfehle ich Ihnen die folgenden Links: