Optimización del rendimiento en Databricks/AWS: liquid clustering, diseño de archivos, skew y ajuste de warehouses

Las consultas lentas del lakehouse casi nunca son «Spark es lento». Son una capa concreta que se comporta mal: demasiados archivos pequeños en S3, una columna de filtro cuyos rangos min/max se solapan en todos los archivos, una única clave de join caliente que arrastra el 38% de las filas, o un warehouse con el tamaño correcto y el número de clusters equivocado. Esta lección enseña la pila en el orden en que debes arreglarla, diseño → estadísticas → planificación/runtime → servicio, y enseña la versión de 2026 de esa pila, no la de 2019.

Esa distinción importa más que cualquier perilla. La documentación actual de Databricks es tajante: «Databricks recomienda usar liquid clustering en lugar de particiones, ZORDER u otros enfoques de diseño de datos» (docs .../tables/operations/optimize, última actualización 2026-03-31, réplica 2026-09-11), y «Las recomendaciones de ajuste manual no se aplican a las tablas gestionadas de Unity Catalog, que usan el ajuste automático del tamaño de archivo» (docs .../tables/tune-file-size, 2026-09-11). Mientras tanto, la capa de motor sigue autotuneándose: AQE está activado por defecto desde DBR 7.3, Photon es el motor de ejecución por defecto en los warehouses de Databricks SQL, y Databricks informa de que «en 2025, Databricks SQL ofreció hasta un 40% más de rendimiento en cargas de trabajo de producción, con mejoras aplicadas automáticamente» (blog, 2026-01-28).

Así que el planteamiento honesto para octubre de 2026 es: el ajuste manual vale más en tablas externas, en cargas de trabajo heredadas de hive-metastore y en clusters que no son los por defecto, y en entender qué capa está rota antes de tocar nada. Cada dato de esta lección procede de las páginas de documentación de Databricks sobre AWS de optimize, tamaño de archivo, particiones, clustering, data skipping, AQE, hints, predictive optimization, caching, comportamiento del warehouse y query profile (todas consultadas o fechadas en octubre de 2026), más blogs fechados de ingeniería de Databricks. Aquí no aparecen tarifas de DBU: el coste es el tema de la lección 15.

En esta lección vas a:

• recorrer la pila de cuatro capas y aprender qué síntoma pertenece a qué capa antes de tocar una sola configuración;
• dimensionar archivos contra los tres objetivos oficiales, 128 MB de auto-optimize, la banda de autotune de 256 MB → 1 GB y el techo manual de OPTIMIZE de 1 GiB, y calcular a mano los recuentos de archivos;
• aplicar la escalera de particionado (< 1 TB nunca · 1 to 100 TB clustering · ≥ 100 TB tal vez) y la guarda de ≥ 1 GB por partición, y ver cómo fracasa aritméticamente el antipatrón de alta cardinalidad;
• profundizar en liquid clustering: CLUSTER BY, CLUSTER BY AUTO, ≤ 4 claves, umbrales de clustering en la escritura, OPTIMIZE incremental frente a OPTIMIZE FULL, claves jerárquicas, idempotencia del bin packing y los suelos de DBR con sus fechas;
• ejecutar un ejemplo resuelto de comparación OPTIMIZE frente a CLUSTER BY, la misma tabla de 8 TB, el SQL heredado de partición+ZORDER al lado del SQL de liquid, y leer la gráfica de latencia antes/después;
• diagnosticar skew de join a partir de evidencia real de perfiles y subir la escalera documentada: hint de broadcast → división de skew por AQE → salting, con el raíl de arreglos equivocados al lado;
• configurar AQE con sus valores por defecto verificados (200 particiones de shuffle, broadcast de runtime de 30 MB, advisory de 64 MB, factor de skew 5×);
• juzgar Photon por carga de trabajo, dónde gana, dónde las Python UDF lo derrotan, y dimensionar un Databricks SQL warehouse con la doctrina de resize frente a scale más las capas de caché;
• perfilar como operador: el query profile para los warehouses, la Spark UI para los clusters, y un cálculo de particiones de shuffle que puedes hacer en papel;
• estudiar tres historias de rendimiento de clientes con nombre en AWS, leer el recuadro de actualización de 2026 y practicar con doce preguntas tipo examen más cuatro controles interactivos.

---

1. La pila de cuatro capas, y cómo elegir una capa

Cada latencia de consulta de este curso se decide en cuatro capas, en este orden. Arréglalas de arriba abajo y vuelve a medir tras cada cambio: nunca dos cambios a la vez, o no podrás atribuir la mejora.

