Estándares operativos para una plataforma de datos unificada

Este artículo ayuda a los responsables de la toma de decisiones a establecer estándares operativos para desarrollar y usar productos de datos en una plataforma de datos unificada.

Las organizaciones deben decidir cómo los dominios de datos ponen los datos a disposición a través de OneLake y los transforman en productos de datos fiables para su reutilización en toda la organización. La gobernanza central debe establecer estándares de toda la organización. Los dominios de datos deben poseer sus productos de datos y tomar decisiones de implementación dentro de esos límites.

Los estándares coherentes reducen la duplicación innecesaria y ayudan a los consumidores a encontrar y usar datos de confianza con la protección adecuada. En este artículo se tratan la ingesta de datos, la transformación, la publicación, el consumo, la administración del ciclo de vida, la seguridad y las excepciones.

1. Ingesta de datos

¿Qué estándares deben regir la ingesta de datos? La organización debe establecer estándares sobre qué datos de origen deben estar disponibles a través de OneLake y los métodos preferidos para ponerlos a disposición. Haga que los datos de origen estén disponibles a través de OneLake solo cuando respalden un producto de datos aprobado o una necesidad analítica.

1.1 Métodos de ingesta de datos

¿Cómo deben los dominios de datos hacer que los datos de origen estén disponibles a través de OneLake? La organización debe preferir patrones que minimicen el movimiento de datos innecesario.

• Los accesos directos deben ser el patrón preferido cuando los datos compatibles pueden permanecer en su origen.
• Creación de reflejo debe ser el patrón preferido para los orígenes admitidos cuando Fabric necesita acceso sincronizado a una base de datos o catálogo externo.
• El movimiento de datos se debe usar cuando Fabric requiere una copia de los datos y los accesos directos o la creación de reflejo no cumplen el requisito.

Los dominios de datos pueden elegir otro método de ingesta aprobado cuando el patrón preferido no cumple con el requisito. Consulte Unificar datos con accesos directos y creación de reflejo en OneLake.

1.2 Fuentes de datos

¿Cómo debemos integrar diferentes orígenes de datos? Los dominios de datos deben hacer que las salidas de confianza estén disponibles a través de OneLake en lugar de volver a crear el procesamiento equivalente en Fabric sin una ventaja organizativa medible.

• Microsoft 365: Microsoft 365 normalmente debe permanecer como sistema de referencia para el contenido de colaboración. Los dominios de datos deben incorporar el contenido de Microsoft 365 a la plataforma de datos unificada solo cuando un producto de datos aprobado lo requiera, como para el análisis estructurado.

• Bases de datos operativas: las bases de datos operativas deben permanecer optimizadas para cargas de trabajo transaccionales. Los dominios de datos no deben permitir que las cargas de trabajo analíticas o de inteligencia artificial consulten directamente una base de datos operativa a menos que el propietario de la base de datos haya aprobado la carga de trabajo esperada y haya establecido los controles necesarios.

• Plataformas de datos existentes: los lagos de datos y las plataformas de transformación existentes, como Azure Databricks, deben permanecer en vigor cuando sigan cumpliendo los requisitos de la organización. La migración o la recreación en Fabric deben requerir una ventaja organizativa medible. Consulte Accesos directos, Reflejar Unity Catalog de Azure Databricks e Integración de OneLake con Azure Databricks.

2. Transformación de datos

¿Cómo se deben transformar los datos en productos de datos? La organización debe establecer una plataforma de transformación preferida para reducir la duplicación innecesaria de funcionalidades. Microsoft Fabric puede servir como valor predeterminado cuando Microsoft Fabric cumple los requisitos del producto de datos. Las plataformas existentes, como Azure Databricks, deben permanecer en uso cuando proporcionan funcionalidades necesarias o representan una inversión organizativa establecida.

Patrón de transformación: la arquitectura de Medallion debe ser el patrón preferido cuando los datos se benefician del refinamiento progresivo. Los dominios de datos deben usar solo las fases de calidad necesarias para generar un producto de datos de confianza.

Consulte vistas materializadas de lago en Fabric, Arquitectura de Medallion Lakehouse en Fabric y análisis integral con Microsoft Fabric.

3. Publicación

¿Qué debe existir para que se publique un producto de datos? Un producto de datos puede constar de uno o varios recursos técnicos que proporcionan colectivamente una oferta empresarial respaldada. Todos los productos de datos publicados deben tener un propietario responsable, un propósito empresarial respaldado, un uso previsto, un proceso de acceso y un estado de calidad. Cuando los consumidores dependen de la disponibilidad oportuna, también se debería definir un compromiso operativo.

• Controles de seguridad: los controles de seguridad necesarios deben estar en vigor antes de la publicación. Los productos de datos confidenciales deben tener los requisitos de clasificación y manipulación necesarios. Consulte las etiquetas de confidencialidad de Purview.

