Compartir a través de

Descripción del almacenamiento para los modelos semánticos de Direct Lake

  • Artículo

En este artículo se presentan los conceptos de almacenamiento de Direct Lake. El texto describe las tablas Delta y los archivos Parquet. También se describe cómo puede optimizar las tablas Delta para los modelos semánticos de Direct Lake y cómo puede mantenerlas para ayudar a ofrecer un rendimiento confiable y rápido de las consultas.

Tablas delta

Las tablas delta existen en OneLake. Organizan los datos basados en archivos en filas y columnas, y están disponibles para los motores de proceso de Microsoft Fabric, como los de cuadernos, Kusto y almacén de lago de datos y almacén. Puede consultar tablas delta mediante expresiones de análisis de datos (DAX), expresiones multidimensionales (MDX), T-SQL (Transact-SQL), Spark SQL e incluso Python.

Nota

Delta ( o Delta Lake) es un formato de almacenamiento de código abierto. Esto significa que Fabric también puede consultar tablas delta creadas por otras herramientas y proveedores.

Las tablas Delta almacenan sus datos en archivos Parquet, que normalmente se almacenan en un almacén de lago de datos que usa un modelo semántico de Direct Lake para cargar datos. Sin embargo, los archivos Parquet también se pueden almacenar externamente. Se puede hacer referencia a los archivos Parquet externos mediante un acceso directo de OneLake, que apunta a una ubicación de almacenamiento específica, como Azure Data Lake Storage (ADLS) Gen2, cuentas de almacenamiento de Amazon S3 o Dataverse. En casi todos los casos, los motores de cálculo acceden a los archivos Parquet realizando consultas en tablas Delta. Pero normalmente los modelos semánticos de Direct Lake cargan datos de columna directamente desde archivos Parquet optimizados en OneLake mediante un proceso conocido como transcodificación.

Versionado de datos

Las tablas Delta constan de uno o varios archivos Parquet. Estos archivos van acompañados de un conjunto de archivos de vínculo basados en JSON, que realizan un seguimiento del orden y la naturaleza de cada archivo Parquet asociado a una tabla Delta.

Es importante comprender que los archivos Parquet subyacentes son incrementales por naturaleza. De ahí el nombre Delta como referencia a la modificación incremental de datos. Cada vez que se produce una operación de escritura en una tabla Delta(por ejemplo, cuando se insertan, actualizan o eliminan los datos), se crean nuevos archivos Parquet que representan las modificaciones de datos como una versión de . Por tanto, los archivos Parquet son inmutables, lo que significa que nunca se modifican. Por ese motivo, es posible que los datos se dupliquen muchas veces en un conjunto de archivos Parquet para una tabla Delta. El marco Delta se basa en archivos de vínculo para determinar qué archivos físicos de Parquet son necesarios para generar el resultado de consulta correcto.

Considere un ejemplo sencillo de una tabla Delta que usa este artículo para explicar diferentes operaciones de modificación de datos. La tabla tiene dos columnas y almacena tres filas.

Id. de producto StockOnHand
A 1
B 2
C 3

Los datos de la tabla Delta se almacenan en un único archivo Parquet que contiene todos los datos y hay un único archivo de vínculo que contiene metadatos sobre cuándo se insertaron los datos (anexados).

  • Archivo Parquet 1:
    • ProductID: A, B, C
    • StockOnHand: 1, 2, 3
  • Archivo de vínculo 1:
    • Contiene la marca de tiempo cuando se creó Parquet file 1 y registra los datos que se anexaron.

Operaciones de inserción

Tenga en cuenta lo que ocurre cuando se produce una operación de inserción: se inserta una nueva fila para el producto C con un valor de stock a mano de 4. Estas operaciones producen la creación de un nuevo archivo Parquet y un archivo de vínculo, por lo que ahora hay dos archivos Parquet y dos archivos de vínculo.

  • Archivo Parquet 1:
    • ProductID: A, B, C
    • StockOnHand: 1, 2, 3
  • Archivo Parquet 2:
    • ProductID: D
    • StockOnHand: 4
  • Archivo de vínculo 1:
    • Contiene la marca de tiempo cuando se creó Parquet file 1 y registra los datos que se anexaron.
  • Archivo de vínculo 2:
    • Contiene la marca de tiempo cuando se creó Parquet file 2 y registra los datos que se anexaron.

