Get best of the week

Migración de un Data Lake continuo a un Data Mesh distribuido

Hola Habr! Le presento la traducción del artículo "Cómo moverse más allá de un lago de datos monolítico a una malla de datos distribuidos" por Zhamak Dehghani (Zhamak Degani) (todas las imágenes están tomadas del mismo artículo).

Todas las grandes empresas ahora están tratando de construir enormes almacenes de datos centralizados. O incluso más grandes clusters Data Lakes (como regla, en una hdup). Pero no conozco un solo ejemplo de la construcción exitosa de dicha plataforma de datos. En todas partes hay dolor y sufrimiento tanto para quienes construyen una plataforma de datos como para los usuarios. En el siguiente artículo, el autor (Zhamak Degani) ofrece un enfoque completamente nuevo para construir una plataforma de datos. Esta es la arquitectura de la plataforma de datos de cuarta generación llamada Data Mesh. El artículo original en inglés es muy voluminoso y francamente difícil de leer. La traducción también resultó ser bastante grande y el texto no es muy simple: oraciones largas, vocabulario seco. No reformulé los pensamientos del autor para mantener la precisión de la redacción.Pero le recomiendo que siga leyendo este texto difícil y lea el artículo. Para aquellos que manejan datos, será muy útil y muy interesante.

Evgeny Cherny

Muchas compañías están invirtiendo en la próxima generación de Data Lake con la esperanza de simplificar el acceso a los datos de toda la compañía y proporcionar información comercial y la capacidad de tomar decisiones de alta calidad automáticamente. Pero los enfoques actuales para construir plataformas de datos tienen problemas similares que no nos permiten alcanzar nuestros objetivos. Para resolver estos problemas, debemos abandonar el paradigma de un lago de datos centralizado (o su predecesor, el almacén de datos). Y pase a un paradigma basado en una arquitectura distribuida moderna: considere los dominios comerciales como una prioridad de primer nivel, aplique el pensamiento de plataforma para crear una infraestructura con la capacidad de autoservicio y percibir los datos como un producto.

imagen

Contenido

  • La arquitectura actual de la plataforma de datos en una gran empresa.
    • Enfoques arquitectónicos problemáticos
    • domain driven
      • -
      • (data pipelines),
        • (discoverable)
        • (addressable)
        • ,
    • data- -
    • Infraestructura de datos centralizada como plataforma
  • Cambio de paradigma hacia Data Mesh

Construir una organización basada en datos sigue siendo uno de los principales objetivos estratégicos de muchas de las empresas con las que trabajo. Mis clientes son conscientes de los beneficios de tomar decisiones basadas en datos de calidad: proporcionar el servicio al cliente de la más alta calidad, hiperpersonalización, reducir los costos operativos y el tiempo debido a la optimización, proporcionar a los empleados herramientas de análisis e inteligencia empresarial. Invierten mucho en la construcción de plataformas de datos modernas. Pero a pesar de los crecientes esfuerzos e inversiones en la construcción de tales plataformas, muchas organizaciones ven los resultados como mediocres.

Las organizaciones enfrentan muchas dificultades en el proceso de transformación en una empresa basada en datos: migración de sistemas heredados y décadas de sistemas de desarrollo, resistencia de la cultura existente y alta competencia entre las diferentes prioridades comerciales. Sea como fuere, quiero compartir con ustedes un enfoque arquitectónico que tenga en cuenta los motivos del fracaso de muchas iniciativas en el campo de la construcción de plataformas de datos. Demostraré cómo podemos adaptar y aplicar las lecciones de la última década en la construcción de arquitecturas distribuidas en el campo de datos. He llamado a este nuevo enfoque arquitectónico Data Mesh .

Antes de seguir leyendo, le pido que intente abandonar los prejuicios establecidos por el paradigma actual de la arquitectura tradicional de la plataforma de datos mientras lee este artículo. Esté abierto a la posibilidad de pasar de Data Lakes centralizados a una arquitectura Data Mesh distribuida deliberadamente. Acepte que los datos están inherentemente distribuidos y omnipresentes.

La arquitectura actual de la plataforma de datos en una gran empresa.


Hablemos del significado centralizado, monolítico e independiente de los negocios de los datos de Data Lake.

Casi todos los clientes con los que trabajo están planificando o ya están construyendo su plataforma de datos de tercera generación. Reconociendo los errores de generaciones anteriores.

  • Primera generación: almacenes de datos empresariales propietarios y plataformas de inteligencia empresarial. Estas son decisiones por grandes sumas de dinero que dejaron a las empresas con cantidades igualmente grandes de deuda técnica. La deuda técnica se encuentra en miles de trabajos, tablas e informes de ETL no admitidos que solo un pequeño grupo de especialistas comprende, lo que lleva a una subestimación del impacto positivo de esta funcionalidad en el negocio.
  • Segunda generación: ecosistemas de Big Data con Data Lake como una bala de plata. Un complejo ecosistema de big data y trabajos por lotes de larga duración respaldados por un equipo central de ingenieros de datos altamente especializados. En el mejor de los casos, utilizado para análisis de I + D.

