メインコンテンツまでスキップ
に最終更新

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

注記

lakeflowスキーマは以前はworkflowと呼ばれていました。どちらのスキーマも内容は同じです。

注記

これらのテーブルはasia-south1リージョンでは使用できません。

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

必要条件​

  • これらのシステムテーブルにアクセスするには、ユーザーは次のいずれかを行う必要があります。

使用可能なジョブ テーブル​

ジョブ関連のすべてのシステムテーブルは、 system.lakeflow スキーマに存在します。 現在、スキーマは 4 つのテーブルをホストしています。

テーブル

説明

ストリーミングをサポート

無料保存期間

グローバルまたは地域データを含む

jobs

アカウントで作成されたすべてのジョブを追跡します

あり

365日

リージョン

ジョブタスク

アカウントで実行されるすべてのジョブタスクを追跡します

あり

365日

リージョン

ジョブ

ジョブの実行と関連するメタデータを追跡します

あり

365日

リージョン

ジョブタスク実行タイムライン

ジョブタスクの実行と関連するメタデータを追跡します

あり

365日

リージョン

パイプライン (パブリック プレビュー)

アカウントで作成されたすべてのパイプラインを追跡します

あり

365日

リージョン

pipeline_update_timeline (パブリックプレビュー)

パイプラインの更新と関連メタデータを追跡します

あり

365日

リージョン

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

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

ジョブ テーブル スキーマ​

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

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

列名

データ型

説明

注

account_id

string

このジョブが属するアカウントの ID

workspace_id

string

このジョブが属するワークスペースの ID

job_id

string

ジョブのID

1 つのワークスペース内でのみ一意

name

string

ユーザーが指定したジョブの名前

description

string

ユーザー指定のジョブの説明

このフィールドは、 顧客管理のキー が設定されている場合、空になります。

creator_id

string

ジョブを作成したプリンシパルの ID

tags

マップ

このジョブに関連付けられたユーザー指定のカスタムタグ

change_time

timestamp

ジョブが最後に変更された時刻

+00:00 (UTC) として記録されたタイムゾーン

delete_time

timestamp

ジョブがユーザーによって削除された時刻

+00:00 (UTC) として記録されたタイムゾーン

run_as

string

パイプラインの更新に権限が使用されるユーザーまたはサービスプリンシパルの ID

trigger

struct

ジョブのトリガー設定

2025 年 12 月初旬より前に発行された行は入力されません

trigger_type

string

ジョブのトリガーの種類

2025 年 12 月初旬より前に発行された行は入力されません

run_as_user_name

string

ジョブ実行に権限が使用されるユーザーの電子メールまたはサービスプリンシパルの ID

2025 年 12 月初旬より前に発行された行は入力されません

creator_user_name

string

ジョブを作成したユーザーの電子メールまたはサービスプリンシパルのID

2025 年 12 月初旬より前に発行された行は入力されません

paused

boolean

ジョブが停止するかどうかを示します

2025 年 12 月初旬より前に発行された行は入力されません

timeout_seconds

long

ジョブのタイムアウト期間（秒）

2025 年 12 月初旬より前に発行された行は入力されません

health_rules

array

このジョブに定義されたヘルスルールのセット

2025 年 12 月初旬より前に発行された行は入力されません

deployment

struct

外部ソースによって管理されるジョブの展開情報

2025 年 12 月初旬より前に発行された行は入力されません

create_time

timestamp

このジョブが作成された時刻。タイムゾーンは +00:00 (UTC) として記録されました。

2025 年 12 月初旬より前に発行された行は入力されません

クエリの例​

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

列名

データ型

説明

注

account_id

string

このジョブが属するアカウントの ID

workspace_id

string

このジョブが属するワークスペースの ID

job_id

string

ジョブのID

1 つのワークスペース内でのみ一意

task_key

string

ジョブ内のタスクの参照キー

1つのジョブ内でのみ一意

depends_on_keys

array

このタスクのすべてのアップストリーム依存関係のタスクキー

change_time

timestamp

タスクが最後に変更された時刻

+00:00 (UTC) として記録されたタイムゾーン

