Ein Leitfaden zur Daten-Tool-Landschaft für Entwickler

• Für Softwareentwickler, die neu in den Datenbereich einsteigen, wird die gesamte Landschaft so eingeordnet, dass sie nicht nur Tool-Namen auswendig lernen, sondern verstehen, welche Rolle die einzelnen Tools in den Phasen Erfassung/Speicherung/Verarbeitung/Nutzung von Daten spielen und wie sie miteinander verbunden sind
• Datenrollen lassen sich grob in Analyse/Wissenschaft/Engineering/Machine Learning einteilen; sie behandeln unterschiedliche Probleme und Tools – von SQL und BI über statistische Modelle und Notebooks bis hin zu Pipeline-Infrastruktur und dem Deployment von Modellen im Betrieb
• Speicher werden unterschieden in Data Warehouses, die schnelle Analysen und Komfort bieten, kostengünstige und flexible Data Lakes sowie Lakehouses, die dem Tabellenformat ACID und Schemaverwaltung hinzufügen
• Datenverarbeitung reicht von SQL-Transformationen wie dbt über lokale Verarbeitung mit pandas und DuckDB, verteilte Batch-Verarbeitung mit Spark bis hin zu Stream-Verarbeitung mit Kafka und Flink; Orchestratoren wie Airflow verwalten die Ausführungsreihenfolge unabhängiger Jobs und die Wiederherstellung nach Fehlern
• Verarbeitete Daten werden nicht nur für Dashboards genutzt, sondern auch für Vertrieb/Support, Ad-hoc-Analysen, Machine Learning, Analysefunktionen im Produkt und den Verkauf von Daten; mit wachsender Größe werden Katalog/Semantische Schicht/Lineage/Governance zur zentralen Grundlage, um Bedeutung und Verantwortlichkeit von Daten zu erhalten

---

Was Entwickler wissen sollten

• Dies ist eine Übersicht für Entwickler, erstellt von einem Software Engineer, der zu einem Datenunternehmen kam, aber keinen entsprechenden Hintergrund hatte, um den Zweck der Tools und ihr Zusammenspiel mit Notebooks zu verstehen
• Nicht behandelt werden der Bau von Dashboards, statistische Grundlagen, der Betrieb von Spark-Clustern oder tiefe Produktvergleiche innerhalb derselben Kategorie
• Entlang der Frage, wo Daten entstehen und wie sie verarbeitet, gespeichert und angezeigt werden, werden die Lebenszyklusphasen unterschieden, für die die einzelnen Tools zuständig sind

Vier Typen von Datenrollen

• In der Praxis sind die Grenzen der Rollen unscharf, besonders in kleinen Unternehmen oder Teams; zum Verständnis der Gesamtlandschaft lassen sie sich aber in vier Typen einteilen
• Analytisch: interpretiert Daten mit SQL und Tabellenkalkulationen und visualisiert Insights
  • Typische Rollen sind Data Analyst und BI Analyst; sie verwenden Tableau, Excel und ähnliche Tools
  • Ein Beispiel ist, Kundendaten abzufragen, die Abwanderungsrate nach Region zu berechnen und daraus ein Tableau-Dashboard sowie Vorschläge für Retention-Kampagnen zu erstellen
• Wissenschaftlich: behandelt mit Statistik, Modellen und Experimenten tiefere Fragen oder Vorhersagen jenseits oberflächlicher Berichte
  • Typische Rolle ist Data Scientist; hauptsächlich werden Python, pandas, scikit-learn und Notebooks genutzt
  • Möglich ist etwa, Abwanderungsfaktoren zu untersuchen, ein Modell für die Abwanderungswahrscheinlichkeit einzelner Kunden zu erstellen und anschließend A/B-Tests für Retention-Kampagnen zu entwerfen und auszuwerten
• Engineering-orientiert: sammelt, bereinigt und standardisiert Quelldaten, lädt sie in Warehouses oder Lakes und betreibt Datentools und Datenbanken
  • Typische Rolle ist Data Engineer; genutzt werden Python, Apache Spark, Datenbanken, Warehouses und Cloud
  • Beispiele sind, Analyseergebnisse zu einer wiederholbar ausführbaren Reverse-ETL-Pipeline auszubauen oder Transaktionsdaten aus mehreren Quellen zu integrieren und Schema-, Query- und Qualitätsprüfungen zu verwalten
