Elección de un patrón de implementación de Microsoft Fabric

Al implementar Microsoft Fabric, debe decidir cómo estructurar capacidades, áreas de trabajo y elementos en toda la organización. El patrón de implementación adecuado depende de los requisitos de gobernanza, seguridad, aislamiento de rendimiento y administración de costos. Esta guía ayuda a los arquitectos y equipos de plataforma a evaluar cuatro patrones de implementación y a comprender las consideraciones y desventajas de cada uno.

Jerarquía de cuatro niveles

En el diagrama siguiente se muestra la jerarquía de cuatro niveles que define todas las implementaciones de Fabric.

Descargue un archivo Visio de esta arquitectura.

La jerarquía de implementación fluye desde el tenant de Microsoft 365 hasta los elementos individuales. La elección del patrón de implementación determina cómo se usa cada nivel.

• Nivel de inquilino. En la parte superior se ubica la entidad de Microsoft 365, que actúa como frontera de identidad y administración para tu organización. El tenant de Fabric existe dentro de este tenant de Microsoft 365 y todos los recursos de Fabric se encuentran dentro de este límite único del tenant. La configuración de nivel de inquilino, incluidos Microsoft Entra Conditional Access, vínculos privados y etiquetas de sensibilidad, aplican en todas las capacidades y áreas de trabajo.

• Nivel de capacidad. Configure al menos una capacidad de Fabric dentro de un inquilino de Microsoft 365. Cada capacidad está enlazada a una región de Azure específica y tiene una SKU F que determina los recursos de proceso disponibles medidos en unidades de capacidad (RU). Las capacidades gestionan la residencia de datos y establecen límites de facturación. Una sola capacidad puede hospedar varias áreas de trabajo.

• Nivel de área de trabajo. Cada capacidad contiene una o varias áreas de trabajo. Las áreas de trabajo son los contenedores principales para la colaboración y la gobernanza. Definen el control de acceso a través de cuatro roles de área de trabajo (Administrador, Miembro, Colaborador y Visor), admiten la integración de Git para el control de versiones y sirven como ámbito para las canalizaciones de implementación. Un área de trabajo pertenece a una sola capacidad a la vez. La migración de la capacidad de la misma región es sencilla. La migración entre regiones es posible, pero debe quitar y volver a crear la mayoría de los elementos Fabric, incluidos los almacenes, almacenes, cuadernos y canalizaciones. Por lo tanto, prefiere la migración de la misma región.

• Nivel de elemento. Los espacios de trabajo contienen elementos de Fabric como lakehouses, almacenes, cuadernos, canalizaciones, modelos semánticos, informes y paneles. Los elementos heredan los permisos del área de trabajo de forma predeterminada. Los roles de seguridad de Microsoft OneLake proporcionan control de acceso pormenorizado a nivel de tabla, carpeta, columna y fila, pero solo se aplican a los usuarios del rol Visualizador. Los administradores, miembros y colaboradores del área de trabajo omiten los roles de seguridad de OneLake.

Las siguientes restricciones de licencias y tipo de área de trabajo suelen determinar qué patrón de implementación es más práctico:

• Las nuevas áreas de trabajo comienzan utilizando capacidad compartida a menos que las vuelvas a asignar. Cada entidad dispone de una capacidad compartida que aloja Mis espacios de trabajo y puede albergar espacios de trabajo de Power BI Pro o Premium por usuario (PPU). Para implementar un patrón gobernado de implementación de Fabric para cargas de trabajo de producción, normalmente debe reasignar espacios de trabajo a capacidad de Fabric dedicada en la entidad.

• PPU no es un sustituto de la capacidad de Fabric. PPU proporciona características Premium de Power BI según el usuario, pero no incluye capacidad de Fabric. Para crear o ejecutar elementos distintos de Power BI Fabric, como lakehouses, almacenes y cuadernos, se necesita una capacidad F.

• El tipo de área de trabajo afecta a lo que el patrón puede hospedar. En este artículo, los patrones de implementación de Fabric asumen que las áreas de trabajo de Fabric están respaldadas por la SKU F. Las SKU de tipo A y EM solo admiten elementos Power BI, por lo que no son capaces de admitir patrones de implementación de Fabric de extremo a extremo.

• La concesión de licencias de visor de Power BI puede modificar el costo de un modelo. En las capacidades F64 y mayores, los usuarios con el rol de Visor pueden acceder al contenido de Power BI con una licencia gratuita. En capacidades más pequeñas, los consumidores de Power BI necesitan una licencia Pro, PPU o de prueba. Este umbral puede reducir la rentabilidad de un patrón centralizado para grandes poblaciones de lectores.

• La creación y el uso compartido en Power BI requieren al menos un usuario Pro o PPU. Incluso si un área de trabajo usa capacidad de Fabric, las organizaciones necesitan que los usuarios tengan licencias Pro o PPU para crear y compartir elementos de Power BI.

Componentes

• Microsoft 365 tenant: Un límite de identidad y administrativo para la organización. Hospeda Microsoft Entra ID (anteriormente Azure Active Directory) para la autenticación y autorización.