Dos realidades de 2026 rehacen esa tabla. Primero, las capas 3 y 4 se autotunean cada vez más: AQE está activo por defecto (spark.databricks.optimizer.adaptive.enabled = true), Photon se ejecuta por defecto en los warehouses de Databricks SQL, y las tablas gestionadas reciben ajuste automático del tamaño de archivo. Segundo, la capa 2 no tiene techo en las tablas gestionadas: en las tablas externas de Unity Catalog se recopilan estadísticas de las primeras 32 columnas; en las tablas gestionadas de UC, «predictive optimization recopila estadísticas de omisión de archivos en las columnas que tus filtros de consulta usan con más frecuencia, en lugar de un conjunto fijo de columnas, de modo que estas tablas no tienen límite de 32 columnas» (docs .../tables/data-skipping, 2026-06-18).

El resto de esta lección es esa pila, capa por capa.

---

2. Capa 1: dimensionamiento de archivos y el problema de los archivos pequeños en S3

Los archivos pequeños duelean porque cada archivo cuesta un ida y vuelta LIST/GET de S3, una tarea de Spark y el parseo del footer de Parquet. Como dice la propia guía de Databricks, parte del coste es sencillamente «el tiempo dedicado solo a abrir y cerrar esos archivos diminutos» (guía discover, 2026-05-06). En S3 no hay capa de bloques: el archivo es la unidad de paralelismo, la unidad de estadísticas y la unidad que VACUUM recupera.

2.1 Tres objetivos oficiales, una banda sana

Tres números distintos son todos «oficiales», y enseñarlos como si fueran uno solo es el error clásico del tutorial desactualizado:

Dos corolarios que previenen los dos errores de diseño más comunes:

1. 1 GiB es un techo, no una meta para tablas pequeñas. Compactar una tabla de 300 GB en archivos de 1 GiB deja ~300 archivos y destruye el paralelismo del escaneo podado.
2. Subir un objetivo nunca fusiona nada por sí solo. «Cuando el tamaño de archivo objetivo de una tabla crece, los archivos existentes no se reoptimizan en archivos más grandes mediante el comando OPTIMIZE» (tune-file-size, 2026-09-11): tienes que ejecutar OPTIMIZE después.

2.2 Ejemplo resuelto E1: a qué se parece la salida de 8 TB de Auto Loader

La lección de E1 no es la banda de 15 to 25×, sino que el recuento de archivos y la forma de los archivos son números distintos. Una media de 440 MB con una mediana de 20 MB significa que el motor sigue pagando la sobrecarga de tarea por archivo en la mayor parte de la tabla.

2.3 Tres mecanismos combaten los archivos pequeños, en orden creciente de autoridad

1. Escrituras optimizadas (autoOptimize.optimizeWrite / spark.databricks.delta.optimizeWrite.enabled) hacen un shuffle antes de escribir para que cada partición emita archivos de ~128 MB. Están activas por defecto en MERGE, en UPDATE/DELETE con subconsultas, en CTAS/INSERT sobre warehouses de SQL, y «en Databricks Runtime 13.3 LTS y superior, todas las tablas registradas en Unity Catalog tienen las escrituras optimizadas activadas para las sentencias CTAS y para las operaciones INSERT en tablas particionadas». El coste es real: «Escribir menos archivos grandes es más eficiente … pero es posible que sigas viendo un aumento de la latencia de escritura, porque los datos se mezclan (shuffle) antes de escribirse».
2. Auto compaction (autoOptimize.autoCompact) «se ejecuta de forma síncrona en el cluster que realiza la escritura, después de que esta tenga éxito, y solo compacta los archivos que aún no se han compactado antes». En el historial de la tabla aparece como una operación OPTIMIZE con operationParameters.auto = true. Para MERGE, UPDATE y DELETE es obligatoria: «No puedes desactivar esta funcionalidad».
3. OPTIMIZE programado o predictivo: «Para tablas mayores de 1 TB, Databricks recomienda ejecutar OPTIMIZE de forma programada», clásicamente diariamente, de preferencia por la noche cuando los precios spot son bajos, y en un cluster de job separado, y para tablas con liquid clustering activo, «programar un job OPTIMIZE cada una o dos horas» (docs de clustering, 2026-09-25), porque el clustering es incremental y la mayoría de las ejecuciones son rápidas.

Auto compaction y las escrituras optimizadas «no son un sustituto completo de OPTIMIZE» (tune-file-size, 2026-09-11), y si predictive optimization está activado, «Databricks recomienda desactivar cualquier job OPTIMIZE programado» para que dejes de pagar dos veces (docs de clustering).

⚠️ ADVERTENCIA, no pelees tú solo con la ruta de escritura. «Si usas escrituras optimizadas, Databricks recomienda que no ejecutes coalesce(n) ni repartition(n) justo antes de una escritura para controlar la cantidad de archivos escritos» (tune-file-size, 2026-09-11), pagas dos shuffles para un solo trabajo. Del mismo modo: nunca desactives auto compaction a nivel de sesión y te olvides de ella. No se puede desactivar para MERGE/UPDATE/DELETE, pero un false a nivel de sesión sí la desactiva en silencio para los appends y los CTAS de esa carga de trabajo.

