Share via

Optimización de tablas de Delta Lake y V-Order

  • Artículo

Los formatos de tablas de Lakehouse y Delta Lake son fundamentales para Microsoft Fabric, lo que garantiza que las tablas estén optimizadas para el análisis sea un requisito clave. En esta guía se describen los conceptos de optimización de tablas de Delta Lake, las configuraciones y cómo aplicarlos a los patrones de uso de macrodatos más comunes.

¿Qué es V-Order?

V-Order es una optimización del tiempo de escritura en el formato de archivo parquet que permite lecturas rápidas de rayos en los motores de proceso de Microsoft Fabric, como Power BI, SQL, Spark y otros.

Los motores de Power BI y SQL usan la tecnología de Microsoft Verti-Scan y los archivos parquet ordenados por V-Order para lograr tiempos de acceso a datos en memoria. Spark y otros motores de proceso que no son Verti-Scan también se benefician de los archivos ordenados por V-Order con un promedio de tiempos de lectura un 10 % más rápidos, con algunos escenarios de hasta un 50 %.

V-Order funciona aplicando una ordenación especial, distribución de grupos de filas, codificación de diccionario y compresión en archivos parquet, lo que requiere menos recursos de red, disco y CPU en los motores de proceso para leerlos, lo que proporciona rentabilidad y rendimiento. La ordenación de V-Order tiene un impacto del 15 % en los tiempos medios de escritura, pero proporciona hasta un 50 % más de compresión.

Todos los motores parquet puede leer su formato parquet de código abierto 100 % compatible como archivos parquet normales. Las tablas delta son más eficientes que nunca; características como Z-Order son compatibles con V-Order. Las propiedades de tabla y los comandos de optimización se pueden usar en el control de V-Order en sus particiones.

V-Order se aplica en el nivel de archivo parquet. Las tablas delta y sus características, como Z-Order, compactación, vacío, viaje de tiempo, etc. son ortogonales a V-Order y, como tal, son compatibles y se pueden usar juntas para beneficios adicionales.

Control de escrituras de V-Order

V-Order está habilitado de forma predeterminada en Microsoft Fabric y en Apache Spark se controla mediante las siguientes configuraciones.

Configuración Valor predeterminado Descripción
spark.sql.parquet.vorder.enabled true Controla la escritura de V-Order de nivel de sesión.
TBLPROPERTIES(“delta.parquet.vorder.enabled”) false Modo de V-Order predeterminado en tablas
Opción del escritor de DataFrame: parquet.vorder.enabled anular Control de escrituras de V-Order mediante el escritor de DataFrame

Use los comandos siguientes para controlar el uso de escrituras de V-Order.

Comprobación de la configuración de V-Order en la sesión de Apache Spark

%%sql 
SET spark.sql.parquet.vorder.enabled

Deshabilitación de la escritura de V-Order en la sesión de Apache Spark

%%sql 
SET spark.sql.parquet.vorder.enabled=FALSE

Habilitación de la escritura de V-Order en la sesión de Apache Spark

Importante

Cuando se habilita en el nivel de sesión. Todas las escrituras de parquet se realizan con V-Order habilitado. Esto incluye tablas de parquet no delta y tablas Delta con la propiedad de tabla parquet.vorder.enabled establecida en true o false.

%%sql 
SET spark.sql.parquet.vorder.enabled=TRUE

Control de V-Order mediante las propiedades de la tabla Delta

Habilite la propiedad de tabla V-Order durante la creación de la tabla:

%%sql 
CREATE TABLE person (id INT, name STRING, age INT) USING parquet TBLPROPERTIES("delta.parquet.vorder.enabled" = "true");

Importante

Cuando la propiedad de tabla se establece en true, los comandos INSERT, UPDATE y MERGE se comportarán según lo esperado y ejecutarán la optimización en tiempo de escritura. Si la configuración de sesión de pedido virtual se establece en true o spark.write la habilita, las escrituras serán V-Order incluso si TBLPROPERTIES está establecida en false.