En este momento, una consulta de la tabla Delta devuelve el resultado siguiente. No importa que el resultado se derive de varios archivos Parquet.

ProductID StockOnHand
A 1
B 2
C 3
D 4

Cada operación de inserción posterior crea nuevos archivos Parquet y archivos de vínculo. Esto significa que el número de archivos Parquet y archivos de enlace crece con cada operación de inserción.

Operaciones de actualización

Ahora considere lo que ocurre cuando se produce una operación de actualización: la fila del producto D tiene su valor de existencias en la mano cambiado a 10. Estas operaciones producen la creación de un nuevo archivo Parquet y un archivo de vínculo, por lo que ahora hay tres archivos Parquet y tres archivos de vínculo.

  • Archivo Parquet 1:
    • ProductID: A, B, C
    • StockOnHand: 1, 2, 3
  • Archivo Parquet 2:
    • ProductID: D
    • StockOnHand: 4
  • Archivo Parquet 3:
    • ProductID: C
    • StockOnHand: 10
  • Archivo de vínculo 1:
    • Contiene la marca de tiempo cuando se creó Parquet file 1 y registra los datos que se anexaron.
  • Archivo de enlace 2:
    • Contiene la marca de tiempo cuando se creó Parquet file 2 y registra los datos que se anexaron.
  • Archivo de enlace 3:
    • Contiene la marca de tiempo cuando se creó Parquet file 3 y registra los datos que se actualizaron.

En este momento, una consulta de la tabla Delta devuelve el resultado siguiente.

ProductID StockOnHand
A 1
B 2
C 10
D 4

Los datos del producto C ahora existen en varios archivos Parquet. Sin embargo, las consultas en la tabla Delta combinan los archivos de vínculo para determinar qué datos se deben usar para proporcionar el resultado correcto.

Eliminar operaciones

Ahora tenga en cuenta lo que sucede cuando se produce una operación de eliminación: se elimina la fila del producto B. Esta operación da como resultado un nuevo archivo Parquet y un archivo de vínculo, por lo que ahora hay cuatro archivos Parquet y cuatro archivos de vínculo.

  • Archivo Parquet 1:
    • ProductID: A, B, C
    • StockOnHand: 1, 2, 3
  • Archivo Parquet 2:
    • ProductID: D
    • StockOnHand: 4
  • Archivo Parquet 3:
    • ProductID: C
    • StockOnHand: 10
  • Archivo Parquet 4:
    • ProductID: A, C, D
    • StockOnHand: 1, 10, 4
  • Archivo de enlace 1:
    • Contiene la marca de tiempo cuando se creó Parquet file 1 y registra los datos que se anexaron.
  • Archivo de enlace 2:
    • Contiene la marca de tiempo cuando se creó Parquet file 2 y registra los datos que se anexaron.
  • Archivo de vínculo 3:
    • Contiene la marca de tiempo cuando se creó Parquet file 3 y registra los datos que se actualizaron.
  • Archivo de vínculo 4:
    • Contiene la marca de tiempo cuando se creó Parquet file 4 y registra los datos que se eliminaron.

Tenga en cuenta que Parquet file 4 ya no contiene datos para el producto B, pero sí contiene datos para todas las demás filas de la tabla.

En este momento, una consulta de la tabla Delta devuelve el resultado siguiente.

ID de Producto StockOnHand
A 1
C 10
D 4

Nota

Este ejemplo es sencillo porque implica una tabla pequeña, solo algunas operaciones y solo modificaciones menores. Las tablas grandes que experimentan muchas operaciones de escritura y que contienen muchas filas de datos generarán más de un archivo Parquet por versión.

Importante

Dependiendo de cómo defina sus tablas Delta y la frecuencia con la que realice operaciones de modificación de datos, podría dar lugar a numerosos ficheros Parquet. Tenga en cuenta que cada licencia de capacidad de Fabric tiene límites de protección. Si el número de archivos Parquet para una tabla Delta supera el límite de la SKU, las consultas revertirán a DirectQuery, lo que podría dar lugar a un rendimiento más lento de las consultas.

