Analytics und Datenplattformen

Jedes System erzeugt Daten, die über das Tagesgeschäft hinaus wertvoll sind: Welche Kurse werden abgebrochen und an welcher Stelle? Welche Produkte werden zusammen gekauft? Wie entwickelt sich der Umsatz je Region? Solche Fragen lassen sich nicht sinnvoll auf der Datenbank beantworten, die gleichzeitig Buchungen und Bestellungen verarbeitet. Analysen brauchen andere Datenstrukturen, andere Werkzeuge und oft Daten aus vielen Quellen zugleich. Datenplattformen schaffen dafür eine eigene Welt neben den operativen Systemen. Diese Lektion zeigt, wie sie aufgebaut sind und worauf man achten muss, damit am Ende Zahlen stehen, denen alle vertrauen.

1. Zwei Arten von Arbeit

Beide Arten von Arbeit stellen gegensätzliche Anforderungen. Sehen Sie selbst, welche Daten jeweils gelesen werden:

Wer schwere Analysen auf der Produktionsdatenbank laufen lässt, riskiert, dass das Tagesgeschäft langsam wird, weil Berichte Speicher, Prozessor und Sperren beanspruchen. Die erste Ausbaustufe ist deshalb oft ein Lesereplikat nur für Berichte. Bei wachsenden Datenmengen und mehreren Quellen folgt ein eigenes Analysesystem mit spaltenorientierter Speicherung, etwa ClickHouse, BigQuery, Snowflake oder DuckDB für kleinere Datenmengen.

2. Der Weg der Daten

Daten durchlaufen auf dem Weg zum Dashboard mehrere Stationen. Klicken Sie sich durch:

Früher wurden Daten vor dem Laden umgewandelt (ETL). Heute lädt man sie meist zuerst roh und wandelt sie im Analysesystem um (ELT), weil Speicher günstig ist und moderne Analysesysteme die Umwandlung schnell erledigen. Das hat einen großen Vorteil: Ändert sich eine Definition, lassen sich alle Ergebnisse aus den Rohdaten neu berechnen.

3. Warehouse, Lake, Lakehouse

Drei Begriffe prägen die Diskussion. Ein Data Warehouse speichert strukturierte, bereinigte Daten in Tabellen und ist für SQL-Analysen optimiert. Ein Data Lake speichert Daten aller Art – Tabellen, Logs, Bilder, Texte – günstig im Objektspeicher, oft in offenen Formaten wie Parquet. Ein Lakehouse verbindet beides: Daten liegen in offenen Formaten im Objektspeicher, und Tabellenformate wie Apache Iceberg ergänzen Transaktionen und Schemas, sodass sie wie in einem Warehouse abgefragt werden können. Für ein mittelständisches Unternehmen ist die Wahl weniger wichtig als die Disziplin: Eine gut gepflegte Postgres-Datenbank für Analysen oder ein verwaltetes Warehouse mit sauberen Modellen schlägt jeden ungepflegten Data Lake.

4. Ereignisse erfassen

Viele wertvolle Fragen lassen sich nicht aus dem Zustand der Datenbank beantworten, sondern nur aus dem Verhalten: In welchem Schritt brechen Nutzer die Registrierung ab? Wie viele kehren nach einer Woche zurück? Dafür werden Ereignisse erfasst – „Kurs geöffnet“, „Quiz bestanden“, „Warenkorb verlassen“ – mit Zeitpunkt, pseudonymer Nutzerkennung und wenigen, festgelegten Eigenschaften. Wichtig ist ein gepflegter Plan, welche Ereignisse es gibt und wie sie heißen. Sonst entstehen über die Jahre Hunderte ähnlicher Ereignisse, die niemand mehr versteht. Im Web ist dabei die Einwilligung zu beachten: Verhaltensdaten, die über das technisch Notwendige hinausgehen, dürfen nur mit Zustimmung erhoben werden, und manche Nutzer lehnen ab. Die Zahlen sind dann Stichproben, keine Vollerhebungen.

