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

注記

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

注記

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

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

必要条件

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

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

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

テーブル	説明	ストリーミングをサポート	無料保存期間	グローバルまたは地域データを含む
jobs (パブリックプレビュー)	アカウントで作成されたすべてのジョブを追跡します	あり	365日	リージョン
job_tasks (パブリックプレビュー)	アカウントで実行されるすべてのジョブタスクを追跡します	あり	365日	リージョン
job_run_timeline (パブリックプレビュー)	ジョブの実行と関連するメタデータを追跡します	あり	365日	リージョン
job_task_run_timeline (パブリックプレビュー)	ジョブタスクの実行と関連するメタデータを追跡します	あり	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

クエリの例

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) として記録されたタイムゾーン

クエリの例

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`	マップ	ジョブ実行で使用されるジョブ・レベルのパラメーター	非推奨のノートブック設定は、このフィールドに含まれません。

クエリの例

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

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

パイプラインテーブルは、ゆっくりと変化する寸法テーブル (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) として記録されたタイムゾーン

クエリの例

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
SELECT
    t1.*,
    t2.*
FROM system.billing.usage t1
    LEFT JOIN system.lakeflow.job_run_timeline t2
        ON t1.workspace_id = t2.workspace_id
            AND t1.usage_metadata.job_id = t2.job_id
            AND t1.usage_metadata.job_run_id = t2.run_id
            AND t1.usage_start_time >= date_trunc("Hour", t2.period_start_time)
            AND t1.usage_start_time < date_trunc("Hour", t2.period_end_time) + INTERVAL 1 HOUR
WHERE
    billing_origin_product="JOBS"

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

このクエリは、 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 列には、ジョブ実行またはタスク実行のアクティブ期間が記録されます。

各行には、最大 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

トリガーの種類の値

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`

必要条件​

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

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

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

クエリの例​

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

クエリの例​

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

クエリの例​

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

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

クエリの例​

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

クエリの例​

一般的な結合パターン​

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

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

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

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

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

SUBMIT_RUNジョブの使用状況ログを取得する​

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

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

汎用 コンピュートで実行されているジョブの特定​

過去 30 日間に実行されていないジョブを検索する​

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

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

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

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

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

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

リファレンス​

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

実行時間の短いジョブ​

実行時間の長いジョブ​

トリガーの種類の値​

実行タイプの値​

結果の状態の値​

終了コード値​

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

パイプライン結果参照​

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

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

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

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

必要条件

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

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

ジョブテーブルスキーマ

クエリの例

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

クエリの例

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

クエリの例

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

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

クエリの例

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

クエリの例

一般的な結合パターン

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

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

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

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

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

SUBMIT_RUNジョブの使用状況ログを取得する

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

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

汎用コンピュートで実行されているジョブの特定

過去 30 日間に実行されていないジョブを検索する

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

トラブルシューティング

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

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

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

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

リファレンス

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

実行時間の短いジョブ

実行時間の長いジョブ

トリガーの種類の値

実行タイプの値

結果の状態の値

終了コード値

パイプラインの種類の値

パイプライン結果参照

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

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

パイプライントリガータイプの値

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