Para administrar el número de archivos Parquet, vea Mantenimiento de tablas Delta más adelante en este artículo.

Viaje en el tiempo Delta

Los archivos de vínculo permiten consultar datos a partir de un momento dado anterior. Esta funcionalidad se conoce como viaje en el tiempo de Delta. El momento anterior en el tiempo podría ser una marca de tiempo o una versión.

Tenga en cuenta los ejemplos de consulta siguientes.

SELECT * FROM Inventory TIMESTAMP AS OF '2024-04-28T09:15:00.000Z';
SELECT * FROM Inventory AS OF VERSION 2;

Sugerencia

También puede consultar una tabla utilizando la sintaxis abreviada @ para especificar la marca de tiempo o la versión como parte del nombre de la tabla. La marca de tiempo debe estar en formato yyyyMMddHHmmssSSS. Puede especificar una versión después de @ si antepone v a la versión.

Estos son los ejemplos de consulta anteriores reescritos con sintaxis abreviada.

SELECT * FROM Inventory@20240428091500000;
SELECT * FROM Inventory@v2;

Importante

Las versiones de tabla accesibles con el viaje en el tiempo se determinan mediante una combinación del umbral de retención para los archivos de registro de transacciones y la frecuencia y la retención especificadas para las operaciones VACUUM (que se describen más adelante en la sección Mantenimiento de tablas Delta). Si ejecuta VACUUM diariamente con los valores predeterminados, siete días de datos estarán disponibles para el viaje en el tiempo.

Enmarcar

Framing es una operación de Direct Lake que establece la versión de una tabla Delta que se debe usar para cargar datos en la columna de un modelo semántico. Igualmente importante, la versión también determina lo que debe excluirse cuando se cargan los datos.

Una operación de enmarcado marca la marca de tiempo o la versión de cada tabla Delta en las tablas del modelo semántico. Desde este punto, cuando el modelo semántico necesita cargar datos desde una tabla Delta, se usa la marca de tiempo o la versión asociada a la operación de enmarcado más reciente para determinar qué datos se van a cargar. Las modificaciones de datos posteriores que se producen para la tabla Delta desde la última operación de enmarcado se omiten (hasta la siguiente operación de marco).

Importante

Dado que un modelo semántico enmarcado hace referencia a una versión determinada de la tabla Delta, el origen debe asegurarse de que mantiene esa versión de la tabla Delta hasta que se complete el marco de una nueva versión. De lo contrario, los usuarios encontrarán errores cuando los archivos de tabla Delta necesiten ser accedidos por el modelo y hayan sido limpiados o eliminados de otro modo por la carga de trabajo del productor.

Para más información sobre el enmarcado, vea Introducción a Direct Lake.

Partición de tablas

Las tablas delta se pueden particionar para que un subconjunto de filas se almacenen juntos en un único conjunto de archivos Parquet. Las particiones pueden acelerar las consultas, así como las operaciones de escritura.

Considere una tabla Delta que tiene mil millones de filas de datos de ventas durante un período de dos años. Aunque es posible almacenar todos los datos en un único conjunto de archivos Parquet, no es óptimo para este volumen de datos en cuanto a las operaciones de lectura y escritura. En su lugar, el rendimiento se puede mejorar si se propagan los mil millones de filas de datos entre varias series de archivos Parquet.

Se debe definir una clave de partición al configurar el particionamiento de tablas. La clave de partición determina qué filas se van a almacenar en qué serie. Para las tablas Delta, la clave de partición se puede definir en función de los valores distintos de una columna especificada (o columnas), como una columna de mes/año de una tabla de fechas. En este caso, dos años de datos se distribuirían entre 24 particiones (2 años x 12 meses).