• 📚 ¿Sabías que…? OPTIMIZE es seguro por construcción: «Bin-packing optimization is idempotent, meaning that if it is run twice on the same dataset, the second run has no effect», y «Como OPTIMIZE no realiza cambios de datos en la tabla, una lectura antes y después de un OPTIMIZE da los mismos resultados. Ejecutar OPTIMIZE en una tabla que es fuente de streaming no afecta a ningún stream actual ni futuro que tenga esta tabla como fuente» (docs.../operations/optimize, 2026-03-31). ZORDER, en cambio, nunca fue idempotente: era incremental y requería re-ejecuciones.

---

3. Capa 1, particionado: la escalera y la guarda de ≥ 1 GB

La recomendación actual de particionado es más reciente que la mayoría de los tutoriales y más tajante de lo que la mayoría de los equipos esperan: «La mayoría de las tablas de Databricks con menos de 100 TB de datos no necesitan particionado» (docs .../tables/partitions, 2026-07-01).

La segunda guarda es por partición: «verify that each partition contains at least 1 GB of data. Tables with fewer, larger partitions tend to outperform tables with many smaller partitions» (misma página). El recuento de particiones es igual al de directorios en tu bucket, así que cada nivel extra de cardinalidad multiplica las llamadas LIST, las entradas de _delta_log, los escaneos de planificación de OPTIMIZE y la superficie de conflictos de MERGE.

No particiones cuando: la tabla sea inferior a 1 TB; la columna de filtro tenga alta cardinalidad (user_id, event_id: haz clustering en su lugar); los patrones de acceso cambien (el particionado «is static and manifests itself as a filesystem hierarchy. There is no easy way to change partitions», página de mejores prácticas); la columna sea un timestamp que explotaría en millones de instantes (haz clustering del timestamp sin procesar, en su lugar); o fueras a particionar por un campo struct (PARTITIONED BY trata un struct como expresión, no como referencia de columna).

3.1 Ejemplo resuelto E2: el antipatrón de alta cardinalidad, en aritmética

El particionado conserva en 2026 exactamente dos papeles legítimos: movimientos de ciclo de vida a nivel de partición (DELETE/DROP PARTITION sobre una columna de fecha a escala ≥ 100 TB) y el filtrado por partición de Delta Sharing en tablas compartidas: que es también la razón por la que convertir a clustering una tabla compartida y particionada está bloqueada.

---

4. Liquid clustering en profundidad

«Liquid clustering es una técnica de optimización del diseño de datos que reemplaza el particionado de tablas y ZORDER» (docs .../tables/clustering, última actualización 2026-09-25), y «puedes redefinir las claves de clustering sin reescribir los datos existentes». Esa última cláusula es todo el diseño: el particionado hornea una jerarquía de sistema de archivos que no puedes cambiar de forma barata; el clustering almacena un conjunto de claves declaradas en los metadatos de la tabla y deja que OPTIMIZE coloque físicamente los rangos de forma incremental.

4.1 La superficie de declaración y los suelos de DBR

Lleva estos números de versión con sus fechas: son los números que preguntan los exámenes y las revisiones de arquitectura:

4.2 Clustering en la escritura: cómo aterriza el streaming ya agrupado

No tienes que esperar a un job nocturno. Cuando una escritura es lo bastante grande, el clustering se ejecuta durante la escritura, según el número de claves (tablas gestionadas de UC / otras tablas Delta):

Por eso un CTAS o un micro-lote de streaming puede aterrizar físicamente agrupado sin ningún mantenimiento programado, y por eso OPTIMIZE sobre una tabla agrupada suele ser rápido: solo reescribe lo que todavía necesita clustering.

4.3 El ciclo de vida, incluidos los dos momentos caros

Dos momentos de ese diagrama cuestan dinero real y tiempo de calendario real:

⚠️ ADVERTENCIA: declarar claves es gratis; hacer que los datos antiguos las cumpla, no. «The default behavior does not apply clustering to previously written data»: tienes que ejecutar OPTIMIZE <table> FULL, lo cual «might take hours» en una tabla grande sin agrupar (docs de clustering, 2026-09-25). Presupuéstalo como un job de migración puntual en su propio cluster (instancias compute-optimized, spot por la noche), no como un paso de una pipeline de release. Y nunca digas «activar clustering reescribió mi tabla»: ALTER TABLE … CLUSTER BY es metadatos; OPTIMIZE FULL es la reescritura.

