Conocer el linaje de los datos es muy importante desde el punto de vista de gobierno del dato para:
El linaje del dato se presenta de muchas formas y quizás una de las más conocidas se corresponde con el linaje técnico. Es decir, conocer, desde el punto de vista técnico, como se mueven los datos de un sitio a otro a través de los procesos que se ejecutan sobre ellos, bien sea de forma automática o manual.
Sin embargo, hay que tener en cuenta que, por mucho que se trate de linaje técnico, esta información tiene que ser de utilidad para el gobierno del dato. Así, para que la información del linaje sea valiosa, esta tiene que ser interpretable y, en la gran mayoría de ocasiones, una ristra de logs de actividad que escupe una máquina sirve más bien de poco. Es por ello que lo más común es que el linaje técnico haya que capturarlo, interpretarlo y traducirlo para que pueda servir de algo.
En este contexto, para poder obtener el linaje técnico de los procesos que mueven los datos de un sitio a otro podemos apoyarnos en varias técnicas:
Adicionalmente, dada la variabilidad de lenguajes, plataformas, tecnologías, etc, el espectro que nos encontramos se hace demasiado grande como para abarcarlo por completo. Es por eso que, cuando hablamos de linaje, normalmente hay que buscar compromisos y se suele aplicar la Ley de Pareto, sobre todo en algunos escenarios particulares.
Como ya hemos visto, no todas las tecnologías de procesamiento de datos nos facilitan las cosas a la hora de obtener el linaje interno de sus procesos y, entre todas estas, Spark es una de las que ocupa los primeros puestos en cuanto a complejidad.
Spark es una tecnología open-source de procesamiento distribuido que ofrece un mayor aprovechamiento de las posibilidades de los clústeres distribuidos de datos y, al ser un proyecto open-source, se pueden encontrar diferentes distribuciones ofrecidas por distintos proveedores de tecnología como, por ejemplo, Cloudera, AWS EMR, GCP DataProc o Databricks, la más famosa de ellas, la cual además se ofrece de forma nativa por Microsoft en su nube de Azure.
Una de las características más particulares de Spark reside en que no tiene almacenamiento propio, sino que usa la memoria de las máquinas que forman el clúster donde se ejecuta y es capaz de recuperar los datos desde distintos tipos de almacenamientos como, por ejemplo, HDFS, S3, Cloud Storage, Blob Storage, etc o también de sistemas de streaming como Kafka.
En este sentido, Spark distribuye, en periodo de ejecución, las tareas por los distintos nodos del clúster usando la memoria y los procesadores de las diferentes máquinas. Es por ello que, por su propia definición, se antoja complicado el pensar en obtener una traza completa de los procesos ejecutados y que mueven o transforman datos. Además, esto no es algo que se resuelva de forma completa y nativa en ninguna de las implementaciones actuales de Spark, pues todas ellas están pensadas y optimizadas para el procesamiento de los datos y no para el gobierno de estos.
Cuando hablamos de gobierno del dato y Spark aparece en la foto como tecnología involucrada, la gran mayoría de profesionales se llevan las manos a la cabeza o asumen un gap importante. Ciertamente, la activación de la captura de logs a bajo nivel nos puede proporcionar mucha información sobre los procesos, pero también penaliza el rendimiento, por tanto hay que buscar una solución de compromiso.
Como hemos visto, obtener la traza de los procesos de Spark no es tarea sencilla, principalmente por los siguientes motivos:
Sin embargo, gracias al enfoque y la implementación de Anjana Data, se puede conseguir una foto bastante fehaciente y con un nivel granular (nivel campo y funciones aplicadas) que ninguna otra solución en el mercado es capaz de ofrecer. ¿Cómo? No podemos contarlo todo pero sí que podemos dar unas pequeñas pinceladas 🙂
Básicamente lo que hace Anjana Data es aplicar una mezcla de las tres técnicas arriba mencionadas interceptando cada uno de los procesos justo en el momento previo a su ejecución.
Para la ejecución de los procesos, Spark hace un plan de ejecución (DAG) antes de dividir el proceso en tareas que son lanzadas en paralelo y este es el único momento en el que toda la información está disponible en un solo punto, justo antes de ser distribuido por todos los elementos encargados de su ejecución. Incluyendo un agente específico que sea invocado siempre en todas y cada una de las ejecuciones por defecto, toda esta información puede ser capturada y extraída con el nivel de detalle requerido. Además, todo esto se puede hacer de forma centralizada y no invasiva, sin necesidad de que los programadores tengan que incluir nada en sus procesos.
Por último, toda esta información es procesada e interpretada por una de las piezas de la arquitectura de Anjana Data para después servirla al CORE de la solución, donde se cruza con la información gobernada para poder generar así un linaje del dato de valor que se pone a disposición del usuario final.
Anjana Data puede hacer esto y muchas cosas más… ¿Quieres descubrirlo?
¡Solicita una demo y te lo contamos!