Data FinOps: Cloud-Datenkosten im Griff

2021 feierte das Data-Team eines Fintechs aus dem Mittelstand einen Meilenstein: Die Snowflake-Rechnung hatte 3 Mio. $ pro Jahr überschritten. Nicht der Meilenstein, den sie sich *gewünscht* hatten, sondern einer, den sie entdeckten, als Finance das Thema an den Vorstand eskalierte. Die Plattform war technisch exzellent. Query-Latenz niedrig, Adoption hoch, die Analysten liebten sie. Und sie verbrauchte still und leise 40 % des gesamten Technologiebudgets, ohne dass ein Fachbereichsverantwortlicher einen einzigen Dollar davon erklären konnte. Der CDO hatte einen Ferrari gebaut und die Schlüssel jedem gegeben, der fragte, während die Tankrechnung an ein Postfach ging, das niemand las.

Das ist die Falle von Cloud-Datenplattformen. Die Elastizität, die sie stark macht, unbegrenzter Storage, Compute on demand, Self-Service-Zugang, ist dieselbe Elastizität, die Kosten unsichtbar hält, bis sie strukturell sind. Sie wissen bereits, wie man den Katalog aufbaut und Governance durchsetzt. **In dieser Lektion geht es darum, die *Rechnung* zu einem governten, zuordenbaren, optimierbaren Asset zu machen**, und zwar ohne die Plattform wieder zu dem Bottleneck zu machen, das Sie zwei Jahre lang beseitigt haben.

AttributionAttributionEin Framework, das den Touchpoints, die zu einer Conversion beigetragen haben, Credit zuweist, damit Sie messen können, welche Kanäle und Interaktionen tatsächlich Ergebnisse bringen.Vollständige Definition ansehen → ist die Voraussetzung für alles

Sie kkDie durchschnittliche Zahl neuer Nutzer, die jeder bestehende Nutzer über Empfehlungen generiert. Über 1,0 verstärkt sich das Wachstum selbst und wird exponentiell.Vollständige Definition ansehen →önnen nicht optimieren, was Sie nicht zuordnen können. Der größte einzelne Fehler im Datenkostenmanagement besteht darin, die Plattform als eine undifferenzierte Kostenstelle zu behandeln. Wenn die Rechnung eine einzige Zahl ist, bleibt nur ein grober Hebel: Ausgaben einfrieren und zusehen, wie die Adoption zusammenbricht.

Die FinOps-Disziplin, geliehen aus der Cloud-Infrastruktur, gibt Ihnen drei Betriebsphasen, Inform, Optimize, Operate, aber speziell bei einer Datenplattform liegt der ganze Hebel vorne in der Attribution. Ihre erste Aufgabe: jeden Dollar Compute und Storage nachvollziehbar machen bis zu einem Team, einem Workload und einem Business-Ergebnis.

Die Strategie aus Tagging und Warehouse-Isolation

Attribution in einem Data WarehouseData WarehouseEin zentrales Repository, das Daten aus vielen Quellsystemen in einem strukturierten, abfrageoptimierten Speicher zusammenführt, ausgelegt für Analytics, Reporting und Business Intelligence.Vollständige Definition ansehen → funktioniert auf zwei Wegen, und Sie brauchen beide.

Compute-Isolation heißt, Workloads auf getrennte virtuelle Warehouses oder Compute-Pools zu legen, damit ihre Kosten unabhängig gemessen werden. Das ist Ihr primärer Attributionsmechanismus, weil Compute meist 70 bis 85 % der Rechnung ausmacht. Ein einzelnes gemeinsames Warehouse, in dem die Dashboards des Marketings, die Abstimmungsjobs von Finance und das entlaufene Notebook eines Data Scientists konkurrieren, liefert Ihnen eine Zahl und keine Verantwortlichkeit. Trennen Sie sie.

Tagging trägt den Business-Kontext, den Isolation allein nicht liefern kann. Jedes Warehouse, jeder geplante Job, jedes materialisierte Dataset sollte Tags für Kostenstelle, Domain, Environment und Kritikalität tragen.

