Seminar Stackable Data Lakehouse mit Iceberg, Trino, Spark und NiFi

Inhaltsübersicht

• Einordnung und Einsatzszenarien
• Lernziele
• Zielgruppe und Voraussetzungen
• Seminarinhalte
• Praxisübungen
• Arbeitsweise und Dokumentation

Einordnung und Einsatzszenarien

Vermittelt den Aufbau eines offenen Lakehouse mit zuverlässiger Datenaufnahme, tabellarischem Speicherformat, Verarbeitung und interaktiven SQL-Abfragen.

Im Mittelpunkt steht ein offenes Lakehouse auf Kubernetes. Die Übungen orientieren sich an einem realistischen Kubernetes-Cluster und berücksichtigen Konfiguration, Sicherheit, Beobachtbarkeit und wiederholbare Betriebsabläufe. Produktfunktionen werden nicht isoliert betrachtet, sondern in ihre Abhängigkeiten innerhalb einer modularen Datenplattform eingeordnet.

Lernziele

• die Architektur und den Lebenszyklus von ein offenes Lakehouse auf Kubernetes fachlich einordnen
• benötigte Operatoren, Custom Resources, Konfigurationen und Abhängigkeiten nachvollziehbar auswählen
• Bereitstellung und Änderungen schrittweise durchführen und anhand technischer Zustände verifizieren
• Identitäten, Verbindungen, Secrets und Berechtigungen entsprechend dem jeweiligen Schutzbedarf gestalten
• Metriken, Logs, Events und Statusinformationen für den laufenden Betrieb auswerten
• Störungen mit einem reproduzierbaren Diagnoseverfahren eingrenzen und dokumentieren

Zielgruppe und Voraussetzungen

Zielgruppe: Data Architects, Data Engineers, Analytics Engineers, Plattformadministration und technische Projektleitung.

Voraussetzungen: Grundkenntnisse in Kubernetes, Linux, Containern, YAML und verteilten Datensystemen; praktische Erfahrung mit einer Kommandozeile ist hilfreich.

Seminarinhalte

Architektur, Verantwortlichkeiten und Einsatzgrenzen

1. Schritt 1: Geschäftliche und technische Anforderungen für ein offenes Lakehouse auf Kubernetes erfassen und priorisieren.
2. Schritt 2: Beteiligte Plattformkomponenten, Datenpfade, Schnittstellen und Fehlerdomänen in einem Architekturmodell abgrenzen.
3. Schritt 3: Operatoren, Rollen, Custom Resources und gemeinsame Dienste den vorgesehenen Verantwortlichkeiten zuordnen.
4. Schritt 4: Akzeptanzkriterien für Bereitstellung, Sicherheit, Leistung und Betriebsfähigkeit festlegen.

Objekt- oder Dateispeicher, Katalog und Iceberg-Tabellen

1. Schritt 1: Anforderungen und erwartetes Verhalten für „Objekt- oder Dateispeicher, Katalog und Iceberg-Tabellen“ im Kontext von ein offenes Lakehouse auf Kubernetes bestimmen.
2. Schritt 2: Benötigte Kubernetes-Ressourcen, Konfigurationswerte, Abhängigkeiten und Sicherheitsvorgaben für „Objekt- oder Dateispeicher, Katalog und Iceberg-Tabellen“ festlegen.
3. Schritt 3: Konfiguration kontrolliert anwenden, Status und technische Wirkung mit geeigneten Prüfungen verifizieren.
4. Schritt 4: Abweichungen analysieren, Betriebsgrenzen dokumentieren und einen reproduzierbaren Prüf- oder Wiederholungsablauf erstellen.

NiFi-Ingestion und standardisierte Landing-Zonen

