Saltar al contenido
Lakehouse LabLakehouse LabPreparación Databricks Data Engineer
Módulo 24 · Lección

Particionado y sus límites

Contenido abierto

Puedes leer todo sin registrarte. Solo crearemos un perfil anónimo cuando decidas guardar tu progreso.

Lección 3 de 5

Particionado y sus límites

Usa liquid clustering para adaptar el layout a patrones de acceso cambiantes sin heredar la rigidez de particiones físicas de alta cardinalidad.

Duración
17 min aprox.
Objetivo
Usa liquid clustering para adaptar el layout a patrones de acceso cambiantes sin heredar la rigidez de particiones físicas de alta cardinalidad.
Siguiente paso
Continuar con la siguiente lección
Ver detalles del módulo

Photon, data skipping y liquid clustering

Diseña layout y mantenimiento de tablas según patrones de consulta que cambian con el tiempo.

Al terminar podrás
  • Interpretar data skipping y pruning
  • Elegir liquid clustering
  • Explicar deletion vectors, Photon y predictive optimization
Ver fuentes y revisión

Metadatos editoriales

Última revisión
21 jul 2026
Nivel
Professional
Ruta relacionada
performance
Dominios blueprint
Delta optimization · Performance
Estado
Revisión editorial interna
Fuentes principales
What is Photon? · Use liquid clustering for tables
Reportar un error
03
Operación

Particionado y sus límites

Usa liquid clustering para adaptar el layout a patrones de acceso cambiantes sin heredar la rigidez de particiones físicas de alta cardinalidad.

Mostrar prerrequisitos
Dificultad
Professional
Prerrequisitos
m23
Reportar un error en esta lección

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.

Modelo mental

Liquid clustering separa la identidad lógica de una tabla de su organización física. En lugar de fijar directorios de partición que cada fila debe habitar para siempre, declara unas claves de clustering y deja que OPTIMIZE organice incrementalmente archivos para favorecer data skipping. Las claves pueden cambiar sin reescribir de inmediato todo el histórico; los datos nuevos y las futuras optimizaciones siguen la nueva intención. Esto hace el layout adaptable a cardinalidad alta, skew y consultas cambiantes. No significa que una declaración reordene instantáneamente los archivos existentes: activar o cambiar claves establece una política futura, y sólo el trabajo de clustering, automático o explícito, materializa gradualmente el beneficio.

Clave de clustering

Columna declarada como señal para agrupar físicamente valores en archivos sin crear directorios de partición.

Mejora data skipping y puede cambiar conforme evoluciona el patrón de consulta.
Clustering incremental

Reescritura sólo de archivos que requieren reorganización durante operaciones de optimización.

Evita reclasificar toda la tabla en cada ejecución y hace viable el mantenimiento continuo.
OPTIMIZE FULL

Modo que fuerza reclustering más amplio de datos existentes en tablas liquid-clustered compatibles.

Materializa nuevas claves históricamente, pero su coste exige una razón y ventana operacional claras.
SQLCrear una tabla con liquid clustering
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;

Elige claves a partir de filtros reales; habilitar clustering no garantiza beneficio si las consultas no podan por esas columnas.

Puntos clave

  • Liquid clustering admite evolución de claves sin redefinir particiones físicas.
  • No combines `CLUSTER BY` con `PARTITIONED BY` o `ZORDER` en la misma estrategia.
  • Automatic liquid clustering requiere predictive optimization.

Evita

  • Replicar la antigua columna de partición como clave sin revisar el historial de consultas.
  • Ejecutar mantenimiento manual agresivo mientras predictive optimization ya gestiona la tabla.

Recuerdo activo

¿Qué ventaja ofrece cambiar claves de liquid clustering frente a cambiar particiones tradicionales?

Borrador privado · solo en este navegador
5 lecciones pendientes

Vista de lectura · sin ejecución

Photon.py

Learn Databricks · commit 08c378c

Photon.py