Améliorer la qualité des données : explorer les contrats de données avec Lyft

On dirait que c'est la deuxième partie de ma série sur la qualité des données !

Dans un article précédent , j'ai exploré la stratégie d'Airbnb visant à améliorer la qualité des données grâce à des incitations. Ils ont mis en œuvre un score unique et des critères de notation clairs pour établir une compréhension commune entre les producteurs de données et les consommateurs, favorisant ainsi un véritable sentiment d'appropriation.

Désormais, Lyft adopte une approche distincte, ne tentant pas la même chose différemment, mais se concentrant plutôt sur différents aspects de la qualité des données. Et la stratégie de Lyft complète les efforts d'Airbnb. Même si je considère le score DQ d'Airbnb (ou tout autre score similaire) comme un moyen efficace de consolider diverses tentatives visant à améliorer la qualité des données, Lyft aborde ce défi sous un angle différent.

Le score DQ d'Airbnb constitue un outil précieux pour fournir une visualisation concrète de la qualité des données. Essentiellement, toute initiative visant à améliorer la qualité des données devrait avoir un impact perceptible sur ce score. D'un autre côté, Lyft présente une initiative possible pour améliorer de manière proactive la qualité en testant et en validant les données par rapport à des critères de qualité spécifiques.

Fondamentalement, il s’agit d’un point différent dans le cycle de vie de la qualité des données. L’introduction d’un mécanisme visant à améliorer la qualité nécessite la capacité de la mesurer initialement.

Ainsi, alors que Airbnb se concentre sur la mesure et l'observation de la qualité des données, en s'appuyant sur l'intérêt du producteur à améliorer cette qualité et à « bien paraître », Lyft adopte une approche différente. Lyft met l'accent sur le test et la validation actifs de la qualité des données, offrant ainsi aux producteurs et aux consommateurs les moyens d'améliorer et de contrôler efficacement la qualité.

Collectivement, ces approches fournissent une stratégie globale pour traiter et améliorer la qualité des données tout au long de leur cycle de vie .

Pour cette raison, j'étais particulièrement intéressé à examiner de plus près l'approche de Lyft.

Un autre facteur qui m'a intrigué est le test, plus particulièrement le test sous contrat, utilisé depuis de nombreuses années maintenant dans l'ingénierie logicielle de base avec l'émergence de l'architecture des microservices. Les contrats de données, cependant, sont quelque chose de plus récent dans le domaine de l’ingénierie des données et sont considérés comme le summum ou l’une des étapes ultimes à mettre en place sur la voie de la création de pipelines de données de haute qualité. C'est pourquoi j'ai voulu examiner l'approche de Lyft plus en détail et explorer quelques parallèles potentiels.

Comme mentionné, les approches adoptées par Airbnb et Lyft sont complémentaires et visent le même objectif : améliorer la qualité des données.

Airbnb a développé le score DQ, qui se concentre sur la mesure et l'amélioration de 4 aspects distincts de la qualité des données :

DQ Score a des principes directeurs, notamment une couverture complète, l'automatisation, l'actionnabilité, la multidimensionnalité et l'évolutivité. Il comporte des dimensions telles que la précision, la fiabilité, l’intendance et la convivialité.

Verity de Lyft est une plateforme conçue pour améliorer la qualité des données dans 5 dimensions

Définit la qualité des données comme la mesure de la manière dont les données peuvent être utilisées comme prévu, couvrant des aspects tels que l'exactitude sémantique, la cohérence, l'exhaustivité, l'unicité, la bonne forme et l'actualité .

Il est facile de faire des parallèles entre les 5 aspects de la qualité des données améliorés par Verity de Lyft et les 4 dimensions de la qualité des données mesurées par le score DQ d'Airbnb. Par exemple, des aspects tels que l'actualité contribueraient certainement à la fiabilité du score DQ, tandis que l'exactitude dépendrait de l'exactitude sémantique, de l'exhaustivité et de l'unicité des données. Le score d’utilisabilité, quant à lui, est influencé par la cohérence des données, entre autres facteurs.

Verity de Lyft se concentre sur la définition des contrôles liés à l'exactitude sémantique, à la cohérence, à l'exhaustivité, à l'unicité, à la bonne formation et à l'actualité . Il suit une approche de test et de validation, tandis que le score DQ unifié d'Airbnb met l'accent sur l'évaluation de la qualité des données à travers diverses dimensions.

