Référence de la table système des Jobs
Le schéma lakeflow était anciennement appelé workflow. Le contenu des deux schémas est identique.
Cet article est une référence pour les tables système lakeflow, qui enregistrent l'activité des Jobs dans votre compte. Ces tables incluent des enregistrements de tous les workspaces de votre compte déployés dans la même région cloud. Pour voir les enregistrements d'une autre région, vous devez afficher les tables d'un workspace déployé dans cette région.
Exigences
- Pour accéder à ces tables système, les utilisateurs doivent :
- Soyez à la fois administrateur du métastore et administrateur du compte, ou
- Avoir les permissions
USEetSELECTsur les schémas système. Voir Autoriser l'accès aux tables système.
Tables de jobs disponibles
Toutes les tables systèmes liées au job se trouvent dans le schéma system.lakeflow. Actuellement, le schéma héberge six tables :
Table | Description | Prend en charge le streaming | Période de conservation gratuite | Comprend des données mondiales ou régionales |
|---|---|---|---|---|
Suit tous les Jobs créés dans le compte. | Oui | 365 jours | Régional | |
Suit toutes les tâches de Job qui s'exécutent dans le compte. | Oui | 365 jours | Régional | |
Suit les exécutions de job et les métadonnées associées | Oui | 365 jours | Régional | |
Suit les exécutions de tâches de Job et les métadonnées associées | Oui | 365 jours | Régional | |
pipelines (Aperçu public) | Suit tous les pipelines créés dans le compte | Oui | 365 jours | Régional |
pipeline_update_timeline (Aperçu public) | Suit les mises à jour du pipeline et les métadonnées associées. | Oui | 365 jours | Régional |
En plus de la période de rétention de 365 jours, Databricks conserve l'enregistrement le plus récent pour chaque entité dans les tables de dimension à évolution lente (SCD2) (jobs, job_tasks et pipelines). Cela signifie que la dernière entrée historique pour chaque job_id, job_task ou pipeline_id est toujours disponible, même si elle date de plus de 365 jours. Les enregistrements au-delà de la période de 365 jours, autres que la dernière entrée par entité, sont supprimés.
Référence de schéma détaillée
Les sections suivantes fournissent des références de schéma pour chacune des tables système liées aux jobs.
Schéma de la table des tâches
La table jobs est une table de dimension à évolution lente (SCD2). Lorsqu'une ligne change, une nouvelle ligne est émise, remplaçant logiquement la précédente.
Chemin de la table : system.lakeflow.jobs
Nom de colonne | Type de données | Description | Notes |
|---|---|---|---|
| chaîne | L'ID du compte auquel ce Job appartient. | |
| chaîne | L'ID du Workspace auquel appartient ce Job | |
| chaîne | L'ID du Job | Unique uniquement au sein d'un seul Workspace |
| chaîne | Le nom du Job fourni par l'utilisateur | |
| chaîne | La description du job fournie par l'utilisateur | Ce champ est vide si vous avez des clés gérées par le client configurées. |
| chaîne | L'ID du mandant qui a créé le Job | |
| Carte | Les tags personnalisés fournis par l'utilisateur associés à ce Job | |
| Horodatage | L'heure à laquelle le job a été modifié pour la dernière fois | Fuseau horaire enregistré comme +00:00 (UTC) |
| Horodatage | L'heure à laquelle le Job a été supprimé par l'utilisateur. | Fuseau horaire enregistré comme +00:00 (UTC) |
| chaîne | L'ID de l'utilisateur ou du Service Principal dont les autorisations sont utilisées pour la mise à jour du pipeline | |
| structure | La configuration du trigger pour le job |
|
| chaîne | Le type de Trigger pour le Job |
|
| tableau | L'ensemble complet de toutes les configurations de trigger pour le job, chacune avec la même structure que | Renseigné pour tous les Job avec des Trigger. Lorsqu'un job a plusieurs triggers, cette colonne inclut la seule vue complète de toutes les configurations de trigger. |
| chaîne | L'e-mail de l'utilisateur, l'ID du Service Principal ou le nom du groupe dont les autorisations sont utilisées pour l'exécution du Job | Non renseigné pour les lignes émises avant début décembre 2025 |
| chaîne | L’e-mail de l’utilisateur, l’ID du Service Principal ou le nom du groupe qui a créé le Job | Non renseigné pour les lignes émises avant début décembre 2025 |
| booléen | Indique si le job est en pause | Non renseigné pour les lignes émises avant début décembre 2025 |
| long | La durée du délai d'expiration du job en secondes | Non renseigné pour les lignes émises avant début décembre 2025 |
| tableau | Ensemble de règles d'intégrité définies pour ce Job | Non renseigné pour les lignes émises avant début décembre 2025 |
| structure | information de déploiement pour les Jobs gérés par des sources externes | Non renseigné pour les lignes émises avant début décembre 2025 |
| Horodatage | L'heure à laquelle ce job a été créé. Fuseau horaire enregistré comme +00:00 (UTC). | Non renseigné pour les lignes émises avant début décembre 2025 |
Exemple de query
-- Get the most recent version of a job
SELECT
*,
ROW_NUMBER() OVER(PARTITION BY workspace_id, job_id ORDER BY change_time DESC) as rn
FROM
system.lakeflow.jobs QUALIFY rn=1
Pour renvoyer une ligne par trigger, y compris les jobs avec plusieurs triggers, développez le tableau triggers :
SELECT
workspace_id,
job_id,
trigger.*
FROM (
SELECT
*,
ROW_NUMBER() OVER(PARTITION BY workspace_id, job_id ORDER BY change_time DESC) as rn
FROM system.lakeflow.jobs QUALIFY rn=1
)
LATERAL VIEW EXPLODE(triggers) AS trigger
Schéma de table de la tâche Job
La table des tâches du Job est une table de dimensions à évolution lente (SCD2). Lorsqu'une ligne change, une nouvelle ligne est émise, remplaçant logiquement la précédente.
Chemin de la table : system.lakeflow.job_tasks
Nom de colonne | Type de données | Description | Notes |
|---|---|---|---|
| chaîne | L'ID du compte auquel ce Job appartient. | |
| chaîne | L'ID du Workspace auquel appartient ce Job | |
| chaîne | L'ID du Job | Unique uniquement au sein d'un seul Workspace |
| chaîne | La clé de référence pour une tâche dans un Job | Unique uniquement dans un seul Job. |
| tableau | Les clés de tâche de toutes les dépendances en amont de cette tâche | |
| Horodatage | L’heure de la dernière modification de la tâche | Fuseau horaire enregistré comme +00:00 (UTC) |
| Horodatage | L'heure à laquelle une tâche a été supprimée par l'utilisateur | Fuseau horaire enregistré comme +00:00 (UTC) |
| long | Le délai d'expiration de la tâche en secondes. | Non renseigné pour les lignes émises avant début décembre 2025 |
| tableau | Ensemble de règles de santé définies pour cette Job tâche | Non renseigné pour les lignes émises avant début décembre 2025 |
Exemple de query
-- Get the most recent version of a job task
SELECT
*,
ROW_NUMBER() OVER(PARTITION BY workspace_id, job_id ORDER BY change_time DESC) as rn
FROM
system.lakeflow.job_tasks QUALIFY rn=1
Schéma de table de la chronologie des exécutions de job
La table de la chronologie d'exécution du Job est immuable et complète au moment de sa production.
Chemin de la table : system.lakeflow.job_run_timeline
Nom de colonne | Type de données | Description | Notes |
|---|---|---|---|
| chaîne | L'ID du compte auquel ce Job appartient. | |
| chaîne | L'ID du Workspace auquel appartient ce Job | |
| chaîne | L'ID du Job | Cette clé n'est unique qu'au sein d'un seul Workspace |
| chaîne | L'ID de l'exécution du job | |
| Horodatage | L'heure de start pour l'exécution ou pour la période | Les informations de fuseau horaire sont enregistrées à la fin de la valeur, |
| Horodatage | L'heure de fin de l'exécution ou de la période. | Les informations de fuseau horaire sont enregistrées à la fin de la valeur, |
| chaîne | Le type de trigger qui peut déclencher une exécution | Pour les valeurs possibles, consultez Valeurs de type de trigger |
| chaîne | Le type d'exécution de job | Pour les valeurs possibles, consultez Valeurs de type d'exécution |
| chaîne | Le nom d'exécution fourni par l'utilisateur associé à cette exécution de job | |
| tableau | Tableau contenant les ID de compute de job pour l'exécution de job parente | Utilisez pour identifier le cluster de Jobs utilisé par les types d'exécution |
| chaîne | Le résultat de l'exécution du Job | Pour les exécutions de plus d'une heure réparties sur plusieurs lignes, cette colonne n'est remplie que dans la ligne qui représente la fin de l'exécution. Pour connaître les valeurs possibles, consultez les valeurs d'état des résultats. |
| chaîne | Code de fin d’exécution du Job | Pour les exécutions de plus d'une heure réparties sur plusieurs lignes, cette colonne n'est remplie que dans la ligne qui représente la fin de l'exécution. Pour les valeurs possibles, voir les valeurs des codes de terminaison. |
| Carte | Les paramètres au niveau du job utilisés dans l'exécution du job | Contient uniquement les valeurs des paramètres de tâche. Les champs de paramètres obsolètes ( |
| chaîne | L'ID de l'exécution de la tâche source. Utilisez cette colonne pour identifier quelle exécution de tâche a déclenché cette exécution de job. | Non renseigné pour les lignes émises avant début décembre 2025 |
| chaîne | ID de l'exécution de la tâche racine. Utilisez cette colonne pour identifier quelle exécution de tâche a déclenché cette exécution de job. | Non renseigné pour les lignes émises avant début décembre 2025 |
| tableau | Détails concernant les ressources de compute utilisées lors de l'exécution du job. | Non renseigné pour les lignes émises avant début décembre 2025 |
| chaîne | Le type d'arrêt de l'exécution du job. | Non renseigné pour les lignes émises avant début décembre 2025 |
| long | Durée de la phase de configuration pour l'exécution du job en secondes | Non renseigné pour les lignes émises avant début décembre 2025 |
| long | La durée passée dans la file d'attente pour l'exécution du Job, en secondes. | Non renseigné pour les lignes émises avant début décembre 2025 |
| long | La durée totale de l'exécution du Job en secondes | Non renseigné pour les lignes émises avant début décembre 2025 |
| long | La durée de la phase de nettoyage pour l'exécution du job en secondes | Non renseigné pour les lignes émises avant début décembre 2025 |
| long | La durée de la phase d'exécution pour l'exécution du job en secondes | Non renseigné pour les lignes émises avant début décembre 2025 |
Exemple de query
-- This query gets the daily job count for a workspace for the last 7 days:
SELECT
workspace_id,
COUNT(DISTINCT run_id) as job_count,
to_date(period_start_time) as date
FROM system.lakeflow.job_run_timeline
WHERE
period_start_time > CURRENT_TIMESTAMP() - INTERVAL 7 DAYS
GROUP BY ALL
-- This query returns the daily job count for a workspace for the last 7 days, distributed by the outcome of the job run.
SELECT
workspace_id,
COUNT(DISTINCT run_id) as job_count,
result_state,
to_date(period_start_time) as date
FROM system.lakeflow.job_run_timeline
WHERE
period_start_time > CURRENT_TIMESTAMP() - INTERVAL 7 DAYS
AND result_state IS NOT NULL
GROUP BY ALL
-- This query returns the average time of job runs, measured in seconds. The records are organized by job. A top 90 and a 95 percentile column show the average lengths of the job's longest runs.
with job_run_duration as (
SELECT
workspace_id,
job_id,
run_id,
CAST(SUM(period_end_time - period_start_time) AS LONG) as duration
FROM
system.lakeflow.job_run_timeline
WHERE
period_start_time > CURRENT_TIMESTAMP() - INTERVAL 7 DAYS
GROUP BY ALL
)
SELECT
t1.workspace_id,
t1.job_id,
COUNT(DISTINCT t1.run_id) as runs,
MEAN(t1.duration) as mean_seconds,
AVG(t1.duration) as avg_seconds,
PERCENTILE(t1.duration, 0.9) as p90_seconds,
PERCENTILE(t1.duration, 0.95) as p95_seconds
FROM
job_run_duration t1
GROUP BY ALL
ORDER BY mean_seconds DESC
LIMIT 100
-- This query provides a historical runtime for a specific job based on the `run_name` parameter. For the query to work, you must set the `run_name`.
SELECT
workspace_id,
run_id,
SUM(period_end_time - period_start_time) as run_time
FROM system.lakeflow.job_run_timeline
WHERE
run_type="SUBMIT_RUN"
AND run_name = :run_name
AND period_start_time > CURRENT_TIMESTAMP() - INTERVAL 60 DAYS
GROUP BY ALL
-- This query collects a list of retried job runs with the number of retries for each run.
with repaired_runs as (
SELECT
workspace_id, job_id, run_id, COUNT(*) - 1 as retries_count
FROM system.lakeflow.job_run_timeline
WHERE result_state IS NOT NULL
GROUP BY ALL
HAVING retries_count > 0
)
SELECT
*
FROM repaired_runs
ORDER BY retries_count DESC
LIMIT 10;
Schéma de table chronologique d'exécution de la tâche Job
La table de chronologie d'exécution des tâches du Job est immuable et complète au moment de sa production.
Chemin de la table : system.lakeflow.job_task_run_timeline
Nom de colonne | Type de données | Description | Notes |
|---|---|---|---|
| chaîne | L'ID du compte auquel ce Job appartient. | |
| chaîne | L'ID du Workspace auquel appartient ce Job | |
| chaîne | L'ID du Job | Unique uniquement au sein d'un seul Workspace |
| chaîne | L'ID de l'exécution de la tâche | |
| chaîne | L'ID de l'exécution du job | |
| chaîne | L’ID de l’exécution parent | |
| Horodatage | L'heure de start de la tâche ou de la période | Les informations de fuseau horaire sont enregistrées à la fin de la valeur, |
| Horodatage | L'heure de fin de la tâche ou de la période. | Les informations de fuseau horaire sont enregistrées à la fin de la valeur, |
| chaîne | La clé de référence pour une tâche dans un Job | Cette clé n'est unique qu'au sein d'un seul Job |
| tableau | Le tableau compute_ids contient les ID des clusters de Job, des clusters interactifs et des SQL Warehouses utilisés par la tâche de Job | |
| chaîne | Le résultat de l'exécution de la tâche du Job | Pour les exécutions de tâches de plus d'une heure qui sont réparties sur plusieurs lignes, cette colonne n'est renseignée que dans la ligne qui représente la fin de l'exécution. Pour connaître les valeurs possibles, consultez les valeurs d'état des résultats. |
| chaîne | Le code de terminaison de l'exécution de la tâche | Pour les exécutions de tâches de plus d'une heure qui sont réparties sur plusieurs lignes, cette colonne n'est renseignée que dans la ligne qui représente la fin de l'exécution. Pour les valeurs possibles, voir les valeurs des codes de terminaison. |
| tableau | Détails sur les ressources de compute utilisées dans l'exécution de la tâche du job | Non renseigné pour les lignes émises avant début décembre 2025 |
| chaîne | Le type de terminaison pour l'exécution de la tâche du Job. | Non renseigné pour les lignes émises avant début décembre 2025 |
| Carte | Les parameters au niveau de la tâche utilisés lors de l'exécution de la tâche du Job | Contient uniquement les valeurs des paramètres de tâche. Les champs de paramètre obsolètes ( |
| long | La durée de la phase de configuration pour l'exécution de la tâche en secondes | Non renseigné pour les lignes émises avant début décembre 2025 |
| long | La durée de la phase de nettoyage pour l’exécution de la tâche en secondes | Non renseigné pour les lignes émises avant début décembre 2025 |
| long | La durée de la phase d'exécution pour l'exécution de la tâche en secondes | Non renseigné pour les lignes émises avant début décembre 2025 |
Schéma de la table de pipelines
La table pipelines est une table de dimension à évolution lente (SCD2). Lorsqu'une ligne change, une nouvelle ligne est émise, remplaçant logiquement la précédente.
Chemin de la table : system.lakeflow.pipelines
Nom de colonne | Type de données | Description | Notes |
|---|---|---|---|
| chaîne | L'ID du compte auquel appartient ce pipeline | |
| chaîne | L'ID du Workspace auquel ce pipeline appartient | |
| chaîne | L'ID du pipeline | Unique uniquement au sein d'un seul Workspace |
| chaîne | Le type du pipeline | Pour les valeurs possibles, voir Valeurs de type de pipeline |
| chaîne | Le nom du pipeline fourni par l'utilisateur | |
| chaîne | L'e-mail de l'utilisateur, l'ID du Service Principal ou le nom du groupe qui a créé le pipeline. | |
| chaîne | L'e-mail de l'utilisateur, l'ID du Service Principal ou le nom du groupe dont les autorisations sont utilisées pour l'exécution du pipeline | |
| Carte | Les tags personnalisés fournis par l'utilisateur associés à ce Job | |
| structure | Les paramètres du pipeline | |
| Carte | La configuration du pipeline fournie par l'utilisateur | |
| Horodatage | L'heure de la dernière modification du pipeline | Fuseau horaire enregistré comme +00:00 (UTC) |
| Horodatage | L’heure à laquelle le pipeline a été supprimé par l’utilisateur | Fuseau horaire enregistré comme +00:00 (UTC) |
| Horodatage | Le moment où un pipeline a été créé par l'utilisateur. Fuseau horaire enregistré comme +00:00 (UTC). | Non renseigné pour les lignes émises avant début décembre 2025 |
Exemple de query
-- Get the most recent version of a pipeline
SELECT
*,
ROW_NUMBER() OVER(PARTITION BY workspace_id, pipeline_id ORDER BY change_time DESC) as rn
FROM
system.lakeflow.pipelines QUALIFY rn=1
-- Enrich billing logs with pipeline metadata
with latest_pipelines AS (
SELECT
*,
ROW_NUMBER() OVER(PARTITION BY workspace_id, pipeline_id ORDER BY change_time DESC) as rn
FROM
system.lakeflow.pipelines QUALIFY rn=1
)
SELECT
usage.*,
pipelines.*
FROM system.billing.usage
LEFT JOIN latest_pipelines
ON (usage.workspace_id = pipelines.workspace_id
AND usage.usage_metadata.dlt_pipeline_id = pipelines.pipeline_id)
WHERE
usage.usage_metadata.dlt_pipeline_id IS NOT NULL
Schéma de la table de chronologie de mise à jour du pipeline
La table de chronologie des mises à jour du pipeline est immuable et complète au moment de sa production.
Chemin de la table : system.lakeflow.pipeline_update_timeline
Nom de colonne | Type de données | Description | Notes |
|---|---|---|---|
| chaîne | L'ID du compte auquel appartient ce pipeline | |
| chaîne | L'ID du Workspace auquel ce pipeline appartient | |
| chaîne | L'ID du pipeline | Unique uniquement au sein d'un seul Workspace |
| chaîne | L'ID de la mise à jour du pipeline | Unique uniquement au sein d'un seul Workspace |
| chaîne | Le type de mise à jour du pipeline | Pour les valeurs possibles, voir Valeurs de type de mise à jour du pipeline |
| chaîne | L'ID de la demande. Permet de comprendre combien de fois une mise à jour a dû être relancée/redémarrée | |
| chaîne | L'e-mail de l'utilisateur, l'ID du Service Principal, ou le nom du groupe dont les autorisations sont utilisées pour la mise à jour du pipeline | |
| chaîne | Qu'est-ce qui a Trigger cette mise à jour ? | Pour les valeurs possibles, consultez Valeurs de type de Trigger de pipeline |
| structure | Les détails du trigger du pipeline | Pour les valeurs possibles, voir détails du type de Trigger de pipeline |
| chaîne | Le résultat de la mise à jour du pipeline | Pour les mises à jour s'exécutant sur plus d'une heure et réparties sur plusieurs lignes, cette colonne n'est renseignée que dans la ligne qui représente la fin de la mise à jour. Pour les valeurs possibles, consultez la référence des résultats de pipeline. |
| structure | Détails sur la ressource compute utilisée dans la mise à jour du pipeline | |
| Horodatage | L'heure de start de la mise à jour du pipeline ou de l'heure. La valeur est stockée en tant que timestamp UTC. | Les informations de fuseau horaire sont enregistrées à la fin de la valeur, |
| Horodatage | L'heure de fin pour la mise à jour du pipeline ou pour l'heure. La valeur est stockée en tant que timestamp UTC. | Les informations de fuseau horaire sont enregistrées à la fin de la valeur, |
| tableau | Une liste de tables à mettre à jour sans fullRefresh | |
| tableau | Une liste de tables à mettre à jour avec fullRefresh | |
| tableau | Une liste de flux de streaming pour effacer les points de contrôle |
Exemple de query
-- This query gets the daily pipeline update count for a workspace for the last 7 days:
SELECT
workspace_id,
COUNT(DISTINCT update_id) as update_count,
to_date(period_start_time) as date
FROM system.lakeflow.pipeline_update_timeline
WHERE
period_start_time > CURRENT_TIMESTAMP() - INTERVAL 7 DAYS
GROUP BY ALL
-- This query returns the daily pipeline update count for a workspace for the last 7 days, distributed by the outcome of the pipeline update.
SELECT
workspace_id,
COUNT(DISTINCT update_id) as update_count,
result_state,
to_date(period_start_time) as date
FROM system.lakeflow.pipeline_update_timeline
WHERE
period_start_time > CURRENT_TIMESTAMP() - INTERVAL 7 DAYS
AND result_state IS NOT NULL
GROUP BY ALL
-- This query returns the average time of pipeline updates, measured in seconds. The records are organized by pipeline. A top 90 and a 95 percentile column show the average lengths of the pipeline's longest updates.
with pipeline_update_duration as (
SELECT
workspace_id,
pipeline_id,
update_id,
CAST(SUM(period_end_time - period_start_time) AS LONG) as duration
FROM
system.lakeflow.pipeline_update_timeline
WHERE
period_start_time > CURRENT_TIMESTAMP() - INTERVAL 7 DAYS
GROUP BY ALL
)
SELECT
t1.workspace_id,
t1.pipeline_id,
COUNT(DISTINCT t1.update_id) as update_count,
MEAN(t1.duration) as mean_seconds,
AVG(t1.duration) as avg_seconds,
PERCENTILE(t1.duration, 0.9) as p90_seconds,
PERCENTILE(t1.duration, 0.95) as p95_seconds
FROM
pipeline_update_duration t1
GROUP BY ALL
ORDER BY mean_seconds DESC
LIMIT 100
Modèles de jointure courants
Les sections suivantes fournissent des exemples de requêtes qui mettent en évidence les modèles de jointure couramment utilisés pour les tables système des Jobs.
Joindre les tables de chronologie des jobs et des exécutions de job
Enrichir l'exécution de Job avec un nom de Job
with jobs as (
SELECT
*,
ROW_NUMBER() OVER (PARTITION BY workspace_id, job_id ORDER BY change_time DESC) as rn
FROM system.lakeflow.jobs QUALIFY rn=1
)
SELECT
job_run_timeline.*
jobs.name
FROM system.lakeflow.job_run_timeline
LEFT JOIN jobs USING (workspace_id, job_id)
Joindre la chronologie d'exécution du job et les tables d'utilisation
Enrichir chaque Log de facturation avec des métadonnées d’exécution de Job
La requête suivante enrichit les Logs de facturation avec les métadonnées d'exécution de job des jobs classiques et Serverless :
with aggregated_job_runs AS (
SELECT
j.workspace_id,
COALESCE(t.job_id, j.job_id) as origin_job_id,
COALESCE(t.job_run_id, j.run_id) AS origin_job_run_id,
j.job_id as billing_job_id,
j.run_id as billing_run_id,
CASE WHEN j.root_task_run_id IS NOT NULL THEN true ELSE false END AS is_workflow_run
FROM
system.lakeflow.job_run_timeline j
LEFT JOIN
system.lakeflow.job_task_run_timeline t
ON
j.workspace_id = t.workspace_id
AND j.root_task_run_id = t.run_id
WHERE j.period_start_time >= CURRENT_DATE() - INTERVAL 7 DAYS
GROUP BY ALL
),
billing_logs_enriched AS (
SELECT
t2.origin_job_id,
t2.origin_job_run_id,
t1.*
FROM system.billing.usage t1
INNER JOIN aggregated_job_runs t2
ON t1.workspace_id = t2.workspace_id
AND t1.usage_metadata.job_id = t2.billing_job_id
AND t1.usage_metadata.job_run_id = t2.billing_run_id
WHERE
billing_origin_product="JOBS" AND usage_date >= CURRENT_DATE() - INTERVAL 7 DAYS
)
SELECT
workspace_id,
origin_job_id AS job_id,
origin_job_run_id AS run_id,
sku_name,
SUM(usage_quantity) as total_usage_quantity,
SUM(CASE WHEN usage_metadata.job_run_id != origin_job_run_id THEN usage_quantity ELSE 0 END) AS workflow_run_usage_quantity,
COUNT(DISTINCT usage_metadata.job_run_id) - 1 AS workflow_runs
FROM billing_logs_enriched
GROUP BY ALL
Calculer le coût par exécution de job
Cette query joint avec la table système billing.usage pour calculer un coût par exécution de job.
with jobs_usage AS (
SELECT
*,
usage_metadata.job_id,
usage_metadata.job_run_id as run_id,
identity_metadata.run_as as run_as
FROM system.billing.usage
WHERE billing_origin_product="JOBS"
),
jobs_usage_with_usd AS (
SELECT
jobs_usage.*,
usage_quantity * pricing.default as usage_usd
FROM jobs_usage
LEFT JOIN system.billing.list_prices pricing ON
jobs_usage.sku_name = pricing.sku_name
AND pricing.price_start_time <= jobs_usage.usage_start_time
AND (pricing.price_end_time >= jobs_usage.usage_start_time OR pricing.price_end_time IS NULL)
AND pricing.currency_code="USD"
),
jobs_usage_aggregated AS (
SELECT
workspace_id,
job_id,
run_id,
FIRST(run_as, TRUE) as run_as,
sku_name,
SUM(usage_usd) as usage_usd,
SUM(usage_quantity) as usage_quantity
FROM jobs_usage_with_usd
GROUP BY ALL
)
SELECT
t1.*,
MIN(period_start_time) as run_start_time,
MAX(period_end_time) as run_end_time,
FIRST(result_state, TRUE) as result_state
FROM jobs_usage_aggregated t1
LEFT JOIN system.lakeflow.job_run_timeline t2 USING (workspace_id, job_id, run_id)
GROUP BY ALL
ORDER BY usage_usd DESC
LIMIT 100
Obtenir les logs d'utilisation pour les jobs SUBMIT_RUN
SELECT
*
FROM system.billing.usage
WHERE
EXISTS (
SELECT 1
FROM system.lakeflow.job_run_timeline
WHERE
job_run_timeline.job_id = usage_metadata.job_id
AND run_name = :run_name
AND workspace_id = :workspace_id
)
Joindre la chronologie d'exécution des tâches de Job et les tables de clusters
Enrichir les exécutions de tâches de job avec les métadonnées des clusters
with clusters as (
SELECT
*,
ROW_NUMBER() OVER (PARTITION BY workspace_id, cluster_id ORDER BY change_time DESC) as rn
FROM system.compute.clusters QUALIFY rn=1
),
exploded_task_runs AS (
SELECT
*,
EXPLODE(compute_ids) as cluster_id
FROM system.lakeflow.job_task_run_timeline
WHERE array_size(compute_ids) > 0
)
SELECT
*
FROM exploded_task_runs t1
LEFT JOIN clusters t2
USING (workspace_id, cluster_id)
Rechercher les jobs exécutés sur le compute multifonction
Cette query se joint à la table système compute.clusters pour renvoyer les Jobs récents qui s'exécutent sur du compute polyvalent au lieu du compute de Jobs.
with clusters AS (
SELECT
*,
ROW_NUMBER() OVER(PARTITION BY workspace_id, cluster_id ORDER BY change_time DESC) as rn
FROM system.compute.clusters
WHERE cluster_source="UI" OR cluster_source="API"
QUALIFY rn=1
),
job_tasks_exploded AS (
SELECT
workspace_id,
job_id,
EXPLODE(compute_ids) as cluster_id
FROM system.lakeflow.job_task_run_timeline
WHERE period_start_time >= CURRENT_DATE() - INTERVAL 30 DAY
GROUP BY ALL
),
all_purpose_cluster_jobs AS (
SELECT
t1.*,
t2.cluster_name,
t2.owned_by,
t2.dbr_version
FROM job_tasks_exploded t1
INNER JOIN clusters t2 USING (workspace_id, cluster_id)
)
SELECT * FROM all_purpose_cluster_jobs LIMIT 10;
Trouver les jobs qui n'ont pas été exécutés au cours des 30 derniers jours
Cette query joint les tables système lakeflow.jobs et lakeflow.job_run_timeline pour renvoyer les Jobs qui n'ont pas été exécutés au cours des 30 derniers jours.
with latest_jobs AS (
SELECT
*,
ROW_NUMBER() OVER (PARTITION BY workspace_id, job_id ORDER BY change_time DESC) as rn
FROM system.lakeflow.jobs QUALIFY rn=1
),
latest_not_deleted_jobs AS (
SELECT
workspace_id,
job_id,
name,
change_time,
tags
FROM latest_jobs WHERE delete_time IS NULL
),
last_seen_job_timestamp AS (
SELECT
workspace_id,
job_id,
MAX(period_start_time) as last_executed_at
FROM system.lakeflow.job_run_timeline
WHERE
run_type="JOB_RUN"
GROUP BY ALL
)
SELECT
t1.workspace_id,
t1.job_id,
t1.name,
t1.change_time as last_modified_at,
t2.last_executed_at,
t1.tags
FROM latest_not_deleted_jobs t1
LEFT JOIN last_seen_job_timestamp t2
USING (workspace_id, job_id)
WHERE
(t2.last_executed_at <= CURRENT_DATE() - INTERVAL 30 DAYS) OR (t2.last_executed_at IS NULL)
ORDER BY last_executed_at ASC
Tableau de bord de monitoring des tâches
Le tableau de bord suivant utilise des tables système pour vous aider à start le monitoring de vos jobs et de votre santé opérationnelle. Il comprend des cas d'utilisation courants, tels que le suivi des performances des jobs, le monitoring des défaillances et l'utilisation des ressources.
Pour des informations sur le download du tableau de bord, consultez Surveiller les coûts et les performances des Job avec les tables système
Dépannage
Le Job n'est pas journalisé dans la table lakeflow.jobs
Si un job n'est pas visible dans les tables système :
- Le job a été créé dans une région différente.
- Création de job récente (retard de table)
- Bien que le dernier enregistrement pour chaque
job_idsoit toujours conservé, les enregistrements historiques plus anciens au-delà de la fenêtre de rétention de 365 jours sont supprimés. Si vous avez besoin d'un nouvel enregistrement, modifiez l'un des champs du job présents dans le schéma pour émettre une nouvelle ligne.
Impossible de trouver un Job vu dans la table job_run_timeline
Toutes les exécutions de job ne sont pas visibles partout. Alors que les entrées JOB_RUN apparaissent dans toutes les tables liées aux Jobs, les WORKFLOW_RUN (exécutions de workflows de Notebook) sont enregistrées uniquement dans job_run_timeline et les SUBMIT_RUN (exécutions soumises une seule fois) sont enregistrées uniquement dans les deux tables chronologiques. Ces exécutions ne sont pas renseignées dans d'autres tables du système de Job comme jobs ou job_tasks.
Consultez le tableau des Types d'exécution ci-dessous pour une ventilation détaillée de l'endroit où chaque type d'exécution est visible et accessible.
Exécution de Job non visible dans la table billing.usage
Dans system.billing.usage, le usage_metadata.job_id n'est renseigné que pour les Jobs qui s'exécutent sur le compute de Job ou le compute Serverless.
De plus, les jobs WORKFLOW_RUN n'ont pas leur propre attribution usage_metadata.job_id ou usage_metadata.job_run_id dans system.billing.usage.
Au lieu de cela, leur consommation de compute est attribuée au notebook parent qui les a déclenchés.
Cela signifie que lorsqu'un Notebook lance l'exécution d'un workflow, tous les coûts de compute apparaissent sous l'utilisation du Notebook parent, et non comme un Job de workflow distinct.
Pour plus d’informations, consultez la référence des métadonnées d’utilisation.
Calculer le coût d'un job exécuté sur un compute multifonction
Le calcul précis des coûts pour les jobs exécutés sur du compute dédié n'est pas possible avec une exactitude de 100 %. Lorsqu'un job s'exécute sur un compute interactif (polyvalent), plusieurs charges de travail, telles que des Notebooks, des queries SQL ou d'autres jobs, s'exécutent souvent simultanément sur la même ressource de compute. Étant donné que les Ressources des clusters sont partagées, il n'y a pas de correspondance directe de 1:1 entre les coûts de calcul et les exécutions de Job individuelles.
Pour un suivi précis des coûts des jobs, Databricks recommande d'exécuter les jobs sur un compute de job dédié ou un compute serverless, où les usage_metadata.job_id et usage_metadata.job_run_id permettent une attribution précise des coûts.
Si vous devez utiliser un compute multifonction, vous pouvez :
- Supervisez l'utilisation globale des clusters et les coûts dans
system.billing.usageen fonction deusage_metadata.cluster_id. - Suivre les métriques d'exécution des jobs séparément.
- Considérez que toute estimation des coûts sera approximative en raison des ressources partagées.
Voir la référence des métadonnées d'utilisation pour plus d'information sur l'attribution des coûts.
Valeurs de référence
La section suivante comprend des références pour certaines colonnes dans les tables liées aux Jobs.
Logique de découpage dans les tables de chronologie
Les colonnes period_start_time et period_end_time des tables job_run_timeline et job_task_run_timeline enregistrent la période active d’une exécution de job ou d’une exécution de tâche.
:::warning Changement important
À partir du 19 janvier 2026, les nouvelles lignes émises vers les tables de chronologie utiliseront une logique de découpage alignée sur l'heure. Les lignes existantes resteront inchangées.
Les tranches sont créées à intervalles d'une heure en fonction de l'heure de start de l'exécution. Par exemple, un Job commençant à 16 h 47 crée des tranches de 16 h 47 à 17 h 47, de 17 h 47 à 18 h 47, et ainsi de suite.
Les tranches s'aligneront sur les limites horaires. Par exemple, un Job démarrant à 16 h 47 créera des tranches de 16 h 47 à 17 h 00, de 17 h 00 à 18 h 00, de 18 h 00 à 19 h 00, et ainsi de suite. Consultez la logique de découpage alignée sur l'heure pour plus de détails.
:::
Chaque ligne enregistre jusqu'à une heure de temps d'exécution. Les exécutions qui durent plus d'une heure sont enregistrées sur plusieurs lignes. Ce découpage assure une granularité horaire pour le monitoring des Jobs de longue durée.
Si une exécution n'a jamais démarré, elle est représentée par une ligne où period_start_time est égal à period_end_time. Cela indique qu'il n'y a pas d'exécution active. Pour comprendre pourquoi l'exécution n'a pas start, vérifiez la colonne termination_code.
Jobs de courte durée
Pour les exécutions de moins d’une heure, une seule ligne est émise, avec period_start_time défini sur l’heure de start de l’exécution et period_end_time défini sur l’heure de fin de l’exécution.
Par exemple, un Job démarré à 12:13 UTC et terminé à 12:45 UTC est représenté par une seule ligne :
workspace_id | job_id | run_id | period_start_time | period_end_time |
|---|---|---|---|---|
6 051 921 418 418 893 | 280090038844882 | 174 832 649 710 507 | 2025-06-08T12:13:01.605 | 2025-06-08T12:45:06.009 |
Jobs de longue durée
Pour les exécutions d’une durée supérieure à 1 heure, plusieurs lignes sont émises avec le même run_id, chacune représentant jusqu’à une heure de la durée de l’exécution :
- La première ligne commence à l'heure de start réelle de l'exécution et se termine à la fin de la première heure d'exécution.
- Les lignes intermédiaires (le cas échéant) couvrent des fenêtres horaires complètes, alignées sur la tranche précédente
period_end_time. - La dernière ligne start au début de la tranche précédente et se termine à l'heure de fin réelle de l'exécution.
Par exemple, un job qui s'est exécuté de 16:47 UTC à 20:28 UTC est divisé en plusieurs lignes. Chaque ligne représente une heure d'activité, à l'exception de la dernière ligne, qui peut être plus courte :
workspace_id | job_id | run_id | period_start_time | period_end_time |
|---|---|---|---|---|
6 051 921 418 418 893 | 280090038844882 | 55408597258956 | 2025-07-01T16:47:55.992 | 2025-07-01T17:47:56.434 |
6 051 921 418 418 893 | 280090038844882 | 55408597258956 | 2025-07-01T17:47:56.434 | 2025-07-01T18:47:58.876 |
6 051 921 418 418 893 | 280090038844882 | 55408597258956 | 2025-07-01T18:47:58.876 | 2025-07-01T19:47:59.682 |
6 051 921 418 418 893 | 280090038844882 | 55408597258956 | 2025-07-01T19:47:59.682 | 01.07.2025T20:28:29.743 |
Logique de découpage alignée sur l'heure
Cette logique de découpage s'applique aux nouvelles lignes dans les tables de chronologie des Job à partir du 19 janvier 2026 .
À partir du 19 janvier 2026, les tables de chronologie utilisent un découpage aligné sur l'heure. Toutes les tranches horaires s'alignent sur les limites des heures d'horloge standard.
Pour les exécutions de Job de moins de 1 heure qui start et se terminent au cours de la même heure, une seule ligne est émise :
workspace_id | job_id | run_id | period_start_time | period_end_time |
|---|---|---|---|---|
6 051 921 418 418 893 | 280090038844882 | 174 832 649 710 507 | 08.12.2025 12:13:01.605 | 08-12-2025T12:45:06.009 |
Pour les exécutions de Jobs qui dépassent les limites horaires, plusieurs lignes sont émises avec des tranches alignées sur les heures :
- La première ligne start à l'heure de début réelle de l'exécution et se termine à la limite horaire suivante.
- Les lignes intermédiaires (le cas échéant) couvrent des heures complètes. Par exemple : de 14 h 00 à 15 h 00 et de 15 h 00 à 16 h 00.
- La dernière ligne start à une limite horaire et se termine à l'heure de fin réelle de l'exécution.
Par exemple, l'exécution d'un Job qui a eu lieu de 1 h 25 UTC à 3 h 40 UTC est divisée en trois lignes :
workspace_id | job_id | run_id | period_start_time | period_end_time |
|---|---|---|---|---|
6 051 921 418 418 893 | 280090038844882 | 55408597258956 | 2025-12-01T01:25:00.000 | 2025-12-01T02:00:00.000 |
6 051 921 418 418 893 | 280090038844882 | 55408597258956 | 2025-12-01T02:00:00.000 | 2025-12-01T03:00:00.000 |
6 051 921 418 418 893 | 280090038844882 | 55408597258956 | 2025-12-01T03:00:00.000 | 2025-12-01T03:40:00.000 |
Valeurs de type de Trigger
Pour plus d'informations sur les types de déclencheurs de Job, veuillez consulter Automatiser les Jobs avec des planifications et des déclencheurs.
Dans les tables job_run_timeline et jobs, les valeurs possibles pour la colonne trigger_type sont :
Type de Trigger | Description | Tables applicables |
|---|---|---|
| Le Job ou l'exécution est déclenché(e) par un Trigger continu qui maintient le Job en cours d'exécution. |
|
| Le Job ou l'exécution est Trigger sur un calendrier récurrent à l'aide de la syntaxe cron. |
|
| Le Job ou l’exécution est Trigger lorsque de nouveaux fichiers arrivent dans un emplacement de stockage configuré. |
|
| Le Job ou l'exécution est Trigger par un événement de service de version de modèle. |
|
| Le job a deux triggers ou plus. La colonne |
|
| L'exécution du job a été déclenchée manuellement ou par un trigger d'API unique. |
|
| Le Job ou l'exécution a été Trigger comme une nouvelle tentative d'une exécution précédente ayant échoué. |
|
| Le Job ou l'exécution est Trigger par un planning périodique basé sur un intervalle de temps (par exemple, toutes les heures). |
|
| L'exécution du Job a été Trigger dans le cadre d'une tâche d'exécution de Job à partir d'un autre Job. |
|
| Le Job ou l'exécution est déclenché par une mise à jour de table à l'aide d'une configuration de Trigger de table. |
|
| Le type de trigger n'est pas défini. Cela peut se produire pour les anciens enregistrements de job ou les jobs dont le type de trigger n'a pas été configuré. |
|
Valeurs de type d'exécution
Dans le tableau job_run_timeline, les valeurs possibles pour la colonne run_type sont :
Type | Description | Emplacement de l'interface utilisateur | Endpoint d'API | Tables système |
|---|---|---|---|---|
| Exécution de Job standard | Interface utilisateur des Jobs et des Exécutions de Job | /Job et /Job/runs Endpoint | jobs, job_tasks, job_run_timeline, job_task_run_timeline |
| Exécution unique via POST /jobs/runs/submit | Interface utilisateur des exécutions de Job uniquement | /jobs/runs endpoints uniquement | job_run_timeline, job_task_run_timeline |
| Exécution lancée depuis le workflow du notebook | Non visible | Non accessible | job_run_timeline |
Valeurs d'état des résultats
Dans les tables job_task_run_timeline et job_run_timeline, les valeurs possibles pour la colonne result_state sont :
État | Description |
|---|---|
| L'exécution s'est terminée avec succès. |
| L'exécution s'est terminée avec une erreur. |
| L’exécution n’a jamais été effectuée car une condition n’a pas été remplie. |
| L'exécution a été annulée à la demande de l'utilisateur. |
| L'exécution a été arrêtée après avoir atteint le délai d'expiration. |
| L'exécution s'est terminée avec une erreur. |
| L'exécution a été bloquée par une dépendance en amont. |
| La ligne représente une tranche intermédiaire d'un Job de longue durée. Le |
Valeurs du code de terminaison
Dans les tables job_task_run_timeline et job_run_timeline, les valeurs possibles pour la colonne termination_code sont :
Code de fin d'exécution | Description |
|---|---|
| L'exécution s'est terminée avec succès. |
| L'exécution a été annulée pendant son déroulement par la plateforme Databricks ; par exemple, si la durée maximale d'exécution a été dépassée. |
| L’exécution n’a jamais été effectuée, par exemple, si l’exécution de la tâche en amont a échoué, si la condition du type de dépendance n’a pas été remplie ou s’il n’y avait pas de tâches matérielles à exécuter. |
| L'exécution a rencontré une erreur lors de la communication avec le Spark Driver. |
| L'exécution a échoué en raison d'une erreur de cluster. |
| Échec de la finalisation du paiement en raison d'une erreur de communication avec le service tiers. |
| L'exécution a échoué car elle a émis une requête invalide pour start le cluster. |
| Le Workspace a atteint le quota pour le nombre maximal d'exécutions actives simultanées. Envisagez de planifier les exécutions sur une période plus longue. |
| L'exécution a échoué car elle a tenté d'accéder à une fonctionnalité indisponible pour le Workspace. |
| Le nombre de demandes de création, de start et d'augmentation de taille de cluster a dépassé la limite de taux allouée. Envisagez de répartir le temps d’exécution sur une plage horaire plus large. |
| L'exécution a échoué en raison d'une erreur lors de l'accès au stockage blob du client. |
| L’exécution s’est terminée avec des échecs de tâche. |
| L'exécution a échoué en raison d'un problème d'autorisation lors de l'accès à une ressource. |
| L'exécution a échoué lors de l'installation de la bibliothèque demandée par l'utilisateur. Les causes peuvent inclure, sans s'y limiter : la bibliothèque fournie est invalide, ou les autorisations sont insuffisantes pour installer la bibliothèque. |
| L'exécution planifiée dépasse la limite du nombre maximal d'exécutions simultanées définie pour le job. |
| L'exécution est planifiée sur un cluster qui a déjà atteint le nombre maximal de contextes qu'il est configuré pour créer. |
| Une ressource nécessaire à l'exécution n'existe pas. |
| L'exécution a échoué en raison d'une configuration non valide. |
| L'exécution a échoué en raison d'un problème lié au fournisseur de cloud. |
| L'exécution a été ignorée en raison de l'atteinte de la limite de taille de la file d'attente au niveau du Job. |
Valeurs de type de pipeline
Dans le tableau pipelines, les valeurs possibles pour la colonne pipeline_type sont :
Type de pipeline | Description |
|---|---|
| pipeline standard |
| |
| |
| |
|
Référence de résultat de pipeline
Dans le tableau pipeline_update_timeline, les valeurs possibles pour la colonne result_state sont :
COMPLETEDFAILEDCANCELED
Référence des paramètres de pipeline
Dans le tableau pipelines, les valeurs possibles pour la colonne settings sont :
Valeur | Description |
|---|---|
| Un indicateur indiquant s'il faut utiliser Photon pour exécuter le pipeline |
| Un indicateur indiquant s’il faut exécuter le pipeline en mode développement ou production |
| Un indicateur spécifiant s'il faut exécuter le pipeline en continu |
| Un indicateur spécifiant si le pipeline doit être exécuté sur un cluster Serverless |
| L'édition de produit pour exécuter le pipeline |
| La version de l'environnement d'exécution de la pipeline à utiliser |
Types de valeurs de mise à jour de pipeline
Dans le tableau pipeline_update_timeline, les valeurs possibles pour la colonne update_type sont :
FULL_REFRESHREFRESHVALIDATE
Types de valeurs de Trigger de pipeline
Dans le tableau pipeline_update_timeline, les valeurs possibles pour la colonne trigger_type sont :
API_CALLRETRY_ON_FAILURESERVICE_UPGRADESCHEMA_CHANGEJOB_TASKUSER_ACTIONDBSQL_REQUESTSETTINGS_CHANGESCHEMA_EXPLORATIONINFRASTRUCTURE_MAINTENANCESTART_RESOURCES
Détails du type de trigger de pipeline
Lorsque le type de Trigger du pipeline est JOB_TASK, alors le trigger_type.details est rempli avec les valeurs suivantes :
Valeur | Description | Notes |
|---|---|---|
| L'ID du Job qui a déclenché la mise à jour du pipeline | La valeur |
| L'ID de l'exécution de la tâche du Job qui a déclenché la mise à jour du pipeline. | La valeur |
| Rempli uniquement pour les mises à jour de pipeline serverless | Soit |