Le lignage des données, une visualisation automatisée des relations sur la façon dont les données circulent entre les tables et d’autres actifs de données, est un incontournable dans la boîte à outils d’ingénierie des données.
Non seulement il est utile pour les cas d’utilisation de la gouvernance et de la conformité des données, mais il joue également un rôle de premier plan en tant que l’un des cinq piliers de l’observabilité des données. Le lignage des données accélère la capacité d’un ingénieur de données à comprendre la cause première d’une anomalie de données et l’impact potentiel qu’elle peut avoir sur l’entreprise.
En conséquence, la popularité de la lignée de données en tant que composant incontournable des outils de données modernes a explosé plus rapidement qu’un lycéen dont les parents voyagent hors de la ville pour le week-end. En conséquence, presque tous les catalogues de données ont introduit la lignée des données au cours des dernières années. Plus récemment, certains fournisseurs de cloud de Big Data, tels que Databricks et Google (dans le cadre de Dataplex), ont annoncé des capacités de lignage des données.
C’est formidable de voir que tant de leaders dans le domaine, comme Databricks et Google, réalisent la valeur de la lignée pour les cas d’utilisation à travers la pile de données, de la gouvernance des données à la découverte.
Mais maintenant qu’il existe plusieurs solutions offrant une certaine saveur de lignage des données, la question se pose : « doit-elle toujours être une fonctionnalité requise dans une solution de qualité des données ? »
La réponse est un « oui » sans équivoque. Lorsqu’il s’agit de s’attaquer à la fiabilité des données, la lignée vanille ne suffit pas. Voici pourquoi…
1. La lignée des données informe sur la détection et l’alerte des incidents
Le lignage des données améliore la détection et l’alerte des incidents de qualité des données lorsqu’il est intégré de manière native dans une plate-forme d’observabilité des données.
Par exemple, imaginons que vous rencontriez un problème avec une table en amont qui se répercute sur plusieurs autres tables sur plusieurs couches en aval. Souhaitez-vous que votre équipe reçoive une alerte ou souhaitez-vous en recevoir 15, toutes pour le même incident ?
La première option décrit avec précision le contexte complet avec un point naturel pour commencer votre analyse des causes profondes. La deuxième option revient à recevoir 15 pages d’un livre en panne et à espérer que votre ingénieur de données sur appel est capable de reconstituer qu’ils font tous partie d’une seule histoire.
En fonction de l’observabilité des données, la lignée des données reconstitue automatiquement cette histoire, identifiant celle qui est le point culminant et celles qui entrent en action.
Sans oublier que trop d’alertes superflues constituent le moyen le plus rapide d’alerter sur la fatigue, définie scientifiquement comme le moment où l’ingénieur de données roule des yeux, secoue la tête et passe à une autre tâche. Ainsi, lorsque votre canal de gestion des incidents dans Slack contient plus de 25 messages non lus, correspondant tous au même incident, tirez-vous vraiment de la valeur de votre plateforme d’observabilité des données ?
Une façon d’aider à lutter contre la fatigue des alertes et d’améliorer la détection des incidents consiste à définir des paramètres d’alerte pour vous informer uniquement des anomalies avec vos tableaux les plus importants. Cependant, sans lignage des données natives, il est difficile et long de comprendre quels actifs sont vraiment importants.
L’une des clés de l’opérationnalisation de l’observabilité des données est de s’assurer que les alertes sont acheminées vers les bons intervenants, ceux qui comprennent le mieux le domaine et les systèmes particuliers en question. Le lignage des données peut aider à faire remonter et à acheminer les alertes vers les propriétaires appropriés, tant du côté de l’équipe des données que des parties prenantes de l’entreprise.
2. La lignée des données accélère la résolution des incidents
Les ingénieurs de données sont en mesure de réparer plus rapidement les pipelines brisés et les données anormales lorsque le lignage des données est intégré de manière native dans la plate-forme d’observabilité des données. Sans cela, vous avez juste une liste d’incidents et une carte des dépendances table/champ, dont aucune n’est particulièrement utile sans l’autre.
Sans incidents intégrés dans la lignée, ces points ne sont pas connectés, et ils ne sont certainement pas connectés à la façon dont les données sont consommées au sein de votre organisation. Par exemple, la traçabilité des données est essentielle au processus de triage des incidents. Pour massacrer un proverbe, « Si une table rencontre une anomalie, mais que personne n’en consomme les données, vous en souciez-vous? »
Le traçage des incidents en amont sur deux outils différents est un processus disjoint. Vous ne voulez pas simplement nager jusqu’à la table en amont la plus brute ; vous voulez nager jusqu’à la table la plus en amont où le problème est toujours présent.
Bien sûr, une fois que nous arrivons à notre table la plus en amont avec une anomalie, notre processus d’analyse des causes profondes ne fait que commencer. Le lignage des données vous donne où mais pas toujours le Pourquoi. Les équipes de données doivent maintenant déterminer s’il s’agit :
- Un problème de système: Une tâche Airflow n’a pas été exécutée ? Y a-t-il eu des problèmes avec les autorisations dans Snowflake ?
- Un problème de code: Quelqu’un a-t-il modifié une requête SQL ou un modèle dbt qui a tout gâché ?
- Un problème de données: Un tiers nous a-t-il envoyé des données parasites remplies de NULL et d’autres bêtises ?
La lignée des données est précieuse, mais ce n’est pas une solution miracle pour la résolution des incidents. Il est à son meilleur lorsqu’il fonctionne au sein d’un écosystème plus large d’outils de résolution d’incidents tels que la détection de changement de requête, des informations à haute corrélation et la détection de lignes anormales.
3. Un seul panneau de verre
Parfois, les fournisseurs disent que leur solution fournit « un seul panneau de verre » avec un peu trop de révérence robotique et sans suffisamment de réflexion critique sur la valeur fournie. Agréable à regarder mais pas très utile.
Comment j’imagine que certains vendeurs disent, « une seule vitre ».
Dans le cas de l’observabilité des données, cependant, un seul panneau de verre fait partie intégrante de l’efficacité et de l’efficacité de votre équipe de données dans ses flux de travail de fiabilité des données.
J’ai mentionné précédemment la nature décousue du renvoi de votre liste d’incidents à votre carte des incidents de données. Néanmoins, il est important de se rappeler que les pipelines de données s’étendent au-delà d’un environnement ou d’une solution unique. C’est formidable de savoir que les données ont été déplacées d’un point A à un point B, mais vos points d’intégration dépeindront toute l’histoire de ce qui leur est arrivé en cours de route.
Tous les lignages de données ne sont pas créés égaux ; les points d’intégration et la façon dont ceux-ci sont présentés sont parmi les plus grands différenciateurs. Par exemple, êtes-vous curieux de savoir comment les changements dans les modèles dbt ont pu avoir un impact sur la qualité de vos données ? Si une tâche Airflow ayant échoué a créé un problème de fraîcheur ? Si une table alimente un tableau de bord particulier ? Eh bien, si vous tirez parti de la lignée de Dataplex ou de Databricks pour résoudre des incidents dans votre environnement, vous devrez probablement passer un temps précieux à rassembler des informations.
Votre équipe utilise-t-elle à la fois Databricks et Snowflake et a-t-elle besoin de comprendre comment les données circulent sur les deux plates-formes ? Disons simplement que je ne retiendrais pas notre souffle pour cette intégration de si tôt.
4. Le bon outil pour le bon travail
En fin de compte, cette décision se résume aux avantages d’utiliser le bon outil pour le bon travail.
Bien sûr, votre voiture est équipée d’un lecteur de CD, mais il serait assez gênant de rester assis dans votre garage chaque fois que vous souhaitez écouter de la musique. Sans oublier que la qualité sonore ne serait pas aussi élevée et que l’intégration avec le compte Amazon Music ne fonctionnerait pas.
Le parallèle ici est le chevauchement entre l’observabilité des données et les solutions de catalogue de données. Oui, les deux ont des fonctionnalités de lignage des données, mais ils sont conçus dans de nombreux contextes différents.
Par exemple, Google a développé ses fonctionnalités de lignage en gardant à l’esprit les cas d’utilisation de la conformité et de la gouvernance, et Databricks a une lignée pour le catalogage et la qualité dans les environnements Databricks natifs. Ainsi, bien que la lignée des données puisse sembler similaire à première vue – alerte spoiler : le graphique de chaque plate-forme aura des cases reliées par des lignes – la vraie magie se produit avec le double-clic.
Par exemple, avec Databricks, vous pouvez commencer par une vue d’ensemble de haut niveau de la lignée et explorer un flux de travail. (Remarque : il ne s’agirait que de workflows Databricks internes, pas d’orchestrateurs externes.)
Vous pourriez alors voir un échec d’exécution, et un autre clic vous amènerait au code (non illustré).
Le lignage des données Dataplex est similaire avec une représentation montrant les relations entre les ensembles de données :
L’exploration ultérieure qui vous permet d’exécuter une analyse d’impact est utile, mais pour un cas d’utilisation « rapports et gouvernance ».
Une solution d’observabilité des données devrait pousser ces diagrammes de lignage de haut niveau un peu plus loin, jusqu’au niveau BI, qui, comme mentionné précédemment, est essentiel pour l’analyse de l’impact des incidents.
Lors de l’exploration, une solution d’observabilité des données doit fournir toutes les informations affichées dans les deux outils, ainsi qu’un historique complet des requêtes exécutées sur la table, leurs durées d’exécution et les tâches associées à partir de dbt. Les informations clés sur les données telles que les lectures/écritures, les modifications de schéma, les utilisateurs et le dernier nombre de lignes doivent également être affichées.
De plus, les tableaux peuvent être étiquetés (peut-être pour indiquer leur niveau de fiabilité) avec des descriptions peut-être (pour inclure des informations sur les SLA et d’autres informations pertinentes).
Au-delà de la comparaison des interfaces utilisateur de lignage pour un moment, il est important de réaliser également que vous avez besoin d’une vue d’ensemble de haut niveau de la santé de vos données. Un tableau de bord de fiabilité des données, alimenté par des métadonnées de lignage, peut vous aider à optimiser vos investissements dans la qualité des données en révélant vos points chauds, le temps de disponibilité/le respect des accords de niveau de service, le nombre total d’incidents, le délai de résolution par domaine, etc.
Conclusion : obtenez le sundae
Alors que les données sont devenues plus cruciales pour les opérations commerciales, l’espace de données a explosé avec de nombreux outils impressionnants et diversifiés. Il y a maintenant 31 saveurs au lieu de votre tartinade typique de vanille, chocolat et fraise.
Cela peut être aussi difficile pour les ingénieurs de données qu’excitant. Notre meilleur conseil est de ne pas se laisser submerger et de laisser le cas d’utilisation piloter la technologie plutôt que l’inverse. En fin de compte, vous vous retrouverez avec un sundae de crème glacée incroyable, bien que parfois désordonné, avec toutes vos saveurs préférées parfaitement équilibrées.