This final lesson covers the operational realities: controlling cloud spend, optimising Delta table performance, sizing clusters efficiently, and establishing runbooks for your production weather-to-power platform. As Tech Lead, cost accountability and operational health are your responsibility.
Databricks cost has two components: compute (DBUs) and cloud infrastructure (VMs + storage).[1]
| Component | Cost Driver | Your Pipeline |
|---|---|---|
| Job clusters (DBUs) | VM size × hours × DBU rate | ~0.5–2h compute/day across 4 runs. Primary cost centre. |
| SQL Warehouse | Warehouse size × active hours | Analyst queries + downstream reads. Serverless auto-scales to zero. |
| Storage | GB stored (cloud blob pricing) | Delta tables + checkpoints. Grows with retention policy. |
| Networking | Egress (data leaving region) | Small unless serving cross-region consumers. |
| Workload | Config | Daily Runtime | ~Monthly Cost |
|---|---|---|---|
| Ingestion (4× daily) | Single-node E4s (0.5 DBU/h) | 4 × 10 min = 40 min | ~$50–80 |
| Silver transforms (4×) | 2-worker D4s (1.5 DBU/h) | 4 × 8 min = 32 min | ~$60–100 |
| Feature + ML inference (4×) | 1-worker E8s (2 DBU/h) | 4 × 5 min = 20 min | ~$40–70 |
| SQL Warehouse (analysts) | Serverless, Small | ~2h active queries/day | ~$100–200 |
| Storage (Delta tables) | ~500 GB growing | — | ~$10–25 |
| Total estimate | ~$260–475/month |
These are rough estimates for a moderate-scale fleet (~50 turbines, 10 parks, Europe region). Actual costs depend on cloud provider, DBU tier (Premium vs. Standard), and data volumes.
Delta tables accumulate small files over time (from frequent appends). Unchecked, this degrades read performance.
-- Run weekly (or let auto-optimize handle it)
OPTIMIZE prod.silver.weather_ts;
OPTIMIZE prod.silver.power_ts;
OPTIMIZE prod.gold.forecast_ts;
-- With Z-ORDER for time-range query performance
OPTIMIZE prod.silver.weather_ts ZORDER BY (timestamp);
OPTIMIZE prod.silver.power_ts ZORDER BY (timestamp);
-- Remove files older than retention period (default 7 days)
-- After VACUUM, time travel to those versions is no longer possible
VACUUM prod.bronze.weather_raw RETAIN 30 DAYS;
VACUUM prod.silver.weather_ts RETAIN 14 DAYS;
VACUUM prod.gold.forecast_ts RETAIN 7 DAYS;
-- Enable at table creation (already in our schemas):
TBLPROPERTIES (
'delta.autoOptimize.optimizeWrite' = 'true', -- write larger files
'delta.autoOptimize.autoCompact' = 'true' -- compact small files
);
-- These reduce the need for manual OPTIMIZE, but Z-ORDER still needs
-- periodic explicit OPTIMIZE runs (auto-compact doesn't Z-ORDER).
| Maintenance Task | Frequency | Method |
|---|---|---|
| OPTIMIZE + ZORDER | Weekly | Scheduled maintenance job |
| VACUUM | Weekly | Same maintenance job |
| ANALYZE TABLE (stats) | After large loads | Improves query planning |
| Drop old Bronze partitions | Monthly | Retention policy enforcement |
| Task | Bottleneck | Right Size |
|---|---|---|
| GRIB download + parse | Network I/O, single-thread Python (cfgrib) | Single-node, memory-optimised (16GB+ RAM) |
| Bronze → Silver (geo-join) | Spark shuffle for join (broadcast eliminates this) | 2–4 workers, general purpose. Broadcast dim_assets. |
| Feature computation | Window functions (partition by asset) | 2–4 workers. Data is partitioned by asset_id = natural parallelism. |
| ML inference | Model predict (CPU-bound, pandas UDF) | 1–2 workers, ML runtime. Or single-node if model is light (LightGBM). |
| Gold write + aggregate | Minimal — small output volume | Shared with transform cluster (reuse). |
Start small, measure, scale up only when tasks are too slow. A single-node cluster for ingestion and 2-worker cluster for transforms is likely sufficient for a fleet of 50–200 turbines. The cluster auto-terminates after the job — over-provisioning costs you per minute, not per month.
-- Bronze: keep raw weather for reprocessing (30–90 days)
-- After that, Silver is the source of truth
ALTER TABLE prod.bronze.weather_raw
SET TBLPROPERTIES ('delta.deletedFileRetentionDuration' = '30 days');
-- Silver: keep indefinitely (primary analytical asset)
-- VACUUM removes only file versions, not logical data
-- Gold: keep forecast history for accuracy tracking (1–2 years)
-- Older forecasts can be archived to cold storage if needed
| Layer | Retention | Rationale |
|---|---|---|
| Bronze | 30–90 days | Reprocessing window. Beyond this, Silver is truth. |
| Silver | Indefinite (2+ years) | Core analytical asset. ML training needs history. |
| Gold | 1–2 years | Forecast accuracy tracking. Regulatory if applicable. |
| Features | Same as Silver | Training requires feature history aligned with labels. |
Key metrics to track on an operational dashboard (Databricks SQL Dashboard or external):
| Metric | Source | Alert Threshold |
|---|---|---|
| Pipeline success rate | Workflow run history | < 95% over 7 days |
| Pipeline duration | Workflow run history | > 2× median |
| Gold freshness | MAX(produced_at) in forecast_ts | > 2 hours stale |
| Forecast MAE (7-day rolling) | forecast_accuracy table | > 20% above baseline |
| Park coverage | DISTINCT parks in latest Gold batch | < 100% expected parks |
| Daily DBU spend | Databricks billing API / account console | > 2× daily budget |
| Storage growth rate | DESCRIBE DETAIL on tables | > 10% week-over-week unexpected growth |
Your Silver weather_ts table has degraded query performance over the past month. The table receives 4 appends daily. Most likely cause?
You want to reduce compute cost for the ingestion tasks. Which change has the highest impact?
Bronze weather data is retained for 30 days. After 30 days, what happens if you need to reprocess older data?
📖 Recommended Reading
Delta Lake table optimization best practices — covers OPTIMIZE, VACUUM, Z-ORDER, auto-optimize, and file management. Also see Cluster configuration best practices for right-sizing guidance.
You've now covered the complete Databricks weather-to-power architecture:
You've completed the foundation course. Ask your teacher to dive deeper into any topic, create hands-on exercises, or explore advanced topics (streaming, real-time inference, multi-model ensembles).
Rechtliches: Impressum