Automatizar la supervisión de la calidad de los datos

Capítulo 1. El imperativo de la calidad de los datos El imperativo de la calidad de los datos

Este trabajo se ha traducido utilizando IA. Agradecemos tus opiniones y comentarios: [e-mail]

En marzo de 2022, Equifax estaba migrando sus datos de los sistemas locales a una nueva infraestructura en la nube, un proceso notoriamente complicado. En algún momento, se introdujo un error que afectaba al cálculo de las puntuaciones crediticias. Aproximadamente el 12% de todos los datos de puntuación crediticia de la empresa se vieron afectados, y cientos de miles de personas acabaron con puntuaciones de 25 puntos o más. Sin ser conscientes del error, las instituciones crediticias que consumían los datos de Equifax alteraron los tipos que ofrecían a los clientes e incluso rechazaron solicitudes de préstamos e hipotecas que deberían haber sido aprobadas.

Por desgracia, éste no es el único lío de calidad de datos que ha sido noticia recientemente:

• En 2020, un error de datos provocó la pérdida de casi 16.000 resultados positivos de la prueba COVID-19 en el Reino Unido, lo que posiblemente hizo que no se dijera a 50.000 personas que se autoaislen.

• Las llamadas "tarifas por error" de las compañías aéreas, que a veces tienen descuentos involuntarios de más del 90%, han obligado a las compañías aéreas a perder dinero o a dañar su reputación al no respetar estos "precios por error".

• Facebook proporcionó un conjunto de datos a un grupo de científicos sociales que dejaba fuera a la mitad de sus usuarios estadounidenses, lo que afectaba a las conclusiones de los trabajos académicos que estudian el impacto de los medios sociales en las elecciones y la democracia.

• La empresa de videojuegos Unity perdió 110 millones de dólares en su sistema de publicidad de IA tras ingerir datos de entrenamiento erróneos de un tercero.

Estas noticias muestran el impacto que pueden tenerlos problemas de calidad de datos especialmente graves , peroeso no es todo. La gran mayoría de los problemas de calidad de datos nunca se detectan y están destruyendo sigilosamente el valor de las empresas mientras lees esto. De los que se detectan, pocos se hacen públicos.

He aquí dos anécdotas que te resultarán familiares si alguna vez has trabajado en un equipo de datos:

• Un día, uno de los cuadros de mando de producto de una gran empresa tecnológica indicó una caída repentina en los resultados de la encuesta de puntuación neta del promotor (NPS). Lo más probable es que esto significara que los clientes estaban frustrados por un cambio en el producto, lo que hizo saltar las alarmas en toda la organización. La alta dirección se implicó y se creó un grupo de trabajo. Ingenieros y analistas evaluaron todos los cambios de código del mes anterior y examinaron todos los datos de los usuarios para averiguar qué podía haber causado la caída en picado de las puntuaciones.

  La causa raíz fue finalmente descubierta por el científico de datos que analizaba los datos de NPS. En su análisis, descubrieron que cualquier puntuación de 9 ó 10 (sobre 10) había dejado de aparecer por completo en los últimos resultados. Esto condujo a una investigación del equipo de ingeniería, que descubrió que la encuesta de NPS estaba incrustada en un iframe que había recortado los valores de respuesta de NPS más altos, de modoque era físicamente (¿o, deberíamos decir, digitalmente?) imposible que un cliente eligiera 9 o 10.

• Una empresa de viajes compartidos había creado un modelo ML para detectar nuevas cuentas de pasajeros potencialmente fraudulentas y bloquearlas automáticamente. Su modelo se basaba en datos de tarjetas de crédito de terceros. Entre otras cosas, el modelo aprendió que cuando los datos del tercero eran NULOS, la probabilidad de fraude era mayor; era una señal de que la persona se estaba registrando con una tarjeta que podía no ser legítima.

  Todo funcionaba bien hasta que un día el tercero tuvo un problema de calidad de datos que le hizo enviar datos NULOS con mucha más frecuencia que antes. Nadie se dio cuenta del error, y la empresa siguió utilizando el modelo ML para hacer predicciones de fraude. Esto provocó que a muchos usuarios nuevos se les denegara la posibilidad de darse de alta en los servicios de la empresa, ya que se les clasificaba erróneamente como cuentas fraudulentas.

Apostamos a que todos los lectores que trabajan con datos han tenido experiencias similares. Cuando los datos se hacen bien, desbloquean un valor increíble. Pero cuando no tienes ninguna garantía de calidad sobre tus datos, es como intentar llevar un restaurante con ingredientes que pueden estar contaminados o no. Puede que tengas suerte y nadie enferme, pero en algunos casos, tus clientes y tu negocio pueden sufrir, y puedes apostar a que no volverán a mirar tu comida de la misma manera. Un estudio reveló que el 91% de los responsables de la toma de decisiones de TI piensan que necesitan mejorar la calidad de los datos en su empresa; el 77% afirmó que carece de confianza en los datos empresariales de su organización.

¿Hay alguna forma de recuperar la confianza en los datos? ¿Y puedes garantizar que los tipos de problemas que acabamos de mencionar se detecten inmediatamente y se resuelvan con rapidez, antes de que nadie más se vea afectado, incluso (y especialmente) cuando trabajas con grandes volúmenes de datos complejos?

