クエリ履歴システム テーブル リファレンス

この記事には、テーブルのスキーマの概要など、クエリ履歴システム テーブルに関する情報が含まれています。

テーブル パス: このシステム テーブルは、 system.query.historyにあります。

クエリ履歴テーブルの使用

クエリ履歴テーブルには、ノートブックやジョブ用の SQL ウェアハウスまたはサーバーレス コンピューティングを使用して実行されるクエリのレコードが含まれています。 テーブルには、テーブルへのアクセス元である同じリージョン内のすべてのワークスペースのアカウント全体のレコードが含まれています。

既定では、管理者のみがシステム テーブルにアクセスできます。 テーブルのデータをユーザーまたはグループと共有する場合、Databricks では、ユーザーまたはグループごとに動的ビューを作成することをお勧めします。 「動的ビューを作成する」を参照してください。

クエリ履歴システム テーブル スキーマ

クエリ履歴テーブルでは、次のスキーマを使用します。

レコードのクエリ プロファイルを表示する

クエリ履歴テーブルのレコードに基づいてクエリのクエリ プロファイルに移動するには、次の操作を行います。

1. 目的のレコードを特定し、レコードの statement_idをコピーします。
2. レコードの workspace_id を参照して、レコードと同じワークスペースにログインしていることを確認します。
3. [ワークスペースサイドバーのクエリ履歴。
4. [ステートメント ID] フィールドに、レコードの statement_id を貼り付けます。
5. クエリの名前をクリックします。 クエリ メトリックの概要が表示されます。
6. [See query profile] (クエリ プロファイルの表示) をクリックします。

query_source列の理解

query_source列には、ステートメントの実行に関与する Azure Databricks エンティティの一意の識別子を含むセットが含まれています。

query_source列に複数の ID が含まれている場合は、ステートメントの実行が複数のエンティティによってトリガーされたことを意味します。 たとえば、ジョブの結果によって、SQL クエリを呼び出すアラートがトリガーされる場合があります。 この例では、3 つの ID はすべて query_source内に設定されます。 この列の値は、実行順序で並べ替えされません。

可能なクエリ ソースは次のとおりです。

• alert_id: アラートからトリガーされるステートメント
• sql_query_id: この SQL エディター セッション内から実行されるステートメント
• dashboard_id: ダッシュボードから実行されたステートメント
• legacy_dashboard_id: レガシ ダッシュボードから実行されるステートメント
• genie_space_id: Genie 空間から実行されるステートメント
• notebook_id: ノートブックから実行されるステートメント
• job_info.job_id: ジョブ内で実行されるステートメント
• job_info.job_run_id: ジョブ実行から実行されたステートメント
• job_info.job_task_run_id: ジョブ タスク実行内で実行されるステートメント

query_sourceの有効な組み合わせ

次の例は、クエリの実行方法に応じて query_source 列がどのように設定されるかを示しています。

• ジョブの実行中に実行されるクエリには、入力された job_info 構造体が含まれます。

  {
alert_id: null,
sql_query_id: null,
dashboard_id: null,
notebook_id: null,
job_info: {
job_id: 64361233243479,
job_run_id: null,
job_task_run_id: 110378410199121
},
legacy_dashboard_id: null,
genie_space_id: null
}

• 従来のダッシュボードからのクエリには、 sql_query_id と legacy_dashboard_idが含まれます。

  {
alert_id: null,
sql_query_id: 7336ab80-1a3d-46d4-9c79-e27c45ce9a15,
dashboard_id: null,
notebook_id: null,
job_info: null,
legacy_dashboard_id: 1a735c96-4e9c-4370-8cd7-5814295d534c,
genie_space_id: null
}

• アラートからのクエリには、 sql_query_id と alert_idが含まれます。

  {
alert_id: e906c0c6-2bcc-473a-a5d7-f18b2aee6e34,
sql_query_id: 7336ab80-1a3d-46d4-9c79-e27c45ce9a15,
dashboard_id: null,
notebook_id: null,
job_info: null,
legacy_dashboard_id: null,
genie_space_id: null
}

• ダッシュボードからのクエリには dashboard_idが含まれますが、 job_infoはありません。

  {
alert_id: null,
sql_query_id: null,
dashboard_id: 887406461287882,
notebook_id: null,
job_info: null,
legacy_dashboard_id: null,
genie_space_id: null
}

メタストアからクエリ履歴を具体化する

次のコードを使用すると、時間単位、日単位、週単位で実行されるジョブを作成して、メタストアからクエリ履歴を具体化できます。 HISTORY_TABLE_PATH 変数と LOOKUP_PERIOD_DAYS 変数は、適宜調整します。

from delta.tables import *
from pyspark.sql.functions import *
from pyspark.sql.types import *

HISTORY_TABLE_PATH = "jacek.default.history"
# Adjust the lookup period according to your job schedule
LOOKUP_PERIOD_DAYS = 1

def table_exists(table_name):
    try:
        spark.sql(f"describe table {table_name}")
        return True
    except Exception:
        return False

def save_as_table(table_path, df, schema, pk_columns):
    deltaTable = (
        DeltaTable.createIfNotExists(spark)
        .tableName(table_path)
        .addColumns(schema)
        .execute()
    )

    merge_statement = " AND ".join([f"logs.{col}=newLogs.{col}" for col in pk_columns])

    result = (
        deltaTable.alias("logs")
        .merge(
            df.alias("newLogs"),
            f"{merge_statement}",
        )
        .whenNotMatchedInsertAll()
        .whenMatchedUpdateAll()
        .execute()
    )
    result.show()

def main():
    df = spark.read.table("system.query.history")
    if table_exists(HISTORY_TABLE_PATH):
        df = df.filter(f"update_time >= CURRENT_DATE() - INTERVAL {LOOKUP_PERIOD_DAYS} days")
    else:
        print(f"Table {HISTORY_TABLE_PATH} does not exist. Proceeding to copy the whole source table.")

    save_as_table(
        HISTORY_TABLE_PATH,
        df,
        df.schema,
        ["workspace_id", "statement_id"]
    )

main()