Patrones de implementación de Microsoft Fabric

En este artículo se describen cuatro patrones de implementación entre los que puede elegir al implementar Microsoft Fabric. Conozca las consideraciones, recomendaciones y posibles decisiones irreversibles de cada patrón de implementación.

Se establecen las siguientes áreas de diseño para cada patrón de implementación de Fabric:

• Gobernanza
• Seguridad
• Administración
• DevOps
• Facilidad de uso
• Rendimiento y escala
• Facturación y gestión de costes

Niveles en una implementación de Fabric

Una implementación de Fabric tiene cuatro niveles: inquilino, capacidad, área de trabajo y elemento. En el nivel superior está el inquilino de Fabric. Cada inquilino puede tener una o varias capacidades, cada capacidad puede incluir una o varias áreas de trabajo y cada área de trabajo puede incluir cero o más elementos de Fabric.

La estructura o los objetivos de una organización en las áreas de seguridad, escala, gobernanza y ciclo de vida de las aplicaciones pueden influir en la elección del patrón de implementación. Los diferentes patrones de implementación ofrecen flexibilidad y énfasis distintos en los niveles de una implementación.

Por ejemplo, una organización puede usar dominios para agrupar áreas de trabajo en Fabric. De forma similar, si una organización debe tener una opción centralizada que puede usar para colaborar y buscar contenido, un centro de datos OneLake en Fabric garantiza un punto de acceso centralizado y se integra con otros productos conocidos, como Microsoft Teams y Excel.

En Fabric, una organización grande que tenga unidades de negocio en localizaciones geográficas independientes puede usar capacidades para controlar dónde residen los datos. Puede administrar una unidad de negocio que funcione desde una localización geográfica diferente como una sola unidad mediante dominios de Fabric, ya que los dominios pueden abarcar áreas de trabajo que sean de diferentes regiones.

Para obtener más información sobre los niveles de Fabric y su función en la elección de un patrón de implementación, consulte Conceptos y licencias de Microsoft Fabric.

Cómo alinear patrones de implementación de Fabric

Todos los patrones de implementación de Fabric:

• Use áreas de trabajo de Fabric como límites para la escala, la gobernanza y la seguridad.
• Use dominios de Fabric para la delegación, para administrar varias áreas de trabajo que podrían pertenecer a la misma unidad de negocio o cuando los datos que pertenecen a un dominio empresarial abarcan más de un área de trabajo. Puede ajustar algunas opciones de configuración de inquilino para administrar y gobernar los datos en el ámbito de dominio y usar la configuración específica del dominio de esas opciones.
• Use las capacidades de Fabric para escalar los recursos computacionales al aprovisionar capacidades específicas por área de trabajo cuando se deban cumplir cuotas de rendimiento determinadas.
• Amplíelo para usar funciones equivalentes a una nube de Microsoft (Microsoft Azure, Microsoft 365 y otros) cuando haya una función que no está disponible en Fabric.
• Use un centro de datos de OneLake para estimular la detección y el uso de recursos de datos.
• Use OneSecurity para crear directivas de seguridad de datos para los recursos de datos.

Casos basados en los requisitos empresariales

En este artículo se usan los siguientes casos para describir la forma en que cada patrón de implementación puede dar respuesta a diversos requisitos empresariales:

• Situación 1: Para las organizaciones que quieran tener unos plazos más cortos (o más largos) de comercialización mediante la organización de equipos que pueden colaborar entre sí, con restricciones más bajas en el uso de datos. En este caso, una organización puede sacar ventaja usando un patrón de implementación monolítico. La organización opera en una sola área de trabajo y la administra. Para obtener más información, consulte Patrón 1: Implementación monolítica.
• Situación 2: Para las organizaciones que deseen crear entornos aislados en los que los equipos trabajen, con un equipo central responsable de aprovisionar y administrar la infraestructura. Este caso también se adapta a las organizaciones que deseen implementar mallas de datos. En este escenario, una organización puede implementar varias áreas de trabajo que usen una capacidad compartida o que tengan capacidades independientes. Para obtener más información, consulte Patrón 2: Varias áreas de trabajo respaldadas por una sola capacidad de Fabric y Patrón 3: Varias áreas de trabajo respaldadas por capacidades independientes.
• Situación 3: Para las organizaciones que deseen un modelo completamente descentralizado que ofrezca a las unidades de negocio o a los equipos la libertad de controlar y administrar sus propias plataformas de datos. En este escenario, una organización puede elegir un modelo de implementación en el que se usen áreas de trabajo independientes, cada una con capacidad concreta o, si se da el caso, con varios inquilinos de Fabric. Para obtener más información, consulte Patrón 3: Varias áreas de trabajo respaldadas por capacidades independientes y Patrón 4: Varios inquilinos de Fabric.
• Situación 4: Una organización podría decidir usar un enfoque híbrido en el que se combinan varios patrones para dar cumplimiento a sus requisitos. Por ejemplo, una organización podría crear una sola área de trabajo para unidades de negocio específicas (un patrón de implementación monolítica) al usar áreas de trabajo independientes y dedicadas y capacidades independientes para otras unidades de negocio.

