Si hace un par de semanas pude participar en un Hands-on con Fivetran y DBT, la semana pasada he podido asistir a una sesión con Piethein Strengholt, actual CDO de Microsoft en Holanda, donde nos ha presentado su particular visión acerca de Data Contracts en arquitecturas de datos distribuidas.
Como ya he comentado en más de una ocasión, mi planteamiento actual en cuanto a arquitecturas de datos está muy alineado con frameworks distribuidos, donde el propietario del sistema fuente reclama el foco y colabora con el resto de actores del ecosistema empresarial para una gestión eficiente del ciclo de vida del dato. Es por eso que, me resulta interesante y esperanzador, comprobar que otros colegas muestran cierto alineamiento hacia esa posición que me gusta llamar: «descentralización comprometida«. Esta aproximación se fundamenta en dotar de un alto grado de autonomía a los sistemas fuente, lo que se traduce en la adquisición de nuevas competencias como, gestión de los glosarios de datos, clasificación de datos, control de la evolución del esquema de datos, optimización de los set de datos, aseguramiento de la calidad de los datos, validaciones de datos,… que se traducen en que permiten reducir la carga de trabajo de los tradicionales equipos de Ingenieros de Datos. Algo que optimiza el proceso de extracción e ingestión sobre manera. Como puedes observar estamos hablando de ELT en vez de ETL 😉
Pues tras esta breve puesta en situación, es aquí donde los Data Contracts se antojan imprescindibles para una correcta gestión del dato. Pero, ¿qué son los Data Contracts? Pues ni más ni menos que acuerdos de servicio de entrega de datos entre un productor y un consumidor. Para construir estos acuerdos es necesario tener una solución de datos que permita monitorizar los procesos, así como controlar la calidad del resultado obtenido en cada uno de los pasos y además, interactuar con el repositorio donde esas reglas vivan para poder establecer el cumplimiento o no del acuerdo. Como solución para plasmar esos acuerdos, DBT es una pieza clave.
Para quien no esté al tanto de cómo funciona DBT, simplemente dejaré una captura de pantalla donde se observa la interfaz de la aplicación y por otro lado, se puede ver un sencillo fichero yaml donde se han incluido un par de reglas sobre la Primary Key de las tablas que contienen ambos modelos de datos. Comentar que reglas existen multitud y que aquí definidas permiten asegurar la calidad de las transformaciones de datos que suceden entre las distintas capas de procesamiento. Personalmente, me pareció muy interesante y más aún si tan siquiera has visto a Great Expectations en funcionamiento.
Otro punto que me resultó interesante siempre y cuando no emplees el linaje de Unity Catalog en Databricks fue la capacidad de DBT de ofrecerte ese detalle. Sin duda una gran ayuda en la gestión de entidades corporativas de destino.
CONCLUSIÓN
Me encanta ver que el ecosistema de los Datos sigue acelerando el paso para hacer posible la incorporación de dato empresarial en el balance de las organizaciones y así finalmente romper ese gap que algunas organizaciones aún no han conseguido quebrar. Los datos son el nuevo petróleo, sin embargo hay muchas organizaciones donde el barril se está regalando. Ayudemos a poner pie en pared y difundamos buenas prácticas de gobierno y gestión del dato.
NOTA:
Hace unos meses escribí acerca del establecimiento de métricas de evaluación al hablar de los datos como producto, aquí. Viene al caso porque en muchas ocasiones, se habla del establecimiento de medidas como SLA o calidad,… asimilando el dato a cualquier otro producto industrial y justo, en la industria, una medida clave para comprender el rendimiento de tu producción es la OEE (Overall Equipment Effectiveness). Que es el resultado de multiplicar la Disponibilidad, por Rendimiento y la Calidad.
OEE = Disponibilidad (66%) x Rendimiento (50%) x Calidad (90%) = 0,297
Si quieres saber más, no dudes en suscribirte a mi blog o seguir al grupo de Meetup «Encuentros en la Tercera Fase». Gracias 🙂
Alb3rto Alonso 