-- Snowflake: Tags auf Objektebene, die in die Kostensichten einfließen
ALTER WAREHOUSE mktg_analytics_wh SET TAG
  cost_center = 'MKT-204',
  data_domain = 'campaign',
  env = 'prod',
  criticality = 'tier2';

Die Disziplin liegt hier nicht in der Syntax, sondern in der *Durchsetzung*. Ungetaggte Ressourcen sind die Entropie, die jedes FinOps-Programm bis Monat vier zerstört. Machen Sie Tagging zu einem Deployment-Gate: Kein Warehouse und kein geplanter Task geht ohne die erforderlichen Tags in Produktion, durchgesetzt in CI, nicht in einem Policy-PDF. Hier zahlt sich Ihr bestehender Governance-Muskel aus, Sie kontrollieren die Deployment-PipelinePipelineAlle aktiven Verkaufschancen über die Phasen des Vertriebsprozesses hinweg, zusammen mit ihrem gesamten potenziellen Wert und ihrer Abschlusswahrscheinlichkeit.Vollständige Definition ansehen → bereits; erweitern Sie dieselbe Policy-Engine auf Kosten-Tags.

Showback vor Chargeback

Sobald Kosten zugeordnet sind, stehen Sie vor einer politischen Entscheidung: Showback (den Teams sagen, was sie kosten) oder Chargeback (es ihrer P&L belasten). Springen Sie nicht direkt zu Chargeback. Chargeback ohne eine ausgereifte Showback-Phase erzeugt Gaming, Teams verlagern Workloads, um der Zuordnung zu entgehen, oder horten Kapazität, um sie zu sichern. Fahren Sie Showback mindestens zwei Quartale. Veröffentlichen Sie einen monatlichen Kostenbericht pro Domain, der die Owner benennt. Allein die Sichtbarkeit senkt die Ausgaben typischerweise um 15 bis 20 %, weil die meiste Verschwendung nicht böswillig ist, sondern daraus entsteht, dass niemand hingeschaut hat. Gehen Sie erst dann zu Chargeback, wenn den Zahlen vertraut wird und die Unit Economics stabil sind.

Die wichtigste Metrik ist hier nicht die Gesamtausgabe, sondern die Unit Cost: Kosten pro Query, Kosten pro Pipeline-Lauf, Kosten pro aktivem Nutzer, Kosten pro Dashboard-Aufruf. Steigende Gesamtausgaben bei fallenden Unit Costs sind eine *gesunde* Plattform, die mit dem Geschäft skaliert. Flache Gesamtausgaben bei steigenden Unit Costs sind eine Plattform, die von innen verrottet. Berichten Sie Ihrer Führungsebene Unit Economics, nicht Bruttobeträge, sonst verlieren Sie das Narrativ an ein Finance-Team, das nur die steigende Rechnung sieht.

Compute: hier verbrennt das Geld wirklich

Mit Attribution im Rücken ist Compute der Ort, an dem Sie die schnellsten und größten Einsparungen finden. Drei Hebel, nach Wirkung sortiert.

Query-Optimierung ist ein Governance-Problem im technischen Gewand

Die schlimmsten Verursacher auf jeder Plattform folgen einem Power Law: Eine Handvoll Queries verbraucht einen überproportionalen Anteil des Compute. Das klassische Muster ist das SELECT * auf einer Tabelle im Multi-Terabyte-Bereich, das ein BIBITechnologien und Prozesse, die Rohdaten über Reporting, Dashboards und Analysen in verwertbare Insights überführen, damit Teams auf Basis von Fakten statt Intuition entscheiden.Vollständige Definition ansehen →-Tool alle fünfzehn Minuten neu ausführt, weil jemand Auto-Refresh angelassen hat. Oder ein unpartitionierter Scan, der die komplette Historie einer Tabelle liest, um eine Frage zur letzten Woche zu beantworten.