• Machine-Learning-orientiert: erstellt und betreibt KI-Modelle, von Klassifikationsmodellen bis zu LLMs
  • Diese Kategorie fasst ML Scientist und ML Engineer zusammen; da es ein großes eigenes Tool-Ökosystem gibt, wird sie im Text nicht im Detail behandelt
  • Dazu gehört, Trainingsdaten für Empfehlungsmodelle zusammenzustellen, Modelle zu trainieren und abzustimmen, sie als API bereitzustellen, Vorhersagen zu überwachen und bei Verhaltensänderungen neu zu trainieren

ETL und ELT

• ETL (Extract-Transform-Load) ist ein typischer Ablauf: Quelldaten werden extrahiert, bereinigt oder mit anderen Daten kombiniert und das Ergebnis anschließend in ein Ziel geladen
• Die Reihenfolge der Schritte ist nicht festgelegt; sie können sich wiederholen oder überschneiden
• ELT lädt Quelldaten zuerst in ein Warehouse, transformiert sie dort und speichert die Ergebnisse in separaten Tabellen
  • Durch zusätzlichen Speicherplatz und Rechenaufwand können die Kosten steigen
  • Da die Rohdaten erhalten bleiben, lassen sie sich später auf andere Weise erneut verarbeiten

Datei- und Speicherformate

• CSV eignet sich gut, um kleine Datenmengen weiterzugeben, und lässt sich in den meisten Office-Programmen öffnen, weshalb es für nichttechnische Nutzer passend ist
• Apache Parquet ist ein spaltenorientiertes Dateiformat mit hoher Kompression, das große Daten effizient speichern und übertragen kann
  • Es wird von den meisten Datentools unterstützt und dient als gemeinsames Format zwischen Tools
  • Apache ORC löst ähnliche Probleme
• Apache Avro ist ein zeilenorientiertes Binärformat für die Übertragung von Datensätzen, insbesondere in der Stream-Verarbeitung
• Apache Arrow ist ein De-facto-Standard für ein In-Memory-Format, das für Verarbeitung und Zero-Copy-Übertragung optimiert ist
  • Parquet konzentriert sich auf kleine Dateien und das Scannen benötigter Elemente, Arrow auf tatsächliche Berechnungen unter Nutzung von CPU-/GPU-Instruktionen und Caches
  • Arrow verwendet mehr Speicher, überträgt Daten aber effizient zwischen Tools wie pandas und DataFusion in Rust
  • Es kann als optionales Backend für pandas verwendet werden; Polars und DataFusion wurden von Anfang an auf Arrow-Basis entwickelt

Data Warehouse

• Ein Data Warehouse ähnelt Datenbanken wie PostgreSQL oder MySQL, ist aber für analytische Lasten optimiert
• OLTP-Datenbanken wie MySQL eignen sich dafür, eine einzelne Nutzerzeile per ID zu finden; OLAP-Warehouses eignen sich für spaltenweise Aggregationen, etwa die Jahressumme des Umsatzes nach Region
• Traditionell waren sie der finale Speicherort für bereinigte, strukturierte Daten; bei ELT dienen sie aber auch als erster Ladepunkt für Rohdaten
• Da Speicherformat und Query Engine eng gekoppelt sind, bieten sie schnelle BI- und Reporting-Queries, sind unter den drei Speichertypen jedoch am teuersten
• Produkte sind Snowflake, BigQuery und Redshift
• Open-Source- und Self-Hosting-Optionen sind ClickHouse, Apache Doris und StarRocks
• Für kleine Projekte kann auch eine klassische Datenbank ausreichen

Data Lake

• Ein Data Lake ähnelt eher einem großen Cloud-Ordner, in dem strukturierte, semistrukturierte und unstrukturierte Daten wie CSV, Parquet, JSON, E-Mails oder Bilder mit minimaler Verarbeitung abgelegt werden
• Er lässt sich aufbauen, indem man in Amazon S3, Google Cloud Storage oder Azure Blob Storage Namens- und Partitionierungsregeln sowie Zugriffsrichtlinien festlegt und dort Dateien speichert
• Ohne sauberes Management kann daraus ein Datensumpf (data swamp) werden, in dem sich Daten schwer finden oder nutzen lassen
• Zu den Managed-Optionen gehören Azure Data Lake und die Data-Lake-Funktionen von Snowflake
• Um Daten abzufragen, ohne sie direkt zu suchen, herunterzuladen und zu parsen, braucht man einen Metadatenkatalog und eine Query Engine
  • Der Katalog hält Tabellennamen, Schemas und Dateizuordnungen fest
  • Die Query Engine liest anhand dieser Metadaten die relevanten Dateien und führt Abfragen etwa in SQL aus
