Seminar Aiven Intensiv – Streaming und Datenpipelines

Dieser Intensivpfad fasst sämtliche Streaming-, Kafka- und Pipeline-Seminare in einer kompakten Woche zusammen. Eine gemeinsame Ereignisstrecke wird von der Topicarchitektur bis zur Multi-Region-Umschaltung aufgebaut.

Inhaltsverzeichnis

1. Einordnung und Nutzen
2. Zielgruppe
3. Voraussetzungen
4. Lernziele
5. Seminarinhalte
6. Tag 1: Kafka-Architektur und Servicebereitstellung
7. Tag 2: Clients, Consumer Groups, Sicherheit und Schemas
8. Tag 3: Kafka Connect und Datenintegration
9. Tag 4: Flink SQL und ClickHouse-Analytics
10. Tag 5: Storage, Multi-Region und Incident-Übung
11. Praxisübungen

Einordnung und Nutzen

Die Woche verdichtet Kafka-Administration, Client- und Topicdesign, Sicherheit, Karapace, Kafka Connect, PostgreSQL-Ingestion, Flink SQL, ClickHouse-Analytics, Inkless Kafka, Tiered Storage und MirrorMaker 2. Jede Stufe wird mit Messwerten, Fehlerpfad und Betriebsrunbook verbunden.

Zielgruppe

• Cloud- und Plattformadministration
• DevOps- und Site-Reliability-Engineering
• Technische Architektur und Betrieb
• Software- und Datenentwicklung
• DevOps- und Plattform-Engineering
• Technische Architektur
• Data Engineering und Event-Streaming-Architektur

Voraussetzungen

• Grundkenntnisse zu Cloud-Diensten, Netzwerken und Datenbanken
• Sicherer Umgang mit Browser und Kommandozeile
• Für Übungen ein freigegebenes Aiven-Projekt oder eine vorbereitete Schulungsumgebung
• Grundverständnis von Kafka und SQL
• Erfahrung mit verteilten Datenanwendungen ist hilfreich

Lernziele

• Eine produktionsnahe Kafka-Plattform auf Aiven planen und absichern
• Topics, Clients, Schemas und Consumer Groups belastbar konfigurieren
• Daten mit Kafka Connect und verwalteten Integrationen bewegen
• Ereignisse mit Flink SQL verarbeiten und in ClickHouse analysieren
• Classic-, Inkless- und diskless Speicherpfade passend dimensionieren
• Multi-Region-Replikation, Monitoring und Failover mit MirrorMaker 2 durchführen

Seminarinhalte

Jeder Arbeitsschritt wird praktisch umgesetzt, mit einem kurzen Funktionstest geprüft und als wiederholbarer Betriebsablauf dokumentiert.

Tag 1: Kafka-Architektur und Servicebereitstellung

Der erste Tag errichtet die technische Grundlage der Streaming-Plattform.

1. Schritt 1: Komponenten und KRaft-Modell einordnen. Praktisches Arbeitsergebnis: Broker, Controller, Partitionen, Replikate und verwaltete Verantwortungsgrenzen in ein Betriebsbild überführt.
2. Schritt 2: Classic und Inkless auswählen. Praktisches Arbeitsergebnis: Latenz, Retention, Durchsatz, Objektstorage, Planmodell und Skalierungsbedarf anhand der gemeinsamen Fallstudie bewertet.
3. Schritt 3: Service, Netzwerk und TLS-Zugang bereitstellen. Praktisches Arbeitsergebnis: Region, Plan, Tags, Benutzer und Clientverbindung eingerichtet und mit einem kontrollierten Produce-/Consume-Test verifiziert.
4. Schritt 4: Topic- und Partitionsmodell erstellen. Praktisches Arbeitsergebnis: Ereignistypen, Schlüssel, Reihenfolge, Parallelität, Replikation, Retention und Kompaktierung festgelegt.
5. Schritt 5: Grundmonitoring etablieren. Praktisches Arbeitsergebnis: Durchsatz, Fehler, Partitionen, Ressourcen und Consumer Lag als Baseline erfasst und erste Schwellen dokumentiert.

Tag 2: Clients, Consumer Groups, Sicherheit und Schemas

Der zweite Tag stabilisiert Datenvertrag und Zugriffsmodell.

1. Schritt 1: Produzentenkonfiguration testen. Praktisches Arbeitsergebnis: Acknowledgements, Idempotenz, Batching, Kompression und Retry unter Normal- und Fehlerlast verglichen.
2. Schritt 2: Consumer Groups betreiben. Praktisches Arbeitsergebnis: Partitionzuordnung, Offsets, Rebalance und Lag mit mehreren Instanzen nachvollzogen und eine sichere Offsetentscheidung geübt.
3. Schritt 3: ACLs und Servicebenutzer umsetzen. Praktisches Arbeitsergebnis: Rollen für Producer, Consumer und Administration mit minimalen Topic- und Gruppenrechten eingerichtet und negativ getestet.
4. Schritt 4: Karapace und Datenvertrag einführen. Praktisches Arbeitsergebnis: Schema registriert, Serialisierung geprüft, kompatible Änderung veröffentlicht und brechende Änderung abgewiesen.
5. Schritt 5: Betriebsstandards dokumentieren. Praktisches Arbeitsergebnis: Namenskonvention, Topicanlage, Schemafreigabe, Benutzerrotation und Clientkonfiguration in wiederverwendbare Checklisten überführt.

