Data Lakes und dokumentenbasierte Datenbanken verbreiten sich und glänzen mit ihren spezifischen Stärken. Schaut man aus der Prozess-Perspektive oder für ein Machine Learning auf solche Datenquellen, kommt schnell der Wunsch nach integrierten Sichten auf: Bspw. um per Elasticsearch abgelegte Prozessprotokolle einer Camunda Process Engine in Ad-hoc-Abfragen mit DWH-Dimensionen wie Kunde oder Region zu verschneiden. Wie kann das gelingen?
Der naive Ansatz, die Daten in Elasticsearch oder einem relationalen DWH zusammenzuführen, verbietet sich schnell, denn damit gehen die spezifischen Stärken der Technologien verloren und man erhält Redundanz sowie ETL-Prozesse hinzu. Die OpenSource-Plattform Dremio tritt an, um diese und ähnliche Probleme aufzulösen.
Lösungsbeitrag
Dremio ist - wie so oft - als eine Abstraktionsschicht zu verstehen. Nach außen hin erscheint sie als relationale Datenbank und kann per JDBC aus den Analysewerkzeugen der Wahl angesprochen werden. Im Hintergrund arbeitet eine skalierbare Cluster-Engine mit den Rohdaten auf den heterogenen Datenquellen, um eine nur-lesende Tabellen-Sicht darauf zu erstellen und zu verwalten. Anschließbar sind neben relationalen DBMS auch Dateien in S3, das Hadoop-Ökosystem oder auch Elasticsearch.Die Schema-Entdeckung, die dazu auf JSON-Daten notwendig ist, hat sich in unserem Experiment mit 5 Mio. Datensätzen als solide und performant gezeigt. Im nächsten Schritt lässt sich elegant ein SELECT-FROM-WHERE inkl. Joins über die Dokumenteninhalte eines Elasticsearch-Clusters schreiben. Gleiches gilt für gemischte Datenquellen. Der initiale Aufwand bis zu den ersten integrativen Abfragen ist beeindruckend gering.
Dies kann analog zu relationalen Views auch hierarchisch geschehen. Dremio kann also ein gut gepflegtes Metadaten-Management für heterogene Datenlandschaften bilden und so auch zur Reproduzierbarkeit von Datenintegrationsvorhaben/Machine Learning beitragen.
Blick hinter die Kulissen
Dremio ist Java-basiert und verdient das Label "Cloud ready". Eine Authentifizierung per LDAP ist vorgesehen. Es gibt neben dem beschriebenen Workflow noch weitere Features, die auf den zweiten Blick relevant werden:- Ein Caching von Rohdaten und vorverarbeiteten Ergebnissen
- Eine grafische Darstellung der Datenflüsse (Data Lineage)
- Execution-Plans, die einen Überblick dazu geben, wie sich eine Query-Antwortzeit zusammensetzt (hier wäre ein höherer Detailgrad wünschenswert)
- Eine Option, hierarchisch aufgebaute JSON-Felder in einzelne Tabellenspalten aufzulösen, bspw. vom Typ Boolean, um auszudrücken, dass ein Dokumenten-Sub-Knoten existiert. Auch ohne Extraktion können solche Felder aus SQL-Abfragen heraus angesprochen werden.
Fazit
Im Sinne eines Technologie-Radars lohnt es sich für Unternehmen mit heterogenen Datenquellen- und -Typen in größeren Mengen, Dremio näher zu evaluieren.Analysten mit SQL-Kenntnissen können (mit oder ohne Datenintegrationsvorhaben) auf diesem Weg ihren Handlungsspielraum massiv vergrößern, ohne pro Datenbanktyp eigene Abfragemechanismen erlernen zu müssen. Sobald es um Performance-Optimierung geht, wird diese Fertigkeit sicher schnell wieder relevant. In üblichen Ad-hoc-Abfragen gelingt das Verbergen der Spezifika der einzelnen Technologien sehr gut. Das Werkzeug scheint eine gute Ergänzung zu unseren Ansätzen bpmn.ai und vPW zu sein.
Hinweis: Dieser Artikel fasst im Wesentlichen Erkenntnisse aus Literatur-Recherche, eigenen Experimenten und Experten-Interviews aus der Bachelor-Arbeit von Alexander von Kölln an der FH Münster 2019 zusammen.
zurück zur Blogübersicht
Diese Beiträge könnten Sie ebenfalls interessieren
Keinen Beitrag verpassen – viadee Blog abonnieren
