Cost
Mittleres LevelWie senke ich meine Databricks-/EMR-/Glue-Rechnung, ohne etwas kaputtzumachen?
Nicht jeder Kostenhebel trägt das gleiche Risiko. Hier die Reihenfolge, die echte Einsparungen bringt, bevor Sie etwas anfassen, das eine Pipeline wirklich kaputtmachen könnte.
Cloud-Data-Infra-Rechnungen schnellen selten wegen eines einzigen großen Fehlers hoch — sie kriechen durch ein Dutzend kleiner Entscheidungen nach oben, die damals sinnvoll waren und nie überprüft wurden. Die gute Nachricht: die meisten günstigen Korrekturen sind auch die sichersten.
Geringes Risiko, das zuerst
- Instanzanzahl an die tatsächliche Auslastung anpassen, nicht an den Peak, für den einmal provisioniert wurde. Liegt die durchschnittliche CPU-Auslastung über die Executor eines Jobs unter 40%, sind Sie sehr wahrscheinlich überprovisioniert — das ist fast ein Free Lunch, da es die Job-Logik überhaupt nicht verändert.
- Autoscaling aktivieren, falls noch nicht geschehen. Feste Cluster-Größe bedeutet, rund um die Uhr für Peak-Kapazität zu zahlen. Die meisten Managed-Spark-Plattformen (Databricks, EMR) unterstützen das nativ mit minimaler Konfiguration.
- Geeignete Batch-Workloads auf Spot-/Preemptible-Instanzen verschieben. Ein wiederholbarer, checkpointeter Batch-Job (kein langlebiger, zustandsbehafteter Streaming-Job) passt meist gefahrlos, oft zu 60-90% Rabatt gegenüber On-Demand-Preisen.
Mittleres Risiko, vorher testen
- Shuffle-Partitionsanzahl reduzieren, falls defensiv zu hoch eingestellt. Weniger, größere Partitionen bedeuten weniger Task-Scheduling-Overhead, aber zu weit gegangen bringt genau die Speicherdruck-Probleme zurück, wegen derer die hohe Zahl vermutlich gesetzt wurde — nach der Änderung gegen GC-Zeit und Spill-Bytes prüfen, nicht nur gegen die Wanduhrzeit.
- Kleine, häufige Jobs zu weniger, größeren Läufen konsolidieren. Cluster-Start-/Warmup-Zeit ist fixer Overhead, der bei jedem Lauf anfällt; ein Job, der alle 5 Minuten läuft, zahlt diesen Overhead 12x häufiger als dieselbe Arbeit, stündlich gebündelt.
Höheres Risiko, braucht echte Validierung
- Instanztyp wechseln (z. B. speicheroptimiert zu general-purpose) ändert das Speicher-pro-Kern- Verhältnis, auf das Ihr Job implizit abgestimmt war — ein Kostengewinn auf dem Papier kann in der Praxis zu einer Performance-Regression oder OOM werden.
- Aggressive TTL-/Lifecycle-Änderungen an Zwischenspeicher sparen Speicherkosten, können aber still alles downstream kaputtmachen, das davon ausging, dass diese Daten noch da wären.
Warum die Reihenfolge wichtig ist: Die Stufe „geringes Risiko" oben ist da, wo sich die Regeln von opti-pipe zuerst konzentrieren — Instanzanzahl und Shuffle-Partitionen, an Ihrer tatsächlich gemessenen Auslastung bemessen, als konkrete Empfehlung mit echter Dollarschätzung gezeigt, nicht als Prozentzahl, die Sie selbst in Kosten übersetzen müssen. Jeder Vorschlag ist etwas, das Sie genehmigen, nichts, das sich automatisch anwendet.
Sehen Sie, wie das bei Ihrer eigenen Pipeline aussieht.
Laden Sie ein echtes Spark-Event-Log, ein dbt run_results.json oder einen Flink-Metrics-Export hoch und erhalten Sie konkrete, vor der Anwendung zu genehmigende Empfehlungen zurück — keine weitere Faustregel.