Recomendados
Más contenido relacionado
Similar a Azure Data Mesh
Similar a Azure Data Mesh (20)
Más de nnakasone
Más de nnakasone (20)
Último
Último (16)
Azure Data Mesh
- 3. Ejemplo de descomposición de un dominio funcional de Tailwind Traders Dominios de datos Administración de vales en línea Reservas y comisiones Publicidad y comercialización Servicios personalizados Administración de la contratación Administración del personal Gestión del dinero y el cambio Planificación e información general management Administración de las negociaciones Administración de seguros Viajes management Administración de logística Administración de costos Colaboración y comunicación IT services management Administración de emisiones y comercio justo Administración de servicios del cliente Administración de la plantilla y el personal Administración de los viajes Administración de servicios auxiliares
- 4. Ejemplo: Colaboración entre diferentes dominios Descomposición de dominios de datos y productos de datos Producto de datos Producto de datos Integración de datos Integración de datos Integración de datos Producto de datos Integración de datos Administración de vales en línea Servicios personalizados Colaboración y comunicación Servicios de productos de datos Servicios de productos de datos Servicios de productos de datos
- 5. Plataforma de adopción de la nube (CAF) Suscripciones para aplicaciones operativas Otras suscripciones Zona de aterrizaje de administración de datos (Purview, administración de datos maestros, calidad de los datos, Key Vault, directivas) Zona de aterrizaje de datos Dominio de datos Dominio de datos Dominio de datos Dominio de datos Dominio de datos Producto de datos Producto de datos Producto de datos Producto de datos Producto de datos Producto de datos Producto de datos Producto de datos Producto de datos Producto de datos Zona de aterrizaje única Patrón de malla de datos
- 6. Plataforma de adopción de la nube (CAF) Suscripciones Suscripciones Zona de aterrizaje de administración de datos (Purview, administración de datos maestros, calidad de los datos, Key Vault, directivas) Zona de aterrizaje de datos (en línea con el consumidor) Dominio de datos Dominio de datos Dominio de datos Dominio de datos Dominio de datos Producto de datos Producto de datos Producto de datos Producto de datos Producto de datos Producto de datos Producto de datos Producto de datos Producto de datos Producto de datos Zona de aterrizaje de datos (en línea con el sistema de origen) Dominio de datos Producto de datos Producto de datos Producto de datos Zonas de aterrizaje en línea con el sistema de origen y el consumidor Patrón de malla de datos II
- 7. Zona de aterrizaje de datos (n.º n) Plataforma de adopción de la nube (CAF) Suscripciones Suscripciones Zona de aterrizaje de administración de datos (Purview, administración de datos maestros, calidad de los datos, Key Vault, directivas) Zona de aterrizaje de datos (área funcional n.º 1) Dominio de datos Producto de datos Producto de datos Dominio de datos Producto de datos Producto de datos Dominio de datos Producto de datos Producto de datos Zona de aterrizaje de datos (área funcional n.º 2) Dominio de datos Producto de datos Producto de datos Dominio de datos Producto de datos Producto de datos Zonas de aterrizaje de datos alineadas funcional y regionalmente Patrón de malla de datos III
Notas del editor
- (Anfitrión):Por medio de nuestros compromisos con los clientes, y viendo cómo las empresas implementan unamalla de datos, una de las preguntas que me hacen a menudo es cómo separar las plataformas. (Anfitrión): El concepto de malla de datos hace referencia a la propiedad descentralizada de los datos orientada a los dominios. ¿Qué le parece? ¿Ve la distribución de datos entre dominios? (Otro): El asunto de los dominios de datos llama mucho la atención. Los profesionales consideran que la propiedad de los datos orientada al dominio es la parte más compleja de la malla de datos. A menudo, hay una falta de comprensión fundamental del diseño orientado al dominio (DDD). Otros profesionales de los datos consideran que las nociones conceptuales del DDD son demasiado difíciles de comprender o proyectan ejemplos procedentes de la arquitectura de software o la programación orientada a objetos en su paisaje de datos. Mi primera recomendación, antes de permitir que los equipos operen con sus datos de un extremo a otro, es examinar el ámbito y comprender los espacios de problema que está tratando de abordar. Es importante hacer este ejercicio primero, antes de pasar a los detalles de una implementación técnica. Como defensores del DDD, ayuda a establecer límites lógicos entre estos espacios de problemas, porque las responsabilidades están más claras y se administrarán mejor. Para agrupar sus espacios de problema, le animo a que examine su arquitectura empresarial. Dentro de la arquitectura empresarial, hay capacidades empresariales: habilidades o capacidades que una empresa puede poseer o intercambiar para lograr un propósito o resultado específico. Dicha abstracción agrupa datos, procesos, organización y tecnología dentro de un contexto particular, alineado con las metas y objetivos empresariales estratégicos de su organización. Un mapa de capacidades empresariales muestra las áreas funcionales supuestamente necesarias para cumplir con su misión y visión. En la pantalla se ve una descomposición de una agencia de viajes ficticia: Tailwind Traders, que necesita dominar todas las áreas funcionales enumeradas en el mapa de capacidades empresariales para completar con éxito sus tareas. Por ejemplo, Tailwind Traders debe ser capaz de vender billetes en el marco de su negocio. Sin esta capacidad, no puede tener éxito. Lo que observará en la práctica es que la mayoría de su personal se organiza en torno a estas capacidades. Las personas que trabajan en la misma capacidad empresarial comparten el mismo vocabulario. Lo mismo ocurre con sus aplicaciones y procesos, que suelen estar bien alineados y estrechamente conectados en función de la cohesión de las actividades a las que deben prestar apoyo. Por lo tanto, la asignación de la capacidad empresarial supone un gran punto de partida. (Anfitrión): La malla de datos también hace referencia al contexto limitado. ¿Esto lo mismo que una capacidad empresarial? (Otro): Las capacidades empresariales y los contextos limitados no son lo mismo, pero están muy relacionados. Los contextos limitados son los límites lógicos (de contexto). Se centran en el espacio de solución: el diseño de sistemas y aplicaciones. Es una esfera en la que la alineación del enfoque en el espacio de solución tiene sentido. (Anfitrión):Suena interesante, pero ¿cómo se aplica en la práctica?
- Anfitrión:Como vimos los dominios en la diapositiva anterior, esta arquitectura muestra la colaboración entre dominios. ¿Es así? Otro:Sí, así es. A la izquierda se ven los dominios donde se producen los datos. Ahí se ven también los servicios operativos y transitorios. Se ven los servicios de productos de datos para tomar los datos y crear productos de datos. Normalmente, se aprovisionan a partir de plantillas de implementación estándar. A la derecha se ve un dominio de consumo. Este dominio consume los datos de los otros dominios. Procesa estos datos, hace una combinación y crea nuevos datos, que de nuevo pueden resultar interesantes para otros dominios. Así que, en este sentido, el consumidor de datos es también un productor de datos. Anfitrión:¿Son los productos de datos una manera de eliminar las dependencias entre un dominio y otro? (Otro): ¡Justamente! Y aquí es también donde los productos de datos desempeñan un papel fundamental. Cuando se realiza una integración de límites o una distribución de datos entre dominios, hay que desacoplar la arquitectura interna de los consumidores de datos. Para ello, lo mejor es hacer una buena abstracción de los datos de su aplicación y proporcionar los datos como un producto. (Anfitrión):¡Suena muy bien! Pero también veo servicios de productos de datos. ¿Podría explicar de qué se trata? (Otro): Los servicios para crear un producto de datosson en el contexto de Azurelo que puede serun grupo de recursos con numeroso servicios preconfigurados, en plantilla o infraestructura como código. Está en consonancia con el enfoque de la plataforma de autoservicio y debería eliminar la preocupación de administrar su infraestructura. Para eso es también DMA.
- Anfitrión:Mike y John presentaron la zona de aterrizaje de administración de datos para la capa de administración y la zona de aterrizaje de datos como la capa para convertir los datos en valor. ¿Qué relación guarda lo que veo aquí con los dominios que hemos discutido hasta ahora? ¿Podría explicar cómo estas zonas de aterrizaje de datos afectan a sus dominios? Otro:Al crear una nueva suscripción en Azure, hay ciertas cosas que deben ser darse para garantizar que su entorno sea seguro, fiable y escalable. Quiere permitir que sus equipos utilicen el autoservicio, pero sin poner en riesgo la seguridad. Para ello, se requiere una composición de servicios de red, directiva y autenticación. A todo en conjunto lo llamamos zona de aterrizaje. Me gusta la analogía con la construcción de una casa, donde espera que esté disponible el agua, la electricidad y un sistema de aguas residuales para empezar a edificar. Pues lo mismo pasa en una zona de aterrizaje: los ingenieros de datos o los científicos de datos quieren centrarse solo en la creación de productos de datos y la empresa quiere prohibir la filtración de datos involuntaria o exponer públicamente los puntos de conexión, e impedir que su valioso lago de datos se convierta en un pantano de datos. Al usar las capacidades aprovisionadas como parte de la zona de aterrizaje garantizamos que los desarrolladores tengan la libertad de crear sus productos sin poner en riesgo ninguna de las directivas de la empresa. Hay un dicho que me gusta: utilizar la herramienta adecuada para el trabajo adecuado. A veces es un grupo de Spark para agregaciones de cientos de archivos, otras veces es un clúster de ADX para millones de registros de series temporales. Lo mismo ocurre con los productos de datos. Mike habló del almacenamiento políglota. Recomiendo el uso de la tecnología de almacenamiento más adecuada para el tipo de producto de datos y los requisitos de su consumo. Anfitrión:¿Por qué no se pueden combinar la zona de aterrizaje de administración de datos y la zona de aterrizaje de datos? Otro: Se puede, pero eso no significa que se deba. Esperamos que diferentes personas o equipos sean responsables de estas dos zonas de aterrizaje. Tienen funciones y propósitos muy diferentes. La zona de aterrizaje de administración de datos es una entidad central única para gobernar los datos en todos los dominios y sus productos de datos. La separación de los privilegios entre la administración de los datos y la creación y las operaciones de los productos de datos es una de las razones por las que recomendamos esta opción. Siempre habrá un 1:n entre los servicios de administración y los dominios de datos. Se pierde la capacidad de escalar horizontalmente cuando se agrupa todo en una sola suscripción.
- En el modelo anterior, no hemos tenido en cuenta otras suscripciones o aplicaciones locales. Por lo tanto, se puede hacer una sutil variación al modelo anterior agregando una zona de aterrizaje alineada con el sistema de origen para administrar todos los datos entrantes. Es lógico tener dos zonas de aterrizaje de datos, porque la incorporación de datos es un proceso difícil. Sigue siendo uno de los problemas más complejos cuando se utilizan datos a gran escala. Además, suele requerir herramientas adicionales para abordar los retos de integración, lo cual contrasta con la forma en que se produce el consumo de datos. Por lo tanto, es lógico distinguir entre el suministro y el consumo de datos. En la arquitectura de la izquierda, generalmente se espera que los servicios faciliten toda la incorporación de datos, comoCDC, servicios que extraen API, o servicios de lago de datos para crear dinámicamente conjuntos de datos inmutables. Los servicios de esta plataforma pueden extraer datos de entornos locales, de la nube o de proveedores de SaaS. Por lo general, también se espera que una plataforma de este tipo tenga más sobrecarga, ya que hay más acoplamiento con las aplicaciones operativas subyacentes. Por ello, es posible que desee plantear esta cuestión de manera diferente a cualquier uso de datos. A la derecha, se optimiza para el consumo y se esperan servicios destinados a convertir los datos en valor: aprendizaje automático, elaboración de informes, etc. De nuevo, en esta arquitectura los dominios siguen todos los principios de la malla de datos. Los dominios se apropian de los datos y pueden distribuirlos directamente a otros dominios.
- Anfitrión:Veo varias zonas de aterrizaje de datos. ¿Ahora qué es diferente? ¿Cuándo utilizar esta opción? Separación técnica, separación de seguridad, separación geográfica, separación de agilidad. Otro:Todo lo que ha dicho es correcto. Un principio de diseño clave es la democratización de la suscripción y el uso de las suscripciones tal cual como método para permitir el escalado. Luego hay que ver más de cerca cómo asignar los dominios a una zona de aterrizaje. Qué dominios pueden coexistir en una zona de aterrizaje y cuáles deben estar separados. La reparación exige algunos requisitos técnicos. Soberanía de los datos: debido a normativas como la Ley de Privacidad del Consumidor de California o el GDPR de la UE, se requiere que algunos datos se almacenen en una región específica o que se apliquen directivas específicas de la región. Redes: una zona de aterrizaje se aprovisiona con una red virtual y, dado que las redes virtuales están vinculadas regionalmente, una nueva región implica una nueva zona de aterrizaje, y las redes virtuales deben revisarse para permitir la comunicación entre dominios. Al decidir la distribución de sus zonas de aterrizaje de datos y sus dominios de datos, también hay que tener en cuenta: Latencia: qué dominios colaboran mucho en grandes cantidades de datos, si es así querrá reducir la cantidad de datos transferidos. Aumentará la latencia y, en caso de tener varias regiones, podría aumentar el coste. Coste: recorte para la asignación de costes, aunque también puede utilizar etiquetas. Seguridad: algunas implementaciones o configuraciones de servicios requieren privilegios elevados en una suscripción, y conceder esto a los usuarios de un dominio les dará implícitamente los privilegios en otro dominio dentro del ámbito de esa misma suscripción. Límites: hay algunos límites asociados a un ámbito de suscripción, y la división en varias suscripciones mitiga la posibilidad de llegar a alguno de estos límites. Una cosa que hay que tener en cuenta y que he visto hacer a los clientes son las zonas de aterrizaje de datos alineadas con el sistema de origen y con el consumidor. Anfitrión:¿Deben conservarse todos los datos de las empresas en una zona de aterrizaje de datos? Otros: Los datos nunca son una isla independiente, y es importante incluir el contexto de toda la arquitectura de la empresa. Las aplicaciones operativas pueden servir de fuente a los dominios de datos y convertirse en el productor del que consume un producto de datos.