Data Lakes, Data Warehouses, Data Hubs - Brauchen wir das?
Seit den Anfängen von Hadoop gibt es eine langjährige Debatte darüber, welche Art von Lager für einen bestimmtenuse case Data Analytics am besten Lager . Ein Daten-Lake? Ein Data Hub? Ein Data Warehouse? Trotz des Rückgangs von Hadoop hält diese Debatte nicht nur an, sondern wird sogar immer komplexer. Die heutigen Cloud Speicher, darunter AWS S3, Microsoft Azure ADLS und Google Cloud , ähneln stark Data Lakes in der Cloud. Ebenso ähneln Cloud Angebote wie Snowflake stark Unternehmens-Data-Warehouses, allerdings in der Cloud. Zugegeben: Für einen direkten Vergleich mit Data Lakes müsste man Hadoop auf HDFS reduzieren oder die Tools für Lager Data Lager , abfragen und dergleichen hinzufügen, die zu den Portfolios Cloud drei öffentlichen Cloud gehören.
Gleichzeitig ist anzumerken, dass keiner der Anbieter, die diese Angebote bewerben, diese Begriffe verwendet. . . Microsoft, Amazon und Google bezeichnen ihre Cloud als „Enterprise Data Hubs“. Snowflake positioniert sich als Cloud Warehouse, orientiert sich jedoch neu und bezeichnet sich aufgrund seines umfangreichen Ökosystems mittlerweile alsCloud-Datenplattform; für sich genommen handelt es sich jedoch eigentlich um eine „Analytics-Engine“.
Die Änderung des Begriffs ändert jedoch nichts an der Frage, die der Debatte zugrunde liegt, und die einfache Wahrheit ist, dass keine Daten-LakeDie einfache Wahrheit ist, dass kein Daten-Lake, keine Datendrehscheibe und kein Data Warehouse - ob On-Premises oder in der Cloud - jemals in der Lage war, alle multidisziplinären Teams aus Geschäftsanalysten, Dateningenieuren, Datenwissenschaftlern und Power-Usern in verschiedenen Geschäftsbereichen effektiv zu unterstützen. Das war schon so, bevor es die Cloud gab, und es wird immer deutlicher, wenn Teams versuchen, neue Datensätze zu integrieren (z. B. Webservices und IoT) und halbstrukturierte Daten in strukturierte Repositories zu überführen. Lassen Sie mich gar nicht erst mit der Flut von Excel-Datenblättern anfangen, die verschwinden sollten (aber nie verschwunden sind), als wir in Sachen Analyse und Datenmanagement anspruchsvoller wurden.
Aber die Sache ist die: Es gibt echte Unterschiede zwischen diesen Plattformen, und es ist wichtig, diese Unterschiede zu verstehen. Letztendlich jedoch – aufgepasst – sind die betrieblichen Unterschiede zwischen diesen Plattformen nicht der eigentliche Grund dafür, dass sie nicht die Unterstützung bieten, die alle Beteiligten erwarten.
Level-Einstellung
Lassen Sie uns zunächst darüber reden, worüber wir eigentlich reden:
Datendrehscheibe
Hier definieren wir einen Daten-Hub als ein Gateway, über das virtuelle oder physische Daten zusammengeführt, umgewandelt und für die Weiterleitung an ein anderes Ziel in eine Warteschlange gestellt werden können. Bei diesem Ziel kann es sich um eine Anwendung, eine Datenbank oder eine andere Art von Lager handeln (z. B. ein Daten-Lake oder Data Warehouse). In jedem Fall sind die Daten in einer Datendrehscheibe flüchtig; sie werden nicht lokal gespeichert und haben keine Persistenz.
Ein Beispiel für einen Datenhub wäre beispielsweise Informatica, das jeden erdenklichen Datentyp verarbeiten und sowohl vorgelagerte als auch nachgelagerte Datenquellen und -ziele miteinander verknüpfen kann. In der Vergangenheit wurden Datenhubs von IT-Mitarbeitern verwaltet und genutzt, die mit isolierten im Silo aus dem gesamten Unternehmen zusammenarbeiteten, um Integrationen zu schaffen, wo diese von Natur aus nicht vorhanden waren.
Daten-Lake
Im Gegensatz zu einem Daten-Hub Daten-Lake ein Daten-Lake als Lager persistente Daten. Er ist nicht einfach nur eine Durchlaufstelle. Data Lakes können in der Regel verwalten jeden Datentyp aufnehmen und verwalten und bieten, wie das Beispiel von Hadoop (dem historisch beliebtesten Daten-Lake) zeigt, Werkzeuge zur Anreicherung, Abfrage und Analyse der darin gespeicherten Daten. Das Problem besteht darin, dass Data Lakes im Allgemeinen als Sandkästen dienen, in denen große Datenmengen abgelegt werden, die in experimentellen Projekten von hochqualifizierten technischen Fachkräften – vor allem IT-Mitarbeitern und Entwicklern – genutzt werden.
Data Warehouse
Ein Data Warehouse unterscheidet sich von einem Daten-Lake dass es als Lager persistente und überwiegend strukturierte Daten dient, die im Laufe der Zeit inkrementell aus mehreren nachgelagerten Datensilos aufgebaut werden. Ein Data Warehouse unterscheidet sich zudem von einem Daten-Lake dass es eine Art Daten-Hub-Technologie erfordert, um die Daten für die Erfassung vorzubereiten. On-Premise-Data-Warehouses, wie sie von den großen etablierten Anbietern wie Oracle, IBM und Teradata angeboten werden, sind sehr IT-zentriert und werden von einem oder mehreren Datenbankadministratoren (DBAs) verwaltet. Während der Großteil der von Geschäftsanwendern genutzten Daten letztendlich in einem Data Warehouse gespeichert sein mag, haben die meisten dieser Anwender keinen direkten Kontakt zum Data Warehouse und wissen möglicherweise nicht einmal, dass sie eines haben oder was es ist.
Virtueller Gummi trifft auf virtuelle Straße
Historisch gesehen haben Datenhubs, Data Lakes und Data Warehouses mehrere Gemeinsamkeiten: Für verwalten Einrichtung, Wartung und verwalten ist jeweils Personal mit speziellen Fachkenntnissen erforderlich – Experten, die die Anforderungen nicht-technischer Geschäftsanwender und Analysten in Abfragen und Berichte umsetzen können, die auf diese Datenspeicher angewendet werden können.
Nebenbei bemerkt ist die Komplexität dieser Plattformen ein Grund für den Niedergang von Hadoop. Hadoop-Data-Lakes wurden oft zu reinen Datenlagern, und sie konnten nur von Entwicklern und sehr qualifiziertem (und teurem) IT-Personal verwaltet werden, was den geschäftlichen Nutzen, den ein Daten-Lake generieren konnte, einschränkte. Es ist nicht ganz überraschend, dass von den drei großen Anbietern, die Hadoop früher unterstützt haben, nun nur noch Cloudera als letzter „Überlebender“ übrig geblieben ist.
Dieser Bedarf an spezialisierten Ressourcen hat sich auch in anderer Hinsicht auf die Nutzung von Datenhubs, Data Lakes und Data Warehouses ausgewirkt, was wiederum die ursprüngliche Frage, welche Plattform für verschiedene Anwendungsfälle am besten geeignet ist, weiter verkompliziert hat. Mit dem Übergang von On-Premises Cloud Infrastrukturen ist die Nachfrage nach all diesen spezialisierten Ressourcen zurückgegangen. Ein immer größerer Teil des Betriebs-Supports wird mittlerweile von den Cloud übernommen, was zur Senkung der Betriebskosten beigetragen hat. Darüber hinaus haben die architektonischen Veränderungen in den neuesten Generationen von Cloud (getrennte Rechen- und Speicherangebote, nutzungsabhängige Abrechnung usw.) weitere Anreize für einen Umstieg auf die Cloud geschaffen, Cloud Kosten Cloud senken.
Die Komplexität nimmt weiter zu
Während all diese strukturellen Veränderungen stattfanden, hat sich der grundlegende Bedarf an datenbasiert jedoch nicht verändert. Die Antwort auf die Frage, wie man diese Erkenntnisse am besten gewinnt, ist nur noch schwieriger zu beantworten geworden. Die Daten, die früher (über Datenhubs) in lokale Data Lakes oder Data Warehouses flossen, werden nun in die Cloud übertragen, doch die Angebote in der Cloud nicht ganz dieselben wie vor Ort. Ihre Objektspeichermodelle unterscheiden sich. Microsoft, Amazon und Google bieten persistente Datenspeicher an und ähneln in dieser Hinsicht vielleicht einem Daten-Lake, doch sie sind auf andere Tools angewiesen, um die Funktionen eines Datenhubs zu erfüllen, und können daher nicht als mehr als reine Datenspeicher definiert werden. Sie erfordern nach wie vor Datenintegration oder Datenhub-Funktionalität, und ihr geschäftlicher Nutzen ist nach wie vor begrenzt. Diejenigen, die direkt geschäftlichen Nutzen generieren – die Business-Analysten, Datenwissenschaftler und (mangels einer spezifischen Bezeichnung) die anderen Power-User aus den Fachabteilungen – können nach wie vor nicht ohne Weiteres auf die in den Daten verborgenen Erkenntnisse zugreifen und diese erschließen.
Heutzutage nutzen die meisten Business-Analysten und Power-User entweder die integrierten Analyse- und Fähigkeiten im Silo wie Salesforce, Marketo oder der jeweiligen ERP-Plattform, die sie benötigen, um geschäftliche Abläufe oder historische Ergebnisse zu verstehen. Gleichzeitig streben sie danach, noch mehr zu erreichen. Geschäftsanwender versuchen möglicherweise, Daten aus Flatfiles wie Excel oder semistrukturierte JSON-Daten, die über Webservice-APIs bereitgestellt werden, einzubinden. Oftmals lassen sie sich von der IT dabei unterstützen, Daten aus einem oder mehreren Systemen zu exportieren, diese mit Excel-Tabellen zu kombinieren und regelmäßig an einen Cube zu senden. Das Ergebnis ist nur allzu bekannt: im Silo , die an im Silo und Visualisierungsergebnisse gebunden sind. Ohne dass diese Geschäftsanwender es wissen: Wenn sie die Hilfe der IT in Anspruch nehmen, nutzen sie möglicherweise tatsächlich einen Daten-Hub, da es in diesem Hub keine dauerhafte Datenspeicherung gibt; sie haben den Hub lediglich als Schaltstelle genutzt, um eine Reihe von Datensilos und ein Analyse-Silo miteinander zu verknüpfen und so ein Ad-hoc-Silo für eine Organisation oder ein Projekt zu schaffen.
Datenwissenschaftler und Dateningenieure nutzen zwar möglicherweise viele der gleichen Datensilos, greifen aber möglicherweise auch auf Daten aus semistrukturierten Datensätzen wie Clickstreams, IoT und Webdiensten zurück. Zu ihren Zielsystemen gehören zwar dieselben Visualisierungstools, aber natürlich auch Advanced Analytics zur Unterstützung von KI/ML. Sie ziehen möglicherweise die IT-Abteilung hinzu, um die Daten für sie zu beschaffen, und schaffen so wiederum dasselbe Punkt-zu-Punkt-Spaghetti-Netzwerk.
Anders ausgedrückt: Das von Data Lakes, Data Warehouses und Data Hubs versprochene gemeinsame Lager ist immer noch ein unerfüllter Traum. Ein echter Analytik-Hub muss erst noch realisiert werden - nicht vor Ort und nicht in der Cloud.
Dennoch.
Verlagerung des Schwerpunkts
Die Cloud beginnen, das Problem zu erkennen, und einige gehen schnell dazu über, es zu lösen. Die meisten von ihnen tun dies jedoch, indem sie sicherstellen, dass ein Cloud als vorgelagertes Lager für nachgelagerte Analyse-, Berichts- und Visualisierungstools fungieren kann. Oft wird dies über ein Partner-Ökosystem versucht, wie bei Snowflake. Dies ist notwendig, aber unzureichend für die Analysedrehscheibe, die wir alle wirklich brauchen.
Aber halt. Ein Analytics Hub? Wo war das in den obigen Definitionen?
Tatsache ist, dass das Cloud derzeit zwar eine Analyse-Engine ist, jedoch ohne integrierten Datenhub im Backend und mit einem Schwerpunkt auf separaten Punkt-zu-Punkt-Verbindungen zu verschiedenen BI- und Analysetools im Frontend. Anbieter wie Snowflake erwähnen keine Analyse-Hubs, geschweige denn, dass sie behaupten, selbst einer zu sein. Ohne die Möglichkeit, Daten einfach aus Datenquellen abzurufen und zusammengesetzte Datenelemente aus diesen verschiedenen Quellen für die Darstellung in den Analysetools zu verknüpfen, verfügt man zudem nicht wirklich über einen Analyse-Hub – vor allem, weil man keinen Daten-Hub hat.
Anstelle eines reinen Daten- oder Analyse-Hubs, die beide nur von der IT genutzt werden können, wird in Wirklichkeit ein Data Analytics benötigt, der von einer Vielzahl von IT- und Geschäftsanwendern genutzt wird. Mehr dazu, was das ist und warum es wichtig ist, erfahren Sie im nächsten Blogbeitrag.
Bleiben Sie in Verbindung
Datenanalysen direkt bei Ihnen.
(z. B. sales@..., support@...)
