FinOps

Databricks recomienda serverless para la mayoría de notebooks, jobs y pipelines porque administra aprovisionamiento, escalado, Photon y actualizaciones. Un SQL warehouse serverless sirve BI y SQL; jobs serverless sirve tareas automatizadas sin configurar clúster. Compute clásico sigue siendo válido cuando una API, runtime, red o configuración especializada no está soportada en serverless.

La decisión se toma por requisito, no por preferencia histórica. Define SLA de arranque y ejecución, lenguaje, librerías, conectividad y observabilidad disponible. En serverless no hay Spark UI: se usa Query Profile. En clásico controlas familias y autoscaling, pero también capacidad, parches y tiempo ocioso. Evita all-purpose para producción automatizada salvo una excepción explícita.

{
  "workload": "daily_customer_360",
  "candidate": "serverless_jobs",
  "requirements": {
    "startup_sla_minutes": 8,
    "languages": ["Python", "SQL"],
    "network": "managed_connector",
    "spark_ui_required": false
  },
  "fallback": "classic_jobs_compute",
  "review_after_runs": 20
}

Más nodos pequeños y pocos nodos grandes pueden sumar cores y memoria similares, pero no se comportan igual. Joins y agregaciones con particiones grandes necesitan memoria por executor; workloads muy paralelos pueden aprovechar más workers. El driver planifica, recopila metadatos y recibe resultados de acciones como `collect()`, por lo que escalar workers no resuelve un driver sobrecargado.

Comienza con una familia general, autoscaling y límites observables. Revisa utilización de CPU, memoria, spill, I/O y duración por stage; cambia una variable cada vez. En AWS, Azure y GCP varían nombres, discos y mercados spot, pero el método es el mismo. Mantén el driver bajo demanda y usa spot/preemptible en workers sólo si el workload tolera interrupciones.

{
  "spark_version": "16.4.x-scala2.12",
  "runtime_engine": "PHOTON",
  "autoscale": {
    "min_workers": 2,
    "max_workers": 8
  },
  "autotermination_minutes": 20,
  "custom_tags": {
    "cost_center": "finance-data",
    "environment": "prod"
  }
}

Serverless jobs y pipelines ofrecen modo performance optimized para arranque rápido y modo standard para automatizaciones que toleran aproximadamente 4–6 minutos de inicio a cambio de menor coste. Los notebooks usan el modo interactivo adecuado. Serverless administra infraestructura y Photon, pero el ingeniero sigue controlando la forma de la consulta, paquetes, parámetros y cuánto dato procesa cada ejecución.

Los entornos serverless sustituyen la selección directa de Databricks Runtime y mantienen una API base estable. Fija versiones de paquetes y usa entornos/base environments, porque init scripts no están soportados. En streaming serverless, `Trigger.AvailableNow` procesa lo disponible; limita `maxFilesPerTrigger` o `maxBytesPerTrigger` para evitar microbatches impredecibles.

# requirements.txt
pydantic==2.11.7
requests==2.32.4
tenacity==9.1.2

# En el job, selecciona un entorno compatible y conserva
# este fichero versionado junto al código y sus pruebas.

Las compute policies restringen la creación de compute clásico: pueden fijar runtime, modo de acceso, Photon, límites de workers, autotermination y tags. Las familias de políticas aportan bases mantenidas por Databricks. Una buena policy reduce opciones peligrosas y deja editables sólo parámetros que el equipo debe decidir; instalar librerías mediante policies es preferible a init scripts.

Serverless usage policies son objetos distintos que asignan tags de coste a notebooks, jobs, pipelines y otros workloads serverless. Sus tags aparecen en `system.billing.usage.custom_tags`. Los tags viajan a registros y pueden replicarse globalmente: usa centro de coste, producto y entorno, nunca correo, nombre de cliente o datos confidenciales. Recuerda que un pipeline disparado por un job conserva su propia policy.

{
  "autotermination_minutes": {
    "type": "range",
    "maxValue": 60,
    "defaultValue": 20
  },
  "autoscale.max_workers": {
    "type": "range",
    "maxValue": 12,
    "defaultValue": 4
  },
  "custom_tags.cost_center": {
    "type": "fixed",
    "value": "finance-data"
  }
}

`system.billing.usage` ofrece registros regionales de consumo con SKU, producto origen, metadatos de job/notebook/warehouse, identidad y tags. Para coste monetario se une con la tabla de precios por SKU y vigencia; las correcciones pueden emitir retracciones y restatements, así que agrega `usage_quantity` con su signo en lugar de descartar filas negativas.

Un dashboard útil separa coste, volumen y resultado: coste por ejecución, por millón de filas o por SLA cumplido. Segmenta serverless por `billing_origin_product` y `usage_metadata`, porque varias capacidades comparten SKU. Define presupuestos y alertas como detección temprana, no como mecanismo que detiene automáticamente todos los workloads.

SELECT
  usage_date,
  billing_origin_product,
  custom_tags['cost_center'] AS cost_center,
  sku_name,
  SUM(usage_quantity) AS usage_quantity
FROM system.billing.usage
WHERE usage_date >= current_date() - INTERVAL 30 DAYS
GROUP BY usage_date, billing_origin_product,
         custom_tags['cost_center'], sku_name
ORDER BY usage_date DESC, usage_quantity DESC;