delete_time

timestamp

タスクがユーザーによって削除された時刻

+00:00 (UTC) として記録されたタイムゾーン

timeout_seconds

long

タスクのタイムアウト期間（秒）

2025 年 12 月初旬より前に発行された行は入力されません

health_rules

array

このジョブタスクに定義されたヘルスルールのセット

2025 年 12 月初旬より前に発行された行は入力されません

クエリの例​

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

列名

データ型

説明

注

account_id

string

このジョブが属するアカウントの ID

workspace_id

string

このジョブが属するワークスペースの ID

job_id

string

ジョブのID

このキーは、1 つのワークスペース内でのみ一意です

run_id

string

ジョブランのID

period_start_time

timestamp

実行または期間の開始時刻

タイムゾーン情報は、 +00:00 UTC を表す値の終わりに記録されます。Databricks が長い実行を時間間隔でスライスする方法の詳細については、「 タイムライン スライス ロジック」を参照してください。

period_end_time

timestamp

実行または期間の終了時刻

タイムゾーン情報は、 +00:00 UTC を表す値の終わりに記録されます。Databricks が長い実行を時間間隔でスライスする方法の詳細については、「 タイムライン スライス ロジック」を参照してください。

trigger_type

string

実行を起動できるトリガーの種類

使用可能な値については、「トリガーの種類の値」を参照してください

run_type

string

ジョブ実行のタイプ

使用可能な値については、「実行タイプの値」を参照してください

run_name

string

このジョブ実行に関連付けられたユーザー指定の実行名

compute_ids

array

親ジョブ実行のジョブ コンピュート ID を含む配列

WORKFLOW_RUN実行タイプで使用されるジョブ クラスタリングを識別するために使用します。その他のコンピュート情報については、 job_task_run_timeline 表を参照してください。

result_state

string

ジョブ実行の結果

1 時間を超える実行が複数の行に分割されている場合、この列は実行の終了を表す行にのみ入力されます。 使用可能な値については、 結果の状態の値を参照してください。

termination_code

string

ジョブ実行の終了コード

1 時間を超える実行が複数の行に分割されている場合、この列は実行の終了を表す行にのみ入力されます。 使用可能な値については、 終了コードの値を参照してください。

job_parameters

マップ

ジョブ実行で使用されるジョブ・レベルのパラメーター

job_parametersの値のみが含まれます。非推奨のフィールド ( notebook_params 、 python_params 、 python_named_params 、 spark_submit_params 、およびsql_params ) は含まれません。

source_task_run_id

string

ソース タスク実行の ID。この列を使用して、どのタスク実行がこのジョブ実行をトリガーしたかを識別します。

2025 年 12 月初旬より前に発行された行は入力されません

root_task_run_id

string

実行されたルート タスクの ID。この列を使用して、どのタスク実行がこのジョブ実行をトリガーしたかを識別します。

2025 年 12 月初旬より前に発行された行は入力されません

compute

array

ジョブ実行で使用されるコンピュート リソースの詳細

2025 年 12 月初旬より前に発行された行は入力されません

termination_type

string

ジョブ実行の終了タイプ

2025 年 12 月初旬より前に発行された行は入力されません

setup_duration_seconds

long

ジョブ実行のセットアップフェーズの所要時間（秒）

2025 年 12 月初旬より前に発行された行は入力されません

queue_duration_seconds

long

ジョブ実行のキュー内で費やされた時間（秒）

2025 年 12 月初旬より前に発行された行は入力されません

run_duration_seconds

long

ジョブ実行の合計時間（秒）

2025 年 12 月初旬より前に発行された行は入力されません

cleanup_duration_seconds

long

ジョブ実行のクリーンアップフェーズの継続時間（秒）

2025 年 12 月初旬より前に発行された行は入力されません

execution_duration_seconds

long

ジョブ実行フェーズの継続時間（秒）

2025 年 12 月初旬より前に発行された行は入力されません

クエリの例​

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

列名

データ型

説明

注

account_id

string

このジョブが属するアカウントの ID

workspace_id

string

このジョブが属するワークスペースの ID