• Kataloge sind Hive Metastore, AWS Glue Data Catalog und Unity Catalog
• Query Engines sind Apache Spark, Trino und Amazon Athena

Data Lakehouse

• Ein Data Lakehouse ergänzt einen günstigen und flexiblen Data Lake um Funktionen, die einem Warehouse nahekommen.
• Die zentrale Komponente, das Tabellenformat, verwaltet zwischen Query Engine und Rohdaten, wie die Daten gespeichert werden.
  • Mit ACID werden gleichzeitige Schreibvorgänge, Fehler während des Schreibens und Datenkorruption behandelt.
  • Auch für semistrukturierte Daten muss ein Schema definiert werden; vollständig unstrukturierte Daten profitieren nicht von den Vorteilen eines Tabellenformats.
  • Unterstützt Schema Evolution und Versionierung.
  • Indizes und Partitionsoptimierung können Abfragen beschleunigen.
  • Einige Implementierungen unterstützen Time Travel, also Abfragen von Snapshots zu einem bestimmten Zeitpunkt.
• Da es auf einem Data Lake basiert, kann es günstiger sein als ein Warehouse und ist nicht an eine bestimmte Query Engine gebunden; ein 1:1-Preisvergleich ist jedoch schwierig, weil separate Rechenkosten einbezogen werden müssen.
• Wichtige Tabellenformate sind Apache Iceberg, Delta Lake und Apache Hudi.
• Zu den Managed Services gehören Googles Lakehouse for Apache Iceberg, Databricks und IBM watsonx.data.

Datenquellen und Ingestion

• Daten kommen aus Anwendungsdatenbanken wie PostgreSQL oder Mongo, aus externen APIs wie Stripe, aus Browser-Analytics-Events, IoT-Geräten und weiteren Quellen.
• Nach der Extraktion können sie direkt verarbeitet werden; bei ELT können die Rohdaten je nach Form, Größe und Infrastruktur zuerst in einem Lake, Lakehouse oder Warehouse gespeichert werden.
• Eigene Skripte sind flexibel, erfordern aber, wiederkehrenden Verbindungscode für Authentifizierung, Pagination, Fehlerbehandlung und Ähnliches erneut zu implementieren.
• Daten-Ingestion-Tools übernehmen diese wiederkehrende Arbeit, indem Quell- und Ziel-Connectoren konfiguriert werden.
  • Da extrahierte Daten zuerst irgendwo geladen werden müssen, tendieren sie leicht zu ELT-Flows.
  • Typische Produkte sind Fivetran, Airbyte und dlt.
• Change Data Capture (CDC) erfasst Inserts, Updates und Deletes aus Replikationslogs von Datenbanken, ohne Tabellen wiederholt abzufragen.
  • Ingestion-Tools nutzen dies intern für Datenbankquellen.
  • Als eigenständige Open-Source-Komponente ist Debezium weit verbreitet.

Datenverarbeitungssprachen

• Python ist die De-facto-Standardsprache für Datenarbeit, mit einer großen Community und einem Ökosystem nativer Libraries.
  • Auch Tools, die in anderen Sprachen entwickelt wurden, bieten häufig Python-Bindings; ein Beispiel ist das Rust-basierte Apache DataFusion.
• numpy stellt leistungsfähige mehrdimensionale Arrays bereit und bildet die Grundlage vieler Libraries.
• pandas ist der De-facto-Standard und bietet eindimensionale Series sowie zweidimensionale DataFrames.
  • Mit seaborn und Plotly lassen sich Visualisierungen erstellen, mit streamlit interaktive Apps.
  • Mit DuckDB können SQL-Abfragen ausgeführt oder mit scikit-learn Machine-Learning-Methoden angewendet werden.
