Liste des 13 problèmes de données les plus courants dans les pipelines (avec des exemples)

La partie la plus délicate de la gestion des pipelines de données est peut-être la compréhension du fantôme dans la machine - les données ex machina, si vous voulez.

Comment résoudre les problèmes de qualité des données ? Il faut d’abord savoir que ce qui distingue les ingénieurs de données remarquables des autres, c’est leur capacité à rechercher la cause racine des problèmes de données. Tout le monde peut réinitialiser le pipeline, hausser le niveau des employés et reprendre le travail. Très peu jouent aux détectives pour résoudre les problèmes, mais c’est ce qu’il faut.

C’est la différence entre être satisfait(e) des causes probables et des causes racines. Les causes proximales sont les choses qui semblent avoir mal tourné, comme une erreur d'exécution. La cause racine est celle qui a causé la cause proximale, et c'est beaucoup plus difficile à déterminer. Parfois, les causes proximales sont les causes profondes, mais c'est rare.

Considérez les causes immédiates comme de simples alertes. Elles vous indiquent qu’un élément dans votre pipeline est une erreur de racine. Si vous l’ignorez, c’est à vos risques et périls, car cette dette de données est aggravée.

Quand il pleut, il pleut à verse, et quand vous avez un problème, vous avez tendance à en avoir plusieurs. Voici les possibilités courantes de problèmes de données immédiates ; ces problèmes ne sont pas mutuellement exclusifs, et la liste est loin d’être exhaustive :

• L'horaire a changé
• Le pipeline a expiré
• Une tâche est bloquée dans la file d’attente
• Une transformation inattendue est survenue
• Une exécution spécifique a échoué (par exemple, elle échoue alors qu’elle démarre)
• L’exécution a été anormalement longue
• Une défaillance de l’ensemble du système s’est produite
• Une erreur de transformation s’est produite
• De nombreuses tâches ont échoué la nuit précédente
• La taille de l'entrée était anormale
• La taille de la sortie était anormale
• Le délai d’exécution était anormal
• Une tâche bloquée de façon inattendue
• Une erreur d’exécution s’est produite

Mais ce n’est pas tout, n’est-ce pas ? Là encore, considérez-les non pas comme des problèmes, mais comme des signaux. Ce sont des événements qui peuvent mal tourner et qui indiquent que quelque chose de plus troublant s’est produit. Beaucoup apparaîtront simultanément.
Une plateforme d’observabilité peut être très utile pour les trier. Elle vous permettra de regrouper les problèmes concomitants afin de mieux les comprendre.

Vous pouvez également regrouper les problèmes en fonction de la dimension de la qualité des données à laquelle ils se rapportent, par exemple l’adéquation, la lignée, la gouvernance ou la stabilité. En regroupant les problèmes de données de cette manière, vous pouvez voir les dimensions dans lesquelles vous rencontrez le plus de problèmes et remettre en contexte ce qui semble être des problèmes isolés.

Évidemment, vous n’êtes pas obligé d’attendre l’échec d’une tâche pour appliquer cette méthode. Databand vous permet d’enquêter a posteriori sur les anomalies (il capture toutes les métadonnées historiques) afin de déterminer ce qui est décontracté et ce qui est simplement corrélé.

C’est ainsi que vous pouvez identifier un problème tel qu’une tâche bloquée parmi une dizaine d’erreurs, et tester une multitude de problèmes pour déterminer que la cause première est probablement un échec du provisionnement du cluster. Et c’est ainsi que vous devez le considérer. Recherchez systématiquement la cause première du problème de données.

Les causes premières représentent le terminus. Elles doivent constituer l’événement initial dans la ligne de causalité (le premier domino, en quelque sorte) et expliquer en grande partie le problème. Si la cause première du problème de données ne se produit pas, aucune des causes immédiates ne devrait se produire non plus. Il existe un lien de causalité direct pour chacun d’entre eux.

Les causes profondes, bien sûr, ne sont pas toujours claires, et les corrélations ne sont pas toujours exactes. Si vous n'êtes pas confiant quant à votre réponse, un moyen probabiliste de déterminer votre véritable score de confiance consiste à tenter cette expérience de pensée : Dites que votre patron vous dit que son équipe mettra tout en avant de votre hypothèse et que personne ne va la vérifier auparavant. il passe en production, et votre nom apparaîtra partout. Si c'est faux, c'est entièrement de votre faute. Quel score de confiance (de 0 à 100) attribueriez-vous à votre hypothèse ? S'il est inférieur à 70, poursuivez votre enquête.

