Mejora de la calidad de los datos: exploración de los contratos de datos con Lyft

¡Parece que es la segunda parte de mi serie sobre calidad de datos!

En una publicación anterior , exploré la estrategia de Airbnb para mejorar la calidad de los datos a través de incentivos. Implementaron una puntuación única y criterios de puntuación claros para establecer un entendimiento común entre los productores y consumidores de datos, fomentando un sentido genuino de propiedad.

Ahora, Lyft está adoptando un enfoque distinto: no intenta hacer lo mismo de manera diferente, sino que se centra en diferentes aspectos de la calidad de los datos. Y la estrategia de Lyft complementa los esfuerzos de Airbnb. Si bien considero que la puntuación DQ de Airbnb (o cualquier puntuación similar) es un medio eficaz para consolidar varios intentos de elevar la calidad de los datos, Lyft está abordando este desafío desde un ángulo diferente.

La puntuación DQ de Airbnb sirve como una herramienta valiosa para proporcionar una visualización concreta de la calidad de los datos. En esencia, cualquier iniciativa para mejorar la calidad de los datos debería manifestar un impacto perceptible en este aspecto. Por otro lado, Lyft presenta una posible iniciativa para mejorar proactivamente la calidad probando y validando datos según criterios de calidad específicos.

Fundamentalmente, es un punto diferente en el ciclo de vida de la calidad de los datos. La introducción de un mecanismo para mejorar la calidad requiere la capacidad de medirla inicialmente.

Entonces, mientras Airbnb se centra en medir y observar la calidad de los datos, confiando en el interés del productor de mejorar esta calidad y "verse bien", Lyft adopta un enfoque diferente. Lyft pone énfasis en probar y validar activamente la calidad de los datos, brindando tanto a los productores como a los consumidores los medios para mejorar y controlar la calidad de manera efectiva.

En conjunto, estos enfoques proporcionan una estrategia integral para abordar y mejorar la calidad de los datos a lo largo de su ciclo de vida .

Por esta razón, estaba particularmente interesado en observar más de cerca el enfoque de Lyft.

Otro factor que me intrigó son las pruebas, más específicamente las pruebas por contrato, que se han utilizado durante muchos años en la ingeniería de software básica con el surgimiento de la arquitectura de microservicios. Los contratos de datos, sin embargo, son algo más reciente en el ámbito de la ingeniería de datos y se consideran el pináculo o uno de los últimos pasos a seguir en el camino hacia la construcción de canales de datos de alta calidad. Es por eso que quería examinar el enfoque de Lyft con más detalle y explorar algunos paralelos potenciales.

Como se mencionó, los enfoques adoptados por Airbnb y Lyft son complementarios y apuntan a lograr el mismo objetivo: mejorar la calidad de los datos.

Airbnb ha desarrollado la puntuación DQ, que se centra en medir y mejorar cuatro aspectos distintos de la calidad de los datos :

DQ Score tiene principios rectores, que incluyen cobertura total, automatización, capacidad de acción, multidimensionalidad y capacidad de evolución. Tiene dimensiones como precisión, confiabilidad, administración y usabilidad.

Verity de Lyft es una plataforma diseñada para mejorar la calidad de los datos en 5 dimensiones

Define la calidad de los datos como la medida de qué tan bien se pueden utilizar los datos según lo previsto, abarcando aspectos como la corrección semántica, la coherencia, la integridad, la singularidad, la buena formación y la puntualidad .

Es fácil establecer paralelismos entre los cinco aspectos de la calidad de los datos mejorados por Verity de Lyft y las cuatro dimensiones de la calidad de los datos medidas por la puntuación DQ de Airbnb. Por ejemplo, aspectos como la puntualidad ciertamente contribuirían a la confiabilidad de la puntuación DQ, mientras que la precisión dependería de la corrección semántica, la integridad y la unicidad de los datos. La puntuación de usabilidad, por otro lado, está influenciada por la coherencia de los datos, entre otros factores.

Verity de Lyft se centra en definir controles relacionados con la corrección semántica, la coherencia, la integridad, la singularidad, la buena formación y la puntualidad . Sigue un enfoque de prueba y validación, mientras que la puntuación DQ unificada de Airbnb enfatiza la evaluación de la calidad de los datos a través de varias dimensiones.

Si quisiéramos incorporar la puntuación DQ en este último esquema, estaría al lado de los pasos de Alerta/Depuración.

