Compartir a través de

Evaluación y optimización de la capacidad de Microsoft Fabric

  • Artículo

En este artículo se explica cómo evaluar y optimizar la carga en las capacidades de Microsoft Fabric. También se describen las estrategias para abordar situaciones de sobrecarga y se proporcionan instrucciones a fin de ayudar a optimizar el proceso para cada una de las experiencias de Fabric.

Aunque el modelo de capacidad de Fabric simplifica la configuración y permite la colaboración, existe una alta posibilidad de agotar los recursos de proceso compartidos de una capacidad. También puede ser el caso de que esté pagando por más recursos de los necesarios. Estas situaciones pueden surgir cuando el diseño de algunas experiencias de Fabric no sigue los procedimientos recomendados.

Es importante reducir el riesgo de agotar recursos compartidos: Fabric, como servicio administrado, aborda automáticamente estas situaciones de dos maneras.

  • La expansión y el suavizado garantizan que las actividades intensivas de CPU se completen rápidamente sin necesidad de una SKU superior (y se pueden ejecutar en cualquier momento del día).
  • La limitación retrasa o rechaza las operaciones cuando una capacidad experimenta una demanda sostenida y alta de CPU (por encima del límite de SKU).

El suavizado reduce la probabilidad de limitación (aunque la limitación todavía puede producirse). Suavizar es cómo se asigna el uso con respecto a los límites, pero es independiente de la ejecución de trabajos. El suavizado no cambia el rendimiento, solo distribuye la contabilidad del proceso consumido durante un período más largo, por lo que no se necesita una SKU mayor para controlar el proceso máximo.

Para obtener más información sobre la capacidad de Fabric, consulte Conceptos y licencias de Microsoft Fabric y Capacidades de Fabric: todo lo que necesita saber sobre las novedades y próximos estrenos.

Herramientas de planificación y presupuesto

Planear el tamaño de una capacidad puede ser un desafío. Esto se debe a que el proceso necesario puede variar ampliamente debido a las operaciones realizadas, el grado de ejecución (por ejemplo, la eficacia de una consulta DAX o el código de Python en un cuaderno) o el nivel de simultaneidad.

Para ayudarle a determinar el tamaño de capacidad adecuado, puede aprovisionar capacidades de prueba o SKU F de pago por uso para medir el tamaño de capacidad real necesario antes de comprar una instancia reservada de SKU F.

Sugerencia

Siempre es una buena estrategia empezar por lo pequeño y, a continuación, aumentar gradualmente el tamaño de su capacidad según sea necesario.

Supervisar las capacidades

Debe supervisar el uso para sacar el máximo partido de sus capacidades. En primer lugar, es importante comprender que las operaciones de Fabric son interactivas o en segundo plano. Por ejemplo, las consultas DAX de un informe de Power BI son solicitudes a petición que son operaciones interactivas, mientras que las actualizaciones del modelo semántico son operaciones en segundo plano. Para obtener más información sobre las operaciones y cómo consumen recursos en Fabric, consulte Operaciones de Fabric.

La supervisión puede revelarle que se está llevando a cabo la limitación. La limitación puede producirse cuando hay numerosas operaciones interactivas o de larga duración. Normalmente, las operaciones en segundo plano relacionadas con las experiencias de SQL y Spark se suavizan, lo que significa que se distribuyen durante un período de 24 horas.

La aplicación de métricas de capacidad de Fabric es la mejor manera de supervisar y visualizar el uso reciente. La aplicación se divide en el tipo de elemento (modelo semántico, cuaderno, canalización y otros) y le ayuda a identificar elementos u operaciones que usan altos niveles de proceso (para que se puedan optimizar).

Los administradores pueden usar el área de trabajo de supervisión de Administración para obtener información sobre los elementos usados con frecuencia (y la adopción general). También pueden usar el centro de supervisión para ver las actividades actuales y recientes en el inquilino. Puede que también haya más información sobre algunas operaciones disponibles en Log Analytics o en los registros de puerta de enlace de datos locales.

Administración del uso elevado de proceso

