Ein flexibler Ansatz für moderne Datenstrukturen Moderne Datenverwaltung durch Headless Data Architecture

Traditionell sind die Speicherung, Verwaltung und der Zugriff auf Daten von den Anwendungen getrennt, die diese Daten schreiben, verarbeiten und abrufen. Die Headless Data Architecture ist eine Weiterentwicklung dieses Prinzips. Aber was genau steckt hinter dieser Architektur?

In einer Headless Data Architecture werden Daten von einem zentralen Ort aus verwaltet, einschließlich Berechtigungen, Schemaentwicklung und Tabellenoptimierungen. Da die Daten nur an einem Ort gespeichert sind, müssen keine zusätzlichen Kopien für andere Verarbeitungssysteme erstellt werden. Dadurch kann für jede Aufgabe die jeweils geeignete Verarbeitungs- oder Abfrage-Engine verwendet werden und es ist leichter, gesetzliche Vorschriften einzuhalten. Diese Datenarchitektur wird „Headless“ genannt, weil sie einem „Headless Server“ ähnelt, bei dem sich die Benutzer mit eigenem Monitor und eigener Tastatur anmelden müssen. Dementsprechend ist für die Verarbeitung oder Abfrage von Daten in einer Headless Data Architecture ein eigener „Head“ erforderlich, der an die Daten angeschlossen wird, zum Beispiel Trino, Presto, Flink oder Spark.

Eine Headless Data Architecture kann mehrere Datenformate unterstützen, wobei Datenströme und Tabellen die häufigsten Formate sind. Während Datenströme einen Zugriff auf inkrementelle Daten mit geringer Latenz ermöglichen, bieten Tabellen effiziente Funktionen für Massenabfragen. Wenn User Datenströme und Tabellen kombinieren, können sie damit flexibel das Format wählen, das für den jeweiligen Anwendungsfall am besten geeignet ist – sei es für operative oder analytische Zwecke oder etwaige Zwischenstufen.

Datenströme in der Headless Data Architecture

Apache Kafka ist eine Open-Source-Plattform für verteiltes, event-getriebenes Daten-Streaming und basiert auf einem Headless-Datenmodell. Kafka stellt dafür die Application Programming Interface (API), die Datenspeicherebene, Zugriffskontrollen und grundlegende Cluster-Metadaten bereit. Ein Producer schreibt dann über ein Topic, aus dem ein oder mehrere Consumer die Daten in ihrem eigenen Tempo lesen können.

Der Producer agiert dabei als ein komplett unabhängiger Head. Dieser kann in Go, Python, Java, Rust oder C und anderen Sprachen geschrieben werden und auch gängige Stream-Processing-Frameworks wie Kafka Streams oder Apache Flink verwenden. Die Consumer sind ebenfalls unabhängig – einer kann in Python geschrieben sein, ein anderer in Java, und ein dritter kann eine Kafka-Connect-Instanz für die direkte Integration mit einem Cloud-Service oder einer Datenbank sein.

Tableflow, Konnektoren und Stream Governance

Confluent Cloud erhält zusätzliche Funktionen

Damit ein vollständiger Streaming-Support in der Headless Data Architecture möglich ist, sind zusätzliche Funktionen erforderlich. Zum einen benötigen Events klar definierte, explizite Schemata für Zuverlässigkeit und Sicherheit, wie sie von einer Schema Registry bereitgestellt und durchgesetzt werden. Zum anderen benötigen sie auch einen Metadatenkatalog, der die Eigentumsrechte erfasst, Schlagwörter sowie geschäftliche Metadaten verwaltet und Funktionen für Suche, Abruf und Abgleich liefert.

Datenströme werden in der Regel für operative Anwendungsfälle verwendet, zum Beispiel für E-Commerce-Bestellungen, um Inventar zu bestellen oder um komplexe Unternehmensabläufe zu planen. Datenströme können zwar auch zur Erstellung von analytischen Anwendungsfällen verwendet werden, aber dafür reichen auch regelmäßige batch-basierte Berechnungen auf Tabellenbasis manchmal aus.

Tabellen für die Headless Data Architecture

Wie können also Tabellen in die Headless Data Architecture integriert werden? Tabellen sind schon lange ein fester Bestandteil von Data Lakes und Data Warehouses, waren aber früher oft an proprietäre Datenbanken gebunden. Tabellen konnten dabei nur mit dem Datenbanksystem abgefragt werden, in dem sie auch gespeichert waren.

Heute liefern gängige Open-Source-Formate wie Apache Parquet saubere Definitionen der zugrunde liegenden Daten. Die zugrunde liegenden Dateien bleiben jedoch unabhängig von den Definitionen der Tabelle. Dafür ist eine Technologie namens Apache Iceberg nötig, ein immer beliebteres Open-Source-Projekt für die Datenverwaltung. Iceberg ist ein robuster und leistungsfähiger Dateisystemmanager für Spaltendaten (einschließlich Parquet) und bietet mehrere Schlüsselkomponenten, um Tabellen in einer Headless Data Architecture zu realisieren:

• Iceberg verwaltet die Speicherung sowie Optimierung der Daten, und verwendet in der Regel leicht zugängliche Cloud-Speicher wie Amazon S3. So werden alle Daten gespeichert, die zum Erstellen von Tabellen notwendig sind.

• Der Iceberg-Katalog enthält Metadaten, Schemata und Tabelleninformationen, zum Beispiel Details dazu, welche Tabellen vorliegen und wo sich diese befinden. Die Tabellen werden im Iceberg-Katalog deklariert, damit Verarbeitungs- und Abfragesysteme auf die zugrunde liegenden Daten zugreifen können.