• Fabric capacity: Un recurso de proceso y facturación que se usa en una región de Azure específica, por ejemplo Este de EE. UU. o Oeste de Europa. Para reducir los costos, puede pausar las capacidades cuando no están en uso.

• Fabric workspace: Un contenedor de colaboración para elementos de Fabric. Admite el control de acceso basado en rol (RBAC), la integración de Git y las canalizaciones de implementación. Para la agrupación lógica, puede asignar áreas de trabajo a dominios de Fabric.

• Elementos de Fabric: artefactos de datos y análisis, como lakehouses, almacenes de datos, cuadernos, canalizaciones, flujos de datos, modelos semánticos, informes y paneles de control.

• Dominios de tejido: Agrupaciones lógicas que organizan áreas de trabajo por unidad de negocio o área temática. Los dominios admiten la gobernanza delegada y aparecen en el catálogo de OneLake para la detección y supervisión.

• OneLake: Lago de datos jerárquico unificado en el que los inquilinos contienen áreas de trabajo, que contienen elementos. Fabric almacena datos en OneLake. OneLake admite Azure Data Lake Storage API, accesos directos al almacenamiento externo e integración con herramientas de Data Lake Storage, como Azure Storage Explorer y AzCopy.

• OneLake catalog: Una interfaz centralizada para buscar, controlar y proteger los datos de Fabric en todo el entorno. Los usuarios pueden acceder al catálogo mediante herramientas como Microsoft Teams, Excel y Microsoft Copilot Studio.

Descripción de los niveles de implementación de Fabric

La estructura, los objetivos, los requisitos de seguridad, la escala, el modelo de gobernanza y el ciclo de vida de la aplicación influyen en las decisiones en cada nivel de implementación. Para obtener más información sobre cada nivel, consulte Jerarquía de cuatro niveles.

• Las capacidades controlan la residencia de datos y la distribución geográfica. Las organizaciones que operan en varias ubicaciones geográficas pueden usar capacidades en diferentes regiones de Azure para controlar dónde se almacenan los datos. Cada capacidad está enlazada a una región de Azure específica, que admite implementaciones geográficas múltiples entre regiones. Para admitir la gobernanza centralizada, los dominios de Fabric pueden agrupar áreas de trabajo y sus capacidades asociadas entre regiones.

• Las áreas de trabajo sirven como límite principal de gobernanza y seguridad. Cada área de trabajo define el control de acceso a través de cuatro roles, admite el control de versiones a través de la integración de Git y actúa como el ámbito de las canalizaciones de implementación. Para centralizar la colaboración y la detección de contenido, use el catálogo de OneLake para implementar una experiencia unificada de detección y gobernanza sobre los datos de OneLake del inquilino. Los usuarios pueden encontrar e interactuar con contenido de herramientas como Teams y Excel a través de este catálogo.

• Cada nivel influye en las opciones del ciclo de vida de la aplicación. Las características como las canalizaciones de implementación y la administración del ciclo de vida no están disponibles en patrones de área de trabajo única porque requieren áreas de trabajo independientes. Las organizaciones que usan dominios para agrupar áreas de trabajo pueden delegar la administración de nivel de dominio sin privilegios de administrador de inquilinos, lo que afecta a cómo los equipos administran las versiones y la gobernanza entre unidades de negocio.

Patrones comunes en todas las implementaciones

Todos los patrones de implementación de Fabric comparten las siguientes características fundamentales:

• Áreas de trabajo como límites para la escala, gobernanza y seguridad. Los patrones de implementación usan espacios de trabajo de Fabric como unidad principal para la organización de elementos, los permisos y el ámbito de características de DevOps. Independientemente del patrón que elija, las áreas de trabajo definen el límite para la colaboración y el control de acceso.

• Dominios de Fabric para la delegación en varios espacios de trabajo y unidades de negocio. Use dominios de Fabric para la delegación. Puede administrar varias áreas de trabajo que pueden pertenecer a la misma unidad de negocio o administrar datos que pertenecen a un dominio empresarial y abarca más de una área de trabajo. Para administrar y controlar los datos en el nivel de dominio, puede ajustar la configuración de nivel de inquilino y usar una configuración específica del dominio para esas opciones.

• Capacidades para el escalado de cómputo con capacidad dedicada por espacio de trabajo para garantizar el rendimiento. Si debe cumplir niveles de rendimiento específicos, use las capacidades de Fabric para escalar los recursos de computación y ofrecer capacidades dedicadas por espacio de trabajo. Las organizaciones que necesitan aislamiento de carga de trabajo para trabajos sensibles al rendimiento pueden asignar esas áreas de trabajo a una capacidad independiente que tenga una asignación de CU garantizada.

• Catálogo OneLake para la detección de recursos y la pestaña Seguridad para las políticas de seguridad de datos. Para promover el descubrimiento y el uso de recursos de datos en su entorno, use el catálogo de OneLake. Para visualizar, supervisar y configurar roles de seguridad en todo el ámbito de las áreas de trabajo y elementos, utilice la pestaña Seguridad en el catálogo de OneLake.

