Compartir a través de


Optimización y mantenimiento de tablas entre cargas de trabajo en Microsoft Fabric

Las tablas delta de Microsoft Fabric sirven a varios motores de consumo, cada uno con diferentes características de rendimiento y requisitos de optimización. En esta guía se proporciona un marco completo para entender cómo otros motores procesan las tablas escritas por uno y cómo optimizar en consecuencia las estrategias de mantenimiento de tablas.

Comprender la relación entre patrones de escritura y rendimiento de lectura en distintos motores es esencial para crear plataformas de datos eficaces. El objetivo es asegurarse de que los productores de datos creen diseños de tabla que optimicen el rendimiento de lectura para los consumidores de nivel inferior, tanto si esos consumidores usan Spark, punto de conexión de SQL Analytics, Power BI Direct Lake o Warehouse.

Matriz de escenarios de escritura y lectura

En la tabla siguiente se resumen las características de rendimiento esperadas para combinaciones comunes de escritura y lectura, junto con las estrategias de optimización recomendadas. Use esta matriz para identificar su escenario y comprender las instrucciones pertinentes.

Método Write Motor de lectura Brechas esperadas Estrategia recomendada
Lote de Spark Spark Sin huecos Las configuraciones de escritura predeterminadas de Spark son suficientes
Procesamiento por lotes en Spark Punto de conexión de análisis SQL Sin huecos Habilitación de la compactación automática y optimización de escritura
Streaming de Spark Spark Archivos pequeños posibles Compactación automática y escritura optimizada con OPTIMIZE programada
Streaming de Spark Punto de conexión de análisis SQL Pequeños archivos y puntos de control Compactación automática, optimización y escritura, capas de medallón dividido
Almacén Spark Sin huecos La optimización administrada por el sistema controla el diseño
Almacén Punto de conexión de análisis SQL Sin huecos La optimización administrada por el sistema controla el diseño

Diseños de archivo óptimos según el motor

Los diferentes motores de consumo tienen diseños de archivo óptimos diferentes. Comprender estos objetivos le ayuda a configurar operaciones de escritura y trabajos de mantenimiento de manera adecuada.

Guía para el punto de conexión de SQL Analytics y Fabric Data Warehouse

Para obtener un rendimiento óptimo con el punto de conexión de SQL Analytics y Warehouse, use la siguiente configuración:

  • Tamaño del archivo de destino: aproximadamente 400 MB por archivo
  • Tamaño del grupo de filas: alrededor de 2 millones de filas por grupo de filas
  • Orden V: mejora el rendimiento de lectura en 10%

Un almacén usa estos criterios para detectar candidatos de compactación:

  • La sobrecarga de archivos de tabla es superior a 10%
  • En la tabla, las filas eliminadas lógicamente superan el 10%.
  • El tamaño de la tabla es mayor que 1024 filas

Durante la ejecución de la compactación, el proceso selecciona candidatos según estos criterios:

  • Cualquier archivo es menor que 25% del tamaño ideal (basado en el recuento de filas)
  • Cualquier archivo tiene más de 20% filas eliminadas

Spark

Spark es sólido al leer varios tamaños de archivo. Para obtener un rendimiento óptimo:

  • Tamaño del archivo de destino: 128 MB a 1 GB en función del tamaño de la tabla
  • Tamaño del grupo de filas: de 1 millón a 2 millones de filas por cada grupo de filas
  • Orden V: No es necesario para el rendimiento de lectura de Spark (puede agregar un 15-33% de sobrecarga de escritura).

Las lecturas de Spark se benefician del tamaño de archivo de destino adaptable, que se ajusta automáticamente en función del tamaño de la tabla:

  • Tablas de menos de 10 GB: objetivo de 128 MB
  • Tablas de más de 10 TB: hasta 1 GB objetivo

Power BI Direct Lake

Para obtener un rendimiento óptimo de Direct Lake:

  • Tamaño del grupo de filas objetivo: 8 millones o más filas por grupo de filas para obtener el mejor rendimiento
  • V-Order: fundamental para mejorar en un 40-60% las consultas con caché frío
  • Recuento de archivos: minimizar el recuento de archivos para reducir la sobrecarga de transcodificación
  • Tamaños de archivo coherentes: importante para el rendimiento predecible de las consultas

