El mejor marco de calidad de datos para ingenieros de plataformas sénior

Es por eso que cualquier organización que considere que los datos son importantes para el funcionamiento de su negocio, ya sean consumidores internos o externos, debe practicar la gestión de la calidad de los datos e implementar un marco de calidad de los datos. Esto es lo que parece: desarrollar procesos y patrones repetibles, idealmente automáticos, para garantizar que los datos que ingresan a su sistema y se entregan en sentido descendente son lo que usted y sus consumidores esperan.

Y como bien saben los ingenieros de datos sénior, comprender esas expectativas es la mitad del trabajo. Gran parte de la otra mitad se dedica a traducir esas expectativas en seguimiento y alertas que le ayudarán a encontrar y arreglar problemas en procesos de ingesta complicados.

En esta guía, compartimos estrategias para garantizar que la gestión de la calidad de los datos no se superponga a sus procesos codificados existentes, sino que esté integrada en cada DAG. Para gestionarlo bien, debe detectar anomalías mucho antes de que los datos de baja calidad entren en su capa de transformación.

Empecemos con una definición. El marco de calidad de los datos es una herramienta que una organización puede utilizar para definir los atributos relevantes de la calidad de los datos y proporcionar orientación para un proceso de gestión de la calidad de los datos que garantice continuamente que dicha calidad cumple las expectativas de los consumidores (SLA).

Esa oración es engañosamente compleja, así que vamos a desglosarla:

1. Necesita un proceso: a menos que tenga horas ilimitadas de ingeniería, un proceso debe incluir pruebas unitarias repetibles e, idealmente, automáticas en cada etapa de la canalización de datos (especialmente en la ingesta si desea detectar problemas de forma proactiva) y un flujo de trabajo para tratar los problemas de datos.
2. Debe garantizar continuamente: La calidad de sus datos decae en proporción a la velocidad de sus datos, también conocida como deriva de datos. Los datos de alta velocidad con los que muchos de nosotros lidiamos ahora requieren comprobaciones frecuentes.
3. Debe satisfacer las expectativas de los consumidores, no las suyas propias: la calidad de los datos es fundamentalmente un proceso empresarial. Sus SLA de datos o “acuerdos de servicio” se establecen con los consumidores y nada de la parte de ingeniería importa si los científicos de datos no pueden ejecutar sus modelos, si los clientes reciben estimaciones de entrega de envíos inexactas o si su vicepresidente regional tiene que acudir a la reunión de la junta con las manos vacías porque el panel no se ha cargado.

Hay muchos factores que intervienen para cumplir la promesa anterior, y cada uno de esos elementos está plagado de dependencias. Por ejemplo, si usted se preguntara cómo diseñar un sistema de este tipo, se plantearía las siguientes preguntas:

1. ¿Cómo llegará a comprender las expectativas de los consumidores en torno a la calidad de los datos?
2. ¿Cómo traducirá esas expectativas en medidas cuantificables de la calidad de los datos?
3. ¿Cómo implementará medidas automáticas de calidad para cada uno de sus pipelines?
4. ¿Cómo determinará los umbrales para cada dimensión de la calidad de los datos?
5. ¿Cómo alertará a su equipo cuando los datos infrinjan esos umbrales?
6. ¿Qué hará tu equipo cuando reciba una alerta?
7. ¿Cómo juzgarán la validez y urgencia de la alerta?
8. Si hay un problema, ¿cómo identificarán las causas próximas?
9. ¿Cómo identificarán las causas principales?
10. ¿Cómo harán saber a los consumidores qué esperar?
11. ¿Cómo abordarán la causa principal?
12. ¿Cómo verificarán que abordaron la causa principal?
13. ¿Cómo documentan lo ocurrido para acumular conocimientos?

¿Parece una lista larga y potencialmente desafortunada? Nunca temas. Puede delegar.

