Data Lakes, Data Warehouses, Data Hubs - Brauchen wir das?

Seit den Anfängen von Hadoop gibt es eine lange Debatte darüber, welche Art von Lager für einen bestimmtenuse case Data Analytics am besten geeignet ist. Ein Daten-Lake? Ein Daten-Hub? Ein Datenlager? Obwohl Hadoop in Ungnade gefallen ist, hält die Debatte nicht nur an, sondern wird sogar noch komplizierter. Die heutigen Cloud Repositories, einschließlich AWS S3, Microsoft Azure ADLS und Google Cloud Store, sehen sehr ähnlich aus wie Data Lakes in der Cloud. In ähnlicher Weise ähneln Cloud Angebote wie Snowflake Enterprise Data Warehouses, allerdings in der Cloud. Zugegeben, für einen Vergleich von Äpfeln zu Äpfeln für Data Lakes müsste man Hadoop auf HDFS reduzieren oder die Tools für die Verwaltung von Lager , Anfrage usw. aus den Portfolios der drei öffentlichen Cloud hinzufügen.

Gleichzeitig ist anzumerken, dass keiner der Anbieter, die für diese Angebote werben, diese Begriffe verwendet. . . Microsoft, Amazon und Google bezeichnen ihre Cloud als "Enterprise Data Hubs". Snowflake positioniert sich selbst als Cloud , bezeichnet sich aber über sein umfassendes Ökosystem alsCloud-Datenplattform, während es für sich allein genommen eigentlich eine "Analyse-Engine" ist.

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 sind die operativen Unterschiede zwischen diesen Plattformen jedoch nicht die Ursache dafür, dass sie nicht die Unterstützung bieten, die die verschiedenen Interessengruppen 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 eine Datendrehscheibe wäre etwas wie Informatica, das jeden erdenklichen Datentyp aufnehmen und sowohl vorgelagerte als auch nachgelagerte Datenquellen und -ziele verbinden kann. In der Vergangenheit wurden Datendrehscheiben von IT-Mitarbeitern verwaltet und verwendet, die mit separaten im Silo aus dem gesamten Unternehmen zusammenarbeiteten, um Integrationen zu schaffen, wo von Natur aus keine existierten.

Daten-Lake

Im Gegensatz zu einer Datendrehscheibe fungiert ein Daten-Lake als Lager für persistente Daten. Er ist nicht einfach nur ein Durchlauferhitzer. Data Lakes können in der Regel fast jede Art von Daten aufnehmen und verwalten , und sie bieten, wie das Beispiel Hadoop (historisch gesehen die beliebteste Art von Daten-Lake) zeigt, Tools zur Anreicherung, Abfrage und Analyse der Daten, die sie enthalten. Das Problem ist, dass Data Lakes in der Regel Sandkästen für große Datensätze sind, die in experimentellen Projekten von hochqualifizierten technischen Ressourcen, hauptsächlich IT und Entwicklern, verwendet werden.

Daten-Warehouse

Ein Data Warehouse unterscheidet sich von einem Daten-Lake dadurch, dass es als Lager für persistente und primär strukturierte Daten fungiert, die im Laufe der Zeit schrittweise aus mehreren nachgelagerten Datenquellensilos aufgebaut werden. Ein Data Warehouse unterscheidet sich von einem Daten-Lake auch dadurch, dass es eine Art von Data-Hub-Technologie benötigt, um die Daten für die Aufnahme vorzubereiten. On-Premise-Data-Warehouses, wie die der großen Anbieter wie Oracle, IBM und Teradata, sind sehr IT-zentriert und werden von einem oder mehreren Datenbankadministratoren (DBA) verwaltet. Der Großteil der von den Geschäftsanwendern genutzten Daten befindet sich zwar letztlich in einem Data Warehouse, aber die meisten dieser Anwender haben keine direkte Interaktion mit dem Data Warehouse und wissen vielleicht nicht einmal, dass sie eines haben oder was es ist.

Virtueller Gummi trifft auf virtuelle Straße

Historisch gesehen haben Data Hubs, Data Lakes und Data Warehouses mehrere Dinge gemeinsam: Sie alle erfordern Personal mit speziellen Fähigkeiten, um sie einzurichten, zu pflegen und zu verwalten , sowie Experten, die die Anfragen von nicht-technischen Geschäftsanwendern und Analysten in Abfragen und Berichte umwandeln können, die auf diesen Datenbeständen ausgeführt werden können.

Nebenbei bemerkt ist die Komplexität dieser Plattformen ein Grund für den Niedergang von Hadoop. Hadoop Data Lakes neigten dazu, zu Müllhalden für Daten zu werden, und sie konnten nur von Entwicklern und sehr qualifiziertem (und teurem) IT-Personal verwaltet werden, was den geschäftlichen Wert, den ein Hadoop Daten-Lake generieren konnte, begrenzte. Es ist daher nicht ganz überraschend, dass von den drei großen Anbietern, die früher Hadoop unterstützten, nur noch Cloudera als letzter "Mann" übrig geblieben ist.

Dieser Bedarf an spezialisierten Ressourcen hat sich auch auf andere Weise auf die Nutzung von Data Hubs, Data Lakes und Data Warehouses ausgewirkt, was wiederum die ursprüngliche Frage, welche Plattform für die verschiedenen Anwendungsfälle am besten geeignet ist, weiter erschwert hat. Mit dem Wechsel von On-Premises zu Cloud Infrastrukturen hat sich die Nachfrage nach all diesen spezialisierten Ressourcen verringert. Die Cloud bieten immer mehr betriebliche Unterstützung an, was zu einer Senkung der Betriebskosten beiträgt. Darüber hinaus haben die architektonischen Veränderungen in den jüngsten Generationen von Cloud (Trennung von Rechen- und Speicherangeboten, Bezahlung für die Nutzung usw.) weitere Anreize für den Wechsel in die Cloud geschaffen, um die Kosten zu senken.