Los modelos semánticos de Direct Lake funcionan mejor cuando:

  • Los datos de columna están ordenados por V para la compresión compatible con VertiPaq
  • Los grupos de filas son lo suficientemente grandes para permitir una combinación eficaz de diccionarios.
  • Los vectores de eliminación se minimizan a través de la compactación normal

Para más información, consulte Descripción del rendimiento de las consultas de Direct Lake.

Creación de reflejo

El reflejo ajusta automáticamente el tamaño de los archivos según el volumen de la tabla.

Tamaño de la tabla Filas por grupo de filas Filas por archivo
Pequeño (hasta 10 GB) 2 millones 10 millones
Medio (de 10 GB a 2,56 TB) 4 millones 60 millones
Grande (más de 2,56 TB) 8 millones 80 millones

Escribir patrones y configuraciones

Patrones de escritura de Spark

Las escrituras de Spark usan las siguientes configuraciones predeterminadas:

Configuración Valor predeterminado Description
spark.microsoft.delta.optimizeWrite.fileSize 128 MB Tamaño de archivo de destino para escrituras optimizadas
spark.databricks.delta.optimizeWrite.enabled Varía según el perfil Habilita la fusión automática de archivos
spark.databricks.delta.autoCompact.enabled Disabled Habilita la compactación posterior a la escritura
spark.sql.files.maxRecordsPerFile Ilimitado Número máximo de registros por archivo

Para configurar las escrituras de Spark para el consumo posterior por SQL:

# Enable optimize write for better file layout
spark.conf.set('spark.databricks.delta.optimizeWrite.enabled', 'true')

# Enable auto-compaction for automatic maintenance
spark.conf.set('spark.databricks.delta.autoCompact.enabled', 'true')

Para más información sobre los perfiles de recursos y sus valores predeterminados, consulte Configuración de configuraciones de perfil de recursos.

Patrones de escritura de almacén

El almacenamiento optimiza automáticamente el diseño de datos durante las escrituras:

  • El orden V está habilitado de forma predeterminada para la optimización de lectura.
  • La compactación automática se ejecuta como un proceso en segundo plano.
  • La administración de puntos de control se controla automáticamente.

Warehouse genera archivos optimizados para el consumo de SQL sin intervención manual. Las tablas escritas por el almacén están intrínsecamente optimizadas tanto para el punto final de SQL Analytics como para las lecturas del almacén.

Operaciones de mantenimiento de tablas

Comando OPTIMIZE

El OPTIMIZE comando consolida los archivos pequeños en archivos más grandes:

-- Basic optimization
OPTIMIZE schema_name.table_name

-- Optimization with V-Order for Power BI consumption
OPTIMIZE schema_name.table_name VORDER

-- Optimization with Z-Order for specific query patterns
OPTIMIZE schema_name.table_name ZORDER BY (column1, column2)

Importante

El OPTIMIZE comando es un comando de Spark SQL. Debe ejecutarlo en entornos de Spark, como cuadernos, definiciones de trabajos de Spark o la interfaz de mantenimiento de Lakehouse. El punto de conexión de SQL Analytics y el editor de consultas SQL warehouse no admiten este comando.

Para obtener más información, consulte Compactación de tablas.

Compactación automática

La compactación automática evalúa automáticamente el estado de la partición después de cada operación de escritura y desencadena la optimización sincrónica cuando se detecta la fragmentación de archivos:

# Enable at session level
spark.conf.set('spark.databricks.delta.autoCompact.enabled', 'true')

# Enable at table level
spark.sql("""
    ALTER TABLE schema_name.table_name 
    SET TBLPROPERTIES ('delta.autoOptimize.autoCompact' = 'true')
""")

Utilice compactación automática para canalizaciones de ingestión con escrituras pequeñas frecuentes (streaming o microprocesamiento por lotes) para evitar la programación manual y mantener los archivos compactados automáticamente.

La compactación automática y la optimización de la escritura suelen generar los mejores resultados cuando se usan juntos. Optimizar la escritura reduce el número de archivos pequeños escritos y la compactación automática controla la fragmentación restante.

Para obtener más información, consulte Compactación automática.

Optimización de la escritura

Optimizar la escritura reduce la sobrecarga de archivos pequeños realizando la compactación de escritura previa, lo que genera menos archivos más grandes:

# Enable at session level
spark.conf.set('spark.databricks.delta.optimizeWrite.enabled', 'true')

# Enable at table level
spark.sql("""
    ALTER TABLE schema_name.table_name 
    SET TBLPROPERTIES ('delta.autoOptimize.optimizeWrite' = 'true')
""")

