Databricks Runtime, Photon y clusters: DBR/LTS, políticas, pools y forma del coste de cómputo

Todo pipeline de este curso se ejecuta en algo. Las tablas Delta no se optimizan solas, Auto Loader no lista un prefijo gratis y un pipeline de Lakeflow solo es tan barato como las máquinas que hay debajo. Esta lección trata de ese algo: qué versión de Databricks Runtime fijas, si Photon está ejecutando tu plan, en qué tipo de cluster (o warehouse, o sesión serverless) corre el trabajo, quién tiene permiso para crearlo (cluster policies), qué tan rápido puede arrancar (instance pools), qué familia EC2 usa y, la parte que aparece en la factura, qué tarifa de DBU le corresponde.

Ese último punto es la columna vertebral de la lección. En AWS, la misma instancia EC2 se factura a una tarifa de DBU distinta según el tipo de cómputo al que la conectaste. La Jobs API 2.0 lo dice sin rodeos: "When you run a job on a new jobs cluster, the job is treated as a Jobs Compute (automated) workload subject to Jobs Compute pricing" y "When you run a job on an existing all-purpose cluster, it is treated as an All-Purpose Compute (interactive) workload subject to All-Purpose Compute pricing" (docs.../jobs-2.0-api, página fechada 2026-08-03). Mismos nodos, mismo Spark, mismos datos, y con los precios de lista de EE. UU. a oct 2026, un SKU de $0.15/DBU frente a un SKU de $0.55/DBU. Todo lo demás de esta lección es una decisión de rendimiento o de gobernanza; esta es aritmética pura, y por eso un ETL nocturno de 45 minutos puede costar $1,027 o$2,947 al mes (ejemplo resuelto E5).

En esta lección vas a:

• leer la tabla de DBR compatibles a oct 2026 con todas sus fechas de EoS, y recorrer el ciclo Beta → GA → LTS → EoS → EoL como un diagrama;
• rastrear una consulta por Catalyst y Photon, nombrar los cuatro casos en los que Photon no ayuda y poner fecha a cada benchmark que cites;
• separar el cómputo all-purpose, job, SQL warehouse y serverless, incluida la regla de precios que decide la factura;
• trabajar seis ejemplos resueltos: un JSON de cluster policy anotado, una configuración de instance pool, la selección de familia de instancias para cuatro formas de carga, la forma de coste job vs all-purpose, un triaje de Photon o no, y una postura de notebook de producción;
• aplicar cluster policies (fixed/allowlist/regex/range, dbus_per_hour, cluster_type, auto:latest-lts) y cerrar la trasera Unrestricted;
• configurar ventanas de autoscaling, terminación automática, topología de spot y first_on_demand sin tropezar con las trampas documentadas;
• estudiar Comcast y Addepar en AWS, leer el recuadro de actualizaciones de 2026 y practicar con doce preguntas más cuatro comprobaciones interactivas.

---

1. Databricks Runtime: la escalera de versiones y el reloj LTS

1.1 El conjunto compatible (página de notas de lanzamiento actualizada el 11 sep 2026)

Databricks publica dos líneas a la vez: una línea actual que sigue recibiendo funciones y una línea LTS que cambia novedades por una ventana de soporte de tres años. La tabla de versiones compatibles en AWS (docs .../release-notes/runtime, última actualización 11 sep 2026, consultada 2026-10) es la única lista de versiones en la que debes fiarte:

Cada versión también trae una variante ML (mismo número, MLflow más librerías ML fijadas a esa versión): la matriz de MLflow lee 19 → MLflow 3.12.0, 18 LTS → 3.8.1, 17.3 LTS → 3.0.1, 16.4 LTS → 2.21.3 (misma página, consultada 2026-10).

Dos detalles de 2026 importan más que las cifras en sí:

1. La numeración cambió en DBR 19. "Prior to Databricks Runtime 19, Databricks released runtimes as minor feature versions (for example, 18.0, 18.1, 18.2), each with its own Beta and GA release" (docs .../release-notes/runtime/databricks-runtime-ver, consultada 2026-10). A partir de la 19, la fase de desarrollo de funciones transcurre como una única línea mayor.
2. Una minor retirada y un LTS vivo conviven. La propia página de notas de la DBR 18.0 ya está etiquetada como (EoS), "El soporte para esta versión de Databricks Runtime ha terminado", aunque esa misma página también registra "This version incorporates all features … Databricks released this version in January 2026", Spark 4.1.0 y JDK 21 por defecto (docs.../release-notes/runtime/18.0, consultada 2026-10). Mientras tanto, 18 LTS está soportado hasta el 10 jun 2029. Fíjate en la línea LTS, nunca en un número minor retirado.

1.2 El ciclo de vida, dibujado