Les problèmes les plus courants liés à la cause première des données sont les suivants :

1. Erreur d’utilisateur : nous allons commencer par les erreurs d’utilisateur, car elles sont courantes. Il se peut que quelqu’un ait saisi un mauvais schéma ou une mauvaise valeur, ce qui signifie que le pipeline ne lit pas les données, ou qu’il ait fait ce qu’il fallait avec des valeurs incorrectes, ce qui entraîne un échec de la tâche.

2. Données mal étiquetées : il arrive que des lignes se déplacent dans un tableau et que les bonnes étiquettes soient appliquées aux mauvaises colonnes.

3. Le partenaire de données a raté une livraison : c’est également très fréquent. Vous pouvez construire un système à toute épreuve, mais vous ne pouvez pas contrôler ce que vous ne pouvez pas voir et si les problèmes de données se trouvent dans les données source, cela entraînera le mauvais comportement des pipelines en parfait état.

4. Il y a un bogue dans le code : cette situation est fréquente lorsqu’une nouvelle version du pipeline est disponible. Vous pouvez vous en rendre compte assez rapidement grâce à un logiciel de gestion des versions tel que Git ou GitLab. Comparez le code de production à une version antérieure et effectuez un test avec cette version précédente.

5. Erreur de données OCR : votre lecteur optique lit mal les données, ce qui génère des valeurs étranges (ou manquantes).

6. Problème de données périmées : Le jeu de données est tellement obsolète qu'il n'est plus valable.

7. Problème de doublons : il arrive souvent qu’un fournisseur ne soit pas en mesure de fournir des données et que le pipeline utilise les données de la semaine précédente.

8. Problème d’autorisation : le pipeline a échoué parce que le système n’était pas autorisé à extraire les données ou à effectuer une transformation.

9. Erreur d’infrastructure : vous avez peut-être dépassé la mémoire disponible ou la limite d’appels d’API, votre cluster Apache Spark ne s’est pas exécuté ou votre entrepôt de données est anormalement lent, ce qui fait que l’exécution se poursuit sans les données.

10. Changements de calendrier : quelqu’un (ou quelque chose) a modifié le calendrier et entraîne une défaillance du pipeline.

11. Jeu de données biaisé : très difficile à trier. Il n’y a pas de bon moyen de le savoir, si ce n’est en effectuant des tests pour voir si les données sont anormales par rapport à un jeu de données réelles comparable, ou en découvrant comment elles ont été collectées ou générées.

12. Échec de l’orchestrateur : votre planificateur de pipeline n’a pas réussi à planifier ou à exécuter la tâche.

13. Fantôme dans la machine (data ex machina) : impossible à savoir. C’est difficile à admettre, mais cela arrive. Le mieux que vous puissiez faire est de vous documenter et d’être prêt pour la prochaine fois, lorsque vous pourrez recueillir davantage de données et commencer à établir des corrélations.

Et puis, bien sûr, il y a une réalité où la cause première n’est pas tout à fait claire. De nombreux éléments sont corrélés et ils sont probablement interdépendants, mais il n’y a pas une seule réponse, et après avoir apporté des modifications, vous avez résolu le problème des données, même si vous ne savez pas comment.

Dans ces cas-là, comme dans tous les autres, notez votre hypothèse dans le journal et, lorsque vous pouvez y revenir, continuez à tester les données historiques et restez à l'affût de nouveaux problèmes et de causes plus explicatives.

La caractéristique qui distingue le plus l’ingénieur en traitement de données amateurs de l’expert est sa capacité à trier les causes première et sa facilité à gérer des réponses ambiguës. Les causes immédiates sont parfois des causes premières, mais pas toujours. Les causes premières sont parfois corrélées à des causes immédiates spécifiques, mais pas toujours. Parfois, il n’est pas possible de faire la distinction entre le biais des données et l’erreur humaine.

Les grands ingénieurs de données savent que leurs pipelines sont instables et ont parfois des personnalités. Mais ils s’adaptent à elles, disposent d’outils pour les mesurer et sont toujours en quête d’une explication plus fiable.

Découvrez comment IBM Databand assure la surveillance des pipelines de données pour détecter rapidement les incidents, tels que les tâches ou les exécutions ayant échoué, afin de pouvoir gérer la croissance des pipelines. Si vous êtes prêt à aller plus loin, réservez une démo dès aujourd’hui.