• Iceberg unterstützt Transaktionen sowie gleichzeitiges Lesen und Schreiben. Dadurch können mehrere Producer gleichzeitig anspruchsvolle Aufgaben erledigen, ohne sich gegenseitig zu beeinträchtigen.

• Iceberg kann Abfragen über Tabellen zu einem bestimmten Zeitpunkt ausführen, was nützlich für Audits, Fehlerbehebung und Regressionstests ist.

Iceberg bietet eine zentrale, modulare Datenebene, und kann Open-Source-Optionen wie Flink, Trino, Presto, Hive, Spark und DuckDB oder beliebte SaaS-Optionen (Software-as-a-Service) wie BigQuery, Redshift, Snowflake und Databricks auf unterschiedliche Weise integrieren. In der Regel müssen dazu Metadaten aus dem Iceberg-Katalog repliziert werden, damit Iceberg herausfinden kann, wo sich die Dateien befinden und wie sie abgefragt werden können.

Vorteile einer Headless Data Architecture

• 1. Daten müssen nicht mehr kopiert werden, was viel Geld und Zeit spart. AWS-Nutzer können zum Beispiel ihre Tabellen in Athena, Snowflake und Redshift integrieren, ohne ihre Daten verschieben zu müssen.

• 2. Ohne diese zusätzlichen Kopien werden Datensätze vermieden, die sich nur geringfügig unterscheiden. Das verringert die Menge der Datenpipelines.

• 3. Es kann der Producer gewählt werden, der am besten geeignet ist – zum Beispiel Flink für die eine Aufgabe und DuckDB für andere. Weil die Datenabstraktion unabhängig von den Verarbeitungssystemen erfolgt, sind die Daten nicht mehr an die spezifischen Systeme gebunden, in die sie geladen wurden.

• 4. Eine zentrale Zugangskontrolle steuert den Zugriff auf der Datenebene für alle Prozessoren. Dies ermöglicht eine präzisere Verwaltung von privaten und finanziellen Informationen, damit die Daten sicher bleiben.

Drei wesentliche Unterschiede zwischen Headless Data und Data Lake Architecture

• 1. In einer Headless Data Architecture können alle Arten von Services auf die Daten zugreifen. Dabei spielt es keine Rolle, ob es sich um einen analytischen oder einen operativen Service handelt. Eine Headless Data Architecture macht den Datenzugriff einfach und flexibel und ist zudem nicht nur auf analytische Toolsets beschränkt.

• 2. Je nach Anwendungsfall und Bedarf können Tabellen, Datenströme oder beides verwendet werden.

• 3. Bei einer Headless Data Architecture müssen die Daten nicht an einen zentralen Ort kopiert werden. Die Datenebene kann aus verschiedenen Datenquellen zusammengesetzt werden, wodurch sich daraus eine modulare Datenebene ergibt.

Die entscheidenden Merkmale der Headless Data Architecture sind Modularität, Wiederverwendbarkeit, Struktur und ein einfacher Zugriff auf Datenströme und Tabellen. Eine Headless Data Architecture ermöglicht es auch, Iceberg-Tabellen als externe Tabellen zu registrieren und sie somit leicht in Datenplattformen zu integrieren. Natürlich können Headless-Daten weiterhin über eine Pipeline in diese Systeme kopiert werden. Die Headless Data Architecture bietet allerdings die gleichen Vorteile, ohne dass kopiert werden muss.

Wie ist eine Headless Data Architecture aufgebaut?

Für den Aufbau einer Headless Data Architecture ist die Investition in die Headless-Datenebene entscheidend. In der Regel ist die Nutzung von Cloud-Services der einfachste und beliebteste Weg, um damit zu beginnen. Beim Aufbau einer eigenen Headless Data Architecture ist es wichtig, zunächst gut organisierte und schematisierte Datenströme zu erstellen, bevor diese in Iceberg-Tabellen eingefügt werden.

Konnektoren (zum Beispiel Kafka Connect) werden oft verwendet, um Datenströme in Iceberg-Tabellen zu konvertieren. Es ist jedoch auch möglich, Managed Services zu nutzen, die automatisch Topics in append-only Iceberg-Tabellen umwandeln, ohne dass Wartungsarbeiten oder Pipelines erforderlich sind. Diese Datenströme und Tabellen können schließlich in beliebige Data Lakes, Data Warehouses, Prozessoren, Abfragesysteme, Reporting-Software, Datenbanken oder Anwendungs-Frameworks integriert werden.

Einige Prozessoren können direkt in den Iceberg-Katalog integriert werden, wodurch sofort auf die Daten zugegriffen werden kann. Proprietäre Verarbeitungssysteme, wie die der großen Cloud-Anbieter, benötigen normalerweise eine Kopie der Iceberg-Metadaten, um die Verarbeitung zu ermöglichen. Daher ist es notwendig, den passenden Prozessor zu wählen.

Ausblick

Die Headless Data Architecture integriert Daten-Streaming nahtlos mit Data Lakes sowie Data Warehouses und eröffnet Unternehmen dadurch neue Möglichkeiten, Daten flexibler und effizienter zu verwalten. Gerade durch die Kombination mit modernen Cloud-Services und fortschrittlichen Open-Source-Technologien wie Apache Iceberg können Unternehmen Daten noch gezielter steuern und innovative Anwendungen schneller realisieren. So zeigt die Headless Data Architecture nicht nur das Potenzial für aktuelle Herausforderungen, sondern legt auch den Grundstein für zukunftsweisende Datenstrategien. Angesichts der wachsenden Nachfrage nach skalierbaren, modularen Datenlösungen wird sie zukünftig eine immer größere Rolle spielen.

(ID:50285247)