⚠️ IMPORTANTE: OPTIMIZE reescribe archivos, así que alimenta a VACUUM. Cada reclustering borra y añade archivos; las versiones antiguas solo sobreviven durante delta.deletedFileRetentionDuration (por defecto 7 días). Fija esa propiedad antes de activar predictive optimization: «If you set delta.deletedFileRetentionDuration to less than 7 days, predictive optimization still retains data files for a minimum of 7 days when it runs VACUUM FULL» (docs de predictive-optimization, 2026-09-11), y nunca ejecutes VACUUM en el mismo paso de job que lectores o streams de larga duración.

4.4 Ejemplo resuelto E3: adoptar clustering en una tabla en producción

¿Por qué un predicado en los pasos 4/5? OPTIMIZE <table> WHERE <predicate> acota la compactación o el reclustering a un subconjunto: más barato, y reduce la ventana de conflicto con escritores concurrentes, la misma razón por la que las mejores prácticas empujan los predicados de poda dentro de MERGE... ON.

• 📚 ¿Sabías que…? DESCRIBE HISTORY es también tu rastro de auditoría del mantenimiento: auto compaction, liquid clustering y Z-ordering «all appear in table history as OPTIMIZE operations», y solo los distingues a través de operationParameters.{auto, clusterBy, zOrderBy, predicate} (docs.../tables/history, 2026-09-11). Un dashboard que cuente «ejecuciones de OPTIMIZE» sobrecuenta por tanto auto compaction: filtra con auto = 'false' para quedarte solo con las ejecuciones manuales.

---

5. Ejemplo resuelto E4: OPTIMIZE frente a CLUSTER BY, lado a lado

Misma tabla, mismos 8 TB, dos generaciones de doctrina de diseño. Esta es la comparación para la que existe el curso.

Qué cambió entre los dos caminos:

Lee esa gráfica como una escalera causal: las escrituras optimizadas y el bin packing (capa 1, tamaño de archivo) te compran una mejora sólida pero acotada, porque la poda todavía no puede demostrar nada; CLUSTER BY (capa 1 y capa 2 a la vez) es lo que hace que el filtro customer_id excluya >95% de los archivos. La última barra está etiquetada como ilustrativa porque es un boceto de arquitectura de referencia constreñido por la banda publicada de 2 to 12× de Databricks, no una cifra de tu tabla: mide la tuya en el query profile.

5.1 Capa 2: por qué el clustering es lo que hace que el skipping funcione

Delta escribe estadísticas por archivo en el momento del commit: «minimum and maximum values, null counts, and total records» (docs de data-skipping, 2026-06-18), y en el momento de la consulta el motor omite cualquier archivo cuyas estadísticas demuestren que el predicado no puede casar. El clustering no cambia qué se puede omitir, «the engine prunes at file granularity. There is no directory-level shortcut to lose» (blog de Databricks, 2026-01-06), cambia cuánto se omite, al hacer que los rangos de la clave sean físicamente contiguos.

El skipping falla en silencio cuando: el predicado no es sargable (WHERE lower(col) = …, WHERE date_add(col, 1) = …); la columna de filtro no tiene estadísticas; los valores están distribuidos de forma uniforme entre todos los archivos; o combinas columnas de un modo que min/max no puede demostrar. Perillas de estadísticas: delta.dataSkippingNumIndexedCols (posicional) y delta.dataSkippingStatsColumns (DBR 13.3 LTS+, lista explícita, reemplaza a la numérica), y «Updating these properties does not automatically recompute statistics for existing data». Por último: «Databricks recomienda que no uses ZORDER BY en columnas que no tengan estadísticas recopiladas, porque es inefectivo y consume recursos de cómputo innecesarios».

---

6. Capa 3, joins: AQE, broadcast, skew y salting

6.1 Los valores por defecto de AQE con los que realmente estás ejecutando

AQE está activo por defecto y hace cuatro cosas: convertir el sort-merge join en broadcast en runtime, coalescer las particiones posteriores al shuffle, dividir (y replicar si hace falta) las particiones con skew, y propagar relaciones vacías (docs de AQE, página fechada el 2023-10-12, todavía vigente en oct 2026).

Regla práctica para dimensionar el shuffle: «cada tarea debería procesar aproximadamente de 128 MB a 200 MB de datos» (guía discover, 2026-05-06). Y mantén AQE activo: «It is recommended to keep AQE enabled» (best-practices, 2026-09-11).

6.2 Ejemplo resuelto E5: un join nocturno de 52 minutos, diagnosticado

El raíl de arreglos equivocados; estos tres aparecen en código de producción y ninguno de ellos ayuda:

