Calidad del dato: a backend approach

Al realizar productos de datos es muy importante medir correctamente la calidad de los datos que se utilizan. Todo el potencial que puede tener un producto de datos queda reducido a lo buenos o malos que sean los datos de origen o los que se generen de manera intermedia. En este post se aborda la cuestión de la calidad del dato desde el punto de vista de backend, como también hemos hecho con el punto de vista de frontend.

A la hora de evaluar la calidad de los datos en un proyecto hay dos bloques claros a tener en cuenta: los inputs y los outputs. Dado el enfoque transversal que tenemos en Keepler, el input de datos es común tanto para la aproximación más de visualización como para la aproximación más de desarrollo. Esto se debe a que el enfoque tiene que ser conjunto, tanto pensando en el análisis exploratorio de datos de cara a la generación de valor más funcional, como planteando un enfoque de completitud y adecuación del modelo de datos.

Fuente de datos

Centraremos la atención en el análisis de las fuentes de datos desde un punto de vista más de procesamiento. En este sentido, sin hacer un análisis funcional profundo, hay múltiples parámetros a revisar para evaluar la calidad de una fuente de datos y corregir, en la medida de lo posible, los errores que se detecten.

Completitud

Al hablar de completitud nos referimos a que los datos sean completos en todas sus observaciones. Es decir, que esté presente la información mínima para que la observación sea coherente y se pueda utilizar. Por ejemplo, en la siguiente tabla se puede ver un listado de elementos a comprar, con su precio unitario. Rápidamente se puede identificar que para las manzanas no tenemos la observación completa puesto que no disponemos del tipo de producto que es.

Aún así, se dan muchos casos en que la completitud tiene una dependencia fuerte con la funcionalidad que se desea extraer de los datos. Por ejemplo, si para este mismo ejemplo la intención fuese evaluar precios medios en el tiempo para cada elemento, la ausencia del tipo no supondría un problema. Debido a esto, la fase de análisis exploratorio más funcional va muy ligado al análisis de formatos.

Coherencia de tipos

Otro problema muy común de formato al tratar con fuentes de datos variadas es la coherencia de los tipos. Este problema se da generalmente en fuentes de datos que agregan información de varios departamentos. Se puede producir que en un mismo campo algunas observaciones sean de un tipo, mientras que otras sean de otro tipo. En estos casos se debe convertir a un tipo común, bien transformando el tipo simplemente, o mediante alguna regla de traducción si funcionalmente tienen diferencias.

Siguiendo con el ejemplo de productos y precios, se puede ver que los precios en general son números decimales (con precio en euros por kilo), salvo el precio unitario del redondo de ternera, que es una cadena de texto puesto que especifica que el precio en lugar de estar en euros por kilo está en libras por kilo.

Estos casos requieren particular atención porque normalmente llevan asociados un componente funcional a la hora de definir el tipo. Es decir, el problema no solo es que el tipo de dato es en formato diferente, si no que conceptualmente es muy probable que no signifiquen lo mismo.

Ingesta y documentación de las fuentes de datos

Además de un análisis exploratorio sobre los datos hay otros parámetros importantes a la hora de validar la calidad de las fuentes de datos, como pueden ser la calidad en la ingesta de las fuentes o la documentación de las mismas.

Un parámetro importante al medir la calidad de las fuentes, y que en muchas ocasiones pasa desapercibido, es la calidad de la ingesta. Reduce mucho la calidad de una fuente de datos el hecho de que la ingesta no sea correcta y puede derivar en problemas tanto con los datos de origen, por ejemplo ausencia o incorrección en las observaciones, como en problemas con el proceso de generación del modelo final, por ejemplo con ausencias que rompan el proceso. Una buena ingesta debería tener siempre la misma periodicidad (por ejemplo diaria), recibiendo datos con el mismo formato y esquema, del mismo periodo, etc.

La documentación de las fuentes, por otro lado, es muy importante para evaluar correctamente todos los parámetros definidos anteriormente. Además, para el análisis funcional de las fuentes aporta mucha información de base que agiliza el proceso.

ETL y modelo de datos

