Gayathri Thiyagarajan

[00:00:06] Bonjour à tous. Bienvenue à ma conférence sur l'assurance qualité des données à grande échelle. Il s'agira d'une étude du maillage de données en pratique. Avant de commencer, je tiens à remercier Flowcon de m'avoir donné cette opportunité et de m'avoir invité à parler de ce sujet aujourd'hui. Je ferai une brève introduction sur ce qu'est la qualité des données, pourquoi j'en parlerai en particulier, puis je passerai à ce qu'est le data mesh, et les défis qu'il introduit, particulièrement quand on le fait à l'échelle, mais aussi quelles sont les opportunités et les défis quand on le fait à l'échelle. Je suis Gathi Harajan, je suis responsable d'ingénierie senior chez Expedia Group, basé au Royaume-Uni. Je suis une conférencière publique. J'ai donné de nombreuses conférences sur le sujet des principes de conception axée sur le domaine. J'ai réalisé quelques projets depuis 2015, alors que je travaillais pour une autre société de conseil basée au Royaume-Uni. Mais j'ai rejoint Expedia il y a environ quatre ans, et depuis, j'ai géré de nombreux produits de données où j'ai eu l'occasion de faire des brainstormings et d'appliquer à nouveau les principes DDD de manière inattendue. Et par extension, c'est à ce moment-là que le concept de maillage de données a commencé à évoluer, j'ai donc eu l'occasion de le pratiquer également, à mesure qu'Expedia, en tant qu'organisation, grandissait. J'en parlerai plus en détail un peu plus tard. J'ai également publié des blogs, des articles et des témoignages. Je suis une grande évangéliste du DDD et je n'ai pas besoin d'excuse pour le pratiquer, si l'occasion se présente.
[00:01:50] Je pensais que cette diapositive n'aurait peut-être pas beaucoup de sens pour cet auditoire, mais ayant vu qu'il y a pas mal de conférences sur le DDD au programme, j'ai pensé la laisser. Étant donné que je vais beaucoup parler de données et d'ingénierie des données, j'ai pensé qu'il fallait avertir sur le langage et la sémantique que j'allais utiliser. Donc ici, quand je dis pipeline, je ne parle pas du pipeline CICD que nous utilisons pour livrer du code. Je vais faire référence aux pipelines d'ingénierie des données et aux pipelines de données. Et quand je parle de métriques, je ne parlerai pas de métriques système ou d'application, mais de métriques très similaires dans le contexte des données, où nous profilons les données, j'en parlerai plus tard. De même, les vérifications ne sont pas des vérifications de la qualité du code, mais plutôt des vérifications de la qualité des données. Et enfin, l'application est juste l'application partout.
[00:02:48] Alors, comment cela a-t-il commencé?
[00:02:51] Expedia, si vous ne le savez pas, est une combinaison de plusieurs marques, parmi les plus célèbres figurent Expedia, Hotels.com ou VBO, qui est la branche de location de vacances du groupe Expedia. Auparavant, ils opéraient tous de manière assez indépendante, mais récemment, Expedia a traversé une transformation au niveau organisationnel. Où nous avons commencé à regrouper les produits non pas en fonction des marques, mais à les aligner en fonction de leurs domaines. Il s'agissait principalement de supprimer la duplication qu'avait introduite l'alignement au niveau de la marque. Mais aussi, nous voulions profiter de cette occasion pour optimiser notre pile, apporter de la cohérence à notre infrastructure de plateforme d'exécution, du mode d'interaction des clients au fonctionnement de nos applications. Mais pendant que nous faisions cela, il était naturel d'étendre cela aux données, ce qui, jusqu'à ce moment-là, était plus ou moins une réflexion après coup. Et j'ai eu beaucoup d'expérience où nous raclions des données en cours de route, euh, des requêtes de navigateur envoyées au backend, les équipes ne se souciant pas de la façon dont les données allaient être appliquées ou utilisées. Mais à mesure que nous avons commencé à aligner les produits de données par domaines également, cela a entraîné un changement de mentalité où l'équipe a commencé à considérer les données comme faisant partie de leurs équipes produit. C'est à peu près ce qu'est le concept de maillage de données. Nous le verrons bientôt. C'était il y a environ trois ans, à peu près au moment où Zamak de Thought Works a écrit un article de blog sur l'architecture du maillage de données sur le site web de Martin Fowler.
[00:04:54] Cela correspondait assez bien à ce que nous essayions de faire. Nous avons donc commencé à adopter certains des principes qu'elle a énoncés dans cet article en développant des capacités de plateforme de données centralisées pour le streaming, le lac de données, le stockage de données, etc.
[00:05:14] Mais en faisant cet alignement par domaines plutôt que par marques, l'échelle à laquelle nous traitions les données, les produits, est devenue beaucoup plus grande, au moins trois fois. Nous avons donc dû adapter nos capacités en conséquence. Dans ce contexte, un écart est apparu. Nous n'avions donc pas la capacité d'évaluer la qualité des données capturées, en particulier à cette échelle. Nous produisions donc beaucoup de produits de données, nous migrions et expédions les produits déjà existants, mais nous n'avions aucune idée de la qualité des données, ni de leur fiabilité.
[00:06:00] Alors, en bref, qu'est-ce que la qualité des données ? À quoi me réfère-je lorsque j'utilise ce terme ?
[00:06:09] Comme vous le savez, ces derniers temps, en particulier, les données sont le moteur de toute entreprise axée sur les données, et pratiquement toutes les entreprises veulent être axées sur les données. Qu'est-ce que cela signifie ? Ainsi, les organisations axées sur les données sont celles où les données sont essentielles à chaque décision et constituent chaque partie de l'organisation. Elles sont donc utilisées pour obtenir des informations et prendre des décisions commerciales à partir des données. Il est donc très important que cela soit fiable, digne de confiance et fiable. Pourtant, vous seriez surpris d'apprendre que de nombreuses organisations ne disposent pas d'un outil central leur permettant de surveiller les données qu'elles collectent réellement, XPGA inclus, jusqu'à récemment.
[00:06:56] Il n'y a donc aucune garantie ou validation effectuée à ce sujet. Les gens se fient aveuglément à ce qui a été capturé et utilisent ce qu'ils peuvent obtenir, ce qui est mieux que rien.
[00:07:10] Du côté des ingénieurs, en particulier des ingénieurs de données, si vous pensez à l'impact que pourrait avoir une mauvaise qualité de données, c'est que vous auriez des pipelines de données cassés.
[00:07:20] Vous êtes réveillé au milieu de la nuit avec un problème de priorité 1, mais vous devez remonter jusqu'à la source des données pour identifier ce qui a provoqué la panne du pipeline. Et puis, une fois que vous avez identifié, vous devrez retraiter, nettoyer les données et les rendre utilisables. Ce n'était pas une petite tâche.
[00:07:46] Par conséquent, une capacité ou plusieurs capacités dans certains cas étaient nécessaires pour fournir des données fiables et dignes de confiance.
[00:07:57] Une qualité élevée des données était sans aucun doute importante pour toute organisation qui avait besoin d'analyses de données perspicaces et fiables, et pour prendre des décisions significatives basées sur les données.
[00:08:14] Par conséquent, vous avez besoin d'un outil ou d'une capacité qui mesure et vous donne une indication de cette qualité, n'est-ce pas ? Vous avez donc besoin de quelque chose pour collecter ces métriques qui vous donne une évaluation de la qualité des données et de ce que vous pouvez faire si ce n'est pas suffisant.
[00:08:33] C'est ce que Martin Fowler a à faire, a à dire sur ce sujet particulier.
[00:08:41] Dans toute entreprise de taille moyenne ou grande, vous déplacez généralement des milliards d'événements et des centaines de téraoctets de données via des flux Kafka ou des pipelines de données, atterrissant dans des lacs de données, des entrepôts de données, etc. Il y a des données qui circulent quelque part, à tout moment. Imaginez faire fonctionner des systèmes distribués à grande échelle et des microservices dont nous parlons beaucoup ces jours-ci, mais sans aucune métrique opérationnelle pour surveiller leur état de santé. C'est une pensée assez effrayante à cet âge, n'est-ce pas ? Mais pourquoi devrions-nous faire fonctionner des centaines de pipelines de données, sans avoir de métriques pour savoir s'ils fonctionnent bien, s'ils se cassent, et si oui, pourquoi, ou du moins avoir une sorte d'alerte ou de surveillance sur eux. Il est donc nécessaire de le faire de manière centralisée, ce qui est incontestable, mais aussi à grande échelle.
[00:09:42] Et c'est également important car vous devez fournir de la transparence et de la confiance sur les métriques calculées sur ces données, car les données possédées seront consommées par une autre partie de l'organisation. Vous avez donc besoin que cela soit fait de manière centralisée et d'une manière qui soit visible par toutes les parties concernées.
[00:10:05] Comment ces problèmes de qualité ont-ils tendance à se manifester ? Voyons quelques exemples que j'ai tirés de nos systèmes de production et qui apparaissent généralement dans notre canal de support.
[00:10:20] Je ne sais pas si c'est assez visible. Je vais juste passer rapidement là-dessus.
[00:10:29] Donc, si vous ne les voyez pas, ce sont quelques-uns des problèmes qui sont apparus, en particulier dans nos données de flux de clics, qui sont capturées. Le flux de clics est en fait un très bon exemple de l'impact de données de mauvaise qualité. Les flux de clics sont traditionnellement capturés par plusieurs équipes, ce qui donne une qualité de données variable entre ces équipes, et ils sont également consommés par une multitude d'équipes, que ce soit pour l'apprentissage automatique pour la personnalisation, en temps réel, ou pour l'analyse hors ligne, le marketing, vous l'appelez, le flux de clics est utilisé quelque part dans votre organisation.
[00:11:14] Donc, naturellement, vous pouvez vous attendre à toutes sortes de problèmes, et si quelque chose se produit, il y a beaucoup de cris, euh, qui en sortent, généralement l'équipe qui possède ces données, c'est-à-dire l'équipe de flux de clics, se fait réprimander. Mais ce ne sont que des causes profondes, n'est-ce pas ? La conséquence n'est pas immédiatement évidente. Vous pourriez donc avoir des perturbations de pipeline ou des pannes de pipelines de données. Parfois, des fonctionnalités sont construites au-dessus de ces données. Nous avons une fonctionnalité appelée recherches récentes qui repose sur le fait qu'un client effectue une recherche et que ces données sont disponibles presque en temps réel, de sorte que lorsque vous retournez à la page d'accueil, vous voyez ce que vous avez recherché. Donc, vous pouvez imaginer que si quelque chose ne va pas avec ces données, les clients ne le voient pas. Cela se manifeste directement par une mauvaise expérience client. Les prédictions sont incorrectes ou non pertinentes, et ainsi de suite.
[00:12:15] Mais en même temps, il est important de différencier les problèmes de qualité d'une dérive légitime des données.
[00:12:24] Parce qu'évidemment, les habitudes des clients changent. Le COVID est un bon exemple, ou s'il y a une conférence comme celle-ci et que les gens affluent, évidemment, vous voyez qu'il y a un pic dans les habitudes des clients ou un changement dans les habitudes des clients. Il faut donc savoir quand cela se produit par rapport au moment où les données sont réellement anormales. Ainsi, globalement, ces problèmes de qualité relèvent de quelques catégories.
[00:12:56] La première est les données incomplètes. Ainsi, tous les pipelines de données et les applications de streaming s'attendent à un certain niveau d'exhaustivité des données pour que celles-ci soient considérées comme utilisables.
[00:13:13] Les données incomplètes signifient que ces processus, les processus de données, ne peuvent pas réellement traiter ces données, ils devront donc les ignorer ou arrêter complètement le pipeline lorsque la quantité de données inutilisables dépasse un certain seuil. En conséquence, vous devrez retraiter, et nous parlons de millions et de millions de données, en particulier avec le traitement par lots de données, vous obtenez généralement une journée de données pour des raisons de marketing. Et de la part de tiers, vous finissez donc par retraiter ces données une fois que vous avez identifié et résolu le problème ou nettoyé les données. Cela représente évidemment beaucoup de puissance de calcul et un retard dans la disponibilité des données finales pour utilisation. Si vous pensez aux flux, qui sont une disponibilité des données en temps réel, le retraitement n'est pas du tout une tâche simple. Dans la plupart des cas, il est impossible, ou presque, de retraiter les données une fois qu'elles ont traversé votre flux Kafka. Et, euh, si vous prenez certains domaines comme la finance ou la fiscalité, même une petite quantité de données incomplètes n'est tout simplement pas acceptable car vous ne pourriez pas effectuer de rapprochement avec ces données.
[00:14:31] La deuxième classification ou catégorie est les données incorrectes. Donc, normalement, cela signifie que les données violent un certain modèle attendu, et cela peut entraîner une mauvaise gestion de celles-ci par les processus s'ils ne savent pas ce qui est une donnée incorrecte, invalide. Vous pourriez donc avoir cela directement reflété dans l'entraînement de l'apprentissage automatique, qui, s'il est entraîné avec des données incorrectes, affecte la prédiction ou la personnalisation, les fonctionnalités de votre site web, ce serait incorrect.
[00:15:08] Mais aussi, les données sont utilisées pour des choses comme la performance du produit, vous faites des visites uniques par utilisateur, ou des visiteurs uniques, des comptes de visites, et ainsi de suite. Donc toutes ces métriques seraient peu fiables si les données sont invalides.
[00:15:30] Données tardives, je suis sûr que beaucoup de gens peuvent s'y rapporter immédiatement. Les données ne sont pas immédiatement disponibles pour votre cas d'affaires ou votre objectif. Cela pourrait arriver si votre pipeline en amont est interrompu ou cassé, pour diverses raisons, il n'y a pas suffisamment de données complètes disponibles ou le pipeline a été arrêté pour d'autres raisons et il doit être retraité, et ainsi de suite. Mais aussi, avec un flux, cela signifie que vos applications qui dépendent de ces données de flux en temps réel peuvent manquer des SLA et des SLO sans que ce soit de votre faute.
[00:16:13] Donc la dernière catégorie, ici, est celle où il y a une différence entre la source et la destination. Cela se rapporte directement à la perte de données en transit, et encore une fois, dans de nombreuses organisations, il n'y a aucun moyen de mesurer directement cela si vous n'avez pas une capacité dédiée qui le fait.
[00:16:37] Alors, comment mesurons-nous la qualité des données ? Tout cela contribue à la façon dont nous le faisons à grande échelle en tant que capacité centrale, comme le recommande le maillage de données. Mais avant d'examiner la mise en œuvre réelle d'une solution, nous devons comprendre les concepts de qualité des données.
[00:16:56] Ainsi, la qualité des données est souvent un principe d'adéquation à l'usage, elle y est normalement associée, ce qui renvoie à la subjectivité et à la dépendance contextuelle de ce sujet. Donc, ce qui est une donnée de bonne qualité pour votre cas d'utilisation, pourrait ne pas être suffisant pour une autre application.
[00:17:15] C'est aussi généralement un concept multidimensionnel, vous avez donc diverses dimensions qui représentent ce qu'est une bonne qualité de données, telles que l'exactitude ou l'actualité, qui peuvent être directement liées à certaines des catégories que nous venons de voir.
[00:17:30] Et une métrique de qualité des données est une fonction qui mappe ces dimensions de qualité, par exemple, l'actualité à une métrique qui calcule ce qu'est une latence. Donc, habituellement, la dimension est une fonction de cette métrique. Et vous pouvez agréger ces métriques de qualité des données à différents niveaux, vous pourriez donc les avoir au niveau de la colonne, au niveau de l'attribut, ou au niveau de l'ensemble de données, selon la dimension que vous calculez et dans quel but.
[00:18:05] Je vais passer rapidement là-dessus. Je ne pense pas que la formule mathématique soit super intéressante, mais si vous voulez jeter un coup d'œil, les diapositives seront partagées après. L'exhaustivité, qui est directement liée aux problèmes de données incomplètes. C'est l'une des dimensions clés de la qualité des données. Cela décrit généralement l'étendue, la profondeur et la portée des informations contenues dans les données. Elle couvre également la condition que les données doivent exister pour être complètes, ce qui signifie que les valeurs nulles ou les lignes complètement manquantes seraient également attribuées à cette dimension.
[00:18:46] Le deuxième est l'exactitude. Ce qui décrit la proximité entre le système d'information qui capture et stocke les données et ce que représente le monde réel. C'est une dimension importante de la qualité des données, évidemment, tout le monde veut des données précises pour ses besoins, mais c'est aussi assez difficile car comment quantifier objectivement ce qui existe dans le monde réel ? Mais parfois, on utilise une métrique qui est suffisamment proche de ce qui existe dans le monde réel pour calculer l'exactitude. Donc, l'exactitude n'est pas toujours exacte.
[00:19:26] Il n'y a donc pas de moyen objectif de mesurer cela. Par exemple, la corrélation inter-ensembles de données entre vos données de flux de clics et votre système de commande. Ainsi, le nombre de clics sur le bouton de commande, par exemple, ou l'affichage réussi d'une page après la réservation devrait correspondre au nombre de commandes saisies dans le système ou aux annulations, et vice-versa. C'est donc une bonne façon de comparer deux ensembles de données différents et de calculer la précision de l'un ou de l'autre. suffisamment proche de ce qui existe dans le monde réel pour calculer la précision. La précision n'est pas toujours précise. Il n'y a donc pas de moyen objectif de mesurer cela. Par exemple, la corrélation entre les ensembles de données, la corrélation entre les données de flux de clics et votre système de commande. Donc, le nombre de clics sur le bouton de commande, par exemple, ou l'affichage réussi de la page après la réservation devrait correspondre au nombre de commandes saisies dans le système ou aux annulations, et vice-versa. C'est donc un bon moyen de comparer deux ensembles de données différents et de calculer la précision de l'un ou de l'autre.
[00:20:01] Le troisième est la cohérence. Cela capture la violation des règles sémantiques définies sur ces éléments de données. Ceci capture la violation des règles sémantiques définies sur ces éléments de données. Il peut donc s'agir de tuples ou d'enregistrements dans un fichier. L'intégrité référentielle est un bon exemple. Il s'agit donc normalement de règles qui nécessitent une certaine connaissance du domaine, et la violation de ces règles est capturée par cette dimension.
[00:20:31] La dernière est la pertinence, comme mentionné précédemment, c'est une fonction de la latence en tant que métrique par exemple. Alors, quelle est l'actualité des données que nous avons et que nous utilisons à nos fins. C'est aussi lié à la notion de volatilité, c'est-à-dire à quelle vitesse ces données deviennent-elles non pertinentes ou obsolètes.
[00:20:57] Il existe d'autres dimensions de qualité des données, selon la littérature à laquelle vous vous référez. La fraîcheur et la validité sont incluses dans certains cas. Mais à des fins générales, ces quatre sont normalement suffisantes.
[00:21:15] Avant de passer au concept de maillage de données. Je veux prendre un moment pour souligner la complexité ici, en particulier lorsque nous décrivons la qualité des données, car je l'ai mentionné brièvement. Les métriques de qualité des données ont des qualités subjectives et objectives associées. Qu'est-ce que cela signifie? Les dimensions que nous avons vues : exhaustivité, exactitude, actualité et l'autre était la cohérence. Ce sont donc des dimensions dites dures. Ce sont des mesures de qualité ou de qualités objectives. Celles-ci n'ont pas tendance à changer selon qui les utilise et qui observe ces dimensions. Et cela peut être fait avec très peu de connaissances du domaine, à part quelques dimensions. Mais il existe aussi des dimensions douces qui nécessitent une évaluation subjective. Elle nécessite donc, elle est très dépendante du contexte, elle nécessite beaucoup de connaissances du domaine pour évaluer ces dimensions. Par exemple, si vous construisez une application qui utilise une base de données SQL et que vous voulez exécuter ou calculer la qualité des données en fonction de la complétude d'une certaine colonne. Ou une certaine colonne étant présente conditionnellement à une autre colonne, ce qui est très spécifique aux besoins de votre application, ce qui peut ne pas définir la qualité des données pour une autre équipe, un autre domaine ou un autre produit. Qui pourrait utiliser le même magasin de données. La duplication est un autre exemple. Cela peut être dans les deux sens, donc un critère de duplication, ce qui constitue un doublon, peut être différent d'une autre application qui examine les mêmes données.
[00:23:12] Ce diagramme, j'espère, explique ce concept facilement. Pour n'importe quel ensemble de données, il y a généralement
[00:23:20] deux, voire trois acteurs différents associés à ces données. Le premier est évidemment, à gauche, les producteurs qui génèrent les données. Et cela peut être plus d'une équipe, il peut s'agir de producteurs externes, de tiers, vous nommez, cela peut être n'importe qui produisant ces données. Et l'intégration de ces données dans votre organisation. Ils s'entendent normalement sur un contrat appelé schéma dans la plupart des cas, et leur responsabilité est de produire des données qui respectent ce contrat. Et ils envoient les données à une fréquence attendue.
[00:23:58] Et puis à l'extrême droite se trouvent les consommateurs qui construisent des applications, des pipelines de traitement.
[00:24:05] Qui utilise les données ou qui se contente de regarder les données comme un tableau et d'effectuer des analyses fréquemment.
[00:24:13] Donc, ces groupes de personnes sont normalement à la réception de tous les problèmes de qualité des données et ils devront, dans le système traditionnel, constamment courir après les produits de données ou les producteurs ou les propriétaires pour savoir Pourquoi une certaine analyse ne semble pas tout à fait correcte ou une certaine donnée nécessite plus de nettoyage avant de pouvoir être utilisée pour entraîner un modèle, et ainsi de suite.
[00:24:35] Et enfin, au milieu se trouvent les propriétaires de données qui possèdent, maintiennent et supportent les données. Ce n'est pas toujours le cas où les producteurs de données sont séparés des propriétaires de données.
[00:24:47] Mais là où il y a une multitude de propriétaires, cela nécessite normalement une équipe centrale qui possède ces données et peut garantir que les données sont constamment disponibles si quelque chose ne va pas, l'équipe s'en occupe et ainsi de suite.
[00:25:05] Donc, comme vous pouvez le voir, selon qui vous êtes et quel est votre but, la qualité subjective change. Pour un producteur, tant que vous correspondez au schéma ou que vous cochez tous les champs obligatoires et facultatifs et que vous envoyez les données assez fréquemment ou à la fréquence attendue, vous avez passé vos contrôles de qualité. Mais pour un consommateur, cela doit être suivi et respecté avec diligence, assuré. Et pour les propriétaires aussi, car ils ont des SLA et des SLO à respecter, qui ne peuvent être manqués.
[00:25:45] Après avoir abordé la notion de qualité des données, reprenons ce concept.
[00:25:51] Parce que tout a commencé par l'identification d'un besoin d'avoir une capacité centrale qui assure la qualité des ensembles de données que nous avions chez Expedia jusqu'à où nous en étions à ce moment-là. L'architecture des données a évolué avec le temps, nous avons eu des lacs de données, des entrepôts de données et ainsi de suite. Mais au cours des deux dernières années, un concept particulier a suscité beaucoup d'intérêt, évidemment, mais a aussi radicalement changé la façon dont les données sont perçues par les organisations. Et avec ce concept qui gagne de plus en plus de terrain, les données sont maintenant considérées comme un citoyen de première classe plutôt que comme une pensée après coup. Alors, qu'est-ce que c'est?
[00:26:44] Comme Max, quand elle a écrit l'article de blog, elle a mentionné Data Mesh comme une architecture. Mais si vous regardez son livre ou ses récentes éditions de l'article de blog, elle appelle cela une approche socio-technique. C'est une approche socio-technique décentralisée pour l'approvisionnement, la gestion et l'accès aux données.
[00:27:07] Principalement à des fins analytiques, mais vous pouvez l'utiliser pour n'importe quel cas d'utilisation à grande échelle.
[00:27:15] Alors, que recommande le maillage de données? Il recommande des limites bien définies pour ceux d'entre vous qui sont familiers avec les principes de conception axée sur le domaine, en particulier le contexte limité, peuvent s'y rapporter davantage. Où vous avez des limites bien définies autour de vos produits. Cela étend donc ce concept pour inclure également les produits de données, là où auparavant cela existait en dehors. Vous encapsulez donc toutes les applications et les données qu'elles produisent et les encapsulez dans des limites. Ainsi, les propriétaires de produits qui possèdent ces produits de domaine possèdent également les produits de données et les données qu'ils produisent et consomment. Ainsi, en cours de route, lorsque ce principe de maillage de données a été de plus en plus mis en pratique, lorsqu'il a été transformé en une application de cette architecture dans les entreprises, il a mis en évidence quelques défis et lacunes qui existaient à ce moment-là. Ce qui était le manque de capacité à découvrir, comprendre, et plus important encore, faire confiance et utiliser des données de bonne qualité.
[00:28:22] Quel était donc l'objectif de Data Mesh? L'accent est mis ici sur la réalisation de cela à grande échelle. Car en décentralisant les produits de données et en les plaçant au sein de chacun de ces domaines, la mise à l'échelle devient soudain un problème. Alors, comment décentralisez-vous les données, tout en fournissant une capacité plus centralisée ou une collection ou une suite de capacités qui peuvent traiter, gérer ces données, prendre des producteurs du côté gauche, si vous vous souvenez de ce diagramme, jusqu'au côté droit pour que les consommateurs les consomment. L'échelle couvre donc ici plusieurs choses. L'un est le changement dans le paysage des données, donc le paysage a évolué pour avoir beaucoup plus de frameworks, d'outils, alors qu'avant nous ne pensions même pas au streaming. Il y a de plus en plus d'adoption de flux et de flux Kafka ces jours-ci et il y a Pulsar et d'autres technologies de streaming qui apparaissent également. Il y a une prolifération de producteurs et de consommateurs de données avec l'IoT et, vous savez, les données sont presque de la poussière d'or en ce moment, vous ne voulez pas, vous voulez en capturer autant que vous pouvez utiliser ou même plus. Il y a aussi une diversité dans la transformation et le traitement et la vitesse de réponse au changement. Vous voulez que les organisations réagissent à ce changement de données, à ce changement de modèles de clients immédiatement et efficacement.
[00:29:55] Ainsi, toute implémentation de maillage de données, comme nous voulions le faire chez Expedia, devrait incarner ces principes. N'oubliez pas que nous construisons cela à grande échelle. Et c'est typiquement ce que nous cherchions, nous cherchions trois fois l'échelle avant de commencer. Ainsi, il devrait fournir des garanties de qualité et d'intégrité nécessaires pour rendre ces données utilisables. Il devrait être décentralisé. La propriété du domaine passe aux propriétaires de produits, aux données en tant que produit, à la plateforme de données en libre-service et aux capacités de gouvernance fédérée. Car en décentralisant, ce n'est pas une seule personne qui possède les données ou en est responsable, mais vous avez une collection de propriétaires qui doivent être tenus responsables de la façon dont ils traitent les informations d'identification personnelle (PII), les informations PCI, etc.
[00:30:53] Donc, pour en revenir au concept de qualité des données que nous avons vu, où cela s'intègre-t-il dans l'architecture de maillage de données ?
[00:31:03] Ainsi, la propriété de la qualité des données en particulier a été décalée vers la gauche pour être plus proche des producteurs de données. Ainsi, les produits de domaine et les propriétaires de produits possèdent les données. Ainsi que de garantir la qualité des données et d'en être responsable. Il préconise donc des capacités de plateforme centrale qui fonctionnent à grande échelle.
[00:31:26] Non pas pour un seul type de source de données, comme nous venons de le mentionner, il y a un changement dans la façon dont les données sont stockées de nos jours, vous avez des bases de données NoSQL, SQL, tant de technologies de streaming, des lacs de données sur le cloud et d'autres fournisseurs de cloud et ainsi de suite. Votre outil devrait donc pouvoir prendre en charge toutes ces piles. Mesures subjectives et objectives de la qualité des données et une méthode bien établie et transparente de mesure de celles-ci afin qu'elles puissent être surveillées de manière centralisée.
[00:32:06] Alors, qu'est-ce que cela signifie de construire une telle capacité à grande échelle?
[00:32:13] La qualité des données est donc un vaste domaine. Donc, normalement, quand on parle de qualité des données, comme c'était le cas hier soir, quelqu'un m'a interrogé sur la gouvernance, alors oui, dès que vous commencez à parler de ces métriques et dimensions, beaucoup de concepts commencent à émerger et ils ont tous un certain niveau de similitude, de sorte que vous penseriez que la qualité des données couvrirait tout cela. Mais lorsque vous vous lancez dans une construction à grande échelle, vous ne voulez pas encore plus de complexité que ce que vous avez déjà à gérer. Donc normalement, ils ont tendance à couvrir des choses comme le monitoring, comment mesurer ces métriques ? Et ensuite les traduire en dimensions. Comment notifier les problèmes de qualité des données à temps et presque en temps réel ? La lignée, donc évidemment les pipelines, les pipelines de données en particulier, sont enchaînés, et vous voulez savoir, vous voulez tracer tout le chemin depuis la source jusqu'à toutes les transformations qui se sont produites entre les deux, jusqu'à l'endroit où votre application commence à consommer.
[00:33:16] Évidemment, l'auto-remédiation est un résultat très désiré lorsque vous repérez un problème de qualité des données, vous ne voulez pas seulement être alerté, vous voulez que cela soit corrigé et corrigé rapidement. L'analyse des causes profondes, les métriques KPI et les métriques de qualité du système peuvent également être ajoutées à ce mélange. Mais quoi que ce soit, vous savez, ce que signifie la qualité des données pour vous, assurez-vous simplement que lorsque vous résolvez cela à grande échelle, la portée en est bien définie.
[00:33:56] Alors, qu'est-ce qu'un outil de surveillance de la qualité des données efficace, prenant en compte ces exigences dans une certaine mesure et rejetant probablement certaines d'entre elles comme étant hors de portée, en tant que capacité centrale, un outil de surveillance de la qualité des données efficace Devrait contenir, avant tout, une définition standardisée pour votre organisation de ce que signifient ces dimensions et métriques. Parce que vous ne traitez plus avec des équipes ou des produits individuels où vous pouvez créer votre propre définition et la partager uniquement avec vos consommateurs, vous avez besoin d'une méthode standardisée pour définir cette qualité des données, car vous traitez avec tous les domaines de votre organisation.
[00:34:40] Prise en charge de différentes sources de données. Évidemment, presque en temps réel, car s'il y a un problème, vous voulez le savoir presque dès que vous recevez ces données.
[00:34:53] Alerte, notification, que ce soit via Slack, PageDuty ou tout autre système de gestion d'incidents utilisé par votre équipe, cela doit être intégré à nouveau au niveau de l'équipe. Mesurer et rendre cela disponible de manière centralisée et transparente. Vous pourriez également utiliser la notation au niveau de l'ensemble de données afin de pouvoir créer une fonction à partir des dimensions de qualité des données et calculer un score qui montre et, espérons-le, encourage de meilleures pratiques sur la façon dont ces données sont capturées et stockées au sein de l'organisation. Surveillance et suivi des tendances au fil du temps et une expérience client simple et intuitive.
[00:35:39] Il existe déjà des offres pour la qualité des données, donc avant de nous lancer dans la construction centralisée. Mais cela souligne également la maturité de Data Mesh telle qu'elle est aujourd'hui. Même si en tant que concept, c'est brillant, cela a du sens, presque intuitif. Mais la maturité des outils disponibles n'est tout simplement pas là. Par exemple, il existe de nombreuses versions open source ainsi que sous licence qui vous permettent de faire cela, mais elles comportent toutes des limitations qui peuvent ou non convenir à votre organisation. Mais il est toujours bon de regarder ce qui existe avant de commencer à construire le vôtre.
[00:36:27] Mais avant de commencer à faire notre propre travail, nous avons évidemment consulté nos parties prenantes pour voir ce qu'elles avaient déjà mis en place. Il y avait beaucoup d'options maison, tout le monde n'était pas aussi aveugle que certains d'entre eux.
[00:36:45] Mais les options variaient du rudimentaire, où ils avaient des vérifications intégrées dans leur code ou ils faisaient des échantillons de données et ensuite exécutaient des vérifications, au plus sophistiqué mais très adapté à leur propre équipe, ce qui ne peut pas évoluer, ce qui n'est pas adapté à quiconque en dehors de leur équipe. Ils n'avaient pas la capacité ou la bande passante pour maintenir et supporter cela correctement car cela ne faisait pas partie de leur offre de produits principale. Et ainsi de suite. Certaines équipes n'avaient aucune idée qu'il y avait des problèmes avec leurs pipelines de données avant que cela ne se produise ou du moins quelques jours après que cela se soit produit et que quelqu'un d'autre ne leur crie dessus. Aucun de ces éléments n'était donc idéal pour que nous puissions le déployer à l'échelle que nous envisagions. Je veux donc juste donner rapidement une approche que nous avons utilisée pour ceux d'entre vous qui sont intéressés par la façon dont nous avons résolu ce problème.
[00:37:53] Donc, ce que nous avons fait, c'est que la capacité de plateforme que nous avons construite comportait quatre étapes. La première consistait donc à ingérer les données, l'ingestion. Le second était le profilage. Le troisième était les vérifications, le processus réel qui exécutait les vérifications sur les données. Et cela s'est appliqué à toutes les sources de données, à tout. Et le dernier était la notification. Sous-tendant tout cela, il y avait la configuration que nous avons capturée auprès de nos clients, si vous vous souvenez. L'analyse subjective requiert les connaissances et les contributions de diverses équipes de domaine pour nous dire ce qu'elles veulent en termes de vérifications qui pourraient être effectuées sur un ensemble de données qui les intéresse.
[00:38:37] Alors, qu'est-ce que l'ingestion signifie, comment avons-nous réalisé cela à grande échelle? Simplement en ne construisant pas tout nous-mêmes. Nous avons internalisé tous les composants pour diverses bases de données et autres piles technologiques au fur et à mesure que le besoin s'en faisait sentir. Nous avons construit les plugins pour l'ingestion de flux et de lacs de données, qui étaient des ensembles de données plus couramment utilisés, largement utilisés dans notre organisation. Mais pour Mongo ou Cassandra, nous n'avons pas construit tous ces adaptateurs d'ingestion nous-mêmes, mais nous avons plutôt invité les équipes à contribuer afin de ne pas nous enliser dans toutes les piles technologiques que nous devons prendre en charge. Mais en même temps, nous offrons cette option de diversité à nos clients.
[00:39:31] Nous avons donc fini par utiliser cette pile technologique pour prendre en charge l'ingestion des données. a construit les plugins pour ingérer des flux et des données comme ce qui était plus couramment utilisé, des ensembles de données largement utilisés dans notre organisation. Mais pour Mongo ou Cassandra, nous n'avons pas construit tous ces adaptateurs d'ingestion nous-mêmes. Mais nous avons plutôt invité les équipes à contribuer afin que nous ne soyons pas submergés par toutes les piles technologiques que nous devons prendre en charge. Mais en même temps, offrir cette option de diversité pour nos clients.
[00:39:32] Nous avons donc fini par utiliser cette pile technologique pour prendre en charge l'ingestion des données.
[00:39:43] Le suivant est le profilage. Pour moi, c'est la partie fondamentale de la façon dont vous pouvez exécuter une offre de qualité des données à grande échelle. Il ne s'agit pas d'exécuter ces vérifications directement sur l'ensemble de données brutes, comme le faisaient certaines équipes, ce qui était bien au niveau de leur équipe. Mais il n'y avait aucun moyen de passer à l'échelle car nous devions en savoir beaucoup plus sur leurs données que nous ne le voulions. Ainsi, le profilage signifie que vous collectez des métriques sur les données brutes qui sont pertinentes pour nous afin d'identifier les problèmes de qualité des données. Par exemple, nous collections des métriques telles que le nombre de lignes que les données contenaient, le nombre de champs manquants dans l'ensemble de données, ou au niveau des lignes, combien de champs étaient remplis, combien de valeurs nulles il y avait, des histogrammes, la cardinalité d'un champ particulier, la latence, quelle était la distribution, quelle était la taille des données, et nous avons également calculé une distribution statistique sur chacun des champs, quel est le minimum, le maximum, la médiane, le mode, la moyenne, l'écart-type et ainsi de suite. Nous calculons donc autant de métriques que possible. Un très bon effet secondaire de ce processus est qu'il était assez indépendant de notre objectif, qui était de résoudre les problèmes de qualité des données ou de pouvoir mesurer la qualité des données. Vous pouvez utiliser ce profilage pour l'analyse exploratoire des données, ce que beaucoup de scientifiques des données et d'ingénieurs en apprentissage automatique utilisent de nos jours, avant de commencer à utiliser une donnée particulière pour leur modélisation. Et vous pouvez également l'utiliser pour calculer un score de qualité des données ou utiliser des métriques dérivées, par exemple, vous pouvez faire un ratio de ces métriques pour calculer le ratio de duplication et ainsi de suite. C'est donc infini, les possibilités de ce que vous pouvez faire, comment vous pouvez l'utiliser.
[00:41:49] Le suivant était les vérifications. Donc toutes ces étapes étaient complètement découplées et asynchrones, et nous avons utilisé des flux pour la sortie et l'entrée de chaque étape. Les vérifications allaient de l'exécution de simples vérifications de seuil à l'utilisation de réseaux neuronaux sophistiqués pour la détection d'anomalies sur ces métriques de profil. Plus de détails plus tard, la partie détection d'anomalies était particulièrement difficile.
[00:42:21] Mais cela signifie que c'est là qu'intervient la subjectivité de la qualité des données en tant que concept. Vous devez donc être capable de capturer et d'exécuter plusieurs vérifications sur les mêmes données et parfois plusieurs vérifications pour le même champ et attribut. Le coût d'exécution de cela à grande échelle est donc beaucoup plus élevé. Et si vous calculez la permutation et la combinaison, vous examinez l'ensemble de données, le niveau de ligne, de champ, multiplié par le nombre de métriques que vous calculez, puis vous exécutez les vérifications sur plusieurs vérifications sur les métriques résultantes également.
[00:43:03] Une chose importante que nous avons faite a été de "manger notre propre nourriture pour chiens". Donc, comme je l'ai mentionné, nous avions découplé chacun de ces processus. Nous avons donc exécuté des vérifications sur nos propres métriques de qualité des données que nous calculions, les métriques de profil. Nous saurions ainsi quand une partie de notre système était cassée, mais nous saurions également à quel point les calculs ou la détection d'anomalies étaient précis pour prédire tout problème.
[00:43:33] Donc finalement, la notification, comme je l'ai mentionné, dépend vraiment de ce qui fonctionne le mieux pour les équipes de domaine. Et vous voulez pouvoir prendre en charge la façon dont ces équipes sont mises en place pour gérer les incidents, et être informé lorsqu'il y a un incident. Et vous voulez pouvoir également rapporter sur ces incidents, ainsi que sur toute remédiation qui suit et toute gestion des incidents et analyse des causes profondes qui se produit après cela.
[00:44:07] Donc les deux dernières diapositives ici. Je veux juste résumer quelle était l'opportunité de faire cela à grande échelle. Comme je l'ai mentionné, le data mesh en tant que principe est très évident, a beaucoup de sens, mais il vient avec la complexité inhérente de faire cela à grande échelle. Il y a une raison pour laquelle Zamak a transformé cela d'une architecture en un principe sociotechnique décentralisé, car ce n'est pas seulement une implémentation technique. Cela nécessite une réorganisation de vos équipes, cela nécessite un support d'outillage, cela nécessite le support de l'organisation pour construire ces capacités à grande échelle ou du moins trouver et acheter des produits qui peuvent vous aider à l'implémenter. Cela dit, j'ai une diapositive qui parle des défis. J'ai probablement brûlé les étapes là. Les opportunités sont bien plus nombreuses. Premièrement, cela crée de la transparence et de la confiance au niveau de l'organisation. J'ai donc dirigé des équipes de produits de données où les analystes et l'équipe marketing n'étaient pas vraiment sûrs des données capturées, même en interne. Nous avons donc dû nous appuyer sur des bibliothèques tierces pour collecter des données fiables comme Adobe Analytics ou Google Analytics. Mais telle était la méfiance envers les données déjà présentes dans l'organisation ou dans le lac de données. Il récompense les pratiques de données plus propres, car vous pouvez calculer le score, le rendre visible dans votre catalogue de données, et dire à quel point cet ensemble de données est utilisable. Vous pouvez utiliser le rouge, le vert, l'orange pour mettre en évidence l'utilisabilité des données dans leur ensemble.
[00:46:06] Et cela a étendu et promu la collaboration de la plateforme. Comme je l'ai mentionné, nous avons invité de nombreuses contributions, nous n'avons donc pas construit tout cela par nous-mêmes, nous avons juste construit le cœur. Mais tout le reste était enfichable et extensible. Nous avons rendu les métriques de profil disponibles, par exemple, pour que les scientifiques des données puissent les utiliser pour effectuer leur analyse exploratoire des données, même s'ils ne se soucient pas de la qualité des données, ce qu'ils font. Et enfin, et ce n'est pas le moindre, les métadonnées réutilisables dont je viens de parler.
[00:46:44] Donc rapidement, certains des défis que je n'ai pas abordés jusqu'à présent. Encore une fois, à grande échelle, atteindre cette fiabilité n'est pas un petit défi ou un mince exploit. Vous avez besoin de la normalisation, de la définition, vous avez besoin que toutes les parties prenantes soient d'accord sur ce que cela signifie pour elles. Nous avons passé des mois à élaborer la définition, en partenariat avec la gouvernance des données, afin que tout le monde soit satisfait de ce que nous avons défini comme ces dimensions, ce qui n'était pas tout à fait la même chose que la définition industrielle, par exemple. Nous devons donc nous adapter, personnaliser et rendre cela visible également. L'ingénierie pour différents types d'ingestion a été un grand défi car le flux versus le lot, même s'ils gèrent tous deux des données à grande échelle, du Big Data. Ce sont des bêtes complètement différentes. Les flux Kafka sont un ensemble de données illimité par rapport à des données par lots, la façon dont elles sont partitionnées, dont elles sont consommées, dont elles sont même créées, est très différente de la façon dont vous diffusez des données. Donc construire cela même pour le type de données le plus couramment utilisé n'était pas facile. Nous avons dû adopter une pile technologique différente, allant à l'encontre de notre meilleur jugement, mais nous avons dû le faire. Le troisième point est la détection d'anomalies. Évidemment, lorsque vous construisez cela comme une capacité centrale, vous construisez un outil de détection d'anomalies qui doit apprendre et détecter les problèmes de qualité sur plusieurs ensembles de données. Donc, même si nous capturons des métriques de profil, il y a un certain niveau de connaissance que ces modèles ont besoin de ces données, qui pourrait varier d'un ensemble de données à l'autre, des données les plus fréquentes aux données moins fréquentes, si vous ne prenez qu'une seule métrique comme le nombre d'événements. Donc la prédiction pourrait varier en fonction des métriques que vous avez utilisées pour entraîner ces données. Nous avons donc dû travailler un peu pour faire fonctionner ce modèle. Ce n'était donc certainement pas une solution miracle que vous pouvez appliquer à toutes les métriques et exécuter tous les types de vérifications. Nous avons donc dû être très sélectifs quant à l'endroit où cela apporterait le plus de valeur à nos clients. Principalement parce que, premièrement, il était physiquement impossible d'exécuter tous ces différents modèles sur tous les ensembles de données tout le temps. Mais deuxièmement, il y avait certaines vérifications qui étaient bien connues des clients, ils savaient exactement ce qu'ils voulaient. Donc, une simple vérification de seuil ou une vérification de motif basée sur des rejets, ferait l'affaire, donc nous n'avions pas du tout besoin de détection d'anomalies dans ce cas. C'était plutôt pour les cas où la tendance était saisonnière que nous en avions besoin. Et évidemment, fournir des mesures subjectives et objectives, et enfin, personnaliser notre produit pour offrir une bonne expérience client était un autre défi.
[00:49:48] Euh, cela conclut, euh, je manque de temps, donc je ne vais pas entrer dans les détails. Euh, si vous êtes intéressé d'en lire un peu plus, euh, voici quelques liens vers des livres blancs et un article de Zamak. Il y a aussi un livre. Euh, si vous êtes intéressé à lire, euh, et d'autres éléments que j'avais rassemblés et auxquels j'ai fait référence dans ma présentation.
[00:50:16] Merci.

Transcription (Traduit)