Para un ingeniero de datos que crea análisis a partir de sistemas transaccionales como ERP (planificación de recursos empresariales) y CRM (gestión de relaciones con el cliente), el principal desafío radica en sortear la brecha entre los datos operativos sin procesar y el conocimiento del dominio. Los sistemas ERP y CRM están diseñados y construidos para cumplir con una amplia gama de procesos y funciones comerciales. Esta generalización hace que sus modelos de datos sean complejos y crípticos y requieran experiencia en el dominio..
Aún más difícil de gestionar, una configuración común dentro de las grandes organizaciones es tener varias instancias de estos sistemas con algunos procesos subyacentes a cargo de transmitir datos entre ellos, lo que podría generar duplicaciones, inconsistencias y opacidad.
La desconexión entre los equipos operativos inmersos en las funciones del día a día y aquellos que extraen valor comercial de los datos generados en los procesos operativos sigue siendo un punto de fricción importante.
Imagine ser un ingeniero/analista de datos encargado de identificar los productos más vendidos dentro de su empresa. Su primer paso podría ser localizar los pedidos. Luego comienza a investigar los objetos de la base de datos y encuentra un par de vistas, pero hay algunas inconsistencias entre ellas, por lo que no sabe cuál usar. Además, es muy difícil identificar a los propietarios, uno de ellos incluso dejó la empresa recientemente. Como no desea comenzar su desarrollo con incertidumbre, decide buscar directamente los datos operativos sin procesar. ¿Te suena familiar?
Solía conectarme a vistas en bases de datos transaccionales o API ofrecidas por sistemas operativos para solicitar los datos sin procesar.
Para evitar que mis extracciones afecten el rendimiento operativo, consulté estos datos periódicamente y los almacené en un área de preparación persistente (PSA) dentro de mi almacén de datos. Esto me permitió ejecutar consultas complejas y canalizaciones de datos utilizando estas instantáneas sin consumir ningún recurso de los sistemas operativos, pero podría dar lugar a una duplicación innecesaria de datos en caso de que no estuviera al tanto de que otros equipos estuvieran realizando la misma extracción.
Una vez que los datos operativos sin procesar estuvieron disponibles, entonces tuve que afrontar el siguiente desafío: descifrar todos los objetos y propiedades crípticos y lidiar con el laberinto de docenas de relaciones entre ellos (es decir, datos generales de materiales en SAP documentados). https://leanx.eu/en/sap/table/mara.html)
Aunque los objetos estándar dentro de los sistemas ERP o CRM están bien documentados, Necesitaba lidiar con numerosos objetos y propiedades personalizados que requieren experiencia en el dominio. ya que estos objetos no se pueden encontrar en los modelos de datos estándar. La mayor parte del tiempo me encontré lanzando consultas de “prueba y error” en un intento de alinear claves entre objetos operativos, interpretando el significado de las propiedades de acuerdo con sus valores y verificando mis suposiciones con capturas de pantalla de la interfaz de usuario operativa.
Una implementación de Data Mesh mejoró mi experiencia en estos aspectos:
- Conocimiento: Pude identificar rápidamente a los propietarios de los datos expuestos. La distancia entre el propietario y el dominio que generó los datos es clave para acelerar un mayor desarrollo analítico.
- Descubribilidad: Una plataforma de datos compartidos proporciona un catálogo de conjuntos de datos operativos en forma de productos de datos alineados con las fuentes que me ayudaron a comprender el estado y la naturaleza de los datos expuestos.
- Accesibilidad: Podría solicitar fácilmente acceso a estos productos de datos. Como estos datos se almacenan en la plataforma de datos compartidos y no en los sistemas operativos, no tuve que alinearme con los equipos operativos durante las ventanas disponibles para ejecutar mi propia extracción de datos sin afectar el rendimiento operativo.
Según la taxonomía de Data Mesh, los productos de datos creados sobre fuentes operativas se denominan productos de datos alineados con la fuente:
Los conjuntos de datos del dominio de origen representan fielmente los datos sin procesar en el momento de su creación y no están ajustados ni modelados para un consumidor en particular. Zhamak Dehghani
Los productos de datos alineados con las fuentes tienen como objetivo representar fuentes operativas dentro de una plataforma de datos compartida en una relación uno a uno con entidades operativas y no deben contener ninguna lógica comercial que pueda alterar cualquiera de sus propiedades.
Propiedad
En una implementación de Data Mesh, estos productos de datos deben
estrictamente ser propiedad del dominio empresarial que genera los datos sin procesar. El propietario es responsable de la calidad, confiabilidad y accesibilidad de sus datos y los datos se tratan como un producto que puede ser utilizado por el mismo equipo y otros equipos de datos en otras partes de la organización.
Esta propiedad garantiza que el conocimiento del dominio esté cerca de los datos expuestos.. Esto es fundamental para permitir el rápido desarrollo de productos de datos analíticos, ya que cualquier aclaración que necesiten otros equipos de datos se puede manejar de forma rápida y eficaz.
Implementación
Siguiendo este enfoque, el dominio de Ventas es responsable de publicar un producto de datos ‘sales_orders’ y ponerlo a disposición en un catálogo de datos compartido.
El canal de datos encargado de mantener el producto de datos podría definirse así:
Extracción de datos
El primer paso para crear productos de datos alineados con las fuentes es extraer los datos que queremos exponer de fuentes operativas. Hay un montón de herramientas de integración de datos que ofrecen una interfaz de usuario para simplificar la ingesta. Los equipos de datos pueden crear un trabajo allí para extraer datos sin procesar de fuentes operativas utilizando conexiones JDBC o API. Para evitar desperdiciar trabajo computacional, y siempre que sea posible, solo se deben agregar incrementalmente al producto de datos los datos sin procesar actualizados desde la última extracción.
Limpieza de datos
Ahora que hemos obtenido los datos deseados, el siguiente paso implica cierta curación, para que los consumidores no tengan que lidiar con las inconsistencias existentes en las fuentes reales. Aunque no se debe implementar ninguna lógica empresarial al crear productos de datos alineados con el origen, se permite la limpieza y estandarización básicas.
-- Example of property standardisation in a sql query used to extract data
case
when lower(SalesDocumentCategory) = 'invoice' then 'Invoice'
when lower(SalesDocumentCategory) = 'invoicing' then 'Invoice'
else SalesDocumentCategory
end as SALES_DOCUMENT_CATEGORY
Actualización de datos
Una vez que los datos operativos extraídos están preparados para su consumo, el conjunto de datos internos del producto de datos se actualiza incrementalmente con la última instantánea.
Uno de los requisitos para un producto de datos es ser interoperable. Esto significa que necesitamos exponer identificadores globales para que nuestro producto de datos pueda usarse universalmente en otros dominios.
Actualización de metadatos
Los productos de datos deben ser comprensible. Los productores deben incorporar metadatos significativos para las entidades y propiedades contenidas. Estos metadatos deben cubrir estos aspectos para cada propiedad:
- Descripción del negocio: Qué representa cada propiedad para el negocio. Por ejemplo, “Categoría comercial para el pedido de venta”.
- Sistema fuente: Establecer un mapeo con la propiedad original en el dominio operativo. Por ejemplo, “Fuente original: ERP | Tabla MARA-MTART Propiedad BIC/MARACAT”.
- Características de los datos: características específicas de los datos, como enumeraciones y opciones. Por ejemplo, “Es una enumeración con estas opciones: Factura, Pago, Reclamo”.
Los productos de datos también deben ser descubrible. Los productores deben publicarlos en un catálogo de datos compartido e indicar cómo se consumirán los datos definiendo los activos del puerto de salida que sirven como interfaces a las que se exponen los datos.
Y los productos de datos deben ser observable. Los productores deben implementar un conjunto de monitores que se puedan mostrar dentro del catálogo. Cuando un consumidor potencial descubre un producto de datos en el catálogo, puede comprender rápidamente el estado de los datos contenidos.
Ahora, nuevamente, imagine ser un ingeniero de datos encargado de identificar los productos más vendidos dentro de su empresa. Pero esta vez, imagine que tiene acceso a un catálogo de datos que ofrece productos de datos que representan la verdad de cada dominio que da forma al negocio. Simplemente ingresa “pedidos” en el catálogo de productos de datos y busca la entrada publicada por el equipo de datos de ventas. Y, de un vistazo, podrás evaluar la calidad y actualidad de los datos y leer una descripción detallada de su contenido.
Esta experiencia mejorada elimina las incertidumbres del descubrimiento tradicional, lo que le permite comenzar a trabajar con los datos de inmediato. Pero es más, sabrás quién es el responsable de los datos en caso de que necesites más información. Y siempre que haya un problema con el producto de datos de pedidos de venta, recibirás una notificación para que puedas tomar medidas con antelación.
Hemos identificado varios beneficios de habilitar datos operativos a través de productos de datos alineados con las fuentes, especialmente cuando son propiedad de productores de datos:
- Accesibilidad de datos operativos seleccionados: En las grandes organizaciones, los productos de datos alineados con las fuentes representan un puente entre los planos operativo y analítico.
- Reducción de colisiones con trabajo operativo.: Los accesos a los sistemas operativos están aislados dentro de los canales de productos de datos alineados con las fuentes.
- fuente de verdad: Un catálogo de datos común con una lista de objetos comerciales operativos seleccionados que reduce la duplicación y las inconsistencias en toda la organización.
- Borrar la propiedad de los datos: Los productos de datos alineados con las fuentes deben propiedad del dominio que genera los datos operativos para garantizar el conocimiento del dominio está cerca de los datos expuestos.
Según mi propia experiencia, este enfoque funciona excepcionalmente bien en escenarios en los que las grandes organizaciones luchan con inconsistencias de datos en diferentes dominios y fricciones al crear sus propios análisis sobre datos operativos. Data Mesh alienta a cada dominio a construir la ‘fuente de verdad’ para las entidades centrales que generan y ponerlos a disposición en un catálogo compartido que permita a otros equipos acceder a ellos y crear métricas consistentes en toda la organización. Esto permite a los equipos de datos analíticos acelerar su trabajo para generar análisis que generen valor comercial real.
https://www.oreilly.com/library/view/data-mesh/9781492092384/
Gracias a mis colegas de Thoughtworks Arne (¡dos veces!), Pablo, Ayush y Samvardhan por tomarse el tiempo de revisar las primeras versiones de este artículo.