Avez-vous déjà eu des flux de données inattendus ou incorrects entrant dans l'un de vos produits analytiques ?

Des données incorrectes compromettent l'intégrité analytique, conduisent à des décisions erronées et à une perte de confiance dans vos données.

Alors que les organisations exploitent de plus en plus de données, le besoin de données de haute qualité ne fait qu'augmenter. Par exemple, en matière d'apprentissage automatique, il est crucial de trouver d'abord un sous-ensemble propre et non biaisé pour entraîner votre modèle prédictif. Des données incorrectes entraînent des prédictions erronées.

C'est pourquoi les entreprises sont de plus en plus ouvertes à l'idée de tester leurs données.

Tester les jeux de données n'est pas un concept entièrement nouveau. En ingénierie logicielle, le TDD, également connu sous le nom de développement piloté par les tests, est une pratique courante depuis de nombreuses années. Les tests automatisés vont de pair avec l'écriture de code logiciel. Si vous ne testez pas automatiquement votre code après chaque validation, alors vous seriez considéré comme un amateur au lieu d'un professionnel. Pour avoir confiance dans les logiciels, vous devez disposer de suites de tests automatisés. Cela n'est pas différent lorsqu'il s'agit de données utilisées en production.

Au cours des dernières années, le développement de produits de données a considérablement progressé. L'adoption généralisée des nouvelles technologies de données est devenue une réalité. Même pour l'apprentissage automatique, l'une des frontières du développement logiciel, de nombreuses solutions préfabriquées sont facilement disponibles en ligne.

En plus de l'apprentissage automatique, l'entreposage de données traditionnel s'est tout aussi bien développé. Les entreprises et les consommateurs ont commencé à produire beaucoup plus de données, donc un nouveau type d'entrepôt de données natif du cloud (comme Snowflake) est apparu sur le marché, où le stockage et le calcul sont séparés (lire rapide et évolutif), et la consommation est basée sur la puissance et le temps de disponibilité (lire faible coût).

Avant de continuer, définissons d'abord ce que nous entendons par « données en production » et introduisons le concept de « produit de données ».

Un produit de données est similaire à d'autres produits logiciels (par exemple, ils ont une interface et reçoivent de nouvelles fonctionnalités qui sont déployées en développement et en production), mais il est différent en ce que l'objectif principal du produit est de fournir de la valeur grâce à des ensembles de données analytiques. Les produits de données dépendent donc fortement des données pour générer des résultats. Une autre caractéristique est que c'est souvent les données les plus récentes (combien de bouchons avons-nous actuellement) qui sont les plus importantes.

Lors du développement d'un produit de données, il est logique de commencer à tester les données dès qu'elles sont mises en production. Des exemples pourraient être de tester l'ensemble quotidien de transactions qui sont arrivées, ou la distribution des prédictions que nous avons effectuées sur tous les segments.

Il est essentiel que les données soient propres et conformes aux attentes pour garantir l'intégrité de votre produit de données.

Pourquoi devriez-vous tester les produits de données une fois qu'ils sont mis en production ?‍

Tout comme dans le développement de logiciels, les développeurs testent parce qu'il est nécessaire de repérer les bugs et leurs causes sous-jacentes tôt, car ils ont tendance à entraîner des plantages. Évidemment, les bugs qui font planter vos systèmes ne sont pas une bonne chose, mais au moins ils signalent que quelque chose ne va pas. Dans le développement logiciel, ces bugs sont facilement détectables.

Dans le développement de produits de données, les tests sont encore plus cruciaux pour de nombreuses raisons. De nombreux facteurs obligent les données à changer constamment. Les personnes qui provoquent ces changements sont souvent dans différentes parties de l'organisation et elles n'évaluent pas toujours nécessairement l'impact sur la chaîne de valeur des données lorsqu'elles apportent des modifications aux systèmes opérationnels.

De plus, les problèmes de données sont souvent silencieux. Un modèle ou un algorithme d'apprentissage automatique, par exemple, continuera de fonctionner, même si certaines de ses entrées sont erronées. Il peut falloir des semaines, des mois, voire des années pour détecter un problème, il est donc crucial de détecter les anomalies dès que possible.

Gardez à l'esprit que les lacs de données et les nouveaux entrepôts de données peuvent devenir très complexes, ce qui signifie que le test manuel n'est plus la seule option pour empêcher les lacs de données de devenir des marécages de données.‍

Quand devriez-vous commencer à tester vos données ?‍

La réponse ici est simple et directe, dès que possible. Cela signifie introduire un changement de culture dans vos équipes qui commence par créer de la transparence sur les erreurs et les déficiences des données. Nous recommandons certainement de commencer à tester votre premier produit de données, après chaque construction ou modification que vous effectuez (même si votre produit est un rapport !).

Vos produits de données échoueront s'ils ne sont pas surveillés. Savoir pourquoi ils échouent est crucial pour le développement ultérieur des produits de données. À un niveau plus technique, il est recommandé de tester après chaque étape de la pipeline, ainsi qu'entre les différents pipelines.‍

Qui devrait être impliqué dans les tests de qualité des données ?‍

Historiquement, cela a toujours été l'équipe d'ingénierie et à cause de leur connaissance plutôt limitée du domaine des données, ils se sont concentrés sur les métriques opérationnelles. L'expérience a montré que tester les données sans connaissance du domaine est assez inutile, car de nombreux problèmes à fort impact seront cachés dans l'ensemble de données.

Nous recommandons donc d'inclure toujours des experts en données dans le test des données sources qui entrent dans tous vos produits de données.‍

Conclusion‍

Les équipes de développement de produits de données peuvent et devraient appliquer certaines des meilleures pratiques qui ont été développées dans l'ingénierie logicielle et la gestion des données au cours des dernières décennies.

Les problèmes de données passent souvent inaperçus pendant un certain temps (erreurs silencieuses) et ont un impact élevé sur la qualité des produits. La plupart des produits de données ne se briseront même pas, de sorte que les problèmes passent inaperçus pendant un certain temps, aboutissant à une qualité de produit médiocre et à des jours/semaines de travail de nettoyage.

Personne ne veut être un concierge de données, alors commencez à tester vos produits de données dès aujourd'hui !