Optimizar la escritura es beneficiosa para:

  • Tablas particionadas
  • Tablas con inserciones de datos pequeñas y frecuentes
  • Operaciones que tocan muchos archivos (MERGE, UPDATE, DELETE)

La compactación antes de la escritura (optimización de escritura) suele ser menos costosa que la compactación después de la escritura (optimización). Para obtener más información, consulte Optimización de la escritura.

Comando VACUUM

El VACUUM comando quita los archivos antiguos a los que ya no hace referencia un registro de tabla Delta:

-- Remove files older than the default retention period (7 days)
VACUUM schema_name.table_name

-- Remove files older than specified hours
VACUUM schema_name.table_name RETAIN 168 HOURS

El período de retención predeterminado es de siete días. Establecer períodos de retención más cortos afecta a las funcionalidades de viaje en tiempo de Delta y puede causar problemas con lectores o escritores simultáneos.

Para obtener más información, consulte Mantenimiento de tablas de Lakehouse.

Optimización del orden V

V-Order es una optimización en tiempo de escritura que aplica ordenación, codificación y compresión compatibles con VertiPaq a los archivos Parquet.

  • Power BI Direct Lake: 40-60% mejora en las consultas en caché en frío
  • Punto de conexión y almacenamiento de SQL Analytics: aproximadamente 10% mejora del rendimiento de lectura
  • Spark: sin ventaja inherente en la lectura; escrituras un 15-33% más lentas

Cuándo habilitar V-Order

V-Order proporciona la mayor ventaja para:

  • Tablas de capa oro que sirven a Power BI Direct Lake
  • Tablas consultadas con frecuencia a través del punto de conexión de SQL Analytics
  • Cargas de trabajo intensivas de lectura en las que el rendimiento de escritura es menos crítico

Cuándo evitar V-Order

Considere la posibilidad de deshabilitar el orden V para:

  • Tablas de capa de bronce centradas en la velocidad de ingesta
  • Canalizaciones de Spark a Spark en las que SQL y Power BI no consumen los datos
  • Cargas de trabajo intensivas de escritura en las que la latencia de datos es crítica

Configurar V-Orden

V-Order está deshabilitado de forma predeterminada en los nuevos espacios de trabajo de Fabric. Para habilitar:

# Enable at session level (default for all writes)
spark.conf.set('spark.sql.parquet.vorder.default', 'true')

# Enable at table level
spark.sql("""
    ALTER TABLE schema_name.table_name 
    SET TBLPROPERTIES ('delta.parquet.vorder.enabled' = 'true')
""")

Para aplicar de manera selectiva el orden V en función del consumo de Direct Lake, considere automatizar la habilitación del orden V para las tablas empleadas en los modelos semánticos de Direct Lake. Las tablas no consumidas por Direct Lake pueden permanecer sin orden V para mejorar el rendimiento de escritura.

Para obtener más información, consulte Optimización de tablas de Delta Lake y Orden V.

Agrupación en clústeres líquidos y orden Z

Agrupación en clústeres líquidos

La agrupación en clústeres líquidos es el enfoque recomendado para la organización de datos. A diferencia de la creación de particiones tradicionales, agrupación en clústeres líquidos:

  • Se adapta a los patrones de consulta cambiantes
  • Requiere OPTIMIZE aplicar la agrupación en clústeres
  • Proporciona una mejor omisión de archivos para consultas filtradas.

Habilite la agrupación en clústeres líquidos en la creación de tablas:

CREATE TABLE schema_name.table_name (
    id INT,
    category STRING,
    created_date DATE
) CLUSTER BY (category)

Orden Z

Z-Order coloca los datos relacionados en los mismos archivos, por lo que obtendrá un mejor rendimiento de las consultas en predicados de filtro.

OPTIMIZE schema_name.table_name ZORDER BY (column1, column2)

Utilice Z-Order cuando:

  • La tabla tiene particiones, ya que la agrupación en clústeres líquidos no funciona con tablas con particiones.
  • Las consultas suelen filtrar por dos o más columnas juntas.
  • Sus predicados son lo suficientemente selectivos como para beneficiarse del salto de archivos.

Recomendaciones de arquitectura de Medallion

La arquitectura de medallón (capas Bronce, Plata, Oro) proporciona un marco para optimizar las estrategias de mantenimiento de las tablas en función del propósito de cada capa.

