Los equipos que desarrollan software suelen tener dependencias con otros equipos intercambiando datos a través de una API Rest o una cola de eventos. Existen varios mecanismos para compartir los datos que necesitan las aplicaciones para funcionar. Por otro lado, un Warehouse puede ser visto como la fuente de datos para la organización completa, ahí están los datos de todas las aplicaciones administradas por los equipos y es utilizado para crear reportes, dashboard, descubrir tendencias, etc. ¿Acaso no es tentador dejar de comunicarse con cada equipo de software, y pedir permisos para acceder a los datos que están en un sólo lugar?
Características de los datos en un Warehouse
Un Almacén de datos o Warehouse puede verse como una base de datos gigante. Son muy eficientes para hacer consultas y buscar información en miles de millones de filas en diferentes tablas, pero las actualizaciones de datos no son su mejor característica.
Una consulta simple puede tomar algunos segundos, eso ocurre porque el warehouse es creado para realizar consultas complejas que involucran muchos datos y levanta toda una infraestructura con sus servicios al momento de consultar datos. El warehouse está pensado en eficiencia para insertar los datos solo una vez y leerlos muchas veces.
Distintos roles e involucrados para los datos
Los equipos que desarrollan software administran bases de datos para sus aplicaciones y envían datos al warehouse, ellos se preocupan de la calidad y consistencia de los datos producidos.
Los analistas revisan y transforman los datos, hacen limpiezas, uniones de distintas tablas y consolidan los datos para obtener información útil en reportes y dashboards. Los insights revelan tendencias y métricas para entender el pasado de la compañía, las decisiones son basadas en datos. Los analistas también conocen el negocio, crean modelos o tablas según sus reglas, especializándose en distintas áreas como marketing, operaciones, finanzas, etc.
El equipo de Data Science extrae los datos y crean modelos, hacen predicciones u otras soluciones basados en los datos proporcionados. A ellos les interesan los datos tal como llegan desde la fuente, el aprendizaje profundo y otras técnicas de inteligencia artificial son sus caballos de batalla.
El equipo de Ingeniería de Datos es el encargado de proporcionar las herramientas para poder ingestar, transformar y visualizar los datos para los distintos roles que los utilizan. Los datos son actualizados y sincronizados desde las distintas fuentes usando herramientas que automatizan los procesos de extracción, governance, auditoría, catálogos y orquestación del ciclo de vida del dato.
¿Quién es el dueño del dato?
En el Warehouse, para crear un modelo o tabla es posible que intervengan diferentes roles, equipos y reglas. Algunos roles hacen limpieza de datos, aplican filtros y crean tablas intermedias. Hay diferentes equipos que pueden estar involucrados en la creación de una tabla final que puede contener lo que necesita alguna aplicación. Si hay un error en un dato ¿Quién es el responsable?
Para entender una tabla o modelo en un Warehouse primero tendríamos que revisar todas las transformaciones que se hicieron en sus datos, las diferentes tablas intermedias que enriquecen al modelo final, entender las reglas aplicadas y los usos. Los pasos para crear una tabla final es un desarrollo en capas parecido a un grafo.
Cuando hay errores si es que tienes mucha suerte, todavía están los equipos o personas que crearon el modelo/tabla final que buscas analizar. Mientras menos afortunado seas, te irás encontrando con reglas de negocio o transformaciones obsoletas que nadie entiende, o puede que el error venga del dato de origen porque una aplicación dejó de validar alguna columna de sus tablas. También pueden haber cambios inesperados en una tabla intermedia que está siendo utilizada por más de un reporte. A veces los equipos que desarrollan aplicaciones nunca visualizan lo lejos que llegará su dato producido.
¿Aceptas el riesgo y el dolor de usar datos del Warehouse para alimentar a tu aplicación?
Reverse ETL es un proceso válido, no siempre
No podemos satanizar extraer los datos enriquecidos, los procesos conocidos como Reverse ETL son útiles bajo las condiciones y acuerdos que tengan en la compañía. En esos casos es clave la comunicación entre los equipos que consumen una tabla y todos los involucrados en producir los datos y las transformaciones para generar el modelo final usado. Mientras haya menos intermediarios es mejor, no es mala idea tomar la responsabilidad del flujo completo de los datos tanto como sea posible. Algunas aplicaciones de catálogo de datos como Datahub ayudan a descubrir las dependencias, usos y responsabilidades.
Hay aplicaciones como Segment y otras que se configuran para tomar datos de una tabla del warehouse y dejarlos en una tabla relacional de una base de datos. No es extraño que los mismos que producen y envían los datos al warehouse, puedan enriquecerlos y pedirlos de vuelta.
Caso: Data Science
Hay casos donde equipos usan el warehouse como su base de datos. Data Science crea sus modelos con datos transformados usando similar o el mismo proceso proveído por la infraestructura para todos. A ellos les gustan las cantidades masivas de datos y mientras sean más cercanos al origen, mejor.
Puede ser por una incapacidad técnica o la presión para que avancen más rápido, ellos difícilmente van a construir una API para consultar sus datos producidos, tampoco van a enviar datos como eventos y menos mantener su propia base de datos.
Se que esto requiere recursos extras en personas, un equipo Data Science necesita de la ayuda de desarrolladores de software en los casos que tengan que proveer datos a otros equipos, en especial cuando es para uso en aplicaciones. Es importante mantener una comunicación directa entre los equipos que usan los datos y los que los producen (Data Science), así tendrán tiempos de respuesta razonables para consultas y problemas.
Si los equipos de software ya comenzaron a buscar datos del warehouse, el equipo de ingenieros de datos deben establecer procesos para obtenerlos con reglas claras y responsabilidades asumidas por los distintos roles.
La forma de utilizar el Warehouse más allá del análisis de datos, como para aplicaciones, es una decisión de la organización. Incluso pueden determinar que están prohibidos para aplicaciones u otros casos de uso. Establece una documentación con los procesos soportados, cuáles son las responsabilidades y trabajo requerido por cada parte, además de tickets para crear las solicitudes. La comunicación clara y directa es el mejor aliado.
No voy a juzgar ahora por qué pensaron que fue una buena idea usar el Warehouse como base de datos directa o indirecta. Es una obligación hacerse esta pregunta antes de pedir datos del warehouse para una funcionalidad planeada: ¿Por qué no obtener el dato directamente desde la aplicación/servicio que lo genera?. Puede que descubras otro problema organizacional.
El ser humano es como el agua, busca el camino más fácil