Blog
Ihre Fragen zur Data Lakehouse Architektur werden beantwortet: Open-Source-Datenkataloge im Vergleich zu Marktführern
Der aufschlussreichste Teil eines technischen Webinars ist nicht immer die Präsentation, sondern die Fragen, die in den Köpfen der Zuhörer verbleiben. In einem kürzlich durchgeführten Deep Dive zum Thema Data Lakehouse sprachen die Experten von Xebia darüber, wie Kataloge Metadaten speichern, die Zugriffskontrolle verwalten und die Datensuche erleichtern können.
Während die Experten den Kampf zwischen den Marktführern und den Open-Source-Herausforderern darstellten, brachten die Live-Demos und die anschließenden Fragen und Antworten das auf den Punkt, was Datenanwender wirklich wissen wollen: "Wird dieser Data Lakehouse-Katalog für mein Unternehmen funktionieren?"
Sind Sie neugierig, wie der Data Lakehouse Katalog funktioniert? Sehen Sie sich hier unser On-Demand-Webinar an. Oder, wenn Sie zunächst mit einem allgemeinen Konzept von Data Lakehouse beginnen möchten, sehen Sie sich das erste Webinar aus dieser Reihe an.
Lassen Sie uns einen Blick auf die wichtigsten Fragen aus dem Publikum werfen, die durch die Konzepte und Live-Demonstrationen der Sitzung beantwortet wurden.
Lesen Sie unseren ersten Blogbeitrag, der auf dem Webinar basiert: Marktführer gegen Herausforderer: der anhaltende Kampf um Datenkataloge in Data Lakehouse.
Frage Nr. 1: "Ist es möglich, Open-Source-Tools mit meiner bestehenden proprietären Plattform zu kombinieren? Oder bin ich da festgelegt?"
Dies war ein zentrales Thema des Webinars, und die Demos lieferten eine überzeugende, doppelte Antwort.
- Die Open-Source-Stack-Demo hat geantwortet: Ja, es ist möglich, eine vollständig offene Alternative aufzubauen. Die Referenten zeigten eine funktionierende Architektur mit Lake Keeper (technischer Katalog), DataHub (Geschäftskatalog) und PyIceberg/Spark, die alle mit Keycloak für die Authentifizierung verbunden sind. In unserem Webinar zeigten wir eine vollständig automatisierte ELT-Pipeline, bei der die Abstammung auf Spaltenebene automatisch in DataHub angezeigt wird. Damit haben wir bewiesen, dass ein modularer Best-of-Breed-Stack nicht nur ein hübsches kleines Diagramm ist, sondern eine einsatzbereite Realität, die die Bindung an einen bestimmten Anbieter vollständig vermeidet.
- Die "Open-by-Design" Demo hat geantwortet: Ja, es ist durchaus möglich, proprietäre Plattformen auf Offenheit zu trimmen. Das war ein echter Publikumsliebling. Für Databricks Unity Catalog wurde gezeigt, dass die Aktivierung der Funktion "Uniform" eine native Delta-Tabelle sofort über die Iceberg REST API von einem externen PyIceberg-Client abfragbar macht. Für Snowflake verwendeten sie den Open Data Catalog (verwaltet von Polaris), um eine Tabelle mit PyIceberg zu erstellen, die dann nahtlos mit dem internen Horizon-Katalog für SQL-Abfragen synchronisiert wurde.
Der offene Aufbau oder die Nutzung von Plattformfunktionen, die sicherstellen, dass Ihre Daten über offene Standards zugänglich bleiben, ist jetzt eine reale Möglichkeit, nicht nur ein ausgefallenes Marketinggespräch.
Frage Nr. 2: "Im Webinar wurde viel über 'technische' und 'geschäftliche' Kataloge gesprochen. Brauche ich als kleines Team beides? Das klingt sehr komplex."
Diese Frage wirft ein Schlaglicht auf ein häufiges Thema, das Teams verwirren kann. In der Fragerunde des Webinars wurde klargestellt, dass es sich um ein Spektrum handelt, nicht um ein Mandat.
- Technische/Betriebliche Kataloge (wie Lake Keeper, Apache Gravitino) konzentrieren sich auf die Engine: Sicherheit, Verkauf von Anmeldeinformationen und Tabellenpflege, damit Engines wie Spark laufen können.
- Business Catalogs (wie DataHub, OpenMetadata) konzentrieren sich auf die Benutzer: Datenermittlung, Abstammung, Qualität und Governance.
Wenn Sie in einem kleinen Team arbeiten, müssen Sie vielleicht in erster Linie den sicheren Datenzugriff für Pipelines ermöglichen. In diesem Fall ist ein technischer Katalog ausreichend. Wenn Ihr Bedarf darin besteht, dass Analysten Daten finden und ihnen vertrauen können, ist stattdessen ein Geschäftskatalog der Schlüssel. Die Demo im Webinar zeigte die elegante Kombination: Lake Keeper führte die Engine aus, und DataHub nahm automatisch die Metadaten auf, um die benutzerfreundliche Oberfläche und die Abstammung bereitzustellen. Für kleine Teams kann diese Kombination mit integrierten Open-Source-Tools durchaus zunehmend realisierbar sein.
Frage Nr. 3 "Die Open-Source-Optionen scheinen vielversprechend, aber unausgereift zu sein. Was ist der wirkliche Haken im Vergleich zu Unity Catalog oder Snowflake?"
Diese pragmatische Frage wurde in der Bewertung direkt angesprochen. Die Redner räumten ein, dass Open-Source-Herausforderer (Gravitino, Lake Keeper) zwar bei den technischen Kernfähigkeiten (Iceberg API, Zugriffskontrolle) überragend sind, ihnen aber oft die für Unternehmen notwendigen Produktionsfunktionen fehlen.
Zu den Lücken, die sie identifiziert haben, gehören:
- Detaillierte Zugriffsprüfung und automatisierte Benutzersynchronisierung (CIAM-Integration).
- Konfiguration als Code und robuste Mechanismen zur gemeinsamen Nutzung von Daten.
- Eingebaute, automatische Tischpflege (Verdichtung, Absaugen).
- Schlüsselfertige hohe Verfügbarkeit.
Was ist hier die eigentliche Erkenntnis? Wenn Sie sich für einen Open-Source-Katalog entscheiden, müssen Sie die "Vollständigkeit" gegen die "architektonische Freiheit" eintauschen. Sie erhalten Interoperabilität und vermeiden Lizenzkosten, aber Sie müssen sich auf höhere betriebliche Investitionen und kundenspezifische Integrationsarbeiten einstellen. Wie ein Redner bemerkte, "müssen Sie darauf vorbereitet sein, individuelle Automatisierungen zu erstellen".
Frage Nr. 4: "Sicher, 'offen' mag ein schickes Modewort sein. Aber was bedeutet es eigentlich für einen Datenkatalog?"
Im Webinar schlugen wir eine entscheidende doppelte Definition vor, die bei den Zuhörern gut ankam:
- Offen durch Lizenz: Die Software ist Open-Source (z.B. Apache-lizenziert wie Lake Keeper).
- Offen nach Design/Standard: Der Katalog hält sich an offene Protokolle, auch wenn diese proprietär sind. Hier glänzen die Unterstützung von Unity für die Iceberg REST API und die Übernahme von Apache Polaris durch Snowflake.
Die Demos haben gezeigt, dass #2 oft genauso wichtig ist wie #1. Eine Plattform kann proprietär sein und dennoch ein "guter Bürger" in einem offenen Ökosystem sein, indem sie Standardprotokolle verwendet. Auf diese Weise können Unternehmen die Leistungsfähigkeit der Plattform nutzen, ohne auf zukünftige Flexibilität verzichten zu müssen.
Das Webinar kam zu dem Schluss, dass der Markt sich weiterentwickelt und echte Wahlmöglichkeiten bietet. Ihr Weg wird davon bestimmt, wie Sie die Fragen des Publikums für sich selbst beantworten:
- Liegt Ihre Priorität auf einer sofort einsatzbereiten Lösung oder auf der Kontrolle der Architektur?
- Müssen Sie einen neuen offenen Stack aufbauen oder Ihre bestehenden Plattforminvestitionen freisetzen?
Die ermutigendste Antwort aus der gesamten Sitzung war diese: Durch offene Standards wie die Iceberg REST Catalog API und Open Lineage gibt es jetzt die Technologie, um beide Wege zu unterstützen, die Ihr Unternehmen wählen könnte. Die Fragen haben sich von "Ist das möglich?" zu "Welcher Kompromiss dient unseren Zielen am besten?" verschoben - ein großartiges Zeichen für ein reifes, leistungsfähiges Ökosystem.
Erfahren Sie mehr über das Open Data Lakehouse-Konzept, und bleiben Sie dran für unseren nächsten Blogbeitrag über Datenkataloge.
Verfasst von
Marek Wiewiórka
Unsere Ideen
Weitere Blogs
Contact