La puntuación DQ de Airbnb utiliza diferentes señales para evaluar la calidad de los datos en los aspectos de precisión, confiabilidad, administración y usabilidad .

También teníamos un conjunto de señales de entrada que miden más directamente la calidad (certificación Midas, validación de datos, errores, SLA, comprobaciones DQ automatizadas, etc.), mientras que otras eran más bien indicadores de calidad (por ejemplo, propiedad válida, higiene de buena gobernanza, el uso de herramientas para caminos pavimentados).

Como se mencionó anteriormente, es probable que existan superposiciones entre la puntuación DQ de Airbnb y la de Verity. Mientras Airbnb se centra en impulsar la calidad de los datos hacia la derecha, enfatizando la medición y la puntuación, Verity de Lyft adopta un enfoque proactivo al desplazar las configuraciones de definición de verificación, las pruebas y los procesos de validación hacia la izquierda, enfatizando la mejora proactiva de la calidad de los datos.

Ahora, mi interés principal se encuentra a la izquierda, en los aspectos de configuración, prueba y validación de definiciones de verificación.

¿Cómo integra Lyft las pruebas de calidad de los datos en sus procesos?

Primero examinemos las rutas de ejecución.

Actualmente, Verity de Lyft se centra principalmente en garantizar la calidad de los datos almacenados en su almacén de datos Hive. Sin embargo, hay planes para ampliar sus capacidades para admitir otras fuentes de datos en el futuro.

Tenga en cuenta que, si bien se refieren a Hive como una casa de trabajo de datos, en realidad la utilizan como una solución de almacenamiento de datos híbrida, que opera como un almacén de datos para datos estructurados, procesados y limpios (capa plateada) y al mismo tiempo sirve como un lago de datos para eventos sin procesar. datos (capa de bronce).

La mala calidad de los datos en Hive provocó métricas de experimentación contaminadas, funciones de aprendizaje automático inexactas y paneles ejecutivos defectuosos.

Las comprobaciones de Verity se pueden integrar en un Airflow DAG para garantizar que solo se procesen y almacenen en Hive datos sin procesar de alta calidad como datos derivados.

Los productores y consumidores de datos pueden definir sus controles de calidad de datos y verificarlos cuando se producen o antes de consumirlos internamente. Flujo de aire o Flyte .

…

VerityAirflowOperator se puede usar de forma de bloqueo para detener un DAG en caso de una falla en la verificación, evitando que los datos incorrectos lleguen a producción. Esto utiliza el “ Intercambio de verificación de etapa Patrón: creamos datos en un esquema por etapas, verificamos los datos con un operador de bloqueo y luego los promovemos a producción si pasan los controles de calidad.

Las comprobaciones también se pueden realizar manualmente o programarse automáticamente para verificar los datos sin procesar y los derivados.

Las comprobaciones programadas de Verity están aisladas de cualquier motor de orquestación de datos, por lo que aún se ejecutan incluso si Airflow o Flyte están completamente inactivos. Esto soluciona un problema común de comprobaciones que no alertan porque la tarea Airflow nunca se ejecutó.

Por lo tanto, existen esencialmente tres formas principales de activar una verificación: como parte de un DAG de Airflow, manualmente o programada a través de la plataforma/UI de Verity.

No creo que las comprobaciones actuales puedan integrarse en canales de transmisión en tiempo real (como Flink + Kafka) para validar, por ejemplo, datos cuando ingresan a Hive (o incluso antes).

La implementación de este tipo de verificación en tiempo real permitiría la detección rápida de discrepancias, lo que conduciría a una reducción de los costos de almacenamiento y procesamiento y a una mejora general de la calidad de los datos.

Bueno, para ser más exhaustivos, las comprobaciones de Verity se administran a través de un servidor API, que podría usarse para activar comprobaciones mediante programación a través de algunas API.

Servidor Verity API : este servicio maneja todas las API externas relacionadas con la ejecución de comprobaciones, así como con la persistencia y recuperación de sus resultados. El servidor API no ejecuta ninguna verificación, sino que escribe un mensaje en nuestra cola de verificación, que utiliza Servicio de cola simple (SQS).

Entonces, tal vez podría activar estos trabajos de una manera más en tiempo real, como desde un trabajo de transmisión o incluso, en un largo plazo, integrándolos con la captura de datos de cambios (CDC) de Hive.

