Daten­platt­form optimieren

Datenplattformen wachsen mit jeder neuen Quelle, jedem Bericht und jedem Team. Irgendwann steigt die Rechnung, und niemand kann erklären, welche Anwendungen sie verursachen. Ladeläufe brauchen jeden Monat länger, Berichte laden langsam, und bei manchen Tabellen weiß keiner, ob sie noch gebraucht werden. Niemand hat das beschlossen. Es ist die Summe vieler Entscheidungen, die jeweils vernünftig waren.

Wir setzen auf der bestehenden Plattform auf. Zuerst messen wir, wo Verbrauch und Laufzeit entstehen, dann beseitigen wir die größten Ursachen nacheinander. Den Neuaufbau einer Plattform behandeln wir unter Cloud-Datenplattform, die Regeln für Qualität und Zugriffe unter Data Governance. Hier geht es um Kosten, Laufzeiten und Übersicht.

Erst messen, dann ändern

Am Anfang steht eine Auswertung der tatsächlichen Nutzung. Alle gängigen Plattformen liefern dafür Daten, etwa Abrechnungs- und Nutzungsansichten, Systemtabellen und Auslastungsberichte. Wir ordnen den Verbrauch nach Anwendung, Team, Umgebung und Zweck zu und fragen: Welche Jobs und Abfragen verursachen den größten Teil? Was läuft ohne erkennbaren Nutzen, nachts oder am Wochenende? Wo wächst der Verbrauch schneller als die Datenmenge?

Meist konzentriert er sich auf wenige Stellen, und die Priorisierung ergibt sich fast von selbst. Voraussetzung für die Zuordnung ist eine konsequente Kennzeichnung der Ressourcen, zum Beispiel über Tags nach Team und Projekt. Fehlt sie, richten wir sie zuerst ein.

Wer Änderungen ohne Ausgangswerte umsetzt, weiß hinterher nicht, ob sie geholfen haben. Das gilt besonders für die Größe von Ressourcen: Eine kleinere Instanz spart Geld, kann aber die Laufzeit verlängern, und eine größere ist nicht immer schneller. Beides testen wir.

Was sich an welcher Plattform drehen lässt

Die Stellschrauben unterscheiden sich je Produkt. Hier die vier, mit denen wir am häufigsten arbeiten.

Snowflake

Die Warehouse-Größe sollte zur Aufgabe passen. Laut Dokumentation helfen größere Warehouses vor allem bei komplexen Abfragen, nicht bei hoher Parallelität. Dafür eignen sich zusätzliche oder Multi-Cluster-Warehouses. Ein kurzes Auto-Suspend verhindert Leerlaufkosten, wobei die Mindestabrechnung von 60 Sekunden pro Start zu beachten ist. Resource Monitors und Budgets begrenzen den Verbrauch.

Microsoft Fabric

Die Leistung wird in Kapazitätseinheiten bemessen. Fabric glättet Lastspitzen über die Zeit und drosselt erst, wenn eine Kapazität überlastet ist. Die Capacity Metrics App zeigt, ob und wann das passiert. Je nach Befund hilft eine größere Kapazität, eine Verteilung auf mehrere Kapazitäten oder die Optimierung einzelner Modelle und Ladeläufe.

Databricks

Serverless-Compute für Notebooks, Jobs und Pipelines verkürzt Startzeiten und nimmt Betriebsaufwand ab. Ob es günstiger ist, entscheidet die Arbeitslast, deshalb testen wir mit einer repräsentativen. Verbrauchsdaten liefert die Systemtabelle für Abrechnung, Tags ordnen Kosten zu, und Compute Policies begrenzen Typ und Größe der Cluster.

Google BigQuery

Abgerechnet wird nach verarbeiteter Datenmenge oder über reservierte Kapazität (Slots) in den Editionen Standard, Enterprise und Enterprise Plus, auch mit automatischer Skalierung. Welches Modell passt, hängt vom Abfrageprofil ab.

Auf anderen Plattformen gilt dasselbe Prinzip: Kosten und Laufzeit vor der Änderung messen, danach prüfen, ob sie gewirkt hat.

Abfragen, Ladeläufe und Speicher

Teure Abfragen lassen sich oft vereinfachen. Typische Ansatzpunkte sind das Lesen nur benötigter Spalten und Zeilen, Partitionierung und Clustering, das Zwischenspeichern aufwendiger Zwischenergebnisse und der Verzicht auf unnötige Verknüpfungen. Im BI-Tool helfen Aggregationen und ein schlankes semantisches Modell.

Bei den Ladeläufen bringt inkrementelles Laden am meisten. Statt jeden Tag alles neu zu laden, werden nur neue oder geänderte Daten verarbeitet, zum Beispiel über inkrementelle dbt-Modelle oder Change Data Capture. Wir prüfen auch die Abfolge und die Startzeiten der Jobs, denn gleichzeitig laufende Jobs konkurrieren um Ressourcen.

Beim Speicher geht es um Aufbewahrung. Selten genutzte Daten können in günstigere Speicherklassen wandern. Fristen für Snapshots, Time Travel und Rohdaten sollten bewusst gesetzt sein, denn jede Kopie kostet. Löschfristen für personenbezogene Daten klären wir mit dem Datenschutz.

Was weg kann

Viele Einsparungen entstehen durch Weglassen: Tabellen, die nie abgefragt werden, Pipelines ohne Abnehmer, Berichte, die niemand öffnet, doppelte Datenkopien. Abgeschaltet wird nie auf Verdacht. Ein Bericht, den niemand zu kennen scheint, kann für den Jahresabschluss gebraucht werden. Wir fragen die Beteiligten und deaktivieren Objekte zunächst nur, statt sie zu löschen.

Dazu kommt die Struktur. Datenschichten, Namenskonventionen und Berechtigungen werden vereinheitlicht, Rechte nach Rollen statt nach Einzelpersonen vergeben, und die Konten ehemaliger Mitarbeitender verschwinden.

Damit es nicht wieder teurer wird

Eine einmalige Aktion hilft wenig. Ohne Budgets, Alarme und feste Verantwortliche steigen die Kosten bald wieder. FinOps beschreibt, wie Technik, Fachbereiche und Finanzen gemeinsam mit Cloud-Kosten umgehen. Das FinOps Framework der FinOps Foundation nennt unter anderem diese Grundsätze: Teams arbeiten zusammen, jedes übernimmt Verantwortung für seine Nutzung, Kostendaten sind zugänglich, zeitnah und korrekt, und Technikentscheidungen richten sich am Geschäftsnutzen aus. Datenplattformen führt es ausdrücklich als Anwendungsbereich auf.

Für die Praxis halten wir das bewusst schlank. Der Verbrauch wird sichtbar und zugeordnet, dann werden Maßnahmen umgesetzt, dann wird regelmäßig geprüft, ob Budgets und Erwartungen eingehalten werden. Das Framework nennt diese Phasen Informieren, Optimieren und Betreiben. Ein monatlicher Blick auf die größten Posten mit benannten Verantwortlichen bringt meist mehr als ein aufwendiges Berichtswesen. Dabei gilt: Wer den Verbrauch verursacht, sollte ihn auch sehen, sonst fehlt der Anreiz zum Sparen. Und Einsparungen, die Datenqualität oder Aktualität verschlechtern, kommen später als Mehraufwand zurück.

Wir erklären dem Team, wie sich Kosten und Laufzeiten im Alltag beobachten lassen, dokumentieren die Änderungen und schulen im Umgang mit Budgets und Alarmen.