Databricks Cost Optimization: 12 Strategien für eine niedrigere Cloud-Rechnung

TL;DR: Die größten Hebel: idle All-Purpose-Cluster killen, Batch-Jobs auf Jobs-Compute migrieren, Spot-Worker, Right-Sizing und Photon. Alles zusammen schneidet eine typische Databricks-Rechnung um 50–70 %.

Databricks ist mächtig — und wie alle mächtige Infrastruktur kann es schnell teuer werden. Teams entdecken regelmäßig Überraschungsrechnungen aus idle Clustern, überdimensionierten Nodes und ineffizienten Queries. Dieser Guide zeigt 12 umsetzbare Strategien, mit denen Data-Engineering-Teams Databricks-Spend senken — ohne Performance zu opfern.

Databricks-Pricing verstehen

Bevor du optimierst, versteh, was Kosten treibt:

Jobs-Compute ist typischerweise 2–3× günstiger als All-Purpose-Compute für denselben Workload — dieser einzelne Insight treibt mehrere Optimierungen unten.

Strategie 1: Idle All-Purpose-Cluster killen

Der #1-Cost-Killer: Cluster, die nach Feierabend oder in der Mittagspause weiterlaufen. Ein vergessener 4-Node-Cluster bei 0,40 $/DBU × 4 Nodes × 10 Idle-Stunden = 16 $/Tag = 5.840 $/Jahr.

Aggressive Auto-Termination setzen:

import requests

DATABRICKS_HOST = "https://adb-WORKSPACE_ID.azuredatabricks.net"
TOKEN = "dapi..."

response = requests.post(
    f"{DATABRICKS_HOST}/api/2.0/clusters/edit",
    headers={"Authorization": f"Bearer {TOKEN}"},
    json={
        "cluster_id": "YOUR_CLUSTER_ID",
        "autotermination_minutes": 20,
    }
)

Default-Cluster-Policies (via Cluster Policies erzwingen):

{
  "autotermination_minutes": {
    "type": "fixed",
    "value": 30
  }
}

Strategie 2: Batch-Jobs auf Jobs-Compute verlegen

All-Purpose-Cluster sind für interaktive Entwicklung. Produktive Jobs sollten immer Jobs-Compute (Job-Cluster) nutzen — günstiger und isoliert:

# In your Databricks Asset Bundle (databricks.yml)
resources:
  jobs:
    nightly_etl:
      tasks:
        - task_key: transform
          new_cluster:
            spark_version: "14.3.x-scala2.12"
            node_type_id: "Standard_DS3_v2"
            num_workers: 4

Job-Cluster fahren für den Job hoch, laufen, terminieren — du zahlst nur Laufzeit.

Strategie 3: Spot/Preemptible-Instances nutzen

Spot-Instances (AWS) oder Spot-VMs (Azure) sind typischerweise 60–80 % günstiger als On-Demand. Für fehlertolerante Batch-Workloads: Hybrid nutzen — On-Demand-Driver + Spot-Workers.

cluster_config = {
    "cluster_name": "spot-workers-cluster",
    "spark_version": "14.3.x-scala2.12",
    "driver_node_type_id": "Standard_DS3_v2",
    "node_type_id": "Standard_DS3_v2",
    "num_workers": 8,
    "azure_attributes": {
        "availability": "SPOT_WITH_FALLBACK_AZURE",
        "spot_bid_max_price": -1
    }
}

Wann Spot: Bronze-Ingestion, Silver-Batch-Transforms, ML-Training. Wann nicht Spot: Interaktive Notebooks, Streaming mit Exactly-Once-Semantik.

Strategie 4: Cluster richtig dimensionieren

Über-Provisionierung ist verbreitet. Die meisten Teams fahren Cluster 2–3× größer als nötig.

Vor dem Sizing profilen:

SELECT
  application_id,
  SUM(disk_bytes_spilled) / 1e9 AS gb_spilled_to_disk,
  SUM(memory_bytes_spilled) / 1e9 AS gb_spilled_to_memory