Las plataformas de datos de tercera generación son más o menos similares a las generaciones anteriores, pero con un sesgo hacia

  1. transmisión para proporcionar disponibilidad de datos en tiempo real con una arquitectura como Kappa ,
  2. combinando procesamiento por lotes y streaming para transformar datos utilizando marcos como Apache Beam ,
  3. uso de servicios en la nube para el almacenamiento y procesamiento de datos y plataformas de Cloud Machine Learning.

La plataforma de datos de tercera generación elimina algunos de los problemas de las generaciones anteriores, como el análisis de datos en tiempo real, y también reduce el costo de administrar una infraestructura de big data. Sin embargo, muchas características subyacentes que llevaron a las fallas de generaciones anteriores aún se conservan.

imagen
Figura 1: Tres generaciones de plataformas de datos

Enfoques arquitectónicos problemáticos


Para descubrir las limitaciones básicas que todas las generaciones de plataformas de datos tienen en sí mismas, echemos un vistazo a su arquitectura y características. En este artículo, utilizaré el negocio de la transmisión de medios de Internet (como Spotify, SoundCloud, Apple iTunes) como ejemplo para explicar algunos conceptos.

Centralizado y monolítico.


Desde una altura de 10,000 metros, la arquitectura de la plataforma de datos se parece a la Figura 2 a continuación.
imagen
Figura 2: Vista desde una altura de 10.000 metros en una plataforma de datos monolíticos. La

parte central de la arquitectura es responsable de:

  • (to ingest) , , . , , : ; ; ; , ; ( ..).
  • , , , . , , — .
  • (to serve) . machine learning BI . , . , Kafka.

Por defecto, el acuerdo generalmente aceptado es el hecho de que la Plataforma de datos monolítica almacena y posee datos que pertenecen a diferentes dominios comerciales. Por ejemplo, 'reproducir eventos', 'KPI de ventas', 'artistas', 'álbumes', 'etiquetas', 'audio', 'podcasts', 'eventos musicales', etc. - datos de una gran cantidad de dominios dispares.

A pesar del hecho de que durante la última década hemos aplicado con éxito el concepto de diseño impulsado por dominio (y su patrón de contexto acotado clave ) al diseño de nuestros sistemas de información, hemos ignorado en gran medida estos conceptos en el diseño de plataformas de datos. Hemos pasado de la propiedad de datos a nivel de dominio comercial a la propiedad de datos, independientemente de los dominios comerciales. Estamos orgullososque creó el mayor monolito: la plataforma Big Data.

imagen
Figura 3: Una plataforma de datos centralizada sin límites claros entre los datos de diferentes dominios comerciales. Y sin la propiedad de los datos relevantes por parte del dominio comercial,

un modelo tan centralizado puede funcionar para organizaciones pequeñas que tienen dominios comerciales simples y opciones limitadas de consumo de datos. Pero no es adecuado para grandes empresas con dominios comerciales grandes y complejos, una gran cantidad de fuentes de datos y diversas necesidades para trabajar con datos de los consumidores.

Hay dos enlaces débiles en la arquitectura y estructura de una plataforma de datos centralizada, que a menudo conducen a fallas en el proceso de construcción:

  • Una gran cantidad de fuentes y grandes cantidades de datos.. , , . , . . , , , . , data scientists . , ( ) , . , – - .
  • . . , . .

Aquí necesito aclarar que no estoy hablando a favor del uso de datos fragmentados y dispares escondidos en las profundidades de los sistemas heredados. Tales datos que son difíciles de detectar, comprender y usar. Tampoco apoyo los numerosos depósitos de datos dispares dentro de la misma organización, que son el resultado de muchos años de deuda técnica acumulada. Pero sostengo que la respuesta a estos datos fragmentados inaccesibles no es crear una plataforma de datos centralizada con un equipo centralizado que almacene y posea datos de todos los dominios comerciales.

Este enfoque no escala en grandes organizaciones, como se muestra arriba.

Descomposición del transportador altamente conectado


imagen
Figura 4: Descomposición arquitectónica de la plataforma de datos

