Mantenimiento y optimización de tablas entre cargas de trabajo en Microsoft Fabric

Las tablas Delta en Microsoft Fabric pueden servir a Spark, endpoint de análisis SQL, Power BI Direct Lake, Warehouse y otras experiencias de Fabric a partir de datos almacenados en OneLake. El rendimiento óptimo entre cargas de trabajo depende de dos factores:

  • La carga de trabajo que crea y mantiene la tabla.
  • Los motores que consumen la mesa.

Las tablas Lakehouse suelen ser gestionadas por Spark, Fabric pipeline actividad de copia o Dataflow Gen2. Spark es el escritor más común y ofrece los controles de diseño y mantenimiento más amplios. La creación de réplicas del almacén y de la base de datos gestiona automáticamente sus diseños físicos. Los catálogos espejo mantienen el diseño gestionado en el sistema fuente. Los requisitos del consumidor son generalmente compatibles, pero Power BI Direct Lake tiene requisitos adicionales de almacenamiento para un rendimiento óptimo.

Utiliza una tabla compartida siempre que sus requisitos sean compatibles. Para las excepciones que justifiquen otra tabla, véase Cuándo crear otra tabla.

Entender la propiedad del diseño

Empieza identificando qué carga de trabajo es la responsable de la disposición física de la mesa. Los controles de la siguiente tabla son los controles clave relevantes para la disposición y mantenimiento de la tabla de carga cruzada, no una lista exhaustiva de las capacidades de cada motor.

Almacén de datos Escritor o método de ingesta Diseño y responsabilidad del mantenimiento Controles clave
Lakehouse Spark Gestionado por los usuarios Tamaño de archivo: tamaño de archivo de destino adaptativo y objetivos de compactación a nivel de archivo.
Escritura y mantenimiento: vectores de borrado, autocompactación, optimización de escritura, OPTIMIZE, y VACUUM.
Organización de datos: agrupación de líquidos, particionamiento, orden Z y orden V.
Lakehouse Canalización de Fabric: actividad Copiar o Dataflow Gen2 El servicio escribe los datos; el propietario del lakehouse mantiene la tabla Configuración de escritura específica para cada destino. Realiza el mantenimiento compatible por separado usando Spark, mantenimiento Lakehouse o una actividad de mantenimiento de oleoductos.
Almacén Fabric Data Warehouse, actividad de copia de la canalización de Fabric o Dataflow Gen2 Gestionado en almacén Agrupación de datos y la configuración de V-Order a nivel de almacén.
Elemento espejo Servicio de espejo Depende del tipo de espejo El reflejo de bases de datos utiliza un diseño Delta V-Ordered gestionado por el sistema, sin controles directos de diseño. Los catálogos espejo conservan la disposición del archivo fuente, que puedes optimizar en el sistema fuente cuando sea compatible.

Guía de carga de trabajo cruzada

La siguiente tabla resume el enfoque recomendado por productor y consumidor.

Producer Consumer Enfoque recomendado
Lakehouse: escritura de Spark Spark Utiliza los valores predeterminados de Fabric Spark runtime 2.0 o posterior y activa la autocompactación. Considera el agrupamiento líquido cuando los predicados medidos se benefician de una mejora en el salto de archivos.
Lakehouse: escritor de Spark Punto de conexión de análisis SQL Usa la misma disposición recomendada para Spark. No pongas un tamaño de archivo objetivo estático, un límite arbitrario de filas o un orden en V solo para el rendimiento de endpoints de analítica SQL.
Lakehouse: escritor de Spark Power BI Direct Lake Utiliza el mismo diseño recomendado para Spark y además activa V-Order, o utiliza el perfil de readHeavyForPBI recursos.
Lakehouse: escritor de canalización de Fabric o Dataflow Gen2 Spark, endpoint de analítica SQL o Power BI Direct Lake Supervisa la estructura de archivos resultante y planifica por separado el mantenimiento compatible del lakehouse. Algunos modos de destino, como la actualización incremental de Dataflow Gen2, imponen restricciones de mantenimiento.
Almacén Fabric Data Warehouse o Spark Utiliza el diseño gestionado por sistema. Fabric Data Warehouse gestiona automáticamente la compactación y otros mantenimientos. Utiliza agrupación de datos para mejorar el salto de archivos en cargas de trabajo con predicados selectivos recurrentes.
Almacén Power BI Direct Lake Mantén la configuración predeterminada de Warehouse V-Order. Utiliza agrupamiento de datos cuando beneficie a patrones de consulta compartidos.
Creación de reflejo Spark, endpoint de analítica SQL o Power BI Direct Lake Para el reflejo de bases de datos, utiliza el diseño V-Ordered Delta gestionado por el sistema. Para catálogos espejados, optimiza los archivos subyacentes en el sistema fuente cuando estén soportados. Consulte ¿Qué es la duplicación en Fabric?.

