ジョブ システム テーブル リファレンス

この記事は、アカウントのジョブ アクティビティを記録する lakeflow システム テーブルのリファレンスです。 これらのテーブルには、同じクラウド リージョン内にデプロイされたアカウント内のすべてのワークスペースのレコードが含まれます。 別のリージョンのレコードを表示するには、そのリージョンにデプロイされているワークスペースのテーブルを表示する必要があります。

Requirements

• これらのシステム テーブルにアクセスするには、ユーザーは次のいずれかを行う必要があります。
  • メタストア管理者とアカウント管理者の両方であるか、または
  • システム スキーマに対する USE 権限と SELECT 権限を持つ。 システム テーブルへのアクセス権の付与を参照してください。

利用可能な仕事のテーブル

ジョブ関連のすべてのシステム テーブルは、 system.lakeflow スキーマに格納されます。 現在、このスキーマによって、次の 4 つのテーブルがホストされています。

詳細なスキーマ リファレンス

次のセクションでは、ジョブ関連の各システム テーブルのスキーマ参照について説明します。

ジョブテーブルスキーマ

jobs テーブルは、緩やかに変化するディメンション テーブル (SCD2) です。 行が変更されると、新しい行が出力され、前の行が論理的に置き換えられます。

テーブル パス: system.lakeflow.jobs

クエリの例

-- 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

ジョブのタスク テーブル スキーマ

ジョブ タスク テーブルは、緩やかに変化するディメンション テーブル (SCD2) です。 行が変更されると、新しい行が出力され、前の行が論理的に置き換えられます。

テーブル パス: system.lakeflow.job_tasks

クエリの例

-- 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

ジョブ実行のタイムライン テーブル スキーマ

ジョブ実行タイムライン テーブルは変更不可であり、作成時に完了します。

テーブル パス: system.lakeflow.job_run_timeline

クエリの例

-- 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;

ジョブ タスク実行のタイムライン テーブル スキーマ

ジョブタスク実行タイムライン テーブルは変更不可であり、作成時に完了します。

テーブル パス: system.lakeflow.job_task_run_timeline

Pipelines テーブル スキーマ

パイプライン テーブルは、緩やかに変化するディメンション テーブル (SCD2) です。 行が変更されると、新しい行が出力され、前の行が論理的に置き換えられます。

テーブル パス: system.lakeflow.pipelines

クエリの例

-- 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

パイプライン更新タイムラインのテーブルスキーマ

パイプライン更新タイムライン テーブルは変更不可であり、作成時に完了します。

テーブル パス: system.lakeflow.pipeline_update_timeline

クエリの例

-- 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

一般的な結合パターン

次のセクションでは、ジョブ システム テーブルでよく使用される結合パターンを強調表示するサンプル クエリを示します。

ジョブテーブルとジョブ実行タイムラインテーブルを結合する

ジョブ名を使用してジョブ実行をエンリッチする

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)

ジョブ実行タイムラインと使用状況テーブルを結合する

ジョブ実行メタデータを使用して各ログをエンリッチする

次のクエリは、クラシック ジョブとサーバーレス ジョブの両方のジョブ実行メタデータを使用して課金ログを強化します。

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

ジョブ実行あたりのコストを計算する

このクエリは、billing.usage システム テーブルと結合して、ジョブの実行あたりのコストを計算します。

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

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
  )

ジョブ タスクの実行タイムラインとクラスター テーブルを結合する

クラスター メタデータを使用してジョブ タスクの実行を強化する

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)

汎用コンピューティングで実行されているジョブを検索する

このクエリは、 compute.clusters システム テーブルと結合し、Jobs Compute ではなく All-Purpose Compute で実行されている最近のジョブを返します。

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;

過去 30 日間に実行されていないジョブを見つける

このクエリは、 lakeflow.jobs テーブルと lakeflow.job_run_timeline システム テーブルを結合して、過去 30 日間実行されていないジョブを返します。

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

ジョブ監視ダッシュボード

次のダッシュボードでは、システム テーブルを使用して、ジョブと運用の正常性の監視を開始できます。 これには、ジョブ パフォーマンスの追跡、障害の監視、リソース使用率などの一般的なユース ケースが含まれます。

