Strategien für kosteneffizientes Datenmanagement

Die Kosten des Datenmanagements wachsen still. Ein paar typische Beispiele: Eine Staging-Tabelle, die niemand nutzt, kostet trotzdem 200 US-Dollar pro Monat. Ein Spark-Cluster, ausgelegt auf die Spitzenlast, steht einen Großteil der Zeit im Leerlauf. Ein Problem mit der Datenqualität in einer vorgelagerten Quelle löst 15 erneute Läufe von Strecken pro Woche aus. Kosteneffizientes Datenmanagement heißt nicht, weniger für Daten auszugeben; es heißt, die Verschwendung zu stoppen, die sich ansammelt, wenn niemand verfolgt, welche Daten es gibt, wer sie nutzt und ob sie noch zählen.

Dieser Artikel ist das praktische Drehbuch. Während die Kostenanalyse erklärt, wie man Kosten zerlegt und versteht, und die Kosteneffizienz darauf zielt, den Wert je ausgegebenem Euro zu erhöhen, behandelt dieser Leitfaden die konkreten Schritte, die eine Leitung im Data Engineering noch in diesem Quartal umsetzen kann: Speicherklassen, richtig bemessene Rechenleistung, das Zusammenlegen von Strecken und Entscheidungen zwischen Eigenbau und Zukauf.

Wohin das Budget für Daten wirklich geht

Bevor Sie irgendetwas verbessern, verstehen Sie, wohin das Geld geht. Budgets für Daten in der Cloud folgen einem absehbaren Muster, auch wenn die Einzelheiten je nach Größe und Architektur der Organisation schwanken.

Rechenleistung ist meist der größte Posten, und eine Handvoll schwerer Lasten beherrscht ihn. Der Rest sind leichte Transformationen, die auf der Rechnung kaum auffallen.

Speicher ist kleiner, wächst aber am schnellsten. Er wirkt je GB billig (0,023 US-Dollar/GB/Monat für S3 Standard, US East, erste 50 TB), also löscht niemand etwas. Über einige Jahre sammeln Organisationen große Datenmengen an, die seit ihrer Aufnahme niemand abgefragt hat.

Datenbewegung und Abfluss sind noch kleiner und werden leicht übersehen. Replikation über Regionen hinweg, API-Aufrufe zwischen Diensten und BI-Werkzeuge, die Daten über Verfügbarkeitszonen ziehen, erzeugen Übertragungskosten, die in keinem Architekturdiagramm auftauchen.

Menschen und Werkzeuge machen den Rest aus. Lizenzkosten sind sichtbar; die Zeit, die Fachleute mit dem Umgehen von Grenzen der Werkzeuge verbringen, ist es nicht.

Speicher verbessern

Der bessere Umgang mit Speicher beginnt mit einer einfachen Frage: Wann wurden diese Daten zuletzt gelesen? Die Antwort bestimmt, in welche Klasse sie gehören.

Heißer Speicher (S3 Standard, aktiver Speicher in BigQuery) kostet etwa 20 bis 23 US-Dollar pro TB und Monat (Preise für S3, Preise für BigQuery) und bietet sofortigen Zugriff. Halten Sie dort nur Daten, die Dashboards und Strecken aktiv abfragen, üblicherweise die letzten 90 Tage an Bewegungsdaten.

Warmer Speicher (S3 Standard-Infrequent Access, Langzeitspeicher in BigQuery) liegt bei etwa 10 bis 16 US-Dollar pro TB und Monat: S3 Standard-IA kostet 12,50 US-Dollar pro TB, der Langzeitspeicher in BigQuery in der US-Multi-Region (logischer Speicher) etwa die Hälfte des aktiven Speichers und anderswo 30 bis 50 % weniger. Der Zugriff bleibt sofort möglich, doch S3 Standard-IA berechnet je gelesenem GB eine Abrufgebühr. Daten, die gelegentlich für freie Auswertungen oder regulatorische Abfragen gebraucht werden, gehören hierher. Wie Daten dorthin gelangen, hängt vom Mechanismus ab: Regeln für den S3-Lebenszyklus verschieben Objekte nach ihrem Alter, S3 Intelligent-Tiering verschiebt sie nach dem Zugriff (nach 30 Tagen ohne Zugriff in Infrequent Access, nach 90 in Archive Instant Access), und BigQuery stellt eine Tabelle oder Partition nach 90 Tagen ohne Änderung selbsttätig auf den Preis für Langzeitspeicher um.

