Informazioni di riferimento sulla tabella di sistema dei processi

Questo articolo è un riferimento su come utilizzare le tabelle di sistema lakeflow per monitorare i processi nel tuo account. Queste tabelle includono record di tutte le aree di lavoro nell'account distribuito nella stessa area cloud. Per visualizzare i record di un'altra area, è necessario visualizzare le tabelle da un'area di lavoro distribuita in tale area.

Requisiti

• Lo schema system.lakeflow deve essere abilitato da un amministratore dell'account. Vedere Abilitare gli schemi di tabella di sistema.
• Per accedere a queste tabelle di sistema, gli utenti devono:
  • Essere sia un amministratore del metastore che un amministratore dell'account oppure
  • Disporre delle autorizzazioni USE e SELECT per gli schemi di sistema. Vedere Concedere l'accesso alle tabelle di sistema.

Tabelle delle posizioni disponibili

Tutte le tabelle di sistema correlate ai processi si trovano nello system.lakeflow schema. Attualmente, lo schema ospita quattro tabelle:

Informazioni di riferimento dettagliate sullo schema

Nelle sezioni seguenti vengono forniti riferimenti degli schemi per ogni tabella di sistema correlata ai lavori.

Schema della tabella lavori

La tabella jobs è una tabella delle dimensioni a modifica lenta (SCD2). Quando una riga viene modificata, viene generata una nuova riga, sostituendo logicamente quella precedente.

percorso tabella: system.lakeflow.jobs

Query di esempio

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

Schema della tabella delle attività processo

La tabella delle attività lavorative è una tabella delle dimensioni a modifica lenta (SCD2). Quando una riga viene modificata, viene generata una nuova riga, sostituendo logicamente quella precedente.

percorso tabella: system.lakeflow.job_tasks

Query di esempio

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

Schema della tabella sequenza temporale dell'esecuzione del processo

La tabella della sequenza temporale dell'esecuzione del processo non è modificabile e viene completata al momento della produzione.

percorso tabella: system.lakeflow.job_run_timeline

Query di esempio

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

Schema della tabella sequenza temporale esecuzione attività processo

La tabella della sequenza temporale dell'esecuzione dell'attività di processo non è modificabile e viene completata al momento della produzione.

percorso tabella: system.lakeflow.job_task_run_timeline

Modelli di join comuni

Nelle sezioni seguenti vengono presentate delle query di esempio che mostrano i modelli di join comunemente utilizzati per le tabelle di sistema dei job.

Unire le tabelle dei lavori e della sequenza temporale di esecuzione dei lavori

Arricchire l'esecuzione di un processo con un nome di processo

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)

Arricchire l'uso con un nome di lavoro

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
  usage.*,
  coalesce(usage_metadata.job_name, jobs.name) as job_name
FROM system.billing.usage
  LEFT JOIN jobs ON usage.workspace_id=jobs.workspace_id AND usage.usage_metadata.job_id=jobs.job_id
WHERE
  billing_origin_product="JOBS"

Aggiungere la sequenza temporale di esecuzione del processo e le tabelle di utilizzo

Arricchire ogni log di fatturazione con i metadati di esecuzione del processo

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"

Calcolare il costo per ogni esecuzione del processo

Questa query viene unita alla tabella di sistema billing.usage per calcolare un costo per ogni esecuzione del processo.

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

Aggiungere la sequenza temporale di esecuzione dell'attività di processo e le tabelle dei cluster

Arricchire le esecuzioni dei processi di lavoro con i metadati dei cluster

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
  exploded_task_runs.*,
  clusters.*
FROM exploded_task_runs t1
  LEFT JOIN clusters t2
    USING (workspace_id, cluster_id)

Trovare processi in esecuzione in un ambiente di calcolo all-purpose

Questa query viene unita alla compute.clusters tabella di sistema per restituire i processi recenti in esecuzione in un ambiente di calcolo all-purpose anziché nell'ambiente di calcolo dei processi.

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

Dashboard di monitoraggio dei lavori