La pregunta 1 es la más adecuada para el analista de negocios de su pod o escuadrón. De ellos depende hablar con las unidades de negocio para descomponer las historias de los usuarios, las preferencias declaradas, las preferencias implícitas, las solicitudes y las post-mortem de eventos en una lista de “demandas” para los datos. Estas son las expectativas cualitativas que los consumidores tienen de los datos, y es un poco una conversación bidireccional, ya que es posible que no tengan las palabras para describir exactamente lo que quieren. (A menos que sus consumidores de datos sean sus científicos de datos, lo que realmente puede acelerar esto).

La pregunta 2 es para que usted y sus científicos de datos respondan juntos (especialmente si también son el consumidor). Dadas las características de sus datos para cada pipeline, ¿qué atributos puede medir realmente para descomponer aún más la lista de expectativas cualitativas en una lista de mediciones cuantitativas?

Dependiendo del modelo de calidad de datos que siga, hay cuatro o cinco dimensiones de calidad a considerar. En IBM Databand preferimos un modelo con cuatro características:

• Fitness
  • Precisión: los datos reflejan la realidad
  • Integridad: calidad / tiempo
• Linaje
  • Fuente: ¿el proveedor está cumpliendo con sus expectativas?
  • Origen: ¿de dónde vino?
• Gobernanza
  • Controles de datos
  • Privacidad de datos
  • Regulación
  • Seguridad
• Estabilidad
  • Coherencia
  • Confiabilidad
  • Puntualidad
  • Sesgo

Con esas métricas en la mano, los ingenieros de datos pueden abordar las preguntas 3-13 y empezar a construir una estrategia de gestión de la calidad de los datos. Y antes de entrar precisamente en cómo hacerlo, vale la pena preguntarse, ¿por qué tanto esfuerzo?

Hace unos años, un cambio de configuración inocuo en Microsoft Dynamics CRM de un minorista importante significó que la cantidad de inventario que se mostraba en cada artículo en línea dejó de reflejar la realidad. El contador simplemente dejó de actualizar.

La gente continuó comprando, pero el número de volumen se mantuvo constante. Cuando se alertó al equipo de ingeniería de datos, las cosas se pusieron feas.

La mayoría de los artículos estaban disponibles para comprar en línea, pero también para recoger en la tienda. Mucha gente eligió la recolección en tienda. Los pedidos se procesaron y, no obstante, se vendieron artículos que no existían. Así que los consumidores acudieron a las tiendas, donde los dependientes se apresuraron a encontrar sustitutos o a prometerles descuentos o a apaciguarlos de alguna manera. Se formaron colas. Los visitantes de la tienda tenían que esperar para comprar y se desanimaban al ver a tanta gente pulsando enfadada sus teléfonos. Y como se tardó días en descubrir el problema y en arreglar la tubería, pasaron algunos días más antes de que las cosas se resolvieran.

Si tenemos en cuenta la pérdida de reputación de la marca, el error costó decenas de millones y no tendría por qué ocurrir.

Es decir, los problemas de datos se agravan. Pueden ser difíciles de detectar y abordar, y crecer sin ser vistos. Es fácil caer en el patrón de suponer que todo funciona solo porque todavía se están obteniendo algunos insights, incluso cuando se acumula una cantidad cada vez mayor de datos subterráneos.

Además, los signos más verdaderos de problemas de calidad de los datos también tienden a ser indicadores rezagados. Por ejemplo, que los consumidores se lo digan. O como en el ejemplo anterior de CRM para venta minorista, se lo dicen miles de gerentes minoristas y vicepresidentes regionales. Eso es malo. Esto significa que los datos han estado en su sistema durante algún tiempo y que la solución tardará días en dar resultados. Hablemos de no satisfacer las expectativas del consumidor.