Patrón 1: Implementación monolítica

En este patrón de implementación, se aprovisiona una sola área de trabajo para dar cabida a todos los casos prácticos. Todas las unidades de negocio funcionan dentro de la misma área de trabajo única.

Al aprovisionar una sola capacidad de Fabric e incorporar una sola área de trabajo, se cumplen los siguientes puntos:

• Todos los elementos de Fabric comparten la misma capacidad aprovisionada. La cantidad de tiempo que tarda una consulta o un trabajo en resolverse varía porque otras cargas de trabajo usan la misma capacidad.
• Las unidades de capacidad máxima (CU) del área de trabajo se limitan a la SKU F o SKU P más grande posible. En el caso de los entornos de ingeniería de datos, puede aprovisionar grupos de Spark independientes para mover la capacidad de procesos que Fabric Spark necesita fuera de las CU aprovisionadas.
• 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 se puede usar este patrón para escenarios multigeográficos.
• Las funciones que dependen de varias áreas de trabajo, como los procesos de implementación y la administración del ciclo de vida, no están disponibles.
• Se aplican limitaciones asociadas a una sola área de trabajo.
• Se aplican limitaciones de capacidades asociadas a una SKU específica.

Puede optar por implementar este patrón de implementación por uno o varios de los siguientes motivos:

• Su organización no tiene establecidos requisitos de ingeniería complejos, tiene una base de usuarios pequeña o sus modelos semánticos son 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 medallion de lakehouse. Cuando la organización está limitada a una sola área de trabajo, puede separar entre las capas de bronce, plata y oro mediante la creación de lakehouses independientes dentro del área de trabajo.
• Las unidades de negocio de la organización comparten roles y es aceptable disponer de los mismos permisos de área de trabajo para los usuarios del área de trabajo. Por ejemplo, cuando varios usuarios que pertenecen a diferentes unidades de negocio son administradores de una sola área de trabajo, tienen los mismos derechos en todos los elementos del área de trabajo.
• Su organización puede tolerar plazos de finalización de trabajos variables. Si una organización no tiene ningún requisito relacionado con garantías de productividad (por ejemplo, un trabajo debe finalizar en un plazo de tiempo específico), es posible compartir una sola capacidad aprovisionada entre unidades de negocio. Cuando se comparte una capacidad, los usuarios pueden ejecutar sus consultas en cualquier momento. El número de CU que están disponibles para ejecutar un trabajo varía en función de las demás consultas que se ejecutan en la capacidad. Puede dar lugar a plazos de finalización de trabajos variables.
• Su organización puede cumplir todos sus requisitos empresariales (desde la perspectiva de las CU) mediante una sola capacidad de Fabric.

En la tabla siguiente se incluyen algunas observaciones que podrían influir en la decisión de hacer uso de este patrón de implementación:

Patrón 2: Varias áreas de trabajo respaldadas por una sola capacidad de Fabric

En este patrón de implementación, se usan áreas de trabajo independientes. Dado que una sola capacidad se comparte entre áreas de trabajo, las cargas de trabajo que se ejecutan simultáneamente en cualquier momento podrían afectar al rendimiento de los trabajos y las consultas interactivas.

Al aprovisionar una sola capacidad de Fabric e incorporar varias áreas de trabajo, se cumplen los siguientes puntos:

• Todos los elementos de Fabric comparten la misma capacidad aprovisionada. La cantidad de tiempo que tarda una consulta o un trabajo en resolverse varía porque otras cargas de trabajo usan la misma capacidad.
• El número máximo de CPU que puede usar un área de trabajo se limita a la SKU F o SKU P más grande posible. En el caso de los entornos de ingeniería de datos, puede aprovisionar grupos de Spark independientes para mover la capacidad de procesos que Fabric Spark necesita fuera de las CU aprovisionadas.
• 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 se puede usar este patrón para escenarios multigeográficos.
• Puede usar funcionalidades de DevOps que necesiten áreas de trabajo independientes, como los procesos de implementación y la administración del ciclo de vida.
• Se aplican limitaciones asociadas a una sola área de trabajo.
• Se aplican limitaciones de capacidades asociadas a una SKU específica.

Puede optar por implementar este patrón de implementación por uno o varios de los siguientes motivos:

