Compartir vía

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

  • Artículo

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 puede variar desde unos segundos hasta minutos, dependiendo de una serie de factores que se analizan en este artículo.

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 creada o actualizada la tabla de Delta Lake en el lago, la tabla de puntos de conexión de SQL Analytics que hace referencia a la tabla delta lake se creará o actualizará 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.

Captura de pantalla del portal de Fabric que muestra el botón Actualizar esquema del punto de conexión de SQL Analytics.

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 almacenes de lago y el punto de conexión de SQL Analytics, podría deberse a un gran número de almacenes de lago en una área 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, es posible que observe que los cambios confirmados en un almacén de lago no están visibles en el punto de conexión de SQL Analytics asociado. Por ejemplo, puede haber creado una nueva tabla en el almacén de lago, pero 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 almacén de lago, pero estos datos no son visibles en el punto de conexión de SQL Analytics. Se recomienda iniciar una sincronización de metadatos a petición, desencadenada desde la cinta Actualizar del editor de consultas de 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 de Fabric, consulte Interoperabilidad de Delta Lake.
  • Si hay un volumen extremadamente grande de tablas cambia durante el procesamiento de transformación y carga de extracción (ETL), podría producirse un retraso esperado hasta que se procesen todos los cambios.

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 que tenga como resultado un tamaño de partición individual de al menos 1 GB.
  • 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, podría haber un pequeño volumen de cambios que llegan al almacén de lago y esto daría lugar a pequeños archivos de 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.

  1. 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.
  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.

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']}")

Contenido relacionado