Esta es la situación en la que se encontraba la compañía naviera Shipper, y por qué invirtieron tanto para evitar que ocurriera. Su equipo de ingeniería de datos entrega datos lo más cerca posible del tiempo real a una aplicación que ayuda a los proveedores de comercio electrónico a entregar su inventario a un puerto de envío. No solo tienen que preocupar por las expectativas de sus consumidores, sino por los consumidores de sus consumidores. Y cuando su sistema a veces tenía dos días de retraso, creaba ondas en cascada de expectativas incumplidas. Por lo tanto, invirtieron mucho en la gestión de la calidad de los datos y en herramientas que pudieran proporcionarles alertas tempranas con comprobaciones automáticas.

La gestión de la calidad de los datos es una forma de hacer que las comprobaciones de la calidad de los datos sean automáticas y generalizadas, de modo que se combatan las fuerzas de la entropía en los conjuntos de datos y las canalizaciones con una fuerza igual y opuesta.

Volvamos a nuestro ejemplo anterior y a la lista de preguntas. Sus analistas hablan con la empresa para recopilar requisitos y usted recibe una lista de expectativas cuantitativas de los consumidores de sus científicos de datos. ¿Cómo avanzar y construir el sistema?

Usted elabora su marco de calidad de datos. Su marco debe reconocer ante todo que el sistema es un ciclo y que todo lo que aprenda sobre las expectativas de los consumidores, que siempre evolucionan, debe influir en el sistema.

Exploremos cada una de estas etapas:

1. Calificar: los analistas de negocio descomponen las necesidades de los consumidores en una lista de requisitos
2. Cuantificar: loscientíficos de datos descomponen los requisitos en medidas cuantificables de la calidad de los datos, que en este punto siguen siendo solo teóricas.
3. Plan: los ingenieros de datos traducen las medidas cuantitativas de la calidad de los datos en comprobaciones que pueden ejecutar en su plataforma de observabilidad de canalización de datos. Una plataforma de este tipo es crítica: los sistemas de programación de flujos de trabajo y canalizaciones como Airflow y Spark pueden detectar problemas con una canalización en sí, pero no dentro de los datos, que es donde surgen la mayoría de los problemas. Sus ingenieros deberán comprender qué se puede y qué no se puede rastrear en su sistema.
4. Implementación: los ingenieros de datos implementan el seguimiento y lo prueban. Por poner un ejemplo muy sencillo, si es necesario que todos los datos estén presentes y que no falte ningún campo o columna, puede establecer una alerta en torno a los parámetros de integridad de los datos. Una plataforma de observabilidad como Databand lo hace posible y puede permitirle configurar la detección de anomalías para que no tenga que establecer cada valor manualmente.
5. Gestión: los ingenieros de datos realizan pruebas retrospectivas de estas alertas con los datos históricos de canalización para verificar que realmente habrían funcionado según lo previsto. Si es cierto, los ponen en producción junto con un plan de gestión de incidentes que determina quién es responsable cuando se dispara una alerta y qué harán cuando reciban esa alerta.
6. Verificación: los ingenieros y científicos de datos confirman que contar con el marco de gestión de datos ha mejorado considerablemente el rendimiento en las métricas deseadas. Los analistas empresariales confirman con los consumidores que así es.

¿Y qué hace con su marco? Usted lo pone en práctica.

Como exploramos en muchos de nuestros ejemplos, el peor indicador de un problema de calidad de datos es un indicador rezagado, por ejemplo, de un consumidor que le dice que algo no funciona. Gran parte de lo que hacemos en ingeniería de datos es generar confianza junto con pipelines.

Si invierte en un marco de gestión de la calidad de los datos que ayude a su equipo a identificar automáticamente los problemas, creará datos en los que valga la pena confiar. Y eso facilita mucho su trabajo.

Explore cómo IBM Databand ofrece una mejor supervisión de la calidad de los datos al detectar cambios inesperados en las columnas y registros nulos para ayudarle a cumplir los SLA de datos. Si está listo para profundizar, reserve una demostración hoy mismo .