Suite à la Conférence Databricks Data and AI et à notre Semaine de Lancement, nous sommes ravis de présenter les dernières fonctionnalités de Soda, spécifiquement conçues pour améliorer la fiabilité des données au sein de l'écosystème Databricks.

Dans cet article, nous vous guiderons à travers nos caractéristiques innovantes, Observabilité des Metrics et Contrats de Donnée Collaboratifs. Celles-ci s'intègrent facilement dans votre flux de travail Databricks actuel, permettant aux équipes techniques et non techniques de collaborer sur la qualité des données comme jamais auparavant.

Pour Commencer

Les outils de Databricks sont principalement centrés sur le code et liés à leurs carnets de notes et Delta Live Tables, ce qui peut limiter l'accessibilité pour les utilisateurs non techniques.

Soda, d'autre part, offre des voies d'intégration flexibles avec Databricks. Chaque utilisateur, des ingénieurs de données intégrant des vérifications aux utilisateurs business définissant des règles dans Soda Cloud, peut contribuer à l'analyse des données et à la prise de décision sans besoin de codage.

Voici comment commencer :

Soda avec Databricks SQL Warehouse

Les nouvelles fonctionnalités sont maintenant disponibles pour les Databricks SQL Warehouses. Les utilisateurs peuvent facilement connecter les données d'un catalogue Unity directement à Soda Cloud.

L'Agent hébergé par Soda permet aux utilisateurs de Soda Cloud de se connecter en toute sécurité aux sources de données et de réaliser des évaluations automatiques de la qualité des données.

Pour les utilisateurs professionnels qui préfèrent une expérience entièrement sans code, Soda Cloud offre une interface web intuitive pour définir et gérer les vérifications de qualité des données.

Où trouver les identifiants Databricks

Dans votre tableau de bord Databricks, allez dans SQL → sélectionnez SQL Warehouses → choisissez Serverless Starter Warehouse (ou votre entrepôt spécifique) → sélectionnez Détails de Connexion.

Vous devrez également créer un jeton d'accès personnel en cliquant sur le lien à droite.

Connecter Databricks à Soda Cloud

Dans Soda Cloud, vous pouvez connecter votre environnement Databricks en fournissant les identifiants nécessaires. Pour le flux détaillé, veuillez vous référer à notre documentation.

Étape 1 : Inscription

Inscrivez-vous gratuitement sur https://beta.soda.io/create-account

Ensuite, vous serez guidé à travers la configuration avec un tour produit.

Nous avons créé un environnement bêta spécialement pour les nouveaux essais où nous hébergeons une source de données avec un jeu de données appelé regional_sales qui est mis à jour quotidiennement. Vous pouvez utiliser ce jeu de données et passer les étapes suivantes, ou ajouter une nouvelle source de données en suivant les instructions ci-dessous.

Étape 2 : Ajouter une Source de Données

L'interface sans code de Soda Cloud vous permet de vous connecter à n'importe quel Databricks SQL Warehouse soutenu par Unity-Catalog en quelques minutes.

1. Dans Soda Cloud, cliquez sur Sources de Données → + Nouvelle Source de Données

2. Nommez votre source de données "Démonstration Databricks" sous Étiquette Source de Données

3. Passez à l'onglet Connexion et renseignez les identifiants suivants pour connecter votre instance Soda à Databricks.

4. Cliquez sur Connecter. Cela testera la connexion et passera à l'étape suivante.

5. Sélectionnez les jeux de données que vous souhaitez intégrer sur Soda Cloud.

Étape 3 : Activer la Surveillance et le Profiling

Par défaut, la Surveillance des Metrics est activée pour suivre automatiquement les indicateurs clés sur tous les jeux de données que vous intégrez et vous alerter lorsque des anomalies sont détectées — plus à ce sujet dans les sections suivantes.

Cela aide à :

1. Évaluer comment les indicateurs de qualité des données ont performé dans le passé.

2. Les utiliser comme données d'entraînement pour les algorithmes de détection d'anomalies.

3. Cliquez sur Terminer pour conclure l'intégration de vos jeux de données.