Los motores informáticos de Fabric no son conscientes de las particiones de tabla. A medida que insertan nuevos valores de clave de partición, las nuevas particiones se crean automáticamente. En OneLake, encontrará una subcarpeta para cada valor de clave de partición único y cada subcarpeta almacena su propio conjunto de archivos Parquet y archivos de vínculo. Debe existir al menos un archivo Parquet y un archivo de vínculo, pero el número real de archivos de cada subcarpeta puede variar. A medida que se realizan operaciones de modificación de datos, cada partición mantiene su propio conjunto de archivos Parquet y archivos de vínculo para realizar el seguimiento de lo que se va a devolver para una marca de tiempo o una versión determinada.

Si una consulta de una tabla Delta con particiones se filtra solo por los últimos tres meses de datos de ventas, el subconjunto de archivos Parquet y archivos de vínculo a los que se debe acceder se pueden identificar rápidamente. Después, permite omitir muchos archivos Parquet por completo, lo que da lugar a un mejor rendimiento de lectura.

Sin embargo, es posible que las consultas que no filtren por la clave de partición no siempre funcionen mejor. Esto puede ser el caso cuando una tabla Delta almacena todos los datos en un único conjunto grande de archivos Parquet y hay fragmentación de archivos o grupos de filas. Aunque es posible paralelizar la recuperación de datos de varios archivos Parquet en varios nodos de clúster, muchos archivos pequeños de Parquet pueden afectar negativamente a la E/S de archivos y, por tanto, al rendimiento de las consultas. Por este motivo, es mejor evitar particionar las tablas Delta en la mayoría de los casos, a menos que los procesos de escritura o extracción, transformación y carga (ETL) se beneficien claramente de ellas.

Las particiones también benefician las operaciones de inserción, actualización y eliminación, ya que la actividad sobre los archivos solo tiene lugar en subcarpetas que coinciden con la clave de partición de las filas modificadas o eliminadas. Por ejemplo, si se inserta un lote de datos en una tabla Delta con particiones, los datos se evalúan para determinar qué valores de clave de partición existen en el lote. Luego, los datos se dirigen únicamente a las carpetas relevantes correspondientes a las particiones.

Comprender cómo las tablas Delta usan particiones pueden ayudarle a diseñar escenarios ETL óptimos que reducen las operaciones de escritura que deben realizarse al actualizar tablas delta grandes. El rendimiento de escritura mejora al reducir el número y el tamaño de los nuevos archivos Parquet que se deben crear. En el caso de una tabla Delta grande con particiones por mes o año, como se describe en el ejemplo anterior, los nuevos datos solo agregan nuevos archivos Parquet a la partición más reciente. Las subcarpetas de los meses naturales anteriores permanecen intactas. Si se deben modificar datos de meses naturales anteriores, solo las carpetas de partición pertinentes reciben nuevos archivos de partición y vínculo.

Importante

Si el propósito principal de una tabla Delta es servir como origen de datos para modelos semánticos (y secundariamente, otras cargas de trabajo de consulta), normalmente es mejor evitar la creación de particiones en preferencia para optimizar la carga de columnas en memoria.

En el caso de los modelos semánticos de Direct Lake o el punto final de análisis de SQL , la mejor manera de optimizar las particiones de la tabla Delta es permitir que Fabric administre automáticamente los archivos Parquet para cada versión de una Tabla Delta. Dejar la administración en Fabric debe dar lugar a un alto rendimiento de las consultas a través de la paralelización, pero podría no proporcionar necesariamente el mejor rendimiento de escritura.

Si debe optimizar las operaciones de escritura, considere la posibilidad de usar particiones para optimizar las operaciones de escritura en tablas Delta en función de la clave de partición. Sin embargo, tenga en cuenta que la sobrepartición de una tabla Delta puede afectar negativamente al rendimiento de lectura. Por este motivo, se recomienda probar cuidadosamente el rendimiento de lectura y escritura, quizá mediante la creación de varias copias de la misma tabla Delta con configuraciones diferentes para comparar los intervalos.

Advertencia

Si crea particiones en una columna de cardinalidad alta, puede dar lugar a un número excesivo de archivos Parquet. Tenga en cuenta que todas las licencias de capacidad de Fabric tienen límites de protección. Si el número de archivos Parquet para una tabla Delta supera el límite de la SKU, las consultas revertirán a DirectQuery, lo que podría dar lugar a un rendimiento más lento de las consultas.