FROM system.runtime.query_history
WHERE date_day >= current_date() - 7
GROUP BY 1
ORDER BY 2 DESC

Sizing-Heuristiken:

Strategie 5: Photon-Engine aktivieren

Photon ist Databricks' vektorisierte Query-Engine — beschleunigt SQL- und DataFrame-Operationen drastisch, also: Jobs sind schneller fertig und kosten weniger:

cluster_config = {
    "runtime_engine": "PHOTON",
    "node_type_id": "Standard_DS3_v2",
    "spark_version": "14.3.x-photon-scala2.12"
}

Photon liefert typischerweise 2–8× Speedups bei SQL-lastigen Workloads. Da du pro DBU-Stunde zahlst: schneller = billiger.

Beste Photon-Workloads: Delta-Lake-Reads/Writes, SQL-Aggregationen, Joins, Sorts.

Strategie 6: SQL Warehouses für BI-Queries

Niemals All-Purpose-Cluster für BI-Tool-Verbindungen (Tableau, Power BI, Looker) nutzen. Stattdessen Databricks SQL Warehouses — sind für concurrent SQL designt und für das Pattern deutlich günstiger:

SELECT
  warehouse_id,
  SUM(execution_duration_ms) / 3600000.0 AS total_hours,
  COUNT(*) AS query_count,
  AVG(execution_duration_ms / 1000.0) AS avg_duration_sec
FROM system.query.history
WHERE DATE(start_time) >= CURRENT_DATE - 30
GROUP BY 1
ORDER BY 2 DESC;

Auto-Stop und Auto-Scale konfigurieren:

{
  "auto_stop_mins": 10,
  "min_num_clusters": 1,
  "max_num_clusters": 3,
  "cluster_size": "Small"
}

Strategie 7: Strategisch partitionieren und Z-Ordern

Schlecht designte Tabellen zwingen zu Full Scans und verschwenden Compute. Partitionierung und Z-Ordering reduzieren gescannte Daten:

CREATE TABLE prod.silver.events
USING DELTA
PARTITIONED BY (event_date)
AS SELECT *, CAST(event_timestamp AS DATE) AS event_date
FROM prod.bronze.events_raw;

OPTIMIZE prod.silver.events
ZORDER BY (user_id, event_type);

Impact: Partition Pruning kann gescannte Daten um 90 %+ reduzieren — schneidet direkt Query-Kosten.

Strategie 8: Delta-Cache nutzen

Der Delta-Cache hält dekodierte spaltenbasierte Daten auf SSD/Memory zur Wiederverwendung. Auf häufig gelesenen Tabellen aktivieren:

spark.conf.set("spark.databricks.io.cache.enabled", "true")
spark.conf.set("spark.databricks.io.cache.maxDiskUsage", "50g")
spark.conf.set("spark.databricks.io.cache.maxMetaDataCache", "1g")

Cache vor Scheduled-Jobs vorwärmen:

spark.sql("CACHE SELECT * FROM prod.gold.customers")
spark.sql("CACHE SELECT * FROM prod.silver.products")

Strategie 9: Delta-Tabellen regelmäßig vakuumieren

Delta behält alte File-Versionen für Time Travel. Ohne VACUUM kumulieren Storage-Kosten:

VACUUM prod.silver.events RETAIN 168 HOURS;

ALTER TABLE prod.silver.events
  SET TBLPROPERTIES ('delta.deletedFileRetentionDuration' = 'interval 3 days');

def vacuum_all_tables(schema: str, retention_hours: int = 168):
    # Vacuum all Delta tables in a schema
    tables = spark.sql(f"SHOW TABLES IN {schema}").collect()
    for row in tables:
        table = f"{schema}.{row['tableName']}"
        print(f"Vacuuming {table}...")
        spark.sql(f"VACUUM {table} RETAIN {retention_hours} HOURS")