• Metadatos: la organización debe definir los metadatos mínimos para los productos de datos publicados. Los consumidores deben poder determinar el dominio de datos al que pertenece, el responsable, el uso admitido, el compromiso de calidad y los requisitos de acceso. Consulte etiquetas en Fabric y metadatos personalizados de Purview.

• Trazabilidad de datos: la trazabilidad disponible debe proporcionar suficiente información para comprender las dependencias ascendentes del material y evaluar el impacto descendente. Consulte Linaje de datos en Fabric.

4. Descubrimiento

¿Cómo deben encontrar los consumidores productos de datos? Los productos de datos publicados deben ser fácilmente localizables de forma predeterminada. Use OneLake Catalog para la detección nativa de Fabric. Representa un producto de datos en Catálogo unificado de Microsoft Purview cuando requiere un contexto empresarial empresarial o una gobernanza en todo el patrimonio de datos más amplio.

Consulte Descripción general del catálogo de OneLake y Productos de datos en Unified Catalog.

5. Respaldo

¿Cómo deben determinar los consumidores si un producto de datos es de confianza para su reutilización? La aprobación en Fabric puede ayudar a los consumidores a evaluar el nivel de garantía proporcionado por los elementos que admiten un producto de datos. La organización debe establecer significados y requisitos coherentes para cada nivel de respaldo.

• Promotion debe indicar que el dominio de datos responsable recomienda el producto de datos para su reutilización.

• La certificación debe indicar que un revisor autorizado confirmó que el producto de datos cumple los estándares de la organización definidos.

La publicación no debería requerir certificación. La publicación establece el umbral organizativo mínimo para la reutilización admitida. La certificación proporciona garantía adicional. Consulte Promoción en Fabric.

6. Consumo aprobado

¿Cuándo pueden los consumidores usar un producto de datos sin aprobación adicional? Los productos de datos pueden admitir muchos patrones de consumo, como análisis, aplicaciones, fundamentación con IA y agentes. Los mismos estándares de seguridad y uso aprobados se aplican independientemente de la tecnología que la consume. El dominio de datos propietario debe definir los usos admitidos por cada producto de datos publicado. Los consumidores deben poder usar el producto de datos sin aprobación adicional cuando su uso propuesto se encuentra dentro de esos límites.

La organización debe definir los usos que siempre requieren revisión adicional. Estos usos deben incluir situaciones en las que el uso cambia materialmente el riesgo de los datos, como la divulgación externa o el uso de inteligencia artificial consecuente.

La aprobación de un uso no debe implicar la aprobación de otro. Por ejemplo, un producto de datos aprobado para los informes internos no debe aprobarse automáticamente para la publicación externa. Un producto de datos aprobado para la fundamentación de IA no debe aprobarse automáticamente para un agente que pueda realizar acciones con consecuencias.

7. Ciclo de vida del producto de datos

¿Cómo deben los dominios de datos gestionar los productos de datos de los que dependen los consumidores? Los productos de datos publicados crean dependencias que el dominio de datos propietario debe administrar. La organización debe establecer estándares para los cambios y la retirada para que los consumidores puedan prever las interrupciones y la transición cuando sea necesario. Juntos, los requisitos de publicación y los compromisos de ciclo de vida establecen el contrato entre el dominio de datos propietario y los consumidores del producto de datos.

7.1 Fiabilidad

¿Qué estándares de confiabilidad se deben aplicar a los productos de datos publicados? La organización debe establecer requisitos de confiabilidad en función del impacto empresarial de un producto de datos que deja de estar disponible o pierde datos. Los dominios de datos deben aplicar estos requisitos al producto de datos completo en lugar de suponer que la confiabilidad de OneLake u otro componente de la plataforma proporciona el nivel de protección necesario.

• Clasificación de confiabilidad: la organización debe definir los requisitos de confiabilidad para cada nivel de importancia empresarial. Los dominios de datos deben asegurarse de que el producto de datos completo cumple los requisitos aplicables.

• Requisitos de recuperación: el dominio de datos propietario debe asegurarse de que el producto de datos completo cumple los requisitos de confiabilidad asociados a su importancia empresarial. El diseño de recuperación ante desastres debe tener en cuenta el producto de datos y las dependencias necesarios para su uso. Los productos de datos críticos para la empresa deben tener un proceso de recuperación probado.

• Fabric requisitos de capacidad: los dominios de datos deben asegurarse de que la capacidad de Fabric compartida no impida que ningún producto de datos asignado cumpla sus requisitos de confiabilidad. Use una capacidad independiente cuando un producto de datos requiera controles de nivel de capacidad que no se deben aplicar a otros productos.

No considere la replicación de OneLake como una recuperación completa de los datos. Cada producto de datos críticos para la empresa debe tener un diseño de recuperación que abarque sus datos y los elementos Fabric necesarios. Consulte la guía de recuperación ante desastres y protección de datos de OneLake y la guía de recuperación ante desastres específica de la experiencia de Fabric.