• SET spark.sql.shuffle.partitions = 2000: no divide nada; la clave caliente sigue aterrizando en exactamente una partición.
• .repartition("cust_id"): el mismo fallo, más un shuffle extra.
• Un hint de skew cuando AQE ya se disparó: sobrecarga para un arreglo que ya ocurrió; «La optimización de skew join tiene cierta sobrecarga, así que conviene usarla solo cuando sea necesaria» (docs retiradas de skew-join, página actualizada el 2024-05-13).

• 📚 ¿Sabías que…? Puedes leer las decisiones de AQE directamente del plan físico: CustomShuffleReader con la propiedad Coalesced significa que las particiones se fusionaron después del shuffle, SortMergeJoin con isSkew=true significa que AQE dividió una partición caliente, y un LocalTableScan significa que AQE demostró que un lado del join estaba vacío y lo saltó (docs de AQE, 2023-10-12). Tres cadenas que merece la pena buscar en el plan de cualquier consulta lenta antes de cambiar una sola configuración.

---

7. Photon: evalúalo por carga de trabajo, no por eslogan

Photon es el motor vectorizado en C++ que procesa datos en lotes columnares, y «Photon is used by default in Databricks SQL warehouses» (best-practices, 2026-09-11). La evidencia publicada, con sus advertencias incluidas:

Los veredictos por carga de trabajo:

• SQL intenso / BI / dashboards: las mayores ganancias (escaneos, joins y agregaciones vectorizados). Ya activo por defecto en los warehouses de SQL.
• ETL / Spark por lotes: sólidas pero menores; los caminos intensivos en MERGE están dominados en cambio por el low shuffle merge (GA desde DBR 10.4 LTS, «up to 5x … average on the order of 2-3x»).
• Código intenso en Python con UDFs: Photon no puede acelerar la ejecución de Python UDFs: «Serialization is required to transfer data between Python and Spark. This significantly slows down queries» (best-practices). La jugada ganadora es reescribir a SQL nativo (o a pandas UDFs si una UDF es inevitable) primero, Photon después. (Esto es razonamiento a partir de la guía documentada de UDFs, no un benchmark publicado de Python.)
• Bucles de entrenamiento de ML construidos sobre RDDs, gráficos o código a medida: Photon es en su mayor parte irrelevante ahí.

---

8. Capa 4: dimensionamiento del warehouse y las capas de caché

8.1 Resize frente a scale out: dos síntomas, dos perillas

La doctrina de dimensionamiento de Databricks (docs de warehouse-behavior, consultadas 2026-10; blog de alta concurrencia, 2025-02-09): resize cuando las consultas necesitan más memoria por consulta (agregaciones, joins de varias tablas: vigila el desborde a disco); scale out cuando las consultas esperan (vigila el encolamiento). «If queries are spilling to disk, increase the cluster size. Check for spills in the query profile.» Los warehouses classic y pro tienen «a fixed limit of one cluster per 10 concurrent queries», la profundidad de la cola está limitada con dureza a 1,000 consultas para todo tipo de warehouse, y un umbral práctico de alerta es peak queued queries > 10 que no se resuelve cuando se dispara el autoscaling.

8.2 Ejemplo resuelto E6: dimensionar un warehouse de 60 analistas

Para la mayoría de las cargas de trabajo «Databricks recommends using a serverless SQL warehouse», y su consejo de dimensionamiento es contraintuitivo pero correcto: «Start with a single larger warehouse and let serverless features manage concurrency and performance. It is usually more efficient to size down if necessary than to start small and scale up.»

8.3 Cuatro cachés, cuatro vidas útiles

Reglas que previenen los bugs clásicos de caché: el caché de resultados necesita consultas deterministas, un predicado al estilo NOW() nunca le da; SET use_cached_result = false lo salta (solo para pruebas y benchmarks); la caché de disco «funciona de forma predeterminada con todos los tipos de instancia que tienen SSD locales», y en cómputo classic eso significa elegir workers con SSD; «En los warehouses de SQL y en Databricks Runtime 14.2 o superior, el comando CACHE SELECT se ignora», se usa en su lugar la caché de disco mejorada.

⚠️ ADVERTENCIA, la Spark cache es la trampa, no el valor por defecto. «using incorrect locations in a query can consume all available memory and significantly slow down queries. As a rule of thumb, avoid Spark caching» (best-practices, 2026-09-11), y la página de mejores prácticas de Delta dice sin rodeos «No uses la caché de Spark con Delta Lake» (actualizada 2026-09-11). Los DataFrames en caché se comen la memoria de los executors que luego hacen shuffle y se desbordan a disco, la firma inconfundible es un desborde que sube mientras la pestaña Storage muestra grandes bloques en caché. Los usos legítimos son estrechos: un dataset no-Delta verdaderamente inmutable y escaneado repetidamente dentro de una misma sesión, siempre acompañado de unpersist(); más el precalentamiento de un cluster frío antes de la mañana punta.