Sin embargo, cuando se ejecutan fuera de Airflow, estos trabajos no podrán bloquear el trabajo de procesamiento de datos; en su lugar, generarían alertas asincrónicas enviadas a la cola de verificación. Algunos consumidores preferirían que se retrasara el procesamiento de datos cuando falla una verificación, mientras que otros preferirían continuar y recibir una alerta.

Ahora, veamos estas pruebas de calidad de datos.

A continuación se muestra un ejemplo que comprueba si rider_events.session_id nunca es nulo. Esto se logra mediante una combinación de componentes de consulta y condición.

 core rider events session_id is not null: # check name metadata: id: 90bde4fa-148b-4f06-bd5f-f15b3d2ad759 ownership_slack: #dispatch-service-dev tags: [rides, core-data, high-priority] query: type: dsl data_source_id: hive.core.rider_events filters: - session_id = null condition: type: fixed_threshold max: 0 notifier_group: pagerduty_policy: dispatch-service email: [email protected]

Verity se centra principalmente en definir y hacer cumplir controles de calidad de los datos en lugar de definir esquemas de datos completos.

La validación de esquemas no es un concepto novedoso. Existen varios métodos para definir esquemas de datos de eventos en sistemas basados en eventos, como JSON Schema, Protocol Buffers, Avro o formatos de almacenamiento como Parquet. La elección óptima depende de su pila tecnológica, su uso y sus requisitos específicos.

Si bien los esquemas de datos son valiosos para definir la estructura general de los objetos de datos o las filas de las tablas, no logran capturar comprobaciones de validación más sofisticadas y específicas para los consumidores, como la distribución de datos, las reglas comerciales, los SLA y los umbrales.

Los contratos de datos van más allá de la validación de esquemas, que se centra en identificar errores sintácticos . Personalmente, encuentro que JSON Schema ofrece aquí una opción más adecuada y legible, separando efectivamente estas capacidades de validación estructural y sintáctica de las preocupaciones de serialización o almacenamiento.

Sin embargo, para abordar los errores semánticos y mejorar la precisión de los datos, contar con un medio eficaz para definir las verificaciones de datos permite definir la otra faceta de los contratos de datos.

Aquí es donde entra en juego Verity DSL.

Más allá de la validación semántica, los contratos de datos ofrecen otro aspecto crucial que merece atención.

Desde un punto de vista sintáctico, las comprobaciones de validación siguen siendo consistentes independientemente del consumidor o productor involucrado. El conjunto de reglas de validación no está vinculado a ningún consumidor o productor específico y puede definirse de una vez por todas como un esquema único.

Sin embargo, el contrato de datos DSL de Verity ofrece una granularidad más fina que define pequeñas reglas independientes, lo que es particularmente adecuado para este contexto: el significado semántico y el uso de los datos varían dependiendo del consumidor específico. Además, no todos los consumidores necesitan utilizar todas las propiedades de un objeto. Sus expectativas difieren. Esto no implica que sean contradictorios (lo que ciertamente sería un problema), sino más bien complementarios y distintos.

Por lo tanto, es crucial permitir que todos los consumidores establezcan reglas únicas que, cuando se combinan de manera colaborativa, puedan proporcionar una comprensión integral de la importancia semántica de la calidad de los datos.

Y es este aspecto colaborativo el que me resuena particularmente. Tengan paciencia, esto puede parecer exagerado, pero desde mi perspectiva, vale la pena mencionarlo. :)

El intercambio de datos permite que diferentes equipos (productores y consumidores) colaboren de forma eficaz. Establecer una comprensión compartida de estos intercambios de datos es primordial, al igual que las API en el desarrollo de software tradicional. En las arquitecturas de microservicios, ha surgido un enfoque de prueba colaborativo conocido como contratos impulsados por el consumidor (CDC), donde los consumidores definen el comportamiento esperado de las API proporcionadas por los productores. Los productores son responsables de verificar estos contratos antes de lanzar nuevas versiones.

Creo que los contratos de datos comparten un espíritu colaborativo similar. Aunque la validación de datos se realiza con datos reales, en lugar de en el momento de la publicación, y no bloquea las publicaciones, se basa en la cooperación y fomenta el trabajo en equipo entre los productores y consumidores de datos. Creo firmemente que este enfoque colaborativo es clave para mejorar la calidad de los datos y debería integrarse aún más en el proceso.

Bueno, soy un gran admirador de establecer paralelos...

De hecho, tenga en cuenta que este aspecto colaborativo es algo que también se menciona como parte de la carta de verdad de Lyft.