El segundo problema con la arquitectura tradicional de la plataforma de datos es cómo descomponemos la arquitectura. Si cae a 3.000 metros sobre la arquitectura de la plataforma de datos, encontraremos una descomposición arquitectónica en torno a las funciones de carga, limpieza, agregación, servicio de datos, etc. Como se describe en la sección anterior, la necesidad de conectar nuevas fuentes y nuevos consumidores requiere un crecimiento de la plataforma. Los arquitectos deben encontrar una manera de escalar el sistema dividiéndolo en cuantos arquitectónicos. Cuántica arquitectónica, como se describe en el libro " Construyendo arquitecturas evolutivas", Es un componente de implementación independiente con alta conectividad funcional, que incluye todos los elementos estructurales necesarios para el correcto funcionamiento del sistema. La motivación para dividir el sistema en cuantos arquitectónicos consiste principalmente en crear equipos independientes, cada uno de los cuales crea y mantiene su propio quantum arquitectónico (subsistema funcional). Esto le permite paralelizar el trabajo y aumentar la velocidad y la escalabilidad operativa.

Influenciados por generaciones anteriores de plataformas de datos, los arquitectos dividen la plataforma en una serie de pasos de procesamiento de datos. Esta es una tubería que implementa el procesamiento de datos: cargar, preparar, agregar, proporcionar acceso / descarga, etc.

Aunque esta partición proporciona un cierto nivel de escala, también tiene una limitación interna que ralentiza el desarrollo de nuevas funcionalidades en la plataforma: hay una alta conectividad entre los pasos de la tubería, lo que no permite la independencia necesaria del trabajo de los equipos individuales.

Volvamos a nuestro ejemplo de transmisión de medios. Las plataformas de transmisión de medios en Internet tienen un diseño de dominio fuerte en torno al tipo de medios que ofrecen. A menudo comienzan sus servicios con "canciones" y "álbumes", y luego se aplican a "eventos musicales", "podcasts", "programas de radio", "películas", etc. Habilitando una nueva característica, por ejemplo, visibilidad para "podcasts" tasa de reproducción ", requiere un cambio en todos los componentes de la tubería. Los equipos necesitan desarrollar nuevos servicios para cargar, limpiar y preparar datos (incluida la agregación) para agregar la visibilidad de la "tasa de reproducción de podcasts". Esto requiere sincronización entre lanzamientos de varios equipos funcionales. Muchas plataformas de datos usan herramientas de descarga basadas en la configuración que pueden manejar fácilmente tales tareas.como simplemente agregar nuevas fuentes o expandir las existentes. Pero esto no elimina la necesidad de una gestión de lanzamiento de extremo a extremo en todas las etapas del proceso de procesamiento de datos. Para proporcionar a los usuarios acceso a cualquier dato nuevo, la unidad arquitectónica mínima que debe cambiarse es toda la tubería. Y esto limita significativamente nuestra capacidad de aumentar la velocidad y la escala del desarrollo de la plataforma de datos en respuesta a la aparición de nuevas fuentes de datos y usuarios.Y esto limita significativamente nuestra capacidad de aumentar la velocidad y la escala del desarrollo de la plataforma de datos en respuesta a la aparición de nuevas fuentes de datos y usuarios.Y esto limita significativamente nuestra capacidad de aumentar la velocidad y la escala del desarrollo de la plataforma de datos en respuesta a la aparición de nuevas fuentes de datos y usuarios.

Equipos dispares y altamente especializados.


El tercer problema con las plataformas de datos modernas es cómo estructuramos los equipos que crean y mantienen la plataforma. Cuando bajemos lo suficiente sobre la arquitectura de una plataforma de datos tradicional, veremos un grupo de ingenieros de datos estrechamente especializados separados de aquellas unidades organizativas en las que los datos se crean o utilizan para la toma de decisiones. Los ingenieros de plataformas de datos se seleccionan en equipos separados solo en función de sus competencias técnicas y experiencia con las tecnologías de big data. El conocimiento comercial de las áreas temáticas correspondientes (dominios comerciales) está ausente en dichos equipos.

imagen
Figura 5: equipos dispersos de plataforma de datos estrechamente especializados

Personalmente, no envidio las vidas de los ingenieros de plataformas de datos. Deben recibir datos de equipos que no tienen incentivos para proporcionar datos correctos y de calidad. Carecen de una comprensión del significado comercial de los datos que tiene que descargar. Deben preparar los datos para satisfacer las necesidades analíticas y operativas, sin una comprensión clara del uso final de estos datos y sin acceso a expertos en el campo del consumo de estos datos.

Cabe señalar que anteriormente nos hemos encontrado con un problema similar de separación del equipo. Y pudieron encontrar una solución exitosa a este problema.

imagen

En nuestro ejemplo con transmisión multimedia, tenemos el comando "reproductor multimedia", que posee datos sobre cómo los usuarios interactúan con el reproductor: canciones que los usuarios escuchan, compras realizadas, calidad de audio de las canciones que escuchan, etc. Por otro lado, hay equipos de consumidores de datos relevantes: un equipo de recomendaciones de canciones; equipo de monitoreo de ventas; equipo de pago del artista, etc. Y entre ellos, un triste equipo de desarrolladores de una plataforma de datos, que, a costa de un gran esfuerzo, recibe datos de un equipo y proporciona acceso a ellos (después del procesamiento preliminar) a todos los consumidores.

