Consideraciones sobre el rendimiento del punto de conexión de SQL Analytics

El punto de conexión de SQL Analytics permite consultar datos en lakehouse mediante el lenguaje T-SQL y el protocolo TDS. Aprovecha el motor Fabric Data Warehouse.

Tip

Para obtener instrucciones completas para cargas de trabajo cruzadas sobre la optimización de tablas Delta para el consumo del endpoint de SQL Analytics, consulte Mantenimiento y optimización de tablas para cargas de trabajo cruzadas, incluidas las recomendaciones de tamaño de archivo y grupo de filas.

Cada lakehouse tiene un punto de análisis SQL. El número de puntos de conexión de SQL Analytics en un área de trabajo coincide con el número de lakehouses y bases de datos reflejadas aprovisionadas en dicha área de trabajo.

Un proceso en segundo plano se encarga de examinar el lakehouse en busca de cambios y de mantener actualizado el punto de conexión de análisis de SQL para todos los cambios guardados en los lakehouses de un área de trabajo. La plataforma Fabric gestiona de forma transparente el proceso de sincronización. Cuando se detecta un cambio en un lakehouse, un proceso en segundo plano actualiza los metadatos y el punto de conexión de SQL Analytics refleja los cambios confirmados en las tablas del lakehouse. En condiciones de funcionamiento normales, el retraso entre un punto de conexión de lakehouse y SQL Analytics es inferior a un minuto. La duración real del tiempo puede variar de unos segundos a minutos en función de muchos factores que se describen en este artículo. El proceso en segundo plano se ejecuta mientras el endpoint de analítica SQL está activo y se detiene tras 15 minutos sin actividad de consulta.

Instrucciones

  • La detección automática de metadatos realiza un seguimiento de los cambios confirmados en lakehouses, y hay una sola instancia por espacio de trabajo de Fabric. Si observa una mayor latencia en la sincronización de los cambios entre los lakehouses y el punto de conexión de análisis de SQL, podría deberse a un gran número de lakehouses en un área de trabajo. En este escenario, considere migrar cada lakehouse a un espacio de trabajo independiente, ya que este enfoque permite ampliar a escala el descubrimiento automático de metadatos.
  • Los archivos Parquet son inmutables por su diseño. Cuando hay una operación de actualización o eliminación, una tabla Delta agrega nuevos archivos Parquet con el conjunto de cambios, lo que aumenta el número de archivos a lo largo del tiempo, en función de la frecuencia de actualizaciones y eliminaciones. Si no programa el mantenimiento, este patrón crea finalmente una sobrecarga de lectura y esta condición afecta al tiempo necesario para sincronizar los cambios en el punto de conexión de SQL Analytics. Para solucionar este problema, programe las operaciones de mantenimiento de tablas de Lakehouse normales.
  • En algunos escenarios, podría observar que los cambios confirmados en un lakehouse no son visibles en el endpoint de SQL Analytics asociado. Por ejemplo, puede crear una nueva tabla en lakehouse, pero aún no aparece en el punto de conexión de SQL Analytics. O bien, podría insertar un gran número de filas en una tabla de un lakehouse, pero estos datos aún no están visibles en el punto de conexión de análisis de SQL. Puedes iniciar la sincronización de metadatos bajo demanda en el portal de Fabric o usar la API REST para actualizar los metadatos del punto de conexión de análisis de SQL.
  • El proceso de sincronización automática no admite todas las características delta. Para obtener más información sobre la funcionalidad admitida por cada motor en Fabric, consulte Interoperabilidad con formato de tabla delta Lake.
  • Si hay un volumen extremadamente grande de cambios en las tablas durante el procesamiento de extracción, transformación y carga (ETL), se produce el retraso previsto hasta que se hayan procesado todos los cambios.

Optimización de tablas de lakehouse para consultar el punto de conexión de SQL Analytics

Cuando el punto de conexión de SQL Analytics lee las tablas almacenadas en un lago, el rendimiento de las consultas depende en gran medida del diseño físico de los archivos Parquet subyacentes. El motor paraleliza los escaneos a nivel de archivo Parquet. Demasiados archivos pequeños aumentan la sobrecarga de archivos y metadatos, mientras que muy pocos archivos grandes pueden limitar el paralelismo de escaneo.

Para las tablas escritas por Spark, usa la configuración predeterminada en Fabric Spark runtime 2.0 o posterior. Estos tiempos de ejecución permiten por defecto un tamaño adaptativo de archivo destino para seleccionar el tamaño de archivo objetivo más óptimo por tabla, desde 128 MB para tablas más pequeñas hasta 1 GB para las tablas más grandes. Evita establecer objetivos estáticos o un límite arbitrario de recuento de filas sobre las configuraciones predeterminadas. Un límite de filas no tiene en cuenta el ancho de fila y puede crear archivos pequeños para tablas estrechas.