• R wird in der Wissenschaft genutzt, Java und Scala in Big-Data-Frameworks wie Spark; auch Julia und Rust kommen in der Datenarbeit zum Einsatz, sind aber weniger verbreitet als Python.
• SQL wird breit für Warehouse-Abfragen und Transformationen eingesetzt, die Syntax unterscheidet sich jedoch je nach Ausführungsumgebung leicht.

Batch- und Echtzeitverarbeitung

• Batch-Verarbeitung verarbeitet große Datenmengen regelmäßig, etwa die Umsatzaggregation des letzten Monats, und eignet sich für Aufgaben, bei denen man Stunden oder Tage auf das Ergebnis warten kann.
• Echtzeitverarbeitung nutzt Stream-Verarbeitung unmittelbar beim Eintreffen der Daten oder Micro-Batches, etwa in 20-Sekunden-Intervallen.
• Pipelines, bei denen die Ergebnisgeschwindigkeit wichtig ist, etwa Bot-Erkennung, verwenden Echtzeitverarbeitung, um Nutzer möglichst schnell zu identifizieren und zu blockieren.

SQL-basierte Transformation

• dbt und SQLMesh definieren Transformationen über SQL-select-Anweisungen und kompilieren sie so, dass sie auf der eigentlichen Query Engine ausgeführt werden.
• Beide Tools verarbeiten Daten nicht direkt, sondern übernehmen die Transformationsorchestrierung.
• Im Vergleich zu benutzerdefinierten Python-Skripten standardisieren sie die Transformationsweise und können komplexe Aufgaben in kleine, voneinander abhängige Modelle aufteilen.
• ref in dbt verweist auf Modelle statt auf hartcodierte Tabellennamen und führt sie gemäß dem Abhängigkeitsgraphen in der richtigen Reihenfolge aus.
• Die Ergebnisse werden üblicherweise im selben Warehouse, Lakehouse oder Lake wie die Rohdaten gespeichert, können je nach Konfiguration der Query Engine aber auch an andere Ziele gesendet werden.

Lokale DataFrames und DuckDB

• Ein DataFrame ist eine zweidimensionale Array-Abstraktion für tabellarische Daten; in Python ist pandas am weitesten verbreitet.
• Weitere Implementierungen sind Polars für Python und Rust, DataFusion für Rust, DataFrames.jl für Julia, data.frame für R und tablesaw für Java.
• pandas, data.frame und tablesaw arbeiten eager, führen Operationen also unmittelbar beim Aufruf aus.
• DataFusion und Polars’ LazyFrame sammeln Operationen zunächst als logischen Plan und führen sie dann mit .collect() aus.
  • Da der Plan vor der Ausführung optimiert werden kann, besteht die Möglichkeit höherer Geschwindigkeit.
• Lokale Libraries sind durch Arbeitsspeicher und CPU begrenzt.
  • pandas verarbeitet alle Daten im Speicher und ist daher an die RAM-Größe gebunden.
  • Polars’ Streaming kann auch Daten verarbeiten, die größer als der RAM sind; einige Operationen müssen jedoch das Working Set in den Speicher laden.
• DuckDB ist eine In-Process-OLAP-Datenbank, die als „SQLite für Analytics“ bezeichnet wird.
  • Sie kann lokale CSV-, Parquet- und pandas-DataFrames ohne separate Infrastruktur per SQL abfragen.

Große verteilte Verarbeitung

• Wenn die Grenzen einer einzelnen Maschine überschritten werden, werden Daten in mehrere Teile aufgeteilt, in einem Cluster parallel verarbeitet und passend zur Arbeitslast horizontal skaliert.
• Apache Hadoop war ein frühes wichtiges Tool, gilt heute jedoch als Legacy und ist vor allem in älteren Umgebungen anzutreffen.
• Apache Spark ist derzeit der De-facto-Standard und übernimmt Data Loading, Transformation, Parallelisierung und Optimierung.
  • PySpark bietet eine DataFrame-API und eine pandas-kompatible Schicht.
  • SparkR wurde kürzlich eingestellt; Java- und Scala-Bindings werden ebenfalls angeboten.
  • Da Spark viele unterschiedliche Speicher lesen und schreiben kann, wird es sowohl als Query Engine für Data Lakes als auch für groß angelegte Transformationsjobs eingesetzt.
