Seminar Ontop Datenquellen und Cloud-Datenplattformen

Datenquellen unterscheiden sich deutlich bei SQL-Dialekten, Metadatenqualität, Datentypen und Verbindungsverhalten. Eine systematische Connector-Strategie verhindert fehlerhafte Annahmen und schafft eine reproduzierbare Grundlage für Mapping und Abfrageoptimierung.

Inhaltsverzeichnis

1. Connector- und Dialektarchitektur
2. Klassische relationale Datenbanken
3. Cloud-Warehouses und Lakehouse-Plattformen
4. Föderatoren und verteilte Abfrageebenen
5. Verschachtelte Daten und Flatten-Verfahren
6. Abnahme- und Betriebscheck je Datenquelle

Lernziele

• Unterstützte Datenquellen nach Architektur, Dialekt und Einsatzszenario einordnen.
• JDBC-Verbindungen und Treiber reproduzierbar konfigurieren und prüfen.
• Fehlende oder unvollständige Metadaten durch explizite Constraints ausgleichen.
• Eine technische Abnahmematrix für relationale und cloudbasierte Plattformen erstellen.

Zielgruppe

Data Engineering, Datenbankadministration, Cloud-Plattformteams, Ontop-Entwicklung und Lösungsarchitektur.

Voraussetzungen

SQL-Grundkenntnisse, Verständnis relationaler Schemas und grundlegende Kenntnisse zu Ontop-Mappings.

Kapitel 1: Connector- und Dialektarchitektur

Kapitel-Inhaltsverzeichnis: JDBC, datenbankspezifische Implementierungen, Treiber, Schemas und Namensauflösung.

1. Schritt 1: Die Datenquelle wird einer unterstützten Dialektfamilie zugeordnet und von generischem JDBC abgegrenzt.
2. Schritt 2: Treiber, Verbindungszeichenfolge, Standardkatalog und Schema werden dokumentiert und isoliert getestet.
3. Schritt 3: Ein Basissatz aus Datentyp-, Funktions- und Metadatenabfragen wird als Connector-Smoke-Test ausgeführt.

Kapitel 2: Klassische relationale Datenbanken

Kapitel-Inhaltsverzeichnis: PostgreSQL, MySQL und MariaDB, SQL Server, Oracle, DB2 und H2.

1. Schritt 1: Für jede relevante Plattform werden Bezeichnerregeln, Datentypbesonderheiten und Funktionsgrenzen erfasst.
2. Schritt 2: Ein identisches semantisches Mapping wird auf zwei Dialekten umgesetzt und die erzeugten SQL-Abfragen werden verglichen.
3. Schritt 3: Plattformspezifische Abweichungen werden in einer wiederverwendbaren Mapping- und Testkonvention festgehalten.

Kapitel 3: Cloud-Warehouses und Lakehouse-Plattformen

Kapitel-Inhaltsverzeichnis: Snowflake, Databricks, BigQuery, Redshift und skalierbare Query Engines.

1. Schritt 1: Authentisierung, Netzwerkzugang und Ressourcenzuordnung werden getrennt von der Ontop-Konfiguration geplant.
2. Schritt 2: Kosten- und Latenztreiber wie Scanvolumen, Warehouse-Start und Datenpartitionierung werden in Testabfragen sichtbar gemacht.
3. Schritt 3: Für fehlende Schlüsselmetadaten werden explizite Constraints vorbereitet und deren Wirkung geprüft.

Kapitel 4: Föderatoren und verteilte Abfrageebenen

Kapitel-Inhaltsverzeichnis: Trino, Presto, Athena, Denodo, Dremio und SparkSQL als einheitlicher Zugriffspunkt.

1. Schritt 1: Die Verantwortungsgrenze zwischen Ontop und dem Föderator wird anhand von Pushdown und Quellzugriff definiert.
2. Schritt 2: Katalog- und Schemanamen werden stabilisiert, damit Mappings nicht von wechselnden Sitzungsstandards abhängen.
3. Schritt 3: Eine quellenübergreifende Abfrage wird auf Datenbewegung, Join-Ort und Engpass untersucht.

Kapitel 5: Verschachtelte Daten und Flatten-Verfahren

Kapitel-Inhaltsverzeichnis: Arrays, JSON-Strukturen, Typinferenz und Grenzen der Plattformen.

1. Schritt 1: Verschachtelte Spalten werden nach Array, strukturierter Spalte oder JSON-codiertem Text klassifiziert.
2. Schritt 2: Ein Flatten-Lens wird mit explizitem Ausgabetyp und benötigten Ursprungsspalten modelliert.
3. Schritt 3: Abfrageergebnis, Kardinalität und Positionserhalt werden mit kontrollierten Testdaten validiert.

Kapitel 6: Abnahme- und Betriebscheck je Datenquelle

Kapitel-Inhaltsverzeichnis: Kompatibilität, Leistung, Fehlerverhalten, Dokumentation und Freigabe.

1. Schritt 1: Eine Abnahmematrix mit Verbindung, Datentypen, Funktionen, Metadaten, Parallelität und Grenzfällen wird erstellt.
2. Schritt 2: Störungen wie abgelaufene Zugangsdaten, Zeitüberschreitungen und Schemaänderungen werden simuliert.
3. Schritt 3: Nur geprüfte Kombinationen aus Treiber, Plattformversion und Ontop-Konfiguration werden als Betriebsstandard freigegeben.