Ser QA en un proyecto de Ingesta de Big Data.

Después de más de un año y medio trabajando como QA en un proyecto de Ingesta de datos, quiero mostraros qué conclusiones he sacado en este post.

Para poneros en contexto, este proyecto consistía en descargar los datos desde los diferentes orígenes, modelar los esquemas de datos, transformar los datos usando Spark y Scala y cargar estos datos procesados en un Data Lake que utilizaba HDFS de Hadoop como sistema de directorios. Después, una vez que se traten estos datos, se utilizarán por los Data Scientists.

Siempre he trabajado en proyectos Web, normalmente con un back-end y un front-end, ya sea con microservicios o sin ellos. Por eso, cuando tuve la oportunidad de participar en este proyecto de Ingesta de datos estaba un poco perdido (para qué nos vamos a engañar). Era la primera vez que trabajaba en un proyecto de Big Data, pero al ver que las transformaciones de datos que se realizaban eran Software implementado por el equipo de desarrollo, teníamos que aplicar todas las buenas prácticas que garantizan la Calidad de Software.

Entre mis investigaciones y las demandas del Product Owner descubrí que casi todo hacía referencia a la Calidad del Dato. Este factor era determinante para las necesidades de negocio, ya que los Data Scientists necesitan sí o sí que los datos sean correctos y explotables.

Una vez que se estaban ingestando datos de forma masiva empezaba a preocupar el rendimiento de los desarrollos de software, ya que por la noche miles de procesos movían una gran variedad de volúmenes de datos, por lo que necesitábamos realizar Pruebas de Rendimiento de nuestras transformaciones. Con estas pruebas ajustábamos el número de peticiones y el volumen del fichero en función de su tamaño.

A continuación os explicaré cómo tratamos estos tres aspectos de Calidad:

Calidad de Software

La Calidad de Software en este proyecto no deja de ser igual que la que se aplica a cualquier desarrollo software. Al final es un desarrollo utilizando Scala y Spark, por lo que es de obligado cumplimiento realizar Test Unitarios, pasar el análisis estático de código y validar funcionalmente el desarrollo. Ahora nos adentraremos en el proceso.

A la hora de desarrollar el código utilizamos BDD (Behavior Driven Development). En esta práctica se definen los criterios de aceptación que surgen de las historias de usuario definidas por el cliente. Estos criterios de aceptación se basan en unos escenarios escritos con formato Dado..., Cuando..., Entonces..., de esta manera tenemos un lenguaje entendible tanto por negocio como por el equipo de desarrollo.

Como ya he comentado, toda la plataforma nos venía dada por el cliente, por lo que la elección del flujo de desarrollo y la Integración Continua ya estaba marcada antes de que empezara el proyecto.

El flujo de desarrollo que utilizamos es Git Flow. Este flujo de trabajo está basado en el modelo de ramas de Git en el que se crean dos ramas principales: master y develop.

La rama master es la que va a recoger el código que se sube a producción y la rama develop, en la que se van a mergear las nuevas funcionalidades que albergan las ramas de feature a través de un Merge Request.

Este flujo cuenta con tres ramas de soporte: feature, release y hotfix. En las ramas de feature desarrollaremos las nuevas funcionalidades que terminarán integradas en la rama develop. La ramas de release nos van a permitir preparar el código para la subida a producción, y utilizaremos las ramas de hotfix para arreglar cualquier bug que se produzca en la versión productiva.

Cada vez que queramos integrar una nueva funcionalidad en la rama develop solicitamos un Merge Request. Esto desencadena una ejecución de la Integración Continua en la cual pasamos las etapas de build y de test. En la fase de test, siempre lanzamos todos los test unitarios y después analizamos el código con Sonar, que siempre tiene activas las siguientes Quality Gates:

Cuando aceptamos el Merge Request e integramos el código en Develop, se desencadena otra ejecución en la que, además de pasar la fase de build y test, se pasa la fase de deploy del artefacto de SNAPSHOT y los test de aceptación.

Calidad del dato

