Référence de table système d'historique des query
Aperçu
Cette table système est en aperçu public.
Cet article inclut des information sur la table système de l'historique des query, y compris un aperçu du schéma de la table.
**Chemin de la table** : Cette table système est située system.query.history à.
Utilisation de la table d'historique des requêtes
La table d'historique des queries inclut les enregistrements des queries exécutées à l'aide de SQL warehouses ou de compute serverless pour les notebooks et les jobs. La table inclut des enregistrements à l'échelle du compte provenant de tous les workspaces de la même région à partir desquels vous accédez à la table.
By default, seuls les administrateurs ont accès à la table système. Si vous souhaitez partager les données de la table avec un utilisateur ou un groupe, Databricks recommande de créer une vue dynamique pour chaque utilisateur ou groupe. Consultez Créer une vue dynamique.
Schéma de la table système de l'historique des query
La table d'historique de query utilise le schéma suivant :
Nom de colonne | Type de données | Description | Exemple |
|---|---|---|---|
| chaîne | ID du compte. |
|
| chaîne | L'ID du Workspace où la query a été exécutée. |
|
| chaîne | L'ID qui identifie de manière unique l'exécution de l'instruction. Vous pouvez utiliser cet ID pour trouver l'exécution de l'instruction dans l'**interface utilisateur de l'historique des requêtes**. |
|
| chaîne | L'identifiant de session Spark. |
|
| chaîne | L'état de terminaison de l'instruction. Les valeurs possibles sont : |
|
| structure | Une structure qui représente le type de ressource de compute utilisée pour exécuter l'instruction et l'ID de la ressource, le cas échéant. La valeur |
|
| chaîne | L'identifiant de l'utilisateur qui a exécuté l'instruction. |
|
| chaîne | L'adresse e-mail ou le nom d'utilisateur de l'utilisateur qui a exécuté l'instruction. |
|
| chaîne | Texte de l'instruction SQL. Si vous avez configuré des clés gérées par le client, |
|
| chaîne | Le type d'instruction. Par exemple : |
|
| chaîne | Message décrivant la condition d'erreur. Si vous avez configuré des clés gérées par le client, |
|
| chaîne | Application client ayant exécuté l'instruction. Par exemple : Databricks SQL Editor, Tableau et Power BI. Ce champ est dérivé des informations fournies par les applications clientes. Bien que les valeurs soient censées rester statiques au fil du temps, cela ne peut être garanti. |
|
| chaîne | Le connecteur utilisé pour se connecter à Databricks afin d'exécuter l'instruction. Par exemple : Databricks SQL Driver for Go, Databricks ODBC Driver, Databricks JDBC Driver. |
|
| chaîne | Pour les résultats de requête extraits du cache, ce champ contient l'ID d'instruction de la requête qui a initialement inséré le résultat dans le cache. Si le résultat de la requête n'est pas extrait du cache, ce champ contient l'ID d'instruction propre à la requête. |
|
| bigint | Temps d'exécution total de l'instruction en millisecondes (hors temps de récupération des résultats). |
|
| bigint | Temps d'attente pour que les Ressources de compute soient provisionnées, en millisecondes. |
|
| bigint | Temps passé en file d'attente pour la capacité de compute disponible en millisecondes. |
|
| bigint | Temps passé à exécuter l'instruction en millisecondes. |
|
| bigint | Temps passé à charger les métadonnées et à optimiser l'instruction en millisecondes. |
|
| bigint | La somme de toutes les durées de tâche en millisecondes. Ce temps représente le temps combiné qu'il a fallu pour exécuter la query sur tous les cœurs de tous les nœuds. Cela peut être significativement plus long que la durée en temps réel si plusieurs tâches sont exécutées en parallèle. Elle peut être plus courte que la durée réelle si les tâches attendent des nœuds disponibles. |
|
| bigint | Temps passé, en millisecondes, à récupérer les résultats de l’instruction après la fin de l’exécution. |
|
| Horodatage | L'heure à laquelle Databricks a reçu la requête. Les informations de fuseau horaire sont enregistrées à la fin de la valeur, où |
|
| Horodatage | L'heure à laquelle l'exécution de l'instruction s'est terminée, à l'exclusion du temps de récupération des résultats. Les informations de fuseau horaire sont enregistrées à la fin de la valeur, où |
|
| Horodatage | L'heure à laquelle l'instruction a reçu la dernière mise à jour de progression. Les informations de fuseau horaire sont enregistrées à la fin de la valeur, où |
|
| bigint | Le nombre de partitions lues après l'élagage. |
|
| bigint | Le nombre de fichiers élagués. |
|
| bigint | Le nombre de fichiers lus après l'élagage. |
|
| bigint | Nombre total de lignes lues par l'instruction. |
|
| bigint | Nombre total de lignes renvoyées par l'instruction. |
|
| bigint | Taille totale des données lues par l'instruction en octets. |
|
| int | Le pourcentage d'octets de données persistantes lus à partir du cache d'E/S. |
|
| booléen |
|
|
| bigint | Taille des données, en octets, écrites temporairement sur le disque lors de l'exécution de l'instruction. |
|
| bigint | La taille en octets des données persistantes écrites dans le stockage d'objets cloud. |
|
| bigint | Le nombre de lignes de données persistantes écrites dans le stockage d'objets cloud. |
|
| bigint | Nombre de fichiers de données persistantes écrits dans le stockage d'objets cloud. |
|
| bigint | La quantité totale de données en octets envoyées sur le réseau. |
|
| structure | Une structure qui contient des paires clé-valeur représentant les entités Databricks impliquées dans l'exécution de cette déclaration, telles que les Jobs, les Notebooks ou les tableaux de bord. Ce champ n'enregistre que les entités Databricks. |
|
| structure | Une structure contenant des paramètres nommés et positionnels utilisés dans les requêtes paramétrées. Les paramètres nommés sont représentés sous forme de paires clé-valeur qui mappent les noms de paramètres aux valeurs. Les paramètres positionnels sont représentés sous forme de liste où l'index indique la position du paramètre. Un seul type (nommé ou positionnel) peut être présent à la fois. |
|
| chaîne | Nom de l'utilisateur ou du Service Principal dont le privilège a été utilisé pour exécuter l'instruction. |
|
| chaîne | L'ID de l'utilisateur ou du service principal dont le privilège a été utilisé pour exécuter l'instruction. |
|
|
| Tags clé-valeur personnalisés appliqués à la query pour le regroupement, le filtrage et l'attribution des coûts. Les tags peuvent être définis à l'aide de paramètres de configuration de session ou de l'instruction SQL |
|
Lecture des champs chiffrés
Aperçu
Cette fonctionnalité est en aperçu public.
Lorsque les espaces de travail utilisent des clés gérées par le client pour les services gérés, les champs statement_text et error_message de la table système sont chiffrés par default. Ceci est dû au fait que les tables système stockent des données provenant de tous les espaces de travail de la région et sont accessibles par ceux-ci. Pour déchiffrer et afficher les champs chiffrés des tables système, les administrateurs de compte doivent ajouter une configuration de clé au catalogue system lui-même. Vous devez disposer de l'autorisation MANAGE sur le catalogue system pour effectuer cette opération.
L'ajout d'une configuration de clé au catalogue system supprime toutes les subventions Unity Catalog que vous avez précédemment appliquées au schéma system.query et à la table system.query.history, les Reset à celles par default. Étant donné que les octrois se situent au niveau du metastore, cela affecte tous les Workspaces associés au metastore, y compris les Workspaces où vous n’avez pas exécuté la commande. Après avoir activé les clés gérées par le client, réappliquez toutes les autorisations personnalisées sur system.query et system.query.history.
Vous pouvez soit créer une configuration de clé, soit réutiliser une existante. Pour ajouter la clé au catalogue system, exécutez la commande suivante. Vous pouvez récupérer l'ID de la clé de chiffrement dans la console du compte en cliquant sur Sécurité , puis sur Clés de chiffrement , puis en ouvrant la configuration de clé que vous souhaitez utiliser.
curl -v -X PATCH https://my-workspace-url/api/2.1/unity-catalog/catalogs/system -H 'Authorization: Bearer <pat token>' --data '{
"managed_encryption_settings": {
"customer_managed_key_id": "<cmk id from account console>"
}
}'
Prévoyez jusqu'à 24 heures pour que system.query.history commence à afficher les champs chiffrés.
Le catalogue system est différent pour chaque metastore, de sorte que la clé gérée par le client doit être configurée séparément pour chaque metastore. Cependant, les métastores dans la même région peuvent être configurés pour utiliser la même clé.
Afficher le profil de la query pour un enregistrement
Pour naviguer vers le profil de query d'une query basé sur un enregistrement dans la table d'historique de query, procédez comme suit :
- Identifiez l'enregistrement d'intérêt, puis copiez le
statement_idde l'enregistrement. - Référencez le
workspace_idde l'enregistrement pour vous assurer que vous êtes connecté au même Workspace que l'enregistrement. - Cliquez
sur **Historique des query** dans la barre latérale du Workspace. - Dans le champ ID de l'instruction , collez le
statement_idsur l'enregistrement. - Cliquez sur le nom d'une query. Un aperçu des métriques de query apparaît.
- Cliquez sur **Afficher le profil de la query**.
Comprendre la colonne query_source
La colonne query_source contient un ensemble d'identifiants uniques des entités Databricks impliquées dans l'exécution de la déclaration.
Si la colonne query_source contient plusieurs ID, cela signifie que l'exécution de l'instruction a été Trigger par plusieurs entités. Par exemple, un résultat de Job peut Trigger une alerte qui appelle une SQL query. Dans cet exemple, les trois ID seront renseignés dans query_source. Les valeurs de cette colonne ne sont pas triées par ordre d'exécution.
Les sources de requêtes possibles sont :
- alert_id : Instruction déclenchée par une alerte
- **sql_query_id** : Instruction exécutée depuis cette session d' éditeur SQL.
- dashboard_id : instruction exécutée à partir d'un tableau de bord
- genie_space_id : instruction exécutée à partir d’un Genie Agent
- notebook_id : instruction exécutée à partir d'un Notebook
- job_info.job_id : Instruction exécutée dans un Job
- `job_info.ID_exécution_du_Job` : Instruction exécutée à partir d'une exécution de Job
- job_info.job_task_run_id : Instruction exécutée dans une exécution de tâche Job
Combinaisons valides de query_source
Les exemples suivants montrent comment la colonne query_source est renseignée en fonction de la manière dont la query est exécutée :
-
Les queries exécutées lors de l'exécution d'un Job incluent une structure
job_inforenseignée :{
alert_id: null,
sql_query_id: null,
dashboard_id: null,
notebook_id: null,
job_info: {
job_id: 64361233243479,
job_run_id: null,
job_task_run_id: 110378410199121
},
legacy_dashboard_id: null,
genie_space_id: null
} -
Les queries issues des alertes incluent un
sql_query_idetalert_id:{
alert_id: e906c0c6-2bcc-473a-a5d7-f18b2aee6e34,
sql_query_id: 7336ab80-1a3d-46d4-9c79-e27c45ce9a15,
dashboard_id: null,
notebook_id: null,
job_info: null,
legacy_dashboard_id: null,
genie_space_id: null
} -
Les requêtes provenant des tableaux de bord incluent un
dashboard_id, mais pas dejob_info:{
alert_id: null,
sql_query_id: null,
dashboard_id: 887406461287882,
notebook_id: null,
job_info: null,
legacy_dashboard_id: null,
genie_space_id: null
}