Seminar Stackable Intensivseminar – Lakehouse, Analytics und Datenprodukte

Inhaltsübersicht

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

Einordnung und Einsatzszenarien

Bündelt Speicher-, Katalog-, Verarbeitungs-, Abfrage- und Governance-Themen zu einer offenen Analytics-Plattform mit betreibbaren Datenprodukten.

Im Mittelpunkt steht Lakehouse- und Analytics-Architekturen mit HDFS, HBase, Hive, Spark, Trino, OpenSearch, Iceberg und Superset. 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 Lakehouse- und Analytics-Architekturen mit HDFS, HBase, Hive, Spark, Trino, OpenSearch, Iceberg und Superset 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 Data Product Owner.

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 Lakehouse- und Analytics-Architekturen mit HDFS, HBase, Hive, Spark, Trino, OpenSearch, Iceberg und Superset 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.

Speicherschichten mit HDFS und objektbasierten Datenzonen

1. Schritt 1: Anforderungen und erwartetes Verhalten für „Speicherschichten mit HDFS und objektbasierten Datenzonen“ im Kontext von Lakehouse- und Analytics-Architekturen mit HDFS, HBase, Hive, Spark, Trino, OpenSearch, Iceberg und Superset bestimmen.
2. Schritt 2: Benötigte Kubernetes-Ressourcen, Konfigurationswerte, Abhängigkeiten und Sicherheitsvorgaben für „Speicherschichten mit HDFS und objektbasierten Datenzonen“ 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.

Hive Metastore, Iceberg und Schemaentwicklung

1. Schritt 1: Anforderungen und erwartetes Verhalten für „Hive Metastore, Iceberg und Schemaentwicklung“ im Kontext von Lakehouse- und Analytics-Architekturen mit HDFS, HBase, Hive, Spark, Trino, OpenSearch, Iceberg und Superset bestimmen.
2. Schritt 2: Benötigte Kubernetes-Ressourcen, Konfigurationswerte, Abhängigkeiten und Sicherheitsvorgaben für „Hive Metastore, Iceberg und Schemaentwicklung“ 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 und Datenpflege

1. Schritt 1: Anforderungen und erwartetes Verhalten für „Spark-Verarbeitung und Datenpflege“ im Kontext von Lakehouse- und Analytics-Architekturen mit HDFS, HBase, Hive, Spark, Trino, OpenSearch, Iceberg und Superset bestimmen.
2. Schritt 2: Benötigte Kubernetes-Ressourcen, Konfigurationswerte, Abhängigkeiten und Sicherheitsvorgaben für „Spark-Verarbeitung 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 und föderierte Zugriffe

1. Schritt 1: Anforderungen und erwartetes Verhalten für „Trino-Abfragen und föderierte Zugriffe“ im Kontext von Lakehouse- und Analytics-Architekturen mit HDFS, HBase, Hive, Spark, Trino, OpenSearch, Iceberg und Superset bestimmen.
2. Schritt 2: Benötigte Kubernetes-Ressourcen, Konfigurationswerte, Abhängigkeiten und Sicherheitsvorgaben für „Trino-Abfragen und föderierte Zugriffe“ 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.

HBase, OpenSearch und spezialisierte Datenmodelle

1. Schritt 1: Anforderungen und erwartetes Verhalten für „HBase, OpenSearch und spezialisierte Datenmodelle“ im Kontext von Lakehouse- und Analytics-Architekturen mit HDFS, HBase, Hive, Spark, Trino, OpenSearch, Iceberg und Superset bestimmen.
2. Schritt 2: Benötigte Kubernetes-Ressourcen, Konfigurationswerte, Abhängigkeiten und Sicherheitsvorgaben für „HBase, OpenSearch und spezialisierte Datenmodelle“ 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.

Superset, Data Mesh, Datenproduktverträge und Governance

1. Schritt 1: Anforderungen und erwartetes Verhalten für „Superset, Data Mesh, Datenproduktverträge und Governance“ im Kontext von Lakehouse- und Analytics-Architekturen mit HDFS, HBase, Hive, Spark, Trino, OpenSearch, Iceberg und Superset bestimmen.
2. Schritt 2: Benötigte Kubernetes-Ressourcen, Konfigurationswerte, Abhängigkeiten und Sicherheitsvorgaben für „Superset, Data Mesh, Datenproduktverträge und Governance“ 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 Lakehouse- und Analytics-Architekturen mit HDFS, HBase, Hive, Spark, Trino, OpenSearch, Iceberg und Superset 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.