job_id

string

ジョブのID

1 つのワークスペース内でのみ一意

run_id

string

タスク実行の ID

job_run_id

string

ジョブランのID

parent_run_id

string

親実行の ID

period_start_time

timestamp

タスクまたは期間の開始時刻

タイムゾーン情報は、 +00:00 UTC を表す値の終わりに記録されます。Databricks が長い実行を時間間隔でスライスする方法の詳細については、「 タイムライン スライス ロジック」を参照してください。

period_end_time

timestamp

タスクまたは期間の終了時刻

タイムゾーン情報は、 +00:00 UTC を表す値の終わりに記録されます。Databricks が長い実行を時間間隔でスライスする方法の詳細については、「 タイムライン スライス ロジック」を参照してください。

task_key

string

ジョブ内のタスクの参照キー

このキーは、1 つのジョブ内でのみ一意です

compute_ids

array

コンピュート配列には、ジョブ クラスター、対話型クラスター、およびジョブ タスクで使用される SQLウェアハウスの ID が含まれています

result_state

string

ジョブタスク実行の結果

1 時間を超えるタスク実行が複数の行に分割されている場合、この列は実行の終了を表す行にのみ入力されます。 使用可能な値については、 結果の状態の値を参照してください。

termination_code

string

タスク実行の終了コード

1 時間を超えるタスク実行が複数の行に分割されている場合、この列は実行の終了を表す行にのみ入力されます。 使用可能な値については、 終了コードの値を参照してください。

compute

array

ジョブタスク実行で使用されるコンピュートリソースの詳細

2025 年 12 月初旬より前に発行された行は入力されません

termination_type

string

ジョブタスク実行の終了タイプ

2025 年 12 月初旬より前に発行された行は入力されません

task_parameters

マップ

ジョブタスク実行で使用されるタスクレベルの問題

2025 年 12 月初旬より前に発行された行は入力されません

setup_duration_seconds

long

タスク実行のセットアップフェーズの所要時間（秒）

2025 年 12 月初旬より前に発行された行は入力されません

cleanup_duration_seconds

long

タスク実行のクリーンアップフェーズの継続時間（秒）

2025 年 12 月初旬より前に発行された行は入力されません

execution_duration_seconds

long

タスク実行フェーズの継続時間（秒）

2025 年 12 月初旬より前に発行された行は入力されません

パイプライン テーブル スキーマ​

パイプライン テーブルは、ゆっくりと変化する寸法テーブル (SCD2) です。 行が変更されると、新しい行が発行され、論理的に前の行が置き換えられます。

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

列名

データ型

説明

注

account_id

string

このパイプラインが属するアカウントの ID

workspace_id

string

このパイプラインが属するワークスペースの ID

pipeline_id

string

パイプラインの ID

1 つのワークスペース内でのみ一意

pipeline_type

string

パイプラインのタイプ

使用可能な値については、「パイプラインの種類の値」を参照してください

name

string

ユーザーが指定したパイプラインの名前

created_by

string

ユーザーの Eメール またはパイプラインを作成したサービスプリンシパルの ID

run_as

string

ユーザーの Eメール または、パイプラインの実行にアクセス許可が使用されているサービスプリンシパルの ID

tags

マップ

このジョブに関連付けられたユーザー指定のカスタムタグ

settings

struct

パイプラインの設定

「パイプライン設定」を参照してください。

configuration

マップ

ユーザー指定のパイプラインの構成

change_time

timestamp

パイプラインが最後に変更された時刻

+00:00 (UTC) として記録されたタイムゾーン

delete_time

timestamp

パイプラインがユーザーによって削除された時刻

+00:00 (UTC) として記録されたタイムゾーン

create_time

timestamp

ユーザーによってパイプラインが作成された時刻。タイムゾーンは +00:00 (UTC) として記録されました。

2025 年 12 月初旬より前に発行された行は入力されません

クエリの例​

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

列名

データ型

説明

注

account_id

string

このパイプラインが属するアカウントの ID

workspace_id

string

このパイプラインが属するワークスペースの ID

pipeline_id

string