Archivos de Parquet

El almacenamiento subyacente de una tabla Delta es uno o varios archivos Parquet. El formato de archivo Parquet se usa generalmente para aplicaciones deuna operación de escritura y varias de lectura. Los nuevos archivos Parquet se crean cada vez que se modifican los datos de una tabla Delta, ya sea mediante una operación de inserción, actualización o eliminación.

Nota

Puede acceder a los archivos Parquet asociados a tablas Delta mediante una herramienta, como el explorador de archivos de OneLake. Los archivos se pueden descargar, copiar o mover a otros destinos tan fácilmente como mover cualquier otro archivo. Sin embargo, es la combinación de los archivos Parquet y los archivos de vínculo basados en JSON lo que permite a los motores de procesamiento emitir consultas sobre los archivos como una tabla Delta.

Formato de archivo Parquet

El formato interno de un archivo Parquet difiere de otros formatos de almacenamiento de datos comunes, como CSV, TSV, XMLA y JSON. Estos formatos organizan los datos por filas, mientras que Parquet organiza los datos por columnas. Además, el formato de archivo Parquet difiere de estos formatos porque organiza filas de datos en uno o varios grupos de filas .

La estructura de datos interna de un modelo semántico de Power BI se basa en columnas, lo que significa que los archivos Parquet comparten mucho en común con Power BI. Esta similitud significa que un modelo semántico de Direct Lake puede cargar datos de forma eficaz desde los archivos Parquet directamente en la memoria. De hecho, los volúmenes de datos muy grandes se pueden cargar en segundos. Contraste esta funcionalidad con la actualización de un modelo semántico de importación que debe recuperar bloques o datos de origen, luego procesar, codificar, almacenar y, a continuación, cargarlo en la memoria. Una operación de actualización del modelo semántico de importación también puede consumir cantidades significativas de proceso (memoria y CPU) y tardar mucho tiempo en completarse. Sin embargo, con las tablas Delta, la mayor parte del esfuerzo por preparar los datos adecuados para la carga directa en un modelo semántico tiene lugar cuando se genera el archivo Parquet.

Almacenamiento de los datos en los archivos Parquet

Considere el siguiente conjunto de datos de ejemplo.

Fecha ProductID StockOnHand
16 de septiembre de 2024 A 10
16-09-2024 B 11
2024-09-17 A 13
…

Cuando se almacena en formato de archivo Parquet, conceptualmente, este conjunto de datos podría tener un aspecto similar al texto siguiente.

Header:
RowGroup1:
    Date: 2024-09-16, 2024-09-16, 2024-09-17…
    ProductID: A, B, A…
    StockOnHand: 10, 11, 13…
RowGroup2:
    …
Footer:

Los datos se comprimen mediante la sustitución de claves de diccionario para los valores comunes y la aplicación de codificación de longitud de ejecución (RLE). RLE se esfuerza por comprimir una serie de mismos valores en una representación más pequeña. En el siguiente ejemplo, se crea un diccionario que asigna llaves numéricas a valores en el encabezado, y se usan los valores de las llaves más pequeñas en lugar de los valores de datos.

Header:
    Dictionary: [
        (1, 2024-09-16), (2, 2024-09-17),
        (3, A), (4, B),
        (5, 10), (6, 11), (7, 13)
        …
    ]
RowGroup1:
    Date: 1, 1, 2…
    ProductID: 3, 4, 3…
    StockOnHand: 5, 6, 7…
Footer:

Cuando el modelo semántico de Direct Lake necesita datos para calcular la suma de la columna de StockOnHand agrupada por ProductID, solo se requieren el diccionario y los datos asociados a las dos columnas. En archivos grandes que contienen muchas columnas, se pueden omitir partes sustanciales del archivo Parquet para ayudar a acelerar el proceso de lectura.

Nota

El contenido de un archivo Parquet no es legible para humanos y, por tanto, no es adecuado para abrir en un editor de texto. Sin embargo, hay muchas herramientas de código abierto disponibles que pueden abrir y revelar el contenido de un archivo Parquet. Estas herramientas también pueden permitirle inspeccionar los metadatos, como el número de filas y grupos de filas contenidos en un archivo.