1. Schritt 1: Anforderungen und erwartetes Verhalten für „NiFi-Ingestion und standardisierte Landing-Zonen“ im Kontext von ein offenes Lakehouse auf Kubernetes bestimmen.
2. Schritt 2: Benötigte Kubernetes-Ressourcen, Konfigurationswerte, Abhängigkeiten und Sicherheitsvorgaben für „NiFi-Ingestion und standardisierte Landing-Zonen“ festlegen.
3. Schritt 3: Konfiguration kontrolliert anwenden, Status und technische Wirkung mit geeigneten Prüfungen verifizieren.
4. Schritt 4: Abweichungen analysieren, Betriebsgrenzen dokumentieren und einen reproduzierbaren Prüf- oder Wiederholungsablauf erstellen.

Spark-Verarbeitung, Compaction und Datenpflege

1. Schritt 1: Anforderungen und erwartetes Verhalten für „Spark-Verarbeitung, Compaction und Datenpflege“ im Kontext von ein offenes Lakehouse auf Kubernetes bestimmen.
2. Schritt 2: Benötigte Kubernetes-Ressourcen, Konfigurationswerte, Abhängigkeiten und Sicherheitsvorgaben für „Spark-Verarbeitung, Compaction und Datenpflege“ festlegen.
3. Schritt 3: Konfiguration kontrolliert anwenden, Status und technische Wirkung mit geeigneten Prüfungen verifizieren.
4. Schritt 4: Abweichungen analysieren, Betriebsgrenzen dokumentieren und einen reproduzierbaren Prüf- oder Wiederholungsablauf erstellen.

Trino-Abfragen, Schemaentwicklung, Partitionierung und Betriebsverfahren

1. Schritt 1: Anforderungen und erwartetes Verhalten für „Trino-Abfragen, Schemaentwicklung, Partitionierung und Betriebsverfahren“ im Kontext von ein offenes Lakehouse auf Kubernetes bestimmen.
2. Schritt 2: Benötigte Kubernetes-Ressourcen, Konfigurationswerte, Abhängigkeiten und Sicherheitsvorgaben für „Trino-Abfragen, Schemaentwicklung, Partitionierung und Betriebsverfahren“ festlegen.
3. Schritt 3: Konfiguration kontrolliert anwenden, Status und technische Wirkung mit geeigneten Prüfungen verifizieren.
4. Schritt 4: Abweichungen analysieren, Betriebsgrenzen dokumentieren und einen reproduzierbaren Prüf- oder Wiederholungsablauf erstellen.

Betriebsprüfung und systematische Fehleranalyse

1. Schritt 1: Sollzustand, Istzustand und letzte Änderungen anhand von Custom Resources, Conditions und Kubernetes-Events vergleichen.
2. Schritt 2: Produkt-, Operator- und Plattformlogs zeitlich korrelieren und die wahrscheinlichste Fehlerdomäne bestimmen.
3. Schritt 3: Metriken und Kapazitätsdaten gegen definierte Schwellenwerte prüfen und geeignete Korrekturmaßnahmen ableiten.
4. Schritt 4: Fehlerbehebung kontrolliert durchführen, Funktionsprüfung wiederholen und Erkenntnisse in einem Runbook festhalten.

Praxisübungen

• eine lauffähige Beispielkonfiguration für ein offenes Lakehouse auf Kubernetes erstellen und prüfen
• Konfigurationsänderungen versioniert vorbereiten, einspielen und zurücknehmen
• einen Sicherheits- oder Zugriffsfall mit überprüfbaren Identitäten und Berechtigungen umsetzen
• eine absichtlich eingebrachte Störung mit Logs, Metriken, Events und Statusfeldern eingrenzen
• eine kompakte Betriebscheckliste mit Prüfkommandos, Sollwerten und Eskalationskriterien erstellen

Arbeitsweise und Dokumentation

Kurze fachliche Einführungen wechseln mit Demonstrationen und geführten Übungen. Jeder Arbeitsschritt wird zunächst begründet, anschließend umgesetzt, technisch verifiziert und in einer wiederverwendbaren Checkliste dokumentiert. Konfigurationen werden so aufgebaut, dass Varianten für Entwicklung, Test und Produktion nachvollziehbar abgeleitet werden können.