Surveillez les données et les assets d'IA avec Lakehouse Monitoring
Cet article décrit Databricks Lakehouse Monitoring. Il couvre les avantages du monitoring de vos données et donne un aperçu des composants et de l'utilisation de Databricks Lakehouse Monitoring.
Databricks Lakehouse Monitoring vous permet de surveiller les propriétés statistiques et la qualité des données dans toutes les tables de votre compte. Vous pouvez également l’utiliser pour suivre les performances des modèles de machine learning et des endpoints de service de modèles en monitoring les tables d'inférence qui contiennent les entrées et les prédictions des modèles. Le schéma montre le flux de données à travers des pipelines de données et de ML dans Databricks, et comment vous pouvez utiliser monitoring pour suivre en continu la qualité des données et les performances du modèle.
Pourquoi utiliser Databricks Lakehouse Monitoring ?
Pour tirer des insights utiles de vos données, vous devez avoir confiance en leur qualité. Le monitoring de vos données fournit des mesures quantitatives qui vous aident à suivre et à confirmer la qualité et la cohérence de vos données au fil du temps. Lorsque vous détectez des modifications dans la distribution des données de votre table ou les performances du modèle correspondant, les tables créées par Databricks Lakehouse Monitoring peuvent capturer et vous alerter du changement, et vous aider à en identifier la cause.
Databricks Lakehouse Monitoring vous aide à répondre aux questions suivantes :
- À quoi ressemble l'intégrité des données, et comment évolue-t-elle au fil du temps ? Par exemple, quelle est la fraction de valeurs nulles ou égales à zéro dans les données actuelles, et a-t-elle augmenté ?
- À quoi ressemble la distribution statistique des données et comment évolue-t-elle au fil du temps ? Par exemple, quel est le 90e centile d'une colonne numérique ? Ou, quelle est la distribution des valeurs dans une colonne catégorielle, et en quoi diffère-t-elle d'hier ?
- Existe-t-il une drift entre les données actuelles et une ligne de base connue, ou entre des fenêtres temporelles successives des données ?
- À quoi ressemble la distribution statistique ou le drift d'un sous-ensemble ou d'une tranche des données ?
- Comment les entrées et les prévisions des modèles de ML évoluent-elles au fil du temps ?
- Comment la performance du modèle évolue-t-elle au fil du temps ? La version A du modèle est-elle plus performante que la version B ?
En outre, Databricks Lakehouse Monitoring vous permet de contrôler la granularité temporelle des observations et de configurer des métriques personnalisées.
Fonctionnement de Lakehouse Monitoring sur Databricks
Pour surveiller une table dans Databricks, vous créez un moniteur associé à la table. Pour surveiller les performances d’un Modèle de machine learning, vous associez le moniteur à une table d'inférence qui contient les entrées du modèle et les prédictions correspondantes.
Databricks Lakehouse Monitoring fournit les types d'analyse suivants : séries chronologiques, instantané et inférence.
Type de profil | Description |
|---|---|
Série temporelle | À utiliser pour les tables qui contiennent un dataset de séries chronologiques basé sur une colonne de timestamp. monitoring compute des métriques de qualité des données sur des fenêtres temporelles de la série chronologique. |
Inférence | À utiliser pour les tables qui contiennent le log de requêtes pour un modèle. Chaque ligne est une requête, avec des colonnes pour le timestamp, les entrées du modèle, la prédiction correspondante et l'étiquette de vérité terrain (facultatif). Le monitoring compare les performances du modèle et les métriques de qualité des données sur des fenêtres temporelles du log de requêtes. |
Instantané | Utiliser pour tous les autres types de tables. Le monitoring calcule les métriques de qualité des données sur toutes les données de la table. La table complète est traitée à chaque refresh. |
Cette section décrit brièvement les tables d'entrée utilisées par Databricks Lakehouse Monitoring et les tables de métriques qu'il produit.
Table principale et table de base
En plus de la table à surveiller, appelée « table principale », vous pouvez éventuellement spécifier une table de référence à utiliser pour mesurer le drift, ou le changement de valeurs au fil du temps. Une table de référence est utile lorsque vous avez un échantillon de l'aspect attendu de vos données. L'idée est que le drift est ensuite calculé par rapport aux valeurs et distributions de données attendues.
La table de base doit contenir un dataset qui reflète la qualité attendue des données d'entrée, en termes de distributions statistiques, de distributions de colonnes individuelles, de valeurs manquantes et d'autres caractéristiques. Il doit correspondre au schéma de la table surveillée. L'exception est la colonne Timestamp pour les tables utilisées avec des séries temporelles ou des profils d'inférence. Si des colonnes sont manquantes dans la table primaire ou dans la table de base, le monitoring utilise des heuristiques basées sur les meilleurs efforts pour compute les métriques de sortie.
Pour les moniteurs qui utilisent un profil d'instantané, la table de référence doit contenir un instantané des données dont la distribution représente une norme de qualité acceptable. Par exemple, pour les données de distribution des notes, on pourrait définir la base de référence comme une classe précédente où les notes étaient distribuées uniformément.
Pour les moniteurs qui utilisent un profil de série chronologique, la table de référence doit contenir des données qui représentent des fenêtre(s) temporelle(s) où les distributions de données représentent un standard de qualité acceptable. Par exemple, pour les données météorologiques, vous pourriez définir la ligne de base sur une semaine, un mois ou une année où la température était proche des températures normales attendues.
Pour les moniteurs qui utilisent un profil d'inférence, un bon choix pour une base de référence est les données qui ont été utilisées pour entraîner ou valider le modèle surveillé. De cette façon, les utilisateurs peuvent être alertés lorsque les données ont subi un drift par rapport à ce sur quoi le modèle a été entraîné et validé. Cette table doit contenir les mêmes colonnes de fonctionnalités que la table principale, et doit également avoir le même model_id_col qui a été spécifié pour le InferenceLog de la table principale afin que les données soient agrégées de manière cohérente. Idéalement, l'ensemble de test ou de validation utilisé pour évaluer le modèle devrait être utilisé pour garantir des métriques de qualité de modèle comparables.
Tables de métriques
Un moniteur de table crée deux tables de métriques. Les valeurs de métriques sont computées pour l'ensemble de la table, et pour les fenêtres temporelles et les sous-ensembles de données (ou « slices ») que vous spécifiez lors de la création du moniteur. De plus, pour l'analyse d'inférence, les métriques sont compute pour chaque ID de modèle.
- La table de métriques de profil contient des statistiques récapitulatives.
- La table des métriques de drift contient des statistiques liées au drift des données au fil du temps. Si une table de référence est fournie, le drift est également surveillé par rapport aux valeurs de référence.
Les tables de métriques sont des tables Delta et sont stockées dans un schéma Unity Catalog que vous spécifiez. Vous pouvez visualiser ces tables à l'aide de l'interface utilisateur de Databricks et les interroger à l'aide de Databricks SQL.
Créer un moniteur Lakehouse
Pour créer un moniteur de données à l'aide de l'interface utilisateur de Databricks, consultez Créer un moniteur à l'aide de l'interface utilisateur de Databricks.
Pour créer un moniteur par programmation à l'aide du SDK Databricks ou de l'API REST, consultez Créer un moniteur à l'aide de l'API Databricks.