Après la fin de l'intégration, Soda exécute un premier scan utilisant vos paramètres de Surveillance des Metrics. Ce scan initial fournit des mesures de base que Soda utilise pour commencer à apprendre des modèles et identifier des anomalies.

La première étape pour construire une stratégie de qualité des données évolutive est d'activer la surveillance des metrics sur tous vos jeux de données. Pourquoi commencer ici ? Parce que c'est peu d'effort et à fort impact.

Plongeons plus profondément dans le fonctionnement.

Observabilité des Données

L'observabilité des données implique une surveillance et une évaluation continues de la santé de vos données tout au long de leur cycle de vie. Elle analyse les métadonnées, les metrics et les logs pour détecter les problèmes dès qu'ils surgissent, aidant les équipes à conserver leur confiance dans leurs données.

Les moniteurs suivent les metrics clés de qualité des données au fil du temps, et notre algorithme de détection d'anomalies analyse les modèles historiques lorsqu'un metric se comporte de manière inattendue pour décider s'il doit déclencher une alerte.

Les anomalies sont des déviations inattendues dans les données qui sortent des modèles normaux, mais qui ne violent pas forcément des règles ou contraintes prédéfinies. Contrairement aux problèmes de qualité qui peuvent être détectés par une logique stricte, les anomalies se manifestent généralement sous la forme de décalages subtils et dépendants du contexte. Elles échappent souvent à la détection et impactent silencieusement les systèmes en aval.

Les détecter nécessite une prise de conscience contextuelle et une compréhension de ce à quoi "normal" ressemble au fil du temps. Et le faire, au bon moment et avec le bon niveau de confiance, n'est pas une mince affaire.

Notre moteur de surveillance des metrics a été développé à partir de zéro, sans compter sur des bibliothèques du commerce ou des composants tiers. Cela nous a donné un contrôle total sur la pile de modélisation, de l'ingénierie des caractéristiques à la logique de détection. Cela signifie aussi que nous ne sommes pas enfermés dans des hypothèses rigides qui compromettent l'exactitude ou l'interprétabilité.

Nous évaluons chaque modèle en utilisant un cadre de test propriétaire qui exécute des expériences sur des centaines de jeux de données internes contenant des problèmes de qualité connus. Cela nous permet de benchmarker la performance réelle, d'optimiser pour une haute précision, et de réduire les faux positifs qui autrement inonderaient les canaux d'alerte.

Parce que nous possédons chaque couche de la pile, nous pouvons expliquer les prédictions, remonter les anomalies à leur source, et affiner en continu le comportement du système en production.

Dans les tests contre Facebook Prophet, notre système a détecté plus de 70% d'anomalies réelles de qualité des données tout en envoyant significativement moins de fausses alertes.

Alors, comment puis-je tirer le meilleur parti de cette fonctionnalité et obtenir automatiquement des informations observables sur la qualité de mes données ?

Moniteurs de Metrics

La surveillance des metrics de Soda est conçue pour une couverture immédiate et étendue avec une configuration minimale.

Juste après l'intégration de votre source de données, notre outil scanne efficacement les métadonnées pour suivre les tendances au fil du temps et comparer automatiquement le comportement actuel aux lignes de base historiques.

Dès le premier jour, vous avez visibilité sur des indicateurs essentiels, par exemple si les données arrivent à temps, si le volume s'aligne avec les modèles passés, et si des changements de schéma se sont produits.

Tout ce que vous avez à faire est de sélectionner un jeu de données puis d'aller à l'onglet Moniteurs de Metrics — le tableau de bord d'observabilité des metrics de Soda.

Sur ce tableau de bord, vous verrez que les metrics clés sont automatiquement surveillés par défaut, vous aidant à détecter les problèmes de pipeline, les retards de données, et les changements structurels inattendus au fur et à mesure qu'ils se produisent.

Soda propose deux principaux types de moniteurs :

• Moniteurs de jeu de données : Pour suivre les metrics clés tels que les changements de nombre de lignes, les mises à jour de schéma et les activités d'insertion. Ils sont efficaces pour identifier des problèmes structurels ou au niveau du pipeline à travers de nombreux jeux de données.