Si nous voulions intégrer le score DQ dans ce dernier schéma, ce serait du côté des étapes Alerte/Débogage.

Le score DQ d'Airbnb utilise différents signaux pour évaluer la qualité des données sous les aspects d'exactitude, de fiabilité, d'intendance et d'utilisabilité .

Nous disposions également d'un ensemble de signaux d'entrée qui mesuraient plus directement la qualité (certification Midas, validation des données, bugs, SLA, contrôles DQ automatisés, etc.), tandis que d'autres ressemblaient davantage à des indicateurs de qualité (par exemple, propriété valide, bonne hygiène de gouvernance, l'utilisation d'outillage de chemin pavé).

Comme indiqué précédemment, il existe probablement des chevauchements entre le score DQ d'Airbnb et celui de Verity. Alors qu'Airbnb s'efforce de pousser la qualité des données vers la droite, en mettant l'accent sur la mesure et la notation, Verity de Lyft adopte une approche proactive en déplaçant les configurations de définition des contrôles, les tests et les processus de validation vers la gauche, en mettant l'accent sur l'amélioration proactive de la qualité des données.

Désormais, mon principal intérêt se situe à gauche, dans les aspects de configuration de la définition des contrôles, de tests et de validation.

Comment Lyft intègre les tests de qualité des données dans ses processus ?

Examinons d'abord les chemins d'exécution.

Actuellement, Verity de Lyft se concentre principalement sur la garantie de la qualité des données stockées dans son entrepôt de données Hive. Cependant, il est prévu d'étendre ses capacités pour prendre en charge d'autres sources de données à l'avenir.

Notez que même s'ils qualifient Hive d'atelier de données, ils l'utilisent en fait comme une solution de stockage de données hybride, fonctionnant comme un entrepôt de données pour les données structurées, traitées et nettoyées (couche d'argent) tout en servant également de lac de données pour les événements bruts. données (couche de bronze).

La mauvaise qualité des données dans Hive a entraîné des mesures d'expérimentation entachées, des fonctionnalités d'apprentissage automatique inexactes et des tableaux de bord exécutifs défectueux.

Les contrôles de Verity peuvent être intégrés dans un DAG Airflow pour garantir que seules les données brutes de haute qualité sont traitées et stockées dans Hive en tant que données dérivées.

Les producteurs et les consommateurs de données peuvent définir leurs contrôles de qualité des données et vérifier les données lorsqu'elles sont produites ou avant qu'elles ne soient consommées en interne. Flux d'air ou Flyte .

…

Le VerityAirflowOperator peut être utilisé de manière bloquante pour arrêter un DAG en cas d'échec de la vérification, empêchant ainsi les mauvaises données d'atteindre la production. Cela utilise le « Stage-Check-Echange " : nous créons des données dans un schéma par étapes, vérifions les données avec un opérateur de blocage, puis les promouvons en production si elles réussissent les contrôles de qualité.

Les contrôles peuvent également être effectués manuellement ou planifiés automatiquement pour vérifier à la fois les données brutes et dérivées.

Les vérifications planifiées Verity sont isolées de tout moteur d'orchestration de données, elles s'exécutent donc toujours même si Airflow ou Flyte sont complètement en panne. Cela résout un problème courant de vérifications qui n'émettent pas d'alerte car la tâche Airflow n'a jamais été exécutée.

Il existe donc essentiellement 3 manières principales de déclencher une vérification : dans le cadre d'un DAG Airflow, manuellement ou planifiée via la plate-forme/l'interface utilisateur Verity.

Je ne crois pas que les contrôles actuels puissent être intégrés dans des pipelines de streaming en temps réel (tels que Flink + Kafka) pour valider par exemple les données lorsqu'elles entrent dans Hive (ou même avant).

La mise en œuvre de ce type de contrôle en temps réel permettrait une détection rapide des écarts, entraînant une réduction des coûts de stockage et de traitement et une amélioration globale de la qualité des données.

Eh bien, pour être complet, les contrôles Verity sont gérés via un serveur API, qui pourrait être utilisé pour déclencher des contrôles par programme via certaines API.

Verity API Server — Ce service gère toutes les API externes concernant l'exécution des vérifications ainsi que la persistance et la récupération de leurs résultats. Le serveur API n'exécute aucune vérification, mais écrit plutôt un message dans notre file d'attente de vérification, qui utilise SimpleQueueService (SQS).

