Mucho se ha dicho y escrito acerca de la importancia cada vez más crítica de los datos en las organizaciones, el escenario hace algunos años nos mostraba que los proyectos de datos, en general avocados a la construcción de Data Warehouses, eran tratados como cuestiones secundarias y cuyo máximo valor final era alimentar una serie de reportes que, en el mejor de los casos, daban soporte a la toma de decisiones de alguno de los niveles gerenciales.
La realidad es que, si existía algún problema con los datos en esos Data Warehouses, ya sea por mala calidad, procesos que fallaban o simplemente por una mala interpretación del negocio, las consecuencias no eran tan terribles. Seguro existían usuarios enojados 😠 tratando de obtener respuestas, pero no se veía afectado ningún proceso crítico de la organización.
De un tiempo a esta parte, esto cambió en forma drástica y hoy existe un consenso de que los datos y todo lo que se construye alrededor de ellos pasaron a ser activos de las organizaciones y gran parte de estos productos forman parte de la operatoria misma de las empresas y en muchas ocasiones es diferencial de valor con respecto a sus competidoras.
Esta criticidad vuelve imprescindible poner en práctica una serie de definiciones y acciones que en su conjunto conforman lo que se conoce como Gobierno del Dato.
Entre una de las tantas aristas que incluye Gobierno, hoy vamos a centrarnos en calidad de datos, vamos a hacer un doble click desde la perspectiva de la ingeniería de datos y cómo podemos hacer para que lo que sea que construyamos tenga la calidad necesaria para que el dato como activo alcance el valor potencial que puede tener.
A qué llamamos calidad del dato
En primer lugar, tenemos que definir qué es un dato en sí mismo, podríamos decir que es una representación simbólica (puede ser un número, pero también una descripción) de algo que ocurrió, por ejemplo, un evento como una tormenta o un hecho como una transacción bancaria, o de una entidad, como por ejemplo un automóvil.
En cada uno de los ejemplos mencionados podríamos encontrar infinidad de datos como cantidad de agua precipitada, monto transferido y color de la pintura. Los datos entonces describen una realidad observable 🧐 y medible, por ende, podemos usarlos para: comprender esa realidad describiéndola, tratando de anticipar lo que puede ocurrir en el futuro e inclusive intervenirla para tomar acciones en pos de un objetivo definido.
Luego de haber hecho una muy breve introducción, ahora si intentemos definir calidad: si un dato es una representación de una observación o medición, vamos a tener disponibles atributos cuantitativos y cualitativos asociados a estos hechos y entidades que mencionábamos, entonces para decir que un dato es de calidad, podemos definir algunas cuestiones que esperamos de él:
• Precisión.
• Consistencia.
• Completitud.
• Actualidad.
Tomemos de nuevo uno de los ejemplos anteriores para entender mejor a qué nos referimos con cada una, supongamos que queremos saber la magnitud de una tormenta 🌩 tomando en cuenta sólo la cantidad de agua precipitada:
• Precisión: no es lo mismo que lluevan 10 milímetros que 100, un simple 0 de más hace que la interpretación sea distinta.
• Completitud: si tenemos el dato de una sola tormenta, y no tenemos registro de otras históricas, será muy complicado determinar si el dato para la tormenta que queremos analizar. Otro aspecto muy importante, sobre todo cuando analizamos hechos o eventos es la temporalidad, si no contamos con el dato acerca del momento en que se realizó la medición, lo que tenemos no sirve para nada.
• Actualidad: según el objetivo que perseguimos, es evidente que no es lo mismo contar con el dato de precipitación al momento de la tormenta que tenerlo disponible una semana más tarde.
• Consistencia: de seguro el dato de precipitación lo obtenemos de un equipo que registra la medición en algún lado, si tenemos más de un equipo que utilizan distintas unidades de medida, si no contemplamos esto, vamos a tener que lidiar con un problema de calidad de datos en breve.
Entonces en una primera medida, si tenemos una serie de características deseables, podemos establecer que el grado de calidad de un dato está asociado a qué tan cerca está del ideal que esperamos de él para cada una de estas características, inclusive es posible ponderar alguna por sobre otra.
Por dónde empezar
Ya que les gustó el ejemplo de la tormenta, vamos a seguir utilizándolo, pero sumemos algunos condimentos: nuestra misión como ingenieros de datos es llevar a un Data Lake los datos de medición de una serie de estaciones meteorológicas para alimentar un proceso de alertas tempranas para prevenir situaciones de riesgo, todo esto a partir de un modelo de Machine Learning que se ejecutará cada 30 minutos.
Para simplificar el escenario, asumamos que tenemos dos estaciones y que los datos se obtienen de archivos de texto csv:
Estación A
Estación B
Tenemos los datos disponibles, si descartamos que el problema de negocio a resolver ya está claro ¿por dónde empezamos?
· Desarrollamos un script que descargue de forma automática los csv. NO ❌
· Creamos las tablas en el Data Lake donde se guardarán los datos. NO ❌
· Hablamos con el equipo de ciencia de datos para definir cómo debemos dejar los datos para el modelo. NO ❌
Lo primero y fundamental es realizar un análisis exploratorio de datos 🔎, es decir, en primer lugar, entender la realidad que están describiendo estos datos en forma general, por ejemplo, para nuestro caso asimilar entre otras cosas que: las mediciones son cada 10 minutos, que por meteorología nos vamos a referir a lluvia, humedad y temperatura.
Luego, tenemos que comprender la naturaleza propia de estos datos, si bien obviamente para el desarrollo vamos a trabajar con un muestreo, es importante que entendamos cómo se comportan en cuanto a variabilidad, faltantes, magnitudes, entre otras cosas. Esto podemos hacerlo con estadística básica y no es necesario que sea un análisis exhaustivo:
Con este simple gráfico ya intuimos que la temperatura en ambas estaciones se registra con unidades de medida diferentes, esto no es un problema en sí mismo, siempre y cuando se contemple que, para analizarlas en conjunto, uno de los dos datos necesita conversión.
Ahora observemos la distribución de los datos (al ser pocos no es significativo el análisis, pero sirve a modo de ejemplo), esto podemos hacerlo de forma visual con diagramas de cajas y bigotes:
Acá vemos en forma clara un valor anómalo en la estación A, hay que confirmar con el responsable de generar estos datos si es un dato real o quizás hubo un problema de que faltó el punto decimal y tenemos 1512 en vez de 15,12.
Quitando el valor anómalo, comparemos las estaciones. En este caso no se observan problemas de unidades, pero si, aunque no es tan sencillo de ver, que los valores de la estación B siempre se redondean a un número entero.
Prevenir es mejor que curar
Si bien podríamos hacer mucho más extensivo el análisis inicial de los datos, avancemos para ver qué otras acciones tomar para tener datos de calidad.
Habiendo entendido los datos con los que contamos, retomemos las cuestiones que definimos como características asociadas a la calidad de los datos y establezcamos algunas reglas de ejemplo para validar cada una de ellas:
• Precisión y consistencia: como estamos trabajando con variables numéricas que sabemos los valores normales que pueden tomar, para cada una se puede establecer un rango de validez.
Para Temperatura, asumimos que las estaciones no están en lugares con temperaturas extremas:
Estación A: -20 a 50 (recordemos que son ºC).
Estación B: -4 a 122 (recordemos que son ºF).
• Completitud: en este caso la regla es sencilla, no queremos datos nulos o NaN (Not a Number), el problema es que en los datos de ejemplo ya detectamos esto, por ende, la regla podría tener asociado un umbral de tolerancia, por ejemplo, un máximo de 10% de registros nulos sobre el total.
• Actualidad: aquí vamos a validar que en cada ejecución que hagamos tengamos datos recientes, entonces tiene sentido controlar el campo de fecha y hora para validar que el último registro corresponda con lo que se espera del productor de los datos, por ejemplo, si afirma que se actualizan cada 10 minutos, podemos chequear que la diferencia entre la fecha y hora de ejecución y la fecha hora máxima que obtengamos del archivo no sea mayor a ese valor de 10.
La integridad referencial
Compliquemos un poco más las cosas. Incorporemos una dimensión al análisis que no contemplamos hasta ahora, la geografía, es decir, dónde se están midiendo las variables meteorológicas.
Supongamos que tenemos el código postal de dónde está ubicada cada estación y además conseguimos un archivo con los datos geográficos asociados a cada código:
En esta instancia debemos validar dos cosas:
1. Que el código que tenemos para cada estación tenga su correspondiente en nuestro nuevo archivo, de lo contrario no vamos a poder obtener los datos geográficos.
2. Que no haya códigos duplicados en el archivo. Si bien es algo que no debería pasar, puede haber un error o alguna situación particular donde ocurra. Si no controlamos esto, lo que va a terminar pasando es que una misma estación tendrá dos ubicaciones diferentes. Esto según el análisis que hagamos puede llevarnos a incurrir en errores graves, por ejemplo, si queremos saber el total de precipitaciones para una determinada estación, si cruzamos contra códigos postales duplicados, vamos a obtener un valor incorrecto, 16 vs 8 en la imagen que sigue:
Calidad everywhere
Hagamos fast forward ⏩ y asumamos que ya se desarrollaron los pipelines necesarios para alimentar la tabla que estará utilizando el modelo de machine learning. Simplifiquemos en un escenario donde el modelo necesita el promedio por hora (cerrada, es decir no móvil) de temperatura y total de precipitaciones junto con las coordenadas de la estación:
Se preguntarán si aquí también debemos hacer controles de calidad, bueno la respuesta es sí, acá también 😉. Si bien el control de las fuentes de datos nos ahorra muchos dolores de cabeza, la realidad es que nuestros pipelines, transforman y enriquecen esos datos originales, por lo tanto, el resultado final, la tabla de promedios por hora en este caso, no está exenta de contener errores introducidos en el proceso de ingeniería de datos, algunos ejemplos:
1. Una de las estaciones registraba la temperatura en grados Fahrenheit, si realizamos mal la conversión, la tabla final contendrá datos erróneos.
2. El cálculo de las métricas puede estar mal hecho, ya sea por una cuestión técnica o funcional, para nuestro caso pareciera ser trivial, pero en la vida real puede ser algo mucho más complejo.
Si seguimos entonces con estos ejemplos, en este punto podemos definir dos reglas:
1. Chequear que la columna de temperatura promedio esté dentro de los mismos rangos que definimos cuando validamos la fuente de datos.
2. Para el caso de las precipitaciones totales, no podemos usar el mismo rango definido para la fuente por cuestiones obvias, ahora estamos sumando las mediciones, de todos modos, se puede establecer un rango más amplio o si queremos algo más preciso se podría comparar el valor de la tabla final contra la suma de los valores individuales de la tabla origen.
Cuánto es suficiente
Ya analizamos los datos, establecimos reglas de calidad tanto para el origen de datos como para las tablas que se generaron en el proceso de ingeniería, y ahora surge una pregunta existencial: ¿cuántas reglas son suficientes?
Como habrán notado, la cantidad y elección de reglas que vimos es más bien arbitraria y bastante subjetiva, seguro a ustedes se les ocurrieron otras cosas para validar o inclusive les parezca que algo de lo que se definió no tenga mucho sentido.
Entre los dos extremos de no validar nada y validar absolutamente todo lo que se nos ocurra, es necesario encontrar un equilibrio, porque si bien la segunda opción suena tentadora, generaría varios problemas:
1. Siempre los recursos disponibles son escasos: primero las personas que van a estar desarrollando y estableciendo reglas, luego el tiempo. Cada regla adicional requiere tiempo de definición y prueba y por último, y no menos importante, la ejecución de cada regla implica recursos computacionales: a mayor cantidad de validaciones mayor tiempo de proceso (puede darse el caso de que validar tarde más que el proceso de transformación en sí) y mayor costo 💸 asociado.
2. Si hay demasiadas reglas, lo más probable es que nos encontremos con varias de ellas que van a fallar pero que van a terminar siendo ignoradas por diferentes cuestiones: incapacidad de poder lidiar con los problemas por falta de equipo, reglas que dejan de tener sentido por la naturaleza viva de los datos, validaciones no críticas que no necesitan corrección inmediata.
Consideraciones finales
Recién mencionábamos que establecer demasiadas reglas podría llevar a que muchas sean ignoradas, esto tiene que ver con una cuestión fundamental que no vimos hasta ahora y es cómo vamos a accionar 👩🔧sobre estas reglas.
Cómo hacer efectivo el proceso completo de calidad de datos tiene varias implicancias, sobre todo asociadas a lo cultural, como vimos en otras iniciativas de datos como Data Mesh, la primera barrera tiene que ver con procesos organizacionales y visión, no hay calidad de datos posibles sin un alineamiento de todas las partes implicadas. Estas son cuestiones que no deben faltar para que el intento de establecer calidad de datos no quede en la nada misma:
· Embeber el proceso de calidad dentro del proceso de desarrollo: si bien es posible, definir las reglas de calidad una vez que está todo el pipeline de datos desarrollado no es lo ideal, preocuparnos por la calidad de datos debe ser algo para considerar desde el inicio, inclusive deberían ser tareas obligatorias para todos los ingenieros de datos.
· Entender la criticidad de cada regla: no todos los problemas de calidad tienen el mismo impacto, es fundamental asociar un nivel de criticidad para cada uno y obviamente priorizar y comenzar por lo más crítico.
· Definir responsables.
a. Para los orígenes de datos, por ejemplo, en nuestro caso sería la empresa encargada de generar y disponibilizar los datos de las estaciones meteorológicas. En la vida real, donde consumimos datos de: sistemas transaccionales, ERPs, CRMs, hay equipos trabajando con estas herramientas que son los que entienden y generan estos datos. Si seguimos buenas prácticas de ingeniería de datos, estas personas habrán sido parte del desarrollo desde el momento inicial, inclusive las reglas que se definieron sobre las fuentes de datos deberían estar asociadas a definiciones de negocio establecidas por estos equipos.
b. Sobre las tablas generadas en el proceso de ingeniería, en este caso tiene sentido definir un equipo de soporte que pueda rastrear y solucionar los problemas que puedan darse.
· Identificar implicados: los problemas de calidad de datos deberían estar afectando a personas, equipos u otros procesos que dependen de estos para tomar decisiones, realizar alguna acción
· Tener un mecanismo de alertado ⚠: si tenemos definidos responsables e implicados, a cada uno de ellos debería llegarle un mensaje (email, Slack, lo que sea) donde esté claro el problema de calidad encontrado y la acción que se debe tomar, inclusive para un mismo incidente puede haber distintas acciones según el receptor.
· Establecer un proceso de revisión: es imposible que las reglas que se definieron una vez sean válidas para siempre, habrá reglas que dejen de tener sentido y otras nuevas necesarias. Es importante poner el foco en reglas que fallan todo el tiempo, pero nadie las arregla. No debemos tener miedo en eliminar reglas que solo meten ruido al proceso.
· Registrar los resultados de las validaciones: este punto es crucial para poder monitorear la calidad de los datos a lo largo del tiempo y ganar en Observabilidad.
Una última recomendación de implementación es la utilización de algún framework o herramienta que permita hacer todo esto de manera sistémica, si bien las soluciones hágalo usted mismo pueden ser útiles en un principio, en algún momento dejan de escalar.