• Moniteurs de colonne : Pour cibler des champs spécifiques, permettant aux utilisateurs de suivre les valeurs manquantes, les moyennes ou la fraîcheur. Ces moniteurs capturent des problèmes de données qui affectent l'exactitude ou la logique métier au niveau de la colonne.

Vous pouvez personnaliser ce que vous surveillez en cliquant sur Configurer les Moniteurs de Jeu de Données ou Ajouter des Moniteurs de Colonne pour suivre les metrics basés soit sur les métadonnées soit sur la colonne de partition temporelle.

Puis, pour explorer plus en profondeur un metric spécifique, cliquez simplement dessus. Cela affichera des vues détaillées, y compris le graphique Historique des Anomalies où vous pouvez analyser le comportement du metric sélectionné au fil du temps.

Ce tableau de bord vous permet de zoomer sur des périodes spécifiques, vous permettant d'analyser les problèmes de plus près. Vous pouvez cliquer et faire glisser pour vous concentrer sur une fenêtre temporelle plus petite, vous aidant à isoler quand exactement l'anomalie s'est produite.

Vous pouvez aussi ajuster manuellement les filtres de la chronologie pour afficher une plage de dates personnalisée pertinente pour votre enquête.

Le tableau de bord d'observabilité de Soda envoie aux équipes un signal proactif lorsque quelque chose dévie de la normale, même avant que les pipelines en aval ou les tableaux de bord ne se cassent.

Configurer les Moniteurs de Metrics

Les utilisateurs peuvent encore personnaliser le tableau de bord de détection d'anomalies à l'aide de trois paramètres : stratégie de seuil, valeurs d'exclusion, et sensibilité.

1. Définir la Stratégie de Seuil

• La stratégie de seuil vous permet de configurer quels types d'anomalies doivent être signalés.

• Disons que vous surveillez les metrics total_row_count ou daily_revenue dans un jeu de données daily_sales. Vous ne vous souciez peut-être que des pics inattendus, une soudaine montée en puissance des revenus quotidiens due à une vente éclair. Dans ce cas, vous pouvez désactiver le seuil inférieur, indiquant au système de ne faire ressortir que les anomalies où la valeur dépasse la plage attendue.

• Ce niveau de contrôle vous aide à adapter la détection d'anomalies à votre contexte commercial.

2. Définir les Valeurs d'Exclusion

• Définir des valeurs d'exclusion vous permet de spécifier certaines valeurs ou périodes qui doivent être ignorées lors de la détection d'anomalies. Ces valeurs exclues ne seront pas signalées comme anomalies, même si elles se trouvent dans la plage attendue.

3. Définir la Sensibilité

• Le curseur de sensibilité vous aide à contrôler à quel point le système est strict ou indulgent lorsqu'il détecte des anomalies dans vos données.

• Si vous déplacez le curseur de sensibilité vers la droite, la plage attendue devient plus large. Cela signifie que le système ne signalera que les grands changements comme anomalies. Par exemple, dans ce jeu de données daily_sales, si vous avez un schéma de ventes stable, une large plage attendue amènera le système à ignorer de petites baisses ou augmentations de ventes et à ne signaler que les changements plus importants et plus inhabituels.

• Si vous déplacez le curseur vers la gauche, la plage attendue se rétrécit. Cela est utile si vous cherchez à détecter toutes les déviations possibles, même les moins perceptibles.

La chose la plus intéressante est que le moteur de surveillance des metrics est conçu pour évoluer. Le modèle s'adapte aux changements dans vos données, et il intègre les retours humains pour s'améliorer au fil du temps.

Nos nouveaux documents ont fière allure. Rendez-vous là-bas pour en savoir plus sur le fonctionnement de la détection d'anomalies chez Soda, et consultez la section Observabilité des Données.

Maintenant, une fois que vous avez configuré comment les anomalies sont détectées et affichées, l'étape suivante est de les gérer lorsqu'elles se produisent.

Créer un incident

Notre modèle d'apprentissage machine signale les points de données anormaux en rouge afin qu'ils puissent être facilement repérés.

Lorsque vous cliquez sur une marque rouge, un panneau de détails s'ouvre, montrant plus d'informations sur cette mesure, y compris le metric et les valeurs impliquées.