Cuando se utiliza una capacidad de alta utilización y comienza a mostrar la limitación o rechazo, hay tres estrategias para resolverla: optimizar, escalar verticalmente y escalar horizontalmente.

Se recomienda configurar notificaciones para saber cuándo el uso de la capacidad supera un umbral establecido. Además, considere la posibilidad de usar la configuración específica de la carga de trabajo para limitar el tamaño de las operaciones (por ejemplo, límites de tiempo de espera de consultas de Power BI o límites de fila o configuración del área de trabajo de Spark).

Optimize (Optimizar)

Los creadores de contenido siempre deben optimizar el diseño de sus elementos de Fabric para asegurarse de que sea eficaz y use los mínimos recursos de proceso posibles. Más adelante en este artículo se proporcionan instrucciones específicas para cada experiencia de Fabric.

Escalado vertical

Puede escalar verticalmente una capacidad para aumentar temporalmente o permanentemente el tamaño de la SKU (con más capacidad de proceso). El escalado vertical garantiza que hay suficientes recursos de proceso disponibles para todos los elementos de una capacidad y para evitar la limitación.

También puede cambiar el tamaño, pausar y reanudar las SKU F de Fabric para ajustarse a los patrones de consumo.

Escalado horizontal

Para escalar horizontalmente, mueva algunas de las áreas de trabajo o elementos a otra capacidad de Fabric para distribuir la carga de trabajo. Puede ser una buena opción cuando se requieren diferentes estrategias de capacidad, configuración o administradores. El aprovisionamiento de varias capacidades también es una buena estrategia para ayudar a aislar el proceso de los elementos de alta prioridad y también para el contenido de autoservicio o desarrollo. Por ejemplo, los ejecutivos de su organización esperan informes y paneles con gran capacidad de respuesta. Estos informes y paneles pueden residir en una capacidad independiente dedicada a los informes ejecutivos.

También puede considerar la posibilidad de mover áreas de trabajo de Power BI a una capacidad compartida, siempre que los consumidores tengan licencias de Power BI Pro que les permitan seguir accediendo al contenido.

Optimización de proceso por experiencia de Fabric

Las experiencias y los elementos de Fabric funcionan de forma diferente, por lo que no se optimizan necesariamente de la misma manera. En esta sección se enumeran los elementos de Fabric según la experiencia y las acciones que puede realizar para optimizarlos.

Fabric Data Warehouse

El almacenamiento de datos usa una arquitectura sin servidor y el servicio administra automáticamente sus nodos. El uso de la capacidad se calcula en función de los segundos de unidad de capacidad por consulta activos en lugar de la cantidad de tiempo que se aprovisionan los nodos front-end y back-end.

Todas las operaciones de almacenamiento de datos son operaciones en segundo plano y se suavizan durante un período de 24 horas.

El punto de conexión de SQL Analytics tiene como objetivo proporcionar un rendimiento de forma predeterminada. Para ello, hay menos opciones de ajuste de consultas disponibles en comparación con los grupos de SQL dedicados de SQL Server o Azure Synapse Analytics.