Ihre Query-Engine loggt das bereits. Snowflakes QUERY_HISTORY, BigQuerys INFORMATION_SCHEMA.JOBS, die System-Tabellen von Databricks, jedes zeigt gescannte Bytes und verbrauchtes Compute pro Query. Der Schritt ist, einen wiederkehrenden Report der teuersten Queries aufzubauen und ihn an die verantwortliche Domain zu schicken, nicht an Ihr zentrales Team. Die Behebung zu zentralisieren schafft das Bottleneck neu; die Domain, die die Query geschrieben hat, besitzt die Behebung, und Ihr Plattformteam besitzt die Sichtbarkeit der Kosten und die Bereitstellung der Pattern-Bibliothek.

Die technischen Muster mit der größten Wirkung, die Sie durchsetzen sollten:

• Partition- und Cluster-Pruning: Stellen Sie sicher, dass Tabellen nach den Spalten partitioniert sind, nach denen Queries tatsächlich filtern. Eine gut geclusterte Tabelle kann die gescannten Bytes um eine Größenordnung senken.
• Materialisierungsdisziplin: Dasselbe Aggregat hunderte Male pro Tag neu zu berechnen ist eine Steuer. Materialisieren Sie es einmal. Aber achten Sie auf den Umkehrfall, Materialized Views, die permanent für Daten aktualisieren, die niemand liest, sind reine Verschwendung.
• Result Caching: Identische Queries sollten den Cache treffen, nicht neu rechnen. Oft ist das eine Konfiguration, die Teams deaktiviert haben, ohne die Kosten zu bemerken.

Right-Sizing und Auto-Suspend

Ungenutztes Compute ist die peinlichste Zeile auf einer Datenrechnung, weil sie buchstäblich nichts kauft. Ein Warehouse, das „für Responsiveness“ warm gehalten wird, während es 80 % des Tages idle ist, ist ein Heizstrahler. Setzen Sie ein aggressives Auto-Suspend, 60 Sekunden sind für die meisten interaktiven Warehouses vertretbar. Der Trade-off ist Cold-Start-Latenz gegen Idle-Kosten; messen Sie ihn, statt aus Angst auf always-on zu setzen.

Right-Sizing ist das schwierigere Urteil. Größere Warehouses laufen schneller, kosten aber proportional mehr; die Frage ist, ob die *Gesamt*kosten (Größe × Laufzeit) sinken. Häufig beendet ein größeres Warehouse eine schwere Transformation so viel schneller, dass es insgesamt günstiger ist, das ist kontraintuitiv und lohnt die Messung pro Workload. Nehmen Sie nicht an, dass kleiner günstiger ist.

Commitment-Einkauf

Sobald Ihr Basisverbrauch vorhersehbar ist, und Attribution ist das, was ihn vorhersehbar macht, verhandeln Sie Committed-Use-Rabatte. Reservierte Kapazität und Committed-Spend-Verträge bringen regelmäßig 20 bis 40 % Abschlag auf On-demand-Raten. Das Risiko ist, sich auf Kapazität festzulegen, die Sie nicht nutzen. Die Regel: Committen Sie auf Ihren *Floor*, den Verbrauch, bei dem Sie sicher sind, und lassen Sie die Peaks über On-demand flexen. Committen Sie niemals auf Ihren Peak.

Storage: das langsame Leck

Storage ist meist ein kleinerer Teil der Rechnung als Compute, aber es ist das Leck, das still wächst und sich aufsummiert. Die zentrale Disziplin ist Tiering: die Storage-Kosten von Daten an ihre Zugriffshäufigkeit und ihren Wert anzupassen.

Das Tiering-Framework

Denken Sie in drei Tiers, definiert über das Zugriffsmuster, nicht allein über das Alter:

• Hot: häufig abgefragt, latenzsensibel, im nativen performanten Storage des Warehouse. Teuer pro Terabyte, aber der Zugriff rechtfertigt es.
• Warm: gelegentlich abgefragt, toleriert etwas höhere Latenz. Kandidat für günstigeren Object Storage, abgefragt über External Tables.
• Cold: aufbewahrt für Compliance oder seltene Audits, praktisch nie abgefragt. Gehört in Archiv-Tiers (S3 Glacier oder Äquivalent) zu einem Bruchteil der Kosten.