V-Order

Fabric admite una optimización adicional denominada V-Order. V-Order es una optimización en tiempo de escritura para el formato de archivo Parquet. Una vez que se aplica el orden V, da como resultado un archivo más pequeño y, por tanto, más rápido para leer. Esta optimización es especialmente relevante para un modelo semántico de Direct Lake porque prepara los datos para la carga rápida en la memoria, por lo que hace menos demandas de recursos de capacidad. También da como resultado un rendimiento de consulta más rápido porque es necesario examinar menos memoria.

Las tablas Delta creadas y cargadas por elementos de Fabric, como canalizaciones de datos, flujos de datosy cuadernos aplican V-Order de manera automática. Pero es posible que esta optimización no se aplique a los archivos Parquet cargados en un almacén de lago de datos de Fabric o a los que se hace referencia mediante un acceso directo. Aunque los archivos Parquet no optimizados todavía se pueden leer, es probable que el rendimiento de lectura no sea tan rápido como un archivo Parquet equivalente que haya aplicado V-Order.

Nota

Los archivos Parquet que tienen V-Order aplicados siguen siendo conformes al formato de archivo Parquet de código abierto. Por lo tanto, las herramientas que no son de Fabric pueden leerlos.

Para obtener más información, consulte Optimización de la tabla de Delta Lake y V-Order .

Optimización de tablas delta

En esta sección se describen varios temas para optimizar las tablas Delta para los modelos semánticos.

Volumen de datos

Aunque las tablas Delta pueden crecer para almacenar grandes volúmenes de datos, los límites de protección de capacidad de Fabric imponen límites para los modelos semánticos que las consultan. Cuando se superan esos límites, las consultas revertirán a DirectQuery, lo que podría dar lugar a un rendimiento más lento de las consultas.

Por lo tanto, considere limitar el recuento de filas de una gran tabla de hechos aumentando su granularidad (almacenar datos resumidos), reducir la dimensionalidad o almacenar menos historia.

Además, asegúrese de que se aplique Orden-V porque da como resultado un archivo más pequeño y, por tanto, más rápido de leer.

Tipo de datos de columna

Se esfuerza por reducir la cardinalidad (el número de valores únicos) en cada columna de cada tabla Delta. Esto se debe a que todas las columnas se comprimen y almacenan mediante codificación hash. La codificación hash requiere optimización de orden V para asignar un identificador numérico a cada valor único contenido en la columna. Por tanto, lo que se almacena es el identificador numérico, para lo que se necesita una búsqueda hash durante el almacenamiento y la consulta.

Al usar tipos de datos numéricos aproximados (como float y real), considere la posibilidad de redondear los valores y usar una precisión inferior.

Columnas innecesarias

Al igual que con cualquier tabla de datos, las tablas delta solo deben almacenar columnas necesarias. En el contexto de este artículo, esto significa que sean necesarias para el modelo semántico, aunque podría haber otras cargas de trabajo analíticas que consulten las tablas Delta.

Las tablas delta deben incluir columnas requeridas por el modelo semántico para filtrar, agrupar, ordenar y resumir, además de las columnas que admiten relaciones del modelo. Aunque las columnas innecesarias no afectan al rendimiento de las consultas del modelo semántico (porque no se cargarán en la memoria), dan lugar a un tamaño de almacenamiento mayor y, por tanto, requieren más recursos de proceso para cargar y mantener.

Dado que los modelos semánticos de Direct Lake no admiten columnas calculadas, debe materializar estas columnas en las tablas Delta. Tenga en cuenta que este enfoque de diseño es un antipatrón para los modelos semánticos import y DirectQuery. Por ejemplo, si tiene FirstName y LastName columnas, y necesita una columna FullName, materialice los valores de esta columna al insertar filas en la tabla Delta.

