Diseño e implementación de una estrategia de agrupación en clústeres

Optimizar la forma en que los datos se organizan físicamente en el disco afectan directamente al rendimiento de las consultas y a la eficiencia del almacenamiento. Al diseñar una estrategia de agrupación en clústeres para las tablas de Delta Lake, se determina cómo el motor de consultas localiza y recupera los datos pertinentes. El enfoque correcto puede reducir drásticamente la cantidad de datos examinados durante las consultas, lo que reduce los tiempos de respuesta y los costos de proceso.

Azure Databricks proporciona varias técnicas complementarias para la organización de datos. Comprender cuándo aplicar clústeres líquidos, ordenación Z o vectores de eliminación le ayuda a tomar decisiones que equilibran el rendimiento, el esfuerzo de mantenimiento y la compatibilidad con las tablas existentes.

Entender los fundamentos de la omisión de datos

Antes de examinar técnicas de agrupamiento específicas, es importante comprender el mecanismo subyacente que todas ellas aprovechan: omisión de datos. Delta Lake recopila automáticamente las estadísticas de cada archivo de datos, incluidos los valores mínimos y máximos, los recuentos nulos y los recuentos de registros de cada columna. Al ejecutar una consulta con condiciones de filtro, el motor de consultas comprueba primero estas estadísticas y omite los archivos que posiblemente no pueden contener registros coincidentes.

Por ejemplo, si consulta los datos de ventas de enero de 2026, y las estadísticas de un archivo determinado muestran que solo contiene registros de marzo de 2026, el motor omite ese archivo por completo sin leer su contenido. Esta optimización se produce automáticamente, pero su eficacia depende de la organización de los datos.

La omisión de datos se vuelve poderosa cuando los registros relacionados se almacenan juntos en los mismos archivos. Si los registros de cada mes se dispersan aleatoriamente en todos los archivos, el motor no puede omitir ningún archivo porque cada archivo contiene registros de cada mes. Existen técnicas de agrupación en clústeres para resolver exactamente este problema.

Implementación de clústeres líquidos para nuevas tablas

La agrupación líquida es el enfoque recomendado para organizar los datos en nuevas tablas de Delta Lake y también está disponible en vista previa pública para las tablas de Apache Iceberg administradas en el Catálogo de Unity (Databricks Runtime 16.4 LTS y versiones posteriores). A diferencia de la creación de particiones tradicionales, la agrupación en clústeres líquidos permite cambiar la estrategia de agrupación en clústeres sin volver a escribir los datos existentes. Esta flexibilidad es valiosa cuando los patrones de consulta evolucionan o cuando no está seguro de qué columnas se filtrarán con más frecuencia.

Para habilitar la agrupación en clústeres líquidos, use la CLUSTER BY cláusula al crear una tabla:

CREATE TABLE sales.transactions (
    transaction_id STRING,
    customer_id STRING,
    product_category STRING,
    region STRING,
    transaction_date DATE,
    amount DECIMAL(12,2)
)
CLUSTER BY (region, transaction_date);

Puede especificar hasta cuatro claves de agrupación en clústeres. Elija columnas que aparecen con frecuencia en los filtros de consulta. El orden de las claves de agrupación en clústeres es menor que seleccionar las columnas correctas, ya que la agrupación en clústeres líquidos se optimiza para todas las claves especificadas simultáneamente.

Después de crear una tabla en clúster, ejecute el OPTIMIZE comando para aplicar la agrupación en clústeres a los datos:

OPTIMIZE sales.transactions;

La agrupación en clústeres líquidos es incremental. Cada OPTIMIZE ejecución solo agrupa los datos que necesitan reorganización, lo que hace que el mantenimiento normal sea eficaz. Databricks recomienda programar OPTIMIZE trabajos cada una o dos horas para tablas con inserciones o actualizaciones frecuentes.

Cambio de las claves de agrupación en clústeres cuando sea necesario

Una ventaja importante de la agrupación en clústeres líquidos sobre la creación de particiones es la capacidad de modificar la estrategia de agrupación en clústeres. Si cambian los patrones de consulta, actualice las claves de agrupación con la instrucción ALTER TABLE.