Creemos que la respuesta es sí, y la solución es automatizar el monitoreo de la calidad de tus datos con aprendizaje automático. Este libro te ayudará a descubrir el poder del monitoreo automatizado de la calidad de los datos. Aprenderás a implantar una plataforma que te ayudará a garantizar datos fiables y de alta calidad para tu empresa.

Los datos de alta calidad son el nuevo oro

Parece que fue ayer cuando las empresas luchaban por sacar datos de bases de datos aisladas. Apache Hadoop hizo posible realizar consultas más avanzadas en conjuntos de datos grandes y complejos (si sabías lo que hacías). A pesar de ello, en el pasado reciente, los datos se limitaban generalmente a un pequeño conjunto de sistemas transaccionales: un "jardín amurallado" de recursos críticos, estrictamente controlados, con acceso limitado.

En cuestión de años, los almacenes de datos en la nube y las herramientas de transformación de datos han transformado rápidamente nuestra forma de trabajar con los datos. Ahora, cada trozo de información que toca una organización se registra y almacena. Cualquier responsable de la toma de decisiones en la organización puede (a) consultar un panel interactivo o un informe para responder a preguntas con datos o (b) consultar directamente los datos por sí mismo. Los sistemas de aprendizaje automático, basados en datos, están informando o automatizando las decisiones empresariales y potenciando nuevos productos.

"Creemos firmemente que los próximos 10 años serán la década de los datos", escribió la empresa de inversión de Silicon Valley Andreessen Horowitz en 2022. A los medios de comunicación les encanta llamar a los datos tanto el nuevo petróleo como el nuevo oro. Creemos que debería haber una advertencia importante sobre este tipo de afirmaciones: sólo son correctas si los propios datos son de alta calidad. Los datos malos son peores que no tener datos.

Para ver por qué, examinemos algunas de las tendencias que se dan en torno a los datos y por qué la calidad es el factor decisivo en cada caso.

Las empresas impulsadas por los datos son las disruptoras actuales

La historia común es que las empresas de más rápido crecimiento y éxito hoy en día son empresas de software. Pero si las examinamos más de cerca, en realidad son empresas de datos.

Piensa en Amazon. No sólo construyeron la mayor plataforma de venta al por menor del mundo por tener un talento de ingeniería de software de talla mundial. Lo hicieron descubriendo cómo aprovechar los datos para obtener recomendaciones personalizadas, precios en tiempo real y una logística optimizada. Por poner un ejemplo de otro sector, Capital One es uno de los primeros bancos estadounidenses en trasladar sus datos de los sistemas locales a la nube. Han conseguido diferenciarse y acelerar su crecimiento utilizando los datos para personalizar el marketing y tomar decisiones de suscripción más inteligentes.

Ya sea en los servicios financieros, el comercio, los medios digitales o la sanidad, la intersección de datos y software es la frontera competitiva. Sin embargo, las empresas no pueden tomar buenas decisiones, y mucho menos revolucionar un sector, si trabajan con datos de baja calidad en los que sus propios empleados tienen dificultades para confiar. Sería un error invertir en nuevos proyectos de ciencia de datos, aprendizaje automático e IA generativa cuando tus cimientos de calidad de datos están podridos.

El análisis de datos se democratiza

Deseosas de seguir el ritmo de los disruptores -o de convertirse en uno de ellos-, las empresas piden a todos los equipos que se orienten más por los datos. Han integrado expertos en análisis en unidades funcionales (marketing, crecimiento, finanzas, equipos de producto, etc.) para impulsar usos más sofisticados de los datos en la toma de decisiones: ¿Podemos obtener las estadísticas de la actividad de navegación y compra anterior de nuestros clientes para escribir correos electrónicos más personalizados? ¿Podemos ver cómo adoptan nuestros usuarios avanzados la última función para ver si nuestro lanzamiento ha tenido éxito?

Ahora existe una plétora de herramientas que permiten a los analistas -o realmente a cualquier persona de un equipo interfuncional- buscar por sí mismos las respuestas a preguntas relacionadas con los datos sin escribir ningún código. En cuestión de segundos, pueden crear un cuadro de mandos o un informe que hasta hace poco habría llevado un mes a un ingeniero. Para apoyar estas necesidades analíticas, los datos ya no los mantiene un pequeño equipo centralizado ni están disponibles como una tabla de hechos consolidada para toda la empresa. En su lugar, los datos están dispersos y son gestionados por un grupo más amplio de personas que se sientan más cerca de las líneas de negocio.

Sin datos de alta calidad, lo que hemos visto es que la democratización se convierte en una pesadilla para los equipos de ingeniería de datos. Están abrumados con una acumulación de preguntas y siempre en perímetro por el próximo simulacro de incendio. Mientras tanto, el resto de la organización desconfía cada vez más de los datos cuanto más intenta trabajar con ellos. La heurística y las corazonadas vuelven a ser la norma. En última instancia, si no hay confianza en los datos, democratizar la analítica es una pérdida de tiempo.

La IA y el aprendizaje automático son diferenciadores