• Extensión de las características de Microsoft Cloud si las características nativas de Fabric no están disponibles. Si una característica nativa no está disponible, los patrones de implementación se pueden extender para usar características equivalentes de la Microsoft Cloud, como Azure y Microsoft 365. Por ejemplo, las organizaciones pueden usar Azure Pipelines o GitHub Actions para la orquestación de la integración y entrega continuas (CI/CD) si las canalizaciones de implementación de Fabric no cubren sus requisitos de automatización entre áreas de trabajo. Las organizaciones también pueden usar Microsoft Purview para la gobernanza de datos de toda la empresa que abarca orígenes de datos Fabric y no Fabric.

Selección de un patrón de implementación

En los escenarios siguientes se describen los requisitos empresariales comunes y los patrones de implementación que se abordan. Use estos escenarios para ayudar a identificar el patrón que mejor se adapte a su organización.

• Escenario 1: tiempo de comercialización más rápido con colaboración entre equipos. Si su organización quiere un tiempo de comercialización más rápido, colaboración entre equipos y restricciones más bajas en el uso de datos, puede implementar un patrón de implementación monolítico . En este escenario, la organización funciona en y administra una sola área de trabajo.

  Usar patrón 1: implementación monolítica.

• Escenario 2: entornos de equipo aislados con administración de infraestructura central. Si su organización quiere proporcionar entornos de equipo aislados y un equipo de administración de infraestructura central, puede implementar varias áreas de trabajo que usen una capacidad compartida o capacidades independientes. Este escenario también se adapta a las organizaciones que desean implementar una arquitectura de malla de datos.

  Usar patrón 2: Varias áreas de trabajo, capacidad única o Patrón 3: Varias áreas de trabajo, capacidades independientes.

• Escenario 3: autonomía de unidad de negocio completa sobre plataformas de datos. Si su organización quiere un modelo completamente descentralizado que ofrezca a las unidades de negocio o equipos la libertad de controlar y administrar sus propias plataformas de datos, puede implementar un modelo de implementación que use separate áreas de trabajo con capacidad dedicada o varios inquilinos de Fabric.

  Use Pattern 3: Varias áreas de trabajo, capacidades independientes o Pattern 4: Varios clientes de Fabric.

• Escenario 4: enfoque híbrido que combina varios patrones. Si su organización quiere una solución híbrida que use varios patrones para cumplir sus requisitos, puede implementar un enfoque híbrido. Por ejemplo, puede configurar una sola área de trabajo para unidades de negocio específicas, como en un patrón de implementación monolítica, y áreas de trabajo dedicadas independientes y capacidades independientes para otras unidades de negocio.

Patrón 1: Implementación monolítica

En este patrón de implementación, se asigna un área de trabajo para todos los casos de uso. Todas las unidades de negocio funcionan dentro del mismo área de trabajo.

Las siguientes características se aplican a este patrón:

• Los elementos del tejido comparten la misma capacidad. El tiempo que tarda una consulta o un trabajo varía, en función de las demás cargas de trabajo que usen la misma capacidad.

• Las RU máximas del área de trabajo se limitan a la SKU F más grande posible. En el caso de las experiencias de ingeniería de datos y ciencia de datos, los administradores de capacidad pueden configurar la facturación Autoscale para Apache Spark para mover la capacidad de cómputo que el motor de Spark usa fuera de las CUs asignadas.

• Las características cuyo ámbito es un área de trabajo se aplican en todas las unidades de negocio que comparten el área de trabajo.

• Todos los elementos y datos del área de trabajo se encuentran en una región. No puede usar este patrón para escenarios geográficos múltiples.

• Las características que dependen de varias áreas de trabajo no están disponibles, por ejemplo, las canalizaciones de implementación y la administración del ciclo de vida.

• Se aplican limitaciones de área de trabajo única.

• Se aplican limitaciones de capacidad de SKU específicas.

Cuándo usar este patrón

Puede implementar este patrón de implementación si:

• Su organización no tiene requisitos de ingeniería complejos, tiene una base de usuarios pequeña o tiene modelos semánticos pequeños.

• Su organización funciona en una sola región.

• No le preocupa principalmente la separación organizativa entre las unidades de negocio.

• Su organización no requiere funcionalidades relacionadas con el área de trabajo, como el uso compartido de repositorios de código con Git.

• Quiere implementar una arquitectura de medallón para almacenamiento en lago. Si su organización usa una sola área de trabajo, puede crear almacenes de lago independientes dentro del área de trabajo para administrar capas de bronce, plata y oro.

• Las unidades de negocio de la organización comparten roles y puede tener los mismos permisos de nivel de área de trabajo para los usuarios del área de trabajo. Por ejemplo, si varios usuarios de diferentes unidades de negocio son administradores de una sola área de trabajo, tienen los mismos derechos en todos los elementos del área de trabajo.

