HYBRIDE DATENARCHITEKTUREN - als Grundlage für ein modernes Data Warehouse - iRIX Software ...
←
→
Transkription von Seiteninhalten
Wenn Ihr Browser die Seite nicht korrekt rendert, bitte, lesen Sie den Inhalt der Seite unten
HYBRIDE DATENARCHITEKTUREN E-Book als Grundlage für ein modernes Data Warehouse Autor: Georg Franzke tdwi.eu
Herausgeber SIGS DATACOM GmbH Lindlaustraße 2c 53842 Troisdorf info@sigs-datacom.de www.sigs-datacom.de Copyright © 2019 SIGS DATACOM GmbH Lindlaustr. 2c 53842 Troisdorf Die vorliegende Publikation ist urheberrechtlich geschützt. Alle Rechte vorbehalten. Die Verwen- dung der Texte und Abbildungen, auch auszugsweise, ist ohne die schriftliche Zustimmung des He- rausgebers urheberrechtswidrig und daher strafbar. Dies gilt insbesondere für die Vervielfältigung, Übersetzung oder die Verwendung in elektronischen Systemen. Es wird darauf hingewiesen, dass die in der Broschüre verwendeten Soft- und Hardware-Bezeich- nungen sowie Markennamen und Produktbezeichnungen der jeweiligen Firmen im Allgemeinen warenzeichen-, marken- oder patentrechtlichem Schutz unterliegen. Alle Angaben und Program- me in dieser Broschüre wurden mit größter Sorgfalt kontrolliert. Weder Autor noch Herausgeber können jedoch für Schäden haftbar gemacht werden, die im Zusammenhang mit der Verwendung dieser Broschüre stehen. Wo nicht anders angegeben, wurde auf die im Text verlinkten Quellen zurückgegriffen. TDWI E-Book in Kooperation mit
ZUM INHALT Inhalt Inhalt 1 Einleitung4 2 Eckpunkte einer Data-Warehouse-Modernisierung8 2.1 Agile-Entwicklung 8 2.2 Plattform vs. „Best-of-Breed” 9 2.3 Interaktionen von Komponenten 11 2.4 InMemory-Verarbeitung 14 2.5 Kosten-Nutzen-Betrachtung 15 3 Betrachtung auf Architekturebene17 3.1 Datenanbindung 17 3.2 Datenmodellierung 25 3.3 Datenspeicher 27 3.4 Datenqualität 29 3.5 Berichtswesen 35 3.6 Auswertungen 37 4 Schlussbetrachtung39 Abkürzungsverzeichnis41 Literaturverzeichnis42 Über unsere Sponsoren 43
ZUM INHALT 1 Einleitung Die Welt der IT verändert sich! Das Volumen verfüg- schneller. Aktuell kann von folgender Erkenntnis aus- barer Daten wächst aufgrund von Digitalisierung gegangen werden: und zunehmender Verwendung von Sensoren immer „Die weltweite Datenmenge wird von rund 33 Zettabyte (ZB) im Jahr 2018 auf 175 ZB im Jahr 2025 steigen – also jedes Jahr um circa 27 Prozent.“ 1 Die Verfügbarkeit von Daten steigt! Auf der anderen sich ständig ändernden Werten, was die Vergleich- Seite sollen diese Datenmengen den Anwendern und barkeit von Ergebnissen erschwerte. Weiterhin wollte analytischen Methoden immer häufiger in kürzerer man mehr Daten, z. B. mehr historische Daten, abfra- Zeit zur Verfügung stehen. gen und auch Änderungen nachvollziehen können, so dass sich neue Speicherformen etablierten. Es waren Diese Herausforderung der stetig steigenden Daten- die Anfänge der Data-Warehouse-Systeme in der mengen und der immer kürzeren Zyklen der Verfügbar- Breite. Daten wurden nun nicht mehr nach speich- keit gilt es mit modernen Data-Warehouse-Architekturen erorganisatorischen Gesichtspunkten abgelegt (3NF), in den Griff zu bekommen. sondern es wurden Speicherformen genutzt, die eine Vereinheitlichung der verschiedenen Quellsysteme Schon seit der Einführung der EDV-Systeme in den und die Zeitorientierung beinhalteten und/oder eine 1970ern hat man sich mit der Auswertung der ent- möglichst schnelle und einfache Abfrage durch den sprechenden Daten beschäftigt. Dies erfolgte häufig Endanwender ermöglichten (OLAP).2 Viel diskutiert auf Basis der gespeicherten Daten direkt aus dem wurden die Speicherungen nach Inmon oder Kim- operativen EDV-System. ball und deren Vor- und Nachteile.3 Daten wurden der jeweiligen Anforderung entsprechend in einem Benannt wurden diese Systeme häufig als Manage- Schichtmodell abgelegt. Sammelschichten wurden ment-Information-Systeme (MIS) oder Decision-Sup- dabei meist in normalisierter Form gehalten, und je port-Systeme (DSS). Dabei ging es vor allem darum, weiter die Daten in die Abfrageschichten überführt die nun in elektronischer Form gespeicherten Daten wurden, wurde eine Speicherung überwiegend in auch für Auswertungen besser nutzen zu können. OLAP-Form gewählt. Mit der fortschreitenden Nutzung der Daten Ende der Ziel einer Data-Warehouse-Architektur war somit, die 1980er / Anfang der 1990er erkannte man, dass die Daten im Unternehmen so aufzubereiten, dass man Speicherform in 3NF für die schnelle Abfrage nicht diese einfach und umfänglich für Analysen nutzen geeignet war. Weitere Herausforderungen waren die konnte. Aus dieser Zeit stammte auch die Unterschei- ständigen Änderungen, die in den operativen Syste- dung nach Einsatzzweck der verschiedenen Werkzeu- men erfolgten – diese führten in den Berichten zu ge für den Aufbau eines Analysesystems: 1 Weitere Informationen zu den Datenvolumen unter https://www.iwd.de/artikel/datenmenge-explodiert-431851/ (Entnommen am 27.09.2019). 2 Mehr zu den Speicherarten in Kap. 3.2. Datenmodellierung. 3 Ein Vergleich der Ansätze ist zu finden unter https://www.zentut.com/data-warehouse/kimball-and-inmon-data-warehouse-architectures/. 3 4 5
ZUM INHALT 1 Einleitung ETL Prozess Reporting ETL1 ETL2 Data Warehouse Quellsysteme Ergebnis- Data Marts darstellung Abbildung 1: Beispiel einer klassischen Data-Warehouse-Architektur. Abbildung 1 zeigt den Aufbau einer klassischen Data- darin, die Daten aus den unterschiedlichen Quellsys- Warehouse-Architektur als Grundlage für die späte- temen eines Unternehmens so aufzubereiten, dass re Auswertung. Dabei haben sich als Unterscheidung diese erst auswertbar wurden. Was auf den ersten für den jeweiligen Einsatzbereich die Begriffe Data Blick einfach klingt, war aber sehr kompliziert. Dies Warehouse und Data Mart durchgesetzt. Als Data lag vor allem daran, dass die datenliefernden Sys- Warehouse hat man dabei eine zentrale Datenspeiche- teme ursprünglich nur nach den Anforderungen der rung für das gesamte Unternehmen bezeichnet, wäh- operativen Systeme erstellt wurden. Selten bis gar rend Datenspeicherungen für eine Abteilung oder eine nicht wurden dabei Anforderungen anderer Systeme spezielle Fragestellung Data Marts genannt wurden. berücksichtigt. Dies führte dazu, dass Daten unter- schiedlich granular und mit unterschiedlichen Refe- Mitte der 1990er setzte sich auch in Deutschland renzdaten in den operativen Systemen gespeichert mehr und mehr der Begriff Business Intelligence – wurden. Diese Unterschiede mussten nun im zentra- geprägt durch Gartner – für Auswertungssysteme len Data Warehouse ausgeglichen und standardisiert durch. Hierbei wird der Fokus mehr auf die Nutzung werden. Auch wurden und werden leider auch heute der Daten gelegt als auf die IT-technische Struktur, noch die Missstände der Dokumentation bezogen auf wie dies bei Data Warehouse oder Data Mart der Fall die reale Datenspeicherung deutlich sichtbar. Viel- war. Häufig wurden die Werkzeuge, die für die Ergeb- fach wurde wahrgenommen, dass die ETL-Prozesse nisdarstellung Verwendung fanden, als BI-Werkzeuge zwar fehlerfrei durchlaufen wurden, die Daten in bezeichnet, und das, obwohl sie nur einen kleinen der Ergebnisdarstellung aber fehlerhaft waren. Dies Teil des Gesamtprozesses darstellten. lag sehr häufig an der Dokumentations- und Daten- qualität der verwendeten Quellsysteme. Am einzel- Eine der wesentlichen Aufgaben eines Data- nen Datensatz sind Fehler schnell zu erkennen, bei Warehouse-Systems in der Anfangszeit bestand der maschinellen Verarbeitung von Millionen von 4 5 6
ZUM INHALT 1 Einleitung Datensätzen sind diese aber im ETL-Prozess nicht 1. Für die Auswertung werden neben den Unter- immer prüfbar, weshalb Fehler im Datensatz zu in- nehmensdaten auch externe Daten benötigt, die haltlich falscher Verarbeitung führen konnten. Wenn vereinzelt nur in bestimmten Bereichen genutzt z. B. Kunden Verkaufsbezirken zugeordnet werden werden. Daher wird eine Aufnahme von externen sollten, aber Adressen keinen Verkaufsbezirk hatten, Daten durch die Fachanwender erforderlich. dann konnte es unter Umständen dazu führen, dass 2. Es gibt eine Vielzahl an Daten, die zwar verfüg- diese Kunden nicht verarbeitet wurden. bar sind, wo jedoch aktuell kein Anwendungsfall vorliegt, weshalb der Aufbau eines Data Marts Diese in den 1990ern gestaltete Data-Warehouse-Ar- nicht sinnvoll ist. Um diese Daten trotzdem ein- chitektur hatte über viele Jahre bestand. An vielen fach verfügbar zu machen, sind entsprechende Stellen wurde immer weiter verfeinert, parallelisiert Data-Lake-Architekturen entstanden, die in einer und die starke Nutzung von Hauptspeicher für hö- Data-Warehouse-Architektur zu berücksichtigen here Verarbeitungsgeschwindigkeiten eingeführt, sind. die Anzahl der Ergebnisdarstellungen erhöht sowie 3. In den vergangenen Jahren haben sich die immer mehr in Analytics investiert, aber im Grunde Cloud-Infrastrukturen etabliert. Durch die dort blieb es bei der oben dargestellten Architektur. vorherrschende Preisstruktur und die flexible Anpassung an Soft- und Hardwareanforderun- Dies hat sich in den letzten Jahren massiv verändert. gen wird immer mehr der bestehenden Data- Die folgenden Anforderungen führen zu einer Verän- Warehouse-Architektur aus Kostengründen in die derung der Architekturen: Cloud migriert. Data Lake Cloud A Cloud B Abbildung 2: Neue Herausforderungen der Data-Warehouse-Architektur. 5 6 7
ZUM INHALT 1 Einleitung Bei der Integration neuer Techniken geht es vor al- anschließend die einzelnen Bausteine einer Data- lem um die behutsame Weiterentwicklung bestehen- Warehouse-Architektur dargestellt und beschrieben der Strukturen und nicht um deren Ablösung. werden. Dabei wird herausgearbeitet, was sich dort an Herausforderungen gegenüber der zuerst gezeig- Jedoch werden Daten für viele Firmen immer kriti- ten Architektur ergibt und warum es aus nutzenori- scher, und je früher man auf mögliche Erkenntnisse entierter Sicht sinnvoll erscheint, diese Änderungen reagieren kann, umso größer ist der Nutzen. Aus die- durchzuführen. sem Grund werden immer mehr Firmen versuchen, die Architektur so weiter zu entwickeln, dass der Nut- Das Ziel einer modernen Data-Warehouse-Archi- zen sich erhöht. Und am Nutzen sollten sich immer tektur ist es, sehr flexibel auf neue Anforderun- alle Änderungen messen lassen. gen reagieren zu können, den Nutzen weiter zu erhöhen und dabei möglichst kosteneffizient zu Im Folgenden sollen die Eckpunkte einer nutzen- bleiben. Dies sind die treibenden Faktoren der orientierten Weiterentwicklung aufgezeigt und Data-Warehouse-Modernisierung. 6 7 8
ZUM INHALT 2 Eckpunkte einer Data-Warehouse-Modernisierung Bevor mit der technischen Beschreibung einer Data- Warehouse-Modernisierung begonnen werden kann, sollten die Eckpunkte erklärt werden, die wesentlich für bestimmte Änderungen innerhalb der Architektur verantwortlich sind. Nur so lässt sich in einem weiteren Schritt abwägen, welche der Änderungen für ein Unternehmen sinnvoll sind und wel- che nicht. Nicht immer ist alles für jeden gleich wichtig. 2.1 Agile-Entwicklung An dieser Stelle soll nicht über Agile-Entwicklung im vergleichbar mit Lego-Bausteinen. Durch definierte im Allgemeinen gesprochen werden. Vielmehr sollen Verbindungen können die Bausteine für viele ver- die Gedanken hinter der agilen Entwicklung aufge- schiedenste Konstruktionen genutzt werden.4 griffen und für die Data-Warehouse-Entwicklung ad- aptiert werden. Wichtig wird es am Ende sein, dass nicht ein Tool al- le benötigten Funktionen beinhaltet, um ausgewählt Waren Data-Warehouse-Systeme in der Anfangs- werden zu können, sondern dass ein Unternehmen zeit auf eine gewisse Stabilität und damit auch auf für alle Funktionen entsprechende Tools zur Verfü- zeitliche Vergleichbarkeit ausgelegt, steigen die An- gung hat. Es kann sein, dass ein Unternehmen mit nur forderungen heute immer mehr. So müssen sich die einem Tool für seine Funktionsanforderungen aus- Datenauswertungssysteme schnell an neue Gege- kommt. Vermutlich wird es aber so sein, dass immer benheiten anpassen, also agil gehalten werden. mehr Unternehmen mehrere Tools für die einzelnen Bereiche einsetzen, um die Funktionsanforderungen Wer heute versucht, ein Data Warehouse nach Schich- abzudecken. ten aufzubauen, wird scheitern, da die Zeit gegen ei- nen arbeitet. Komplette Planungen pro Schicht, von Mit Hilfe einer umfassenden API-Verwaltung kann der Anbindung der Quellsysteme über einen Opera- dann sichergestellt werden, dass die Nutzung der tional Data Store (ODS) als erste Datensammlung, Funktionen zeitnah gelingen kann. dann DWH und Data-Mart bis hin zum Bericht, sind sehr aufwändig. Um sowohl in der Entwicklung als Letztendlich sollte aber auch immer beachtet werden, auch später in der Wartung nichts an Agilität zu ver- dass eine größere Anzahl von Tools die Komplexität lieren, sollten die Systeme so aufgebaut werden, dass von Administration und Anzahl von Programmier- entsprechende Schnittstellen zwischen den Syste- sprachen erhöht. Daher sollten die Unternehmen be- men klar definiert sind, Verantwortlichkeiten granu- müht sein, die Anzahl nicht zu groß werden zu lassen. lar festgelegt sind und immer das Thema Flexibilität im Fokus behalten wird. Auf der anderen Seite hat die Nutzung von mehr als einem Tool für einen Bereich den Vorteil, dass sich ein- Weiterhin wird es notwendig, Data-Warehouse-Ar- zelne Tools leichter austauschen lassen, da es entspre- chitekturen nicht nach Tools zu planen; also ein Tool chende Alternativen in dem Bereich gibt. Nutzt ein für ETL, eines für die Datenhaltung, eines für das Be- Unternehmen mehr als ein Reporting-Tool, kann bei richtswesen, etc. Eine Planung sollte vielmehr nach Ausfall des einen Tools erstmal auf ein anderes umge- Funktionen und der Möglichkeit erfolgen, diese auch stiegen werden. Dies ist dann nicht funktionsoptimal, toolübergreifend zu nutzen, z. B. über offene APIs – jedoch agil im Ersetzen ausgefallener Technologien. 4 Pattern Based Design (Idee basiert auf den Ausführungen von Roelant Vos) entnommen dem Vortrag von Christian Hädrich, „Virtual Enterprise Data Warehouse oder: Warum Sie wirklich eine PSA (Persistent Staging Area) für Ihr DWH wollen“, Vortrag auf dem 33. TDWI Roundtable Hamburg, 15.08.2019. 7 8 9
ZUM INHALT 2 Eckpunkte einer Data-Warehouse-Modernisierung Zusammenfassung Agilität wird im Zusammenhang von Data- angepasst werden können, die Kosten sich eng am Warehouse-Architekturen immer wichtiger. Dabei Nutzen orientieren und wenn die methodische Um- sind sowohl Datenmengen und -strukturen als auch setzung ein agiles Vorgehen erlaubt. Besonders im fachliche Themen immer wieder neu zu integrieren. Bereich der Datenmodellierung hat sich hier ein neu- es Vorgehen etabliert, welches später noch beschrie- Diese Anforderungen lassen sich nur umsetzen, ben wird. wenn die Hardware- und Softwarearchitekturen agil 2.2 Plattform vs. „Best-of-Breed” 5 In diesem Abschnitt soll eine alte, aber weiterhin wich- Hierzu ist es heute wichtiger denn je, sich mit den tige Diskussion aufgegriffen werden: Ist es besser, eine Hintergründen dieser Diskussion zu beschäftigen. integrierte Data-Warehouse-Plattform zu verwenden, Beide Möglichkeiten haben entsprechende Vor- und oder sollte man sich für jeden Bereich das jeweils bes- Nachteile, die in der folgenden Tabelle aufgelistet te Tool aussuchen („Best-of-Breed“ genannt)? werden: Funktion DWH-Plattform Best-of-Breed Administration einheitlich spezifisch für jedes eingesetzte Tool Schnittstellen abgestimmt spezifisch für jedes eingesetzte Tool Funktionsumfang abgestimmt meist pro Bereich höher als Plattform Programmierung einheitlich spezifisch für jedes eingesetzte Tool Metadaten plattformeinheitlich tooleinheitlich Austauschbarkeit meist nur komplett jedes Tool einzeln austauschbar Im Folgenden werden die dargestellten Punkte kurz Schnittstellen erläutert, bevor eine Zusammenfassung erfolgt. Bei einer Data-Warehouse-Plattform sind die Schnitt- stellen aufeinander abgestimmt, und bei einem Administration Releasewechsel müssen diese nicht neu getestet DWH-Plattformen haben den Vorteil, dass sie sich werden, da es die Aufgabe eines DWH-Plattformher- über eine einheitliche Administrationsumgebung stellers ist, dies sicherzustellen. Weiterhin müssen steuern lassen. So sind die Aufwände für die IT z. B. Zugriffe auf Datenhaltungen nur einmal definiert meist einfacher zu steuern. Weiterhin sind über werden und stehen allen Komponenten der Plattform entsprechende Gruppenrichtlinien auch funk- zur Verfügung. tionsübergreifende Administrationstätigkeiten ausführbar, so dass nicht in jedem Bereich neu ad- Bei einem „Best-of-Breed“-Ansatz müssen für alle ministriert werden muss. An dieser Stelle haben die verwendeten Tools die entsprechenden Zugriffe er- Plattformen einen großen Vorteil gegenüber einer stellt und administriert werden. Weiterhin müssen „Best-of-Breed“-Umgebung. die Schnittstellenvoraussetzungen für jedes Tool 5 Definition „Best-of-Breed“ siehe https://www.it-business.de/was-ist-best-of-breed-a-769845/ (entnommen am 26.04.2019). 8 9 10
ZUM INHALT 2 Eckpunkte einer Data-Warehouse-Modernisierung geprüft und gewartet werden. Ändern sich diese Metadaten Schnittstellenvoraussetzungen bei einem Tool – z. B. Zu allen Tools und Prozessen werden im Allgemei- ein Reportingtool unterstützt die aktuell eingesetzte nen auch entsprechende Metadaten erzeugt. Um die- Datenbankversion nicht mehr –, dann müssen even- se übergreifend nutzen zu können, ist eine zentrale tuell weitere Änderungen an der Architektur vor- Ablage der Metadaten Voraussetzung. genommen werden. Auf der anderen Seite können „Best-of-Breed“-Tools einzeln gewechselt werden, DWH-Plattformen bringen diese Voraussetzung mit. was den Testaufwand6 im Verhältnis zum Wechsel ei- Bei den „Best-of-Breed“-Tools muss diese Vorausset- ner ganzen DWH-Plattform verringert. zung erst geschaffen werden, was jedoch mit erheb- lichen Aufwänden oder Einschränkungen verbunden Funktionsumfang sein kann. Aufgrund der Beschränkung der „Best-of-Breed“-Tools auf bestimmte Bereiche haben sich häufig sehr gro- Einschränkungen deshalb, weil es bisher nur sehr ße Funktionsumfänge innerhalb dieser Bereiche her- rudimentäre Standards für den Metadatenaustausch ausgebildet. Der Funktionsumfang und meist auch gibt. Da nur standardisierte Objekte unterstützt wer- eine einfachere Bedienung waren und sind die gro- den, werden allgemein nur sehr minimale Standards ßen Vorteile von „Best-of-Breed“-Tools. geschaffen, so dass die toolübergreifende Nutzung mit entsprechenden Einschränkungen einhergeht. Bei Data-Warehouse-Plattformen wird ein Teil der Entwicklung auf plattformspezifische Funktio- Möchte man mehr als die minimalen Standards nut- nen konzentriert und Teile des Funktionsumfangs zen, muss man einen erheblichen Aufwand betrei- werden in Bezug auf die gesamte Plattform ent- ben, um die zusätzlichen Metadaten zentral ablegen wickelt, so dass sich hier feststellen lässt, dass der zu können. Dieser Aufwand ist nicht nur einma- bereichsspezifische Funktionsumfang meist gerin- lig zu erbringen, sondern nach jeder Änderung von ger ist als bei „Best-of-Breed“-Tools. Dafür haben Metadatenstrukturen. Data-Warehouse-Plattformen zusätzliche plattform- übergreifende Funktionen, die im „Best-of-Breed“- Festzuhalten ist, dass die Metadaten möglicherweise Ansatz so nicht vorhanden sind. im Bereich DWH-Plattform geringer ausfallen, jedoch die bereichsübergreifende Nutzung hier im Standard Programmierung möglich ist und häufig auch den entscheidenden Bei den „Best-Of-Breed“-Tools werden meist spezifi- Vorteil gegenüber den „Best-of-Breed“-Tools brachte. sche Programmier- oder Makrosprachen eingesetzt. Das kann dazu führen, dass bei einer größeren An- Um einen Metadaten-Austausch zwischen verschie- zahl von verschiedenen Tools auch die Anzahl der denen Tools zu ermöglichen, wurde und wird an ent- Programmiersprachen wächst, was die übergreifende sprechenden Standards gearbeitet. Ein bekannter, Nutzung und Dokumentation erschwert. aber bisher nicht wirklich erfolgreicher Standard ist das „Common-Warehouse-Metamodel“-Austausch- Bei DWH-Plattformen wird meist nur eine Program- format.7 Seit kurzer Zeit versucht sich ein weiterer miersprache eingesetzt, was eine bereichsübergrei- Standard zu etablieren, der „Egeria“-Standard für den fende Nutzung ermöglicht. So kann zum Beispiel offenen Metadaten-Austausch.8 Hilfreich für den Me- eine Score-Berechnung aus dem analytischen An- tadaten-Austausch sind auch bestimmte Tools, die wendungsbereich schon innerhalb einer ETL-Verar- sich vertieft diesem Thema widmen und die Bestand- beitung erfolgen. teil einer „Best-of-Breed“-Architektur sein sollten. 6 Mehr zum Thema Testen von Data-Warehouse-Systemen in Stauffer/Honegger/Gisin (2013), „Testen von Data-Warehouse- und Business-Intelligence-Systemen“, dpunkt.verlag. 7 Mehr zu CWM unter https://de.wikipedia.org/wiki/Common_Warehouse_Metamodel. 8 Mehr zu Egeria unter https://www.odpi.org/announcements/2018/08/27/odpi-announces-egeria-for-open-sharing-exchange-and-governance-of-metadata. 9 10 11
ZUM INHALT 2 Eckpunkte einer Data-Warehouse-Modernisierung Austauschbarkeit Es wird also zwangsläufig auf einen „Best-of-Breed“- Dieser Punkt ist sicher einer der Bereiche, mit denen Ansatz hinauslaufen. Hier kann eine umfangreiche sich Entscheider bisher kaum bis gar nicht befasst Data-Warehouse-Plattform sehr wohl auch eine Kom- haben. Betrachtet man jedoch die Historie, so ist fest- ponente einer „Best-of-Breed“-Strategie sein. Dabei zuhalten, dass es durchaus Tools gab, die vom Markt sollte man die Vorteile einer Plattform im Auge behal- verschwunden sind, als auch Tools, deren Weiterent- ten und sich künftig von folgendem Satz leiten lassen: wicklung mehr als ins Stocken geraten ist. Deshalb sollte man sich schon bei der Planung der Data-Warehouse-Architektur Gedanken machen, wie So viele Tools wie nötig sich einzelne Funktionsbausteine austauschen oder & durch parallele Nutzung anderer Tools erweitern lassen. so wenige Tools wie möglich Je mehr die Schnittstellen und Datennutzung inner- Abbildung 3: Grundsatz der Toolauswahl. halb der Funktionsbausteine klar voneinander abge- grenzt und dokumentiert sind, desto einfacher lassen sich Erweiterung oder Austausch von Funktionsbau- steinen vornehmen. Hierbei ist es wichtig, sich die In- Jedes Tool, welches zusätzlich in die Data- teraktionen von Komponenten anzuschauen, wie im Warehouse-Architektur aufgenommen werden soll, folgenden Kapitel 2.3 beschrieben. muss einen entscheidenden Wertbeitrag leisten. Sollten sich die Funktionen auch mit bestehenden Zusammenfassung Tools realisieren lassen, dann sind die Kosten mit Die vielfältigen Anforderungen an eine moderne Data- dem Wertbeitrag abzuwiegen. Jedes zusätzliche Tool Warehouse-Architektur führen dazu, dass eine Data- erhöht die Komplexität und damit die Aufwände für Warehouse-Plattform kaum ausreichend ist. die Wartbarkeit. 2.3 Interaktionen von Komponenten Eine moderne, vielschichtige Data-Warehouse-Ar- Data Warehouse oder ein Data Mart. Sowohl die ETL- chitektur besteht aus einer Vielzahl an Tools, welche Tools als auch die Tools zur Berichterstellung oder die benötigten Funktionen für den Betrieb zur Verfü- zur Analytik greifen auf die gemeinsame Datenhal- gung stellen. Wichtig in diesem Zusammenhang ist tung zu. Im Einsatz befinden sich hier meist gängi- die Frage nach der Zusammenarbeit der eingesetzten ge Datenbanken, da diese auch von einer Vielzahl an Tools. Hier gibt es verschiedene Varianten, die kurz Tools unterstützt werden. vorgestellt werden sollen: Mindestens eine der von der Datenbank zur Verfü- Zusammenarbeit über die Datenhaltung gung gestellten Schnittstellen (nativ oder Standard Die gängigste Form der Zusammenarbeit ist die Nut- wie z. B. ODBC) wird von den eingesetzten Tools zung einer gemeinsamen Datenbasis, hier häufig das unterstützt. 10 11 12
ZUM INHALT 2 Eckpunkte einer Data-Warehouse-Modernisierung korrekte und häufig noch angereicherte Adresse zu- rück. Der Datenaustausch erfolgt hier über entspre- chende APIs. Zusammenarbeit über die gruppenweise Daten- übergabe Bei manchen Funktionsbausteinen ist der Bedarf an Daten größer, so dass hier der Datenaustausch meist nicht über eine API, sondern über eine Datei Zentrale erfolgt. Das aufrufende Tool erzeugt eine Datendatei Datenhaltung und startet dann den Prozess auf Seiten des verar- beitenden Tools. Das verarbeitende Tool liest die Da- tei und gibt das Ergebnis entweder auch über eine entsprechende Ergebnisdatei oder über den Funk- tionsraufruf wieder. Die folgende Grafik stellt den Datenaustausch über Dateien dar: Ergebnis Abbildung 4: Zusammenarbeit über Datenhaltung. Zusammenarbeit über die satzweise Datenübergabe Bei dieser Variante der Zusammenarbeit wird von ei- nem Tool jeweils ein Datensatz an ein weiteres Tool übergeben, und bei Bedarf wird ein entsprechendes Funktions- Funktions- Ergebnis zurückgeliefert: baustein A baustein B Daten Abbildung 6: Zusammenarbeit über gruppenweise Datenübergabe. Tool A Tool B Abbildung 5: Zusammenarbeit über satzweise Datenübergabe. Zusammenarbeit mittels Filterübergabe Eine weitere Möglichkeit, die vor allem im Rahmen von Web-Anwendungen immer mehr Verbreitung Tool A sendet einen Datensatz, den Tool B verarbei- findet, ist die Zusammenarbeit mit Hilfe von Filter- tet und gegebenenfalls das Ergebnis zurück an Tool übergaben via Link. Hierbei nutzen die Tools jeweils A sendet. ihre eigene Datenhaltung, mit dem Unterschied, dass Tool B zur Anzeige einen Filter von Tool A bekommt. Als Beispiel kann hier die Adressprüfung angeführt Vergleichbar ist dies mit dem OLAP-Würfel, wo man werden. Nur wenige Tools können auf entsprechende in der Dimension navigieren kann, jedoch ist hier der Referenzdaten zurückgreifen. Häufig nutzt man ent- Unterschied, dass die Strukturen sich durchaus än- sprechende Funktionsmodule. Diese bekommen die dern können. Selbst ein Sprung von einem Bericht in bekannten Adressbestandteile und prüfen diese. Als die operative Anwendung ist möglich, z. B. aus der Rückgabe erhält die aufrufende Funktionseinheit die Kundenliste direkt in den Kundendatensatz. 11 12 13
ZUM INHALT 2 Eckpunkte einer Data-Warehouse-Modernisierung Abbildung 7: Zusammenarbeit mittels Filterübergabe. Ein weiterer Anwendungsfall könnte sein, dass man in Tool A die DQ-Fehlerlisten sehen kann, mit Hilfe eines Links im WEB-Bericht A direkt zu Tool B springt und nun den Status zu den einzelnen Fehlern sehen kann (Data Remediation). GUI-Integration Abbildung 8: Zusammenarbeit über GUI-Integration. In Zeiten, in denen immer mehr Endanwender-Tools den Web-Browser als Frontend nutzen, nimmt die Zusammenarbeit mittels einer GUI-Integration zu. Genaugenommen ist dies keine neue Form der Zu- führen. Besonders wichtig wird die Frage nach der sammenarbeit, sondern es werden lediglich die Zusammenarbeit, wenn man einen Funktionsblock Ausgaben der verwendeten Programme in einer nicht mit nur einem Tool abdecken kann oder möch- Oberfläche gebündelt. Im Idealfall merkt der Anwen- te. Hier gilt es zu klären, wie die Nutzung mehrerer der nicht, dass er mit mehreren Programmen gleich- Funktionsbausteine möglichst automatisiert und für zeitig arbeitet. Die folgende Grafik verdeutlicht die den Anwender optimiert werden kann. entsprechende Architektur (siehe Abb. 8). Die Zusammenarbeit über die Datenhaltung ist sicher Häufig wird diese Art der Zusammenarbeit mit dem eine grundlegende, jedoch auch eine sehr minimalisti- Fall der Filterübergabe kombiniert. Wenn z. B. die Aus- sche. Um die Produktivität zu steigern und die Fehler- gabe von Tool B von dem Ergebnis oder der Selektion anfälligkeit zu minimieren, sollten die anderen Formen des Tools A abhängig ist, dann handelt es sich um der Zusammenarbeit geprüft und auch bevorzugt wer- den Fall der Zusammenarbeit mittels Filterübergabe. den. Dies setzt aber voraus, dass die APIs bekannt und Wenn die Ausgabe dann noch in einer GUI-Integra- unternehmensintern dokumentiert sind, besonders für tion mündet, so hat der Anwender den Eindruck, es die Fälle, in denen die Tools oder eigene Programme handele sich um nur eine Applikation statt um zwei. eigene API-Spezifikationen ermöglichen. APIs können sehr nützliche und produktivitätssteigernde Ansätze Zusammenfassung darstellen. Leider beinhalten sie jedoch bei falscher Da die Anzahl der Tools weiterhin zunehmen wird, Nutzung ein großes Fehlerpotential. Um einen Über- sollten sich die DWH-Architekten die Möglichkeiten blick über die APIs zu erhalten, empfiehlt es sich, ent- der Zusammenarbeit der Tools deutlich vor Augen sprechende API-Übersichten aufzubauen. 12 13 14
ZUM INHALT 2 Eckpunkte einer Data-Warehouse-Modernisierung 2.4 InMemory-Verarbeitung Viele Tools am Markt werben heute mit der InMemory- Notwendig vs. wählbar Nutzung zur performanteren Verarbeitung großer Unter einer notwendigen InMemory-Struktur wird Datenmengen. verstanden, dass Produkte nur jene Daten verarbeiten können, die sich zum Zeitpunkt der Verarbeitung im Für den Anwender ist es jedoch häufig nicht er- Hauptspeicher befinden. Dies ist z. B. bei Berichtswerk- sichtlich, welchen gesamtheitlichen Nutzen die zeugen sowie bei bestimmten Server-Verarbeitungen angebotene InMemory-Funktion bietet. Dies ist der Fall. Bei einer notwendigen InMemory-Struktur umso wichtiger, wenn die meist teureren InMemo- begrenzt der zur Verfügung stehende Hauptspeicher ry-Funktionen nur für ein bestimmtes Tool genutzt die zu verarbeitende Datenmenge. werden können. Unter einer wählbaren InMemory-Struktur wird ver- Im Folgenden wird eine Klassifizierung der Speicher- standen, wenn man frei wählen kann, ob man Daten verarbeitung eingeführt. Diese dient der Grundlage im Hauptspeicher halten möchte oder nicht. Als Bei- einer Entscheidungsfindung, welche Art der Spei- spiel hierzu seien Data-Federation-Tools genannt, bei chernutzung für den jeweiligen Anwendungsfall zu denen man entscheiden kann, ob diese eine einzelne bevorzugen ist. Tabelle im Hauptspeicher halten (meist in Verbin- dung mit einer einstellbaren Refresh-Rate, die angibt, Statisch vs. dynamisch in welchen Zyklen die Daten erneut von der Festplat- Unter einer statischen InMemory-Verarbeitung wird te/Datenbank in den Hauptspeicher zu laden sind). verstanden, dass die zu verarbeiteten Daten zu einem bestimmten Zeitpunkt in den Hauptspeicher geladen Zusammenfassung werden. Welche Daten das sind, ist vor der Nutzung InMemory ist nicht gleich InMemory! Es muss sehr zu entscheiden. genau festgestellt werden, welche Tools von den InMemory-Funktionen profitieren. Weiterhin ist zu Unter einer dynamischen InMemory-Verarbeitung klären, ob die generellen Vorteile von schneller In- wird verstanden, wenn die Softwarekomponenten in Memory-Speicherung generell erhalten bleiben, trotz der Lage sind, zur Laufzeit zusätzliche Daten in den eines eventuell längeren Transfers der Daten von der Hauptspeicher zu laden, ohne dass der Anwender InMemory-Architektur zur Verarbeitungskomponente. dies vorher veranlassen muss. Prinzipiell ist eine InMemory-Speicherung gut und Geschlossen vs. offen sehr schnell, jedoch auch teurer im Verhältnis zu Unter einer geschlossenen InMemory-Verarbeitung SSD-Speicher, der ebenfalls in den letzten Jahren wird verstanden, wenn die Daten, die von einem schneller geworden ist, vor allem durch die Nutzung Produkt im Hauptspeicher gehalten werden, nur für von entsprechenden BUS-Anschlüssen. die Verarbeitung durch dieses Produkt zur Verfü- gung stehen. Dies ist häufig bei Berichtswerkzeu- Berichtswerkzeuge, die eine eigene InMemory-Verwal- gen der Fall. tung haben, bieten den Vorteil, dass die Datenhaltung und die Datenauswertung eng aufeinander abge- Unter einer offenen InMemory-Verarbeitung wird stimmt sind und somit optimal zusammenarbeiten. verstanden, wenn die Daten, die von einem Pro- Der Nachteil gegenüber einer InMemory-Datenhal- dukt im Hauptspeicher gehalten werden, über Stan- tung ist, dass die Datenhaltung von Berichtswerkzeu- dard-Schnittstellen auch anderen Produkten zur gen nicht anderen Tools zur Verfügung gestellt werden Nutzung zur Verfügung gestellt werden. Dies ist z. B. kann. Somit ist die InMemory-Datenspeicherung auf bei den InMemory-Datenbanken der Fall. die Nutzung mit genau einem Tool beschränkt. 13 14 15
-Speicherung gut und schnell, jedoch auch teurer im Verhältnis zu SSD-Speicher, der ZUM Jahren sehr schnell geworden ist, vor allem durch die Nutzung von entsprechenden INHALT 2 Eckpunkte einer eigene InMemory-Verwaltung Data-Warehouse-Modernisierung haben, bieten den Vorteil, dass die Datenhaltung und die nander abgestimmt sind und somit optimal zusammenarbeiten. Der Nachteil gegenüber ng ist, dass die Datenhaltung von Berichtswerkzeugen nicht anderen Tools zur Verfügung 2.5 Kosten-Nutzen-Betrachtung ist die InMemory-Datenspeicherung auf die Nutzung mit genau einem Tool beschränkt. Betrachtet man die Vorhersagen der weltweit zur V = Datenmenge für den betrachteten Verfügung stehenden Daten heute und in Zukunft, 9 Anwendungsfall die vor allem auf den immer häufiger automatisier- Q = Qualität der Daten für den betrachteten ten Entstehungspunkten wie IoT-Sensoren und der Anwendungsfall ständig zunehmenden Digitalisierung basieren, so- N = Nutzung der Daten für den betrachteten wie den Wunsch nach möglichst granularer und um- Anwendungsfall nNutzen-Betrachtung fassender Datenspeicherung, wird deutlich, dass dem Thema der „Kosten-Nutzen“-Betrachtung besondere Der Wert von Daten für ein Unternehmen ergibt sich 9 agen der weltweit zur Verfügung stehenden Daten heute Aufmerksamkeit gewidmet werden muss. undaus somit in Zukunft, der Summediealler vor allem Anwendungsfälle des figer automatisierten Entstehungspunkten wie IoT-Sensoren Produktes und aus die verwendeter der ständig Datenmenge, Qualität Schon heute sind die Kosten, die für eine Data- der verwendeten Daten und Nutzungsintensität der g basierten, sowie der den Wunsch Warehouse-Architektur anfallen,nach enorm.möglichst Diese stei- granularer und umfassender betrachteten Anwendungsfälle. tlich, dass gendem Thema mit dem der „Kosten-Nutzen“-Betrachtung zusätzlichen Bedürfnis, immer granula- besondere Aufmerksamkeit rere Daten über längere Zeiträume sowie zunehmend Aus dieser Formel wird ersichtlich, dass die Fak- externe Daten zu speichern. toren Datenmenge, Datenqualität und Datennut- , die für eine Data Warehouse ArchitekturData-Warehouse-Architektur zung den Wert eines Data Warehouses anfallen, enorm. maßgeblich Ausgehend von der Annahme, dass die Kosten sich beeinflussen. zlichen Bedürfnis, immer granularere Daten über längere Zeiträume sowie zunehmend nach dem gestiegenen Nutzen richten, soll vor allem dieser Nutzen greifbarer gemacht werden. Bei den Bezogen auf eine Data-Warehouse-Architektur füh- Kosten ist dies nicht nötig, da sich diese sehr leicht ren diese Faktoren zu folgenden Aussagen: e, dass die Kosten sich ermitteln lassen. nach dem gestiegenen Nutzen richten, soll vor 1. Vielfältige allem dieser führt zu einem hö- Datenspeicherung werden. Bei den Kosten ist dies nicht Nötignötig, da sich diese herensehr Wertleicht ermitteln der Daten! Bei einer „Kosten-Nutzen“-Betrachtung wird der Nut- 2. Eine höhere Qualität der Daten führt zu einem hö- zen durch den Wert der Daten wiedergegeben. Dies heren Wert der Daten! bedeutet, ein Unternehmen zieht seinen Nutzen aus Betrachtung wird der Nutzen durch den Wert der Daten3.wiedergegeben. Vielfältige Nutzungsmöglichkeiten führen zu ei- Dies bedeutet, dem Wert der Daten, den das Unternehmen mit den nem höheren Wert der Daten! en Nutzen ausgeneriert. Daten dem Wert der Daten, den das Unternehmen mit den Daten generiert. 10 Im Bereich der Nutzungsmöglichkeiten kristallisiert weise aus der folgenden Formel abgeleitet Dieser Wert lässt sich ansatzweise aus der folgenden werdenableiten: sich heraus, dass vor allem das Thema „Tempo“ sowohl Formel ableiten: 10 bei der Datenverfügbarkeit im System als auch bei der Nutzung aus dem System von entscheidender Bedeu- tung ist. Somit wird viel in den Bereich Verfügbarkeit (Stichwort near real-time) sowie in den Bereich per- ൌ ൌ ሺ ∗ ∗ ሻ formanter Nutzung (Stichwort InMemory) investiert. ൌͳ ൌͳ Alle Faktoren haben einen massiven Einfluss auf die Kosten der Data-Warehouse-Architektur. Wäh- W = Wert der Daten rend Geschwindigkeit (Tempo), Menge und Qua- U = Unternehmen lität möglichst einen hohen Wert erhalten sollen, UC = Use Case (Anwendungsfall) sind die Kosten für die Datenhaltung möglichst zu t = Betrachtung zum Zeitpunkt t minimieren. fall) kt t rachteten Anwendungsfall 9 Siehe hierzu Kap. 1 Einleitung. en betrachteten 10 Anwendungsfall In Anlehnung an einen LinkedIn-Beitrag von Martin Guther, VP SAP SE. en betrachteten Anwendungsfall. 14 15 16
ZUM
INHALT
2 Eckpunkte einer Data-Warehouse-Modernisierung
Zusammenfassung
Im Bestreben, immer weitere Nutzungsmöglichkeiten
Max{Menge} zu schaffen, werden die Data-Warehouse-Architektu-
ren immer weiter angepasst. Zum einen wollen die
Anwender immer mehr Daten in immer kürzerer Zeit
zur Verfügung haben, was die Data-Management-Pro-
zesse zwangsläufig dynamischer gestalten wird. Zum
anderen wollen Anwender weitere Methoden der Da-
tenauswertung nutzen. Hier kommt es besonders im
Min{Kosten} Bereich der Analyse zu neuen Anwendungsfällen, die
zur Einführung neuer analytischer Tools und Metho-
den der Zusammenarbeit führen. Auch werden durch
die Möglichkeiten der InMemory-Verarbeitung neue
Max{Qualität} Max{Tempo} Anwendungsfälle entstehen, deren Einsatz wiederum
die Nutzung der Daten erhöht.
Abbildung 9: Spannungsfeld zwischen Kosten und Wert
der Datenspeicherung.
15 16 17 ZUM INHALT 3 Betrachtung auf Architekturebene Nachdem die Eckpunkte einer Data-Warehouse-Architektur erläutert wurden, soll im Folgenden dargestellt werden, wel- chen Einfluss dies auf die allgemeine Data-Warehouse-Ar- chitektur mit sich bringt. 3.1 Datenanbindung Daten wurden in der Vergangenheit immer zunächst Um nun eine frühere Datenbereitstellung für den in einer Datenbank oder in einer einfach strukturier- Nutzer zu ermöglichen, werden immer häufiger ten Datei gespeichert, bevor diese weiterverarbeitet Funktionen zur Beschleunigung der Datenverfügbar- wurden. Die bisherigen Herausforderungen der Da- keit genutzt. Folgende Techniken kommen dabei im tenanbindungen waren dabei die Vereinheitlichung ETL-Umfeld häufig zum Einsatz: von Zeichensätzen, der Beschreibung von Objekten, von Spaltenformaten und der Sprache. • Parallelisierung ––… auf Prozessebene: Die klassische Datenanbindung einer Data-Warehouse- Ein Prozess startet mehrere Threads, die parallel ar- Architektur mittels eines ETL-Tools erfährt zurzeit beiten und somit zu einer Beschleunigung der Ver- massive Veränderungen, die sich aus den folgenden arbeitung führen. Das Sortieren von Daten kann z. B. Punkten ergeben: durch mehrere Unterprozesse aufgeteilt werden. • Die unternehmensinternen Daten sollen immer ––… auf Verbindungsebene: schneller im Data-Warehouse-System zur Verfü- Hierbei werden mehrere Verbindungen zur Da- gung stehen. Tendenzen der Ladezyklen gehen von tenbank aufgebaut und die Daten können paral- monatlicher über wöchentliche bis hin zu tägli- lel verarbeitet werden. Je besser die Datenbank cher Beladung. Immer häufiger kommen auch An- und die Verarbeitungssoftware aufeinander abge- wendungsfälle zum Einsatz, in denen die Zyklen stimmt sind, desto besser und schneller werden Tendenzen zu stündlicher bis hin zu Real-Time-Be- die Daten verarbeitet. ladung aufweisen. ––… Data-Management-Ebene: • Die Anzahl der verfügbaren Formate wird immer Hier wird versucht, möglichst eine Anzahl von höher. Neben den klassischen CSV-Dateien steigt Teilprozessen parallel ablaufen zu lassen, um so- der Bedarf an Datenanbindungsmöglichkeiten wei- mit die Verarbeitung zu beschleunigen. terer Dateiformate. • Datenanbindungen laufen nicht immer nach ei- Nicht immer führt eine Parallelisierung zu dem ge- nem festen Verfahren ab. Es müssen Interaktionen wünschten Beschleunigungseffekt. zugelassen werden, bei denen Benutzer der Wei- terverarbeitung zustimmen müssen: sogenannte • Change-Data-Capture (CDC) Workflows. Um zu vermeiden, dass immer alle Daten aus dem • Anwender wollen heute in vielen Bereichen die Quellsystem geladen werden müssen, kann man Möglichkeit besitzen, weitere Daten in eine Data- Verfahren der Delta-Erkennung nutzen. Diese Ver- Warehouse-Architektur zu übernehmen. fahren kennzeichnen neue, gelöschte oder verän- derte Datensätze. Nur diese Änderungen werden Den klassischen Ansatz für die Beladungsprozesse den weiteren Prozessschritten für die Verarbeitung stellen wie beschrieben die ETL-Tools dar. Diese sind zugeführt. So kann die Datenmenge enorm verrin- darauf spezialisiert, Daten fester Struktur zu entla- gert werden, besonders dann, wenn man die Daten den, zu transformieren und in eine Data-Warehouse- aus den operativen Systemen sehr zeitnah im DWH oder Data-Mart-Ablage zu laden. haben möchte. 16 17 18
ZUM INHALT 3 Betrachtung auf Architekturebene • Bulk-Load Wurden in der Vergangenheit hauptsächlich Daten in Besonders das Schreiben von Daten in eine Daten- den Formaten Text, Zahlen oder Datum verwendet, so bank ist sehr zeitaufwändig. Viele Datenbanken bie- haben sich in den letzten Jahren neue Möglichkeiten ten deshalb besondere Bulk-Load-Verfahren an, um und veränderte Prozesse etabliert, welche es zu be- den Schreibvorgang zu beschleunigen. Wenn ein rücksichtigen gilt. Zum einen hat sich die Datennut- ETL-Tool das Bulk-Load-Verfahren der verwendeten zung stark auf Audio/Video/Bilder erweitert, und zum Datenbank unterstützt, dann werden die Schreib- anderen werden Daten unstrukturiert abgelegt, um vorgänge sehr beschleunigt. erst in einem späteren Schritt die Strukturen in den Daten zu definieren. • InDatabase-Verarbeitung (ELT) Bei der Nutzung von Daten aus einer relationalen Auf Basis der Dateien hat sich erst ein Wechsel Datenbank ist es sinnvoll, einen Teil der Verarbei- von CSV in Richtung temporär strukturierte XML/ tung in der Datenbank vornehmen zu lassen. Statt JSON-Dateien und seit kurzem auch eine Nutzung erst alle Daten aus der Datenbank zu lesen und zu von HADOOP-Daten direkt auf Dateibasis, wie z. B. verarbeiten, ist es häufig viel schneller, wenn man AVRO11 oder PARQUET12, gezeigt. Verarbeitungsschritte in dem liefernden System oder auch im Zielsystem durchführen lässt. Es wird CSV-Dateien hatten und haben den Vorteil, dass dann von einer ELT-Verarbeitung gesprochen, weil sie sehr einfach zu erstellen sind und von fast al- die Transformation in der Datenbank und nicht im len Programmen genutzt werden können. Nachteil eigentlichen ETL-Tool stattfindet. Technisch wer- ist, dass die Formate innerhalb der Datei nicht ge- den entsprechende SQL-Programme erstellt und sichert sind und daher beim Import geprüft wer- zur Verarbeitung an die Datenbank gesendet. den müssen. Die Nutzung von CSV-Dateien birgt ein hohes Potential an Datenqualitätsproblemen • InMemory-Verarbeitung und bedarf entsprechender Vorkehrungen bei der Besonders der Transformations-Schritt beim Trans- Datenanbindung. port der Daten aus dem Quell- in das Zielsystem ist sehr aufwändig und zeitintensiv. Hier können Bei XML/JSON-Dateien sind die Felder den Spalten zum einen optimierte Datenspeicherformate hel- explizit zugeordnet, weshalb hier einige Fehlerquel- fen, indem die ETL-Tools die Daten in einem ei- len gegenüber einer CSV-Datei entfallen. genen performanten Format statt im Textformat zwischenspeichern, und zum anderen, indem die zu XML/JSON haben daher den Vorteil, dass deren inter- verarbeitenden Daten in Hauptspeicher gehalten ne Struktur besser definiert und die Daten passend zu werden, was mathematische Verarbeitungen über den Spalten abgelegt werden können. Doch auch hier Zeilengrenzen hinweg sehr beschleunigt oder erst kann es vorkommen, dass die Inhalte nicht zum de- ermöglicht (besonders bei BigData). finierten Format passen. Da die Datenstruktur inner- halb der Datei mitgeliefert wird, kann es vorkommen, Externe Daten wurden und werden häufig über ent- dass sich die Struktur zwischen den Datenlieferun- sprechende Dateien importiert. Im Laufe der Zeit gen ändert (was auch bei CSV-Dateien sein kann), haben sich sowohl die Dateiformate als auch die Da- was bei nicht angepassten ETL-Prozessen meist zu teninhalte stark geändert. unerwünschten Folgen führt. Hier ist es wichtig, falls 11 Siehe hierzu auch https://de.wikipedia.org/wiki/Apache_Avro. 12 Siehe hierzu auch https://en.wikipedia.org/wiki/Apache_Parquet. 17 18 19
ZUM INHALT 3 Betrachtung auf Architekturebene eine derartige Änderung möglich ist, dass in einem Betracht zu ziehen, dass Formate oder Strukturen ge- Vorverarbeitungsschritt die Struktur und die Inhalte ändert wurden. zu prüfen sind, bevor die Daten der eigentlichen Ver- arbeitung zugeführt werden. Dies führt zu der architektonischen Änderung, dass Dateien immer in einer Vorbearbeitungseinheit ent- Ganz allgemein lässt sich daher die Empfehlung aus- sprechend geprüft und vor der weiteren Verarbeitung sprechen, Dateien nicht einfach als statisch im For- gesichert und standardisiert werden. Der Prozess mat anzunehmen, sondern immer die Möglichkeit in kann sich daher folgendermaßen gestalten: ETL Prozess ETL0 Konvertierung Prüfen & Data Warehouse Quellsysteme Abbildung 10: ETL0-Schicht zur Vorverarbeitung von gelieferten Dateien. 18 19 20
ZUM INHALT 3 Betrachtung auf Architekturebene Diese Dateivorverarbeitung kann durch ein separates Schon an dieser Stelle wird deutlich, dass die bisheri- Tool erfolgen, durch mehrere Tools oder durch das ge ETL-Struktur weiter aufgebrochen wird in eine hy- eingesetzte ETL-Tool, sofern es alle benötigten Da- bride Architektur mit mehreren Funktionsbausteinen. teiformate unterstützt. Neben dem klassischen ETL-Verfahren haben sich Der Vorteil einer separaten Lösung ist zum einen, dass in den vergangenen Jahren weitere Ansätze zur Da- die Verarbeitung vom eigentlichen Beladungsprozess tenanbindung etabliert. Diese sollten kurz darge- entkoppelt wird,und zum anderen hier frühzeitig auf stellt und abgegrenzt werden. die Strukturprobleme eingegangen werden kann. Die Prüfung und Standardisierung kann unmittelbar bei Datenvirtualisierung Lieferung erfolgen und ist somit unabhängig vom Nicht immer ist es sinnvoll, Daten materialisiert zu- allgemeinen Start des DWH-Ladeprozesses. sammenzufassen und somit zu duplizieren. Ein Virtu- alisierungssystem simuliert für Anwendungen einen Weiterhin kann die ETL0-Schicht dann sukzessive aus- SPOT, obwohl die Daten erst zur Abfragezeit gesam- gebaut werden, um auch weitere Dateien bestmöglich melt werden. Der große Vorteil ist hier die hohe Fle- zu integrieren, wie z. B. die angesprochenen AVRO- und xibilität der Datenzusammenfassung, da diese meist PARQUET-Dateien. Der Einsatz von Standardstruktu- über einen SQL-View13 erfolgt, welcher in kürzester ren im Output macht zum einen die Entwicklung der Zeit angepasst oder neu erstellt werden kann. Datenanbindung einfacher, weil klar geregelt ist, wo was zu erfolgen hat, und zum anderen werden Feh- Virtualisierungssysteme eignen sich hervorragend ler so frühzeitig erkannt und nicht weiterverarbeitet. bei der Migration von Systemen, da durch die virtu- Auch kann die Funktion dann unternehmensweit ge- elle Zusammenfassung von Daten sowohl Anwender nutzt und muss nicht bei jedem eingesetzten Modul als auch Applikationen keine Aufgaben der Daten- erneut umgesetzt werden. Im Bereich von Self-Service integration anwenden müssen. Eine Migration von muss beispielsweise nun nur noch geklärt werden, Datenhaltungen kann mit Hilfe einer Virtualisierung wie die Dateien zur Konvertierungseinheit gelangen. von Daten unterstützt werden. Die anschließende Verarbeitung ins DWH oder in den Data Mart erfolgt dann automatisch unter Nutzung Datenvirtualisierungen haben sich auch im Bereich der bestehenden Struktur. der DWH-Entwicklung als nützlich erwiesen, da Datenmodelle in den unterschiedlichen Schichten Die beschriebene ETL0-Schicht kann auch für die getestet werden können, ohne erst materialisiert Konvertierung diverser anderer Dateien wie dBase, werden zu müssen. Dies spart Zeit in der Entwick- EXCEL, Access, etc. Anwendung finden. lung und bringt eine höhere Flexibilisierung. Erst wenn die Datenmodelle soweit fixiert sind, dass sie Der zeitliche Nachteil der zusätzlichen Prüfung ist im in die Produktion gehen sollen, kann entschieden Verhältnis zu den zu vermeidenden Fehlerbeladun- werden, ob man weiterhin mit virtuellen Anbindun- gen zu vernachlässigen. Fehler in der Beladung sind gen arbeitet, weil es performant genug ist, oder ob kostenintensiv und nicht kalkulierbar, der Aufwand für Datenmodelle ganz oder teilweise materialisiert die Datei-Prüfung und -Konvertierung überschaubar. werden sollen.14 13 Siehe zu SQL-View auch https://en.wikipedia.org/wiki/View_(SQL) (entnommen am 25.09.2019). 14 Christian Hädrich, „Virtual Enterprise Data Warehouse oder: Warum Sie wirklich eine PSA (Persistent Staging Area) für Ihr DWH wollen“, Vortrag auf dem 33. TDWI Roundtable Hamburg, 15.08.2019. 19 20 21
ZUM INHALT 3 Betrachtung auf Architekturebene Abbildung 11: Virtualisierung von Datenanbindungen. Ein weiterer Punkt der Virtualisierung ist die Umset- einzeln. Dies vereinfacht die entsprechende Pflege zung von Datenschutzmaßnahmen15, die hier an zen- von Datenschutzrichtlinien im Unternehmen. traler Stelle erfolgen kann anstatt in jeder Datenbank 15 Weitere Informationen zu der neuen EU DSGVO: Nils Bruckhuisen, Lars von Lipinski (2018), „Die neue EU-Datenschutz-Grundverordnung“, TDWI eBook. 20 21 22
ZUM INHALT 3 Betrachtung auf Architekturebene iPaaS (Integrated Platform as a Service) modelliert werden können. Ein weiterer Vorteil von Bei iPaaS handelt es sich um eine cloudbasierte iPaaS ist die meist hohe Anzahl an möglichen Da- Lösung für die Verbindung von Anwendungen und tenanbindungen, so dass die Nutzung von verschie- Daten aus Cloud- oder On-Premises-Umgebungen. denen Dateien und Programmen ermöglicht wird. Durch eine Vielzahl vorgefertigter Connectoren ist der Zugriff auf Applikationen, Datenbanken und Da- Da es sich bei iPaaS um eine cloudbasierte Lösung teien einfach zu realisieren. Innerhalb der Prozesse handelt, sollte aus datenschutzrechtlicher Sicht be- werden neben den Zugriffen auf Daten und deren achtet werden, wie die Daten fließen und ob es ei- Ablage bei Bedarf auch Funktionen zur Bearbeitung, ne Möglichkeit gibt, bei z. B. sehr sensiblen Daten Bereinigung und Zusammenführung genutzt. den Fluss auf die eigene On-Premises-Umgebung zu beschränken. Dies ist dann möglich, wenn die Eine iPaaS-Architektur ermöglicht den Transport von Prozessdefinition zwar in der Cloud liegt, die Pro- Daten über einen definierten Prozessfluss sowohl zessverarbeitung jedoch durch eine eigens in der manuell, zeit- oder ereignisgesteuert als auch via ei- On-Premises-Umgebung installierte Engine erfolgt. ner API-Steuerung. Somit kann flexibel entschieden werden, wann benötigte Daten von einem System Zunehmend werden bei Datenintegrationen komple- in ein anderes System übertragen werden. Da hier xere Workflow-Funktionen gefordert, wie dies z. B. meist kurze Wege mit einfachen Transformationen bei IFRS17-Projekten oder Schadensabwicklungen zur Anwendung kommen, sind die Latenzzeiten sehr der Fall ist. Um nun diese Anforderung umsetzen zu gering. Ein iPaaS kann weiterhin für die Steuerung können, haben iPaaS-Anbieter entsprechende Work- von Daten für Anwendungen genutzt werden, da häu- flow-Komponenten integriert, um die Datenprozesse fig komplette Datenflüsse inkl. externer Steuerung mit Workflow-Funktionen zu kombinieren. On-Premise Abbildung 12: iPaaS als cloudbasierter Integrationsservice. 21 22 23
ZUM INHALT 3 Betrachtung auf Architekturebene Daten- strom ESP Engine Abbildung 13: Eine ESP-Engine filtert bestimmte Daten aus einem Datenstrom (Stream) heraus. Data Preparation Datenbeständen, die optimal die geplante Analyse Mit der Zunahme von Analytics und dem damit ein- unterstützen. Anwender von Data-Preparation-Tools hergehenden Anspruch, Analytics allumfassend zu sind vor allem Personen aus den Fachbereichen, die betrachten, nimmt auch der Bedarf zu, die Datenbasis mit einfachen Methoden Datenbestände aufbau- für die Analytics flexibel aufbauen zu können. Im Ge- en wollen. Diese Tools werden interaktiv verwendet gensatz zu einem IT-Fachanwender, der sich mit dem und manuell oder automatisch gestartet. Für einen Verbindungsaufbau und der Nutzung von Datenban- erfolgreichen Einsatz von Data-Preparation-Tools im ken und APIs gut auskennt, hat der Data Scientist hier Unternehmen sollten integrierte Funktionen der Da- meist keine Kenntnisse, so dass er Tools benötigt, die tenqualitätssicherung enthalten sein. Ein Vorhanden- das Zusammenführen und Aufbereiten von Daten für sein einer Profiling-Funktion16 kann helfen, zu prüfen, die Analyse möglichst einfach gestaltet. Für diesen ob die Datenqualität der zu nutzenden Daten den Er- Anspruch wurden Data-Preparation-Tools entwickelt. wartungen entspricht. Die Verbindung zu den meisten Datenhaltungen im Unternehmen ist bei dieser Art von Tools schon defi- Event Stream Processing (ESP) niert und steht somit für die Nutzung zur Verfügung. Nicht immer ist es sinnvoll, alle Daten für die spätere Einzelne weitere Datenpakete in Form von Dateien Verwendung zu speichern. Es gibt Anwendungsfälle, können hinzugefügt werden. Anschließend können bei denen nur bestimmte Daten aus einem Datenfluss alle Daten so aufbereitet und bereinigt werden, dass (Stream) gespeichert werden sollen. Hierfür können sie für die Analyse genutzt werden können. Ziel von Tools genutzt werden, die vor allem darauf speziali- Data-Preparation-Tools ist somit nicht in erster Linie siert sind, aus einer Vielzahl von Datensätzen nur je- die zentrale Datenablage, wie dies bei ETL- oder iPaaS- ne herauszufiltern und weiterzuleiten, die speziellen Tools der Fall ist, sondern der flexible Aufbau von Anforderungen genügen. Verglichen mit ETL erfolgt 16 Mehr zum Thema Profiling im Kap. 2.4 Datenqualität. 22 23 24
Sie können auch lesen