Optimizar las tablas de Lakehouse

Las tablas Delta de Lakehouse requieren una estrategia de mantenimiento explícita, independientemente de si las escribe Spark, Pipeline actividad de copia o Dataflow Gen2. Spark es el ejemplo principal de esta sección porque ofrece los controles de diseño y mantenimiento más amplios en Fabric.

Importante

El mantenimiento de las tablas es fundamental para un rendimiento óptimo en lectura y escritura en todos los motores. Incluso las cargas de trabajo solo append-up que inicialmente funcionan bien sin mantenimiento pueden acumular archivos demasiado pequeños, lo que afecta a Spark, SQL Analytics Endpoint, Direct Lake y lectores de datos externos. Consulta Tablas Delta de Compactación para métodos de compactación automáticos y manuales.

Usa los valores predeterminados de Spark en tiempo de ejecución

Cuando Spark escriba la tabla, utiliza los valores predeterminados de Fabric Spark en tiempo de ejecución 2.0 o posteriores:

En Fabric Spark runtime 1.3, el tamaño adaptativo del archivo objetivo, los objetivos de compactación a nivel de archivo y los vectores de eliminación están disponibles como configuraciones opt-in.

Cuando Pipeline actividad de copia o Dataflow Gen2 escriban la tabla, inspecciona el diseño resultante del archivo y programa el mantenimiento por separado. No des por hecho que estos escritores aplican valores predeterminados en tiempo de ejecución de Spark.

Importante

Los destinos de tipo lakehouse de Dataflow Gen2 que usan actualización incremental no admiten OPTIMIZE ni REORG TABLE. Sigue las limitaciones de actualización incremental de Dataflow Gen2.

Prevenir y compactar archivos pequeños

Para tablas escritas por Spark, prefiero la autocompactación. Esta característica evalúa la fragmentación de la tabla tras la escritura y ejecuta compactación solo cuando es necesario. Elimina la necesidad de realizar una comprobación del estado de la tabla por separado antes de ejecutar las tareas de mantenimiento.

Utiliza las siguientes directrices para excepciones y características complementarias:

Scenario Enfoque recomendado
Tabla escrita con Spark Activa la autocompactación como estrategia de mantenimiento por defecto.
Escrituras en streaming o microbatch Activar la autocompactación y optimizar la escritura para reducir la acumulación de archivos pequeños.
Cargas de trabajo con requisitos estrictos de latencia de escritura Planifica OPTIMIZE por separado en lugar de ejecutar la compactación automática síncrona.
Tabla existente con archivos pequeños acumulados Ejecuta OPTIMIZEuna vez y luego activa la compactación automática para el mantenimiento continuo.
Tablas con actualizaciones, eliminaciones o fusiones frecuentes Mantén activados los vectores de eliminación y la autocompactación .

OPTIMIZE compacta archivos y purga automáticamente los vectores de eliminación de un archivo cuando más de 5% de sus registros son referenciados por vectores de borrado. Úsalo REORG TABLE ... APPLY (PURGE) solo cuando debas purgar físicamente registros por debajo de ese umbral o cumplir con un requisito específico de cumplimiento.

Note