• La organización tolera los tiempos de finalización de trabajos variables. Si se comparte una capacidad, los usuarios pueden ejecutar consultas en cualquier momento. El número de CUs disponibles para ejecutar un trabajo depende de las otras consultas que se ejecutan en la misma capacidad, lo que puede llevar a tiempos variables de finalización de trabajos.

• Su organización puede cumplir con sus requisitos empresariales de CU mediante una única capacidad de Fabric.

Consideraciones sobre el área de diseño

En la tabla siguiente se presentan consideraciones que podrían influir en la decisión de usar este patrón de implementación.

Patrón 2: Varias áreas de trabajo, capacidad única

En este patrón de implementación, se asignan varias áreas de trabajo en una sola capacidad compartida. Las áreas de trabajo comparten esa capacidad, por lo que las cargas de trabajo simultáneas pueden afectar al rendimiento de los trabajos y las consultas interactivas.

Las siguientes características se aplican a este patrón:

• Los elementos del tejido comparten la misma capacidad. El tiempo que tarda una consulta o un trabajo varía, en función de las demás cargas de trabajo que usen la misma capacidad.

• Las RU máximas del área de trabajo se limitan a la SKU F más grande posible. En el caso de las experiencias de ingeniería de datos y ciencia de datos, los administradores de capacidad pueden configurar la Facturación de Escalabilidad Automática para Spark para mover la capacidad de cómputo utilizada por el Spark Engine fuera de las CUs asignadas.

• Las funcionalidades que pertenecen a un área de trabajo se aplican en todas las unidades de negocio que comparten esa área de trabajo.

• Todos los elementos y datos del área de trabajo se encuentran en una región. No puede usar este patrón para escenarios geográficos múltiples.

• Puede usar características de DevOps que requieren áreas de trabajo independientes, como canalizaciones de implementación y administración del ciclo de vida.

• Se aplican limitaciones de área de trabajo única.

• Se aplican limitaciones de capacidad de SKU específicas.

Cuándo usar este patrón

Puede implementar este patrón de implementación si:

• Quiere una arquitectura hub-spoke que centralice algunos aspectos del funcionamiento del entorno analítico y descentralice otros.

• Quiere una descentralización operativa y de gestión variable. Por ejemplo, su organización podría hospedar las capas de bronce y plata de una arquitectura de medallón en un área de trabajo y hospedar la capa de oro en un área de trabajo independiente. Esta separación suele reflejar distintas responsabilidades operativas, por ejemplo, donde un equipo administra las capas de bronce y plata y otro equipo administra la capa dorada.

• Principalmente, no le preocupa la administración del rendimiento y el aislamiento de cargas de trabajo.

• Su organización no necesita implementar cargas de trabajo en diferentes regiones geográficas. Todos los datos deben residir en una región.

• Es posible que la organización requiera áreas de trabajo independientes porque:

  • Los miembros del equipo responsable de las cargas de trabajo se encuentran en diferentes áreas de trabajo.

  • Quiere crear áreas de trabajo independientes para cada tipo de carga de trabajo. Por ejemplo, puede crear un área de trabajo para la ingesta de datos, como canalizaciones de datos, flujos de datos o ingeniería de datos, y un área de trabajo independiente para su consumo a través de un almacenamiento de datos. Este diseño funciona bien si los equipos independientes son responsables de cada carga de trabajo.

  • Quiere implementar una arquitectura de malla de datos que agrupe una o varias áreas de trabajo juntas en un dominio de Fabric.

• Su organización puede implementar áreas de trabajo independientes en función de la clasificación de datos.

Consideraciones sobre el área de diseño

En la tabla siguiente se presentan consideraciones que podrían influir en la decisión de usar este patrón de implementación.

Patrón 3: Varias áreas de trabajo, capacidades independientes

En este patrón de implementación, se asignan varias áreas de trabajo a capacidades de Fabric independientes, lo que proporciona un aislamiento de la gobernanza y el rendimiento entre diferentes unidades de negocio.

Las siguientes características se aplican a este patrón:

• La mayor SKU de F o SKU de P que está asociada a un área de trabajo determina el número máximo de CUs que este puede usar.

• Las áreas de trabajo independientes crean descentralización de la organización y de la administración.

• Las organizaciones pueden escalar más allá de una región mediante capacidades y áreas de trabajo en diferentes regiones geográficas.

• Puede usar las funcionalidades completas de Fabric porque las unidades de negocio pueden tener varias áreas de trabajo en capacidades independientes y agruparse a través de dominios de Fabric.

• Se aplican limitaciones del área de trabajo para una sola área de trabajo, pero puede crear nuevas áreas de trabajo para escalar más allá de estos límites.

• Se aplican limitaciones de capacidad de SKU específicas, pero puede escalar CUs mediante capacidades separadas.

• Puede usar el catálogo OneLake para detectar elementos Fabric y sus estados de certificación.

• Los dominios pueden agrupar áreas de trabajo para que una sola unidad de negocio pueda operar y administrar varias áreas de trabajo.

• Los accesos directos de OneLake eliminan las copias físicas de los datos para reducir el movimiento de datos. Los accesos directos de OneLake también ofrecen acceso controlado entre áreas de trabajo a través de OneLake y no transfieren la propiedad de los datos subyacentes.