ALTER TABLE sales.transactions
CLUSTER BY (customer_id, transaction_date);

Las operaciones posteriores OPTIMIZE usan el nuevo enfoque de agrupación en clústeres. Los datos escritos anteriormente no se vuelven a escribir automáticamente. Para aplicar una nueva agrupación en clústeres a todos los datos existentes, ejecute:

OPTIMIZE sales.transactions FULL;

Habilitación de la selección automática de claves de agrupación en clústeres

Azure Databricks puede seleccionar de forma inteligente las claves de agrupación en clústeres en función de los patrones de consulta reales. La agrupación automática de líquidos analiza el historial de carga de trabajo y elige las columnas que brindan el mayor beneficio de omisión de datos:

CREATE TABLE sales.orders CLUSTER BY AUTO;

Puede habilitar la agrupación automática en clústeres en tablas existentes:

ALTER TABLE sales.transactions CLUSTER BY AUTO;

La agrupación automática en clústeres líquidos requiere que se habilite la optimización predictiva. Azure Databricks evalúa periódicamente si diferentes claves de agrupación en clústeres mejorarían el rendimiento y ajusta la estrategia en consecuencia.

Migración desde el orden Z a la agrupación en clústeres líquidos

El orden Z es una técnica heredada que organiza los datos para colocar información relacionada en los mismos archivos. Aunque se recomienda la agrupación en clústeres líquidos para las nuevas tablas, encontrará tablas existentes que usan el orden Z y necesitan comprender ambos enfoques.

El orden Z usa el OPTIMIZE comando con una ZORDER BY cláusula :

OPTIMIZE sales.legacy_transactions
ZORDER BY (region, transaction_date);

El orden Z difiere de la agrupación en clústeres líquidos de varias maneras importantes:

Al heredar una tabla ordenada por Z, tiene dos opciones. Siga usando el orden Z para la coherencia o migre a la agrupación en clústeres líquidos para mejorar la flexibilidad. Para migrar, primero habilite la agrupación en clústeres líquidos en la tabla no particionada existente:

ALTER TABLE sales.legacy_transactions
CLUSTER BY (region, transaction_date);

A continuación, ejecute una optimización completa para reorganizar todos los datos existentes:

OPTIMIZE sales.legacy_transactions FULL;

Administración de vectores de eliminación para actualizaciones eficaces

Los vectores de eliminación abordan un aspecto diferente de la organización de datos: cómo Delta Lake controla los registros modificados o eliminados. De forma predeterminada, al actualizar o eliminar una sola fila en un archivo Parquet, Delta Lake debe volver a escribir todo el archivo. En el caso de las tablas con modificaciones frecuentes, esto crea una sobrecarga significativa.

Con los vectores de eliminación habilitados, Delta Lake marca las filas modificadas como eliminadas en un archivo de metadatos independiente en lugar de volver a escribir el archivo Parquet inmediatamente. Las lecturas posteriores aplican estas eliminaciones sobre la marcha, combinando el archivo original con el vector de eliminación para devolver resultados precisos.

Los vectores de eliminación están habilitados de forma predeterminada para las nuevas tablas creadas con Databricks Runtime 14.1 o superior. Puede habilitarlas explícitamente en tablas existentes:

ALTER TABLE sales.transactions
SET TBLPROPERTIES ('delta.enableDeletionVectors' = true);

Los vectores de eliminación se aplican físicamente cuando los archivos de datos se vuelven a escribir durante:

• Un OPTIMIZE comando
• Desencadenadores de compactación automática
• Una REORG TABLE ... APPLY (PURGE) operación

Para escenarios de cumplimiento en los que debe asegurarse de que los datos eliminados se quitan físicamente, ejecute una REORG operación seguida de VACUUM:

REORG TABLE sales.transactions APPLY (PURGE);
VACUUM sales.transactions;

Los vectores de eliminación también permiten la simultaneidad de nivel de fila, lo que permite que varias transacciones simultáneas modifiquen filas diferentes en la misma tabla sin conflictos. Esta funcionalidad es especialmente valiosa para las tablas con volúmenes de actualización elevados.