Kalter Speicher (S3 Glacier Deep Archive und ähnliche Klassen für die Archivierung) kostet etwa 1 US-Dollar pro TB und Monat. Archive für die Compliance, historische Sicherungen und rohe Quelldaten, die für eine erneute Verarbeitung gebraucht werden könnten, liegen hier. Der Preis dafür ist die Zeit bis zum Abruf, Stunden statt Sekunden.

Der Haken: Sie müssen wissen, welche Daten aktiv sind und welche totes Gewicht. Ein Datenkatalog mit Metadaten zu Verantwortlichen und Lineage gibt, zusammen mit den Zugriffsprotokollen der Plattform, Entscheidungen über Speicherklassen eine verlässliche Grundlage. Ohne ihn halten Teams alles „für alle Fälle“ im heißen Speicher und zahlen je TB mehr als das 20-Fache dessen, was Klassen für die Archivierung kosten, für Daten, die niemand liest.

Bessere Formate bringen sofortige Ersparnis ohne jede Änderung an der Infrastruktur. CSV-Dateien nach Parquet oder ORC zu wandeln macht sie oft um ein Mehrfaches kleiner, je nach Daten, und beschleunigt Abfragen, weil spaltenweise Formate beim Lesen unbeteiligte Spalten überspringen. Als Beispiel: Aus einem Datenbestand von 10 TB in CSV könnten 1 bis 2 TB in Parquet werden. Bei 23 US-Dollar pro TB und Monat sind das 184 bis 207 US-Dollar Ersparnis im Monat, für einen einzigen Datenbestand.

Rechenleistung richtig bemessen

Rechenleistung ist der größte einzelne Kostenblock und zugleich der am stärksten überdimensionierte. Die meisten Cluster sind auf die Spitzenlast ausgelegt und stehen den Rest der Zeit still.

Selbsttätiges Skalieren ersetzt feste Cluster durch elastische Kapazität. Statt 20 Knoten rund um die Uhr für eine Last zu betreiben, die zwei Stunden am Tag 20 Knoten braucht, laufen beim selbsttätigen Skalieren in ruhigen Zeiten 2 Knoten, und es geht auf 20 hoch, wenn die Nachfrage anzieht. Das sind 84 statt 480 Knotenstunden am Tag, in diesem Beispiel etwa 80 % weniger Knotenstunden.

Spot- und unterbrechbare Instanzen passen zur Stapelverarbeitung: Spot-Kapazität kostet bis zu 90 % weniger als On-Demand (AWS, Google Cloud). Ein nächtlicher Stapellauf, der die Daten von gestern verarbeitet, braucht keine zugesicherte Verfügbarkeit. Wird die Spot-Instanz zurückgeholt, startet der Lauf neu, in einem anschaulichen Fall also 20 Minuten Verzögerung gegen 60 % weniger Kosten.

Bessere Abfragen sind die billigste Form der Ersparnis bei der Rechenleistung. Eine einzige neu geschriebene SQL-Abfrage, mit passenden Filtern, mit konkreten Spalten statt SELECT * oder mit einem Join statt einer korrelierten Unterabfrage, kann den Verbrauch an Rechenleistung um das 10-Fache senken. In einem angenommenen Fall senkt ein Logistikunternehmen seine Ausgaben für Databricks um 4.200 US-Dollar pro Monat, indem es die fünf teuersten Abfragen neu schreibt, die eine Überwachung der Kosten zutage gefördert hatte.

Serverlos für schwankende Lasten beseitigt untätige Rechenleistung ganz. Dienste wie AWS Lambda oder BigQuery auf Abruf rechnen je Aufruf und Laufzeit (Lambda) oder je gelesener Datenmenge (BigQuery auf Abruf) ab. Für vereinzelte Lasten, etwa eine API, die 200-mal am Tag je 3 Sekunden läuft, kostet serverlos Pfennige gegenüber einer eigenen Instanz.

Strecken wirtschaftlich machen

Drei Teams, die unabhängig voneinander dieselbe Dimensionstabelle für Kunden bauen, sind kein technisches Problem; das ist ein Problem der Governance mit unmittelbarer Wirkung auf die Kosten. Doppelte Strecken vergeuden Rechenleistung, Speicher und Entwicklungszeit.