• Quiere una arquitectura radial en la que la organización centraliza algunos aspectos del funcionamiento del entorno de análisis y descentraliza otros.
• Quiere descentralizar una parte operativa y de administración, pero en distintos grados. Por ejemplo, puede decidir tener capas de bronce y plata de una arquitectura medallion implementada en un área de trabajo y la capa de oro implementada en otra área de trabajo. Esto podría justificarlo por el hecho de que un equipo se hace responsable de las capas de bronce y plata y otro equipo se hace responsable de operar y administrar la capa de oro.
• No le preocupa principalmente la gestión del rendimiento ni aislar las cargas de trabajo desde el punto de vista de la productividad.
• Partiendo de una arquitectura medallion de lakehouse, su organización puede crear áreas de trabajo independientes para implementar capas de bronce, plata y oro.
• Su organización no necesita implementar cargas de trabajo en diferentes regiones geográficas (todos los datos deben residir en una región).
• Su organización puede necesitar que se separen las áreas de trabajo por uno o varios de los siguientes motivos:
  • Los miembros del equipo responsable de las cargas de trabajo se encuentran en áreas de trabajo diferentes.
  • 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 (procesamiento de datos, flujo de datos Gen2 o ingeniería de datos) y crear un área de trabajo independiente para su consumo a través de un almacén de datos. Este diseño funciona bien cuando equipos independientes son responsables de cada una de las cargas de trabajo.
  • Quiere implementar una arquitectura de malla de datos en la que una o varias áreas de trabajo se agrupen en un dominio de Fabric.
• Su organización puede optar por implementar áreas de trabajo independientes en función de la clasificación de los datos.

En la tabla siguiente se incluyen algunas observaciones que podrían influir en la decisión de elegir este patrón de implementación:

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

En este patrón de implementación, se logra la separación entre las unidades de negocio para la gobernanza y el rendimiento.

Al aprovisionar varias capacidades de Fabric con sus propias áreas de trabajo, se cumplen los siguientes puntos:

• La SKU F o la SKU P más grande posible asociadas a un área de trabajo determina el número máximo de CU que puede usar un área de trabajo.
• La descentralización de la organización y de la administración se consigue mediante el aprovisionamiento de áreas de trabajo independientes.
• Las organizaciones pueden escalar en más de una región aprovisionando capacidades y áreas de trabajo en diferentes regiones geográficas.
• Puede usar todas las funcionalidades de Fabric, ya que las unidades de negocio pueden tener una o varias áreas de trabajo que se encuentran en capacidades independientes y agrupadas entre sí a través de dominios de Fabric.
• Se aplican limitaciones asociadas a una sola área de trabajo, pero puede escalar más allá de estos límites mediante la creación de nuevas áreas de trabajo.
• Se aplican limitaciones de capacidades asociadas a una SKU específica, pero puede escalar CU mediante el aprovisionamiento de capacidades independientes.
• Todos los elementos de Fabric de todas las áreas de trabajo del inquilino y sus estados de certificación se pueden detectar mediante un centro de datos de OneLake.
• 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 reducen el movimiento de datos, así como la capacidad de uso de los datos en las áreas de trabajo.

Puede optar por implementar este patrón de implementación por uno o varios de los siguientes motivos:

• 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, el aprovisionamiento de una capacidad y un área de trabajo independientes es el factor clave que permite avanzar hacia el patrón de implementación de varias áreas de trabajo y varias áreas de trabajo.
• Opera a gran escala y tiene requisitos para escalar y superar los límites de una SKU de una sola capacidad o de una sola área de trabajo.
• Tiene cargas de trabajo que siempre deben finalizar dentro de un período específico o cumplir un acuerdo de nivel de servicio de rendimiento específico. Puede aprovisionar un área de trabajo independiente respaldada por una capacidad de Fabric para hacer cumplir las garantías de productividad de esas cargas de trabajo.

En la tabla siguiente se incluyen algunas observaciones que podrían influir en la decisión de elegir este patrón de implementación:

Patrón 4: Varios inquilinos de Fabric

Cuando se implementan inquilinos de Fabric independientes, todas las instancias de Fabric son entidades independientes con respecto a la gobernanza, la gestión, la administración, la escala y el almacenamiento.

Se dan los siguientes aspectos cuando se usan varios inquilinos de Fabric:

• Los recursos de inquilino se separan de forma estricta.
• Los planos de administración entre inquilinos son independientes.
• Los inquilinos son entidades independientes y pueden tener sus propios procesos de gobernanza y administración, pero se pueden administrar por separado.
• Puede usar procesamientos de datos o funcionalidades de ingeniería de datos para compartir o acceder a datos entre inquilinos de Fabric.

Podría implementar este patrón de implementación por los siguientes motivos:

• La organización podría acabar con varios inquilinos de Fabric tras una adquisición de la empresa.
• La organización podría crear un inquilino de Fabric específicamente para una unidad de negocio o una subsidiaria más pequeña.

Colaboradores

Microsoft mantiene este artículo. Originalmente lo escribieron los siguientes colaboradores.

• Holly Kelly | Administradora jefa de programas
• Gabi Muenster | Jefa de programas sénior
• Sarath Sasidharan | Jefe de programas sénior
• Amanjeet Singh | Administrador de programas principal