Tag 3: Kafka Connect und Datenintegration

Der dritte Tag verbindet operative Quellen und Zielsysteme.

1. Schritt 1: Connect-Betriebsform auswählen. Praktisches Arbeitsergebnis: eingebetteter und dedizierter Betrieb nach Ressourcenisolation, Skalierung und Inkless-Anforderung verglichen.
2. Schritt 2: Source-Connector bereitstellen. Praktisches Arbeitsergebnis: Datenbankquelle, Converter, Topicabbildung und Polling beziehungsweise Änderungsstrom eingerichtet und kontrolliert.
3. Schritt 3: Sink-Connector bereitstellen. Praktisches Arbeitsergebnis: Zielsystem, Batchverhalten, Schlüssel und Schreibsemantik konfiguriert und mit Datenvergleich abgenommen.
4. Schritt 4: Secrets und Pluginversionen steuern. Praktisches Arbeitsergebnis: Kennwörter über geeigneten Secret-Mechanismus referenziert, Connectorversion festgelegt und Upgradeprüfung vorbereitet.
5. Schritt 5: Fehlerpfad und Connect-Monitoring umsetzen. Praktisches Arbeitsergebnis: Retries, Dead-Letter-Topic, Taskstatus, automatische Neustarts und Metriken an absichtlich fehlerhaften Daten getestet.

Tag 4: Flink SQL und ClickHouse-Analytics

Der vierte Tag verarbeitet den Ereignisstrom zustandsbehaftet und macht ihn analytisch nutzbar.

1. Schritt 1: Flink-Anwendung und Tabellen modellieren. Praktisches Arbeitsergebnis: Kafka-Quell- und Senkentabellen mit Datentypen, Schlüssel und Event Time erstellt und interaktiv geprüft.
2. Schritt 2: Transformation und Datenqualität entwickeln. Praktisches Arbeitsergebnis: Filter, Normalisierung, Fehlerstrom, Zeitfenster und Aggregation schrittweise aufgebaut.
3. Schritt 3: Anreicherung und Upsert umsetzen. Praktisches Arbeitsergebnis: Referenzdaten verbunden, Changelog-Semantik bewertet und ein aktueller Objektzustand als Upsert-Strom erzeugt.
4. Schritt 4: ClickHouse integrieren und modellieren. Praktisches Arbeitsergebnis: Streamingquelle, MergeTree-Tabelle, Sortierschlüssel und Materialized View eingerichtet und vollständigkeitsgeprüft.
5. Schritt 5: Ende-zu-Ende-Latenz messen. Praktisches Arbeitsergebnis: Zeitpunkte über Quelle, Kafka, Flink und ClickHouse verfolgt und der größte Verzögerungsanteil identifiziert.

Tag 5: Storage, Multi-Region und Incident-Übung

Der fünfte Tag prüft Kapazität und Ausfallverhalten der gesamten Strecke.

1. Schritt 1: Diskless und klassisches Topic vergleichen. Praktisches Arbeitsergebnis: identische Last auf unterschiedlichen Topictypen gemessen und nach Latenz, Wiederlesen, Retention und Kostenwirkung bewertet.
2. Schritt 2: Kapazitäts- und Retentionmodell erstellen. Praktisches Arbeitsergebnis: Durchsatz, Nachrichtengröße, Partitionen, Aufbewahrung, Objektstorage und Sicherheitsreserve in ein nachvollziehbares Sizing überführt.
3. Schritt 3: MirrorMaker-2-Flow aufbauen. Praktisches Arbeitsergebnis: Quell- und Zielcluster, Aliases, Topicfilter, ACLs und Replikationsrichtung eingerichtet und Datenfluss kontrolliert.
4. Schritt 4: Failover und Offsetwechsel testen. Praktisches Arbeitsergebnis: Replikationsrückstand geprüft, Produzenten und Consumer umgeschaltet, Offsetbezug verifiziert und Datenvollständigkeit nachgewiesen.
5. Schritt 5: Gesamtincident bearbeiten. Praktisches Arbeitsergebnis: Connectorausfall, Lagspitze, fehlerhafte Schemaänderung und Zielverzögerung priorisiert, stabilisiert und in einer Abschlussanalyse dokumentiert.

Praxisübungen

• Durchgängige Streaming-Fallstudie mit Kafka, Connect, Flink und ClickHouse
• ACL- und Schemakompatibilitätstest
• Connectorfehler mit Dead-Letter- und Wiederanlaufprozess
• Flink-Fensteraggregation und Upsert-Verarbeitung
• Vergleich von klassischem und diskless Topic
• MirrorMaker-2-Failover mit Offset- und Vollständigkeitskontrolle