En realidad, tenemos equipos de fuente de datos no involucrados y equipos de consumidores de datos frustrados que tienen que luchar por un lugar en la cima del trabajo atrasado del equipo de desarrollo de la plataforma de datos.

Hemos creado una arquitectura y estructura organizativa que no proporciona la escalabilidad necesaria y no puede lograr los objetivos de construir una organización basada en datos.

Arquitectura de plataforma de datos de próxima generación


¿Y cuál es la solución a los problemas que discutimos anteriormente? En mi opinión, se necesita un cambio de paradigma. Un cambio de paradigma en la intersección de los métodos que han jugado un papel importante en la construcción de una arquitectura distribuida escalable moderna y que la industria de la tecnología en su conjunto ha implementado a un ritmo acelerado. Métodos que han arrojado resultados exitosos.

Creo que la próxima arquitectura para la plataforma de datos empresariales es integrar la Arquitectura dirigida por dominio distribuido, diseñar plataformas de autoservicio y el pensamiento de productos para los datos.

imagen
Figura 6: Cambio del cambio de paradigma de la plataforma de datos de próxima generación.

Entiendo que esto puede sonar como muchas palabras de moda en una oración, pero cada uno de estos componentes ha tenido un impacto increíblemente positivo en el cambio de las bases técnicas de nuestros sistemas de información. Veamos cómo podemos aplicar cada una de estas disciplinas al mundo de los datos para alejarnos del paradigma actual que se ha transferido de muchos años de construir almacenes de datos de generaciones anteriores.

Arquitectura impulsada por datos y dominio distribuido


Descomposición y propiedad de los datos en función de la orientación del dominio empresarial.


El libro de Eric Evans, Diseño impulsado por dominio , ha tenido un profundo impacto en el pensamiento arquitectónico contemporáneo y, por lo tanto, en el modelado organizacional. La nueva arquitectura de microservicios descompuso los sistemas de información en servicios distribuidos que se construyen dentro de los límites de dominios comerciales específicos. Esto cambió fundamentalmente la forma en que se forman los equipos: a partir de ahora, un equipo puede ser dueño de sus microservicios de forma independiente y autónoma.

Curiosamente, ignoramos el concepto de dominios comerciales en el campo de los datos. Próxima aplicación de diseño dirigido por dominio en arquitectura de plataforma de datos: esta es la aparición de eventos de dominio empresarialen sistemas de información y cargarlos en plataformas de datos monolíticas. Sin embargo, después de que los datos se cargan en el almacenamiento centralizado, se pierde el concepto de propiedad de los datos de diferentes dominios comerciales por parte de diferentes equipos.

Para descentralizar una plataforma de datos monolíticos, debe cambiar su forma de pensar sobre los datos, su ubicación y propiedad. En lugar de transferir datos a un Data Lake o plataforma, los dominios deberían almacenar y mantener sus conjuntos de datos de una manera fácil de usar.

En nuestro ejemplo, en lugar de cargar datos del reproductor multimedia en un repositorio centralizado para su posterior procesamiento por parte del equipo de soporte del repositorio, ¿por qué no almacenar y procesar estos conjuntos de datos dentro del dominio y no darles acceso a ningún otro equipo? El mismo lugar donde estos conjuntos de datos se almacenarán físicamente se puede implementar técnicamente dentro del dominio como lo desee. Por supuesto, puede utilizar una arquitectura centralizada, pero los datos de los reproductores multimedia permanecerán bajo la propiedad y el soporte del equipo del dominio correspondiente en el que se generan estos datos. De manera similar, en nuestro ejemplo, el dominio de desarrollo de recomendaciones de canciones puede crear conjuntos de datos en el formato más adecuado para su uso (por ejemplo, en forma de estructuras gráficas) en base a los datos del reproductor multimedia. Si hay otros equipos,quienes consideran este formato conveniente y útil, también pueden acceder a él.

Esto, por supuesto, implica que podemos duplicar datos en diferentes dominios cuando cambiamos su formato a uno que se adapte a un consumidor en particular.

Todo esto requiere un cambio en nuestro pensamiento de descargar datos (a través de ETL o transmisión) para escalar este proceso a todos los dominios. El cuanto arquitectónico en una plataforma de datos orientada al dominio es un dominio empresarial, no la etapa de carga y transformación de datos.

imagen
Figura 7: Descomposición de una arquitectura basada en dominios empresariales y equipos propietarios de datos.

Conjuntos de datos del dominio de origen