Cuándo usar este patrón

Puede implementar este patrón de implementación si:

• Su organización quiere implementar modelos de trabajo basados en arquitecturas, como mallas de datos o tejidos de datos.

• Quiere priorizar la flexibilidad en la estructura de las capacidades y áreas de trabajo.

• Opera en diferentes regiones geográficas. En este caso, cree una capacidad y un espacio de trabajo independientes para avanzar hacia un patrón de implementación multicapacidad y multiespacio de trabajo.

• Opera a gran escala y tiene requisitos para escalar más allá de los límites de una SKU con capacidad única o de un solo espacio de trabajo.

• Tiene cargas de trabajo que siempre deben finalizar dentro de un tiempo específico u necesitan cumplir con los SLA basados en el rendimiento. Puede configurar un área de trabajo respaldada por la capacidad de Fabric para cumplir con los objetivos de nivel de servicio (SLO) de esas cargas de trabajo.

Consideraciones sobre el área de diseño

En la tabla siguiente se presentan consideraciones que podrían influir en la decisión de usar este patrón de implementación.

Patrón 4: Varios inquilinos de Fabric

En este patrón de implementación, todas las instancias de Fabric son entidades independientes con respecto a la gobernanza, la administración, la administración, la escala y el almacenamiento.

Las siguientes características se aplican a este patrón:

• Los recursos del arrendatario están estrictamente segregados.

• Los planos de administración entre inquilinos son independientes.

• Los inquilinos son entidades independientes, cada una con sus propios procesos de gobernanza y administración y cada uno administrado de forma independiente.

• Puede usar canalizaciones de datos o ingeniería de datos para compartir o acceder a datos entre inquilinos de Fabric.

Cuándo usar este patrón

Puede implementar este patrón de implementación si:

• Su organización tiene varios inquilinos Fabric debido a una adquisición empresarial.

• Su organización quiere configurar un tenant de Fabric específicamente para una unidad de negocio o una subsidiaria pequeña.

Evaluación de plataformas alternativas

Si los requisitos de la organización no se alinean con los modelos de implementación basados en Fabric, tenga en cuenta las siguientes alternativas restringidas:

• Azure Data Factory con Data Lake Storage o OneLake, incluidas las arquitecturas híbridas de Data Factory y Fabric

  Las organizaciones que necesitan control de orquestación explícita o modernización por fases pueden usar Data Factory para la orquestación de ingesta y canalización y Data Lake Storage como base de almacenamiento. En un modelo híbrido, las canalizaciones de datos administradas por Data Factory pueden cargar datos en OneLake, mientras que Fabric administra la creación de recursos de datos analíticos. Este enfoque admite la adopción incremental de Fabric y conserva los patrones de integración establecidos.

• Data Lake Storage, Azure Databricks y Power BI

  Las organizaciones que prefieren una arquitectura basada en plataforma como servicio (PaaS) en lugar de una plataforma unificada de software como servicio (SaaS) podrían crear un patrimonio de datos mediante Data Lake Storage para el almacenamiento, Azure Databricks para la ingeniería y el análisis de datos, y Power BI para el modelado semántico y los informes. Este enfoque ofrece un control y flexibilidad máximos, pero requiere un mayor esfuerzo de integración y aumenta la complejidad operativa y la sobrecarga de gobernanza.

Consideraciones

Estas consideraciones implementan los pilares de Well-Architected Framework, que es un conjunto de principios rectores que puede usar para mejorar la calidad de una carga de trabajo. Para obtener más información, consulte Well-Architected Framework.

Las tablas por patrón anteriores en este artículo utilizan áreas de diseño específicas para las decisiones de implementación de Fabric, como gobernanza, seguridad, administración, DevOps, facilidad de uso, rendimiento y facturación. Las siguientes subsecciones proporcionan orientación complementaria organizada por los pilares del Marco Well-Architected. Use las tablas por patrón para comparar patrones. Use estas subsecciones para obtener instrucciones arquitectónicas transversales que se apliquen independientemente del patrón que elija.

Confiabilidad

La confiabilidad ayuda a garantizar que la aplicación pueda cumplir los compromisos que realice para sus clientes. Para obtener más información, consulte Lista de comprobación de revisión de diseño para confiabilidad.

• Resistencia regional integrada. Fabric proporciona resiliencia regional integrada a través de zonas de disponibilidad, si es compatible. Fabric distribuye automáticamente los recursos entre varias zonas sin configuración del cliente. La compatibilidad con la zona de disponibilidad varía según la región de Azure. Para comprobar si la región de destino admite zonas de disponibilidad para Fabric, consulte Disponibilidad regional de Fabric.

