Daten und Analyse + Plattform und Zuverlässigkeit

Datenplattformen und Pipelines

Ihre Zahlen liegen in fünf Tools, ein paar Excel-Dateien und einem Skript auf irgendjemandes Laptop. Reports brechen, wenn sich eine Spalte ändert, und das merkt niemand bis zum nächsten Meeting. Wir bauen die Plattform, die Ihre Daten sammelt, modelliert und prüft, und wir betreiben sie mit derselben Disziplin wie die Systeme, mit denen Sie Geld verdienen.

Was wir tun

Die Daten an einen Ort bringen. Wir wählen die Quellen aus, die zählen, etwa Ihre Produktdatenbank, Billing, CRM und Werbeplattformen, und laden sie in ein Data Warehouse oder eine Postgres-Analysedatenbank. Die Rohdaten landen zuerst und bleiben verfügbar. Wo fertige Konnektoren günstiger sind als eigener Code, nutzen wir sie. Wo nicht, schreiben wir eigene Loader.

Einmal modellieren, in SQL. Transformationen liegen als SQL-Modelle in der Versionskontrolle, aufgebaut wie bei dbt: zuerst Staging, dann saubere Fachtabellen, dann die wenigen Tabellen, die Ihre Dashboards lesen. Jedes Modell hat Tests und eine kurze Beschreibung. Ändert sich eine Definition, ändert sie sich in einer Datei, und alle bekommen die neue Zahl.

Betrieb wie in der Produktion. Pipelines bekommen einen Orchestrator, Retries und ein Aktualitätsziel pro Tabelle. Datenqualitätsprüfungen erkennen Duplikate, Nullwerte und plötzliche Einbrüche bei der Zeilenzahl. Wenn etwas bricht, erreicht ein Alert jemanden, der es beheben kann, mit Runbook. Das ist dieselbe SRE-Praxis, die wir bei Systemen für Ihre Kunden anwenden, denn eine falsche Zahl in der Geschäftsführungsrunde ist auch ein Ausfall.

Die Rechnung im Rahmen halten. Bei einem Data Warehouse gibt man leicht zu viel aus. Wir schauen, welche Abfragen und Jobs am meisten kosten, setzen Partitionen und Zeitpläne, die zur tatsächlichen Nutzung passen, und geben Ihnen eine Kostenübersicht pro Quelle und pro Job.

Die Plattform an das Unternehmen anpassen. Ein Team von zehn Leuten braucht nicht den Stack einer Bank. Wir beginnen mit dem kleinsten Setup, das Ihre Fragen beantwortet, oft ein gemanagtes Postgres und ein Scheduler, und wechseln erst auf ein Cloud Data Warehouse, wenn Datenmenge oder Nutzerzahl es rechtfertigen. Alles ist als Code definiert, der nächste Schritt ist also eine Änderung und kein Neubau.

Wie es meistens abläuft

Die meisten Projekte beginnen mit dem zweiwöchigen Daten-Check-up. Wir verfolgen Ihre wichtigsten Kennzahlen von der Quelle bis zum Dashboard und finden heraus, wo sie abweichen oder verloren gehen. Daraus ergibt sich eine klare Liste, was die Plattform zuerst lösen muss.

Dann bauen wir in Iterationen von zwei Wochen, jeweils ein paar Quellen auf einmal. Dasselbe Team richtet die Infrastruktur ein und schreibt die Analysen darauf, es gibt also keine Übergabe zwischen einem Plattform-Dienstleister und einem Daten-Dienstleister. Wenn wir gehen, gehören Code, Konfiguration und Runbooks Ihrem Team.

Passt gut, wenn

  • Ihre Reports lesen direkt aus den Produktionsdatenbanken und bremsen sie aus.
  • Zwei Teams nennen zwei verschiedene Zahlen für dieselbe Sache.
  • Letzten Monat ist eine Pipeline ausgefallen, und eine Woche lang hat es niemand gemerkt.
  • Sie stellen bald die erste Person für Datenanalyse ein und wollen ihr eine saubere Arbeitsgrundlage geben.

Häufige Fragen

Brauchen wir ein Data Warehouse?
Nicht immer. Wenn Ihre Daten bequem in eine einzelne Postgres-Instanz passen und aus wenigen Quellen kommen, reicht oft ein eigenes Analyse-Schema oder eine Read Replica. Ein Cloud Data Warehouse wie BigQuery oder Snowflake lohnt sich, wenn Datenmenge, Zahl der Quellen oder gleichzeitige Nutzer über das hinauswachsen, was eine Datenbank gut bewältigt. Wir starten mit dem kleinsten Setup, das funktioniert, und lassen Platz für den nächsten Schritt.
Was ist der Unterschied zwischen ETL und ELT?
Bei ETL werden die Daten transformiert, bevor sie ins Warehouse geladen werden. Bei ELT werden zuerst die Rohdaten geladen und dann im Warehouse mit SQL transformiert. ELT ist heute die übliche Wahl: Die Rohdaten bleiben verfügbar, Transformationen sind versioniert und testbar, und Sie können ein Modell neu aufbauen, ohne zurück an die Quelle zu müssen.
Was ist dbt und brauchen wir das?
dbt ist ein Werkzeug, mit dem man Datentransformationen als SQL-Modelle schreibt, mit Tests, Dokumentation und Abhängigkeiten zwischen den Modellen. Für Teams, die SQL schon können, ist es ein guter Standard. Wenn Sie nur eine Handvoll Transformationen haben, reichen oft einfache SQL-Views mit einem Scheduler, und das sagen wir Ihnen dann auch.
Wie macht man Datenpipelines zuverlässig?
Wir behandeln sie wie Produktivsysteme. Jede Pipeline hat einen Verantwortlichen, ein Ziel für die Datenaktualität, automatische Datenqualitätstests und Alerts, die bei einer Person ankommen und nicht in einem Kanal, den niemand liest. Ausfälle bekommen ein kurzes Review und einen Fix, genau wie ein Incident in der Produktion.

Sagen Sie uns, was nicht funktioniert.

Ein paar Sätze reichen. Wir antworten innerhalb eines Werktags, und das erste Gespräch ist kostenlos.