Legen Sie doppelte Transformationen zusammen. Nehmen wir ein angenommenes Handelsunternehmen, bei dem eine Prüfung der Data Observability drei Abteilungen findet, die eigene ETL-Läufe mit nahezu gleichen Aggregationstabellen für Kunden pflegen. Sie in einer einzigen geregelten Strecke zusammenzulegen könnte 2.400 US-Dollar pro Monat an Rechenleistung sparen und 15 Entwicklungsstunden pro Woche freisetzen.

Wechseln Sie von vollständigen Neuaufbauten zu schrittweiser Verarbeitung. Viele Strecken bauen nachts ganze Tabellen neu auf, obwohl sich nur 0,1 % der Zeilen geändert haben. Schrittweise Verarbeitung (über Change Data Capture oder Wasserzeichenspalten) verarbeitet nur neue oder geänderte Datensätze. Bei einer Tabelle von 500 GB mit 50.000 Änderungen pro Tag kann die Verarbeitung von 45 Minuten auf unter 2 Minuten sinken.

Nutzen Sie materialisierte Sichten für teure Aggregationen. Ein Dashboard, das bei jeder Aktualisierung einen Join über 12 Tabellen ausführt, kostet jedes Mal dieselbe Rechenleistung. Eine materialisierte Sicht führt den Join einmal aus, legt das Ergebnis ab und aktualisiert es nach Plan. Wird das Dashboard 50-mal am Tag geöffnet und die Sicht einmal am Tag aktualisiert, sinkt die Rechenleistung um 98 %.

Führen Sie Data Contracts ein. Änderungen am Schema weiter oben, die nachgelagerte Strecken brechen, verursachen erneute Läufe, Ausfälle und Handarbeit, und all das kostet Geld. Ein Data Contract legt fest, welches Schema, welche Aktualität und welche Qualität ein Datenbestand haben soll. Wird er verletzt, hält die Strecke sauber an, statt teuer zu scheitern.

Eigenbau oder Zukauf

Der Reflex „bauen wir selbst“ ist teuer, wenn die Kapazität in der Entwicklung der Engpass ist. Der Reflex „kaufen wir alles“ ist teuer im großen Maßstab. Die richtige Antwort hängt vom Zusammenhang ab.

Open Source spart Geld, wenn das Team starke Kapazität in der Entwicklung hat, übliche Muster nutzt und Aktualisierungen und Sicherheitspatches selbst stemmen kann. Apache Airflow für die Orchestrierung und dbt Core für Transformationen kosten keine Lizenz. Sie kosten viel Entwicklungszeit, wenn das Team klein oder der Anwendungsfall ungewöhnlich ist.

SaaS ist billiger, wenn das Team klein ist, die Datenmenge überschaubar und die Time-to-Value zählt. Ein verwaltetes Werkzeug für ETL zu 500 US-Dollar pro Monat ersetzt zwei Wochen Arbeit an Strecken. Bei Vollkosten von 180.000 US-Dollar für eine Fachkraft sind diese zwei Wochen 6.900 US-Dollar wert. Das Werkzeug zahlt sich im ersten Monat aus.

Verwaltete Dienste treffen den Punkt bei großen Datenmengen und geringer Kapazität. Snowflake und BigQuery übernehmen Skalieren, Flicken und Verbessern von selbst. Die Kosten je Einheit liegen höher als bei selbst betriebenen Alternativen, doch die Gesamtkosten fallen niedriger aus, wenn man das Betriebsteam einrechnet, das man nicht einstellen muss.

Die Gefahrenzone sind große Datenmengen bei großer Kapazität in der Entwicklung. Das Team könnte es bauen, also will es das auch. Aber „könnte“ heißt nicht „sollte“. Bevor Sie sich für den Eigenbau entscheiden, rechnen Sie die Gesamtkosten über drei Jahre aus, einschließlich Pflege, Aktualisierungen, Rufbereitschaft und der entgangenen Arbeit an Data Products. Lizenzgebühren sind meist der kleinere Teil der Gesamtkosten; Einführung, Anbindung und Pflege kommen erheblich hinzu.

Die Dividende der Governance

Die größte Kostensenkung kommt daraus, zu wissen, was man hat. Jede handfeste Verbesserung oben hängt an Metadaten.