Capa de bronce (zona de aterrizaje)

Las tablas bronze se centran en el rendimiento de escritura y la ingesta de baja latencia:

  • Prioridad de optimización: velocidad de ingesta sobre el rendimiento de lectura
  • Creación de particiones: aceptable, pero no recomendable para las nuevas implementaciones
  • Archivos pequeños: aceptable, ya que el foco está en la velocidad de ingesta
  • V-Order: No recomendado (añade sobrecarga de escritura)
  • Compactación automática: activar para reducir el tamaño de los archivos pequeños, pero se puede sacrificar para la velocidad de ingestión.
  • Vectores de eliminación: habilitar para tablas con patrones de combinación

Las tablas Bronze no deben servirse directamente al endpoint de SQL Analytics ni a los consumidores de Power BI Direct Lake.

Capa de plata (zona curada)

Las tablas Silver equilibran el rendimiento de escritura y lectura.

  • Prioridad de optimización: equilibrio entre la ingesta y el rendimiento de las consultas
  • Tamaños de archivo: moderado (128-256 MB) para admitir operaciones de escritura y lectura
  • V-Order: Opcional; actívelo si el uso del punto de conexión SQL Analytics o el consumo de Power BI es considerable
  • Clústeres líquidos o orden Z: recomendado para mejorar el rendimiento de las consultas
  • Compactación automática y optimización de escritura: habilitar en función de los requisitos posteriores
  • Vectores de eliminación: habilitar para tablas con actualizaciones frecuentes
  • Optimización programada: ejecutar de forma agresiva para mantener el diseño de archivos

Capa de oro (zona de servicio)

Las tablas Gold priorizan el rendimiento de lectura para el consumo del usuario final:

  • Prioridad de optimización: Rendimiento de lectura para análisis
  • Tamaños de archivo: grandes (400 MB a 1 GB) para obtener un rendimiento óptimo de SQL y Power BI
  • Orden V: requerido para Power BI Direct Lake; beneficioso para el extremo de análisis de SQL
  • Clústeres líquidos: necesario para omitir archivos óptimos
  • Optimizar escritura: necesario para tamaños de archivo coherentes
  • Optimización programada: ejecutar de forma agresiva para mantener un diseño óptimo

Optimice las tablas de oro de acuerdo con el motor de consumo principal:

Motor de consumo Orden V Tamaño del archivo de destino Tamaño de grupo de filas
Punto de conexión de análisis SQL 400 MB 2 millones de filas
Power BI Direct Lake 400 MB a 1 GB Más de 8 millones de filas
Spark Opcional 128 MB a 1 GB 1-2 millones de filas

Múltiples copias de una tabla

Es aceptable mantener varias copias de tablas optimizadas para diferentes patrones de consumo:

  • Una tabla Silver optimizada para el procesamiento de Spark
  • Una tabla Gold optimizada para el punto de conexión de SQL Analytics y Power BI Direct Lake
  • Tuberías de datos que transforman y establecen la estructura correcta en cada capa

El almacenamiento es económico en comparación con la computación. La optimización de tablas para sus patrones de consumo proporciona una mejor experiencia de usuario que intentar servir a todos los consumidores desde un único diseño de tabla.

Identificación del estado de la tabla

Antes de optimizar las tablas, evalúe el estado de la tabla actual para comprender las necesidades de optimización.

Inspeccionar archivos Parquet directamente

Puede examinar la carpeta de tablas en OneLake para inspeccionar los tamaños de los archivos Parquet individuales. Las tablas correctas tienen tamaños de archivo distribuidos uniformemente. Busque:

  • Tamaños de archivo coherentes: los archivos deben tener aproximadamente el mismo tamaño (dentro de 2 veces entre sí).
  • No hay archivos extremadamente pequeños: los archivos menores de 25 MB indican fragmentación.
  • No hay archivos extremadamente grandes: los archivos de más de 2 GB pueden reducir el paralelismo.

La distribución de tamaño de archivo desigual suele indicar que faltan patrones de escritura o compactación incoherentes en distintos trabajos.

OPTIMIZACIÓN DE LA EJECUCIÓN SECA en Spark SQL

Use la DRY RUN opción para obtener una vista previa de los archivos que son aptos para la optimización sin ejecutar la compactación:

-- Preview files eligible for optimization
OPTIMIZE schema_name.table_name DRY RUN