• La recuperación ante desastres (DR) requiere participar y tiene advertencias. La recuperación entre regiones está disponible a través de una configuración de recuperación ante desastres opcional en la página de configuración de capacidad. Habilite la configuración de capacidad de DR para replicar datos de OneLake en regiones emparejadas de Azure mediante la replicación asincrónica.

  Importante

  Algunas Azure regiones no están emparejadas con regiones que admiten Fabric, lo que podría poner en peligro las funcionalidades de recuperación ante desastres incluso si los datos se replican. Dado que la replicación de datos es asincrónica, los datos escritos inmediatamente antes de un desastre regional podrían perderse. Para obtener más información, consulte Confiabilidad en Fabric.

• Los patrones de capacidad única concentran el riesgo en una región. En los patrones 1 y 2, las cargas de trabajo se encuentran en una región Azure. Si la región experimenta una interrupción, todas las áreas de trabajo se ven afectadas simultáneamente. Para protegerse frente a errores regionales, configure la configuración de capacidad para replicar datos de OneLake en una región emparejada. Planee el tiempo de recuperación necesario para restaurar el servicio en la región emparejada.

• Los patrones multicapacidad proporcionan aislamiento regional natural. En los patrones 3 y 4, las capacidades de diferentes regiones significan que una interrupción regional afecta solo a las capacidades de esa región. Las cargas de trabajo de otras regiones siguen funcionando. Estos patrones soportan los requisitos de residencia de datos y proporcionan la base para estrategias regionales activas-pasivas o activas-activas.

• La pausa de la capacidad afecta la fiabilidad. Si pausa la capacidad de Fabric para reducir los costos, todas las cargas de trabajo de esa capacidad dejarán de estar disponibles. Tenga en cuenta el impacto en la confiabilidad antes de pausar una capacidad que admite cargas de trabajo de producción.

• Los accesos directos de OneLake introducen dependencias externas. Los accesos directos a orígenes de datos externos presentan dependencia de la disponibilidad del origen. Si el origen externo no está disponible, es posible que se produzcan errores en los elementos que dependen de métodos abreviados. Monitoree la salud de los orígenes de datos externos y planifique la degradación controlada.

Seguridad

La seguridad proporciona garantías contra ataques deliberados y el uso indebido de sus valiosos datos y sistemas. Para obtener más información, vea Lista de comprobación para la revisión de diseño de seguridad.

• El modelo de seguridad en capas abarca tres niveles. Fabric implementa un modelo de seguridad en capas que abarca los niveles de inquilino, área de trabajo y elemento. La elección del patrón de implementación determina cómo segmenta los límites de seguridad. Los patrones de área de trabajo única, como el patrón 1, aplican el acceso uniforme. Los patrones de varios espacios de trabajo, como los patrones 2, 3 y 4, admiten límites de seguridad por equipo o por unidad de negocio.

Identidad y acceso

• Aplicar directivas de autenticación de nivel de inquilino mediante el acceso condicional. Usa Acceso Condicional para aplicar directivas de autenticación a nivel de inquilino, como la autenticación multifactor, el cumplimiento de dispositivos y las restricciones basadas en la ubicación. El acceso condicional requiere una licencia Microsoft Entra ID P1.

• Utilice roles de área de trabajo para controlar el acceso a elementos. Asigne roles de área de trabajo para controlar quién puede crear, editar y consumir elementos dentro de un área de trabajo. En los patrones de varios espacios de trabajo, como los patrones 2, 3 y 4, use áreas de trabajo independientes para aplicar límites de roles entre unidades de negocio.

• Aplique el acceso a nivel granular de datos mediante roles de seguridad de OneLake. Use roles de seguridad de OneLake para aplicar el control de acceso pormenorizado en el nivel de tabla, carpeta, columna y fila para los usuarios del rol Visor. Los administradores, miembros y colaboradores del área de trabajo omiten estos roles.

Seguridad de red

• Use vínculos privados para el tráfico entrante. Use vínculos private para enrutar el tráfico entrante a través de la red troncal Microsoft en lugar de la red pública de Internet. Los vínculos privados de nivel de inquilino se aplican a todas las áreas de trabajo. Los vínculos privados de nivel de área de trabajo proporcionan granularidad por área de trabajo.

• Use puntos de conexión privados administrados para las conexiones de Spark salientes. Use puntos de conexión privados administrados para proteger las conexiones salientes de las cargas de trabajo de Spark a orígenes de datos protegidos por firewall, como Data Lake Storage y Azure SQL Database.

• Utilice las puertas de enlace de red virtual de datos cuando los vínculos privados a nivel de inquilino bloqueen las puertas de enlace locales en las instalaciones. Al habilitar vínculos privados de nivel de inquilino, las puertas de enlace de datos locales no se pueden registrar. Use una puerta de enlace de datos de red virtual en lugar de puentes que conecten orígenes de datos locales o protegidos por red virtual.

Protección de los datos

• Aplique etiquetas de confidencialidad para la clasificación de datos de un extremo a otro. Para la clasificación y protección de datos, aplique etiquetas de sensibilidad de Microsoft Purview Information Protection a los datos que fluyen a través de Fabric. Las etiquetas siguen los datos del origen al informe.

• Use los registros de auditoría y las herramientas de cumplimiento para la aplicación de directivas. Para detectar y responder a infracciones de directivas, revise los registros de audit y use Microsoft Purview Compliance Manager.