• Dask skaliert Python-Code in Cluster und bleibt dabei nahe an vertrauten pandas- und numpy-APIs.
• Ray ist ein allgemeines Framework für verteiltes Rechnen und wird besonders häufig für ML-Training genutzt.
• Apache Flink verarbeitet auch Batches, hat seinen Schwerpunkt aber auf Stream Processing.

Event Streaming und Kafka

• Stream Processing eignet sich für Aufgaben, bei denen Ergebnisse sofort benötigt werden, etwa bei der Erkennung von Kreditkartenbetrug, oder dafür, Web-Analytics-Events beim Eintreffen zu validieren, mit IP-Geoinformationen anzureichern und in ClickHouse zu schreiben
• Wenn die Verarbeitung direkt beim Eintreffen erfolgt, muss die Roh-Payload unter Umständen nicht separat bis zum nächsten Batch-Lauf aufbewahrt werden
• Apache Kafka ist eine verteilte, fehlertolerante Event-Streaming-Plattform, die Events von Produzenten entgegennimmt, speichert und für Konsumenten lesbar macht
  • Anders als bei Message Queues werden Events nicht gelöscht, wenn ein Konsument sie bestätigt; mehrere Konsumenten können sie wiederholt lesen, bis die Aufbewahrungsregeln ablaufen
  • Kafka selbst verarbeitet keine Daten; separate Worker tun dies als Konsumenten
• Kafka Connect verbindet Kafka mit externen Systemen wie Datenbanken
• Kafka Streams ist eine Java- und Scala-Bibliothek, die auf Kafka zustandsbehaftete Transformationen, Window-Aggregationen und Joins ausführt
  • Sie wird in Anwendungen eingebettet und ausgeführt und funktioniert nur mit Kafka
• Weitere Event-Streaming-Plattformen sind Apache Pulsar, Redpanda und AWS Kinesis Data Streams

Stream-Processing-Engines

• Apache Flink übernimmt Cluster-Deployment, Skalierung und Fehlerbehebung anhand definierter Event-Quellen und Verarbeitungsschritte
• Eine Pipeline kann Filtering, Field Mapping, Window-Aggregationen, Deduplizierung und die Ausgabe in andere Kafka-Topics oder Datenbanken umfassen
• Deployte Jobs enden nicht wie ein Batch, sondern verarbeiten kontinuierlich neue Events
• Weitere Optionen sind Spark Structured Streaming, Google Cloud Dataflow und Azure Stream Analytics

Job-Orchestrierung

• Wenn dbt-Transformationen, Spark-Jobs und benutzerdefinierte Skripte zunehmen, kombiniert ein Orchestrator die einzelnen Schritte zu einer Pipeline
• Definiert man die einzelnen Jobs und Abhängigkeiten als Code, meist in Python, entsteht ein gerichteter azyklischer Graph, ein DAG
• Orchestratoren verarbeiten Daten nicht selbst, sondern koordinieren etwa die Ausführung von Spark-Skripten, den Aufruf von dbt-Transformationen oder HTTP-Requests
• Als Trigger können Zeitpläne, Kafka-Events, manuelle Ausführungen in der UI, HTTP-Requests oder per Plugin erstellte Trigger genutzt werden
• Unabhängige Jobs können parallel ausgeführt werden; nur fehlgeschlagene Schritte lassen sich erneut versuchen und ab diesem Punkt fortsetzen
• Da dies für Batch Processing gedacht ist, das von Anfang bis Ende läuft, passt es nicht gut zu dauerhaft laufenden Stream-Pipelines; in solchen Fällen stützt man sich auf die Processing-Engine selbst, etwa Flink
• Repräsentative Produkte sind Apache Airflow, Dagster, Prefect und Luigi
  • Luigi ist älter und heute weniger populär

Observability und Qualitätsmonitoring

• Daten-Observability gliedert sich in den Pipeline-Zustand und die Qualität der Daten selbst
  • Pipeline-Monitoring prüft, ob Läufe stattfinden, ob sie fehlschlagen und wie lange sie dauern
  • Datenmonitoring prüft Aktualität, Anomalien beim Datenvolumen und unangekündigte Schemaänderungen