Algunos dominios comerciales están bien alineados con las fuentes de datos (sistemas de información). En el caso ideal, el sistema de información y el equipo que lo acompaña no solo son responsables de agregar y respaldar la funcionalidad comercial, sino que también proporcionan conjuntos de datos que describen los hechos y la realidad del dominio comercial correspondiente. Sin embargo, a escala de una gran organización, por regla general, no existe una correspondencia inequívoca entre el dominio comercial y el sistema de información. Como regla general, para cada dominio hay varios sistemas de información que automatizan diferentes procesos comerciales de un dominio determinado y, en consecuencia, almacenan datos relacionados con él. Para tales dominios, existe la necesidad de integrar y agregar datos dispares para obtener conjuntos de datos consistentes y alineados en todo el dominio comercial.

El mejor formato para almacenar hechos que describen un dominio comercial es Eventos de dominio . Se pueden almacenar como un registro de eventos distribuido con marcas de tiempo. Este registro puede tener acceso a consumidores autorizados.

Además de estos registros, las fuentes de datos también deben proporcionar acceso a instantáneas periódicas de conjuntos de datos clave en su dominio. Agregar tales imágenes es para el intervalo de tiempo que refleja mejor el intervalo de cambios para su dominio (generalmente un día / semana / mes / trimestre, etc.).

Tenga en cuenta que los conjuntos de datos de dominio empresarial preparados para los consumidores deben estar separados de los conjuntos de fuentes de datos internos (que los sistemas de información utilizan para su trabajo). Deben almacenarse en un lugar físicamente diferente adecuado para trabajar con big data. A continuación, se describirá cómo crear un almacén de datos y una infraestructura de servicio de este tipo.

Los conjuntos de datos específicos del dominio preparados para los consumidores son los elementos más básicos de toda la arquitectura. No se transforman y no se adaptan a un consumidor específico, sino que son datos sin procesar y sin procesar.

Conjuntos de datos de dominio del consumidor


Otros dominios están estrechamente relacionados con los consumidores de datos. Los conjuntos de datos de dicho dominio se crean de tal manera que, cuando se usan, se ajustan al conjunto asociado de escenarios de usuario. Estos conjuntos de datos son diferentes de los conjuntos de datos del dominio de origen. No se trata de datos sin procesar, sino de datos que pasan por varias etapas de transformación. La estructura de estos conjuntos de datos y su presentación se adaptan a los casos específicos de su uso. Aquellos. Este es un análogo de los mercados de datos especializados en un repositorio centralizado. Para tales conjuntos de datos del dominio del consumidor (conjuntos de datos del dominio del consumidor) se debe proporcionar la posibilidad de una recuperación rápida de los datos sin procesar.

Canalizaciones de datos distribuidos implementados dentro de sus dominios


La propiedad de los datos en nuestra nueva arquitectura se delega desde la plataforma central a los equipos dentro de los dominios comerciales, pero la necesidad de limpieza, preparación y agregación de datos (utilizando la tubería de datos) no desaparece. Por lo tanto, la implementación de su propia tubería de datos se convierte en una tarea interna del equipo del dominio comercial. Como resultado, obtenemos nuestros propios canales de datos de dominio distribuidos en todos los dominios.

Por ejemplo, los dominios de origen deben incluir limpieza de datos, eliminación de duplicados, enriquecimiento de datos, etc., para que otros dominios puedan usar estos datos sin un procesamiento preliminar. Cada conjunto de datos debe cumplir con su objetivo de nivel de servicio en términos de calidad de datos.

Del mismo modo, las etapas de creación de vitrinas especializadas de una tubería centralizada para el procesamiento de datos entran en las propias tuberías de datos de los dominios del consumidor que crean conjuntos de datos de dominio del consumidor.

imagen
Figura 8: Tuberías de procesamiento de datos distribuidos implementadas dentro de sus dominios

Puede parecer que tal modelo conducirá a una gran duplicación de esfuerzos en cada dominio para crear su propia implementación de una tubería de procesamiento de datos. Hablaremos sobre este tema en la sección "infraestructura de datos centralizada como plataforma".

Pensamiento de datos y productos


La transferencia de la propiedad de los datos y la responsabilidad del desarrollo y mantenimiento de las canalizaciones de procesamiento de datos al lado de los dominios comerciales puede causar una gran preocupación sobre la disponibilidad continua y la facilidad de uso de dichos conjuntos de datos distribuidos. Por lo tanto, aquí llegamos al pensamiento práctico del producto en relación con los datos.

Datos de dominio como producto


En los últimos diez años, el pensamiento sobre productos ha penetrado profundamente en el desarrollo de los sistemas de información de las organizaciones y ha transformado seriamente el enfoque de este desarrollo. Los equipos de dominio para el desarrollo de sistemas de información proporcionan nuevas capacidades en forma de API que los desarrolladores usan en las organizaciones como bloques de construcción para crear una funcionalidad de mayor orden y un mayor valor. Los equipos se esfuerzan por crear la mejor experiencia para los usuarios de sus API a través de una documentación clara y detallada que sea de fácil acceso para los usuarios; entornos de prueba indicadores de calidad cuidadosamente rastreados.