Ainsi, vous pourriez peut-être potentiellement déclencher ces tâches de manière plus en temps réel, par exemple à partir d'une tâche de streaming ou même, sur une longue période, en intégrant la capture de données modifiées Hive (CDC).

Cependant, lorsqu'elles sont exécutées en dehors d'Airflow, ces tâches ne pourront pas bloquer la tâche de traitement des données ; au lieu de cela, ils généreraient des alertes asynchrones transmises à la file d'attente de contrôle. Certains consommateurs préféreraient que le traitement des données soit retardé en cas d'échec d'un contrôle, tandis que d'autres préféreraient continuer et recevoir une alerte.

Examinons maintenant ces tests de qualité des données.

Voici un exemple qui vérifie si rider_events.session_id n'est jamais nul. Ceci est accompli grâce à une combinaison de composants de requête et de condition.

 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 concentre principalement sur la définition et l'application de contrôles de qualité des données plutôt que sur la définition de schémas de données complets.

La validation de schéma n'est pas un concept nouveau. Il existe plusieurs méthodes pour définir des schémas de données d'événements dans les systèmes basés sur des événements, tels que JSON Schema, Protocol Buffers, Avro ou des formats de stockage comme Parquet. Le choix optimal dépend de votre pile technologique, de votre utilisation et de vos exigences spécifiques.

Même si les schémas de données sont utiles pour définir la structure globale des objets de données ou des lignes de tableaux, ils ne parviennent pas à capturer des contrôles de validation plus sophistiqués spécifiques aux consommateurs, tels que la distribution des données, les règles métier, les SLA et les seuils.

Les contrats de données vont au-delà de la validation de schéma, qui se concentre sur l'identification des erreurs syntaxiques . Personnellement, je trouve que JSON Schema offre ici une option plus adaptée et plus lisible, séparant efficacement ces capacités de validation structurelle et syntaxique des problèmes de sérialisation ou de stockage.

Cependant, pour remédier aux erreurs sémantiques et améliorer l’exactitude des données, disposer d’un moyen efficace de définition des contrôles de données permet de définir l’autre facette des contrats de données.

C'est là que Verity DSL entre en jeu.

Au-delà de la validation sémantique, les contrats de données offrent un autre aspect crucial qui mérite attention.

D'un point de vue syntaxique, les contrôles de validation restent cohérents quel que soit le consommateur ou le producteur impliqué. L'ensemble des règles de validation n'est lié à aucun consommateur ou producteur spécifique et peut être défini une fois pour toutes comme un schéma unique.

Cependant, le contrat de données Verity DSL offre une granularité plus fine définissant de petites règles indépendantes, particulièrement bien adaptée à ce contexte : la signification sémantique et l'usage des données varient en fonction du consommateur spécifique. De plus, tous les consommateurs n’ont pas besoin d’utiliser toutes les propriétés d’un objet. Leurs attentes diffèrent. Cela ne veut pas dire qu’ils sont contradictoires (ce qui poserait certainement problème), mais plutôt complémentaires et distincts.

Par conséquent, il est crucial de permettre à tous les consommateurs d’établir des règles uniques qui, lorsqu’elles sont combinées de manière collaborative, peuvent fournir une compréhension globale de la signification sémantique de la qualité des données.

Et c’est cet aspect collaboratif qui me touche particulièrement. Soyez indulgents avec moi, cela peut sembler exagéré, mais de mon point de vue, cela vaut la peine de le mentionner. :)

L'échange de données permet à différentes équipes (producteurs et consommateurs) de collaborer efficacement. Établir une compréhension commune de ces échanges de données est primordial, tout comme les API dans le développement de logiciels traditionnels. Dans les architectures de microservices, une approche de test collaboratif connue sous le nom de contrats axés sur le consommateur (CDC) a émergé, dans laquelle les consommateurs définissent le comportement attendu des API fournies par les producteurs. Les producteurs sont responsables de vérifier ces contrats avant de publier de nouvelles versions.

Je pense que les contrats de données partagent un esprit de collaboration similaire. Même si la validation des données est effectuée sur des données réelles, plutôt qu'au moment de la publication, et ne bloque pas les diffusions, elle repose sur la coopération et encourage le travail d'équipe entre les producteurs et les consommateurs de données. Je crois fermement que cette approche collaborative est essentielle pour améliorer la qualité des données et devrait être davantage intégrée au processus.

Eh bien, je suis un grand fan des parallèles…