Estos son algunos puntos que se deben tener en cuenta para ayudar a minimizar el proceso.

  • Escriba consultas mediante el uso del T-SQL más óptimo posible. Cuando sea posible, limite el número de columnas, cálculos, agregaciones y otras operaciones que podrían aumentar innecesariamente el uso de recursos de consulta.
  • Diseñe tablas para usar los tipos de datos más pequeños posibles. La elección del tipo de datos puede influir en gran medida en los planes de consulta generados por el motor de SQL. Por ejemplo, reducir un campo VARCHAR de longitud de 500 a 25 o cambiar DECIMAL(32, 8) a DECIMAL(10, 2) puede dar lugar a una disminución significativa de los recursos asignados para una consulta.
  • Use el diseño de esquema de estrella para reducir el número de filas leídas y minimizar las combinaciones de consulta.
  • Asegúrese de que las estadísticas existen y están actualizadas. Las estadísticas desempeñan un papel fundamental en la generación del plan de ejecución más óptimo. Se crean automáticamente en tiempo de ejecución, pero es posible que tenga que actualizarlos manualmente, especialmente después de cargar o actualizar los datos. Considere la posibilidad de crear estadísticas mediante la opción FULLSCAN en lugar de confiar en las estadísticas generadas automáticamente que usan el muestreo.
  • Use vistas integradas para supervisar consultas y uso, especialmente cuando se solucionan problemas.
    • La vista de administración dinámica (DMV) sys.dm_exec_requests proporciona información sobre todas las consultas que se ejecutan activamente, pero no almacena ninguna información histórica. El cuadro de herramientas de Fabric proporciona una consulta que usa esta DMV y hace que el resultado de la consulta sea fácil de usar mediante la unión a otras vistas para proporcionar detalles como el texto de la consulta.
    • La información de consultas, que es una característica del almacenamiento de datos de Fabric, proporciona una vista holística de la actividad histórica de consultas en el punto de conexión de SQL Analytics. En concreto, la vista queryinsights.exec_requests_history proporciona información sobre cada solicitud de SQL completa. Presenta todos los detalles pertinentes para cada ejecución de consulta que se puede correlacionar con los identificadores de operación que se encuentran en la aplicación de métricas de capacidad. Las columnas más importantes para supervisar el uso de la capacidad son: distributed_statement_id, command (texto de consulta), start_time y end_time.

Ingeniería de datos de Fabric y Ciencia de datos de Fabric

Las experiencias de Ingeniería de datos y Ciencia de datos usan el proceso de Spark para procesar, analizar y almacenar datos en un almacén de lago de Fabric. El proceso de Spark se configura y mide en términos de núcleos virtuales. Sin embargo, Fabric usa CU como medida del proceso consumido por varios elementos, incluidos cuadernos de Spark, definiciones de trabajos de Spark y trabajos de almacén de lago.

En Spark, una CU se traduce en dos núcleos virtuales de Spark de proceso. Por ejemplo, cuando un cliente compra una SKU F64, hay 128 núcleos virtuales de Spark disponibles para las experiencias de Spark.

Todas las operaciones de Spark son operaciones en segundo plano y se suavizan durante un período de 24 horas.

Para obtener más información, consulte Informes de facturación y uso en Fabric Spark.

Estos son algunos puntos que se deben tener en cuenta para ayudar a minimizar el proceso.

  • Siempre se esfuerza por escribir código Spark eficaz. Para obtener más información, consulte Optimización de trabajos de Apache Spark en Azure Synapse Analytics y La necesidad de optimizar la escritura en Apache Spark.
  • Reserve los ejecutores necesarios para los trabajos de Spark a fin de liberar recursos para otros trabajos o cargas de trabajo de Spark. De lo contrario, aumenta la posibilidad de que los trabajos de Spark produzcan un error con un estado HTTP 430, lo que significa demasiadas solicitudes para la capacidad. Puede ver el número de ejecutores asignados a un cuaderno en el centro de supervisión de Fabric, donde también puede determinar el número real de ejecutores usados por el cuaderno. Los trabajos de Spark solo reservan los nodos necesarios y permiten envíos paralelos dentro de los límites de SKU.
  • El grupo de Spark solo se puede configurar para usar el número máximo de núcleos virtuales admitidos por la SKU. Sin embargo, puede escalar horizontalmente las cargas de trabajo de ingeniería de datos aceptando trabajos paralelos de Spark dentro de los límites de SKU. Este enfoque se conoce normalmente como factor de ráfaga y está habilitado de forma predeterminada para cargas de trabajo de Spark en el nivel de capacidad. Para obtener más información, consulte Limitación de simultaneidad y puesta en cola.
  • Las sesiones activas de Spark pueden acumular el uso de CU en una capacidad. Por este motivo, es importante detener las sesiones activas de Spark cuando no están en uso. Tenga en cuenta que este período de tiempo de expiración de sesión predeterminado de Spark se establece en 20 minutos. Los usuarios pueden cambiar el tiempo de espera de la sesión en un cuaderno o la definición del trabajo de Spark.

Inteligencia en tiempo real