La calidad del dato es la que nos permite comprobar que los datos tengan calidad, y se marca con 6 factores:

• Disponibilidad
• Completitud
• Validez
• Consistencia
• Integridad
• Precisión

Disponibilidad

Los datos tienen que estar disponibles en la fecha y hora establecida para que se puedan procesar sin problemas.

En nuestro caso, los datos se procesan desde las 6 de la tarde hasta las 8 de la mañana del día siguiente, que es cuando los Data Scientists empiezan a explotar los datos. Por tanto, el campo que indica la fecha de procesamiento tiene que ser una fecha anterior a las 8 de la mañana del día siguiente.

Completitud

Los datos tienen que estar completos cuando se están ingestando en el data lake, por lo que tenemos que asegurarnos de que no se están perdiendo durante los procesos de transformación. Es importante que el número de registros del fichero de origen y el fichero de destino sean los mismos.

Validez

La validez de los datos es un aspecto fundamental a la hora de ingestar los datos. Siempre tenemos que chequear que los datos más importantes para el negocio sean firmes y exactos.

Los campos que sean clave nunca se deben ingestar vacíos o nulos. De la misma forma que si algún campo relevante tiene que cumplir un formato específico, tenemos que asegurarnos de que se cumpla.

Consistencia

Los datos tienen que ser consistentes para que puedan ser útiles y explotables por los científicos de datos. Los datos que están presentes en diferentes tablas deben de ser iguales, porque si no existe consistencia entre ellos, cualquier explotación que se realice utilizando estos datos va a producir resultados diferentes.

Integridad

Los datos que acabamos de ingestar se tienen que integrar con otros datos de forma correcta. Es de vital importancia que, si existen ciertas reglas entre ellos, se cumplan.

Por ejemplo, si un dato es el resultado de la multiplicación de otros dos es necesario comprobar que la integridad de estos se está cumpliendo.

Precisión

Los datos que se ingestan tienen que ser precisos, y cuando hablamos de grandes cantidades de datos, es muy importante tener controlada su tendencia de crecimiento. Si normalmente se están ingestando todos los días 10 TB de datos y un día se ingestan 20 TB, tenemos que tener detectado ese crecimiento anómalo.

También es importante que se controle la precisión del dato a nivel individual para verificar que los datos ofrecen una información fiable.

Pruebas de Rendimiento

Las pruebas de rendimiento son muy vitales en el proceso de ingesta. Cuando estamos ingestando y transformando los datos, el rendimiento depende de muchos factores: volumen del fichero, número de columnas, el número de particiones que se han generado e incluso del volumen de cada partición. Por lo que dar una respuesta universal es prácticamente imposible y adaptar todos estos factores para cada ingesta es muy costoso.

En nuestro caso, para poder abordar este tipo de pruebas necesitamos fijar ciertos valores ya que, si intentamos fijar todas las variables para todos los escenarios posibles, seguiríamos haciendo pruebas a día de hoy. Las variables que fijamos fueron el volumen y el número de columnas.

Establecimos estas variables eligiendo el volumen y el número de columnas que más se repetía entre todas las ingestas, y a continuación ya pudimos ajustar el número de particiones y su tamaño para dar el mejor particionado al máximo número de ingestas posibles.

En aquellos casos críticos en los que el rendimiento no resultaba eficiente, realizamos una solución más a medida. Detectamos procesos que a nivel de volumetría distaban enormemente de la media que solíamos ingestar, y para ellos en concreto realizamos pruebas de rendimiento que permitían reajustar los valores de nuestras variables e incluso refactorizar el proceso de la ingesta.

Conclusiones

La tecnología Big Data es muy importante para los grandes negocios y por eso está en constante evolución. Gracias al gran equipo que hemos formado en Paradigma se pudieron aplicar todas las medidas de Calidad, garantizando unos datos correctos, consistentes y en fecha, que permitían a nuestro cliente explotar los datos con total confianza.

Ha sido una experiencia muy enriquecedora y, para todos aquellos que os sintáis un poco perdidos acerca de cómo aplicar QA en Big Data, espero que os haya servido mi experiencia.