• Für Pipelines lassen sich allgemeine Observability-Tools für Anwendungen wie Prometheus, Grafana und ELK sowie die integrierten Funktionen des Orchestrators nutzen
• Datenqualitätsprüfungen können mit Great Expectations, wo erwartete Formate direkt definiert werden, sowie mit dbt tests umgesetzt werden
• Automatisierte Produkte lernen Muster normaler Daten und erkennen anschließend Anomalien; Beispiele sind Monte Carlo, Bigeye und Metaplane

Wiederholtes Laden in Pipelines

• Das letzte Ladeziel in ETL ist ein Warehouse, Lake oder Lakehouse, doch Daten werden nicht nur einmal am Ende der Pipeline gespeichert, sondern mehrfach in unterschiedlichen Formen
• Die Medallion-Architektur unterteilt den Bereinigungsgrad innerhalb desselben Speichers in drei Ebenen
  • Bronze sind Rohdaten, die unverändert aus der Quelle übernommen wurden
  • Silver sind bereinigte und standardisierte Daten nach Typkorrekturen, Deduplizierung, Zusammenführung von Quellen und Ähnlichem
  • Gold sind für bestimmte Zwecke wie Dashboards oder Reports aggregierte und modellierte Daten
• Analysten fragen meist Gold-Tabellen ab, während Engineers zur Pipeline-Fehlersuche bis zur Bronze-Ebene hinuntergehen können

Dimensionale Modellierung

• Während die Medallion-Struktur den Bereinigungsgrad von Daten beschreibt, bestimmt dimensionale Modellierung die Form der Warehouse-Tabellen
• Der durch Ralph Kimballs 《The Data Warehouse Toolkit》 populär gewordene Ansatz unterscheidet zwischen Fakten- und Dimensionstabellen
• Faktentabellen speichern pro Zeile ein Ereignis oder einen Messwert, etwa eine Bestellung, Zahlung oder Seitenansicht
  • Sie sind lang und schmal, enthalten viele Zahlen und Fremdschlüssel auf Dimensionstabellen und wachsen kontinuierlich
• Dimensionstabellen speichern den Kontext, in dem ein Ereignis stattgefunden hat, etwa Kunde, Produkt oder Datum
  • Sie sind breiter und ändern sich vergleichsweise langsam
• Wenn Dimensionstabellen eine zentrale Faktentabelle umgeben, entsteht ein Star Schema
  • Es gibt auch das stärker normalisierte Snowflake Schema, das nichts mit dem Produkt Snowflake zu tun hat
• Grain definiert, was eine Zeile repräsentiert: eine Bestellung, eine Bestellposition oder tägliche Bestellungen pro Kunde
• Ein Data Mart ist ein Teil des Warehouses für ein bestimmtes Team oder Thema, etwa Marketing oder Finanzen, und befindet sich meist in der Gold-Ebene
• Nicht alle Teams halten sich strikt daran; manche nutzen schnelle moderne Warehouses und günstigen Speicher, um zweckgebunden eine breite denormalisierte One Big Table zu erstellen

Echtzeit-OLAP für Anwendungen

• Für interne Dashboards reichen Gold-Tabellen im Warehouse aus, doch wenn viele Nutzer innerhalb von Millisekunden bedient werden sollen, können Query-Latenz und Kosten pro Abfrage ungeeignet sein
• Daten, die hohe Parallelität und schnelle Antworten erfordern, etwa nutzerseitige Analytics, internes Echtzeit-Monitoring, Leaderboards, Trending Items oder Nutzungsmessung, werden in Echtzeit-OLAP-Datenbanken verschoben
• Dazu zählen Apache Druid, Apache Pinot, ClickHouse und Apache Doris; ClickHouse ist weit verbreitet

Reverse ETL

• Reverse ETL sendet im Warehouse verarbeitete Daten zurück an operative Tools wie CRM-Systeme
• Wenn mit Stripe-Daten der Customer Lifetime Value berechnet und in HubSpot geschrieben wird, kann das Vertriebsteam hochwertige Kunden sofort erkennen
• Spezialisierte Tools verknüpfen Tabellen und Spalten mit Zielfeldern und kümmern sich um Fehler, Wiederholungen, Rate Limits, Warnungen und inkrementelle Synchronisierung
• Optionen sind Airbyte Data Activation, Fivetran Activations, Hightouch und RudderStack
  • Fivetran Activations hieß vor der Übernahme Census

Datenkataloge und semantische Schicht