パイプラインの ID

1 つのワークスペース内でのみ一意

update_id

string

パイプライン更新のID

1 つのワークスペース内でのみ一意

update_type

string

パイプライン更新の種類

可能な値については、パイプライン更新タイプの値を参照してください。

request_id

string

リクエストの ID。更新を何回再試行/再起動する必要があったかを把握するのに役立ちます

run_as_user_name

string

パイプラインの更新に権限が使用されているユーザーの電子メールまたはサービスプリンシパルの ID

trigger_type

string

このアップデートのきっかけ

可能な値については、パイプライントリガータイプの値を参照してください。

trigger_details

struct

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

可能な値については、パイプライントリガータイプの詳細を参照してください。

result_state

string

パイプライン更新の結果

1 時間を超えて複数の行に分割されて実行される更新の場合、この列は更新の終了を表す行にのみ入力されます。可能な値については、パイプライン結果リファレンスを参照してください。

compute

struct

パイプラインアップデートで使用するコンピュートリソースの詳細

period_start_time

timestamp

パイプラインの更新の開始時刻または時間。値は UTC タイムスタンプとして保存されます。

タイムゾーン情報は、 +00:00 UTC を表す値の終わりに記録されます。Databricks が長い実行を時間間隔でスライスする方法の詳細については、「 タイムライン スライス ロジック」を参照してください。

period_end_time

timestamp

パイプラインの更新または時間の終了時刻。値は UTC タイムスタンプとして保存されます。

タイムゾーン情報は、 +00:00 UTC を表す値の終わりに記録されます。Databricks が長い実行を時間間隔でスライスする方法の詳細については、「 タイムライン スライス ロジック」を参照してください。

refresh_selection

array

fullRefresh なしで更新するテーブルのリスト

full_refresh_selection

array

fullRefresh で更新するテーブルのリスト

reset_checkpoint_selection

array

チェックポイントをクリアするストリーミングフローのリスト

クエリの例​

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

一般的な結合パターン​

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

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

ジョブ名によるジョブ実行の強化​

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

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

各請求ログをジョブ実行メタデータで強化する​

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

SQL
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 システムテーブルと結合して、ジョブ実行あたりのコストを計算します。

SQL
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ジョブの使用状況ログを取得する​

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

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

クラスター メタデータによるジョブタスク実行の拡張​

SQL
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 システムテーブルと結合して、ジョブコンピュートではなく汎用コンピュートで実行されている最近のジョブを返します。

SQL
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 日間に実行されていないジョブを返します。

SQL
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

ジョブ モニタリングダッシュボード​

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

Lakeflow 可観測性ダッシュボード

Lakeflow Observability Dashboard ジョブの概要

ダッシュボードのダウンロードに関する情報については、システムテーブルによるジョブのコストとパフォーマンスの監視を参照してください。

トラブルシューティング​

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

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

汎用コンピュートで実行されるジョブのコストを計算する​

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

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

汎用コンピュートを使用する必要がある場合は、次のことができます。

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

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

リファレンス​

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

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

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

:::警告 重要な変更

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

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

スライスは時計の時間の境界に合わせて配置されます。たとえば、午後 4:47 に開始するジョブでは、午後 4:47 ～ 5:00、午後 5:00 ～ 6:00、午後 6:00 ～ 7:00 などのスライスが作成されます。詳細については、時刻に合わせたスライス ロジックを参照してください。

:::

各行には、最大 1 時間のランタイムが記録されます。 1 時間を超える実行は、複数の行に記録されます。このスライスにより、長時間実行されるモニタリングジョブの時間単位の粒度が保証されます。

注記

実行が開始されなかった場合は、 period_start_time が period_end_timeと等しい行で表されます。これは、アクティブなランタイムがないことを示します。実行が開始されなかった理由を理解するには、 termination_code 列を確認します。

実行時間の短いジョブ​

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

たとえば、ジョブが 12:13 PM UTC に開始され、12:45 PM UTC に終了したジョブは、次の 1 つの行で表されます。

workspace_id

job_id

run_id

period_start_time

period_end_time

6051921418418893