• 📚 ¿Sabías que…? La caché de disco es la Delta cache renombrada: «The disk cache (formerly known as 'Delta cache') stores copies of remote data on the local disks (for example, SSD) of the virtual machines… The recommended (and easiest) way to use disk caching is to choose a worker type with SSD volumes» (best-practices, 2026-09-11). Y como el autoscaling retira workers, «si el autoscaling está activado, hay cierta inestabilidad en la caché»: los clusters de job sensibles a la caché quieren un scale-down conservador o pools.

---

9. Profiling: el query profile y la Spark UI

El profiling es lo que convierte la pila en un bucle y no en una lista de verificación. Elige la herramienta según el tipo de cómputo: query profile para warehouses de SQL y serverless, Spark UI para clusters clásicos y de jobs.

Qué te dice cada señal, y la única respuesta documentada:

Dos detalles de acceso que te ahorran un ticket de soporte: el acceso al profile requiere ser propietario de la consulta «or at least CAN MONITOR permission on the SQL warehouse», y «El query profile no está disponible para consultas que se ejecutan desde la caché de resultados. Para saltarte la caché de resultados, haz un cambio trivial en la consulta, como cambiar o quitar el LIMIT.»

9.1 Ejemplo resuelto E7: dimensionar spark.sql.shuffle.partitions en papel

Una salvedad de streaming: spark.sql.shuffle.partitions «no se puede cambiar entre reinicios de la consulta desde la misma ubicación del checkpoint» (docs de AQE): elígelo antes del primer arranque de una consulta de streaming.

• 📚 ¿Sabías que…? Una consulta servida desde la caché de resultados no tiene query profile en absoluto: «Query profile is not available» en la UI suele significar tu consulta fue rápida porque estaba en caché, no que el profiling esté roto. Durante benchmarks, SET use_cached_result = false (docs.../query-caching, consultadas 2026-10), y mantén fuera de las consultas de BI que quieras en caché en producción cualquier no-determinismo al estilo NOW().

---

10. La capa de automatización: predictive optimization y materialized views

Dos funciones de 2026 te quitan trabajo del runbook, pero solo si sabes qué es lo que reemplazan.

Predictive optimization «automatically runs OPTIMIZE, VACUUM, and ANALYZE on Unity Catalog managed tables (Delta Lake and Iceberg)», está «enabled by default for accounts created on or after November 11, 2024» con el despliegue gradual de las cuentas existentes «expected to complete by August 2026», se ejecuta en cómputo serverless facturado como un SKU de jobs serverless, y, la trampa, «OPTIMIZE does not run ZORDER when executed by predictive optimization. On tables that use Z-order, predictive optimization ignores Z-ordered files.» Se aplica solo a tablas gestionadas; con las tablas externas sigues en la escalera manual de las secciones 2 to 4. Obsérvalo con DESCRIBE TABLE EXTENDED … AS JSON → predictive_optimization_evaluations, con el filtro «Automatic runs» del History del Catalog Explorer, o con system.storage.predictive_optimization_operations_history.

Materialized views son la contraparte de la capa de servicio: «una vista donde los resultados precalculados están disponibles para la consulta y pueden actualizarse para reflejar cambios en la entrada. Todas las materialized views están respaldadas por una pipeline de ETL», creadas «using a Pro or Serverless SQL warehouse, or within a pipeline», refrescadas por pipelines de Lakeflow serverless, con la salida en caché materializada en almacenamiento en la nube. La elegibilidad para el refresco incremental es comprobable antes de comprometerte: EXPLAIN CREATE MATERIALIZED VIEW … (DBR 17.3+) informa «La materialized view puede refrescarse de forma incremental» o no: un filtro, una proyección o una agregación sobre Delta califica; LIMIT y las fuentes que no son Delta (INPUT_NOT_IN_DELTA) no, y una expectation dentro de la definición fuerza un refresco completo. Tanto las materialized views como las streaming tables admiten liquid clustering: «Liquid clustering applies to both streaming tables and materialized views.»

---

11. Las trampas: dieciséis confusiones que esta lección no te dejará conservar