7.2 Cambios

¿Cómo deben administrar los dominios de datos los cambios que afectan a los consumidores? Los dominios de datos responsables deben administrar los cambios incompatibles según el impacto empresarial del producto de datos. Deben identificar a los consumidores afectados antes de realizar un cambio incompatible y proporcionar un período de transición proporcionado al impacto.

Los compromisos relacionados con cambios deben aumentar a medida que aumente la dependencia y la importancia empresarial. Un producto de datos ampliamente reutilizado que admita un proceso empresarial crítico debe tener requisitos de cambio más sólidos que un producto de datos con un uso limitado.

Los dominios de datos deben usar el linaje disponible y el análisis de impacto para identificar las dependencias técnicas. También deben tener en cuenta las dependencias empresariales conocidas que el linaje técnico no captura. Consulte análisis de impacto de Fabric.

7.3 Obsolescencia

¿Cómo debe un dominio de datos retirar un producto de datos publicado? La organización debe establecer los requisitos mínimos de jubilación. Antes de la desactivación, el dominio de datos propietario debe evaluar las dependencias activas y proporcionar un período de transición proporcionado al impacto empresarial.

El dominio de datos propietario debe identificar un reemplazo aprobado cuando existe uno. Debe quitar el respaldo cuando los consumidores deban dejar de crear nuevas dependencias. Los consumidores existentes deben recibir un aviso suficiente antes de que finalice el acceso.

8. Seguridad del data product

¿Cómo se deben aplicar los requisitos de autorización cuando se consumen los productos de datos? Una nueva ruta de consumo no debe debilitar la protección requerida por el producto de datos de origen. La organización debe clasificar los patrones de consumo aprobados según si los requisitos de autorización del producto de datos siguen siendo efectivos.

8.1. Autorización de origen conservada

¿Cuándo conserva un patrón de consumo la autorización del producto de datos de origen? Un patrón de consumo puede basarse en la autorización del producto de datos de origen cuando conserva la identidad del consumidor y sigue aplicando las restricciones de acceso necesarias.

Por ejemplo, si un producto de datos de ventas restringe a cada vendedor a los clientes asignados, el patrón de consumo debe conservar esa restricción para cada consumidor. Las organizaciones deben validar cada patrón aprobado antes de permitir que consuma datos restringidos.

Consulte agentes de datos de Fabric, Power BI y servidor MCP de OneLake.

8.2. Nuevo perímetro de autorización

¿Qué estándares se aplican cuando un patrón de consumo debe establecer una nueva frontera de autorización? Un patrón de consumo que no conserva los requisitos de autorización del producto de datos de origen debe establecer un nuevo límite de autorización que proporcione protección equivalente. La organización no debe aprobar el patrón para los datos restringidos cuando no puede proporcionar esa protección.

Esta situación suele producirse cuando un servicio crea otra representación de los datos o accede a los datos de origen a través de una identidad de aplicación compartida.

• Índices: un índice de búsqueda crea otra representación de los datos de origen. Los datos restringidos del índice deben permanecer protegidos según los requisitos de autorización del producto de datos de origen. La organización debe validar cómo se representan y aplican los permisos de origen en el índice en lugar de asumir que los controles de acceso de OneLake protegen automáticamente el contenido indexado. Consulte OneLake Indexer, control de acceso de nivel de documento y procedimientos recomendados de seguridad de Búsqueda de Azure AI.

• Identidades de servicio o compartidas: cuando un servicio de consumo accede a un producto de datos a través de una identidad de servicio en lugar de la identidad del consumidor, la autorización de origen se aplica a esa identidad de servicio. La solución de consumo debe aplicar cualquier autorización de nivel de consumidor requerida por el producto de datos. Consulte Autenticación para herramientas de Protocolo de contexto de modelo (MCP) y Uso de la autenticación de entidad de servicio con el agente de datos de Fabric.

9. Excepciones a los estándares

¿Qué excepciones puede aprobar un dominio de datos? La organización debe definir qué dominios de datos estándar pueden variar y cuáles requieren aprobación central.

• Los dominios de datos deben tener autoridad para aprobar excepciones que afecten solo a su presupuesto o modelo operativo local. No deben aprobar excepciones que debiliten los requisitos de toda la organización para el cumplimiento normativo o de seguridad. La aprobación central también debe ser necesaria para excepciones que debilitan los requisitos de interoperabilidad de toda la organización o el estándar de publicación de producto de datos mínimo.

• La gobernanza central debe poseer estándares de toda la organización y revisarlos a medida que evolucionan las funcionalidades de Fabric y las prácticas organizativas. Los dominios de datos deben proporcionar excepciones periódicas como entrada para estas revisiones. Las excepciones repetidas pueden indicar que un estándar organizativo debe cambiar.