--- title: "Moderne Datenplattformen und Lakehouse-Architekturen | SKAFFON" description: "Datenplattform aufbauen: von PostgreSQL und Objektspeicher bis Iceberg-Lakehouse. Mit Stufenmodell zur Entscheidung, ob Sie ein Lakehouse brauchen." url: https://skaffon.de/daten/datenplattformen/ --- ![Laptop auf einem Holztisch, auf dem Bildschirm Entwicklungsumgebung mit Analyse-Diagrammen](/_astro/laptop-analyse-oberflaeche.tqDOr94H_1saNVs.jpg) 1. [Startseite](/) 2. [Daten](/daten/) 3. Moderne Datenplattformen und Lakehouse-Architekturen 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](/projekt-anfragen/) [Zum Stufenmodell](/daten/datenplattformen/#drei-stufen-jede-mit-eigenem-wechselsignal) - Dreistufiges Entscheidungsmodell - Anbieterneutral: souveräne Cloud, eigene Infrastruktur, Hyperscaler - Infrastruktur als Code, Wiederherstellungstest in der Abnahme Autor: [Ibrahim Yesilay](/unternehmen/ibrahim-yesilay/), Gründer und Geschäftsführer Stand: 13.11.2026 Ausgangsfrage ## 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](/daten/). Die Pipelines selbst behandelt [Data Engineering](/daten/data-engineering/). Hier geht es um die Architekturfrage: welche Stufe, welche Komponenten, welcher Betrieb. Wovon ein Angebot abhängt Bestimmend sind die gewählte Stufe, die Zahl der Datenquellen und Teams, Anforderungen an Verfügbarkeit und Wiederherstellung, Standort und Air-Gap-Vorgaben, die Zahl der Umgebungen und der Betriebsumfang. Das Angebot beschreibt, welche Bausteine wir liefern und wie sich der Preis zusammensetzt. ## Dreistufige Architekturskizze Jede Stufe löst ein konkretes Problem der vorherigen und kostet zusätzlichen Betriebsaufwand. Jede Stufe löst ein konkretes Problem der vorherigen und kostet zusätzlichen Betriebsaufwand. ## 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. Stufe 3 ## Was Iceberg im Objektspeicher leistet Laut [Projekt](https://iceberg.apache.org/) erlaubt Iceberg, dass Engines wie Spark, Trino, Flink, Presto, Hive und Impala gleichzeitig sicher mit denselben Tabellen arbeiten. Als Abfrageschicht kommt zum Beispiel [Dremio](https://docs.dremio.com/current/what-is-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](/_astro/server-einschuebe-blau.BOSctj3C_Z1rPf09.jpg) ## Die drei Stufen im Vergleich __Plattformstufen nach Anforderung, Aufwand und Komponenten__ | Frage | Stufe 1 | Stufe 2 | Stufe 3 | | ---------------------------------------------- | ------------- | ---------------------------------------- | ------------------------------------------- | | Rohdaten dauerhaft und unverändert aufbewahren | eingeschränkt | ja | ja | | Mehrere Abfrage-Engines auf denselben Tabellen | nein | nein | ja | | Reproduzierbare Tabellenstände (Time Travel) | nein | über Neuberechnung | ja, durch das Tabellenformat | | Betriebsaufwand | gering | mittel | hoch | | Typische Komponenten | PostgreSQL | PostgreSQL, Objektspeicher, Airflow, dbt | zusä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. Bausteine ## 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](/infrastruktur/souveraene-cloud/), auf eigener Infrastruktur ([Private Cloud](/infrastruktur/private-cloud/), [Proxmox](/infrastruktur/proxmox/)) oder bei einem Hyperscaler. - ### [Ingestion](/daten/data-engineering/) 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](https://docs.getdbt.com/docs/introduction) 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](/managed-services/managed-postgresql/) für die Datenbankschicht, [Cloud-Betrieb](/managed-services/cloud-betrieb/) für die Umgebung. ## 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](/_astro/festplatten-leiterplatten-sata-anschluessen.CW6Dvl86_1hxrmj.jpg) Eingaben ## 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 ## 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. Verantwortung ## 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. ## 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](/cybersecurity/cloud-security/). ## Angrenzende Themen: Datenbank, Migration, KI - ### [Daten im Überblick](/daten/) Die vier Aufgaben einer Plattform: Ingest, Speichern, Verarbeiten, Bereitstellen. Weiter - ### [MLOps und KI-Plattformen](/ki-infrastruktur/ki-plattform-mlops/) Für Daten in KI-Anwendungen. Weiter - ### [PostgreSQL-Beratung](/daten/postgresql-datenbanken/) Die Datenbankschicht vertiefen. Weiter - ### [Datenbankmigration](/daten/datenbank-migration/) Bestehende Datenbanken auf die neue Plattform bringen. Weiter ## Welche Stufe braucht Ihre Datenplattform? Beschreiben Sie Ihre Daten, Teams und Anforderungen in einer Projektanfrage. [Projekt anfragen](/projekt-anfragen/)