Seminar RisingWave – Iceberg und Streaming Lakehouse

Apache Iceberg verbindet offene Lakehouse-Tabellen mit skalierbarer Speicherung und analytischer Weiterverarbeitung. Die Schulung behandelt RisingWave als Streaming-Schicht für das Lesen, Transformieren und Schreiben von Iceberg-Daten einschließlich Katalog, Partitionierung, Wartung und Betriebsüberwachung.

Inhaltsverzeichnis

• Zielsetzung
• Zielgruppe
• Voraussetzungen
• Seminarinhalte
• Praxisübungen
• Methodik

Zielsetzung

• Iceberg-Tabellen, Kataloge und Objektspeicher fachgerecht konfigurieren
• Streaming- und Batch-Daten aus Iceberg lesen und nach Iceberg schreiben
• Partitionierung, Dateigröße, Commits und Wartung aufeinander abstimmen
• Ein Streaming-Lakehouse mit Datenqualität, Wiederanlauf und Kostenkontrolle betreiben

Zielgruppe

Data Engineers, Lakehouse-Architektur, Plattformteams, Analytics Engineering, Data Architects und technische Betriebsverantwortliche.

Voraussetzungen

Gute SQL-Kenntnisse, Verständnis von Objektspeichern und tabellarischen Datenformaten. Grundkenntnisse von Iceberg oder einem vergleichbaren Lakehouse-Format sind hilfreich.

Seminarinhalte

1. Schritt 1: Lakehouse-Zielbild definieren

   Streaming-Quellen, RisingWave-Verarbeitung, Iceberg-Tabellen, Abfrageengines und Verantwortlichkeiten werden in einer durchgängigen Architektur abgegrenzt.

2. Schritt 2: Iceberg-Metadaten verstehen

   Snapshots, Manifestdateien, Datendateien, Partition Specs und Schemaentwicklung werden hinsichtlich Lesen, Schreiben und Wartung eingeordnet.

3. Schritt 3: Katalog und Objektspeicher anbinden

   Katalogtyp, Namespace, Speicherpfad, Authentifizierung, Netzwerk und Berechtigungen werden als wiederverwendbare Verbindung konfiguriert.

4. Schritt 4: Iceberg-Quelle lesen

   Tabellenschema, Snapshot-Stand, Startpunkt, Streaming-Verhalten und Datentypabbildung werden in einer kontrollierten Quelle geprüft.

5. Schritt 5: Daten für das Lakehouse modellieren

   Schlüssel, Zeitspalten, fachliche Granularität, Änderungssemantik und Qualitätsregeln werden vor der Ausgabe festgelegt.

6. Schritt 6: Iceberg-Sink schreiben

   Zieltabelle, Schreibmodus, Commit, Partitionierung und Fehlerbehandlung werden aus einer Materialized View heraus konfiguriert.

7. Schritt 7: Partitionierung entwerfen

   Abfrageprädikate, Zeitgranularität, Kardinalität, Datenverteilung und spätere Schemaänderungen werden zu einer tragfähigen Partitionierung verbunden.

8. Schritt 8: Dateigröße und Kompaktierung steuern

   Kleine Dateien, Schreibfrequenz, Kompaktierung, Zielgröße und nachgelagerte Abfragekosten werden anhand von Messdaten bewertet.

9. Schritt 9: Schemaentwicklung absichern

   Neue Spalten, Typänderungen, Umbenennungen und inkompatible Änderungen werden über Testtabellen und geregelte Freigaben behandelt.

10. Schritt 10: Snapshots und Zeitreisen nutzen

    Versionierte Tabellenstände werden für Prüfung, Reproduzierbarkeit, Fehleranalyse und kontrollierte Rücksetzung eingesetzt.

11. Schritt 11: Mehrere Engines integrieren

    RisingWave-Schreibverhalten und Lesezugriffe anderer Analysewerkzeuge werden hinsichtlich Sichtbarkeit, Commit-Stand und konkurrierender Wartung abgestimmt.

12. Schritt 12: Datenqualität und Abstimmung prüfen

    Zeilenanzahl, Schlüssel, Partitionen, Snapshot-Zeit, Kontrollsummen und fachliche Kennzahlen werden Ende zu Ende verglichen.

13. Schritt 13: Betrieb und Kosten überwachen

    Speicherwachstum, Dateianzahl, Commit-Latenz, Sink-Rückstau, Katalogfehler und Abfragekosten werden in einem Betriebsmodell erfasst.

14. Schritt 14: Streaming-Lakehouse abschließen

    Eine vollständige Pipeline von der Ereignisquelle über Transformation und Iceberg-Sink bis zur analytischen Abfrage wird produktionsnah abgenommen.

Praxisübungen

• Katalog und Objektspeicher als Verbindung konfigurieren
• Eine vorhandene Iceberg-Tabelle lesen und ihren Snapshot-Stand prüfen
• Eine partitionierte Iceberg-Zieltabelle aus einem Streaming-Modell befüllen
• Kleine Dateien analysieren und eine Kompaktierungsstrategie entwerfen
• Einen vollständigen Datenabgleich zwischen Quelle, RisingWave und Iceberg durchführen

Methodik

Drei Tage folgen dem Lebenszyklus einer Lakehouse-Tabelle: Architektur und Lesen, Modellierung und Schreiben, anschließend Wartung und Betrieb. Jeder Abschnitt endet mit einer prüfbaren Pipeline-Stufe. Die gewählte Seminardauer beträgt 3 Tage. Drei Tage sind sachlich notwendig, weil Lesen, Schreiben, Modellierung, Partitionierung, Kompaktierung, Schemaentwicklung und Multi-Engine-Betrieb jeweils praktische Laborphasen benötigen.