De là, vous pouvez marquer la mesure comme attendue ou comme une anomalie — cela aide le modèle sous-jacent à améliorer sa connaissance de vos modèles de données.

Si vous n'êtes pas sûr ou souhaitez enquêter davantage, vous pouvez cliquer sur Créer un Incident pour l'enregistrer. Cela ouvre un panneau d'incident où vous pouvez ajouter des détails de base tel que le titre et la description.

Après cela, l'incident sera disponible dans l'onglet principal Incidents où vous pouvez définir la gravité et le statut, et assigner un responsable. Le système enregistre automatiquement les métadonnées de qui l'a signalé, quand il a été détecté, et à quel jeu de données et vérification de qualité il se rapporte.

Une fois créé, l'incident passe par quatre étapes : Signalé, Enquête, Réparation et Résolution, que vous pouvez suivre visuellement en haut de l'écran. Ensuite, vous pouvez surveiller les progrès et revisiter les données historiques pour assurer une résolution rapide.

Une intégration Slack, Jira, et MS Teams est également possible via des webhooks. Pour plus de détails à ce sujet, visitez notre page de Documentation et consultez la section Intégrations.

Lors de l'examen des anomalies, utilisez une logique commerciale simple et le contexte pour déterminer si elles nécessitent réellement une attention. Par exemple, s'il y a un pic soudain, disons dans une colonne de ventes, alors vous pouvez vérifier s'il y a eu une campagne marketing, un festival, ou une baisse de prix qui explique le pic. Si oui, c’est attendu et peut être marqué comme tel.

Pensez aux anomalies comme à des incitants à la conversation. Si vous pouvez expliquer en toute confiance la cause racine comme faisant partie des opérations normales, marquez-la comme attendue. Sinon, ouvrez un incident pour creuser plus profondément et faire intervenir les bonnes personnes.

Comme vous pouvez le voir, l'observabilité des données avec Soda est très facile à configurer, et vous n'avez pas à spécifier manuellement de règles.

Avec les outils d'observabilité, nous pouvons voir les flux de données, recevoir des alertes d'anomalies, et remonter facilement aux sources des problèmes, automatiquement et à l'échelle. Mais l'observabilité n'est que le début.

Une fois les incidents évalués et les causes racines comprises, les producteurs et consommateurs de données peuvent avancer vers la définition de normes de qualité des données plus strictes, basées sur leurs règles commerciales spécifiques.

Test des Données

Les tests des données valident que vos données répondent aux attentes définies avant qu'elles n'atteignent les parties prenantes, les tableaux de bord, ou les systèmes en aval. Nous commençons bien puis déplaçons à gauche, en amenant plus tôt les considérations de qualité dans le cycle de vie des données et en mettant plus l'accent sur la prévention que sur la réponse.

Chez Soda, nous croyons que la qualité des données doit aussi être faite à la source, du côté gauche des pipelines de données. En déplaçant à gauche, nous pouvons nous assurer que les données sont fiables et que les insights sont corrects, empêchant les problèmes de se propager dans tout votre écosystème de données.

Si vous avez travaillé avec des systèmes de données en production, vous avez probablement expérimenté les impacts en aval des changements non suivis. Ces problèmes ne sont pas nouveaux, mais ils deviennent plus difficiles à ignorer à mesure que les organisations développent leur infrastructure de données et s'appuient sur des pipelines de plus en plus interconnectés.

Un grand partie du problème est que la qualité des données n'a jamais eu de propriétaire clair. Les producteurs génèrent les données, mais la responsabilité de les vérifier atterrit souvent sur les consommateurs. Les consommateurs pourraient être des analystes, des ingénieurs de données, ou des équipes d'affaires qui sont alors laissés à corriger les problèmes en aval.

Sans une définition partagée de ce que les données devraient ressembler, les équipes mettent en œuvre des vérifications ad hoc basées sur des hypothèses. Ces vérifications de qualité s'exécutent après ingestion ou transformation, ce qui signifie que les mauvaises données sont toujours dans la boucle, prêtes à gâcher la journée de quelqu'un.

Les outils intégrés de Databricks font un excellent travail pour soutenir les ingénieurs de données au sein de son écosystème. Mais la collaboration entre producteurs et consommateurs manque.

