Tuning Delta

Photon es el motor vectorizado nativo de Databricks. Catalyst sigue generando el plan, mientras Photon ejecuta operadores compatibles en lotes columnares y usa un runtime C++ que reduce costes de JVM. Está habilitado en serverless y SQL warehouses, y por defecto en compute clásico moderno; acelera scans, joins, agregaciones, shuffles y escrituras compatibles sin exigir reescribir SQL o DataFrames.

No toda consulta mejora igual. UDFs, RDDs, APIs Dataset y operaciones no compatibles pueden ejecutar partes en Spark, y consultas subsegundo suelen estar dominadas por planificación. En Spark UI los operadores Photon se distinguen en el DAG; en Query Profile se observa el porcentaje de tiempo. Evalúa duración, task time, datos leídos y coste total, no sólo que la casilla esté activada.

SELECT
  order_date,
  customer_segment,
  SUM(net_amount) AS net_revenue,
  COUNT(DISTINCT order_id) AS orders
FROM prod.gold.sales
WHERE order_date >= current_date() - INTERVAL 30 DAYS
GROUP BY order_date, customer_segment;

Delta registra estadísticas por archivo para que el motor descarte archivos cuyo rango no puede satisfacer el filtro. El skipping funciona cuando las columnas consultadas tienen estadísticas útiles y los valores están organizados de forma que distintos archivos cubren rangos discriminantes. Un filtro muy selectivo no ayuda si todos los archivos contienen casi todo el rango de la columna.

En tablas Unity Catalog administradas, predictive optimization puede recopilar estadísticas automáticamente. Si cambias las columnas de estadísticas, `ANALYZE TABLE ... COMPUTE DELTA STATISTICS` recalcula la información del log; las estadísticas del optimizador se actualizan con `ANALYZE TABLE ... COMPUTE STATISTICS`. Verifica en Query Profile bytes leídos y porcentaje podado, no sólo el tiempo caliente de una segunda ejecución.

ALTER TABLE prod.gold.orders
SET TBLPROPERTIES ('delta.dataSkippingStatsColumns' = 'order_date,customer_id');

ANALYZE TABLE prod.gold.orders COMPUTE DELTA STATISTICS;
ANALYZE TABLE prod.gold.orders COMPUTE STATISTICS;

SELECT *
FROM prod.gold.orders
WHERE order_date = DATE '2026-07-20'
  AND customer_id = 184203;

Liquid clustering reemplaza particionado y `ZORDER` para tablas nuevas que necesitan layout flexible. `CLUSTER BY` define claves y las operaciones de mantenimiento reagrupan datos incrementalmente. Las claves pueden evolucionar sin reescribir inmediatamente toda la tabla; lecturas y escrituras requieren versiones compatibles del runtime y no debes mezclar la tabla con particionado tradicional o `ZORDER`.

Automatic liquid clustering usa predictive optimization para escoger y evolucionar claves cuando el ahorro esperado por skipping supera el coste de clustering. La decisión práctica parte de consultas observadas: filtros por fecha y cliente pueden justificar claves, mientras una columna de cardinalidad extrema sin patrón estable puede empeorar mantenimiento. Valida en historial y perfiles qué archivos se podan.

CREATE TABLE prod.gold.customer_orders (
  order_id BIGINT,
  customer_id BIGINT,
  order_date DATE,
  net_amount DECIMAL(18,2)
)
USING DELTA
CLUSTER BY (order_date, customer_id);

INSERT INTO prod.gold.customer_orders
SELECT order_id, customer_id, order_date, net_amount
FROM prod.silver.orders;

Sin deletion vectors, modificar pocas filas puede obligar a reescribir archivos Parquet completos. Con la característica activada, Delta registra qué filas están lógicamente eliminadas y difiere la reescritura física. Photon puede usar predictive I/O para acelerar actualizaciones y lecturas compatibles; el protocolo de tabla se eleva, por lo que todos los clientes externos deben soportarlo.

Los vectores no eliminan mantenimiento: operaciones posteriores materializan cambios cuando conviene, y `VACUUM` sigue gobernado por retención. También habilitan row-level concurrency en tablas elegibles, reduciendo conflictos entre escrituras sobre filas distintas. Desactivarlos por costumbre puede perder concurrencia; activarlos sin inventariar lectores externos puede romper interoperabilidad.

ALTER TABLE prod.silver.customers
SET TBLPROPERTIES ('delta.enableDeletionVectors' = true);

DESCRIBE DETAIL prod.silver.customers;

DELETE FROM prod.silver.customers
WHERE deletion_requested_at < current_date() - INTERVAL 30 DAYS;

Predictive optimization observa tablas administradas por Unity Catalog y ejecuta mantenimiento donde estima beneficio: compacta y aplica clustering con `OPTIMIZE`, elimina archivos no referenciados con `VACUUM` y mantiene estadísticas mediante `ANALYZE`. Puede habilitarse en cuenta, catálogo, esquema o tabla, con herencia; las tablas externas quedan bajo responsabilidad del propietario.

Automatizar no significa perder control. Revisa la propiedad efectiva con `DESCRIBE ... EXTENDED`, el historial de operaciones y el coste atribuido a `PREDICTIVE_OPTIMIZATION` en `system.billing.usage`. Evita jobs cron que ejecutan `OPTIMIZE` sobre todas las tablas sin observar necesidad: compiten con la automatización y pueden gastar más que el beneficio obtenido.

ALTER CATALOG prod ENABLE PREDICTIVE OPTIMIZATION;

DESCRIBE CATALOG EXTENDED prod;
DESCRIBE TABLE EXTENDED prod.gold.orders;

SELECT operation, operationParameters, operationMetrics, timestamp
FROM (DESCRIBE HISTORY prod.gold.orders)
ORDER BY timestamp DESC
LIMIT 20;