El comando devuelve una lista de archivos que se volverían a escribir durante la optimización. Úselo para:

  • Evalúe el ámbito de optimización antes de ejecutarlo.
  • Comprenda la fragmentación de archivos sin modificar la tabla.
  • Calcule el tiempo de optimización en función del número de archivos afectados.

Distribución de tamaño de archivo

Use el siguiente enfoque para analizar los tamaños de archivo y la distribución:

from delta.tables import DeltaTable

# Get table details
details = spark.sql("DESCRIBE DETAIL schema_name.table_name").collect()[0]
print(f"Table size: {details['sizeInBytes'] / (1024**3):.2f} GB")
print(f"Number of files: {details['numFiles']}")

# Average file size
avg_file_size_mb = (details['sizeInBytes'] / details['numFiles']) / (1024**2)
print(f"Average file size: {avg_file_size_mb:.2f} MB")

La distribución se puede sesgar, ya que es posible que los archivos cerca del encabezado de la tabla o de una partición específica no estén optimizados.

Puede evaluar la distribución ejecutando una consulta que agrupa por las claves de particionamiento o clústeres de la tabla.

Determinación de las necesidades de optimización

En función del motor de consumo, compare los tamaños de archivo reales con los tamaños de destino:

Motor Tamaño del archivo de destino Si los archivos son más pequeños Si los archivos son más grandes
Punto de conexión de análisis SQL 400 MB Ejecute OPTIMIZE: Los archivos son aceptables
Power BI Direct Lake 400 MB a 1 GB Ejecute OPTIMIZE VORDER: Los archivos son aceptables
Spark 128 MB a 1 GB Habilitación de la compactación automática Los archivos son aceptables

Historial de tablas y registro de transacciones

Revise el historial de tablas para comprender los patrones de escritura y la frecuencia de mantenimiento:

-- View table history
DESCRIBE HISTORY schema_name.table_name

-- Check for auto-compaction runs
-- Auto-compaction shows as OPTIMIZE with auto=true in operationParameters

Procedimientos recomendados de configuración

Uso de propiedades de tabla en configuraciones de sesión

Las propiedades de la tabla permanecen entre sesiones y garantizan un comportamiento coherente en todos los trabajos y procesos de escritura.

# Recommended: Set at table level for consistency
spark.sql("""
    CREATE TABLE schema_name.optimized_table (
        id INT,
        data STRING
    )
    TBLPROPERTIES (
        'delta.autoOptimize.optimizeWrite' = 'true',
        'delta.autoOptimize.autoCompact' = 'true',
        'delta.parquet.vorder.enabled' = 'true'
    )
""")

Las configuraciones de nivel de sesión solo se aplican a la sesión de Spark actual y pueden provocar escrituras incoherentes si las distintas sesiones usan configuraciones diferentes.

Habilitación del tamaño del archivo de destino adaptable

El tamaño adaptable del archivo de destino ajusta automáticamente los objetivos de tamaño de archivo según el tamaño de la tabla.

spark.conf.set('spark.microsoft.delta.targetFileSize.adaptive.enabled', 'true')

Esta característica:

  • Comienza con archivos más pequeños (128 MB) para tablas pequeñas
  • Las tablas de más de 10 TB pueden escalar hasta 1 GB
  • Se vuelve a evaluar automáticamente durante las OPTIMIZE operaciones

Habilitar objetivos de compactación a nivel de archivo

Evite volver a escribir archivos previamente compactos cuando cambien los tamaños de destino:

spark.conf.set('spark.microsoft.delta.optimize.fileLevelTarget.enabled', 'true')

Resumen de recomendaciones

Nivel Compactación automática Optimización y escritura Orden V Agrupación en clústeres líquidos Optimización programada
Bronce Habilitar (opcional) Enable No No Opcional
Plata Enable Enable Opcional Agresivo
Oro Enable Enable Agresivo

Para escenarios específicos, use las siguientes recomendaciones:

  • Spark-to-Spark: Enfocarse en la optimización del tamaño de archivo; V-Order opcional.
  • Spark-to-SQL: habilitar la escritura optimizada y la compactación automática; archivos objetivo de 400 MB con 2 millones de grupos de filas.
  • Ingesta de streaming: Habilite la compactación automática y programe trabajos adicionales OPTIMIZE para los consumidores de SQL.
  • Power BI Direct Lake: Habilitar orden V; dirigirse a más de 8 millones de grupos de filas; ejecute OPTIMIZE VORDER.