VerityUI proporciona una experiencia de descubrimiento de datos optimizada a través de la página de inicio de Verity. Nuestra búsqueda de texto completo en los metadatos de definición de cheques permite a los usuarios ver todos los controles que se aplican actualmente y sus resultados. Esto tiene agregaciones útiles como equipo propietario, nombre de tabla y etiquetas.

No tengo del todo claro cómo se comparten los problemas del contrato de datos entre consumidores y productores a través de la interfaz de usuario de la plataforma Verity, pero definitivamente reconozco la importancia de la colaboración a través de los paneles:

• El productor de una interfaz de producto de datos puede asegurarse con confianza de que no está provocando inadvertidamente interrupciones posteriores que no había previsto.

• El consumidor de la interfaz puede estar seguro de que su confianza en la interfaz no está ni estará comprometida.

Si bien Verity es una herramienta extraordinaria para definir controles de calidad de datos, lamentablemente no es de código abierto.

Afortunadamente, existe otro marco de calidad de datos de código abierto llamado Soda Core que proporciona una funcionalidad similar.

Soda Core es una herramienta de línea de comandos y una biblioteca de Python gratuita y de código abierto que permite a los ingenieros de datos probar la calidad de los datos. Utiliza entradas definidas por el usuario para generar consultas SQL que ejecutan comprobaciones en conjuntos de datos en una fuente de datos para encontrar datos no válidos, faltantes o inesperados. Cuando las comprobaciones fallan, aparecen los datos que usted definió como "malos" en la verificación.

Durante el análisis de un conjunto de datos, Soda Core evalúa las comprobaciones predefinidas para identificar datos no válidos, faltantes o inesperados.

Aquí está la verificación equivalente usando la sintaxis de Soda.core para la prueba Verity DSL que se definió previamente.

 name: rider_events_session_id_check source: hive query: SELECT * FROM rider_events WHERE session_id IS NULL; raise_alert: true threshold: 10 action: slack message: "There are more than 10 rows that are null for the 'session_id' property in the 'rider_events' table. Please investigate this issue."

 soda run --check checks/rider_events_session_id_check.yaml

Soda Core es una poderosa herramienta para garantizar la calidad de sus datos. Puede ayudarle a identificar y solucionar problemas de datos de forma temprana, antes de que puedan causar problemas a su empresa.

Vale la pena señalar que Soda Core también puede facilitar las comprobaciones de calidad de los datos para la transmisión de datos al integrarse perfectamente con Spark DataFrames.

Si bien las comprobaciones de calidad de datos de Verity para Hive se aplican a conjuntos de datos estáticos, las comprobaciones de datos en streaming deben ser más ligeras y eficientes.

Los datos normalmente se procesarían en pequeños lotes de eventos, con una latencia muy baja, lo que los hace adecuados para comprobaciones en tiempo real y casos de uso específicos como la detección de anomalías.

Por último, mencionar que existen otras herramientas de validación de datos disponibles, como DeeQu, Great Expectations,…

A medida que concluimos, espero que tenga una comprensión más clara de los pasos que puede seguir para mejorar su viaje hacia la calidad de los datos.

Hemos visto dos enfoques distintos para mejorar la calidad de los datos, cada uno con sus propias fortalezas y metodologías. Uno se centra en aumentar la visibilidad y la observabilidad, motivando a los productores de datos a elevar el nivel de calidad. El otro prioriza elevar el estándar de calidad a través de un enfoque de prueba y validación primero. Ambos son complementarios.

Verity no es simplemente un lenguaje de dominio específico (DSL) para definir comprobaciones de datos; es una plataforma centralizada que permite a los profesionales de datos colaborar de forma eficaz. Esta plataforma ayuda a productores y consumidores a alinearse con las expectativas de calidad de los datos, incluido el formato, la estructura y la precisión.

Las capacidades de gestión de contratos de datos de Verity podrían (¿están?) mejorar aún más mediante la integración con un conjunto más amplio de funciones, como la gestión y el descubrimiento de metadatos, para abordar necesidades de calidad de datos más sofisticadas.

De manera similar a la puntuación DQ de Airbnb, Verity de Lyft fomenta un ciclo de retroalimentación colaborativa entre productores y consumidores de datos. Al incentivar y empoderar a cada equipo para que se haga cargo de la calidad de los datos, Verity cultiva un entorno de apoyo donde la calidad de los datos mejora continuamente.

¿Encontró útil este artículo? Sígueme en LinkedIn , tarde-hack , y Medio ! ¡Por favor 👏 este artículo para compartirlo!