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

Se aplica a:✅ Punto de conexión de análisis SQL en Microsoft Fabric

El punto de conexión de SQL Analytics permite consultar datos en el almacén de lago mediante el lenguaje T-SQL y el protocolo TDS.

Cada almacén de lago tiene un punto de conexión de SQL Analytics. El número de puntos de conexión de SQL Analytics en un área de trabajo coincide con el número de almacenes de lago y las bases de datos reflejadas aprovisionadas en esa área de trabajo.

Un proceso en segundo plano es responsable de examinar el almacén de lago para saber si hay cambios y mantener actualizado el punto de conexión de SQL Analytics en función de todos los cambios confirmados en los almacenes de lago de un área de trabajo. La plataforma Microsoft Fabric administra de forma transparente el proceso de sincronización. Cuando se detecta un cambio en un almacén de lago, 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 almacén de lago. En condiciones de funcionamiento normales, el retraso entre un punto de conexión de almacén de lago 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 solo se ejecuta cuando el punto de conexión de SQL Analytics está activo y se detiene después de 15 minutos de inactividad.

Esquema generado automáticamente en el punto de conexión de análisis SQL del almacén de lago

El punto de conexión de análisis SQL administra las tablas generadas automáticamente para que los usuarios del área de trabajo no puedan modificarlas. Los usuarios pueden enriquecer el modelo de base de datos agregando sus propios esquemas SQL, vistas, procedimientos y otros objetos de base de datos.

Para cada tabla delta del almacén de lago, el punto de conexión de análisis SQL genera automáticamente una tabla en el esquema adecuado. Para los tipos de datos de esquema generados automáticamente para el punto de conexión de análisis SQL, consulte Tipos de datos en Microsoft Fabric.

Las tablas del punto de conexión de análisis SQL se crean con un leve retraso. Una vez que creas o actualizas la tabla de Delta Lake en el lago, la tabla de punto de enlace de SQL Analytics que hace referencia a la tabla de Delta Lake se crea o actualiza automáticamente.

La cantidad de tiempo que se tarda en actualizar la tabla está relacionada con la optimización de las tablas Delta. Para obtener más información, revise Optimización de tablas y orden V de Delta Lake para aprender más sobre los escenarios clave y obtener una guía detallada sobre cómo mantener de forma eficaz las tablas Delta a fin de obtener el máximo rendimiento.

Puede forzar manualmente una actualización del examen automático de metadatos en el portal de Fabric. En la página del punto de conexión de SQL Analytics, seleccione el botón Actualizar de la barra de herramientas Explorador para actualizar el esquema. Vaya a Consulta del punto de conexión de SQL Analytics y busque el botón Actualizar, tal como se muestra en la imagen siguiente.

También puede forzar programáticamente una actualización del escaneo automático de metadatos usando la API REST de Actualización de metadatos del punto de conexión SQL.

Guía

La detección automática de metadatos realiza un seguimiento de los cambios confirmados en almacenes de lago y se tiene en cuenta una sola instancia por área de trabajo de Fabric. Si observa una mayor latencia para que los cambios se sincronicen entre lakehouses y el punto de conexión de SQL Analytics, podría deberse a un gran número de lakehouses en un espacio de trabajo. En este escenario, considere la posibilidad de migrar cada almacén de lago a un área de trabajo independiente, ya que esto permite escalar la detección automática 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 agregará nuevos archivos Parquet con el conjunto de cambios, lo que aumentará el número de archivos a lo largo del tiempo, en función de la frecuencia de actualizaciones y eliminaciones. Si no hay ningún proceso de mantenimiento programado, este patrón crea una sobrecarga de lectura y esto afecta al tiempo necesario para sincronizar los cambios en el punto de conexión de SQL Analytics. Para solucionar esto, programe las operaciones de mantenimiento de tablas de almacén de lago 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, podría haber creado una nueva tabla en lakehouse, pero aún no aparece en el punto de conexión de SQL Analytics. O bien, es posible que haya confirmado un gran número de filas en una tabla de un lakehouse, pero estos datos aún no están visibles en el endpoint de SQL Analytics. Se recomienda iniciar una sincronización de metadatos a petición, iniciada desde la opción Actualizar de la cinta del editor de consultas SQL o la API REST para actualizar metadatos del punto de conexión SQL. Esta opción fuerza una sincronización de metadatos a petición, en lugar de esperar a que finalice la sincronización de metadatos en segundo plano.
El proceso de sincronización automática no entiende todas las características de 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 podría producir un retraso esperado hasta que se procesen 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 lakehouse, el rendimiento de las consultas se ve muy influenciado por el diseño físico de los archivos parquet subyacentes.

Una gran cantidad de archivos parquet pequeños resulta en una sobrecarga y afecta negativamente al rendimiento de las consultas. Para garantizar un rendimiento predecible y eficaz, se recomienda mantener el almacenamiento de tablas para que cada archivo parquet contenga dos millones de filas. Este recuento de filas proporciona un nivel equilibrado de paralelismo sin fragmentar el conjunto de datos en segmentos excesivamente pequeños.

