Nota:
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
Se aplica a: punto de conexión de análisis SQL ✅ y almacenamiento en Microsoft Fabric
En este artículo se describe la arquitectura y la administración de cargas de trabajo en Fabric Data Warehouse.
Procesamiento de datos
El almacén de datos y el punto final de análisis SQL comparten la misma arquitectura de procesamiento subyacente. A medida que Fabric recupera o ingiere datos, un motor distribuido controla tanto datos pequeños como a gran escala y funciones computacionales.
El sistema de procesamiento es sin servidor en el sentido de que la capacidad de computación de backend se escala de forma autónoma para satisfacer las demandas de trabajo.
Cuando se envía una consulta, el front-end (FE) de SQL optimiza las consultas para determinar el mejor plan en función del tamaño y la complejidad de los datos. Una vez generado el plan, se proporciona al motor de procesamiento de consultas distribuidas (DQP). El DQP organiza la ejecución distribuida de la consulta al dividirla en consultas más pequeñas que se ejecutan en nodos de ejecución de back-end. Cada consulta pequeña es una tarea y representa una unidad de ejecución distribuida. Lee archivos de OneLake, une los resultados de otras tareas, agrupa u ordena datos recuperados de otras tareas. Para los trabajos de ingesta, los datos también se escriben en las tablas de destino correspondientes.
Cuando se procesan los datos, los resultados se devuelven a la interfaz de SQL para entregar resultados al usuario o a la aplicación que realiza la llamada.
Elasticidad y resistencia
La capacidad de computación de backend se beneficia de una arquitectura de provisión rápida. Aunque no hay ningún Acuerdo de Nivel de Servicio en la asignación de recursos, normalmente se adquieren nuevos nodos en unos segundos. A medida que aumenta la demanda de recursos, las nuevas cargas de trabajo aprovechan la capacidad escalada. El escalado es una operación en línea y el procesamiento de consultas se lleva a cabo sin interrupciones.
El sistema es tolerante a errores y, si un nodo pasa a un estado incorrecto, las operaciones que se ejecutan en el nodo se redistribuyen a nodos correctos para su finalización.
El punto de conexión del almacén de datos y el análisis de SQL proporciona capacidad elástica que permite a las cargas de trabajo usar más recursos para lograr un mejor rendimiento y utilizar el suavizado para ofrecer alivio a los clientes que crean picos repentinos durante sus horas punta y tienen capacidad inactiva que no se utiliza en otros momentos. El suavizado simplifica la gestión de la capacidad mediante la distribución de la evaluación del cómputo para garantizar que los trabajos de los clientes se ejecuten sin problemas y de forma eficiente.
Programación y recursos
El programador de procesamiento de consultas distribuidas funciona por tareas. Las consultas se representan en el programador como un grafo acíclico dirigido (DAG) de tareas. Este concepto es familiar para los usuarios de Spark. Un DAG permite paralelismo y simultaneidad, ya que las tareas que no dependen entre sí se pueden ejecutar simultánea o desordenadamente.
A medida que llegan las consultas, sus tareas se programan en función de los principios de tipo primero en entrar, primero en salir (FIFO). Si hay capacidad inactiva, el programador podría usar un enfoque de "mejor ajuste" para optimizar la simultaneidad.
Cuando el programador identifica la presión de recursos, invoca una operación de escalado. El escalado se administra de forma autónoma y la topología de back-end crece a medida que aumenta la simultaneidad. Como tarda unos segundos en adquirir nodos, el sistema no está optimizado para un rendimiento coherente de subsegundos de las consultas que requieren un procesamiento distribuido.
Cuando disminuye la presión, la topología del backend se reduce y libera los recursos a la región.
Aislamiento del grupo de cómputo
Esto se aplica a:✅ Warehouse en Microsoft Fabric
La SKU de capacidad asignada a un área de trabajo determina la capacidad de cómputo total disponible para su punto de conexión de SQL Analytics. Este cómputo se divide equitativamente (50/50) en dos grupos de recursos aislados para que las consultas de los usuarios los utilicen.
-
SELECT Pool : controla todas las
SELECTconsultas. -
Grupo no SELECT - Maneja todas las consultas que no sean
SELECT, como las operaciones de ETL o ingesta.
Cada grupo se escala de forma independiente en función de la demanda de consultas, pero nunca supera el 50% de la capacidad total de cómputo para el punto de acceso de SQL Analytics. Esta separación evita la contención de recursos, lo que garantiza que las cargas de trabajo de ingesta se ejecuten en una computación dedicada optimizada para ETL sin afectar a las consultas de lectura. El resultado mejora el rendimiento y la confiabilidad de ambos tipos de consulta.
Nota:
El aislamiento del grupo SELECT y del grupo no-SELECT es la administración autónoma de cargas de trabajo predeterminada que se aplica a cada espacio de trabajo. Sin embargo, los administradores del área de trabajo pueden personalizarlo mediante grupos de SQL personalizados.
Sesiones
El punto de conexión de Almacén y SQL Analytics tiene un límite de sesión de usuario de 724 por área de trabajo. Si se alcanza este límite, se devolverá un error: The user session limit for the workspace is 724 and has been reached.
Nota:
Como Microsoft Fabric es una plataforma SaaS, hay muchas conexiones del sistema que se ejecutan para optimizar continuamente el entorno. Las DMV muestran tanto sesiones del sistema como de usuario. Para obtener más información, consulte Supervisión de conexiones, sesiones y solicitudes mediante DMV.
procedimientos recomendados
El área de trabajo de Microsoft Fabric proporciona un límite de aislamiento natural del sistema de proceso distribuido. Las cargas de trabajo pueden aprovechar este límite para administrar el costo y el rendimiento.
Los accesos directos de OneLake se pueden usar para crear réplicas de solo lectura de tablas en otros espacios de trabajo para distribuir la carga en varios motores SQL, creando un límite de aislamiento. Esto puede aumentar eficazmente el número máximo de sesiones que realizan consultas de solo lectura.