Las cuatro duraciones salen directamente de la página del ciclo de vida de soporte (consultada 2026-10): una fase de funciones GA de ~seis meses, retroportaciones LTS durante tres años, "The end-of-support date is three years after the GA release date" y "Databricks makes a best effort to set the end-of-life date six months after the end-of-support date". En el EoS la versión "ya no se puede seleccionar en la UI cuando creas o actualizas un recurso de cómputo"; en el EoL "becomes unusable … existing workloads running on these versions fail". Esa es la diferencia entre un job que deja de programarse y un job que se cae, y por eso fijar la versión es un control de producción, no una preferencia.

1.3 Qué línea para qué carga

La página de configuración de cómputo es explícita (docs .../compute/configure, última actualización 6 oct 2026): "Para el cómputo all-purpose, usa la versión más reciente … Para el cómputo de jobs que ejecuta cargas de trabajo operativas, considera usar la versión de Databricks Runtime de soporte a largo plazo (LTS)." Traducción:

• Interactivo/exploratorio (all-purpose): la versión compatible más nueva: quieres las funciones y, además, reinicias a menudo.

• Jobs operativos: una línea LTS, fijada por la cadena exacta (17.3.x-scala2.12), porque un minor de Spark inesperado a mitad de trimestre es una caída.

• Ciencia de datos / ML: la variante ML de la línea que hayas elegido.

• En una cluster policy: spark_version con un token especial, auto:latest-lts, auto:latest-ml, auto:prev-major, auto:prev-lts, que "no hace que el cómputo se actualice solo cuando se publica una nueva versión del runtime"; se resuelve cuando un usuario edita el cómputo (docs.../admin/clusters/policy-definition, última actualización 1 oct 2026).

• 📚 ¿Sabías que…? Databricks retiene "cluster configuration information for terminated clusters for 30 days" (intro de la Clusters API, consultada 2026-10). Es suficiente para responder «¿qué runtime y tipo de nodo usaba aquel job que falló el martes pasado?» y suficientemente corto como para que convenga exportar las formas que te interesan (con asset bundles o Terraform) en lugar de hacer arqueología en la UI.

---

2. Photon: lo que hace el motor vectorizado, y lo que no hace

2.1 Un planificador, dos motores de ejecución

"Photon is the Databricks-native vectorized query engine that accelerates your SQL workloads, DataFrame API calls, ETL pipelines, and stateless streaming workloads" (docs.../compute/photon, última actualización 11 sep 2026). La frase de arquitectura que hay que memorizar: "El optimizador de consultas de Apache Spark (Catalyst) sigue planificando tu consulta, pero Photon se hace cargo en la capa de ejecución", y "Cuando Photon encuentra una operación no soportada … vuelve de forma transparente al runtime de Spark para el resto de esa operación."

Photon procesa "data in batches of thousands of rows at a time, enabling modern CPUs to use SIMD instructions", y funciones como el I/O predictivo y el podado dinámico de archivos en MERGE/UPDATE/DELETE requieren Photon (misma página). Es "el motor predeterminado para todos los SQL warehouses", está habilitado en el cómputo serverless y en los pipelines Lakeflow serverless y, desde DBR 9.1 LTS, "Photon is enabled by default on compute running Databricks Runtime 9.1 LTS and above" para el cómputo classic all-purpose y de jobs creado a través de la UI.

2.2 Dónde no ayuda Photon

Las docs son inusualmente directas, y cada cláusula de abajo es citable:

También hay una cláusula de economía: Photon no es velocidad gratis. "Photon instance types consume DBUs at a different rate than the same instance type running the non-Photon runtime" (blog de Databricks, "Announcing Photon Public Preview", 2021-06-17). La regla operativa: Photon solo compensa cuando es más que proporcional en velocidad: así que haz benchmark de tu carga y mide la cuota de Photon en la Spark UI en lugar de adivinar.

2.3 Las pruebas, con fecha

Cítalas con sus fechas; no son intercambiables:

