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

En este artículo se presentan los conceptos de almacenamiento de Direct Lake. Se describen 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, Kustoy 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.

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. Pero 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 proceso acceden a los archivos Parquet mediante la consulta de 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.

Control de versiones 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 el 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, como cuando se insertan, actualizan o eliminan datos, se crean archivos Parquet, que representan las modificaciones de datos como una versión. 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 se usa en este artículo para explicar diferentes operaciones de modificación de datos. La tabla tiene dos columnas y almacena tres filas.

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 han insertado los datos (anexados).

• Archivo Parquet 1:
  • ProductID: A, B, C
  • StockOnHand: 1, 2, 3
• Archivo de vínculo 1:
  • Contiene la marca de tiempo de cuándo se ha creado Parquet file 1 y registra que se han anexado datos.

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 existencias disponibles de 4. Estas operaciones producen la creación de un 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 de cuándo se ha creado Parquet file 1 y registra que se han anexado datos.
• Archivo de vínculo 2:
  • Contiene la marca de tiempo de cuándo se ha creado Parquet file 2 y registra que se han anexado datos.

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

En cada operación de inserción posterior se crean archivos Parquet y archivos de vínculo. Esto significa que el número de archivos Parquet y archivos de vínculo crece con cada operación de inserción.

Operaciones de actualización

Ahora, tenga en cuenta lo que sucede cuando se produce una operación de actualización:en la fila del producto D su valor de existencias disponible se cambia a 10. Estas operaciones producen la creación de un 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 de cuándo se ha creado Parquet file 1 y registra que se han anexado datos.
• Archivo de vínculo 2:
  • Contiene la marca de tiempo de cuándo se ha creado Parquet file 2 y registra que se han anexado datos.
• Archivo de vínculo 3:
  • Contiene la marca de tiempo de cuándo se ha creado Parquet file 3 y registra que se han actualizado datos.

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

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

Delete operations (Operaciones de eliminación)

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 produce la creación de un 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 vínculo 1:
  • Contiene la marca de tiempo de cuándo se ha creado Parquet file 1 y registra que se han anexado datos.
• Archivo de vínculo 2:
  • Contiene la marca de tiempo de cuándo se ha creado Parquet file 2 y registra que se han anexado datos.
• Archivo de vínculo 3:
  • Contiene la marca de tiempo de cuándo se ha creado Parquet file 3 y registra que se han actualizado datos.
• Archivo de vínculo 4:
  • Contiene la marca de tiempo de cuándo se ha creado Parquet file 4 y registra que se han eliminado esos datos.

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

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

Viaje en el tiempo de 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.

Considere los ejemplos de consulta siguientes.

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

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

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

Enmarcar

El entramado es una operación de Direct Lake que establece la versión de una tabla Delta que se debe usar para cargar datos en una columna de modelo semántico. Igualmente importante, la versión también determina lo que se debe excluir 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 enmarcado).

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 de manera conjunta en un único conjunto de archivos Parquet. Las particiones pueden acelerar las consultas, así como las operaciones de escritura.

Imagine una tabla Delta que tiene mil millones de filas de datos de ventas para un período de dos años. Aunque es posible almacenar todos los datos en un único conjunto de archivos Parquet, en el caso de este volumen de datos no es óptimo para 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.

Al configurar la creación de particiones de tablas se debe definir una clave de partición. La clave de partición determina qué filas se van a almacenar en cada serie. Para las tablas Delta, la clave de partición se puede definir en función de los valores distintos de una columna (o columnas) especificada, como una columna de mes y 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 de proceso de Fabric no son conscientes de las particiones de tabla. A medida que insertan nuevos valores de clave de partición, las 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, lo que da lugar a un mejor rendimiento de lectura.

Pero es posible que las consultas que no filtren por la clave de partición no siempre funcionen mejor. Esto puede suceder 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 desde varios archivos Parquet entre 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 la creación de particiones de 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 ello.

La creación de particiones también es beneficiosa para las operaciones de inserción, actualización y eliminación, ya que la actividad de archivo 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. Después, los datos solo se dirigen a las carpetas pertinentes para las particiones.

Comprender cómo se usan las particiones en las tablas Delta pueden ayudarle a diseñar escenarios ETL óptimos que reducen las operaciones de escritura que se deben realizar al actualizar tablas delta grandes. El rendimiento de escritura mejora al reducir el número y el tamaño de los archivos Parquet que se deben crear. En el caso de una tabla Delta grande con particiones por mes o año, como se ha descrito en el ejemplo anterior, los nuevos datos solo agregan archivos Parquet nuevos 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.

