Comparteix via

Procedimientos recomendados: Delta Lake

En este artículo se describen los procedimientos recomendados al usar Delta Lake.

Introducción a los procedimientos recomendados

A continuación se muestran recomendaciones generales que se aplican a la mayoría de las cargas de trabajo de Delta Lake:

Eliminación de configuraciones Delta heredadas

Databricks recomienda quitar las configuraciones Delta heredadas más explícitas de las configuraciones de Spark y las propiedades de tabla al actualizar a una nueva versión de Databricks Runtime. Las configuraciones heredadas pueden impedir que se apliquen nuevas optimizaciones y valores predeterminados presentados por Databricks a las cargas de trabajo migradas.

Archivos compactos

La optimización predictiva ejecuta automáticamente los comandos OPTIMIZE y VACUUM en las tablas administradas por Unity Catalog. Consulte Optimización predictiva para tablas administradas de Unity Catalog.

Databricks recomienda ejecutar con frecuencia el comando OPTIMIZE para compactar archivos pequeños.

Nota:

Esta operación no quita los archivos antiguos. Para quitarlos, ejecute el comando VACUUM.

No usar el almacenamiento en caché de Spark con Delta Lake

Databricks no recomienda usar el almacenamiento en caché de Spark por los siguientes motivos:

  • Se perderá cualquier omisión de datos que pueda proceder de filtros adicionales agregados sobre el elemento DataFrame almacenado en caché.
  • Es posible que los datos que se almacenan en caché no se actualicen si se tiene acceso a la tabla mediante un identificador diferente.

Diferencias entre Delta Lake y Parquet en Apache Spark

Delta Lake controla las siguientes operaciones automáticamente. Nunca debe realizar estas operaciones manualmente:

  • REFRESH TABLE: las tablas Delta siempre devuelven la información más actualizada, por lo que no es necesario llamar a REFRESH TABLE manualmente después de los cambios.
  • Agregar y quitar particiones: Delta Lake hace un seguimiento automático del conjunto de particiones presente en una tabla y actualiza la lista a medida que se agregan o quitan datos. Como resultado, no es necesario ejecutar ALTER TABLE [ADD|DROP] PARTITION ni MSCK.
  • Cargar una sola partición: no es necesario leer particiones directamente. Por ejemplo, no es necesario ejecutar spark.read.format("parquet").load("/data/date=2017-01-01"). En su lugar, use una cláusula WHERE para omitir datos, como spark.read.table("<table-name>").where("date = '2017-01-01'").
  • No modifique manualmente los archivos de datos: Delta Lake usa el registro de transacciones para confirmar los cambios en la tabla de forma atómica. No modifique, agregue ni elimine directamente archivos de datos de Parquet en una tabla Delta, ya que esto puede provocar daños en las tablas o datos perdidos.

Mejora del rendimiento de la fusión de Delta Lake

Puede reducir el tiempo que necesita la combinación mediante los enfoques siguientes:

  • Reducir el espacio de búsqueda de coincidencias: de forma predeterminada, la operación merge busca coincidencias en toda la tabla Delta en la tabla de origen. Una manera de acelerar merge es reducir el espacio de búsqueda agregando restricciones conocidas en la condición de coincidencia. Por ejemplo, suponga que tiene una tabla particionada por country y date y que desea usar merge para actualizar la información del último día y de un país específico. Agregar la siguiente condición hace que la consulta sea más rápida, ya que busca coincidencias solo en las particiones pertinentes:

    events.date = current_date() AND events.country = 'USA'

    Además, también reducirá las posibilidades de conflictos con otras operaciones simultáneas. Consulte Niveles de aislamiento y conflictos de escritura en Azure Databricks para más información.

  • Compactar archivos: si los datos se almacenan en muchos archivos pequeños, la lectura de los datos para buscar coincidencias puede resultar lenta. Puede compactar archivos pequeños en archivos más grandes para mejorar el rendimiento de lectura. Consulte Optimización del diseño del archivo de datos para obtener detalles.

  • Controlar las particiones aleatorias para escrituras: la operación merge selecciona aleatoriamente los datos varias veces para calcular y escribir los datos actualizados. El número de tareas que se usan para mezclar se controla mediante la configuración spark.sql.shuffle.partitions de la sesión de Spark. Si se establece este parámetro, no solo se controla el paralelismo, sino que también se determina el número de archivos de salida. Al aumentar el valor aumenta el paralelismo, pero también se genera un mayor número de archivos de datos pequeños.

  • Habilitar escrituras optimizadas: en el caso de las tablas con particiones, merge puede generar un número mucho mayor de archivos pequeños que el número de particiones aleatorias. Esto se debe a que cada tarea aleatoria puede escribir varios archivos en varias particiones y puede convertirse en un cuello de botella de rendimiento. Puede reducir el número de archivos habilitando las escrituras optimizadas. Consulte Operaciones de escritura optimizadas para Delta Lake en Azure Databricks.

  • Ajustar los tamaños de archivo de la tabla: Azure Databricks puede detectar automáticamente si una tabla Delta tiene operaciones frecuentes de merge que reescriben archivos y pueden optar por reducir el tamaño de los archivos reescritos en anticipación de las reescrituras de archivos en el futuro. Para más información, consulte la sección sobre el ajustes de los tamaños de los archivos.

  • Combinación de orden aleatorio bajo: Combinación de orden aleatorio bajo proporciona una implementación optimizada de MERGE que proporciona un mejor rendimiento para las cargas de trabajo más comunes. Además, conserva las optimizaciones de diseño de datos existentes, como la ordenación Z en datos sin modificar.

  • Last updated on