Muchas empresas tienen la IA/ML en su hoja de ruta porque puede crear un valor increíble en forma de interacciones personalizadas y automatizadas. El aprendizaje automático (o ML, que utilizaremos indistintamente con IA) se basa en modelos estadísticos avanzados para predecir el futuro a partir de señales históricas en los datos llamados características. Con suficientes datos de características y las técnicas de modelado adecuadas, la IA puede optimizar o personalizar cualquier interacción frecuente con una entidad de la que se preocupe la empresa (consumidores, contenidos, transacciones, etc.).

La calidad de los datos hace o deshace los modelos de ML. Debes asegurarte de que dispones de conjuntos de datos de alta calidad, tanto para el entrenamiento como para la inferencia. Los modelos funcionan bastante bien si los datos que ven en la producción coinciden con la distribución de los datos con los que fueron entrenados. Pero los modelos tienden a fracasar estrepitosamente cuando se les presentan datos que están muy lejos de la distribución que han visto antes. (Contrasta esto con los humanos, que pueden utilizar inteligencia de orden superior para generalizar de un dominio o distribución a otro y tener en cuenta desviaciones significativas de la norma).

IA generativa y calidad de los datos

Hablando de diferenciadores: ¿Qué pasa con la IA generativa? Estos modelos no funcionan como el ML tradicional. En lugar de hacer predicciones basadas en características diseñadas a partir de datos estructurados, ingieren directamente datos brutos no estructurados: es como beber de la manguera de incendios.

¿Sigue siendo relevante la calidad de los datos si las empresas dependen cada vez más de la IA generativa? La respuesta es un sí rotundo. Los modelos tendrán que incorporar datos estructurados de la empresa (como información sobre los clientes). Si automatizas partes de tu negocio con estos modelos, necesitas formas de rastrear esa automatización y asegurarte de que las cosas funcionan como se espera mediante registros de alta calidad. Y en última instancia, aunque la IA generativa esté a la altura o supere el bombo publicitario, siempre vamos a necesitar poder confiar en los datos que agregamos, contamos y analizamos, como el tiempo y el dinero.

Además, seguirá habiendo problemas de calidad de datos en los datos no estructurados que las organizaciones alimentan a estos modelos de IA generativa. Estos serán aún más difíciles de encontrar con los enfoques tradicionales de monitoreo de la calidad de los datos y requerirán ML o IA automatizados para identificarlos. Esto hace que las técnicas tratadas en este libro sean aún más relevantes como base para garantizar que las nuevas aplicaciones de IA generativa trabajan con entradas de alta calidad.

Las empresas están invirtiendo en una pila de datos moderna

Ningún resumen de las tendencias de datos actuales estaría completo sin una mención de la pila de datos moderna (¡aunque no podemos esperar a que este término pase de moda, para ser completamente honestos!) Hoy en día, el conjunto adecuado de proveedores de software como servicio (SaaS) puede lograr lo que un equipo de 100 personas de ingenieros de datos a tiempo completo habría hecho hace 10 años. Las empresas están migrando del almacenamiento heredado on-prem a sistemas en la nube que les permiten aprovechar más datos con más facilidad que nunca.

Figura 1-1. La pila de datos moderna.

La pila de datos moderna es una inversión importante. Esta inversión se ve socavada cuando se dejan de lado las herramientas para la calidad de los datos (como en la Figura 1-1). Especialmente porque las migraciones pueden ser una fuente importante de problemas de calidad de los datos, las organizaciones suelen acabar con datos en mal estado tras la actualización (consulta la sección "Migraciones de datos"). Rastrear en la causa raíz de los problemas es aún más difícil en un sistema totalmente nuevo en el que todo el mundo está aprendiendo el funcionamiento.

Más datos, más problemas

En la sección anterior, explicamos las tendencias que llevan a las empresas a depender más que nunca de datos de alta calidad. Por desgracia, los datos de alta calidad son más difíciles de conseguir que nunca. Hay más complejidad, ocurre más deprisa y con menos guardarraíles. Son las dos caras de una misma moneda: progreso y dolor. En esta sección, examinaremos algunos de los principales factores que provocan la degradación de la calidad de los datos.

Para una taxonomía de los tipos específicos de problemas de calidad de datos que pueden producirse, consulta el Apéndice A.

Problemas dentro de la fábrica de datos

Tradicionalmente, el almacén ha sido la metáfora elegida para describir cómo funcionan los sistemas de datos dentro de una empresa, haciendo hincapié en el almacenamiento y el transporte de mercancías. Pero con el auge de la pila de datos moderna y las nuevas formas en que las empresas trabajan con los datos, esa metáfora ya no es completa. En su lugar, sugerimos que las empresas actuales operan de un modo que se asemeja más a una fábrica de datos: un entorno complejo que sirve para transformar materias primas en productos útiles.

En lugar de acero, caucho y electrónica, estamos ingiriendo conjuntos de datos en streaming, réplicas de bases de datos, extractos de API de aplicaciones SaaS y archivos sin procesar de fuentes de datos. La fábrica está construida sobre cimientos, pero en lugar de cemento, aquí los cimientos son los almacenes de datos en la nube y los lagos de datos. Las máquinas que operan en la fábrica, en este caso, son herramientas de extracción, transformación y carga (ETL) como Matillion y Fivetran, plataformas de orquestación como Apache Airflow, y transformaciones que tienen lugar en dbt, Apache Spark y SQL. La gente de a pie que maneja las máquinas son los ingenieros de datos y los ingenieros analíticos del equipo de datos moderno. Y los productos producidos, en lugar de bienes de consumo o industriales, son productos de datos curados que impulsan las decisiones tomadas por los usuarios empresariales y los profesionales de los datos, el entrenamiento y la predicción de los algoritmos de ML, y las alimentaciones directas que se canalizan hacia otros sistemas de datos.