Optimización de costos

La optimización de costos se centra en formas de reducir los gastos innecesarios y mejorar las eficiencias operativas. Para obtener más información, consulte Lista de comprobación de revisión de diseño para la optimización de costes.

• Costos del modelo antes de la implementación. Los patrones de implementación afectan a la estructura de costos. Modele los costos del escenario mediante precios de Fabric y el estimador de capacidad de Fabric.

• Ajuste su SKU de capacidad al tamaño adecuado. Ajuste el tamaño de su SKU F según la demanda de la carga de trabajo. Comience con una SKU más pequeña y escale verticalmente según sea necesario. Supervise el consumo e identifique capacidades sobreaprovisionadas o infraaprovisionadas mediante la aplicación métricas de capacidad Fabric.

• Automatice la pausa de capacidad para entornos que no son de producción. Reduzca los costos pausando las capacidades SKU tipo F cuando no están en uso. En entornos de desarrollo y pruebas, se recomienda pausar los recursos fuera del horario laboral. La pausa hace que todas las cargas de trabajo no estén disponibles, por lo que considere la posibilidad de automatizar a través de Azure Resource Manager Fabric API o canalizaciones programadas.

• Los patrones de capacidad única, como los patrones 1 y 2, centralizan la facturación, pero limitan el contracargo. Una capacidad significa una factura. La administración de costos está centralizada, pero no es posible la devolución a unidades de negocio individuales porque todas las cargas de trabajo comparten la misma capacidad.

• Los patrones de multicapacidad, como los patrones 3 y 4, admiten el recargo por equipo. Cada capacidad genera su propio medidor de facturación Azure. Puede imputar costos a la unidad de negocio responsable de cada capacidad. Puede ajustar adecuadamente u optimizar de forma independiente cada capacidad en función de la carga de trabajo que admite.

• Administre los costos de almacenamiento de OneLake de forma independiente. OneLake Storage se factura a una tarifa de pago por uso por GB y no consume CUs. Elimine periódicamente los datos sin usar, incluidos los datos eliminados temporalmente, y supervise el almacenamiento a través de la aplicación Métricas de capacidad de Fabric.

• Monitoriza el recurso computacional de Spark por separado. En el caso de las cargas de trabajo de ingeniería de datos, puede usar grupos de Spark independientes para mover el proceso fuera del presupuesto de CU. Para evitar costos inesperados, supervise el consumo de CU de Spark.

Excelencia operativa

La excelencia operativa abarca los procesos de las operaciones que implementan una aplicación y la mantienen en ejecución en producción. Para obtener más información, consulte la Lista de comprobación de revisión de diseño para la excelencia operativa.

• Usa canalizaciones de despliegue para la promoción por etapas. Use Fabric tuberías de implementación para promover el contenido a través de las etapas de desarrollo/pruebas y producción. Las canalizaciones de implementación requieren áreas de trabajo independientes, por lo que no están disponibles en el patrón 1. En los patrones 2, 3 y 4, cree áreas de trabajo dedicadas para cada fase de DTAP. La estrategia de capacidad varía según el patrón.

  • En el patrón 2, todas las áreas de trabajo de DTAP comparten la misma capacidad, que es rentable, pero no proporciona aislamiento de rendimiento entre entornos.

  • En el patrón 3, puede usar capacidades dedicadas por entorno para el aislamiento completo, o puede equilibrar el costo y el aislamiento mediante una capacidad compartida para desarrollo y pruebas con una capacidad de producción independiente.

• Planifique entornos de preproducción como una decisión de diseño a nivel de espacio de trabajo. El patrón 1 no proporciona ninguna separación de preproducción porque el desarrollo y la prueba se producen en el área de trabajo de producción. El patrón 2 admite áreas de trabajo de desarrollo, pruebas y producción independientes en una capacidad compartida, que se adapta a la validación funcional, pero no a pruebas de resistencia o rendimiento similares a producción. El patrón 3 admite la validación de preproducción similar a la de producción a través de áreas de trabajo alineadas con el entorno con aislamiento a nivel de capacidad. El patrón 4 implica inquilinos independientes en lugar de decisiones de nivel de área de trabajo. Cada inquilino puede elegir de forma independiente su propia topología de entorno y no es necesario que coincida con otros inquilinos.

• Conecte áreas de trabajo a repositorios de Git para el control de código fuente. En los patrones 2 y 3, las áreas de trabajo independientes por equipo o carga de trabajo se alinean con las estrategias de bifurcación estándar. En el patrón 1, todos los equipos comparten un único repositorio, lo que puede crear conflictos de fusión.

• Supervise el estado de la capacidad y la carga de trabajo. Use la aplicación Métricas de capacidad de Fabric para supervisar el consumo de capacidad, como el uso de CU, la limitación y el uso por encima del límite. Puede acceder a la telemetría detallada sobre las cargas de trabajo individuales mediante la supervisión del área de trabajo. En los patrones de múltiples capacidades, como los patrones 3 y 4, puede delegar la supervisión al equipo responsable de cada capacidad.