5. Vertrauen in Zahlen

Die größte Gefahr einer Datenplattform ist nicht technischer Natur, sondern ein Vertrauensproblem: Wenn Marketing und Vertrieb unterschiedliche Umsatzzahlen präsentieren, glaubt niemand mehr irgendeiner Zahl. Üben Sie, typische Probleme zu erkennen:

Gegen solche Probleme helfen zentral definierte Kennzahlen, automatische Tests der Datenmodelle – etwa „jede Buchung hat genau einen Kunden“ oder „der Umsatz ist nie negativ“ –, eine Überwachung der Aktualität und eine klare Verantwortung je Datenbereich. Datenschutz gehört von Anfang an dazu: Direkte Personenbezüge werden vor der Analyse entfernt oder pseudonymisiert, Zugriffe auf Rohdaten eng begrenzt, Löschungen aus den operativen Systemen auch in der Analyse berücksichtigt.

6. Ein Beispiel

Ein Café mit angeschlossener Rösterei verkauft vor Ort, im Onlineshop und über ein Abo-Modell. Bisher zieht der Inhaber jeden Monat Exporte aus Kassensystem, Shop und Zahlungsanbieter in eine Tabellenkalkulation – mühsam und fehleranfällig. Der Entwurf für eine schlanke Datenplattform sieht vor: Alle drei Quellen werden nachts in eine eigene Postgres-Datenbank für Analysen geladen, zunächst unverändert. Versionierte SQL-Modelle bereinigen die Daten, führen Kunden über die pseudonymisierte E-Mail-Adresse zusammen und berechnen Kennzahlen wie Umsatz je Kanal, Abo-Kündigungsquote und meistverkaufte Sorten. Automatische Tests prüfen jede Nacht, ob die Summen mit den Auszahlungen des Zahlungsanbieters übereinstimmen. Ein einfaches Dashboard zeigt die Zahlen. Die Kosten liegen bei wenigen Euro im Monat, und zum ersten Mal kann der Inhaber sehen, dass Abo-Kunden, die im ersten Monat eine zweite Sorte probieren, deutlich seltener kündigen – eine Erkenntnis, die direkt in eine neue Probierbox mündet.

Damit schließt das Modul Moderne Anwendungsmuster. Echtzeit, Offline-Fähigkeit, globale Verteilung und Datenplattformen sind Bausteine, die viele Systeme irgendwann brauchen – aber selten alle auf einmal. Das letzte Modul fügt alles zusammen: In Fallstudien entwerfen Sie vollständige Systeme Schritt für Schritt.

7. Klein anfangen

Datenplattformen haben den Ruf, groß und teuer zu sein. Das muss nicht so sein. Viele Unternehmen brauchen am Anfang nur drei Dinge: eine Kopie der wichtigsten Daten an einem Ort, an dem Analysen niemanden stören, eine Handvoll gut definierter Kennzahlen und einen regelmäßigen Blick darauf. Werkzeuge wie DuckDB oder eine zweite Postgres-Datenbank reichen für Millionen von Zeilen, und versionierte SQL-Modelle lassen sich später ohne Umbau in ein größeres Warehouse übernehmen. Wichtiger als die Technik ist die Frage, welche Entscheidungen die Zahlen unterstützen sollen. Eine Kennzahl, die niemand für eine Entscheidung nutzt, ist Aufwand ohne Nutzen.

Zunehmend kommen KI-Werkzeuge hinzu, die Fragen in natürlicher Sprache in Abfragen übersetzen. Sie funktionieren umso besser, je sauberer die Datenmodelle und je klarer die Kennzahlen definiert sind – eine gepflegte semantische Schicht ist deshalb auch die beste Vorbereitung auf solche Assistenten.

Stand: September 2026. Kursmaterial der Klarwerk Akademie. Zahlen zu Latenzen und Kosten sind Größenordnungen zur Orientierung, keine Messwerte.