Para que una plataforma de datos distribuidos tenga éxito, los equipos de datos de los dominios comerciales deben aplicar el pensamiento del producto en relación con el suministro de conjuntos de datos: percibir los datos que preparan como producto y los consumidores (analistas, científicos de datos, ingenieros de datos, especialistas en ML) etc.) como sus clientes.

imagen
Figura 9: Características de los conjuntos de datos de dominio como productos

Considere nuestro ejemplo: transmisión de contenido multimedia a través de Internet. El dominio comercial más importante es la historia de la reproducción: por quién, dónde, cuándo y qué canciones se escucharon. Este dominio tiene varios consumidores de datos clave dentro de la organización. Uno requiere datos en modo casi en tiempo real para estudiar la experiencia del usuario y la detección oportuna de cualquier problema y error de reproducción. Otros están interesados ​​en instantáneas históricas agregadas por día o mes. Por lo tanto, nuestro dominio proporciona datos en dos formatos: eventos de reproducción en forma de transmisión (transmisión, tema en kafka o algo así) y eventos de reproducción agregados en formato por lotes (archivo, tabla en colmena, etc.).

Para proporcionar la mejor experiencia de usuario a los consumidores, los productos de datos de dominio empresarial deben tener las siguientes características clave.

Conveniencia y facilidad de detección (detectable)


Es necesario garantizar las condiciones bajo las cuales se puede encontrar fácilmente cualquier producto de datos. La implementación más común de este requisito es la presencia de un registro: un catálogo de todos los productos de datos disponibles con la metainformación necesaria (como propietarios, fuentes de origen, muestras de conjuntos de datos, frecuencia de actualización, estructura de conjuntos de datos, etc.). Dicho servicio centralizado permite a los consumidores de datos encontrar fácilmente el conjunto de datos que les interesa. Cada producto de datos de cualquier dominio comercial debe estar registrado en un directorio de datos centralizado.

Tenga en cuenta que hay un cambio de una única plataforma centralizada que posee todos los datos a los productos de datos distribuidos de diferentes dominios comerciales que están registrados en un solo directorio de datos.

Dirección única (direccionable)


Cada producto de datos debe tener una dirección única (de acuerdo con el acuerdo global), lo que permitirá a sus consumidores obtener acceso programático. Las organizaciones pueden adoptar varios acuerdos sobre el nombre de los productos de datos y su ubicación, según los métodos disponibles de almacenamiento físico de datos y los formatos de los datos en sí. Para la arquitectura descentralizada distribuida, tales convenciones generales son necesarias. Los estándares de dirección del conjunto de datos eliminarán la fricción al buscar y acceder a productos de datos.

Calidad de los datos


Nadie usará un producto que no sea creíble. En las plataformas de datos de la generación actual, la descarga y publicación de datos que contienen errores y no reflejan toda la verdad comercial es generalizada, es decir datos en los que no se puede confiar. Es en esta parte que se concentra un número significativo de trabajos ETL, que borran los datos después de la carga.

La nueva arquitectura requiere que los propietarios de productos de datos adopten el SLO (objetivo de nivel de servicio) en términos de precisión, confiabilidad y relevancia de los datos. Para garantizar una calidad aceptable, es necesario utilizar métodos como la limpieza de datos y las pruebas automáticas de integridad de datos en la etapa de creación de un producto de datos. La información sobre el linaje de datos en los metadatos de cada producto de datos brinda a los consumidores una confianza adicional en el producto en sí y su idoneidad para necesidades específicas.

El valor objetivo del indicador de calidad de datos (o el rango aceptable) varía según el producto de datos de un dominio comercial particular. Por ejemplo, un dominio de "evento de reproducción" puede proporcionar dos productos diferentes: uno en modo casi en tiempo real con un nivel de precisión más bajo (incluidos los eventos perdidos o repetidos); y el segundo con un retraso más largo y un mayor nivel de calidad de datos. Cada producto de datos define y mantiene un nivel objetivo de integridad y confiabilidad de sus datos en forma de un conjunto de SLO (objetivo de nivel de servicio).

Descripción clara de la semántica y la sintaxis de datos.


Los productos de calidad deben ser fáciles de usar. La creación de productos de datos tan simples como sea posible para el uso de analistas, ingenieros y científicos de datos requiere la presencia de una semántica y sintaxis de datos bien descritas. Idealmente, los conjuntos de datos de muestra se proporcionan como ejemplos.

Integrabilidad de datos y estándares de toda la organización


Uno de los principales problemas en una arquitectura de datos dirigida por dominio distribuido es la necesidad de integrar datos de diferentes dominios. La clave para una integración de datos fácil y eficiente entre dominios es definir y seguir reglas y estándares. Dichos estándares deben definirse a nivel de la organización. Se requiere estandarización en el campo de determinar tipos de datos y reglas aceptables para su aplicación, convenciones sobre los nombres y direcciones de productos de datos, formatos de metadatos, etc.