Si usas Fabric Spark runtime 1.3, activa el tamaño adaptativo del archivo objetivo y los objetivos de compactación a nivel de archivo, que están disponibles como funciones opt-in.

V-Order beneficia principalmente a Power BI Direct Lake y, aunque puede mejorar la compresión para algunas cargas de trabajo, generalmente no es necesario ni recomendado por defecto para un rendimiento óptimo en endpoints de análisis SQL.

Los ajustes de escritura por defecto no sustituyen el mantenimiento de tablas. Utiliza las siguientes prácticas para mantener una distribución saludable a medida que cambian las mesas:

  • Activa la autocompactación para cargas de trabajo donde la latencia periódica añadida de escritura síncrona sea aceptable. La autocompactación es una función de Spark que solo se ejecuta cuando hay demasiados archivos pequeños en una tabla.
  • Programe tareas periódicas OPTIMIZE para cargas de trabajo en las que la latencia periódica adicional de la compactación automática no cumpla los SLA de actualización de datos.
  • Ejecuta VACUUM según tus requisitos de retención y desplazamiento temporal para eliminar los archivos a los que el registro Delta ya no hace referencia. VACUUM reduce el almacenamiento retenido pero no mejora la disposición activa del archivo.
  • Evita la partición de alta cardinalidad y las configuraciones personalizadas de escritura que generan muchos archivos pequeños.

Si no usas la autocompactación, para identificar tablas que necesitan mantenimiento, utiliza una tubería de datos y el sys.sp_get_table_health_metrics procedimiento almacenado T-SQL antes de ejecutar OPTIMIZE. Para ver un tutorial, consulte Optimize Lakehouse tables based on health checks (Optimización de tablas de Lakehouse en función de las comprobaciones de estado).

Note

Para obtener instrucciones sobre el mantenimiento general de las tablas de lakehouse, consulte Ejecución del mantenimiento de tablas desde Lakehouse.

Consideraciones sobre el tamaño de partición

La disposición de las particiones afecta cuánto tarda el endpoint de analítica SQL en descubrir y sincronizar los cambios. Un gran número de particiones o pequeños archivos Parquet aumenta la sobrecarga de escaneo de metadatos. Siga estos procedimientos:

Para evaluar el tamaño y el número de archivos de cada partición, utiliza el script de ejemplo para los detalles de la partición.

Script de ejemplo para los detalles de la partición

Utiliza el siguiente cuaderno para imprimir un informe detallando el tamaño y los detalles de las particiones que sustentan una tabla Delta.

  1. Primero, proporciona la ruta ABFSS para tu tabla Delta en la variable delta_table_path.
    • Puede obtener la ruta de acceso ABFSS de una tabla Delta desde el Explorador del portal de Microsoft Fabric. Haga clic con el botón derecho en el nombre de la tabla y, a continuación, seleccione COPY PATH en la lista de opciones.
  2. El script genera todas las particiones de la tabla Delta.
  3. El script recorre en iteración cada partición para calcular el tamaño total y el número de archivos.
  4. El script genera los detalles de las particiones, los archivos por partición y el tamaño por partición en GB.

Puede copiar el script completo desde el siguiente bloque de código:

# Purpose: Print out details of partitions, files per partitions, and size per partition in GB.
from notebookutils import mssparkutils

# Define ABFSS path for your delta table. You can get ABFSS path of a delta table by simply right-clicking on table name and selecting COPY PATH from the list of options.
delta_table_path = "abfss://<workspace id>@<onelake>.dfs.fabric.microsoft.com/<lakehouse id>/Tables/<tablename>"

# List all partitions for given delta table
partitions = mssparkutils.fs.ls(delta_table_path)

# Initialize a dictionary to store partition details
partition_details = {}

# Iterate through each partition
for partition in partitions:
  if partition.isDir:
      partition_name = partition.name
      partition_path = partition.path
      files = mssparkutils.fs.ls(partition_path)
      
      # Calculate the total size of the partition

      total_size = sum(file.size for file in files if not file.isDir)
      
      # Count the number of files

      file_count = sum(1 for file in files if not file.isDir)
      
      # Write partition details

      partition_details[partition_name] = {
          "size_bytes": total_size,
          "file_count": file_count
      }
      
# Print the partition details
for partition_name, details in partition_details.items():
  print(f"{partition_name}, Size: {details['size_bytes']:.2f} bytes, Number of files: {details['file_count']}")

Contenido relacionado

  • Last updated on