• Ein Datenkatalog für Menschen enthält Informationen zu Herkunft, Eigentümern, Zugriffsrichtlinien und Auffindbarkeit von Daten und versieht Tabellen und Spalten mit geschäftlichem Kontext
  • Er hat einen anderen Zweck als ein Metastore für Query Engines
  • Unity Catalog, DataHub und OpenMetadata sind typische Beispiele
• Eine semantische Schicht speichert standardisierte Definitionen von Geschäfts-Entitäten, Beziehungen und Kennzahlen
  • Sie vereinheitlicht etwa, aus welchen Tabellen und Spalten das Kundenmodell stammt, welche Märkte zu EMEA gehören oder ob Rückerstattungen vom Umsatz ausgeschlossen werden
  • Wenn in BI-Tools oder AI Agents die richtigen Entitäten und Kennzahlen ausgewählt werden, werden sie in die nötigen Queries übersetzt oder liefern die Informationen, die zur Query-Erzeugung erforderlich sind
• Beispiele sind Lookers LookML, Cube, dbt Semantic Layer und die semantischen Funktionen von Unity Catalog

Data Lineage

• Data Lineage verfolgt, wie Daten beim Durchlaufen von Pipelines transformiert wurden
• Sie kann automatisch aus Orchestrator-DAGs, geparstem Transformations-SQL sowie Events und Metadaten gesammelt werden, die Verarbeitungsjobs ausgeben
• Auf Tabellenebene wird die Beziehung festgehalten, dass gold.orders aus silver.orders und silver.customers erzeugt wurde
• Auf Spaltenebene wird sogar nachverfolgt, dass customers.life_time_value aus orders.total und subscription_payments.amount berechnet wurde
• Das wird genutzt, um nachgelagerte Auswirkungen gelöschter Spalten zu bewerten, Root-Cause-Analysen für falsche Kennzahlen durchzuführen und Compliance beim Einsatz personenbezogener Daten sicherzustellen
• Unity Catalog, DataHub und OpenMetadata unterstützen Lineage-Visualisierung, doch die gesamte Pipeline muss über Konnektoren oder manuelle Events Tracking-Daten liefern
• Statt anbieterspezifischer Formate kann der OpenLineage-Standard genutzt werden, den mehrere Kataloge und Verarbeitungstools unterstützen

BI-Dashboards und Berichte

• Dashboards und Berichte sind die häufigsten Konsumenten von Datenpipelines und können in kleinen Unternehmen praktisch der einzige Anwendungsfall sein
• BI-Tools verbinden sich mit Warehouses, Lakehouses und Applikationsdatenbanken und ermöglichen es, ohne Code Diagramme und Dashboards zu erstellen
• Der Kern ist Self-Service: Nichttechnische Nutzer können direkt in der UI Diagramme erstellen oder Daten explorieren, ohne jedes Mal Analysten anzufragen
• Geplante Berichte können per E-Mail oder Slack verschickt werden, und bei Überschreitung von Schwellenwerten lassen sich Warnungen auslösen
• Tableau und Power BI sind in großen Unternehmen weit verbreitet und fokussieren sich auf leistungsfähige, flexible Visualisierung
• Looker ist rund um die semantische Schicht LookML aufgebaut und auf technische Organisationen zugeschnitten
• Metabase lässt sich schnell einrichten, auch selbst gehostet, und ist für nichttechnische Nutzer leicht zugänglich
• Looker Studio ist ein separates Produkt, das kein LookML nutzt und weniger Funktionen als Looker bietet; vor Kurzem wurde es wieder in Data Studio umbenannt

Operative Analysen

• Operative Analysen liefern Daten nicht für Managementberichte, sondern direkt in Anwendungen, die nichtanalytische Rollen täglich nutzen
• Beispiele sind:
  • Nutzungsaggregationen mit HubSpot synchronisieren, damit das Vertriebsteam den passenden Kunden Upsells anbieten kann
  • Aktuelle Bestellungen, Support-Tickets und Tarife mit Zendesk synchronisieren, damit das Support-Team den Kundenkontext sieht
  • Eine interne App bauen, die dem Customer-Success-Team den Stand der Produktadoption je Kunde zeigt
• Reverse ETL ist eine typische Auslieferungsmethode, aber auch interne Customer-360-Apps, die das Warehouse direkt abfragen, zählen zu operativen Analysen