Ein Datenkatalog beseitigt doppelte Datenbestände. Ohne ihn bauen drei Teams unabhängig voneinander Kundentabellen, weil sie die Arbeit der anderen nicht finden. Der Katalog macht vorhandene Bestände auffindbar und verhindert das Problem der doppelten Strecke aus dem Beispiel oben mit 2.400 US-Dollar pro Monat.

Ein Business Glossary verhindert, dass Teams dieselbe Kennzahl auf drei verschiedene Arten bauen. Wenn „Kundenwert über die Lebenszeit“ in drei Abteilungen drei Definitionen hat, baut jede Abteilung ihre eigene Rechenstrecke. Die Definition zu vereinheitlichen spart nicht nur Rechenleistung und Speicher, sondern auch die Zeit, die in der Auswertung auf das Abgleichen widersprüchlicher Zahlen geht.

Die Automatisierung der Data Governance verhindert den teuersten verborgenen Posten: Entscheidungen auf falschen Daten und die Nacharbeit, die folgt. Selbsttätige Prüfungen der Qualität, die eine Änderung am Schema abfangen, bevor sie 12 nachgelagerte Strecken bricht, sparen weit mehr, als sie im Betrieb kosten.

Wie Dawiso die Kosten des Datenmanagements senkt

Der Datenkatalog von Dawiso macht doppelte und ungeregelte Datenbestände sichtbar, die Teams dann mit ihren Kosten für Speicher und Rechenleistung abgleichen können. Metadaten zu Lineage und Verantwortlichen helfen Teams zu entscheiden, was archiviert und welcher tote Bestand abgeschaltet wird.

Das Business Glossary schafft gemeinsame Definitionen für Kennzahlen und verhindert damit das Problem der doppelten Strecke. Wenn sich alle Teams einig sind, was „monatlich aktiver Nutzer“ bedeutet und wo die maßgebliche Berechnung liegt, baut niemand eine konkurrierende Fassung.

Data Lineage zeigt, welche nachgelagerten Prozesse an jedem Bestand hängen, sodass Teams Datenbestände gefahrlos abschalten können, ohne etwas zu brechen, das sie nicht sehen. Eine „ungenutzte“ Tabelle zu löschen, die einen vierteljährlichen Bericht für die Compliance speist, ist ein teurer Fehler. Lineage verhindert ihn.

Über das Model Context Protocol (MCP) kann Automatisierung diesen Kontext abfragen. Jeder MCP-kompatible Agent kann die Verantwortlichen eines Bestands und seine nachgelagerte Lineage nachschlagen, bevor eine Regel für den Lebenszyklus ihn archiviert, sodass die Entscheidung auf geregelten Metadaten beruht statt auf Vermutungen.

Fazit

Kosteneffizientes Datenmanagement ist keine Strategiesitzung. Es ist eine Liste zum Abhaken: Speicher stufen, Rechenleistung richtig bemessen, doppelte Strecken zusammenlegen, Eigenbau gegen Zukauf durchrechnen und Data Contracts durchsetzen. Jeder Punkt auf dieser Liste hängt daran, zu wissen, welche Daten man hat, wer sie nutzt und was ihre Pflege kostet. Die Organisationen, die zuerst ihre Metadaten regeln, geben für alles andere weniger aus.

Quellen

• Flexera, 2026 State of the Cloud Report (29 % der Ausgaben für IaaS und PaaS gelten als vergeudet; Kosten sind für 85 % die größte Herausforderung).
• Amazon Web Services, Amazon S3 pricing (S3 Standard zu 0,023 US-Dollar/GB/Monat in US East für die ersten 50 TB; Preise für Standard-IA und Glacier Deep Archive).
• Amazon Web Services, Understanding and managing Amazon S3 storage classes (Abrufgebühren bei Standard-IA, Zugriffsstufen von Intelligent-Tiering, Abrufzeiten bei Glacier).
• Google Cloud, BigQuery pricing (aktiver und Langzeitspeicher, der Wechsel nach 90 Tagen, Abrechnung auf Abruf je gelesener Datenmenge).
• Amazon Web Services, Amazon EC2 Spot Instances (Spot-Rabatte von bis zu 90 % gegenüber On-Demand).
• Google Cloud, Spot VMs (Rabatte für Spot-VMs gegenüber On-Demand-Preisen).