Habilite o deshabilite V-Order modificando la propiedad de tabla:

%%sql 
ALTER TABLE person SET TBLPROPERTIES("delta.parquet.vorder.enabled" = "true");

ALTER TABLE person SET TBLPROPERTIES("delta.parquet.vorder.enabled" = "false");

ALTER TABLE person UNSET TBLPROPERTIES("delta.parquet.vorder.enabled");

Después de habilitar o deshabilitar V-Order mediante propiedades de tabla, solo se ven afectadas las escrituras futuras en la tabla. Los archivos parquet mantienen la ordenación usada cuando se creó. Para cambiar la estructura física actual para aplicar o quitar V-Order, consulta la sección «Control de V-Order al optimizar una tabla».

Control de V-Order directamente en operaciones de escritura

Todos los comandos de escritura de Apache Spark heredan la configuración de sesión si no está explícita. Todos los comandos siguientes escriben con V-Order mediante la herencia implícita de la configuración de sesión.

df_source.write\
  .format("delta")\
  .mode("append")\
  .saveAsTable("myschema.mytable")

DeltaTable.createOrReplace(spark)\
  .addColumn("id","INT")\
  .addColumn("firstName","STRING")\
  .addColumn("middleName","STRING")\
  .addColumn("lastName","STRING",comment="surname")\
  .addColumn("birthDate","TIMESTAMP")\
  .location("Files/people")\
  .execute()

df_source.write\
  .format("delta")\
  .mode("overwrite")\
  .option("replaceWhere","start_date >= '2017-01-01' AND end_date <= '2017-01-31'")\
  .saveAsTable("myschema.mytable")

Importante

V-Order solo aplica a los archivos afectados por el predicado.

En una sesión en la que spark.sql.parquet.vorder.enabled no se establece o se establece en false, los siguientes comandos escribirían mediante V-Order:

df_source.write\
  .format("delta")\
  .mode("overwrite")\
  .option("replaceWhere","start_date >= '2017-01-01' AND end_date <= '2017-01-31'")\
  .option("parquet.vorder.enabled ","true")\
  .saveAsTable("myschema.mytable")

DeltaTable.createOrReplace(spark)\
  .addColumn("id","INT")\
  .addColumn("firstName","STRING")\
  .addColumn("middleName","STRING")\
  .addColumn("lastName","STRING",comment="surname")\
  .addColumn("birthDate","TIMESTAMP")\
  .option("parquet.vorder.enabled","true")\
  .location("Files/people")\
  .execute()

¿Qué es la optimización de escritura?

Las cargas de trabajo analíticas en motores de procesamiento de macrodatos, como Apache Spark, funcionan de forma más eficaz al usar tamaños de archivo más grandes estandarizados. La relación entre el tamaño del archivo, el número de archivos, el número de trabajos de Spark y sus configuraciones desempeña un papel fundamental en el rendimiento. La incorporación de datos a las tablas del lago de datos puede tener la característica heredada de escribir constantemente un gran número de archivos pequeños; este escenario se conoce comúnmente como el "problema de los archivos pequeños".

La característica Optimizar escritura de Delta Lake en Microsoft Fabric y Azure Synapse Analytics en el motor de Apache Spark reduce el número de archivos escritos y tiene como objetivo aumentar el tamaño del archivo de los datos escritos. El tamaño del archivo de destino se puede cambiar según los requisitos de carga de trabajo mediante las configuraciones.

La característica está habilitada de manera predeterminada en Microsoft Fabric Runtime para Apache Spark. Para más información sobre escenarios de optimización de uso de escritura, lea el artículo Necesidad de optimizar la escritura en Apache Spark.

Optimización de combinación