En el caso de los modelos semánticos de Direct Lake o el punto de conexión de análisis SQL, la mejor manera de optimizar las particiones de tabla delta consiste en permitir que Fabric administre automáticamente los archivos Parquet para cada versión de una tabla Delta. Dejar la administración a Fabric debe dar lugar a un rendimiento alto de las consultas mediante 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. Pero tenga en cuenta que la creación de particiones de una tabla Delta puede afectar negativamente al rendimiento de lectura. Por este motivo, se recomienda probar cuidadosamente el rendimiento de lectura y escritura, posiblemente mediante la creación de varias copias de la misma tabla Delta con configuraciones diferentes para comparar los intervalos.

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. Se crean archivos Parquet 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.

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 los organiza por columnas. Además, el formato de archivo Parquet difiere de estos formatos porque organiza las 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 tienen 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 memoria. De hecho, se pueden cargar en segundos volúmenes de datos muy grandes. Compare esta funcionalidad con la actualización de un modelo semántico de importación que debe recuperar bloques o datos de origen, después procesarlos, codificarlos y almacenarlos, y luego cargarlos en 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. Pero con las tablas Delta, la mayor parte del esfuerzo de 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 conjunto de datos de ejemplo siguiente.

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 valores iguales en una representación más pequeña. En el ejemplo siguiente, se crea una asignación de diccionario de claves numéricas a valores en el encabezado y se usan los valores de clave más pequeños 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 StockOnHand agrupada por ProductID, solo se necesitan 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.

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 V-Order, da como resultado un archivo más pequeño y, por tanto, más rápido de 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 memoria y necesita menos recursos de capacidad. También da como resultado un rendimiento más rápido de la consulta, 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 al que se haya aplicado V-Order.

Para obtener más información, consulte Optimización de la tabla de Delta Lake yV-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 tanto, considere la posibilidad de limitar el recuento de filas de una tabla de hechos grande mediante el aumento de su granularidad (almacenar datos resumidos), la reducción de la dimensionalidad o el almacenamiento de menos historial.

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

Tipo de datos de la columna

Intente reducir la cardinalidad (el número de valores únicos) en todas las columnas de cada tabla Delta. Esto se debe a que todas las columnas se comprimen y almacenan mediante codificación hash. La codificación hash necesita la optimización V-Order 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

Como sucede con cualquier tabla de datos, las tablas Delta solo deben almacenar las 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 las columnas necesarias para 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 memoria), dan lugar a un tamaño de almacenamiento mayor y, por tanto, necesitan más recursos de proceso para la carga y el mantenimiento.

Como 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 no es el patrón adecuado para los modelos semánticos de importación y DirectQuery. Por ejemplo, si tiene las columnas FirstName y LastName, 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 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 fragmentarlas en tres grupos, 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 número mayor de grupos de filas con menos filas afecte negativamente a la carga de datos de columna en un modelo semántico debido a una E/S excesiva.

Por lo general, no se recomienda cambiar el tamaño predeterminado del grupo de filas. Pero podría considerar 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, posiblemente mediante la creación de varias copias de la misma tabla Delta con configuraciones diferentes para comparar los intervalos.

Mantenimiento de tablas delta

Con el tiempo, a medida que se realizan operaciones de escritura, se acumulan las versiones de la tabla Delta. En última instancia, podría llegar a un punto en el que el impacto negativo en el rendimiento de lectura sea evidente. 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 tanto, es importante mantener las tablas Delta con regularidad.

OPTIMIZE

Puede usar OPTIMIZE para optimizar una tabla Delta a fin de fusionar los archivos más pequeños en otros más grandes. También puede establecer la cláusula WHERE como destino de 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, posiblemente de manera diaria cuando se complete el proceso de ETL. Establezca un equilibrio entre un mejor rendimiento de las consultas y el costo del uso de recursos necesarios para optimizar la tabla.

VACUUM

Puede usar VACUUM para quitar archivos a los que ya no se hace referencia o que sean 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.

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.

Mantenimiento automático de las tablas

Para automatizar las operaciones de mantenimiento de tablas, puede usar Lakehouse API. Para más información, vea Administración del almacén de lago de datos con la API REST de Microsoft Fabric.

Contenido relacionado

• Introducción a Direct Lake
• Desarrollo de modelos semánticos de Direct Lake
• Administración de modelos semánticos de Direct Lake
• Optimización de tablas de Delta Lake y orden V