Die Komplexität nimmt weiter zu

Bei all diesen strukturellen Veränderungen hat sich jedoch der grundsätzliche Bedarf an datenbasiert Erkenntnissen nicht verändert. Die Antwort auf die Frage, wie man diese Erkenntnisse am besten gewinnt, ist nur schwieriger zu beantworten geworden. Die Daten, die früher in On-Prem-Data-Lakes oder Data-Warehouses (über Data-Hubs) landeten, wandern in die Cloud, aber die Angebote in den Clouds sind nicht ganz dieselben wie im On-Prem-System. Ihre Objektspeichermodelle unterscheiden sich. Microsoft, Amazon und Google bieten persistente Datenspeicher an und können auf diese Weise einem Daten-Lake ähneln, aber sie verlassen sich auf andere Tools, um die Funktionen der Datendrehscheibe auszuführen, und können daher nicht als etwas anderes als Datenspeicher definiert werden. Sie erfordern nach wie vor Datenintegrations- oder Datendrehscheibenfunktionen, und ihr geschäftlicher Wert ist auf dieselbe Weise begrenzt wie eh und je. Die Personen, die den Geschäftswert direkt generieren - die Geschäftsanalysten, Data-Scientist und (in Ermangelung eines spezifischen Titels) die anderen Power-User in den Geschäftsbereichen - können immer noch nicht einfach auf die in den Daten enthaltenen Erkenntnisse zugreifen und diese freisetzen.

Heutzutage nutzen die meisten Business-Analysten und Power-User entweder die integrierten Analyse- und Funktionen von im Silo wie Salesforce, Marketo oder einer beliebigen ERP-Plattform, die sie für das Verständnis von Geschäftsabläufen oder historischen Ergebnissen benötigen. Gleichzeitig streben sie danach, mehr zu tun. Geschäftsanwender können versuchen, Daten aus flachen Dateien wie Excel oder halbstrukturierte JSON-Daten, die über Webservice-APIs bereitgestellt werden, zu integrieren. Oft werden sie von der IT-Abteilung dabei unterstützt, Daten aus einem oder mehreren Systemen zu exportieren, sie mit Excel-Tabellen zu kombinieren und in regelmäßigen Abständen an einen Cube zu senden. Das Ergebnis ist schmerzlich vertraut: im Silo Datenpipelines, die mit im Silo Analyse- und Visualisierungsergebnissen verbunden sind. Wenn diese Geschäftsanwender die Hilfe der IT-Abteilung in Anspruch nehmen, wissen sie nicht, dass sie in Wirklichkeit eine Datendrehscheibe nutzen, denn in der Drehscheibe gibt es keine Datenpersistenz, sie haben die Drehscheibe einfach als Schalter benutzt, um eine Reihe von Datensilos und ein Analysesilo miteinander zu verbinden, um ein Ad-hoc-Organisations- oder Projektsilo zu schaffen.

Data Scientists und Data Engineers können viele der gleichen Datensilos nutzen, aber sie können auch Daten aus halbstrukturierten Datensätzen wie Clickstreams, IoT und Webservices verwenden, und ihre Ziele können die gleichen Visualisierungstools umfassen, aber natürlich auch advanced analytics zur Unterstützung von KI/ML. Sie können die IT-Abteilung damit beauftragen, die Daten für sie zu beschaffen, was wiederum das gleiche Punkt-zu-Punkt-Spaghetti-Netzwerk zur Folge hat.

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 eine Analyse-Engine ist, jedoch ohne integrierte Datendrehscheibe am Back-End und mit dem Schwerpunkt auf separaten Punkt-zu-Punkt-Verbindungen zu verschiedenen BI- und Analysetools am Front-End. Anbieter wie Snowflake erwähnen keine Analysedrehscheibe, geschweige denn behaupten sie, eine zu sein. Ohne die Möglichkeit, auf einfache Weise Daten aus Datenquellen abzurufen und zusammengesetzte Datenelemente aus diesen verschiedenen Quellen für die Präsentation in den Analysewerkzeugen zu verknüpfen, verfügen Sie nicht wirklich über eine Analysedrehscheibe, vor allem, weil Sie keine Datendrehscheibe haben.

Anstelle eines Daten-Hubs oder eines Analyse-Hubs, die beide nur von der IT-Abteilung genutzt werden können, ist in Wirklichkeit ein Data Analytics erforderlich, der von einer breiten Palette von IT- und Geschäftsanwendern genutzt wird. Mehr darüber, was das ist und warum es wichtig ist, im nächsten Blog.

Über Actian Corporation

Actian macht Daten einfach. Unsere Datenplattform vereinfacht die Verbindung, Verwaltung und Analyse von Daten in Cloud-, Hybrid- und lokalen Umgebungen. Mit jahrzehntelanger Erfahrung in den Bereichen Datenmanagement und -analyse liefert Actian leistungsstarke Lösungen, die es Unternehmen ermöglichen, datengesteuerte Entscheidungen zu treffen. Actian wird von führenden Analysten anerkannt und wurde für seine Leistung und Innovation mit Branchenpreisen ausgezeichnet. Unsere Teams präsentieren bewährte Anwendungsfälle auf Konferenzen (z. B. Strata Data) und tragen zu Open-Source-Projekten bei. Im ActianBlog behandeln wir Themen wie Echtzeit-Dateneingabe, Datenanalyse, Data Governance, Datenmanagement, Datenqualität, Datenintelligenz und KI-gesteuerte Analysen.