Il seguente dashboard utilizza le tabelle di sistema per aiutarti a cominciare a monitorare i tuoi processi e la salute operativa. Include casi d'uso comuni, ad esempio il rilevamento delle prestazioni dei processi, il monitoraggio degli errori e l'utilizzo delle risorse.

Per informazioni sul download del dashboard, vedere Monitorare i costi dei processi & prestazioni con le tabelle di sistema

Risoluzione dei problemi

Il lavoro non è registrato nella tabella lakeflow.jobs

Se un lavoro non è visibile nelle tabelle di sistema:

• Il lavoro non è stato modificato nell'ultimo anno.
• Il lavoro è stato creato in una regione diversa
• Creazione recente di lavoro (ritardo nella tabella)

Impossibile trovare un lavoro nella tabella job_run_timeline

Non tutte le esecuzioni dell'attività sono visibili ovunque. Mentre le voci di JOB_RUN appaiono in tutte le tabelle correlate al processo, sia WORKFLOW_RUN (esecuzioni del flusso di lavoro del notebook) sia SUBMIT_RUN (esecuzioni una tantum) vengono registrate solo nella tabella job_run_timeline. Queste esecuzioni non vengono popolate in altre tabelle di sistema di lavoro, come jobs o job_tasks.

Consulta la tabella Tipi di esecuzione per una suddivisione dettagliata delle posizioni in cui ogni tipo di esecuzione è visibile e accessibile.

l'esecuzione del processo non è visibile nella tabella billing.usage

In system.billing.usage, il usage_metadata.job_id viene popolato solo per i processi eseguiti in job compute o nel calcolo serverless.

Inoltre, i processi WORKFLOW_RUN non hanno la propria attribuzione usage_metadata.job_id o usage_metadata.job_run_id in system.billing.usage. Invece, il loro utilizzo di calcolo viene attribuito al notebook padre che li ha avviati. Ciò significa che quando un notebook avvia un lancio del flusso di lavoro, tutti i costi di calcolo sono riportati sotto l'utilizzo del notebook padre, non come un processo del flusso di lavoro separato.

Per altre informazioni, vedere Analizzare i metadati di utilizzo.

Calcolare il costo di un task in esecuzione in un ambiente di calcolo multiuso

Il calcolo preciso dei costi per i processi in esecuzione nel calcolo per scopi non è possibile con 100% accuratezza. Quando un processo viene eseguito in un calcolo interattivo (tutto scopo), più carichi di lavoro come notebook, query SQL o altri processi spesso vengono eseguiti contemporaneamente sulla stessa risorsa di calcolo. Poiché le risorse del cluster sono condivise, non esiste un mapping diretto 1:1 tra i costi di calcolo e le esecuzioni di singoli processi.

Per tenere traccia dei costi dei processi accurati, Databricks consiglia l'esecuzione di processi in un ambiente di calcolo dedicato o serverless, in cui l'usage_metadata.job_id e usage_metadata.job_run_id consentono un'attribuzione precisa dei costi.

Se è necessario utilizzare il calcolo generico, è possibile:

• Monitorare l'utilizzo complessivo del cluster e i costi in system.billing.usage in base a usage_metadata.cluster_id.
• Tenere traccia delle metriche di esecuzione del lavoro separatamente.
• Si consideri che qualsiasi stima dei costi sarà approssimativa a causa delle risorse condivise.

Per altre informazioni sull'attribuzione dei costi, vedere Analizzare i metadati di utilizzo.

Valori di riferimento

La sezione seguente include riferimenti per le colonne selezionate nelle tabelle relative ai lavori.

Valori dei tipi di trigger

I valori possibili per la trigger_type colonna sono:

• CONTINUOUS
• CRON
• FILE_ARRIVAL
• ONETIME
• ONETIME_RETRY

Valori del tipo di esecuzione

I valori possibili per la run_type colonna sono:

Valori dello stato dei risultati

I valori possibili per la result_state colonna sono:

Valori del codice di terminazione

I valori possibili per la termination_code colonna sono: