Projekt anfragen
Laptop auf einem Holztisch, auf dem Bildschirm Entwicklungsumgebung mit Analyse-Diagrammen

Datenplattform · PostgreSQL bis Iceberg-Lakehouse

Moderne Datenplattformen und Lakehouse-Architekturen

Wir entwerfen und bauen die Datenplattform, die zu Ihren Daten, Ihrem Team und Ihren Datenschutzvorgaben passt, und sagen Ihnen ehrlich, wenn eine einfachere Stufe genügt.

Projekt anfragen Zum Stufenmodell
  • Dreistufiges Entscheidungsmodell
  • Anbieterneutral: souveräne Cloud, eigene Infrastruktur, Hyperscaler
  • Infrastruktur als Code, Wiederherstellungstest in der Abnahme

Autor: Ibrahim Yesilay, Gründer und Geschäftsführer Stand:

01Ausgangsfrage

Erst die Stufe klären, dann die Technik wählen

Wer eine Datenplattform aufbauen will, steht meist vor der Frage, wie viel Plattform er wirklich braucht. Diese Seite richtet sich an IT-Leitung und CTOs, die keine komplexe Architektur bauen wollen, wo ein einfacheres Setup genügt.

Die vier Aufgaben einer Plattform (Ingest, Speichern, Verarbeiten, Bereitstellen) erklärt der Bereich Daten. Die Pipelines selbst behandelt Data Engineering. Hier geht es um die Architekturfrage: welche Stufe, welche Komponenten, welcher Betrieb.

02

Dreistufige Architekturskizze

Drei Plattformstufen Stufe 1 PostgreSQL, Stufe 2 PostgreSQL mit Objektspeicher, Airflow und dbt, Stufe 3 Lakehouse mit Iceberg, Katalog und Abfrage-Engines. Drei Plattformstufen: jede löst ein konkretes Problem der vorherigen Stufe 1 PostgreSQL als Datenbasis PostgreSQL Transformation in SQL Betriebsaufwand: gering Rohdaten: eingeschränkt Stufe 2 Objektspeicher + Orchestrierung Objektspeicher (S3-kompatibel) Airflow dbt PostgreSQL (Analyse) Betriebsaufwand: mittel Rohdaten: unverändert, nachvollziehbar Stufe 3 Lakehouse mit Tabellenformat Objektspeicher + Iceberg-Tabellen Katalog Engine A Engine B Betriebsaufwand: hoch Mehrere Engines, Time Travel Wechsel zur nächsten Stufe erst, wenn das Wechselsignal real vorliegt. Schematische Darstellung, keine Mengen- oder Leistungsangaben.
Jede Stufe löst ein konkretes Problem der vorherigen und kostet zusätzlichen Betriebsaufwand.
Drei Plattformstufen Stufe 1 PostgreSQL, Stufe 2 PostgreSQL mit Objektspeicher, Airflow und dbt, Stufe 3 Lakehouse mit Iceberg, Katalog und Abfrage-Engines. Die Stufen folgen von oben nach unten aufeinander. Drei Plattformstufen: jede löstein konkretes Problemder vorherigen Stufe 1 PostgreSQL als Datenbasis PostgreSQL Transformation in SQL Betriebsaufwand: gering Rohdaten: eingeschränkt Stufe 2 Objektspeicher + Orchestrierung Objektspeicher (S3-kompatibel) Airflow dbt PostgreSQL (Analyse) Betriebsaufwand: mittel Rohdaten: unverändert, nachvollziehbar Stufe 3 Lakehouse mit Tabellenformat Objektspeicher + Iceberg-Tabellen Katalog Engine A Engine B Betriebsaufwand: hoch Mehrere Engines, Time Travel Wechsel zur nächsten Stufe erst, wenn dasWechselsignal real vorliegt. SchematischeDarstellung, keine Mengen- oderLeistungsangaben.
Jede Stufe löst ein konkretes Problem der vorherigen und kostet zusätzlichen Betriebsaufwand.

03

Drei Stufen, jede mit eigenem Wechselsignal