Para aquellas entidades que pueden almacenarse en una forma diferente y con un conjunto diferente de atributos en diferentes dominios, es necesario implementar la práctica de la Gestión de datos maestros. Asigne identificadores globales y alinee el conjunto y, lo más importante, atribuya valores entre todos los dominios.

Asegurar la interoperabilidad de los datos para su integración efectiva, así como definir estándares para almacenar y presentar productos de datos a nivel de la organización, son uno de los principios fundamentales para construir tales sistemas distribuidos.

Seguridad de datos y control de acceso


Es imprescindible garantizar un acceso seguro a los datos, independientemente de si la arquitectura está centralizada o no. En el mundo de los productos de datos orientados al dominio empresarial descentralizado, el control de acceso es posible (y debe aplicarse) con un mayor grado de granularidad para cada conjunto de datos. Las políticas de control de acceso a datos se pueden definir de forma centralizada, pero se implementan por separado para cada producto de datos. Como una forma conveniente de implementar el control de acceso a los conjuntos de datos, puede utilizar el sistema Enterprise Identity Management y el control de acceso basado en roles .

A continuación, se describirá una infraestructura única, que le permite implementar fácil y automáticamente las características anteriores para cada producto de datos.

Comando de datos de dominio empresarial multifuncional


Los siguientes roles deben estar representados en los equipos que proporcionan datos en forma de productos de datos: propietario del producto de datos e ingeniero de datos.

El propietario del producto de datos es responsable del concepto y la hoja de ruta, el ciclo de vida de sus productos. Mide la satisfacción de sus clientes y mide y mejora constantemente la calidad de los datos de su dominio comercial. Llena y equilibra la acumulación de sus productos de datos con los requisitos de los consumidores de datos.

Además, los propietarios de productos de datos deben definir métricas clave e indicadores de rendimiento (KPI) para sus productos. Por ejemplo, el tiempo requerido por el usuario para familiarizarse y comenzar a usar el producto de datos puede ser una de estas métricas.

Para crear y mantener sus propios canales de datos dentro de un dominio comercial, el equipo debe incluir ingenieros de datos. Un buen efecto secundario de esto será la difusión de habilidades relevantes dentro del dominio comercial. Según mis observaciones, en la actualidad algunos ingenieros de datos, aunque son competentes en el uso de sus herramientas y tecnologías, carecen de conocimiento de las prácticas estándar de desarrollo de software cuando se trata de crear productos de datos. En primer lugar, las prácticas de DevOps como la entrega continua y las pruebas automáticas. Por otro lado, los desarrolladores de software que desarrollan sistemas de información a menudo no tienen suficiente experiencia y conocimiento en el campo de las tecnologías y herramientas para trabajar con datos como producto.Combinarlos en equipos multifuncionales dentro del dominio comercial conducirá a la aparición de especialistas de un perfil más amplio. Observamos algo similar durante el desarrollo de DevOps cuando aparecieron nuevos tipos de ingenieros, comoSRE .

imagen
Figura 10: Comando de datos de dominio funcional cruzado

Infraestructura de datos centralizada como plataforma


Uno de los aspectos sensibles de la arquitectura de la plataforma de datos basada en el dominio distribuido es la necesidad de duplicar en cada dominio los esfuerzos y habilidades necesarias para operar la infraestructura y la pila de tecnología utilizada en las tuberías de datos. Afortunadamente, la creación de una infraestructura común como plataforma es una tarea que se aprende bien a resolver en TI (pero no en el campo de trabajar con datos).

El equipo de infraestructura de datos debe poseer y proporcionar como servicio las herramientas necesarias para que los dominios comerciales recopilen, procesen y almacenen sus productos de datos.

imagen
Figura 11: Infraestructura de datos como plataforma

La infraestructura de datos como plataforma debe estar libre de conceptos específicos de dominio o lógica de negocios. Además, la plataforma debe ocultar a los usuarios la complejidad de su implementación y proporcionar la cantidad máxima de su funcionalidad para usar en modo de autoservicio. Aquí hay una lista de algunas de las características que debe proporcionar una infraestructura de datos centralizada, como una plataforma:

  • Almacenamiento de datos escalable en varios formatos.
  • Cifrado de datos (aquí hashing, despersonalización, etc.)
  • Versiones de productos de datos
  • Almacenamiento de datos esquema de datos del producto
  • Control de acceso a datos
  • Inicio sesión
  • Orquestación de subprocesos / procesos de procesamiento de datos
  • Caché en memoria
  • Almacenar metadatos y linaje de datos
  • Monitoreo, alertas, registro.
  • Cálculo de métricas de calidad para productos de datos.
  • Mantenimiento del catálogo de datos
  • Estandarización y políticas, la capacidad de controlar el cumplimiento
  • Direccionamiento de productos de datos
  • Canalizaciones de CI / CD para productos de datos