Notez en effet que cet aspect collaboratif est également mentionné dans la charte de vérité de Lyft.

VerityUI offre une expérience de découverte de données rationalisée via la page d'accueil de Verity. Notre recherche en texte intégral sur les métadonnées de définition des contrôles permet aux utilisateurs de voir tous les contrôles actuellement appliqués et leurs résultats. Cela contient des agrégations utiles telles que l'équipe propriétaire, le nom de la table et les balises.

Je ne suis pas tout à fait clair sur la manière dont les problèmes de contrat de données sont partagés entre les consommateurs et les producteurs via l'interface utilisateur de la plateforme Verity, mais je reconnais certainement l'importance de la collaboration via les tableaux de bord :

• Le producteur d'une interface de produit de données peut s'assurer en toute confiance qu'il ne provoque pas par inadvertance des pannes en aval qu'il n'avait pas anticipées.

• Le consommateur de l'interface peut être assuré que sa confiance dans l'interface n'est pas et ne sera pas compromise.

Bien que Verity soit un outil remarquable pour définir des contrôles de qualité des données, il n'est malheureusement pas open source.

Heureusement, il existe un autre framework open source de qualité des données appelé Soda Core qui offre des fonctionnalités similaires.

Soda Core est un outil de ligne de commande gratuit et open source et une bibliothèque Python qui permet aux ingénieurs de données de tester la qualité des données. Il utilise une entrée définie par l'utilisateur pour générer des requêtes SQL qui exécutent des vérifications sur des ensembles de données dans une source de données afin de rechercher des données invalides, manquantes ou inattendues. Lorsque les vérifications échouent, elles font apparaître les données que vous avez définies comme « mauvaises » dans la vérification.

Lors de l'analyse d'un ensemble de données, Soda Core évalue les vérifications prédéfinies pour identifier les données invalides, manquantes ou inattendues.

Voici la vérification équivalente utilisant la syntaxe Soda.core pour le test Verity DSL précédemment défini.

 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 est un outil puissant pour garantir la qualité de vos données. Il peut vous aider à identifier et à résoudre rapidement les problèmes de données, avant qu'ils ne puissent causer des problèmes à votre entreprise.

Il convient de noter que Soda Core peut également faciliter les contrôles de qualité des données pour le streaming en s'intégrant de manière transparente à Spark DataFrames.

Alors que les contrôles de qualité des données de Verity pour Hive sont appliqués aux ensembles de données statiques, les contrôles des données en streaming doivent être plus légers et efficaces.

Les données sont généralement traitées par petits lots d'événements, avec une latence très faible, ce qui les rend adaptées aux contrôles en temps réel et aux cas d'utilisation spécifiques comme la détection d'anomalies.

Mentionnons enfin qu’il existe d’autres outils de validation de données disponibles, comme DeeQu, Great Expectations,…

Alors que nous terminons, j'espère que vous comprenez mieux les étapes que vous pouvez suivre pour améliorer votre parcours de qualité des données.

Nous avons vu deux approches distinctes pour l'amélioration de la qualité des données, chacune avec ses propres atouts et méthodologies. L’une se concentre sur l’augmentation de la visibilité et de l’observabilité, en motivant les producteurs de données à élever la barre de qualité. L’autre donne la priorité à l’élévation du niveau de qualité grâce à une approche axée sur les tests et la validation. Les deux sont complémentaires.

Verity n'est pas simplement un langage spécifique à un domaine (DSL) pour définir des contrôles de données ; il s'agit d'une plate-forme centralisée qui permet aux praticiens des données de collaborer efficacement. Cette plateforme aide les producteurs et les consommateurs à s'aligner sur les attentes en matière de qualité des données, notamment le format, la structure et l'exactitude.

Les capacités de gestion des contrats de données de Verity pourraient (sont ?) encore améliorées en s'intégrant à un ensemble plus large de fonctionnalités, telles que la gestion et la découverte des métadonnées, pour répondre à des besoins plus sophistiqués en matière de qualité des données.

Semblable au score DQ d'Airbnb, Verity de Lyft favorise une boucle de rétroaction collaborative entre les producteurs de données et les consommateurs. En incitant et en donnant à chaque équipe les moyens de s'approprier la qualité des données, Verity cultive un environnement favorable où la qualité des données s'améliore continuellement.

Vous avez trouvé cet article utile ? Suivez-moi sur Linkedin , Hacker-midi , et Moyen ! S'il vous plaît 👏 cet article pour le partager !