vacuum_all_tables("prod.silver", retention_hours=72)

Strategie 10: Cluster-Policies implementieren

Engineers daran hindern, überdimensionierte Cluster hochzufahren — Policies erzwingen:

policy = {
    "name": "Data Engineer Standard",
    "definition": {
        "dbus_per_hour": {
            "type": "range",
            "maxValue": 100
        },
        "autotermination_minutes": {
            "type": "fixed",
            "value": 30
        },
        "node_type_id": {
            "type": "allowlist",
            "values": ["Standard_DS3_v2", "Standard_DS4_v2"]
        },
        "num_workers": {
            "type": "range",
            "maxValue": 8
        }
    }
}

response = requests.post(
    f"{DATABRICKS_HOST}/api/2.0/policies/clusters/create",
    headers={"Authorization": f"Bearer {TOKEN}"},
    json=policy
)

Strategie 11: Structured Streaming effizient nutzen

Streaming-Cluster laufen oft 24/7 — sorgfältig optimieren:

# Micro-batch every 5 minutes instead of continuous
df.writeStream \
  .trigger(processingTime="5 minutes") \
  .format("delta") \
  .option("checkpointLocation", "/checkpoints/events") \
  .table("prod.silver.events") \
  .start()

# For batch workloads that can run on a schedule
df.writeStream \
  .trigger(availableNow=True) \
  .format("delta") \
  .table("prod.silver.events") \
  .start() \
  .awaitTermination()

Strategie 12: Kosten kontinuierlich monitoren

Was du nicht misst, kannst du nicht optimieren. Databricks System-Tables nutzen:

SELECT
  job_id,
  job_name,
  SUM(dbu_consumed) AS total_dbus,
  SUM(dbu_consumed) * 0.40 AS estimated_cost_usd,
  COUNT(*) AS run_count
FROM system.billing.usage
WHERE usage_date >= CURRENT_DATE - 30
  AND usage_type = 'JOBS_COMPUTE'
GROUP BY 1, 2
ORDER BY 3 DESC
LIMIT 20;

Billing-Daten an ein Monitoring-Tool wie Harbinger Explorer anbinden für automatische Anomalie-Detection — bekomm Alerts, wenn der DBU-Verbrauch eines Jobs unerwartet spikt.

Cost-Optimization-Checkliste

Alle Strategien zusammen können eine typische Databricks-Rechnung um 50–70 % schneiden.

FAQ

Wo fange ich an, wenn ich nur einen Hebel ziehen darf?

Auto-Termination + Cluster-Policies. Beides ist in einem halben Tag aufgesetzt und liefert 30–50 % Reduktion bei unkontrollierter Nutzung.

Sind Spot-Instances wirklich sicher genug für Produktion?

Für Batch-ETL und ML-Training: ja, mit On-Demand-Driver und Fallback. Für Streaming oder Jobs mit strikten SLAs: vorsichtig, mit Fallback-Konfiguration und Monitoring.

Wie sieht das DACH-Cost-Bild aus (DSGVO/EU-Hosting)?

Azure Databricks in West Europe oder AWS Frankfurt für EU-Residency. Premium-Tier kostet ~30 % mehr als Standard, dafür Unity Catalog und Audit-Logs inklusive. Für DSGVO sind die Compliance-Kosten gerechtfertigt.

Was, wenn ich keinen Photon nutzen kann (Custom UDFs etc.)?

Photon fällt auf Spark zurück, wenn nicht unterstützte Operationen genutzt werden — kein Failure. Du verlierst nur den Speedup. Workloads-Profile prüfen, ob die Custom-Operationen wirklich nötig sind.

Wie viel Aufwand realistisch für 50 % Einsparung?

2–4 Wochen für ein 15-Personen-Team, wenn du die Top-5-Strategien umsetzt: Auto-Termination, Jobs-Compute-Migration, Spot, Right-Sizing, Photon.

Stand: 14. Mai 2026.