La autocompactación purga los vectores de eliminación solo cuando la partición también cumple con su disparador de archivo pequeño. Si una carga de trabajo realiza actualizaciones o eliminaciones sin generar archivos pequeños, ejecuta OPTIMIZE periódicamente para eliminar los vectores de eliminación que cumplan los requisitos. Usa REORG TABLE ... APPLY (PURGE) cuando debas forzar una purga física.

Ejecuta VACUUM en un horario separado para eliminar archivos sin referencia después del periodo de retención. VACUUM recupera almacenamiento pero no mejora la disposición activa del archivo.

Warning

No acortes el VACUUM periodo de retención sin evaluar los requisitos de viaje en el tiempo y los lectores o escritores concurrentes. Eliminar archivos demasiado pronto puede hacer que las versiones requeridas de las tablas no estén disponibles.

Organizar los datos para el salto de archivos

Utiliza agrupamiento líquido cuando los patrones recurrentes de filtros o procesamiento se beneficien de una mejora en el salto de archivos. Las tablas en clúster líquidas requieren OPTIMIZEo autocompactación para organizar los datos recién escritos.

Evita la partición por defecto. Úsalo cuando un requisito específico justifique los compromisos operativos, como aislar a escritores concurrentes que actualizan, eliminan o fusionan datos entre particiones disjuntas. Para más información, véase Cuándo usar la partición.

Para tablas particionadas existentes, consideremos el orden Z cuando los predicados selectivos suelen filtrarse en las mismas columnas dentro de una partición.

Optimizar tablas gestionadas por Warehouse

Fabric Data Warehouse gestiona la disposición física de la tabla Delta independientemente del método de ingestión.

Utiliza los controles estratégicos que expone Warehouse para ajustar el diseño de los datos:

  • Aplicar agrupamiento de datos a tablas grandes cuando las consultas usen repetidamente predicados selectivos en las mismas columnas.
  • Mantén V-Order activado para cargas de trabajo orientadas a lectura y mixtas. V-Order está activado por defecto.
  • Considera desactivar V-Order para cargas de trabajo intensivas en escritura en el almacén.

Warning

Desactivar la Orden V es una operación irreversible a nivel de almacén. Prueba toda la carga de lectura y escritura antes de desactivarla.

Para una guía completa sobre el Almacén, consulte las directrices de rendimiento en Fabric Data Warehouse.

Optimizar los datos reflejados

Tu capacidad para mejorar el diseño físico depende de si Fabric replica los datos o hace referencia a los archivos fuente:

  • Creación de reflejo de base de datos: Fabric replica los datos de origen en tablas Delta en OneLake y administra el diseño y mantenimiento de archivos V-Order. No puedes configurar directamente el tamaño del archivo destino, la limpieza de vectores de borrado, el agrupamiento de líquidos, la partición o el orden en V en el destino espejado.
  • Catálogos reflejados: Fabric sincroniza los metadatos y utiliza accesos directos de OneLake para hacer referencia a los datos de origen donde se encuentran. Fabric no reescribe ni mantiene estos archivos. Mejorar el diseño físico y la limpieza en el sistema fuente cuando las características compatibles lo permitan. Esos cambios son visibles mediante los accesos directos, sin necesidad de crear otra copia en Fabric.

Para datos espejados en la base de datos:

  • Utiliza predicados selectivos y evita columnas innecesarias en consultas de Spark y SQL.
  • Diseñar modelos semánticos de Power BI y medidas DAX para un consumo eficiente de Direct Lake.

Para catálogos espejados:

  • Utiliza las funciones de mantenimiento de tablas y maquetación soportadas por la plataforma fuente.
  • Evalúa la distribución del archivo de origen y la de los grupos de filas para los consumidores de Fabric que consultan los accesos directos.
  • Para Direct Lake, evalúa la creación de una capa de servicio adicional modelada dimensionalmente y V-Ordered cuando el diseño fuente no cumpla con los requisitos de rendimiento.

Para espejar conceptos, tipos y fuentes soportadas, consulta ¿Qué es el reflejo en Fabric? y Cómo funciona el reflejo de metadatos.

Aplicar optimización específica para el consumidor