C'est là que nous avons vu une opportunité de résoudre ce problème avec Contrats de Donnée.

Pensez-y comme la Magna Carta de vos jeux de données — un accord versionné entre producteurs et consommateurs qui définit la structure, les attentes de qualité et les garanties de livraison :

• Les producteurs définissent explicitement la structure, les métriques de qualité et les attentes de livraison des données qu'ils possèdent. Ces définitions sont appliquées par le système, pas laissées à l'interprétation.

• Les consommateurs fonctionnent avec ces garanties claires. Ils peuvent faire confiance aux données dont ils dépendent sans avoir besoin de déchiffrer la logique en amont ou de construire des vérifications défensives autour de l'instabilité.

• Le contrat sert de source unique de vérité. Il consolide les attentes dans une définition partagée, autoritaire, portable à travers les environnements et outils.

Contrats de Données Collaboratifs

Les contrats de données font depuis longtemps partie de l'expérience CLI de Soda. Avec cette version, nous avons fait un pas de plus et avons rendu les Contrats de Données Collaboratifs disponibles dans l'UI.

Voici ce que signifient les contrats de données collaboratifs pour les équipes de données :

• Tous les changements de contrat sont versionnés et auditées. Les mises à jour de schéma, les changements de règles de validation, et les modifications de livraison sont suivis avec un historique complet pour traçabilité et conformité.

• La collaboration est intégrée au flux de travail. Les contrats obligent les producteurs et consommateurs à s'aligner sur les cas d'utilisation et les attentes avant que les données ne traversent le système.

• Les ingénieurs peuvent aussi mettre à jour les contrats depuis leur IDE préféré, et les changements se refléteront dans le Contrat de Données Soda Cloud (et vice versa).

• Les utilisateurs métier peuvent définir et gérer les attentes directement dans l'interface sans code de Soda Cloud.

Pour essayer cela dans Soda, cliquez sur Créer un Contrat sur le tableau de bord Vérifications du jeu de données. Cela ouvrira l'interface Contrat de Données où vous pouvez définir vos contrats de données dans une interface intuitive.

Si vous préférez travailler directement avec le code, vous pouvez utiliser le bouton bascule pour voir le code. Cela permet aux développeurs de voir le code sous-jacent généré par les sélections de l'interface.

Les utilisateurs peuvent alors appliquer des règles au niveau du jeu de données, soit sur les colonnes soit sur la structure du schéma, et les appliquer au niveau de la colonne.

En utilisant le jeu de données daily_sales comme exemple, le contrat de données a deux vérifications :

• Vérification de colonne : store_id ne doit pas être nul.

• Vérification de jeu de données : si un magasin est fermé (open = 0), il ne devrait pas y avoir de promotions (promotion = 1). Cela signale les lignes où les promotions sont incorrectement enregistrées pour des magasins fermés.

Une fois que vous avez terminé d'écrire votre contrat de données, il est temps de le vérifier. Le système vérifiera le jeu de données par rapport aux conditions que vous avez définies dans le contrat.

Par exemple, après avoir exécuté cette vérification, il y avait 0 lignes avec un store_id manquant, ce qui a réussi la vérification de colonne.

Mais, la vérification au niveau du jeu de données a signalé 3707 lignes où des promotions ont été enregistrées alors même que le magasin était marqué comme fermé. Ce sont des données invalides qui seraient passées inaperçues sans le contrat. Si le contrat est bien exécuté et tout est vérifié, vous pouvez publier le contrat. Une fois publié, le contrat sera actif, et le jeu de données sera continuellement vérifié par rapport aux règles du contrat.

Selon les besoins de votre organisation, le système peut être configuré pour soit complètement stopper le pipeline soit envoyer des alertes tout en permettant au processus de continuer.

Pour en savoir plus sur nos capacités de Contrats de Données, lisez la section sur Test des Données dans notre documentation.

Comment Soda Complète l'Outil de Qualité des Données de Databricks

Databricks DQX est particulièrement bien adapté pour certains scénarios :

• Lorsque l'intégration profonde avec les fonctionnalités natives de Databricks est essentielle.