1. «El tamaño de archivo objetivo es 1 GiB.» El OPTIMIZE manual se limita a 1 GiB; auto-optimize apunta a 128 MB; autotune elige 256 MB por debajo de 2.56 TB. Compactar una tabla de 300 GB en archivos de 1 GiB perjudica el paralelismo del escaneo podado.
2. Dar por sentado que las tablas gestionadas necesitan rituales manuales de OPTIMIZE. Autotune + predictive optimization las poseen; un cron nocturno paga dos veces.
3. Particionar una tabla de 50 GB «para mejorar el rendimiento». Por debajo de 1 TB no deberías particionar en absoluto, y cada partición necesita ≥ 1 GB.
4. ZORDER sobre una columna sin estadísticas, o esperar que las tablas con ZORDER sigan mantenidas bajo predictive optimization («ignores Z-ordered files»).
5. Cambiar las claves de clustering y esperar resultados instantáneos. Necesitas OPTIMIZE FULL, y «might take hours» en una tabla grande sin agrupar.
6. Demasiadas claves de clustering o de cardinalidad demasiado alta. Máximo 4; por debajo de 10 TB las claves extra degradan los filtros de una sola columna; las claves jerárquicas deberían ser de baja cardinalidad.
7. El intercambio VACUUM ↔ clustering. Cada reclustering borra y añade; fija delta.deletedFileRetentionDuration antes de activar predictive optimization (suelo de 7 días), y nunca hagas vacuum junto a lectores de larga duración.
8. coalesce(n)/repartition(n) justo antes de una escritura con las escrituras optimizadas activas: dos shuffles, un job.
9. Un autoOptimize.autoCompact = false a nivel de sesión del que te olvidaste: obligatorio para MERGE/UPDATE/DELETE, silenciosamente desactivado en tus appends.
10. spark.sql.shuffle.partitions = 2000 «porque el valor por defecto es demasiado bajo». La regla es 128 to 200 MB por tarea; con AQE prefiere auto o empieza alto y deja que el coalescing fusione.
11. Llegar a un hint de skew cuando AQE ya lo gestiona, o hacer salting antes de probar el broadcast. Si un lado cabe en 10/30 MB, un hint BROADCAST elimina el shuffle: estrictamente mejor que dividirlo.
12. Abuso de la Spark cache. «As a rule of thumb, avoid Spark caching»; «No uses la caché de Spark con Delta Lake».
13. Confusión con la caché de resultados durante la depuración. Una consulta en caché no tiene profile; la latencia del dashboard puede ser latencia de caché.
14. Leer el skew solo con el tiempo de pared. El test es Max > 1.5× p75 en Summary Metrics, no «el job se sintió lento».
15. Dar por sentado que Photon arregla las pipelines de Python UDF. La serialización manda; reescribe a SQL nativo primero.
16. Ejecutar OPTIMIZE … ZORDER BY sobre doce columnas, a mitad del día, en el cluster interactivo. Técnica heredada, hora equivocada, cluster equivocado: usa clustering, un job cluster de spot separado y un horario.

---

Veredicto comparativo: particionado tradicional + ZORDER frente a liquid clustering (AWS, a oct 2026)

• Particionado tradicional + ZORDER: el manual de 2019 to 2023, hoy heredado. Declaras una jerarquía de directorios al estilo Hive (PARTITIONED BY (event_date)) para la poda, y después ejecutas periódicamente OPTIMIZE … ZORDER BY (hot_col) para colocalizar una columna no particionada entre archivos. Funciona, y a ≥ 100 TB con una clave de fecha genuinamente de baja cardinalidad, el particionado todavía puede compensar en los DELETE/DROP a nivel de partición y en el filtrado por partición de Delta Sharing. Los costes: la jerarquía es «static … no easy way to change partitions»; ZORDER es una reescritura que «is not idempotent but is incremental» y la rompe MERGE (el low shuffle merge la amortigua, pero no la elimina); ZORDER necesita estadísticas o es «ineffective and a waste of resources»; las columnas de alta cardinalidad no pueden ser claves de partición en absoluto; y: el clavo operativo: predictive optimization nunca ejecuta ZORDER y «ignores Z-ordered files», así que las tablas heredadas con ZORDER dejan de mantenerse en silencio.
• Liquid clustering: el valor por defecto documentado para todas las tablas nuevas. CLUSTER BY (hasta 4 claves, estadísticas requeridas, protocolo 3/7) es solo metadatos al declararlo o cambiarlo; el clustering en la escritura hace que el tráfico de CTAS y de streaming aterrice pre-agrupado con umbrales de 64 MB/256 MB/512 MB/1 GB (gestionadas); OPTIMIZE hace después el clustering y el bin packing juntos, de forma incremental, idempotente, con una cadencia de 1 to 2 horas para tablas activas; CLUSTER BY AUTO deja que la plataforma elija las claves con conciencia del coste; y predictive optimization lo mantiene por ti. Evidencia: clustering 2.5× más rápido que Z-order en una carga de trabajo de warehouse de 1 TB con el particionado Hive «an order of magnitude slower» (blog, 2023-06-29), consultas puntuales hasta 12× y lecturas 2 to 12× en GA (blog, 2024-05-22). Los costes: un OPTIMIZE FULL puntual cuando las claves se declaran o cambian (horas en una tabla grande), incompatibilidad con el particionado y el ZORDER existentes, y un techo de 4 claves.
• Veredicto en una línea: tabla nueva → CLUSTER BY (o CLUSTER BY AUTO en una tabla gestionada) con predictive optimization activado; tabla existente particionada o con ZORDER → migra con ALTER TABLE … REPLACE PARTITIONED BY WITH CLUSTER BY (18.1+) más un OPTIMIZE FULL, conservando el particionado solo donde una tabla ≥ 100 TB necesite genuinamente movimientos de ciclo de vida a nivel de partición o sharing filtrado por partición. Cada número de versión de esa frase está fechado en la sección 4.1; lleva las fechas, no solo los números.

