Delta Lake liquid clustering

En el Radar compartido: Trial (valoración de la edición aportada).

Cómo funciona

El clustering permite evolucionar las claves y optimizar archivos incrementalmente. Sustituye el particionado convencional y Z-ordering en las tablas que lo utilizan.

Ejemplo de uso

En un motor compatible, definir CLUSTER BY (cliente_id, fecha) y ejecutar OPTIMIZE según el volumen de cambios. Comparar bytes escaneados y latencia frente a la tabla anterior.

CREATE TABLE transacciones_demo (
  cliente_id STRING, fecha DATE, importe DECIMAL(18, 2)
) USING DELTA CLUSTER BY (cliente_id, fecha);

OPTIMIZE transacciones_demo;

Comparación con las alternativas

Técnica	Cómo organiza	Limitaciones
Particionado (PARTITIONED BY)	Un directorio por valor de la columna	Alta cardinalidad crea millones de archivos pequeños; cambiar la columna exige reescribir
Z-ORDER	Reordena archivos dentro de particiones por varias columnas	OPTIMIZE ZORDER reescribe mucho; no incremental
Liquid clustering	Agrupa datos por claves de clustering de forma incremental	Requiere versiones de protocolo y motores compatibles

Operaciones habituales

-- Crear con clustering
CREATE TABLE pagos (credito_id STRING, fecha_pago DATE, importe DECIMAL(18,2), canal STRING)
USING DELTA CLUSTER BY (credito_id, fecha_pago);

-- Cambiar las claves sin reescribir los datos existentes
ALTER TABLE pagos CLUSTER BY (fecha_pago, canal);

-- Agrupar los datos nuevos (incremental) o recalcular todo tras cambiar claves
OPTIMIZE pagos;
OPTIMIZE pagos FULL;

-- Convertir una tabla existente sin particiones
ALTER TABLE eventos CLUSTER BY (servicio, fecha);

-- Desactivar
ALTER TABLE pagos CLUSTER BY NONE;

-- Comprobar las columnas de clustering
DESCRIBE DETAIL pagos;

En Databricks, CLUSTER BY AUTO con predictive optimization elige y ajusta las claves a partir del historial de consultas.

Elegir las claves

• Columnas usadas con más frecuencia en filtros (WHERE) y joins, analizando el historial de consultas.
• Hasta cuatro columnas; más reduce la eficacia.
• El orden importa menos que con Z-ORDER, pero conviene empezar por la más selectiva en las consultas.
• Columnas de alta cardinalidad son válidas (a diferencia del particionado).
• Las claves deben tener estadísticas recogidas (por defecto, en las primeras columnas de la tabla).

Medir el efecto

-- Antes y después: bytes y archivos leídos por una consulta representativa
SELECT sum(importe) FROM pagos WHERE credito_id = 'CR-000042' AND fecha_pago >= '2026-01-01';

Compara en el perfil de la consulta los archivos podados (files pruned), bytes leídos y duración. Programa OPTIMIZE según el volumen de escrituras, o delega en la optimización automática si la plataforma la ofrece.

Compatibilidad

Liquid clustering no puede combinarse con particionado ni Z-ORDER en la misma tabla. Habilitarlo actualiza las características del protocolo de la tabla: todos los lectores y escritores (Spark, Trino, Delta Sharing, conectores) deben soportarlas. En Apache Iceberg, el equivalente aproximado son el particionado oculto y los sort orders con compactación.

Criterios de implementación

Revisar requisitos de lectura y escritura de todos los motores. La selección automática de claves es una capacidad de Databricks con requisitos propios; no asumir equivalencia con Delta Lake abierto.