280090038844882

174832649710507

2025-06-08T12:13:01.605

2025-06-08T12:45:06.009

実行時間の長いジョブ​

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

  • 最初の行は、実行の実際の開始時刻から開始し、最初の実行時間の終了時に終了します。
  • 中間行 (存在する場合) は、前のスライス period_end_timeに揃えられた 1 時間ごとのウィンドウ全体にわたっています。
  • 最後の行は、前のスライスの先頭から始まり、実行の実際の終了時刻で終わります。

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

workspace_id

job_id

run_id

period_start_time

period_end_time

6051921418418893

280090038844882

55408597258956

2025-07-01T16:47:55.992

2025-07-01T17:47:56.434

6051921418418893

280090038844882

55408597258956

2025-07-01T17:47:56.434

2025-07-01T18:47:58.876

6051921418418893

280090038844882

55408597258956

2025-07-01T18:47:58.876

2025-07-01T19:47:59.682

6051921418418893

280090038844882

55408597258956

2025-07-01T19:47:59.682

2025-07-01T20:28:29.743

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

注記

このスライス ロジックは 、2026 年 1 月 19 日 以降のジョブ タイムライン テーブルの新しい行に適用されます。

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

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

workspace_id

job_id

run_id

period_start_time

period_end_time

6051921418418893

280090038844882

174832649710507

2025-12-08T12:13:01.605

2025-12-08T12:45:06.009

クロック時間の境界を越えるジョブ実行の場合、クロック時間に合わせてスライスされた複数の行が出力されます。

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

たとえば、UTC 午前 1 時 25 分から午前 3 時 40 分 (UTC) までに実行されるジョブ実行は、次の 3 行にスライスされます。

workspace_id

job_id

run_id

period_start_time

period_end_time

6051921418418893

280090038844882

55408597258956

2025-12-01T01:25:00.000

2025-12-01T02:00:00.000

6051921418418893

280090038844882

55408597258956

2025-12-01T02:00:00.000

2025-12-01T03:00:00.000

6051921418418893

280090038844882

55408597258956

2025-12-01T03:00:00.000

2025-12-01T03:40:00.000

トリガーの種類の値​

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

  • CONTINUOUS
  • CRON
  • FILE_ARRIVAL
  • ONETIME
  • ONETIME_RETRY

実行タイプの値​

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

タイプ

説明

UI の場所

API エンドポイント

システムテーブル

JOB_RUN

標準ジョブ実行

ジョブ & ジョブ 実行 UI

/jobs および /jobs/runs エンドポイント

jobs, job_tasks, job_run_timeline, job_task_run_timeline

SUBMIT_RUN

POST /jobs/runs/submitによる1回限りの実行

ジョブは UI のみを実行します

/ジョブ/実行エンドポイントのみ

job_run_timeline, job_task_run_timeline

WORKFLOW_RUN

ノートブックワークフローから開始された実行

非表示

アクセス権がありません

ジョブ

結果の状態の値​

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

状態

説明

SUCCEEDED

実行は正常に完了しました。

FAILED

実行はエラーで完了しました。

SKIPPED

条件が満たされなかったため、実行は実行されませんでした。

CANCELLED

ユーザーの要求により、実行が取り消されました。

TIMED_OUT

タイムアウトに達した後、実行が停止されました。

ERROR

実行はエラーで完了しました。

BLOCKED

実行はアップストリームの依存関係でブロックされました。

NULL

このローは、実行時間の長いジョブの中間スライスを表します。result_stateは、実行の終了を表す行でのみ使用できます。

終了コード値​

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

終了コード

説明

SUCCESS

実行は正常に完了しました。

CANCELLED

実行は、Databricks プラットフォームによる実行中にキャンセルされました。たとえば、最大実行時間を超えた場合です。

SKIPPED

実行が実行されなかった (たとえば、アップストリーム タスクの実行が失敗した場合、依存関係タイプの条件が満たされなかった場合、または実行するマテリアル タスクがなかった場合)。

DRIVER_ERROR

Spark ドライバーとの通信中に、実行でエラーが発生しました。