---

Actualizaciones de 2026 (en octubre de 2026)

---

Estudios de caso reales

📋 Caso A: Comcast (comunicaciones y medios, Cloud: AWS) El reto. Petabytes de telemetría y miles de millones de interacciones de voz de más de 20M de mandos de voz, con pipelines frágiles, dolor de ingestión por archivos pequeños y cientos de modelos a desplegar en la nube, on-prem y edge. Stack en AWS. Databricks, Delta Lake para ingest/enrich/optimize small files, MLflow gestionado, autoscaling + spot instances, notebooks, Tableau aguas abajo: Cloud: AWS en la página de la historia. Resultado informado. «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»; el despliegue de modelos pasó de «weeks to minutes» (https://www.databricks.com/customers/comcast, página sin fecha, consultada 2026-10). Comcast también aparece entre los clientes «already leveraging Databricks on AWS» en el comunicado de prensa de Databricks sobre AWS Marketplace (2022-05-10), y su telemetría RDK se describe como «petabytes of data, collected every 15 minutes from 70 million devices» (databricks.com/blog, 2021-05-10). Qué mapea a esta lección. Secciones 2 y 8: el titular es una ganancia estructural: el manejo de archivos de Delta hundió 640 máquinas a 64 antes de cualquier ajuste de consultas, que es exactamente el orden de «primero la capa 1» que enseña esta lección, más spot instances para la ventana de compactación. ⏳ Nota temporal: origen de la historia 2019, página sin fecha consultada en oct 2026: un resultado de cliente informado, no una garantía de 2026.

📋 Caso B: Rivian (vehículos eléctricos, Cloud: AWS) El reto. Más de 70,000 vehículos en circulación «generating terabytes of data every day», con herramientas heredadas que «struggled to scale pipelines cost-effectively», alimentando el ML de mantenimiento predictivo y de predicción de carga. Stack en AWS. Databricks SQL, Delta Lake, Unity Catalog, y, explícitamente, «Liquid Clustering for data layout» junto a «Unity Catalog for data governance, Delta Tables for storage» para el ML de predicción de carga en tiempo real (databricks.com/blog, 2025-07-09); Cloud: AWS en la página de la historia. Resultado informado. «50% better runtime performance» (https://www.databricks.com/your-ai/customers/rivian, 2024-05-30); «1,000+ platform users, a 75% increase from a year ago» (https://www.databricks.com/customers/rivian, sin fecha, consultada 2026-10). Qué mapea a esta lección. Secciones 4 y 5: Rivian es el ejemplo con nombre en AWS de la palanca exacta que ejercita el ejemplo resuelto E4 de esta lección: la telemetría de vehículos es de alta cardinalidad, crece rápido y se consulta por columnas de filtro, que es la lista de mejor encaje documentada para el clustering («Consultas que filtran por columnas de alta cardinalidad», «Fast growing tables», «Tables with varied or changing access patterns»). ⏳ Nota temporal: la cifra del 50% es de 2024-05-30; la mención del stack con liquid clustering es de 2025-07-09.

📋 Caso C: Punchh (fidelización de retail / tecnología de restauración, Cloud: AWS) El reto. Había crecido más allá de su AWS MySQL, un almacén de datos demasiado costoso de mantener, y los informes de Tableau lentos por joins ejecutados de cero en cada informe: «Cuando haces join de 12 tablas sobre la marcha cada vez que un cliente ejecuta un informe, el costo de generar el informe puede ser alto.» Stack en AWS. Databricks SQL, Delta Lake bronze/silver/gold, notebooks, Tableau encima: Cloud: AWS en la página de la historia. Resultado informado. «10x Faster time-to-insight · 30% Lower operational costs · 12% Increase in customer satisfaction» (https://www.databricks.com/customers/punchh, página sin fecha, consultada 2026-10; origen de la historia 2021). Qué mapea a esta lección. Secciones 8 y 10: el join más barato es el que no ejecutas: una tabla gold pre-joinada (o una materialized view con refresco incremental) gana tanto a un join de 12 vías en el momento del informe como a cualquier resize de warehouse que lo habría forzado a pulso. ⏳ Nota temporal: historia de 2021 que sigue mostrándose en 2026: enseña el mecanismo y fecha las métricas.

---

---

Preguntas de Práctica (Practice Questions)