Además de la guía de recuento de filas, el tamaño del archivo es igualmente importante. El punto final de SQL Analytics funciona mejor cuando los archivos parquet son lo suficientemente grandes como para minimizar la sobrecarga de manejo de archivos, pero no tan grandes que limiten la eficiencia del escaneo paralelo. Para la mayoría de las cargas de trabajo, mantener los archivos parquet individuales cerca de 400 MB logra un buen equilibrio. Para lograr este equilibrio, siga estos pasos:

Establézcalo maxRecordsPerFile en 2000 000 antes de que se produzcan cambios en los datos.
Realice los cambios de datos (ingesta de datos, actualizaciones, eliminaciones).
Establézcalo maxFileSize en 400 MB.
Ejecute OPTIMIZE. Para obtener detalles sobre el uso de OPTIMIZE, consulte Operaciones de mantenimiento de tabla.

El siguiente script proporciona una plantilla para estos pasos y se debe ejecutar en un lakehouse:

from delta.tables import DeltaTable

# 1. CONFIGURE LIMITS

# Cap files to 2M rows during writes. This should be done before data ingestion occurs. 
spark.conf.set("spark.sql.files.maxRecordsPerFile", 2000000)

# 2. INGEST DATA
# Here, you ingest data into your table 

# 3. CAP FILE SIZE (~400 MB)
spark.conf.set("spark.databricks.delta.optimize.maxFileSize", 400 * 1024 * 1024)

# 4. RUN OPTIMIZE (bin-packing)
spark.sql("""
    OPTIMIZE myTable
""")

Para mantener tamaños de archivo correctos, los usuarios deben ejecutar periódicamente operaciones de optimización delta, como OPTIMIZE, especialmente para tablas que reciben escrituras incrementales frecuentes, actualizaciones y eliminaciones. Estas operaciones de mantenimiento compactan archivos pequeños en los de tamaño adecuado, lo que ayuda a garantizar que el punto de conexión de SQL Analytics pueda procesar consultas de forma eficaz.

Nota:

Para obtener instrucciones sobre el mantenimiento general de las tablas de lakehouse, consulte Ejecución del mantenimiento de tablas ad hoc en una tabla Delta mediante Lakehouse.

Consideraciones sobre el tamaño de partición

La elección de la columna de partición para una tabla Delta en un almacén de lago también afecta al tiempo que se tarda en sincronizar los cambios en el punto de conexión de SQL Analytics. El número y el tamaño de las particiones de la columna de partición son importantes para el rendimiento:

Una columna con alta cardinalidad (principalmente o completamente hecha de valores únicos) da como resultado un gran número de particiones. Un gran número de particiones afecta negativamente al rendimiento del examen de detección de metadatos para los cambios. Si la cardinalidad de una columna es alta, elija otra columna para la creación de particiones.
El tamaño de cada partición también puede afectar al rendimiento. Nuestra recomendación es usar una columna que daría lugar a una partición de al menos (o cerca de) 1 GB. Se recomienda seguir los procedimientos recomendados para el mantenimiento de tablas Delta; optimización. Para obtener un script de Python para evaluar las particiones, consulte Script de ejemplo para obtener detalles de la partición.

Un gran volumen de archivos de Parquet de tamaño pequeño aumenta el tiempo necesario para sincronizar los cambios entre un almacén de lago y su punto de conexión de SQL Analytics asociado. Es posible que termine con un gran número de archivos de Parquet en una tabla Delta por una o varias razones:

Si decide hacer una partición en una tabla Delta con un gran número de valores únicos, se particiona por cada valor único y puede tener particiones excesivas. Elija una columna de partición que no tenga una cardinalidad alta y da como resultado particiones individuales al menos 1 GB cada una.
Las tasas de ingesta de datos por lotes y streaming también pueden dar lugar a archivos pequeños en función de la frecuencia y el tamaño de los cambios que se escriben en un almacén de lago. Por ejemplo, puede haber un pequeño volumen de cambios que llegan a la casa del lago, lo que da lugar a pequeños archivos parquet. Para solucionar esto, se recomienda implementar el mantenimiento normal de la tabla del almacén de lago.

Script de ejemplo para los detalles de la partición

Use el cuaderno siguiente para imprimir un informe que detalle el tamaño y proporciona información sobre las particiones que respaldan una tabla Delta.

En primer lugar, debe proporcionar la ruta de acceso ABSFF para la 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 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.
El script genera todas las particiones de la tabla Delta.
El script recorre en iteración cada partición para calcular el tamaño total y el número de archivos.
El script genera los detalles de las particiones, los archivos por partición y el tamaño por partición en GB.

El script completo se puede copiar del 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']}")

Comentarios

¿Le ha resultado útil esta página?

Last updated on 2026-01-27