Eine höhere Stufe wird erst gewählt, wenn das Problem der vorherigen real vorliegt.

  1. 01

    PostgreSQL als zentrale Datenbasis

    Stufe 1

    Eine oder mehrere PostgreSQL-Datenbanken, Transformationen in SQL, Auswertungen auf einer Replika oder einem getrennten Analyse-Schema. Passt, wenn strukturierte Daten dominieren, Auswertungen die operative Last nicht gefährden und das Team SQL kann. Wechselsignal: Analyseabfragen stören den operativen Betrieb, Rohdaten und Dateien (Dokumente, Logs, Exporte) müssen aufbewahrt werden, mehrere Quellen müssen zusammengeführt werden.

  2. 02

    PostgreSQL, Objektspeicher und Orchestrierung

    Stufe 2

    S3-kompatibler Objektspeicher hält Rohdaten und Archive, Airflow orchestriert, dbt erzeugt aufbereitete Modelle in einer analytischen Zieldatenbank. Passt, wenn Rohdaten unverändert nachvollziehbar bleiben sollen, mehrere Teams auf aufbereitete Daten zugreifen und historische Zeiträume neu berechnet werden müssen. Wechselsignal: Datenmengen oder Dateiformate, die die Zieldatenbank nicht mehr sinnvoll trägt; mehrere Abfrage-Engines sollen dieselben Tabellen nutzen; Zugriffsregeln und Tabellenstände müssen unabhängig von einer einzelnen Datenbank gelten.

  3. 03

    Lakehouse mit offenem Tabellenformat

    Stufe 3

    Daten liegen im Objektspeicher als Tabellen eines offenen Formats, etwa Apache Iceberg. Passt, wenn mehrere Engines oder Teams dieselben großen Tabellen nutzen, Herkunft und Stand von Daten reproduzierbar sein müssen und Speicher und Rechenleistung getrennt skalieren sollen.

04Stufe 3

Was Iceberg im Objektspeicher leistet

Laut Projekt erlaubt Iceberg, dass Engines wie Spark, Trino, Flink, Presto, Hive und Impala gleichzeitig sicher mit denselben Tabellen arbeiten.

Als Abfrageschicht kommt zum Beispiel Dremio in Betracht, das sich laut Dokumentation als offene Lakehouse-Plattform auf Basis von Standards wie Apache Iceberg und Apache Arrow versteht; Spark nehmen wir hinzu, wo verteilte Verarbeitung nötig ist. Welche Engine passt, hängt von Lizenzmodell, Betriebsmodell und Ihren Anforderungen ab und wird im Projekt entschieden, nicht vorab.

  • Schema-Evolution ohne Neuschreiben der Tabelle
  • Versteckte Partitionierung
  • Time Travel für reproduzierbare Abfragen
  • Rollback auf einen früheren Stand
Nahaufnahme blau beleuchteter Server-Einschübe in einem Rack, einer teilweise herausgezogen

05

Die drei Stufen im Vergleich

Plattformstufen nach Anforderung, Aufwand und Komponenten
FrageStufe 1Stufe 2Stufe 3
Rohdaten dauerhaft und unverändert aufbewahreneingeschränktjaja
Mehrere Abfrage-Engines auf denselben Tabellenneinneinja
Reproduzierbare Tabellenstände (Time Travel)neinüber Neuberechnungja, durch das Tabellenformat
Betriebsaufwandgeringmittelhoch
Typische KomponentenPostgreSQLPostgreSQL, Objektspeicher, Airflow, dbtzusätzlich Iceberg, Katalog, Abfrage-Engine

Die Tabelle enthält keine Mengen- oder Leistungsangaben: Schwellen hängen von Abfragen, Hardware und Team ab und werden mit Ihren Daten gemessen.

Ein Lakehouse braucht einen Grund, nicht eine Mode

Gegen Stufe 3 sprechen ein kleines Datenteam ohne Kapazität für zusätzlichen Betrieb, Datenmengen, die eine einzelne PostgreSQL-Instanz mühelos trägt, und das Fehlen einer Anforderung an mehrere Abfrage-Engines. Liegt keine der Stufe-3-Anforderungen vor, empfehlen wir die einfachere Stufe.

06Bausteine