Todas las cosas que pueden ir mal en una fábrica física pueden ir mal en una fábrica de datos. La Figura 1-2 ofrece una visión general.

Figura 1-2. La fábrica de datos y lo que puede ir mal en la fábrica.

Máquinas rotas

Las herramientas de procesamiento u orquestación de datos pueden averiarse por completo, deteniendo o degradando el flujo de datos.

Errores de programación

Los trabajos de procesamiento de datos pueden ejecutarse fuera de orden o con una cadencia incorrecta, provocando datos que faltan, cálculos incorrectos o datos duplicados.

Materias primas pobres

Los datos brutos introducidos en la fábrica pueden ser de mala calidad debido a problemas previos, y los efectos adversos pueden propagarse por el resto del almacén.

Piezas incorrectas

Se pueden introducir errores en el SQL, Spark u otro código que esté procesando y manipulando los datos, provocando uniones, transformaciones o agregaciones no válidas.

Ajustes incorrectos

Los ingenieros pueden cometer errores en la configuración de trabajos complejos de procesamiento de datos, lo que puede provocar una gran variedad de problemas.

Mejoras chapuceras

Los intentos de actualizar el código, las versiones de las aplicaciones o subsistemas enteros pueden introducir diferencias sutiles pero omnipresentes en la forma de codificar o transformar los datos.

Fallos de comunicación

Los cambios bienintencionados para añadir nuevas características o funcionalidades pueden comunicarse mal a otros equipos afectados, lo que provoca incoherencias en la lógica de procesamiento de datos que crean problemas de calidad.

Los problemas dentro de la fábrica de datos suelen ser las fuentes más comunes de incidentes relacionados con la calidad de los datos, ya que afectan directamente al flujo y al contenido de los datos (y pueden ser muy difíciles de probar fuera de un entorno de datos de producción).

Migración de datos

Las migraciones de datos son cada vez más frecuentes, ya que las empresas tratan de mantenerse al día con la infraestructura más moderna y avanzada. Esto incluye pasar de un almacén de datos local a un proveedor en la nube (por ejemplo, de Teradata a Snowflake), de un proveedor en la nube a otro (por ejemplo, de Amazon Web Services [AWS] a Google Cloud Platform [GCP] o viceversa), de una base de datos a otra (por ejemplo, de PostgreSQL a AWS Aurora), o de una versión de base de datos a otra (por ejemplo, migraciones de clústeres de Elasticsearch).

Todas estas migraciones son propensas a problemas de calidad de los datos. Echemos un vistazo a la migración de almacenes de datos locales a proveedores de nube/SaaS. Muchas empresas tienen canalizaciones de datos muy complejas procedentes de sistemas heredados de mainframe que se transfirieron a almacenes de datos locales cada vez más heredados. Estos sistemas heredados llevan décadas en funcionamiento y han acumulado una enorme cantidad de complejidad incremental a medida que se han ido añadiendo nuevas funciones, los equipos han ido y venido, y los requisitos empresariales han cambiado.

Al trasladar esta maraña de procesamiento y almacenamiento de datos a la nube, las empresas tratan de replicar lo que se hacía en su entorno on-prem. Pero pueden introducirse problemas muy sutiles al recrear los flujos on-prem en la nube, con importantes consecuencias para la calidad de los datos.

Por ejemplo, una empresa con la que trabajamos mencionó que las fechas de nacimiento de sus clientes estaban muy alteradas por una migración de este tipo (visualizadas en la Figura 1-3). En su mainframe heredado, las fechas de nacimiento se almacenaban como números enteros desplazados de una determinada fecha de referencia, como el 1 de enero de 1900. Al exportarlos, esos enteros se convertían en fechas en el nuevo almacén en la nube. Esto parecía bastante fácil, salvo que, sin que nadie lo supiera, el almacén de datos en la nube utilizaba automáticamente la referencia de fecha y hora Unix de 1970 como desfase. Todas las fechas de nacimiento se desplazaron hacia el futuro.

Como ocurre con muchos problemas de calidad de datos, las repercusiones se produjeron más tarde, y de forma silenciosa. La empresa tenía una aplicación de marketing que enviaba correos electrónicos a los clientes en función de su edad. Una vez que esta aplicación fue apuntada al nuevo almacén de datos en la nube, ningún cliente recibió ningún correo electrónico hasta que alguien advirtió el problema. (Los equipos de marketing a menudo acaban soportando una cantidad significativa de dolor por la mala calidad de los datos. Una encuesta reveló que los responsables de marketing malgastaban el 21% de su presupuesto total en problemas de datos).

Figura 1-3. Cuando los datos almacenados en un almacén de datos on-prem se migran a un almacén de datos en la nube, pueden surgir discrepancias, como en este ejemplo, que implica diferentes fechas de referencia para calcular las fechas de nacimiento de los clientes.