CLUSTER_ERROR

クラスタリング エラーのため、実行に失敗しました。

REPOSITORY_CHECKOUT_FAILED

サードパーティサービスとの通信中にエラーが発生したため、チェックアウトを完了できませんでした。

INVALID_CLUSTER_REQUEST

クラスタリングを開始するための無効な要求を発行したため、実行が失敗しました。

WORKSPACE_RUN_LIMIT_EXCEEDED

ワークスペースが、並列 active 実行の最大数のクォータに達しました。 より長い時間枠での実行をスケジュールすることを検討してください。

FEATURE_DISABLED

ワークスペースで使用できない機能にアクセスしようとしたため、実行が失敗しました。

CLUSTER_REQUEST_LIMIT_EXCEEDED

クラスタリングの作成要求、開始要求、およびアップサイズ要求の数が、割り当てられたレート制限を超えました。 実行の実行をより大きな時間枠に分散することを検討してください。

STORAGE_ACCESS_ERROR

顧客の BLOB ストレージへのアクセス中にエラーが発生したため、実行が失敗しました。

RUN_EXECUTION_ERROR

実行はタスクの失敗で完了しました。

UNAUTHORIZED_ERROR

リソースへのアクセス中にアクセス許可の問題があったため、実行が失敗しました。

LIBRARY_INSTALLATION_ERROR

ユーザーが要求したライブラリのインストール中に実行が失敗しました。原因には、提供されたライブラリが無効である、またはライブラリをインストールするためのアクセス許可が不十分であることが含まれますが、これらに限定されません。

MAX_CONCURRENT_RUNS_EXCEEDED

スケジュールされた実行が、ジョブに設定された最大並列実行の制限を超えています。

MAX_SPARK_CONTEXTS_EXCEEDED

実行は、作成するように設定されているコンテキストの最大数にすでに達しているクラスタリングでスケジュールされます。

RESOURCE_NOT_FOUND

実行の実行に必要なリソースが存在しません。

INVALID_RUN_CONFIGURATION

構成が無効なため、実行が失敗しました。

CLOUD_FAILURE

クラウド プロバイダーの問題により、実行が失敗しました。

MAX_JOB_QUEUE_SIZE_EXCEEDED

ジョブ・レベルのキュー・サイズ制限に達したため、実行はスキップされました。

パイプラインの種類の値​

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

パイプラインタイプ

説明

ETL_PIPELINE

標準パイプライン

MATERIALIZED_VIEW

Databricks SQLのマテリアライズドビュー

STREAMING_TABLE

Databricks SQL のストリーミングテーブル

INGESTION_PIPELINE

Lakeflowコネクト インジェスター

INGESTION_GATEWAY

Lakeflowコネクト ゲートウェイインジェスター

パイプライン結果参照​

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

  • COMPLETED
  • FAILED
  • CANCELED

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

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

Value

説明

photon

Photonを使用してパイプラインを実行するかどうかを示すフラグ

development

パイプラインを開発モードと本番運用モードのどちらで実行するかを示すフラグ

continuous

パイプラインを連続して実行するかどうかを示すフラグ

serverless

サーバレス クラスターでパイプラインを実行するかどうかを示すフラグ

edition

パイプラインを実行するための製品エディション

channel

使用するパイプライン ランタイムのバージョン

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

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 列に指定できる値は次のとおりです。

Value

説明

job_task

パイプラインの更新をトリガーしたjob_taskの詳細

パイプライントリガータイプの詳細​

pipeline_update_timelineテーブルでは、 trigger_type.job_task構造体の可能な値は次のとおりです。

Value

説明

注

job_id

パイプラインの更新をトリガーしたジョブのID

SQL_SCHEDULE値は、このjob_task SQL コードの一部としてスケジュールされていることを示します。

job_task_run_id

パイプラインの更新をトリガーしたジョブタスク実行のID

SQL_SCHEDULE値は、このjob_task SQL コードの一部としてスケジュールされていることを示します。

performance_target

サーバレス パイプライン更新の場合にのみ設定されます

PERFORMANCE_OPTIMIZEDまたは STANDARD