ダッシュボードのダウンロードの詳細については、「システム テーブル を使用したジョブ コスト & パフォーマンスの監視」を参照してください。

Troubleshooting

ジョブが lakeflow.jobs テーブルにログに記録されていない

ジョブがシステム テーブルに表示されない場合:

• 過去 365 日間にジョブが変更されませんでした
  • スキーマに存在するジョブのフィールドを変更して、新しいレコードを出力します。
• ジョブが別のリージョンで作成されました
• 最近のジョブ作成（テーブルの遅延）

job_run_timeline テーブルに表示されるジョブが見つかりません

すべてのジョブ実行がどこでも表示されるわけではありません。 JOB_RUN エントリはすべてのジョブ関連テーブルに表示されますが、WORKFLOW_RUN (ノートブック ワークフローの実行) は job_run_timeline にのみ記録され、SUBMIT_RUN (1 回限りの実行) は両方のタイムライン テーブルにのみ記録されます。 これらの実行は、jobs や job_tasksなどの他のジョブ システム テーブルには入力されません。

実行の 各種類 が表示され、アクセス可能な場所の詳細については、以下の実行の種類の表を参照してください。

ジョブ実行が billing.usage テーブルに表示されない

system.billing.usageでは、usage_metadata.job_id は、ジョブ コンピューティングまたはサーバーレス コンピューティングで実行されるジョブに対してのみ設定されます。

さらに、WORKFLOW_RUN ジョブには、usage_metadata.job_idに独自の usage_metadata.job_run_id や system.billing.usage 属性はありません。 代わりに、コンピューティング使用量は、それらをトリガーした親ノートブックに起因します。 つまり、ノートブックがワークフロー実行を起動すると、すべてのコンピューティング コストが、個別のワークフロー ジョブとしてではなく、親ノートブックの使用状況の下に表示されます。

詳細については、「使用状況メタデータ リファレンス」を参照してください。

汎用コンピューティングで実行されているジョブのコストを計算する

100% の精度では、専用コンピューティングで実行されるジョブの正確なコスト計算はできません。 対話型 (万能) コンピューティングでジョブを実行する場合、ノートブック、SQL クエリ、その他のジョブなどの複数のワークロードは、多くの場合、同じコンピューティング リソースで同時に実行されます。 クラスター リソースは共有されるため、コンピューティング コストと個々のジョブ実行の間に直接 1 対 1 のマッピングはありません。

正確なジョブ コストの追跡のために、Databricks では、専用のジョブ コンピューティングまたはサーバーレス コンピューティングでジョブを実行することをお勧めします。ここで、usage_metadata.job_id と usage_metadata.job_run_id により正確なコスト属性が可能になります。

万能コンピューティングを使用する必要がある場合は、次のことができます。

• system.billing.usageに基づいて、クラスターの全体的な使用状況と usage_metadata.cluster_id のコストを監視します。
• ジョブ ランタイム メトリックを個別に追跡します。
• コスト見積もりは、共有リソースが原因で概算されることを検討してください。

コスト属性の詳細については、「使用状況メタデータ リファレンス」を参照してください。

参照値

次のセクションでは、ジョブ関連テーブルの選択列の参照を示します。

タイムライン テーブルのスライス ロジック

period_start_timeテーブルとperiod_end_timeテーブルのjob_run_timeline列とjob_task_run_timeline列には、ジョブ実行またはタスク実行のアクティブな期間が記録されます。

:::warning 重要な変更

2026年1月19日以降、タイムラインテーブルに生成される新しい行では、クロック時刻に揃えたスライスロジックを使用します。 既存の行は変更されません。

スライスは、実行の開始時刻に基づいて 1 時間間隔で作成されます。 たとえば、午後4時47分開始のジョブでは、午後4時47分から5時47分、午後5時47分から6時47分などの時間区切りが作成されます。

スライスはクロック時間の境界に合わせて配置されます。 たとえば、ジョブが午後4時47分に始まると、16時47分から17時まで、17時から18時まで、18時から19時までといったスライスを作成します。 詳細については クロック時間と整列したスライスロジックを参照してください。