El consumo de CU de la base de datos KQL se calcula en función del número de segundos que la base de datos está activa y el número de núcleos virtuales usados. Por ejemplo, cuando la base de datos usa cuatro núcleos virtuales y está activa durante 10 minutos, consumirá 2400 (4 x 10 x 60) segundos de CU.

Todas las operaciones de base de datos KQL son operaciones interactivas.

Se usa un mecanismo de escalado automático para determinar el tamaño de la base de datos KQL. Garantiza que el rendimiento más optimizado y rentable se consigue en función de los patrones de uso.

A fin de permitir que los datos estén disponibles para otros motores de Fabric, la base de datos KQL se sincroniza con OneLake. En función del número de transacciones de lectura y escritura que realiza la base de datos KQL, las CU se usan a partir de la capacidad. Utiliza los medidores de lectura y escritura de OneLake, que son equivalentes a las operaciones de lectura y escritura en cuentas de Azure Data Lake Storage (ADLS) Gen2.

Data Factory

En esta sección se abordan las optimizaciones para flujos de datos y canalizaciones de datos en Data Factory.

Todas las operaciones son operaciones en segundo plano y se suavizan durante un período de 24 horas.

Estos son algunos puntos que se deben tener en cuenta para ayudar a minimizar el proceso.

  • Evite la lógica de Power Query ineficaz para minimizar y optimizar las transformaciones de datos costosas, como combinar y ordenar.
  • Se esfuerza por lograr el plegado de consultas siempre que sea posible. Puede mejorar el rendimiento de los flujos de datos reduciendo la cantidad de datos que se deben transferir entre el origen de datos y el destino. Cuando no se produce el plegado de consultas, Power Query recupera todos los datos del origen de datos y realiza transformaciones localmente, lo que puede ser ineficaz y lento.
  • Deshabilite el almacenamiento provisional cuando trabaje con volúmenes de datos pequeños o realice transformaciones simples. El almacenamiento provisional puede ser necesario en algunos casos, como cuando se carga un almacenamiento de datos.
  • Evite actualizar los datos con más frecuencia de lo que requiere el origen de datos. Por ejemplo, si el origen de datos solo se actualiza una vez cada 24 horas, actualizar los datos cada hora no proporcionará ningún valor más. En su lugar, considere la posibilidad de actualizar los datos con una frecuencia adecuada para asegurarse de que está actualizado y preciso.

Power BI

Las operaciones de Power BI son interactivas o en segundo plano.

Las siguientes operaciones interactivas suelen dar lugar a un uso elevado de proceso.

  • Modelos semánticos que no siguen los procedimientos recomendados. Por ejemplo, es posible que no adopten el diseño de esquema de estrella con relaciones uno a varios. O bien, pueden incluir filtros complejos y costosos de seguridad de nivel de fila (RLS). Considere la posibilidad de usar el Editor tabular y el Analizador de procedimientos recomendados para determinar si se siguen los procedimientos recomendados.
  • Las medidas DAX son ineficaces.
  • Las páginas de informe contienen demasiados objetos visuales, lo que puede dar lugar a una actualización visual lenta.
  • Los objetos visuales de informe muestran resultados de cardinalidad alta (demasiadas filas o columnas) o contienen demasiadas medidas.
  • La capacidad experimenta una alta simultaneidad porque hay demasiados usuarios para el tamaño de capacidad. Considere la posibilidad de habilitar el escalado horizontal de consultas a fin de mejorar la experiencia del usuario para los modelos semánticos de alta simultaneidad (pero no da lugar a más procesos totales).

Las siguientes operaciones en segundo plano suelen dar lugar a un uso elevado de proceso.

  • Transformaciones de datos ineficaces o excesivamente complejas en la lógica de Power Query.
  • Ausencia de plegado de consultas o actualización incremental para tablas de hechos grandes.
  • Expansión de informes, que es cuando se genera un gran número de informes de Power BI o informes paginados al mismo tiempo.

Contenido relacionado

¿Tiene alguna pregunta más? Intente preguntar a la comunidad de Fabric.