Fuentes de datos de terceros

Utilizar datos de terceros -es decir, datos que proceden de fuera de la empresa- es más fácil y común que nunca. Por poner algunos ejemplos, mientras Jeremy estaba en Instacart, se recopilaban regularmente datos de terceros:

• Datos meteorológicos para la previsión/programación de la demanda

• Servicios de terceros para información de mapas para el encaminamiento

• Datos de catálogos de productos de bienes de consumo envasados (BPC) para enriquecer la experiencia de búsqueda y compra del usuario

• Datos de puntuación de la propensión al fraude para evitar devoluciones de cargos

• Datos de inventario del minorista para determinar qué hay en las estanterías de cada tienda en un momento dado

Con frecuencia, los datos de terceros se codifican como una relación de datos entre dos socios: la empresa A y la empresa B tienen que trabajar juntas para dar servicio al cliente X o realizar la operación Y, y eso requiere intercambiar datos. A veces, esto se denomina datos de segunda parte.

En otros casos, estás consumiendo datos públicos o datos empaquetados por un proveedor de servicios externo para revenderlos en una relación de uno a muchos, a menudo para tomar decisiones sobre entidades (clientes, empresas, ubicaciones) sobre las que tienes información limitada. Si exploras los feeds disponibles públicamente en el catálogo online Demyst, verás que es posible aprovechar datos fiscales, inmobiliarios y empresariales exhaustivos, todo ello con unos pocos clics.

Los datos de terceros son una fuente habitual de problemas de calidad de datos. Esto no sólo se debe a que los proveedores cometen errores, sino también a que a menudo realizan cambios, por ejemplo, en sus API o formatos de datos. A menos que dispongas de un contrato de datos muy claro, los terceros no pensarán necesariamente en cómo pueden afectar sus actualizaciones a tu caso de uso específico, ni estarán obligados a avisar o a proporcionar mitigaciones.

Crecimiento y cambio de la empresa

Diríamos que casi todos los datos empiezan siendo de alta calidad. Cuando se construye e instrumenta por primera vez un producto , los datos captados sobre ese producto por el ingeniero que lo construyó suelen estar muy alineados con su intención y la función del producto.

Pero los datos no existen en el vacío. En el mundo real, una empresa está constantemente adaptando y mejorando sus productos, lo que a su vez afecta a los datos emitidos por esos productos. Es como la segunda ley de la termodinámica: la entropía de los datos siempre aumentará con el tiempo. A medida que pasa el tiempo, los siguientes factores hacen que la calidad de los datos se degrade:

Novedades

Las nuevas funciones suelen ampliar el alcance de los datos que capta el sistema. En la medida en que se trata de un cambio del tipo "añadir columnas adicionales", el riesgo para la calidad de los datos no es alto. Sin embargo, en algunos casos, las nuevas funciones pueden sustituir a las existentes, lo que suele tener un impacto repentino en los datos emitidos por el sistema. En muchos casos, las nuevas funciones pueden cambiar la forma de los datos. Puede que aumente el nivel de granularidad, por ejemplo, que los datos se capturen ahora a nivel de un artículo en lugar de a nivel de todo el producto. O lo que antes era un único mensaje puede dividirse y reestructurarse en muchos mensajes.

Corrección de errores

El software comercial medio contiene entre 20 y 30 errores por cada 1.000 líneas de código, según el Consorcio de Informática Sostenible CyLab de la Universidad Carnegie Mellon. Las correcciones de errores pueden tener el mismo impacto que las nuevas funciones. También pueden mejorar realmente la calidad de los datos, pero cuando esa mejora repentina llega como un "shock" a los sistemas que dependen de los datos, puede tener consecuencias negativas (véase la sección "Shocks de datos").

Refactoriza

La refactorización se produce cuando los equipos quieren mejorar la estructura del código o los sistemas que hay detrás de una aplicación sin cambiar la funcionalidad. Sin embargo, las refactorizaciones a menudo presentan el riesgo de cambios no intencionados, especialmente en cosas como la captura de datos, que pueden no estar sólidamente probadas en el código de la aplicación.

Optimizaciones

A menudo, los cambios se realizan simplemente para mejorar la velocidad o la eficacia de una aplicación en . En muchos casos, la forma en que se capturan los datos puede ser un problema de rendimiento, y los cambios pueden afectar a la fiabilidad, la granularidad temporal o la unicidad de los datos emitidos por el sistema.

Equipos nuevos

Los nuevos equipos suelen heredar una aplicación heredada y llegan con un conocimiento limitado de cómo interactúa con otros sistemas o cómo se consumen los datos que produce. Pueden romper involuntariamente con las expectativas existentes de otros equipos al realizar cambios en su producto, introduciendo problemas de calidad de datos.

Apagones

Además de los cambios intencionados, muchos sistemas sufrirán simplemente interrupciones en las que dejarán de funcionar o lo harán con un nivel de servicio degradado. La captura de datos suele perderse por completo durante estas interrupciones. A menudo no se trata de un problema de calidad de datos en sí, ya que la falta de datos es un reflejo de la falta de actividad debida a la interrupción. Pero en muchos casos, la interrupción puede afectar a los datos que se emiten sin afectar al servicio en sí, lo que sí es un problema de calidad de los datos.