Al crear una infraestructura de datos centralizada, es necesario asegurarse de que la creación de un producto de datos en dicha infraestructura tome el menor tiempo posible. Por lo tanto, la máxima automatización de la funcionalidad clave es muy importante, como: la capacidad de descargar datos utilizando configuraciones simples, el registro automático de un producto de datos en el directorio de datos, etc. El uso de la infraestructura en la nube puede reducir los costos operativos y aumentar la velocidad de acceso a la infraestructura de datos a pedido.

Cambio de paradigma hacia Data Mesh


Fue una lectura larga! Resumamos brevemente todo lo que está escrito arriba. Examinamos algunas de las características clave de las plataformas de datos modernas: canalizaciones de datos centralizadas, monolíticas y complejas (con cientos y miles de trabajos estrechamente conectados entre sí), equipos dispares y altamente especializados. Después, hablamos sobre un nuevo enfoque de malla de datos, que incluye productos de datos distribuidos centrados en dominios comerciales administrados por equipos multifuncionales (con propietarios de productos de datos e ingenieros de datos), utilizando una infraestructura de datos común como plataforma para el alojamiento.

Data Mesh es una arquitectura distribuida, con administración centralizada y estándares desarrollados que aseguran la integración de datos, y con una infraestructura centralizada que permite el uso de autoservicio. Espero que el lector sea bastante obvio que dicha arquitectura está muy lejos de un conjunto de almacenamiento de datos inaccesibles acoplado libremente, desarrollado independientemente en diferentes departamentos.

imagen
Figura 12: Arquitectura de malla de datos de 10,000 metros

Puede preguntar: ¿cómo encaja Data Lake o Data Warehouse en esta arquitectura? Son simplemente nodos separados (dominios) en esta arquitectura distribuida. Hay una alta probabilidad de que en dicha arquitectura ya no necesitemos Data Lake. Después de todo, tendremos acceso para investigar los datos originales de diferentes dominios comerciales, diseñados en forma de productos de datos.

En consecuencia, Data Lake ya no es el elemento central de toda la arquitectura. Pero continuaremos utilizando las tecnologías y herramientas utilizadas para construir Data Lake, ya sea para crear una infraestructura de datos común o para la implementación interna de nuestros productos de datos.

Esto realmente nos lleva de vuelta a donde todo comenzó. James dicksonen 2010 tenía la intención de usar Data Lake para un dominio comercial, y varios dominios de datos formarían Water Garden.

El cambio de paradigma principal es considerar el producto de datos de dominio empresarial como una tarea de primera prioridad, y las herramientas y tecnologías como una tarea de segunda prioridad (como un detalle de implementación). Esto es para desviar el modelo mental de un Data Lake centralizado a un ecosistema de productos de datos que se integran de manera transparente y eficiente entre sí.

Algunas palabras sobre informes y visualización (usando herramientas de BI, etc.). El mismo principio se aplica a ellos: en esta arquitectura son nodos separados. Aquellos. son productos de datos independientes dentro de un dominio comercial, enfocados principalmente en el consumidor y no en la fuente de datos.

Admito que aunque veo la aplicación exitosa de los principios de Data Mesh por parte de mis clientes, escalar estos principios en grandes organizaciones tiene un largo camino por recorrer. Pero la tecnología obviamente no es una limitación aquí. Todas las herramientas que utilizamos hoy en día pueden usarse igualmente para la distribución y propiedad de productos de datos por diferentes equipos. En particular, la transición a la estandarización de los trabajos de procesamiento de paquetes y transmisión de datos, así como el uso de herramientas como Apache Beam o Google Cloud DataFlow , facilita el procesamiento de una variedad de conjuntos de datos con direcciones únicas.

Plataformas de catálogo de datos como Google Cloud Data Catalog, proporcionan facilidad de descubrimiento, control de acceso y administración centralizada de conjuntos de datos de dominios comerciales distribuidos. Una gran cantidad de plataformas en la nube permite a los dominios empresariales elegir el adecuado para el almacenamiento dirigido de sus productos de datos.

La necesidad de un cambio de paradigma es obvia. Existen todas las tecnologías y herramientas necesarias para esto. Los ejecutivos de negocios y los profesionales de procesamiento de datos deben reconocer que el paradigma y el enfoque actual de Big Data con una gran plataforma de Data Lake solo repetirá las fallas del pasado, utilizando nuevas tecnologías y herramientas en la nube.

Pasemos de una plataforma de datos monolíticos centralizada a un ecosistema de productos de datos.

imagen

Enlaces a fuentes primarias y materiales adicionales sobre el tema.


More articles:


All Articles