• Pour les équipes déjà fortement investies dans les outils natifs de Databricks.

• Lorsqu'on travaille principalement avec des charges de travail PySpark et des opérations de DataFrame.

• Pour des cas d'utilisation nécessitant des capacités de mise en quarantaine intégrées dans l'environnement Databricks.

DQX offre des capacités impressionnantes, y compris la prise en charge de toutes les charges de travail Spark (y compris Delta Live Tables), différentes réactions aux échecs (y compris la mise en quarantaine des données invalides), et différentes sévérités de vérification.

Soda renforce et élargit les capacités de DQX de plusieurs manières clés.

Passons en revue les principaux aspects et contrastons-les :

La plateforme spécialisée de Soda élargit les capacités de Databricks avec des fonctionnalités dédiées pour les tests multiplateformes, la surveillance avancée des metrics, et les contrats de données collaboratifs.

Ensemble, ils forment une base solide pour garantir que les données qui alimentent vos processus commerciaux critiques sont fiables, précises, et dignes de confiance.

Cette approche complémentaire crée une stratégie de qualité des données complète qui exploite les atouts des deux plateformes :

• Utilisez DQX pour les vérifications de qualité natives de Databricks intégrées directement dans vos flux de travail Spark.

• Exploitez Soda pour les tests multiplateformes, la surveillance avancée, et la gouvernance de la qualité des données à l'échelle de l'organisation.

• Implémentez des contrats de données dans Soda pour établir des attentes de qualité formelles tout en utilisant DQX pour l'application au moment de l'exécution.

La combinaison des nouvelles fonctionnalités de Soda et des puissantes capacités de traitement de Databricks aboutit à une approche complète de la qualité des données qui aide les organisations à éviter les problèmes de données coûteux avant qu'ils ne perturbent les opérations commerciales.

Notre dernier lancement retravaille toute la plateforme Soda pour garantir une intégration transparente. En introduisant une nouvelle version majeure, nous modernisons non seulement la fondation du produit mais nous concrétisons aussi notre vision des contrats de données comme une approche unifiée, gouvernable, et accessible de la qualité des données basée sur la propriété, la confiance, et la collaboration.

En Résumé

En apprenant des modèles historiques, Soda peut détecter des changements soudains et subtils dans le comportement des données, mettant en lumière des problèmes comme des pipelines cassés, des chargements retardés, ou des modifications de schéma imprévues avant qu'ils ne s'aggravent.

Dans des environnements à grande échelle avec des centaines ou des milliers de tables, il n'est tout simplement pas pratique de définir un contrat de données pour chacune dès le départ. C'est pourquoi le mouvement intelligent est de commencer avec la Surveillance des Metrics : obtenir une couverture large, détecter les problèmes tôt, et enquêter sur les causes profondes de manière efficiente.

De là, vous pouvez prendre des mesures ciblées, en déplaçant à gauche en appliquant des Contrats de Données là où ils sont le plus nécessaires, directement à la source. Cela garantit qu'une fois qu'un problème est résolu, il le reste.

Nous avons reconstruit Soda pour faciliter ce parcours, combinant observabilité, détection d'anomalies et contrats de données en une expérience unifiée.

Nous avons voulu nous assurer que les outils de Soda s'intègrent bien aux outils que les gens font déjà confiance et utilisent chaque jour. Même si vous n'utilisez pas Databricks, ne vous inquiétez pas. La nouvelle version de Soda pourra se connecter entièrement à toutes les principales sources de données à partir du 30 juin.

Que vous travailliez avec Databricks ou que vous gériez divers environnements de données, Soda est conçu pour vous aider à établir la confiance dans vos données à grande échelle.

Curieux d'essayer ? Soyez le premier à essayer la nouvelle observabilité des metrics alimentée par l'IA de Soda et les contrats de données collaboratifs sur beta.soda.io. Gratuitement, sans carte de crédit requise.

La création de compte en libre-service pour Soda Cloud est temporairement interrompue alors que nous préparons la disponibilité générale de plusieurs mises à jour majeures. Si vous souhaitez essayer Soda Cloud entre-temps, veuillez planifier un appel avec notre équipe d'experts, discuter de votre cas d'utilisation, et commencer.