Sechs Bausteine, aus denen die Zielarchitektur besteht

  • Architektur

    Zielbild mit Stufe, Datenzonen (Rohdaten, bereinigt, aufbereitet), Mandantentrennung, Standort und Betriebsmodell. Die Plattform läuft in der souveränen Cloud, auf eigener Infrastruktur (Private Cloud, Proxmox) oder bei einem Hyperscaler.

  • Ingestion

    Batch, CDC und Ereignisströme nach der Auswahlmatrix auf der Seite Data Engineering.

  • Storage

    PostgreSQL für strukturierte Daten; Objektspeicher für Rohdaten und Lakehouse-Tabellen.

  • IAM

    Zugriff über Ihre Identity-Lösung, Rollen je Datenzone, technische Konten für Pipelines, Zugriffsprotokolle. Zugriff auf Rohdaten ist enger als auf aufbereitete Daten; bei personenbezogenen Daten gilt das besonders.

  • Data Catalog

    Beschreibung der Datensätze mit Eigentümer, Herkunft und Qualitätsstatus. Bei dbt-basierten Modellen entsteht ein Teil davon laut Dokumentation automatisch aus dem Code; ein unternehmensweiter Katalog ist eine eigene Entscheidung.

  • Betrieb

    Backup mit Wiederherstellungstest, Hochverfügbarkeit nach Bedarf, Monitoring, Update-Prozess, Kapazitätsplanung. Als Service: Managed PostgreSQL für die Datenbankschicht, Cloud-Betrieb für die Umgebung.

07

Bei Stufe 3 ist der Tabellenkatalog kritische Infrastruktur

Der Katalog der Tabellen muss gesichert, versioniert und wiederherstellbar sein, sonst sind die Daten im Objektspeicher ohne Zusammenhang. Deshalb gehört er in dasselbe Backup- und Wiederherstellungskonzept wie die Datenbanken und wird in der Abnahme mit einem Wiederherstellungstest geprüft.

Nahaufnahme von Festplatten mit Leiterplatten und SATA-Anschlüssen in Einbaurahmen auf hellem Untergrund

08Eingaben

Was wir für eine belastbare Stufenempfehlung von Ihnen brauchen

Diese sechs Punkte entscheiden über die Stufe, nicht allein die Datenmenge.

  • Wer die Daten fachlich verantwortet
  • Welche Datenklassen und Standortvorgaben gelten
  • Welche Teams mit welchen Werkzeugen zugreifen
  • Welche Aktualität gefordert ist
  • Vorhandene Systeme, Kubernetes-Plattform und Identity-Lösung
  • Die Betriebskapazität Ihres Teams

09

Fünf Projektschritte, je mit einem greifbaren Ergebnis

  1. 01

    Assessment

    Ergebnis: empfohlene Stufe

    Datenlandschaft, Anforderungen, Teamkapazität; Ergebnis ist die empfohlene Stufe mit Begründung und den Gegenindikatoren, die gegen höhere Stufen sprechen.

  2. 02

    Zielarchitektur

    Ergebnis: Zielbild

    Komponenten, Datenzonen, IAM, Betriebsmodell, Alternativen.

  3. 03

    Aufbau

    Ergebnis: laufende Plattform

    Infrastruktur als Code, Plattformkomponenten, erste Pipelines für einen priorisierten Datensatz bis zum Abnehmer.

  4. 04

    Abnahme

    Ergebnis: Nachweis

    Zugriffstests, Wiederherstellungstest, Lasttest mit Ihren Abfragen.

  5. 05

    Übergabe oder Betrieb

    Ergebnis: Betriebsmodell

    Sie übernehmen die Plattform selbst oder wir betreiben sie als Service.

10Verantwortung

Technische Umsetzung bei uns, rechtliche Bewertung bei Ihnen

Das bauen wir technisch ein

  • Verschlüsselung im Ruhezustand und bei der Übertragung
  • Getrennte Rollen für Administration, Pipelines und Auswertung
  • Protokollierung von Zugriffen
  • Keine Zugangsdaten in Code oder Images

Das gehört nicht zu dieser Leistung

  • Datenschutzrechtliche Bewertung, Löschkonzept und Auftragsverarbeitung liegen bei Ihnen.
  • Auswahl und Gestaltung von BI-Werkzeugen, Berichten und Dashboards sind nicht Teil dieser Leistung.
  • Eine fertige Software-as-a-Service-Datenplattform mit Selbstbedienung: Dann ist der Dienst eines Anbieters der kürzere Weg.

11

Die Lieferobjekte eines Plattformprojekts

  • Architekturdokument mit Stufenbegründung
  • Infrastruktur-as-Code-Repository
  • IAM-Konzept
  • Backup- und Wiederherstellungs-Runbooks
  • Betriebsdokumentation
  • Abnahmeprotokoll

Vertiefung zur Sicherheit: Cloud Security.

12

Angrenzende Themen: Datenbank, Migration, KI

Welche Stufe braucht Ihre Datenplattform?

Beschreiben Sie Ihre Daten, Teams und Anforderungen in einer Projektanfrage.

Projekt anfragen