Una enmarañada red de datos

Cuando se trata de datos, no es útil pensar en un único sistema aislado. Cada producto forma parte de una red de muchos sistemas que interactúan entre sí pasando datos de un lado a otro (en tiempo real o por lotes de solicitudes). Por tanto, lo que un sistema emite como datos es función no sólo de su comportamiento, sino también de cómo interactúa con todos los demás sistemas de la red a la que está conectado.

Los ingenieros y jefes de producto que realizan un cambio suelen comprender las implicaciones de ese cambio en sus propios sistemas. Pero, ¿qué pasa con las implicaciones que se extienden por toda la aplicación o la organización? La capacidad de los equipos para comprender y prever estas implicaciones disminuirá a medida que nos alejemos de su área de propiedad.

Por ejemplo, si el equipo de catálogos de productos de una empresa de comercio electrónico realiza un cambio en la estructura de sus datos, puede que entienda cómo afectaría a los sistemas de recomendación de productos de la empresa, con los que trabaja frecuentemente. Pero, ¿qué probabilidades hay de que conozcan las implicaciones para el equipo de publicidad que vende anuncios dirigidos? ¿Y qué hay de las consecuencias para el equipo de cumplimiento que está optimizando cómo se enrutan los pedidos y que forma parte de una división completamente diferente?

En una gran empresa, prever todas las implicaciones de un cambio de datos es casi imposible. La mayoría de los equipos hacen el mejor esfuerzo y siguen adelante. Así, a medida que las organizaciones crecen, aumentan sus problemas de calidad de datos.

Factores exógenos

Cuando aprovechas los datos de para tomar decisiones o crear productos, siempre habrá factores que afecten a los datos que están fuera de tu control, como el comportamiento de los usuarios, los acontecimientos globales, las acciones de la competencia y las fuerzas de los proveedores y del mercado. Ten en cuenta que no se trata de problemas de calidad de los datos en sí, pero a menudo parecen problemas de calidad de los datos y es posible que deban tratarse de forma similar.

Por ejemplo, en algunos sectores, las empresas toman decisiones automatizadas basadas en datos en tiempo real sobre lo que hacen los competidores. Las empresas de comercio electrónico monitorean los datos de precios de la competencia y, en respuesta, ajustan sus precios casi instantáneamente. Las aerolíneas hacen lo mismo. En estos casos, si un competidor cambia su comportamiento de forma repentina y drástica, la empresa hará lo mismo inmediatamente y acabará con un gran cambio en sus datos. Es importante que las empresas estén informadas de estos cambios, ya que no siempre son deseables o intencionados.

Cualquier debate sobre factores exógenos sería negligente si no mencionara la pandemia de COVID-19. Todo el mundo tuvo que tratar los primeros meses de COVID-19 como un caso especial al analizar el comportamiento de los usuarios. Por ejemplo, la Figura 1-4 muestra cómo los datos sobre el número de kilómetros registrados en los viajes en taxi de Chicago cambiaron drásticamente en marzo de 2020.

Figura 1-4. La duración media de un viaje en taxi en Chicago cayó en picado en marzo de 2020. Los datos sobre taxis están disponibles públicamente en el sitio web de la ciudad de Chicago. Puedes ver una versión a tamaño completo de esta imagen en https://oreil.ly/adqm_1_4.

Durante COVID-19, los modelos de aprendizaje automático tuvieron que volver a entrenarse rápidamente con datos nuevos, ya que sus supuestos basados en tendencias históricas ya no eran válidos. En un caso muy conocido, el modelo de Zillow para predecir los precios de la vivienda -que impulsaba una nueva rama de negocio, Zillow Offers- no pudo adaptarse con la suficiente rapidez. El servicio automatizado pagó de más por viviendas que no pudo vender en un mercado cambiante, y lamentablemente Zillow tuvo que despedir a casi una cuarta parte de su plantilla.

Los equipos suelen encontrarse en una de estas dos situaciones respecto a los factores externos:

• En algunos casos, como con COVID-19, los cambios externos son lo suficientemente drásticos como para que tengas que poner sobre aviso tus procesos de toma de decisiones y posiblemente volver a entrenar tus modelos ML. Es casi como un problema de calidad de datos: es un cambio del que quieres ser notificado inmediatamente para poder controlar los daños.

• En otros casos, los factores externos tienen una influencia más sutil, como un problema en la cadena de suministro que afecte a tus tiempos de procesamiento de pedidos. Tienes que comprender rápidamente el contexto de estos cambios y descartar cualquier problema de calidad de los datos, que a menudo pueden parecerse a tendencias externas reales.

Por qué necesitamos un monitoreo de la calidad de los datos

Con la importancia cada vez mayor de los datos de alta calidad, y el hecho de que los problemas de calidad de los datos son más prolíficos que nunca, puede que ya estés convencido de que mejorar la calidad de los datos es importante. Pero, ¿cómo debes plantearte esta iniciativa? ¿Se trata de un arreglo puntual: poner tus datos en forma durante un periodo de meses o trimestres, y dejar que las cosas funcionen sin problemas a partir de ahí?