Spark y el punto de conexión de análisis SQL ofrecen un buen rendimiento en la misma arquitectura lakehouse adaptativa. Utiliza el tamaño de archivo objetivo adaptativo, evita archivos demasiado pequeños y aplica agrupamiento líquido cuando los predicados medidos se benefician de una mejora en el salto de archivos. No habilites V-Order únicamente por el rendimiento de los endpoints de análisis de Spark o SQL. Para detalles específicos del motor, véase consideraciones sobre el rendimiento de endpoints en analítica SQL.

Power BI Direct Lake

Direct Lake utiliza las mismas tablas Delta subyacentes pero añade recomendaciones relacionadas con la transcodificación y el enmarcado incremental:

Note

Direct Lake generalmente rinde mejor con grupos de hileras entre 1 y 16 millones de hileras. Evalúa la distribución de los grupos de filas y el rendimiento de Direct Lake antes de cambiar una configuración compatible del productor.

Para tablas escritas por Spark, spark.sql.parquet.native.writer.maxRowGroupRowCount establece el número máximo de filas por grupo de filas cuando el motor de ejecución nativo escribe los archivos Parquet. El valor por defecto es 0, que no impone un máximo. Si el análisis muestra que el tamaño de grupos de filas está afectando al rendimiento de Direct Lake, establezca un límite probado antes de escribir o reescribir la tabla. Por ejemplo:

spark.conf.set("spark.sql.parquet.native.writer.maxRowGroupRowCount", 8_000_000)

No pongas el límite solo para alcanzar un número específico de filas. El ancho de fila, la compresión, la distribución de archivos y el paralelismo de capacidad también afectan al rendimiento. Utiliza Delta Analyzer para evaluar la disposición resultante.

Para orientación detallada sobre encuadre, transcodificación, grupos de filas, patrones de actualización y Delta Analyzer, consulte Entender el rendimiento de consultas Direct Lake.

Aplica la guía a las capas de medallón

Bronce, Plata y Oro describen el propósito y el refinamiento de los datos. No determinan si el diseño está gestionado por el usuario o por el sistema, y no requieren copias separadas para cada consumidor.

Nivel Objetivo principal Guía de carga de trabajo cruzada
Bronce (aterrizaje) Preservar la fidelidad del código fuente y el rendimiento de ingestión Prioriza el rendimiento de escritura manteniendo tablas escritas por Spark con autocompactación. Evita los modelos semánticos de Power BI Direct Lake en tablas Bronze en bruto, a menos que el modelo y la forma de los datos estén diseñados intencionadamente para ese uso.
Plata (seleccionada) Proporcionar datos validados y conformes para su reutilización Reutiliza la tabla en consumidores de Fabric compatibles. Para las tablas de lakehouse escritas por Spark, habilita V-Order solo cuando Direct Lake sea el consumidor principal.
Oro (porción) Ofrece dimensiones, hechos, agregados y modelos analíticos listos para su uso empresarial Prefiero esta capa para modelos semánticos de Direct Lake. Reutiliza la tabla entre consumidores compatibles y aplica los controles específicos del productor descritos en este artículo.

Resolver problemas de distribución y mantenimiento

Utiliza una corrección que tenga en cuenta al productor. Aplica comandos de mantenimiento de Spark a las tablas lakehouse cuando el modo destino soporte esas operaciones. Trata las señales como indicadores en lugar de umbrales universales, y validalas frente al patrón de escritura de la tabla y al rendimiento del consumidor.