• 📚 ¿Sabías que…? El récord auditado de TPC-DS de 100 TB se ejecutó sobre el sustrato de este curso: datos en Amazon S3, 256 × i3.2xlarge (SIGMOD '22). Instancias optimizadas para almacenamiento más un motor vectorizado es el dato de referencia de "el lakehouse gana al warehouse", y es la misma familia de instancias en la que los warehouses classic y pro siguen estandarizándose hoy (todos los workers de warehouse classic/pro son i3.2xlarge, docs.../warehouse-behavior, consultada 2026-10).

2.4 Ejemplo resuelto E1: ¿Photon o no? Tría dos notebooks

A octubre de 2026. Dos equipos afirman "Photon no ayudó". Tría antes de cambiar nada:

---

3. Anatomía del cluster: all-purpose vs job vs warehouse vs serverless

3.1 Qué corre dónde, en AWS

"Databricks components" (docs, página fechada 2026-07-28) traza la línea así de simple: "There are two types of clusters: all-purpose and job." Añade los SQL warehouses y las sesiones serverless y tienes los cuatro tipos de cómputo que usa este curso.

Tres hechos específicos de AWS de ese dibujo: los clusters classic y los warehouses classic/pro corren en EC2 en tu VPC ("With a pro SQL warehouse (unlike a serverless SQL warehouse), the compute layer exists in your AWS account", docs .../warehouse-types, última actualización 12 feb 2026); serverless corre en la cuenta de Databricks sin IPs públicas; y con la conectividad segura de clusters activada (el modo de despliegue por defecto), nada del plano de datos necesita una IP pública de entrada.

3.2 La diferencia de ciclo de vida, y la de precio

Cita de la docs (página de componentes, 2026-07-28): "El programador de trabajos de Databricks crea un job cluster cuando ejecutas un job en un job cluster nuevo, y termina el cluster cuando el job está completo." Y la consecuencia en precios, de la Jobs API 2.0 (página fechada 2026-08-03): "When you run a job on a new jobs cluster, the job is treated as a Jobs Compute (automated) workload subject to Jobs Compute pricing": mientras que apuntar un job a un all-purpose cluster existente es All-Purpose pricing y, según la página de componentes, "running a job on an existing all-purpose cluster is also treated as an interactive workload." La misma API añade: "We suggest running jobs on new clusters for greater reliability."

La guía de jobs-compute de Databricks va más lejos (docs.../jobs/compute, última actualización 15 sep 2026): "El cómputo serverless para jobs es el predeterminado para todos los tasks que lo admiten", y "Cómputo all-purpose: Puedes configurar opcionalmente tasks usando cómputo all-purpose classic. Databricks no recomienda esta configuración para jobs de producción."

Un matizo que conviene llevar a la lección 09: un job cluster compartido está "scoped to a single job run and cannot be used by other jobs or runs of the same job. Libraries cannot be declared in a shared job cluster configuration." Declara las dependencias por task (o con job environments), nunca en el objeto del cluster compartido.

3.3 Ejemplo resuelto E2, la forma de coste: un pipeline, tres configuraciones

A octubre de 2026, lista US, nivel Premium, AWS. Escenario: un ETL nocturno de 45 minutos que ejecuta 400 horas-cluster al mes, 4 nodos en total (1 driver + 3 workers). El propio ejemplo resuelto de Databricks usa un nodo que "runs at 3 DBU/hour" (blog, Best practices for cost management in Databricks, 2022-10-18): trata ese valor de emisión como ilustrativo: la emisión de DBU por nodo no se publica como tabla oficial, así que lee la tuya en system.billing.list_prices o en la calculadora de precios.

La configuración (B) también arrastra horas en reposo: un all-purpose cluster factura mientras está encendido, no mientras trabaja, que es exactamente por lo que existen la terminación automática (sección 8) y las políticas (sección 6). Fíjate en lo que no cambió entre (A) y (B): nodos, runtime, Spark, datos. Solo el tipo de cómputo, y con él, el SKU. Esa es la decisión de mayor apalancamiento de toda esta lección, y por eso Databricks informa de que los clientes "saved tens of thousands of dollars by simply moving just ten percent of their workloads from all-purpose clusters to jobs clusters" (blog, 2022-10-18).

---

4. Cómputo serverless y SQL warehouses

4.1 La matriz de cómputo recomendado

Databricks publica una tabla de recomendación por tipo de task (docs .../jobs/compute, última actualización 15 sep 2026). Léela como "lo por defecto, salvo que tu lista de dependencias lo prohíba":

Elegibilidad de serverless en AWS (docs.../sql/admin/serverless, última actualización 10 jun 2026): workspace en plan Premium o superior, no es una prueba gratuita, soportado en todas las regiones de AWS, sin IPs públicas, y "Cluster policies, including spot instance policies, are not supported". Esa última cláusula es el borde de todo lo de la sección 6: las políticas gobiernan el cómputo classic; serverless se gobierna con controles a nivel de cuenta o de workspace.

4.2 Limitaciones de serverless: lee esta lista antes de migrar un job

De docs .../compute/serverless/limitations (consultada 2026-10), los bloqueos que obligan al cómputo classic:

• "R is not supported." · "Scala y R no están soportados en notebooks."
• "Solo las APIs de Spark Connect están soportadas. Las APIs RDD de Spark no están soportadas."
• "Maven coordinates are not supported." · "JAR libraries are not supported in notebooks … JAR tasks in jobs are supported." · "Las librerías de task no están soportadas para tasks de notebook."
• "Debes usar Unity Catalog para conectarte a fuentes de datos externas." · "Access to DBFS is limited."
• "Serverless compute has a maximum runtime of 7 days."
• Triggers de streaming: Trigger.AvailableNow() (recomendado) y el obsoleto Trigger.Once(); Trigger.ProcessingTime y Trigger.Continuous no están soportados.

La página de migración (última actualización 2026-07-10) lista los mismos bloqueos como cosas que sustituir primero: imágenes personalizadas, variantes de ML Runtime, DBR < 13, instance profiles, y "dependencies such as eggs, JARs, and Maven libraries", con sus patrones de sustitución: RDD APIs → DataFrame APIs, rutas DBFS → volúmenes UC, IAM instance profiles → external locations de UC, JARs JDBC propios → Lakehouse Federation.

4.3 SQL warehouses: tres tipos, dos relojes

(docs .../sql-warehouse/warehouse-types, última actualización 12 feb 2026; auto-stop de docs .../sql-warehouse/create, consultada 2026-10)

El dimensionado de classic/pro es un cluster por 10 consultas concurrentes, desde 2X-Small (1 driver + 1 worker) pasando por X-Small, Small … X-Large (32 workers), 2X (64), 3X (128), 4X (256), con 5X-Large (512) en Public Preview (docs.../warehouse-behavior, consultada 2026-10). La recomendación permanente de Databricks: "Databricks recommends using serverless SQL warehouses when available", y la frase de facturación que hay que memorizar: "Idle SQL warehouses continue to accumulate DBU and cloud instance charges until they are stopped."

Veredicto comparativo: job cluster vs all-purpose vs SQL warehouse vs serverless (a oct 2026)

• Job cluster (classic, Jobs Compute $0.15/DBU + tu EC2): la respuesta por defecto para el batch de producción. Efímero por ejecución, sin reinicio, se termina junto con la ejecución, admite spot, gobernado por política, el SKU classic más barato por DBU. Paga las horas en las que corre de verdad; tú eres dueño de EC2, EBS y del calentamiento. Úsalo cuando las dependencias sean solo classic (JAR/Spark Submit, RDD, instance profiles, DBFS) o cuando el job corra largo y caliente con una forma predecible.
• All-purpose (All-Purpose Compute $0.55/DBU + tu EC2): solo interactivo: exploración, notebooks compartidos, enseñanza. 3,7× la tarifa por DBU de jobs en lista US, factura mientras está encendido, y apuntar jobs de producción a él es a la vez un anti-patrón de facturación interactiva y de fiabilidad ("Databricks no recomienda esta configuración para jobs de producción"). Controles obligatorios: terminación automática, una política, nunca un driver en spot.
• SQL warehouse (SQL Classic $0.22 / Pro $0.55 / Serverless $0.70 por DBU), la vía de servicio de BI, facturado mientras está encendido, dimensionado por talla de camiseta y no por los workers que elijas. Serverless añade Predictive IO + IWM y un auto-stop de 10 minutos; pro/classic corren en tu VPC sobre i3.2xlarge con auto-stop de 45 minutos y arranque de ~4 minutos. Elige por concurrencia de consultas y SLA de latencia, no solo por la tarifa de DBU, la brecha classic/serverless ($0.48 por DBU-hora) es la máquina más operaciones que serverless absorbe por ti.
• Jobs/notebooks serverless (Jobs Serverless $0.35/DBU, All-Purpose Serverless $0.75/DBU): el valor por defecto de la plataforma donde la lista de limitaciones lo permite: sin factura de EC2, sin pools, sin calentamiento, sin superficie de política, runtime máximo de 7 días, facturación por segundo, coste en reposo cero. Cuesta entre 1,3 y 2,3× más por DBU que classic, pero borra las columnas de tiempo en reposo y de administración de la factura.
• Veredicto en una línea: serverless por defecto → job clusters classic cuando un bloqueo o una forma larga y caliente lo exigen → all-purpose para humanos, nunca para pipelines → SQL warehouse para BI con auto-stop obligado. Todas las tarifas de arriba son lista US, nivel Premium, AWS, a oct 2026; confírmalas contra system.billing.list_prices en tu cuenta antes de comprometer un presupuesto.

---

5. Instance pools: arranque en caliente, no cómputo gratis

Un pool es "A set of idle, ready-to-use instances that reduce cluster start and auto-scaling times" (docs .../getting-started/concepts, 2026-07-28). Los clusters conectados toman su driver y sus workers del pool y los devuelven al terminar. Tres mandos de dimensionado (docs .../compute/pools, consultada 2026-10): min_idle_instances, max_capacity, idle_instance_autotermination_minutes.

La regla de facturación es la que los estudiantes suelen fallar: "Databricks no cobra DBUs mientras las instancias están en reposo en el pool. El cobro del proveedor de instancias sí aplica" (docs .../pool-best-practices / pool-index, consultadas 2026-10). Los pools desplazan el coste de la columna de DBU a la de AWS y te compran minutos de arranque; no borran la factura. Restricciones y reglas de las mismas páginas:

• Un pool es "either all spot instances or all on-demand instances"; la Instance Pools API añade SPOT_WITH_FALLBACK: "el pool adquiere primero instancias spot y pasa a instancias on-demand cuando la capacidad spot no está disponible".
• "By default, Databricks sets the max spot price at 100% of the on-demand price."
• El sobreescalado falla en voz alta: "Si un cluster que usa el pool solicita más instancias que este número durante el autoscaling, la solicitud falla con un error de tipo INSTANCE_POOL_MAX_CAPACITY_FAILURE." Mantén el tamaño máximo del cluster ≤ pool max_capacity.
• Los clusters heredan la availability zone del pool; usa pools separados cuando los requisitos de driver y de workers difieran.
• Nunca pongas el driver en spot: "No uses un pool con instancias spot como tipo de driver. Elige un tipo de driver on-demand para evitar que tu driver sea reclamado."
• Donde encaja serverless, el consejo de Databricks es directo: "If your workload supports serverless compute, Databricks recommends using serverless compute instead of pools."
• Guía de dimensionado: pools spot para los workers que toleran el coste; pools on-demand para "jobs with short execution times and strict execution time requirements".

5.1 Ejemplo resuelto E3: configuración del pool + la factura en reposo

A octubre de 2026 (lista us-east-1, leída 2026-10-12). Un equipo quiere arranques en caliente para un job nocturno de 45 minutos y para clusters de desarrollo interactivos.

• 📚 ¿Sabías que…? El seguro en reposo del pool cuesta unos $136/mes en este ejemplo: mientras que un solo día accidental de ese all-purpose cluster de 4 nodos dejado encendido (12 DBU/h × 24 h × $0.55 = $158.40 de DBUs más 4 × $0.192 × 24 ≈ $18.43 de EC2 ≈ $177) ya cuesta más que un mes entero de arranques en caliente. Los pools son para la latencia de arranque y la capacidad; la terminación automática es para el coste; los equipos que instalan pools pero se saltan la terminación automática suelen acabar con las dos facturas.

---

6. Cluster policies: gobernanza y barandas de coste en JSON

"A policy is a tool workspace admins can use to limit a user or group's compute creation permissions based on a set of policy rules" (docs.../admin/clusters/policies, página fechada 2026-06-10). Los beneficios documentados: ajustes prescritos, límites a cuántos clusters puede crear un usuario, una UI simplificada, "Control cost by limiting per-cluster maximum cost" y "Enforce cluster-scoped library installations". El propio blog de introducción de políticas de Databricks (2025-04-17) nombra las dos recompensas, "Simplification of platform usage and effective cost control are the two main benefits of cluster policies", y el conjunto inicial de cuatro familias: Personal Compute, Power User Compute, Shared Compute, Job Compute.

Mecánica que debes conocer antes de escribir JSON (docs .../admin/clusters/policy-definition, última actualización 1 oct 2026):

• Las reglas se enganchan a "cualquiera de los atributos controlados con la Clusters API", y "Solo puede haber una limitación por atributo."
• Tipos de limitación: fixed, forbidden, allowlist, blocklist, regex, range, unlimited (cada uno puede llevar defaultValue, isOptional, hidden).
• Atributos virtuales: dbus_per_hour, "Atributo calculado que representa el máximo de DBUs que un recurso puede usar por hora, incluido el nodo driver … Úsalo con range", y cluster_type (all-purpose / job / dlt), que te deja bloquear de entrada una clase de cómputo.
• runtime_engine acepta PHOTON o STANDARD; spark_version acepta los tokens auto:* (sección 1); workload_type.clients.jobs / .notebooks controlan qué tipo de cliente puede conectarse.
• Trampa de la API: "Default values don't automatically get applied to compute created with the Clusters API. To apply default values using the API, add the parameter apply_policy_default_values … set it to true."
• Borrar una política no limpia nada: el cómputo en marcha continúa, pero "cannot be edited unless the user has unrestricted cluster creation permissions."

6.1 Ejemplo resuelto E4: una política de baranda de coste solo para jobs

Construida sobre el propio ejemplo solo-para-jobs de las docs (página policy-definition, 1 oct 2026) y ampliada con Photon, topología de spot y etiquetas. Este es el JSON que pegarías en un recurso databricks_cluster_policy de Terraform o en la UI de administración:

---

7. Librerías y postura del notebook

7.1 Cuatro ámbitos, una matriz de fuentes

(docs .../libraries, última actualización 11 sep 2026)

Fuentes: PyPI, Maven, CRAN, archivos del workspace, volúmenes de Unity Catalog, almacenamiento de objetos de la nube. Los cortes a oct 2026:

• El standard access mode necesita DBR 13.3 LTS+ para PyPI, Maven, volúmenes y archivos del workspace; "CRAN: Not supported" en standard access mode (dedicated/legacy lo conservan).
• Los eggs de Python solo en "Databricks Runtime 13.3 LTS and below"; requirements.txt necesita DBR 15.0+.
• "storing library files in the DBFS root is deprecated and disabled by default in Databricks Runtime 15.1 and above": usa archivos del workspace, volúmenes UC o repos de paquetes.
• "Las librerías del workspace están obsoletas y no deberían usarse": ten en cuenta que los archivos del workspace siguen siendo totalmente soportados.
• Precedencia de import de Python (de mayor a menor): cwd de carpeta Git → raíz de carpeta Git → notebook-scoped (%pip) → a nivel de cómputo → librerías incluidas en la DBR.

Ergonomía de notebook que vale la pena memorizar: "%pip, Install Python packages (notebook-scoped)" pero "los comandos %pip no reinician automáticamente el proceso de Python … puede que necesites dbutils.library.restartPython()"; "%run, Execute another notebook, importing its functions and variables" y "%run must be in a cell by itself, because it runs the entire notebook inline." En serverless, %uv pip es la alternativa más rápida (versión del environment 5+).

7.2 Ejemplo resuelto E5: la postura del notebook de producción

• 📚 ¿Sabías que…? La guía de ingeniería de Databricks dice hoy: "Declarative automation is built on the idea that if something isn't in version control, it doesn't exist" y "Minimize business logic in notebooks … Use notebooks only as thin orchestration and visualization layers that call the underlying code" (docs .../notebooks/best-practices y .../developers/best-practices, ambas última actualización 2026-09-11). El repositorio complementario es github.com/databricks/notebook-best-practices.

---

8. Autoscaling, terminación automática y spot

8.1 Horizontal en classic, vertical en el lado serverless

Los clusters classic all-purpose y de jobs hacen autoscaling solo de workers, entre autoscale.min_workers y max_workers. El autoscaling optimizado (Premium y superior; los workspaces en plan Standard reciben autoscaling estándar) tiene cuatro características documentadas (docs .../compute/configure, última actualización 6 oct 2026):

• "Scales up from min to max in at most 2 scaling events."
• "On job compute, scales down if the compute resource is underutilized over the last 40 seconds. On all-purpose compute … 150 seconds." (spark.databricks.aggressiveWindowDownS, hasta 600 s, ralentiza esa caída.)
• Puede bajar nodos que no están en reposo usando el estado de los archivos de shuffle: así que un nodo caliente-pero-esperando no está protegido.
• El autoscaling estándar en cambio arranca con "+8 nodes, then exponential" y "baja cuando el 90% de los nodos están inactivos durante 10 minutos".

El escalado vertical no existe en classic: "Scale vertically by adding or removing resources from a single machine … This typically means stopping the workload, moving it to a larger machine, and restarting it" (docs.../performance-efficiency, consultada 2026-10). La selección vertical de instancias es una característica de pipelines serverless: "Vertical autoscaling is used for all serverless pipelines", eligiendo tipos de instancia eficientes en coste a partir de evidencias de OOM (docs.../ldp/auto-scaling, consultada 2026-10).

Dos trampas documentadas: "Do not enable Apache Spark Dynamic Allocation (spark.dynamicAllocation.enabled) on compute resources that use Databricks autoscaling" (ejecutores en conflicto → NODES_LOST), y el autoscaling "has limitations scaling down … for Structured Streaming workloads": los streams de larga duración quieren un suelo, no un suelo que se mueve.

8.2 Terminación automática y topología de spot

Terminación automática: mata un all-purpose cluster en reposo tras autotermination_minutes de inactividad. La API acepta 10 to 10.000 minutos, y 0 lo desactiva (docs del esquema de asset bundles y de jobs de Databricks, consultadas 2026-10), y las páginas de docs leídas en octubre de 2026 no imprimen ningún valor numérico por defecto, así que fíjalo explícitamente en lugar de fiarte de un valor de la UI que no has comprobado. Los valores por defecto de auto-stop de los SQL warehouse sí están documentados (sección 4.3): 45 min pro/classic, 10 min serverless.

Spot, de la misma página de configuración de cómputo: aws_attributes.availability ∈ SPOT / ON_DEMAND / SPOT_WITH_FALLBACK; aws_attributes.first_on_demand fija el driver (y N nodos) a on-demand; aws_attributes.spot_bid_price_percent por defecto es el 100% del on-demand. "La primera instancia siempre será on-demand (el nodo driver siempre es on-demand) y las instancias siguientes serán spot." AWS precifica el Spot a "up to 90% off On-Demand prices" (aws.amazon.com/ec2/spot, consultada 2026-10) con un aviso de interrupción de dos minutos, y el ahorro cae solo en la columna de AWS: las tarifas de DBU y los recuentos de emisión no cambian con el spot.

---

9. Tipos de nodo AWS: familias, Graviton, fleet y discos

9.1 Las familias

De la documentación de tipos de instancia de EC2 (consultada 2026-10): M de propósito general, C optimizadas para cómputo, R optimizadas para memoria y D/I optimizadas para almacenamiento con NVMe local: "Storage optimized instances are designed for workloads that require high, sequential read and write access to very large data sets on local storage" (las familias abarcan C5…C9g, R5…R9g, D3/D3en/I3en/I4i/I7i/I8g/Im4gn/Is4gen).

La propia guía de selección de Databricks (docs .../cluster-config-best-practices, página fechada 2026-06-11): el ETL por lotes simple que "don't require wide transformations" → "instancias con requisitos bajos de memoria y almacenamiento"; las cargas analíticas "will likely require reading the same data repeatedly, so recommended node types are storage optimized with disk cache enabled or instances with local storage"; y "Para jobs ETL por lotes simples … usa instancias spot para cargas de trabajo con requisitos de latencia laxos."

9.2 Ejemplo resuelto E6: selección de familia de instancias para cuatro formas de carga

A octubre de 2026; EC2 Linux on-demand, us-east-1, leído de la lista de precios de AWS el 2026-10-12.

Dos hechos de hardware más que conviene llevar: los tipos de instancia fleet (m-fleet.xlarge, rd-fleet.4xlarge, …) son "a variable instance type that automatically resolves to the best available instance type of the same size" usando el Spot Placement Score de AWS, y "Si actualizas el porcentaje de puja de instancias spot desde la API o JSON, no tiene efecto cuando el tipo de nodo worker es un tipo de instancia fleet." Los tipos fleet no llevan GPUs. La EC2 P2 ya no está soportada (misma página). Para ventanas garantizadas de GPU o de instancias, los Capacity Blocks se conectan con la etiqueta X-Databricks-AwsCapacityBlockId más una AZ y solo on-demand.

---

10. El medidor: la misma instancia, dos facturas distintas

10.1 La tabla de tarifas sobre la que te examinan

Lista US, nivel Premium, AWS, a oct 2026: fuentes documentales (las propias páginas de precios de Databricks se renderizan en cliente; estas cifras vienen del registro de proveedor UK G-Cloud 15 capturado el 2026-09-25 más seis lecturas independientes de la misma tarifa fechadas entre el 2026-06-03 y el 2026-10-06, y están corroboradas para SQL por instantáneas de página de databricks.com). Confírmalas en tu cuenta con system.billing.list_prices antes de presupuestar:

Tres reglas alrededor de esa tabla:

1. Región: las tarifas classic son planas en todas las regiones de AWS (de todos modos pagas EC2 local); las tarifas serverless no lo son: SQL Serverless es $0.70/DBU en us-east-1 frente a $0.91 en eu-central-1 (lectura de page-data, 2026-08-07). Una cifra de EE. UU. nunca se traslada a Fráncfort.
2. El nivel Standard se acabó. "Databricks has announced end-of-life for the Standard tier. All current Standard tier workspaces will be upgraded to the Premium tier effective October 1, 2025 on AWS and GCP": así que la vieja tarifa de $0.10 para jobs es historia (databricks.com/product/pricing/lakeflow-jobs, consultada 2026-10).
3. Dos facturas en classic, una en serverless. Classic = DBUs + EC2/EBS en tu cuenta; serverless dobla la máquina dentro de la DBU. system.billing.usage contiene solo el lado de Databricks: "El system.billing.usage solo contiene los costos de Databricks … el gasto de infraestructura en la nube no está incluido y debería revisarse desde la consola de la nube correspondiente" (blog, 2026-09-22).

10.2 Atribución: da a cada DBU una dirección

system.billing.usage (página fechada 2026-07-23) lleva sku, usage_type, product_feature, workspace_name, region, tags, run_as, metered_quantity, list_price y unblended_cost, "When a classic compute resource's driver and worker nodes use different instance types, their usage appears as separate records". Agrupa por sku + run_as y verás exactamente cuánto de tu parque está sobre All-Purpose frente a Jobs. Un límite que recordar cuando construyas el panel: las consultas de atribución de coste de jobs "only calculate costs for jobs run on jobs compute and serverless compute. Jobs run on SQL warehouses and all-purpose compute are not billed as jobs" (docs.../system-tables/jobs-cost, consultadas 2026-10). Y los presupuestos (hasta 1.000 por cuenta, 4 umbrales cada uno, en USD a precio de lista) monitorizan el gasto, no lo acotan (doc de presupuestos, 2026-10-07).

---

11. Las trampas: catorce confusiones que esta lección no te deja conservar

1. "LTS significa el número con .x." A oct 2026 18 LTS está soportado (hasta 2029-06-10) mientras que 18.0 está en EoS. Fija spark_version a la línea LTS.
2. "auto:latest-lts mantiene mis clusters al día." Se resuelve cuando se edita el cómputo, no de forma continua: los clusters en marcha no se actualizan solos.
3. "Nuestros clusters creados por API están sobre Photon." No, salvo que runtime_engine sea "PHOTON": el valor por defecto de la UI no viaja a la Clusters API ni a la Jobs API.
4. "Photon arreglará mi dashboard de 100 ms." "Queries that normally complete in under two seconds don't see meaningful improvement."
5. "Photon gestiona todo lo que gestiona Spark." Sin UDFs, sin APIs RDD/Dataset, sin streaming stateful; la caída es por operación y en silencio.
6. "Un job sobre un all-purpose cluster existente es la opción barata." Se factura al precio de All-Purpose (interactivo) y se marca como interactivo: 3,7× la tarifa por DBU en lista US.
7. "Los pools son gratis." 0 DBUs en reposo, pero los cargos de instancia de AWS continúan; fija min_idle_instances de forma deliberada.
8. "Workers en spot, driver en spot." Nunca: el driver siempre on-demand (first_on_demand >= 1), y el spot solo descuenta la columna de AWS.
9. "Dynamic Allocation + autoscaling de Databricks = más seguridad." Explícitamente desaconsejado: rotación de ejecutores y NODES_LOST.
10. "Más memoria = nodo más grande, sin reinicio." Los clusters classic no tienen escalado vertical; cambiar el tipo de nodo implica un reinicio.
11. "Los valores por defecto de la política se aplican solos." No vía la Clusters API: tienes que pasar apply_policy_default_values: true.
12. "Borramos la política, así que el gasto se detuvo." El cómputo existente sigue corriendo y se vuelve no editable (salvo para usuarios unrestricted).
13. "%pip install en el notebook significa que el job tiene el paquete." Las librerías notebook-scoped "do not persist": declara las dependencias a nivel de task, cluster o environment.
14. "La tarifa de DBU es mi coste total." En classic es la mitad de la factura; la mitad de EC2/EBS/NAT/S3 vive solo en AWS Cost Explorer.

Actualizaciones de 2026 (en octubre de 2026)

---

Casos Reales

📋 Caso A: Comcast (comunicaciones y medios, Cloud: AWS) Reto. Petabytes de telemetría y miles de millones de interacciones de voz de más de 20 millones de mandos de voz; pipelines frágiles y dolor de ingestión de archivos pequeños, con cientos de modelos desplegados en la nube, on-prem y edge. Stack en AWS. Databricks con Delta Lake para la ingestión y la optimización de archivos pequeños, MLflow gestionado y autoscaling con instancias spot: Cloud: AWS en la página de la historia (https://www.databricks.com/customers/comcast, página sin fecha, consultada 2026-10); también listado entre los clientes "already leveraging Databricks on AWS" (https://www.databricks.com/company/newsroom/press-releases/databricks-strengthens-scope-of-work-with-aws, 2022-05-10). Resultado comunicado. "10x Reduction in overall compute costs to process data · 90% Reduction in required DevOps resources"; "Delta Lake has enabled Comcast to optimize data ingestion, replacing 640 machines with 64 while improving performance" (https://www.databricks.com/customers/comcast, sin fecha, consultada 2026-10; historia originada en 2019). Encaje con esta lección. Secciones 8 to 10: los workers spot más el autoscaling horizontal y el right-sizing estructural son exactamente las palancas del ejemplo resuelto E2: el ahorro vino de qué forma de cómputo ejecutó el trabajo, no de un descuento. ⏳ Nota temporal: una historia de origen 2019 que en 2026 sigue mostrándose: enséñala como lo que Comcast informó en su momento, no como un 10× garantizado.

📋 Caso B: Addepar (gestión de patrimonio, Cloud: AWS) Reto. Equipos de ingeniería y de datos en silos, entregas de pipeline lentas y coste de infraestructura creciente en una plataforma que modela más de 8 billones de dólares en inversiones. Stack en AWS. Databricks sobre AWS con Unity Catalog, notebooks compartidos y Databricks SQL: etiqueta Cloud: AWS en la página de la historia. Resultado comunicado. "Addepar models over $8 trillion in investments on Databricks running on AWS. Shared notebooks, Unity Catalog and collaborative data access bring engineering and data teams together in one place, accelerating pipeline delivery by 5x and cutting infrastructure costs by $2 million" (https://www.databricks.com/customers/addepar/aws, página sin fecha, consultada 2026-10). Encaje con esta lección. Secciones 6 y 10: una reducción de infraestructura de 2 millones de dólares con 5× de velocidad de entrega es lo que "la gobernanza y la estandarización del cómputo" significan en una factura: el cómputo compartido y gobernado por políticas gana al desorden de un-cluster-por-notebook, que es el problema de la política de cómputo personal de la sección 6 resuelto a escala de empresa. ⏳ Nota temporal: página sin fecha, consultada en oct 2026; los 2 millones de dólares son coste de infraestructura, no coste de DBU.

---

---

Preguntas de Práctica (Practice Questions)