Hybride Architekturen:
Hybris oder Heilsbringer? (Teil 1)
Vorteile, technische Details und Fallstricke: Wie funktionieren hybride Architekturen genau?
Hybride Architekturen – Teil 1: Seit einiger Zeit geistert ein neues Einhorn durch die Business-Intelligence-Welt: Hybride Architekturen. In dieser Interviewreihe versuchen wir mit unserem Experten Nico Inhoffen, dieses Fabelwesen zu entmystifizieren, zu domestizieren und etwaige Pferdefüße zu identifizieren: Unter den Aspekten Technologie (Teil 1), Unternehmenskultur (Teil 2), geeignetem Einstieg (Teil 3) und den Protagonisten (Teil 4) beleuchten wir alle relevanten Details dieser neuen Architekturform. In diesem ersten Artikel stellen wir die hybriden Architekturen auf den Prüfstand: Was für einen Mehrwert bieten sie, wo schlummern Probleme, wie sieht die Architektur im Detail aus? Und was haben hybride Architekturen mit Garagen gemeinsam?
Es werde Licht.
Fabian: Hallo Nico, wir beide reden heute über hybride Architekturen: Kannst du zum Einstieg in wenigen Worten zusammenfassen, was für dich diesen Trend ausmacht?
Nico: Sehr gerne: Eine hybride Big Data Architektur ist die Verbindung von einem klassischen DWH und der neuen Big-Data-Technologie Hadoop, im spezifischen der Data Lake. Dabei vereinigt die hybride Architektur die Vorteile eines Data Lake mit den Vorteilen eines DWH, wie wir es aus den klassischen BI Landschaften kennen.
Fabian: Direkt ans Eingemachte: Geht das denn? Kann man einfach sagen, ich nehme die Vorteile von dem einen und die Vorteile von dem anderen System, und das Ganze ohne die Nachteile mitzuschleppen?
Nico: Ganz ohne Nachteile geht es natürlich nie: Man hat eine größere Komplexität, je mehr das System anwächst. Aber wir haben bereits in vielen Projekten gezeigt, dass die Vorteile, die man durch beide Systeme erzeugt, die negativen Punkte überwiegen. Und zwar deutlich.
Fabian: Was sind denn die schlagenden Argumente für eine hybride Architektur, die dir als erstes einfallen? Welcher Mehrwert entsteht für Unternehmen dabei, genau auf eine Zwischenlösung zu setzen?
Nico: Durch die Kombination der beiden Systeme nutzt man einmal das bewährte System des DWHs, das bereits seit ca. 25 Jahren auf dem Markt ist und permanent verbessert wird. Ergo sind das sehr ausgereifte Technologien, die eine hohe Abfrageperformance auf relationale Daten erlauben. Allerdings ist so ein DWH meistens hypothesengetrieben. All das bezeichne ich heute als die „klassische relationale Welt“. Und dann haben wir die „neue Welt“, die Big Data Technologie. Da wären Data Discovery Tools wie z.B. Spark, mit denen man neue Auswertungsmöglichkeiten nutzen kann. Diese sind dann eben nicht hypothesengetrieben, sondern datengetrieben und explorativ. Außerdem kann man mit Clustern arbeiten und dort hochkomplexe verteilte Algorithmen laufen lassen, was ein klassisches DWH oft an seine Grenzen bringt. Und wir haben die Möglichkeit, auch Rohdaten zu speichern. Denn im DWH sind wir limitiert bezüglich der Datenmenge, sowie der Art der Daten. Im Data Lake hingegen haben wir so gut wie unbegrenzten Speicherplatz und können auch unstrukturierte Daten speichern. Es können also nicht nur die Daten gespeichert werden, die ich aktuell für meine Hypothesen brauche, sondern alle Daten, die anfallen. Mit der zusätzlichen Rechenpower und Speicherkapazität aus Big Data kann man dann zukünftig diese größere Datenmengen analysieren und damit ganz neue Erkenntnisse gewinnen. Und durch diese Kombination der beiden Technologien haben wir sowohl die bewährten Zugriffspattern optimiert, als auch alle Potentiale der neuen Technologie zur Verfügung.
Fabian: Kann man sinnbildlich sagen: Die Architektur ist eine Garage, in der normalerweise ein klassisches Auto mit Verbrennungsmotor steht. Jetzt rüste ich auf, aber kaufe mir nicht nur ein Elektroauto, sondern auch noch ein Hybridfahrzeug, so dass ich dann drei Fahrzeuge für die verschiedensten Bedürfnisse in meiner Garage stehen habe…?
Nico: Vielleicht ist es eher so: Du hast deine Garage und da steht dein Auto mit Verbrennungsmotor drin, das extrem schnell ist. Und oben drauf baust du dann einen Helikopterlandeplatz für deinen Big-Data-Helikopter, mit dem man unwegsames Daten-Gelände erforschen kann, wo man es vorher mit den herkömmlichen Autos gar nicht hingeschafft hätte.
Fabian: Was natürlich dann auch bei der Garage, um in der Metapher zu bleiben, problematisch werden könnte: Man braucht eine große Garage, man braucht einen Hausmeister und man braucht Mechaniker, die sowohl Hubschrauber als auch Autos reparieren können. Siehst du da Probleme?
„Nur, weil wir die Daten jetzt abspeichern können, heißt das ja nicht, dass wir keine Ordnung darin brauchen.“
Nico: Naja, die Skills für die entsprechenden Technologien braucht man immer. Aber was ist die Gegenthese? Wenn man sagt, man möchte nur in der einen Welt bleiben, natürlich, dann brauche ich keine neuen Skills, dann kann ich mit den Leuten weiter arbeiten, die ich habe. Aber es gibt ja oben genannte Gründe, warum diese Technologien an ihre Grenzen stoßen. Deswegen muss ich mich irgendwann nach neuen Technologien umschauen. Und wenn ich dann eine neue Technologie habe, brauche ich auch neue Leute, in die ich investiere. Das heißt, ich brauch die passenden Experten, die nicht nur die Big-Data-Technologie verwalten können, sondern auch die Verbindung zum DWH und zurück verstehen. Hier spiegelt sich auch der ganze Big Data Gedanke wieder, um direkt unseren nächsten Blog-Artikel zu spoilern: Big Data ist ja nicht nur eine Technologie, sondern es ist auch ein Kulturwandel. Ich investiere nicht nur in eine neue Technologie, sondern auch in neue Leute, man möchte eine neue Herangehensweise für Daten etablieren, und muss somit auch etwas in der Kultur des Unternehmens ändern. Wenn man das nicht schafft und jeder weiterhin sein eigenes Süppchen kocht, dann hat man wieder genau diese Datensilos, die man eigentlich vermeiden wollte.
Fabian: Du sprichst gerade Silos an: Ist das nicht gerade ein Damoklesschwert, das immer über den hybriden Architekturen schwebt? Die Verbindung zwischen den beiden Elementen als Dreh- und Angelpunkt: Wie kann man das gewährleisten, dass man nicht zwei parallele Architekturen, sondern wirklich etwas Hybrides baut, das auch miteinander verknüpft ist?
Nico: Am besten indem man Woodmark beauftragt! (lacht) – Nein, Spaß beiseite, man muss sich im Vorfeld ein klares Bild von hybriden Architekturen machen und beide Welten verstehen. Man muss wissen, was in der klassischen BI Welt die Anforderungen sind und muss auch die neue Big Data Welt verstehen und den besagten Kulturwandel mitgemacht haben. Dann versteht man, wie das klassische DWH mit Big Data verbunden werden muss. Das heißt, in unserer Architektur, die wir als hybride Architektur von Woodmark vorschlagen, ist der Data Lake die Schicht in der alle Daten, einschließlich der Rohdaten, ankommen und dauerhaft gespeichert werden und das DWH die Schicht die die business ready Daten vorhält. Momentan werden diese DWHs von den Datenquellen direkt gespeist. In unserem Fall wird das DWH stattdessen durch den Data Lake gespeist. Dadurch haben wir einen Single Point of Truth, nämlich den Date Lake. So kann das DWH dann nach wie vor der Zugriffspunkt für Endanwender sein, beispielsweise für Reports. Zusätzlich kann der Endanwender aber auch direkt auf den Data Lake zugreifen. Dort hat der Anwender alle Möglichkeiten, die wir in der Big Data Welt haben wie zum Beispiel Data Science auf den Rohdaten zu betreiben und dann nur die Ergebnisse ins DWH zu schreiben. Denn was wollen wir im DWH? Wir wollen Informationen, die business ready sind.
Fabian: Sehe ich das richtig, dass der Teil vom DWH zum Endanwender komplett gleich bleibt, lediglich der Unterbau wird durch den Data Lake unterfüttert? Und es gibt sogar noch eine Überholspur für Data Scientists oder andere Power User, die die Daten schnell oder in Rohform brauchen?
Nico: Genau, es gibt ja auch noch weitere Anwender außer den Endanwender, es gibt besagte Power-User oder andere Leute, die nicht so lange warten wollen: Die Versorgung des DWHs kann ja heutzutage schon extrem lange dauern. Und da können wir dieser Nutzergruppe die Möglichkeit geben, auf die verschiedenen Access-Layer in den Data Lake zu zugreifen. Das heißt, da wir sowieso die Rohdaten immer von den Datenquellen in ihrer nativen Form im Data Lake speichern, kann man sich sogar diese Daten schon sofort anschauen. Natürlich muss man mit im Hinterkopf behalten, dass diese Daten dann noch nicht wirklich aufbereitet und überprüft sind. Aber man hat wenigstens die Chance, vor irgendwelchen Transformationen oder Aggregationen darauf zu zugreifen.
Fabian: Was sind denn die klassischen Konnektoren, also wie verbinde ich den Data Lake mit dem DWH?
Nico: Es gibt eigentlich kaum Unterschiede zwischen der Verbindung „Data Lake – DWH“ zu „Datenquelle – DWH“. Denn der Data Lake bietet die gleichen klassischen Verbindungsmöglichkeiten über JDBC und ODBC. Das heißt, wir haben zum Beispiel das Tool Apache Hive oder Apache Spark, die beide eine SQL JDBC-Schnittstelle anbieten. Aber auch die großen ETL oder ELT-Hersteller wie Informatica oder Talend haben mittlerweile verstanden, dass man um Big Data nicht herumkommt und haben deshalb Schnittstellen gebaut, um direkt aufs HDFS zugreifen zu können. Mit diesen Tools kann man problemlos auf Hadoop zugreifen und die Daten dann im DWH speichern. Wichtig ist nur, dass man eine Datenquelle als Single Point of Truth hat, und das sollte der Data Lake sein, damit man nicht verschiedene Datenquellen für die Ergebnisse hat.
Fabian: Das Wort „Hybrid“ leitet sich ja ursprünglich vom griechischen Begriff „hýbris“, also Übermut, Anmaßung, ab. Das lateinische „hybrida“ wird sogar mit Bastard oder Frevelkind übersetzt. Siehst du vor diesem Hintergrund Fallstricke, die bei dieser Architektur lauern könnten, und die man bis jetzt unterschätzt? „Es muss klar geregelt sein, wer welche Daten sehen darf; es gilt immer noch der Datenschutz in Deutschland!“
Nico: Natürlich gibt es die auch, wir übernehmen ein paar Probleme, die wir schon im klassischen DWH haben: Die Themen Metadatenmanagement, Governance und Security sind nach wie vor extrem wichtig: Nur, weil wir die Daten jetzt abspeichern können, heißt das ja nicht, dass wir keine Ordnung darin brauchen. Oder dass jeder auf die Daten zugreifen darf. Es muss klar geregelt sein, wer welche Daten sehen darf; es gibt immer noch einen Datenschutz in Deutschland. Zum Thema Metadatenmanagement, also zu wissen, welche Daten liegen wo, und was sind das für Daten: Wenn wir das nicht abspeichern, dann gehen uns wertvolle Information verloren. Dann haben wir nämlich nur noch Daten, aber wir wollen ja Information daraus machen. Bei kleinen Datenmengen, beispielsweise bei einem Data Mart, gibt es immer diverse Domänenexperten. Die kennen ihre Daten, die kannst du alles fragen: Solche Leute können sofort beantworten, was dieses Feld bedeutet, was jenes. Das wird schon schwieriger, wenn wir über ein komplettes DWH reden. Das ist schon so groß, dass es große Teile des Unternehmens umfasst. Schon hier gibt es niemanden mehr, der alle Fragen beantworten kann. So muss man dann immer zu unterschiedlichen Leuten gehen, und die wissen auch nicht immer, was der aktuelle Stand ist: Es wird immer schwieriger. Und beim Data Lake kriegen wir jetzt noch mehr Daten hinzu! – Und nicht nur relationale Daten, sondern auch Binärdaten, unstrukturierte Daten, und, und, und. All dieses Wissen zu behalten ist extrem wichtig, diese Aufgaben muss man auf jeden Fall angehen. Dazu gibt es verschiedene Herangehensweisen: Von den ETL- / ELT-Tool-Herstellern kommt der Ansatz, ein Metadatenmanagement in gewissen Teilen mitzuliefern. Oder man bleibt im Open Source Bereich und nutzt zum Beispiel Apache Atlas, was jetzt immer weiterentwickelt wird und auch namentlich schon viele Partner in der Branche gefunden hat.
Fabian: Das heißt, da gibt es noch eine Leiche im Keller, die von den DWHs mitgenommen wurde und die man jetzt auch noch nicht losgeworden ist?
Nico: Historisch gesehen: Das DWH versucht seit 25 Jahren, das Problem des Metadatenmanagements zu lösen. Und trotzdem habe ich noch keine wirklich zufriedenstellende Software Lösung dafür gesehen. Sondern meistens nur starke Charaktere in Data-Governance-Positionen, die das dann mit hoher Disziplin durchgesetzt haben. Und so ein Data-Governance-Sheriff hat dann beispielsweise penibel darauf geachtet, dass alle Daten die in das DWH kommen, auf jeden Fall immer perfekt dokumentiert sind. Diese Rolle kann man natürlich auch in der hybriden Architektur installieren.
Fabian: Hast du das Gefühl, die Big Data Architekten haben hier aus den Fehlern der klassischen DWH-Architekten gelernt und dann gleich ein besseres Metadatenmanagementsystem eingeführt?
Nico: (Lacht) Nein, ich glaube nicht.
Fabian: Eher andersrum?
Nico: Wäre das Problem trivial, wäre es schon lange gelöst worden. Es ist noch nicht im DWH gelöst worden und nur weil wir jetzt noch mehr Datenmengen haben oder da jetzt ein Data Lake darunter liegt, ändert sich nichts am eigentlichen Problem. Ich glaube, es gibt da keine 100%- ige Lösung, aber man sollte zu mindestens versuchen, sich dem so weit wie möglich anzunähern.