Condition Señal Tabla de la casa del lago Mesa de almacén
Archivos demasiado pequeños El número de archivos aumenta más rápido que el tamaño de la tabla activa, y los archivos permanecen por debajo del objetivo adaptativo. Con Spark, ejecuta una OPTIMIZE única para el trabajo pendiente existente y luego activa la compactación automática. Para la actividad Copy de canalización o las escrituras de Dataflow Gen2, programe por separado el mantenimiento compatible del lakehouse. Sin acción. La compactación en almacén es automática.
Archivos obsoletos de gran tamaño El número de archivos sigue siendo muy superior al objetivo adaptativo actual, y un número demasiado bajo de archivos limita el paralelismo en el escaneo. Reescribe la tabla usando una sobrescritura o CREATE OR REPLACE TABLE AS SELECT con el tamaño adaptativo del archivo de destino habilitado. Sin acción. El almacén gestiona el tamaño del archivo automáticamente.
Acumulación de vectores de deleción DESCRIBE HISTORY Las métricas muestran que los vectores de eliminación se añaden o actualizan más rápido de lo que la compactación los elimina, lo que podría aumentar la sobrecarga de lectura. Mantén la autocompactación activada. Si los vectores de eliminación se acumulan sin activar la compactación de archivos pequeños, programe OPTIMIZE. Úsalo REORG TABLE ... APPLY (PURGE) solo para requisitos explícitos de purga. Sin acción. La limpieza está gestionada por el sistema.
Salto pobre de archivos Los predicados selectivos escanean una gran parte de la tabla, o la evaluación de calidad por agrupamiento muestra una mala organización. Con Spark, configura el clúster líquido o usa Z-Order para una tabla particionada existente. Configurar la agrupación de datos del almacén.
Sobrecarga de transcodificación Direct Lake Delta Analyzer muestra un exceso excesivo de archivos, grupos de filas pequeños o una retranscodificación amplia tras las actualizaciones. Compactar archivos pequeños, revisar grupos de filas y aplicar el orden V a tablas escritas por Spark. Opcionalmente, configure la agrupación líquida para mejorar la calidad de la compresión en archivos Parquet. Mantén V-Order activado y evalúa el agrupamiento de datos.
Crecimiento del almacenamiento de archivos sin referencias El almacenamiento OneLake crece más rápido que el tamaño activo de la tabla tras operaciones de cambio de datos. Ejecute VACUUM de acuerdo con los requisitos de conservación. Sin acción. La limpieza está gestionada por el sistema.

Para los datos replicados, siga las instrucciones de corrección específicas del productor en Optimizar datos replicados. La duplicación de la base de datos la gestiona el sistema; para los catálogos duplicados, aplique el mantenimiento compatible en la plataforma de origen.

Para las tablas de lakehouse, las opciones de inspección compatibles con Spark incluyen:

  • Ejecuta DESCRIBE DETAIL para inspeccionar el recuento de archivos, el tamaño total y la propiedad evaluada delta.targetFileSize.adaptive .
  • Corre DESCRIBE HISTORY para revisar patrones de escritura e historial de mantenimiento.
  • Utiliza Delta Analyzer cuando necesites un análisis detallado de grupos de filas Direct Lake y de patrones de actualización.

Inspeccionar el tamaño medio del archivo

Úsase DESCRIBE DETAIL para calcular el tamaño medio del archivo como indicador inicial de la disposición de la tabla:

details = spark.sql("DESCRIBE DETAIL schema_name.table_name").first()

table_size_gb = details["sizeInBytes"] / (1024**3)
num_files = details["numFiles"]
avg_file_size_mb = (
    details["sizeInBytes"] / num_files / (1024**2)
    if num_files
    else 0
)

print(f"Table size: {table_size_gb:.2f} GB")
print(f"Number of files: {num_files}")
print(f"Average file size: {avg_file_size_mb:.2f} MB")

Un promedio puede ocultar el desfase entre particiones o archivos recientes y previamente compactados. Si la media indica un posible problema de organización, inspecciona los archivos Parquet individuales o utiliza Delta Analyzer para evaluar la distribución antes de cambiar la configuración de mantenimiento.

Cuándo crear otra tabla

No crees otra tabla física solo porque varios motores Fabric consumen los datos.

Crea otra tabla cuando tenga un propósito independiente, como:

  • Una transformación o agregación que cambia el grano o el significado empresarial de los datos.
  • Diferentes requisitos de seguridad, retención o calidad de datos.
  • Un requisito de latencia o actualización que la tabla compartida no puede cumplir.
  • Un diseño específico para el consumidor cuyo beneficio medido supera sus costes de almacenamiento, procesamiento, linaje y gobernanza.

Contenido relacionado

  • Last updated on