Puedes leer todo sin registrarte. Solo crearemos un perfil anónimo cuando decidas guardar tu progreso.
Lección 1 de 5
DBUs, SKUs y coste cloud
Elige serverless, SQL warehouse o compute clásico según APIs, latencia, control de infraestructura y patrón operativo.
- Duración
- 17 min aprox.
- Objetivo
- Elige serverless, SQL warehouse o compute clásico según APIs, latencia, control de infraestructura y patrón operativo.
- Siguiente paso
- Continuar con la siguiente lección
Ver detalles del módulo
Compute, políticas, etiquetas y costes
Atribuye consumo, controla guardrails y optimiza coste sin degradar el valor del workload.
- Consultar costes con system tables
- Etiquetar y atribuir consumo
- Elegir modos serverless y políticas
01Modelo mentalDBUs, SKUs y coste cloud
Elige serverless, SQL warehouse o compute clásico según APIs, latencia, control de infraestructura y patrón operativo.
+
DBUs, SKUs y coste cloud
Elige serverless, SQL warehouse o compute clásico según APIs, latencia, control de infraestructura y patrón operativo.
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.
Modelo mental
Elegir compute es elegir un contrato operativo, no una talla de máquina. Serverless entrega capacidad gestionada con arranque, escalado y actualizaciones abstraídos; un SQL warehouse ofrece un endpoint gobernado y concurrente para SQL y BI; el compute clásico expone familias de instancia, driver, workers, runtime y políticas para workloads que necesitan ese control. Las tres opciones ejecutan trabajo, pero difieren en APIs admitidas, aislamiento, latencia de preparación, responsabilidad de operación y forma de facturación. El punto de partida son las propiedades del workload: lenguaje, estado, duración, concurrencia, dependencias, red privada, previsibilidad y SLA. La preferencia personal por un tipo de clúster no es un requisito técnico.
Conjunto de capacidades, límites y responsabilidades operativas asociado a una modalidad de ejecución.
Evita elegir sólo por nombre o precio cuando una API, red o dependencia puede bloquear el workload.Recurso de compute orientado a consultas SQL, BI y concurrencia mediante un endpoint administrado.
Aísla clientes del ciclo de vida del compute y ofrece controles específicos de cola y escalado.Compute con driver, workers, runtime y configuración de infraestructura explícitos.
Aporta control para requisitos especiales a cambio de mayor operación y riesgo de dimensionamiento.{
"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
}La decisión incluye un fallback y una fecha de revisión; evita declarar serverless o clásico como dogma.
Puntos clave
- Serverless es la opción por defecto para workloads compatibles.
- SQL warehouse corresponde a SQL/BI; jobs serverless a automatización general compatible.
- Compute clásico se justifica con una limitación concreta, no con costumbre.
Evita
- Usar all-purpose compartido para un job crítico y mezclar su coste con trabajo interactivo.
- Migrar a serverless sin revisar configuraciones Spark, sinks o dependencias no compatibles.
Recuerdo activo