Der Fehler ist Tiering nach Alter. „Alles älter als 90 Tage wird cold“ scheitert, wenn ein Machine-Learning-Team drei Jahre Historie für das Training braucht. Tiern Sie nach *tatsächlichem Zugriff*, den Ihre Query-Logs Ihnen schon verraten. Eine Tabelle, die 90 Tage nicht gescannt wurde, ist ein Tiering-Kandidat, unabhängig von ihrem Alter; eine zwei Jahre alte Tabelle, die täglich abgefragt wird, bleibt hot.

Die drei Storage-Killer

Drei Muster machen den größten Teil der Storage-Verschwendung aus, und keines davon sind die Daten, die Ihr Geschäft tatsächlich nutzt:

1. Time-Travel- und Failsafe-Retention zu lang gesetzt. Diese Features erlauben es, gelöschte oder geänderte Daten wiederherzustellen, und sie sind wunderbar, bis Sie dafür zahlen, 90 Tage Änderungshistorie auf Tabellen zu halten, die jede Nacht komplett neu aufgebaut werden. Setzen Sie Retention nach Kritikalität der Tabelle, nicht als einen globalen Default.
2. Verwaiste Datasets. Das Ergebnis eines Experiments, das vor achtzehn Monaten endete, die „temp“-Tabelle, die jemand 2022 angelegt hat, die vollständige Kopie der Produktion, die ein Data Scientist „zur Sicherheit“ gezogen hat. Ihr Katalog kann diese finden, gleichen Sie das Asset-Inventar gegen Zugriffslogs ab und markieren Sie Datasets mit null Reads und ohne Downstream-Lineage.
3. Nicht kompaktierte kleine Dateien. In Data-Lake-Architekturen erzeugen Streaming- und Micro-Batch-Schreibvorgänge tausende winzige Dateien, die Storage- und Query-Kosten aufblähen. Geplante Compaction ist unglamourös und unverzichtbar.

Hier wird Lineage, das Thema dieses Moduls, zu einem *Kosten*instrument und nicht nur zu einem Governance-Instrument. Ein Dataset ohne Downstream-Lineage und ohne Reads ist ein Löschkandidat. Lineage sagt Ihnen, was bricht, wenn Sie etwas archivieren; ohne sie horten Teams alles, weil Löschen sich gefährlich anfühlt. Der Katalog, den Sie für Vertrauen gebaut haben, ist auch die Landkarte für sichere Kostensenkung.

Die Disziplin betreiben: damit es hält

Eine Kostenbereinigung ist ein Projekt. Data FinOps ist ein Operating Model. Der Unterschied zwischen beidem zeigt sich daran, ob die Einsparungen das Wachstum des nächsten Quartals überleben. Die meisten Kosteninitiativen liefern eine spektakuläre Einmalreduktion, und dann klettert die Rechnung direkt wieder hoch, weil sich Incentives und Rituale nie geändert haben.

Der cross-funktionale Arbeitsrhythmus

FinOps funktioniert nur als geteilte Verantwortung zwischen dem Plattformteam des CDO, Finance und den konsumierenden Domains. Etablieren Sie eine leichtgewichtige FinOps-Arbeitsgruppe mit monatlicher Kadenz. Das Plattformteam bringt die zugeordneten Kosten und die Unit Economics. Finance bringt Budgetkontext und Forecast. Die Domains besitzen ihren Verbrauch und ihr Optimierungs-Backlog. Ihre Rolle als CDO ist, die Trade-offs zu moderieren, nicht jede Query zu überwachen, was Sie wieder zum Bottleneck machen würde, sondern zu entscheiden, wenn das Kostenwachstum einer Domain ihren Wertbeitrag überholt.

Das zentrale Artefakt ist eine Budget-gegen-Ist-Sicht pro Domain mit Anomalie-Alerting. Eine Domain, deren Ausgaben Woche über Woche um das Dreifache springen, sollte automatisch einen Alert an *den Owner dieser Domain* auslösen, bevor Finance es überhaupt bemerkt. Auf die Monatsrechnung zu warten, um eine entlaufene Pipeline zu entdecken, ist der Weg zur 3-Mio.-$-Überraschung.