El comando MERGE de Data Lake permite a los usuarios actualizar una tabla delta con condiciones avanzadas. Puede actualizar datos de una tabla de origen, una vista o un DataFrame en una tabla de destino mediante el comando MERGE. Sin embargo, el algoritmo actual de la distribución de código abierto de Delta Lake no está totalmente optimizado para controlar las filas sin modificar. El equipo Delta de Microsoft Spark implementó una optimización de combinación aleatoria baja personalizada. Las filas sin modificar se excluirán de operaciones de orden aleatorio costosas que se necesiten para actualizar las filas coincidentes.

La implementación se controla mediante la configuración spark.microsoft.delta.merge.lowShuffle.enabled, habilitada de forma predeterminada en el tiempo de ejecución. No requiere cambios de código y es totalmente compatible con la distribución de código abierto de Delta Lake. Para más información sobre los escenarios de uso de combinación aleatoria baja, lea el artículo Optimización de combinación aleatoria baja en tablas delta.

Mantenimiento de tablas delta

A medida que cambian las tablas delta, el rendimiento y la rentabilidad del almacenamiento tienden a degradarse por los siguientes motivos:

  • Los nuevos datos agregados a la tabla pueden sesgar datos.
  • Las tasas de ingesta de datos por lotes y streaming pueden traer muchos archivos pequeños.
  • Las operaciones de actualización y eliminación finalmente crean sobrecarga de lectura; los archivos parquet son inmutables por diseño, por lo que las tablas delta agregan nuevos archivos parquet con el conjunto de cambios, ampliando aún más los problemas impuestos por los dos primeros elementos.
  • Ya no se necesitan archivos de datos ni archivos de registro disponibles en el almacenamiento.

Con el fin de mantener las tablas en el mejor estado para obtener el mejor rendimiento, realice operaciones de compactación y vaciado de bin en las tablas Delta. La compactación de bin se logra mediante el comando OPTIMIZE; combina todos los cambios en archivos parquet más grandes y consolidados. La limpieza de almacenamiento desreferenciada se logra mediante el comando VACUUM.

Los comandos de mantenimiento de tablas OPTIMIZE y VACUUM se pueden usar en cuadernos y definiciones de trabajos de Spark y, a continuación, orquestarlos mediante funcionalidades de plataforma. Lakehouse en Fabric ofrece una funcionalidad para usar la interfaz de usuario para realizar el mantenimiento de tablas ad hoc, como se explica en el artículo Mantenimiento de tablas de Delta Lake.

Importante

Diseñar correctamente la estructura física de la tabla en función de la frecuencia de ingesta y los patrones de lectura esperados es probablemente más importante que ejecutar los comandos de optimización descritos en esta sección.

Control de V-Order al optimizar una tabla

Las siguientes estructuras de comandos realizan la compactación de bin y vuelven a escribir todos los archivos afectados mediante V-Order, independientemente de la configuración de TBLPROPERTIES o de la configuración de sesión:

%%sql 
OPTIMIZE <table|fileOrFolderPath> VORDER;

OPTIMIZE <table|fileOrFolderPath> WHERE <predicate> VORDER;

OPTIMIZE <table|fileOrFolderPath> WHERE <predicate> [ZORDER  BY (col_name1, col_name2, ...)] VORDER;

Cuando se usan ZORDER y VORDER juntos, Apache Spark realiza la compactación de bin, ZORDER y VORDER secuencialmente.

Los siguientes comandos realizan la compactación de bin y vuelven a escribir todos los archivos afectados mediante la configuración TBLPROPERTIES. Si TBLPROPERTIES se establece en true en V-Order, todos los archivos afectados se escriben como V-Order. Si TBLPROPERTIES no se establece o se establece en false en V-Order, hereda la configuración de sesión; por lo tanto, para quitar V-Order de la tabla, establezca la configuración de sesión en false.

%%sql 
OPTIMIZE <table|fileOrFolderPath>;

OPTIMIZE <table|fileOrFolderPath> WHERE predicate;

OPTIMIZE <table|fileOrFolderPath> WHERE predicate [ZORDER BY (col_name1, col_name2, ...)];

Contenido relacionado