Auswerten, nicht verschieben: BI mit Daten aus allen Quellen

Früher war alles einfacher. Da lagen die Daten gut aufgeräumt und strukturiert in Data Warehouses und kluge Hirne hatten sich vorher überlegt, welche Fragen sie beantworten sollen. Heute kommen Daten aus den unterschiedlichsten Quellen, an die bisher niemand gedacht hatte. Fast jedes Gerät; vom Sensor über die Kamera, vom Türeingang über die Kasse ist vernetzt. Gartner meint darüber hinaus, dass bis 2019 rund 75 Prozent der Analytics Lösungen 10 oder mehr externe Datenquellen – sei es von Partnern oder Drittanbietern – umfassen werden. Ein Großteil davon wird unstrukturiert sein. Und keiner überlegt sich lange vorher, welche Fragen morgen aus diesen Daten beantwortet werden sollen.

All das stellt eine BI-Lösung vor Herausforderungen, die in der Frühzeit von Data Analytics einfach noch kein Thema waren. Eine gute Analyse lebt nun einmal von der guten Datenbasis. Wie greift man auf diese unterschiedlichen Daten zu, wie findet man die Datenquellen überhaupt? Welcher Ansatz passt – Data Lake oder ein Auswertungs-Layer?

Für und Wider eines Data Lake

In einigen Unternehmen wird diese Aufgabe den Data Scientists zugewiesen. Nur: diese Fachleute sind rar und teuer. Ein Versuch, aus diesem Dilemma zu entkommen ist die Demokratisierung von Daten – also die Möglichkeit, einen Teil der Data Analytics-Aufgaben an Power User und normale Anwender zu übertragen. Dashboards zu erstellen ist beispielsweise kein Hexenwerk, das kann ein Poweruser ganz einfach übernehmen. Und die Anwender haben maximale Freiheit durch intuitive Nutzerführung.

Diese Art von Self-Service BI setzt allerdings voraus, dass Daten nicht in Silos eingesperrt bleiben, sondern intuitiv und fast automatisch für Analysen zugänglich gemacht werden. Eine Möglichkeit, das zu lösen wäre ein Data Lake mit allen Daten in ihren ursprünglichen Formaten. Doch auch das bedeutet Aufwand – nicht alle Datenformate eignen sich gleich für Data Analytics und wer will sich schon dauernd mit Datenintegration und Formatierung plagen? Konsequenterweise existiert oftmals beides – ein Date Lake neben dem alten Data Warehouse, denn aus wirtschaftlichen Gesichtspunkten macht es wenig Sinn, die über Jahre aufgebaute und gepflegte Infrastruktur zu „entvölkern“, um etwa die Daten in eine Cloud zu migrieren. Oder Daten in eine Analyse-Datenbank einzuspeisen, um von dort aus die Auswertungen zu fahren.

Wie aber müsste ein Repository aussehen, in dem Daten extrem schnell verfügbar sind? Oft stellt sich heraus, dass aus dem Data Lake ein Sumpf geworden ist, der bei weitem nicht die erhoffte schnelle und einfache Auswertung garantiert. In der Praxis hat sich mehr und mehr herausgestellt, dass ein Data Lake nur dann funktioniert, wenn klar definiert ist, welchen Zwecken er dient und wenn das systematische Management der Daten gewährleistet ist. Ein Hadoop Cluster eignet sich perfekt für die Ablage und Verwaltung der Daten eines Data Lakes. Rohdaten abzulegen bringt aber auch ein Risiko für Datenqualität und Governance mit sich – sie können spontan im laufenden Betrieb für eine Analyse geändert werden (was übrigens auch ihre Weiterverwendung limitiert).

Datenpools komplett analysieren, aber nicht bewegen

Ein grundsätzlich anderer Weg ist, eine Analytics-Lösung zu nutzen, die wie ein Layer über den Datenquellen liegt und bei Bedarf dynamisch darauf zugreift. Viele der Tools, die Big Data verwalten und verarbeiten, haben genau hier Limitierungen. Sie verarbeiten Informationen in Batch Jobs und sind für Echtzeit-Anfragen und Interaktivität schlichtweg zu langsam.

Das Ziel ist klar: relevante Daten möglichst in Echtzeit für jeden berechtigen Anwender zugänglich zu machen – möglichst interaktiv. Dafür müssen eine Vielzahl an Datenquellen zur Verfügung gestellt werden – Quellen, die der Anwender möglicherweise nicht kennt und die von einer Engine dennoch transparent bereitgestellt werden müssen. Natürlich muss man sich dabei darauf verlassen können, dass die Datenquelle dabei nicht angetastet wird und die Beziehungen zwischen den Daten erhalten bleiben. In einem assoziativen Modell werden Daten aus verschiedensten Quellen und in variierenden Formaten integriert – ohne Datenverlust oder Datenfilterung während des Zugriffs.

Erst diese vollständige Betrachtung der Daten – ohne vorausgehende, limitierende Priorisierung, ohne Unterschiede – vermeidet blinde Flecken oder ungenaue Einsichten. Die Engine verarbeitet alles, was der Anwender sehen will oder darf. Allerdings muss sie dafür hochperformant sein und eine immense Menge an Daten aus vielen Quellen zusammenbringen. Wir haben es durch die Kombination von Big Data Indexing mit dem oben beschriebenen assoziativen Modell geschafft, 40 Milliarden Datenreihen blitzschnell zu analysieren.

Die Intelligenz der Engine sorgt darüber hinaus dafür, dass bei jedem Klick die Zusammenhänge aktualisiert werden, auch ungeübte Anwender mit dem Tool umgehen können und die Analysen dynamisch an Veränderungen angepasst werden. Erst so wird der interaktive Umgang und ein „Spielen“ mit den Daten spannend.