Este tipo de enfoque suele tener sentido para el software, pero mucho menos para los datos. El código es el mismo hoy que mañana, salvo actualización deliberada. Puedes probarlo en un entorno de control de calidad controlado y también ejecutar pruebas unitarias que aíslen sólo una parte del sistema. Una vez superadas las pruebas, básicamente has terminado.

Los datos, por otra parte, son caóticos y cambian constantemente. Dependen de factores externos que no controlas, como la forma en que los usuarios interactúan con tu producto en tiempo real, por lo que sólo puedes probarlos de forma holística en producción. Tus pruebas tienen que ser capaces de filtrar todo el ruido -y hay mucho ruido- de la verdadera señal de calidad de los datos.

Por esta razón, mientras que los errores de software suelen detectarse y corregirse rápidamente mediante pruebas automatizadas y comentarios de los usuarios, creemos firmemente que la gran mayoría de los problemas de calidad de los datos nunca se detectan. Como los equipos carecen de las herramientas adecuadas de monitoreo continuo de los datos, los problemas se producen en silencio y pasan desapercibidos.

Para empeorar las cosas , el coste de solucionar un problema de calidad de datos aumenta drásticamente cuanto más tiempo ha pasado desde que se produjo el problema:

• El número de cambios potenciales que podrían haber causado el problema aumenta linealmente con la duración de la evaluación.

• La cantidad de contexto que tiene el equipo sobre por qué se hizo un cambio, o cuáles podrían ser las implicaciones de ese cambio, disminuye con el tiempo transcurrido desde el cambio.

• El coste de "arreglar" el problema (incluido el relleno de los datos) aumenta con el tiempo transcurrido desde que se produjo el problema.

• Los problemas que persisten durante largos periodos de tiempo acaban convirtiéndose en un "comportamiento normal" para otros sistemas posteriores, por lo que solucionarlos puede provocar nuevos incidentes.

Cuando se introduce un incidente y se arregla más tarde, en realidad tiene dos tipos diferentes de impacto. Los llamamos cicatrices de datos y choques de datos.

Cicatrices de datos

Después de que ocurra un incidente, a menos que los datos se reparen meticulosamente (lo que a menudo es imposible o caro de hacer), dejará una cicatriz en los datos. La primera vez que oímos este término fue a Daniele Perito, director de datos y cofundador de Faire. Una cicatriz es un periodo de tiempo para un conjunto determinado de datos en el que un subconjunto de registros no son válidos o son anómalos y no pueden ser fiables para ningún sistema que opere con esos registros en el futuro.

Las cicatrices de datos afectarán a los modelos ML, ya que dichos modelos tendrán que adaptarse para aprender relaciones diferentes en los datos durante el periodo de la cicatriz. Esto debilitará su rendimiento y limitará su capacidad de aprender de todos los datos captados durante la cicatriz. También amortiguará la creencia del modelo en la importancia de las características afectadas por la cicatriz: el modelo infraponderará estas entradas, creyendo erróneamente que son menos frecuentes en el conjunto de datos. Incluso si consigues retroceder en el tiempo y reparar la cicatriz, es fácil introducir lo que se conoce como fuga de datos en las aplicaciones de ML posteriores, al incluir inadvertidamente alguna información del estado actual en tu reparación. Esto hace que el modelo funcione muy bien en las evaluaciones fuera de línea (ya que tiene acceso a la información "viajada en el tiempo" desde el futuro), pero que actúe de forma errática en producción (donde ya no dispone de esta información).

Las cicatrices de datos también afectarán en gran medida a cualquier trabajo futuro de análisis o ciencia de datos que se realice sobre este conjunto de datos. Pueden dar lugar a canalizaciones de datos más complejas que son más difíciles de escribir y mantener, ya que los usuarios de datos tienen que añadir una gran cantidad de manejo de excepciones para evitar los sesgos introducidos por la cicatriz. Estas excepciones pueden tener que señalarse y tratarse en cualquier informe o visualización que incluya datos de la época de la cicatriz, lo que aumenta la sobrecarga cognitiva de cualquiera que intente interpretar los datos o tomar decisiones a partir de ellos. O bien, puede ser necesario eliminar las cicatrices por completo del conjunto de datos, lo que provoca una "amnesia de datos" de ese periodo, que puede afectar al análisis de tendencias o a las comparaciones temporales (por ejemplo, ¿cuál fue nuestro resultado interanual para esta estadística?)

Choques de datos

Además del efecto cicatrizante, también hay efectos en la producción que se producen tanto cuando se introdujo el problema de calidad de los datos como cuando se soluciona. Esto es lo que llamamos un choque de calidad de datos, y también puede afectar a la IA/ML y a la toma de decisiones.

Cuando se produce el primer problema de calidad de los datos, los modelos de ML que utilizan características derivadas de los datos se encontrarán de repente con datos totalmente diferentes de aquellos con los que fueron entrenados. Esto hará que se sientan "conmocionados" por los nuevos datos, y producirán predicciones que a menudo son tremendamente inexactas para cualquier observación afectada por el incidente de la calidad de los datos. Este choque durará hasta que los modelos se vuelvan a entrenar con los nuevos datos, lo que suele ocurrir automáticamente en un modelo de implementación continua.