• Delegar la administración a través de dominios de Fabric. En los patrones 2 y 3, delegue la configuración del inquilino y la administración del área de trabajo a los administradores de nivel de dominio sin privilegios de administrador de inquilinos mediante Fabric dominios. El patrón 1 no puede usar dominios porque todos los elementos están en un área de trabajo.

• Administre las capacidades mediante el uso de la infraestructura como código (IaC). Cree y administre capacidades de Fabric mediante Bicep o Terraform. Almacene las definiciones de infraestructura en el control de código fuente junto con el código de aplicación.

Eficiencia en el rendimiento

La eficiencia del rendimiento hace referencia a la capacidad de escalado de la carga de trabajo para satisfacer las demandas de los usuarios de forma eficaz. Para obtener más información, consulte Lista de comprobación de revisión de diseño para la eficiencia del rendimiento.

• Comprenda la determinación del tamaño y el comportamiento de regulación de la capacidad. Cada capacidad tiene una asignación fija de CU determinada por su SKU. Si la demanda supera las UC disponibles, Fabric aplica limitación y pone en cola las solicitudes. Supervise los eventos de limitación mediante la aplicación Fabric Capacity Metrics y amplíe la SKU o distribuya las cargas de trabajo entre varias capacidades según sea necesario.

• Aísle las cargas de trabajo sensibles al rendimiento en una capacidad dedicada. En los patrones 1 y 2, todas las cargas de trabajo compiten por las mismas CUs. Una canalización de datos o consulta costosa puede degradar el rendimiento de las consultas interactivas para otros usuarios. En los patrones 3 y 4, puede aislar las cargas de trabajo sensibles al rendimiento en una capacidad dedicada con una asignación de CU garantizada.

• Configura clústeres de Spark para cargas de trabajo de ingeniería de datos. En el caso de las cargas de trabajo de ingeniería de datos, use grupos de Spark personalizados para controlar el número mínimo y máximo de nodos y admitir el escalado automático. Las redes virtuales administradas deshabilitan los grupos de inicio o los clústeres compartidos precalentados, lo que aumenta el tiempo de inicio de la sesión de segundos a de entre 3 y 5 minutos.

• Coloque capacidades cercanas a los productores y consumidores de datos. En el patrón 3, puede usar capacidades en regiones cercanas a productores o consumidores de datos, lo que reduce la latencia entre regiones. Los accesos directos de OneLake pueden hacer referencia a datos en otras regiones, pero las lecturas entre regiones incurren en costos de latencia y salida.

• Aplicar técnicas de optimización específicas de la carga de trabajo. Mejore el rendimiento de escaneo mediante Z-Ordering y V-Ordering para lakehouses. En el caso de los almacenes, optimice los patrones de consulta para leer lotes más pequeños. Reduzca la carga de capacidad en comparación con el modo de importación utilizando el modo Direct Lake para informes de Power BI.

Matriz de funcionalidades

En las tablas siguientes se resumen las diferencias clave en las funcionalidades de cada patrón.

Gobernanza y administración

¹ Las áreas de trabajo proporcionan cierto aislamiento, pero todas las áreas de trabajo comparten una sola capacidad, lo que limita la granularidad del seguimiento y la administración del uso.

² El patrón 4 usa inquilinos independientes en lugar de dominios. Cada inquilino tiene su propio modelo de administración.

Seguridad

Administración del ciclo de vida y DevOps

³ Las canalizaciones de implementación requieren áreas de trabajo independientes, que no están disponibles en un patrón monolítico de un solo área de trabajo.

⁴ La integración de Git está disponible, pero todos los equipos comparten un único repositorio, lo que puede crear conflictos de fusión.

Rendimiento y escala

⁵ El riesgo de limitación es bajo si las cargas de trabajo están en capacidades dedicadas, pero aún puede ocurrir dentro de una sola capacidad si la demanda supera las unidades de capacidad disponibles.

Facturación y gestión de costes

⁶ Cada capacidad genera su propio medidor de facturación, por lo que la facturación se distribuye entre capacidades en lugar de centralizada.

Colaboradores

Microsoft mantiene este artículo. Los siguientes colaboradores escribieron este artículo.

Autor principal:

• Amanjeet Singh | Administrador de programas principal

Otros colaboradores:

• Lorrin Fernando | Consultor principal
• Holly Kelly | Administradora jefa de programas
• Gabi Muenster | Jefa de programas sénior
• Sarah Sasidharan | Jefe de programas sénior

Para ver perfiles de LinkedIn no públicos, inicie sesión en LinkedIn.

Pasos siguientes

• Fabric: Conceptos y licencias
• Fabric Workspaces
• dominios Fabric
• ¿Qué es OneLake?
• Fabric canalizaciones de implementación
• Fiabilidad en Fabric
• Información general de seguridad de Fabric

Recursos relacionados

• Introducción a las opciones tecnológicas
• Analítica de un extremo a otro con Fabric
• Inteligencia empresarial con Fabric
• Construir un lakehouse desde cero con Fabric