Después de haber validado la calidad del origen de datos y tras el proceso de EDA y definición de funcionalidad de los que hablaremos próximamente en otro artículo, se puede implementar el proceso de extracción, transformación y carga de los datos (ETL) para generar el modelo de datos intermedio. Sobre este modelo de datos aún debe construirse la solución descriptiva o predictiva de nuestro producto de datos, pero es donde se puede entender que termina el trabajo puro de “backend”.

A la hora de definir el enfoque de desarrollo de la ETL se debe tener en cuenta que sea un enfoque relativamente sencillo de probar y validar. Al igual que se mide la calidad de las fuentes de datos, debemos asegurar que la calidad del modelo intermedio que se genere es la correcta. Sin esta validación, podemos estar introduciendo incorrecciones o sesgos a nuestra solución que no se detecten hasta que no se haya desarrollado la solución completa y se validen los datos finales. Una máxima que conviene tener en cuenta en estos casos es “garbage in, garbage out”. Es decir, si los datos de los que se parte (iniciales o intermedios) no tienen la calidad correcta, el resultado no va a ser aceptable.

En este sentido, sobre el proceso de transformación se deben realizar algunos tipos de validaciones comunes con otros procesos de desarrollo generales. A la hora de realizar estas pruebas es importante realizarlas con la misma volumetría y tipos de datos que se usarán en el proceso final. Usar una volumetría similar es particularmente importante ya que puede impactar en que la ETL no sea capaz de generar el modelo intermedio, bien por tiempo (que tarde mucho) o bien por potencia (se requiere demasiada capacidad de máquinas para ejecutarlo).

También es muy interesante que el proceso de diseño de toda la batería de pruebas sea un proceso conjunto entre todos los implicados (tanto personas más de “backend” como personas más de “analítica”). Esto ayuda a que las pruebas sean lo más completas posibles y que se aborden todos los enfoques del proyecto.

Pruebas sobre los procesos

Las pruebas mínimas que se deben realizar sobre el proceso de transformación son pruebas “unitarias” sobre cada proceso. Esto quiere decir que se realicen pruebas en las que se compruebe que el funcionamiento del proceso es el esperado. Se simula la entrada de datos en base a las fuentes de datos de ese proceso y se simula la salida esperada para esa entrada dada. Estas pruebas deben ser capaces de evaluar cada uno de los procesos de transformación que tenga nuestra ETL. Una buena norma es que, como mínimo, se pruebe cada proceso que genere una tabla o entidad diferente.

Pruebas de regresión

También es conveniente desarrollar algunas pruebas sobre todos los procesos que garanticen que si se realizan cambios en los diferentes procesos no afecta al resultado final de todo el modelo intermedio. Este tipo de pruebas son particularmente importantes cuando los resultados de algunos procesos hacen de entrada para otros procesos. En estos casos, pequeños cambios de comportamiento en el resultado del primer proceso pueden tener un gran impacto en el resultado final.

Pruebas de integración

Además, en caso de que se tengan diferentes procesos relacionados entre sí también conviene que se realicen pruebas que aseguren la correcta integración de los procesos. Para estos casos, es interesante incluso utilizar las mismas entradas y salidas de datos, de forma que se pueda detectar rápidamente que los cambios en algún proceso impactan en el resto.

Pruebas funcionales

Por último, es conveniente realizar algún tipo de pruebas más “funcionales” en colaboración con los compañeros de analítica para validar que los resultados cuadran con lo esperado y que no hay ningún comportamiento inesperado.

—

Muchos proyectos fracasan debido a una mala gestión de esta fase. En muchas ocasiones se resta importancia a la calidad del dato ya que este análisis y validación es costoso en tiempo y esfuerzo. Este esfuerzo extra no es atractivo en muchas ocasiones, pero es esencial para evitar impactos posteriores, en muchas ocasiones más costosos para el producto.

Continuar con el desarrollo de un proyecto en el que no se ha analizado correctamente la calidad de los datos deriva en que, como mínimo, haya errores conceptuales en la solución desarrollada. Esto puede reflejarse en que haya cálculos (tanto descriptivos como predictivos) que no tengan sentido, y se tomen decisiones erróneas en base a ellos; o directamente en que el producto final desarrollado quede inservible o se alargue su desarrollo en el tiempo de forma indefinida. Por todos estos motivos disminuir el análisis de calidad del dato para reducir costes tiene más contraindicaciones que beneficios.

Imagen: unsplash | rawpixel