:::

各行は、最大 1 時間のランタイムを記録します。 1 時間を超える実行は、複数の行に記録されます。 このスライスにより、実行時間の長いジョブを監視するための時間単位の細分性が確保されます。

実行時間の短いジョブ

実行時間が 1 時間未満の場合は、1 つの行が出力され、 period_start_time は実行の開始時刻に設定され、 period_end_time は実行の終了時刻に設定されます。

たとえば、ジョブが午後 12 時 13 分 (UTC) に開始され、午後 12 時 45 分 (UTC) に終了したジョブは、1 行で表されます。

実行時間の長いジョブ

1 時間を超える実行の場合、複数の行が同じ run_idで出力され、それぞれが実行の期間の最大 1 時間を表します。

• 最初の行は、実行の実際の開始時刻から開始し、最初の実行時間の終わりに終了します。
• 中間行がある場合、前のスライスperiod_end_timeに合わせて、完全な1時間単位のウィンドウ全体にわたって配置されます。
• 最後の行は、前のスライスの先頭から始まり、実行の実際の終了時刻で終了します。

たとえば、午後 4 時 47 分 (UTC) から午後 8 時 28 分 (UTC) まで実行されたジョブは、複数の行にスライスされます。 各行は、最後の行を除いて 1 時間のアクティビティを表します。これは短い場合があります。

クロック時間に合わせたスライスロジック

2026 年 1 月 19 日以降、タイムラインテーブルでは、時間ごとに揃えられたスライシングが使用されます。 すべてのタイム スライスは、標準クロック時間の境界に合わせて調整されます。

同じクロック時間内に開始および終了するジョブ実行が 1 時間未満の場合、1 行が出力されます。

時刻の境界を越えるジョブの実行の場合、複数の行が出力され、その分割は時刻に合わせて配置されます。

• 最初の行は、実行の実際の開始時刻から始まり、次のクロック時間の境界で終了します。
• 中間行 (ある場合) は、完全なクロック時間にまたがります。 たとえば、午後 2:00~3:00、午後 3:00~4:00 などです。
• 最後の行はクロック時間の境界から始まり、実行の実際の終了時刻で終了します。

たとえば、午前 1 時 25 分から午前 3 時 40 分までの UTC で実行されたジョブの実行時間は、3 つの行に分割されます。

トリガーの種類の値

job_run_timelineテーブルでは、trigger_type列に使用できる値は次のとおりです。

• CONTINUOUS
• CRON
• FILE_ARRIVAL
• ONETIME
• ONETIME_RETRY

Run の種類の値

job_run_timelineテーブルでは、run_type列に使用できる値は次のとおりです。

結果の状態値

job_task_run_timelineテーブルとjob_run_timelineテーブルでは、result_state列に使用できる値は次のとおりです。

終了コード値

job_task_run_timelineテーブルとjob_run_timelineテーブルでは、termination_code列に使用できる値は次のとおりです。

パイプラインの種類の値

pipelinesテーブルでは、pipeline_type列に使用できる値は次のとおりです。

パイプラインの結果リファレンス

pipeline_update_timelineテーブルでは、result_state列に使用できる値は次のとおりです。

• COMPLETED
• FAILED
• CANCELED

パイプライン設定リファレンス

pipelinesテーブルでは、settings列に使用できる値は次のとおりです。

パイプライン更新タイプの値

pipeline_update_timelineテーブルでは、update_type列に使用できる値は次のとおりです。

• API_CALL
• RETRY_ON_FAILURE
• SERVICE_UPGRADE
• SCHEMA_CHANGE
• JOB_TASK
• USER_ACTION
• DBSQL_REQUEST
• SETTINGS_CHANGE
• SCHEMA_EXPLORATION
• INFRASTRUCTURE_MAINTENANCE
• START_RESOURCES

パイプライン トリガーの種類の値

pipeline_update_timelineテーブルでは、trigger_type列に使用できる値は次のとおりです。

パイプライン トリガーの種類の詳細

pipeline_update_timeline テーブルでは、trigger_type.job_task構造体に使用できる値は次のとおりです。