Luego, una vez que se corrige la calidad de los datos, se introduce otra perturbación en el modelo (a menos que los datos se reparen históricamente, lo que a menudo no es posible). A menudo, la conmoción provocada por la corrección puede ser tan grave como la conmoción inicial provocada por la introducción del problema de calidad de los datos.

Para los casos de uso de análisis/informes, estas perturbaciones suelen manifestarse como métricas o análisis que presentan cambios repentinos inesperados. Cuando se observan, a menudo se confunden con cambios del mundo real (todo el propósito de estos informes es reflejar lo que ocurre en la realidad), por lo que se cambian las operaciones o se toman otras decisiones para responder al problema de calidad de los datos como si fuera real. De nuevo, lo mismo puede ocurrir a la inversa cuando se publica la corrección.

Cuanto más tiempo pase sin que se solucione el problema de la calidad de los datos, más profunda será la cicatriz y mayor el impacto de solucionarlo.

Figura 1-5. Cómo se acumulan los incidentes para erosionar la calidad de los datos y la confianza a lo largo del tiempo. Cada barra es una cicatriz de datos dejada por el incidente. Cada X (que marca cuándo se produjo el incidente por primera vez) es un choque de datos. En particular, la marca de verificación (cuando se resolvió el Incidente 2) también es un choque de datos.

La consecuencia de permitir que sigan acumulándose cicatrices y golpes es que, lentamente, con el tiempo, se erosiona la calidad objetiva de los datos. La figura 1-5 ilustra cómo los incidentes se acumulan de tal forma que todo el mundo se convence de que la calidad de los datos es baja y de que los propios datos no son de fiar. Y por difícil que sea rellenar los datos, es aún más difícil rellenar la confianza.

Por tanto, es necesario un cambio de marco en la forma en que las organizaciones piensan sobre la lucha contra la mala calidad de los datos. No debería tratarse de un proyecto puntual para arreglar la calidad de los datos de una determinada fuente de datos. En su lugar, debe ser una iniciativa de monitoreo continuo de la calidad de los datos, en la que los problemas de calidad de los datos se detecten a medida que se producen y se resuelvan lo antes posible.

Sin un monitoreo de la calidad de los datos, los problemas pasarán desapercibidos hasta que un usuario empresarial, un profesional de los datos o un cliente del algoritmo ML u otros sistemas se dé cuenta. Dirigir una fábrica de datos de este modo es similar a dirigir una fábrica que elabora un bien de consumo sin ningún proceso de control de calidad.

Automatizar el monitoreo de la calidad de los datos: La nueva frontera

Hoy en día, los profesionales de los datos están experimentando cambios apasionantes y francamente asombrosos en este campo. Ya sea invirtiendo en IA generativa, democratizando la analítica en toda la empresa o migrando de una base de datos heredada a la nube, casi todas las empresas están haciendo algo nuevo con los datos que nunca antes habían hecho.

Para la mayoría de las empresas, por tanto, el mejor momento para invertir en la calidad de los datos es ahora. A medida que crece tu uso de los datos, también aumentan los riesgos y el impacto negativo de los problemas de calidad de los datos. La calidad de los datos es algo que hay que monitorear constantemente y mantener con diligencia, solucionando los problemas en cuanto surjan.

El monitoreo eficaz de la calidad de los datos no es tarea fácil, especialmente a escala de miles de tablas y miles de millones de registros, que es lo habitual en una gran empresa. Aunque pueda resultar obvio que no funciona hacer que los humanos inspeccionen manualmente tus datos, tampoco funciona utilizar soluciones heredadas como escribir pruebas para tus datos y hacer un seguimiento de las métricas clave. Puede que quieras hacer esto para tus tablas más importantes, pero implementarlo para todo tu almacén de datos simplemente no es factible.

En este libro, te presentaremos el concepto de automatizar el monitoreo de la calidad de los datos con ML no supervisado. Se trata de una nueva técnica con muchas ventajas. Apenas requiere configuración manual y se adapta fácilmente a todo tu almacén de datos. Con la implementación adecuada, aprende automáticamente los umbrales apropiados para determinar si un cambio en los datos es lo suficientemente grande como para señalar un problema de calidad. Puede detectar una amplia gama de problemas, incluidos los desconocidos para los que nadie ha pensado nunca en escribir una prueba.

Utilizar el ML conlleva sus propios retos. Construir el modelo es una tarea complicada de por sí, pero también tendrás que asegurarte de que funciona con una amplia variedad de datos del mundo real sin sobrealertar ni subalertar. Querrás crear notificaciones que ayuden a tu equipo a clasificar eficazmente los problemas, e integraciones con tu conjunto de herramientas de datos que pongan la calidad de los datos en primer plano para tu organización. Y tendrás que disponer de un plan para implementar y gestionar tu plataforma de monitoreo a largo plazo.

No te preocupes: estamos aquí para ayudarte con los consejos y las herramientas que necesitarás en el camino. Creemos que automatizar el monitoreo de la calidad de los datos con ML es tan emocionante como cualquier innovación de datos que se haya producido en los últimos años y uno de los avances más importantes en la pila de datos moderna. Al final de este libro, esperamos que estés de acuerdo.