Tenga en cuenta que algunos resúmenes de modelos semánticos pueden depender de más de una columna. Por ejemplo, para calcular las ventas, la medida del modelo suma el producto de dos columnas: Quantity y Price. Si ninguna de estas columnas se usa de forma independiente, sería más eficaz materializar el cálculo de ventas como una sola columna que almacenar sus valores de componente en columnas independientes.

Tamaño de grupo de filas

Internamente, un archivo Parquet organiza las filas de datos en varios grupos de filas dentro de cada archivo. Por ejemplo, un archivo Parquet que contiene 30 000 filas podría fragmentarlos en tres grupos de filas, cada uno con 10 000 filas.

El número de filas de un grupo de filas influye en la rapidez con la que Direct Lake puede leer los datos. Es probable que un mayor número de grupos de filas con menos filas afecte negativamente a la carga de datos de columnas en un modelo semántico debido a un exceso de operaciones de entrada/salida (E/S).

Por lo general, no se recomienda cambiar el tamaño predeterminado del grupo de filas. Sin embargo, es posible que considere la posibilidad de cambiar el tamaño del grupo de filas para tablas delta grandes. Asegúrese de probar cuidadosamente el rendimiento de lectura y escritura, quizás mediante la creación de varias copias de las mismas tablas Delta con distintas configuraciones para comparar los intervalos.

Importante

Tenga en cuenta que todas las licencias de capacidad de Fabric tienen límites de protección. Si el número de grupos de filas de una tabla Delta supera el límite de la SKU, las consultas revertirán a DirectQuery, lo que podría dar lugar a un rendimiento de consultas más lento.

Mantenimiento de tablas delta

Con el tiempo, a medida que se realizan operaciones de escritura, se acumulan las versiones de la tabla Delta. Finalmente, podría llegar a un punto en el que un impacto negativo en el rendimiento de lectura se vuelve notable. Peor todavía, si el número de archivos Parquet por tabla, grupos de filas por tabla o filas por tabla supera los límites de protección para la capacidad, las consultas revertirán a DirectQuery, lo que podría dar lugar a un rendimiento más lento. Por lo tanto, es importante mantener las tablas Delta con regularidad.

OPTIMIZE

Puede usar OPTIMIZE para optimizar una tabla Delta para fusionar archivos más pequeños en otros más grandes. También puede establecer la cláusula WHERE como destino solo un subconjunto filtrado de filas que coincidan con un predicado de partición determinado. Solo se admiten filtros que impliquen claves de partición. El comando OPTIMIZE también puede aplicar V-Order para compactar y reescribir los archivos Parquet.

Se recomienda ejecutar este comando en tablas Delta grandes y actualizadas con frecuencia de forma periódica, quizás cada día cuando se complete el proceso de ETL. Equilibre el equilibrio entre un mejor rendimiento de las consultas y el costo del uso de recursos necesario para optimizar la tabla.

VACÍO

Puede usar VACUUM para quitar archivos a los que ya no se hace referencia o que son anteriores a un umbral de retención establecido. Asegúrese de establecer un período de retención adecuado; de lo contrario, podría perder la capacidad de viaje en el tiempo a una versión anterior a la del marco marcado en las tablas del modelo semántico.

Importante

Dado que un modelo semántico enmarcado hace referencia a una versión determinada de la tabla Delta, el origen debe asegurarse de que mantiene esa versión de la tabla Delta hasta que se complete el marco de una nueva versión. De lo contrario, los usuarios encontrarán errores cuando el modelo tenga acceso a los archivos de tabla Delta y se hayan vaciado o eliminado de otro modo por la carga de trabajo del productor.

REORG TABLE

Puede usar REORG TABLE para reorganizar una tabla Delta si reescribe los archivos para purgar los datos eliminados temporalmente, como cuando se elimina una columna mediante ALTER TABLE DROP COLUMN.

Automatización del mantenimiento de tablas

Para automatizar las operaciones de mantenimiento de tablas, puede usar lakehouse API. Para obtener más información, consulte Administrar el Lakehouse con la API REST de Microsoft Fabric.

Sugerencia

También puede usar la característica de mantenimiento de tablas del almacén de lago de datos en el portal de Fabric para simplificar la administración de las tablas Delta.

Contenido relacionado