GuardrailsGuardrailsRegeln und Kontrollen, die ein KI-System in sicheren, rechtskonformen und markengerechten Grenzen halten und unerwünschte Ausgaben blockieren.Vollständige Definition ansehen →, keine Gates

Der Reflex nach einem Kostenschock ist, alles zuzusperren, Freigabe-Workflows für jedes neue Warehouse, Quoten, die Arbeit blockieren. Das zerstört die Self-Service-Kultur, die Sie aufgebaut haben, und treibt Teams in Shadow-Infrastruktur. Bevorzugen Sie Guardrails: automatisierte Limits, die Katastrophen verhindern und Autonomie erlauben.

Konkret: Setzen Sie Resource Monitors, die ein Warehouse suspendieren, wenn es eine Credit-Schwelle überschreitet, damit ein entlaufener Job abgeriegelt wird statt das ganze Wochenende zu laufen. Setzen Sie Timeout-Limits pro Query. Setzen Sie Default-Warehouse-Größen, die Teams mit Begründung überschreiben können, statt für jedes Provisioning eine Freigabe zu verlangen. Die Philosophie: Machen Sie den sicheren Pfad zum Default und den teuren Pfad sichtbar, aber lassen Sie niemanden um Erlaubnis bitten, seinen Job zu machen.

Effizienz an das Wertnarrativ binden

Die Falle, die Sie vermeiden müssen: FinOps zu einer reinen Kostensenkungsübung werden zu lassen. Die Aufgabe einer Datenplattform ist, Wert zu erzeugen, und es gibt Workloads, die ihre hohen Kosten wert sind. Ein Fraud-Detection-Modell, das teure Echtzeit-Inferenz fährt und Millionen an Verlusten verhindert, ist kein Optimierungskandidat, es ist ein *Investitions*kandidat. Der Unit-Economics-Rahmen schützt Sie hier: Wenn Sie Kosten gegen den Wert berichten, den jede Domain erzeugt, können Sie die teuren Workloads verteidigen, die sich rechnen, und die günstigen streichen, die nichts liefern. Das ist das Gespräch, das Sie am Strategietisch hält statt am Budgetverteidigungstisch.

Wichtigste Erkenntnisse

• Attribution ist das ganze Spiel. Isolieren Sie Compute nach Workload und setzen Sie Kosten-Tags als Deployment-Gate durch. Ungetaggte Ressourcen sind die Entropie, die jedes FinOps-Programm tötet, machen Sie „ungetaggt“ zur Ausnahme, die in CI fehlschlägt, nicht zur Norm.
• Berichten Sie Unit Economics, nicht Bruttoausgaben. Kosten pro Query, pro Nutzer und pro Ergebnis sagen Ihnen, ob die Plattform gesund skaliert oder verrottet. Steigende Gesamtausgaben bei fallenden Unit Costs sind ein Erfolg; verteidigen Sie dieses Narrativ vor Ihrem Board.
• Erst Compute angehen, dann Storage. Das Power Law der teuren Queries und die idlen Warehouses sind das schnelle Geld. Schicken Sie den Report der teuren Queries an die verantwortliche Domain, Sie liefern Sichtbarkeit, sie besitzt die Behebung.
• Tiern Sie Storage nach Zugriff, nicht nach Alter, und nutzen Sie Ihren Lineage-Graph, um verwaiste Datasets mit null Reads als sichere Löschkandidaten zu identifizieren. Der Katalog, den Sie für Vertrauen gebaut haben, ist auch Ihre Landkarte für sichere Kostensenkung.
• Bauen Sie Guardrails, keine Gates. Resource Monitors, Query-Timeouts und Anomalie-Alerts an Domain-Owner erhalten Self-Service und begrenzen den Schaden. Ein monatlicher cross-funktionaler Rhythmus macht aus einer Einmalbereinigung ein dauerhaftes Operating Model.