Ad-hoc- und explorative Analysen sowie Notebooks

• Ad-hoc-Analysen untersuchen einmalige Fragen anhand vorhandener Daten, etwa die Gründe für sinkende Registrierungen oder Kohorten, die Rückerstattungen auslösen
• Explorative Analysen durchsuchen Daten ohne vorab festgelegte Frage, um Erkenntnisse zu finden
• Da die nächsten Operationen von den Ergebnissen abhängen und komplexer sind als einfache Filter und Aggregationen, reichen klassische Reporting-Tools dafür oft nicht aus
• Verwendet werden können Python mit pandas oder Polars, SQL-UIs von Warehouses, Spyder, RStudio und Ähnliches
• Notebooks kombinieren Zellen für Markdown, Code und SQL in einer Datei und platzieren Bilder, interaktive Charts und Tabellenausgaben neben dem Code
  • Sie eignen sich gut, um schrittweise zu explorieren und Ergebnisse zu präsentieren, während man die Ausgaben sieht
  • Jupyter, Google Colab, Deepnote und marimo sind typische Beispiele
  • Plattformen wie Databricks und Snowflake bieten ebenfalls eigene Notebooks an

Datenkonsum im Machine Learning

• ML ist ein eigenes Feld mit Feature Stores, Trainings-, Tracking- und Deployment-Tools, aber zugleich ein wichtiger Konsument von Daten
• Neben LLMs gibt es spezialisierte Modelle wie Churn Prediction, Empfehlungen, Nachfrageprognosen und Kundensegmentierung; vor dem Produktionseinsatz benötigen sie bereinigte Trainingsdaten
• Data Scientists oder ML Engineers holen Features wie die Anzahl der Bestellungen in den letzten 30 Tagen oder die seit dem letzten Login verstrichenen Tage aus dem Warehouse, um Modelle zu trainieren und bereitzustellen
• Vorhersageergebnisse fließen anschließend wieder in operative Analysen, etwa als Churn Score im CRM, oder in nutzerseitige Produktempfehlungen ein

Embedded Analytics

• Embedded Analytics stellt Analysen wie beliebte Produkte, Kundenregionen oder Suchrankings innerhalb einer Anwendung für Marketplace-Verkäufer bereit
• Wenn es nur um fünf vordefinierte Charts und begrenzte Filter geht, können Querys, UI und Chart-Bibliotheken direkt selbst implementiert werden
• Müssen Nutzer komplexe Abfragen stellen, lassen sich BI-Tools wie Metabase, Looker oder Tableau oder auf Embedding ausgerichtete Produkte wie Sisense und Luzmo verwenden
• Die Host-Anwendung übernimmt Authentifizierung und Autorisierung, während das eingebettete Tool die Query-UI und das Rendering der Charts verarbeitet

Daten selbst als Produkt verkaufen

• Daten können über den Rohstoff für Funktionen hinaus zum Produkt selbst werden
• Man kann etwa Daten aus mehreren Kryptowährungs-Blockchains sammeln, transformieren und indexieren und Analysten Zugriff darauf verkaufen, oder Google-Suchergebnisse sammeln und an SEO-Experten verkaufen
• Wer Daten und Query-Zugriff verkaufen will, braucht robuste Pipelines für zeitnahe Erfassung und leistungsfähige Abfragefunktionen

Data Governance

• Data Governance verwaltet, wer auf sensible Daten wie personenbezogene Informationen oder Gesundheitsdaten zugreifen darf, und protokolliert Zugriffe
• Dazu gehören auch Data Ownership, Datenschutzprozesse wie das Recht auf Vergessenwerden, physischer Speicherort und Aufbewahrungsfristen
• Technologien wie Rollen- und Zugriffskontrollen im Warehouse, Ownership-Informationen im Katalog und die Verfolgung von PII-Nutzung über Lineage können das unterstützen
• Es ist nicht nur ein technisches Thema, sondern stark von Menschen und Prozessen geprägt und eng mit Rechts-, Compliance- und Security-Teams verbunden
• Die gesamte Datenlandschaft lässt sich als Fluss betrachten, der Daten aus Quellen sammelt, speichert, verarbeitet und nutzbar macht; unter jeder Kategorie entstehen fortlaufend weitere Tools und detailliertere Auswahlmöglichkeiten