メインコンテンツまでスキップ

スタンドアロンマテリアライズドビューの監視

カタログエクスプローラ、 DESCRIBE EXTENDED、またはパイプライン イベント ログを使用して、スタンドアロン マテリアライズドビューに関する更新データを監視およびクエリーします。

単一のマテリアライズドビューの詳細を表示​

カタログエクスプローラ を使用するか、プログラム的に DESCRIBE EXTENDED 操作を実行して、単一のマテリアライズドビューの詳細を表示できます。また、イベント ログにクエリーを実行して、マテリアライズドビューの更新履歴の詳細を表示することもできます。

カタログエクスプローラで詳細を表示​

カタログエクスプローラで表示することで、マテリアライズドビューに関する情報にアクセスできます。カタログエクスプローラ では、最後の更新ステータスと SQL で作成された更新スケジュールを表示できます。SQL で作成されたスケジュールの詳細については、 CREATE MATERIALIZED VIEWを参照してください。

カタログエクスプローラには、右側のペインに各マテリアライズドビューの詳細が表示されます。その内容は次のとおりです。

  1. 現在の更新ステータス と最後のラン時間。実行時間、詳細なエラー、および更新タイプ(マテリアライズドビューが完全更新されたか増分更新されたか、その理由など)を含む更新の詳細については、「 更新の詳細を表示 」をクリックします。
  2. 更新スケジュール 。マテリアライズドビューにSQLを使用してスケジュールが設定されている場合、そのスケジュールが表示されます。スケジュールを更新するには、 ALTER マテリアライズドビューを使用します。
  3. タグ .カスタムタグを追加するには、 タグを追加 をクリックします。タグは自動的にコスト配分に使用されるわけではありませんが、カスタムタグとコストを関連付けるクエリーを手動で作成することができます。詳細については、「 カスタムタグを使ってSQLウェアハウスにコストを割り当てる」を参照してください。

マテリアライズドビューのプロパティの一部は、カタログエクスプローラでは利用できません。これらのプロパティについて、またはプログラムで情報を取得するには、 DESCRIBE EXTENDED コマンドを使用できます。

詳細を表示(使用: DESCRIBE EXTENDED​

注記

DESCRIBE EXTENDED コマンドは、専用コンピュートではサポートされていません。マテリアライズドビューで DESCRIBE EXTENDED を実行するには、標準コンピュートを使用する必要があります。

DESCRIBE EXTENDED コマンドを使用して、マテリアライズドビューに関する詳細をプログラムで表示できます。これには、カタログエクスプローラーから取得できる詳細以外も含まれます。それらには、次のものが含まれます。

  • 最後に完了した更新のステータスです。
  • 更新スケジュール。
  • マテリアライズドビューの列。
  • マテリアライズドビューの更新タイプ(カタログエクスプローラでは利用できません)。
  • マテリアライズドビューのデータサイズ(バイト単位)(カタログエクスプローラでは使用できません)。
  • マテリアライズドビューのストレージ場所(カタログエクスプローラでは使用できません)。
  • 有効にした場合、一部の情報は結果にのみ含まれます。
    • クラスタリング列(有効な場合)。
    • 削除ベクトルが有効かどうか(trueの場合のみ表示)。
    • 行トラッキングが有効かどうか(trueのときのみ表示)。
SQL
-- As table:
DESCRIBE TABLE EXTENDED sales;

-- As a single JSON object:
DESCRIBE TABLE EXTENDED sales AS JSON;

プログラムからのイベントログのクエリー​

マテリアライズドビューの更新履歴の詳細を取得したり、更新が発生したときの詳細を取得したりするには、イベント ログに対してプログラムでクエリーを実行します。

パイプラインの所有者は、 ビュー を作成して、他のユーザーがパイプラインのイベント ログをクエリーできるようにします。次のクエリーは、他のユーザーがイベント ログをクエリーするために使用できるビューを作成します。このクエリーは、TABLE値関数を使用して正しいイベント ログ テーブルをクエリーします。

SQL
CREATE VIEW my_event_log_view AS
SELECT *
FROM event_log(TABLE(<catalog_name>.<schema_name>.<mv_name>));

イベント ログ ビューをクエリーするには、以下のようなクエリーを使用します。

SQL
SELECT *
FROM my_event_log_view
WHERE event_type = "update_progress"
ORDER BY timestamp desc;

パイプライン所有者としてイベントログを直接クエリーする場合は、ビューを作成する必要はありません。TABLE 値関数を使用して、次のサンプルクエリーのようにデータを直接クエリーできます。

SQL
SELECT *
FROM event_log(TABLE(<catalog_name>.<schema_name>.<mv_name>))
WHERE event_type = "update_progress"
ORDER BY timestamp desc;

イベント Logsを使用したサンプル クエリーの全リストについては、「基本的なクエリーの例」を参照してください。

マテリアライズドビューのランの監視​

ジョブとパイプライン ページ、 クエリー履歴 ページを使用するか、イベント ログをクエリすることで、ワークスペース全体でパイプラインの実行を監視できます。スケジュールされたパイプラインの通知を設定することもできます。

UIですべてのマテリアライズドビューのランを表示​

[ジョブとパイプライン] ページを使用してワークスペース全体のさまざまなオーケストレーション ジョブのステータスを監視する場合、そこで作成されたすべてのマテリアライズドビューとストリーミングテーブルを追跡することもできます。各スタンドアロン マテリアライズドビューには、それをサポートするパイプラインがあります。アクセスできるすべてのマテリアライズドビューとストリーミングテーブルを表示するには:

  1. ワークスペースの左側にある ワークフローアイコン。 ジョブ & パイプライン ボタンをクリックします。
  2. パイプライン トグル ボタンをクリックして、表示をパイプラインのみにフィルタリングします。
  3. パイプラインタイプ ボタンをクリックし、 MV/ST を選択してスタンドアロンパイプラインのみにフィルター処理します。
  4. 自分がアクセス可能 フィルタをクリックして、アクセス権のあるすべてのパイプラインを表示します。

組織全体で作成されたすべてのマテリアライズドビューとストリーミングテーブルを、最近のランステータスの概要ビューを含めて確認できます。パイプラインの名前をクリックすると、パイプラインモニタリングの詳細ページが開き、詳細情報を取得できます。パイプラインモニタリングの詳細ページの詳細については、 「失敗した更新のトラブルシューティング」を参照してください。

クエリー履歴を使用してランを表示する​

[クエリー履歴] tabに慣れている場合は、これを使用して、実行中のSQL Warehouseへの CAN VIEW アクセス権があるすべてのクエリーの過去のすべてのランを表示することもできます。クエリー履歴ページを使用して、クエリーの詳細とクエリー プロファイルにアクセスできるため、ストリーミングテーブルの更新をランするために使用されるパイプラインでパフォーマンスの低いクエリーやボトルネックを特定するのに役立ちます。クエリー履歴とクエリー プロファイルで使用できる情報の種類の概要については、クエリー履歴および クエリー プロファイルを参照してください。

備考

プレビュー

この機能は パブリック プレビュー段階です。ワークスペース管理者は、 プレビュー ページからこの機能へのアクセスを制御できます。Databricksのプレビューを管理するを参照してください。

マテリアライズドビューに関連するすべてのステートメントはクエリー履歴に表示されます。 ステートメント ドロップダウン・フィルターを使用してコマンドを選択し、関連するクエリーを検査できます。すべて CREATE ステートメントの後には、パイプライン上で非同期に実行される REFRESH ステートメントが続きます。REFRESH ステートメントには通常、パフォーマンスの最適化に関する知見を提供する詳細なクエリープランが含まれています。

クエリー履歴 UI で REFRESH ステートメントにアクセスするには、次のステップを使用します。

  1. 左サイドバーの 履歴アイコン。 クエリー履歴 をクリックします。
  2. ステートメント ドロップダウン・フィルターから REFRESH チェック・ボックスを選択します。
  3. クエリーステートメントの名前をクリックすると、クエリーの処理時間や集計メトリクスなどの概要の詳細を表示できます。
  4. [ クエリー プロファイルの表示 ] をクリックして、クエリー プロファイルを開きます。クエリー プロファイルのナビゲーションの詳細については、 クエリー プロファイルを参照してください。
  5. オプションで、 クエリーソース セクションのLinkを使用して、関連するクエリーまたはパイプラインを開くことができます。

CREATE MATERIALIZED VIEWを参照してください。

スケジュールされた更新の通知を受け取る​

備考

ベータ版

DDLスケジュール更新機能の通知はベータ版です。ワークスペース管理者は、 マテリアライズドビューおよびストリーミングテーブルのシステム管理ジョブ のプレビューにオプトインすることで、 プレビュー ページからこの機能へのアクセスを制御できます。 Databricksのプレビューを管理するを参照してください。

マテリアライズドビューのスケジュールを作成するときに、それを編集して通知を受け取ることができます。マテリアライズドビューをスケジュールする方法は複数あり、通知を受け取ることができるかどうかは、これらのどの方法を選択するかによって異なります。

  • ジョブでスケジュール済み :Lakeflow JobsのSQLタスクから通知を受け取るには、タスクを編集して通知を追加してください。ジョブのSQLタスクを参照してください。

    受信する通知のオプションと受信方法を幅広く選択できます。ジョブに通知を追加するを参照してください

  • SCHEDULE句でスケジュールされています :SQL定義のSCHEDULE句によってスケジュールされたマテリアライズドビューから通知を受け取るには、カタログエクスプローラで編集します。

    1. カタログエクスプローラでマテリアライズドビューを開きます。

    2. 概要 tabの 更新スケジュール の下にある鉛筆アイコン。をクリックして、通知を受け取るスケジュールを編集します。

    3. その他のオプション で、通知を追加または変更します。

      スケジュールされた更新の起動、成功、または失敗について、Eメールで通知を受け取ることができます。defaultでは、失敗時にのみオーナーに通知されます。

更新失敗のトラブルシューティング​

マテリアライズドビュー (またはストリーミングテーブル) の失敗した更新は、 ジョブとパイプライン リストを確認することで確認できます。失敗した更新のトラブルシューティングを行うには、パイプラインのモニタリング詳細ページまたはイベントログを使用します。

増分である必要があると思われる更新がいっぱいになった場合のトラブルシューティングを行うには、まず、ソース Delta テーブルで 行追跡が有効になっている ことを確認します。増分更新の詳細については、「 マテリアライズドビュー のインクリメンタル 更新のサポート」を参照してください。

詳細については、パイプラインのモニタリングページから、またはプログラムによってイベント ログをクエリして取得できます。

パイプラインモニタリングページの使用​

失敗したマテリアライズドビュー(またはストリーミングテーブル)に関する詳細を取得するには、パイプラインモニタリングページを使用して問題をデバッグできます。各マテリアライズドビューには、それをサポートするパイプラインがあります。パイプラインモニタリングページには、次のような情報が含まれています。

  • 最後のランのステータスとラン履歴。
  • 前回のラン期間。
  • マテリアライズドビューが完全に更新されたか、増分的に更新されたか。マテリアライズドビューの増分更新を取得する詳細については、「 マテリアライズドビュー のインクリメンタル 更新のサポート」を参照してください。
  • より詳細なデバッグのためのイベントログ。マテリアライズドビューの更新に失敗した、またはその他の問題が発生した場合は、問題ペインをクリックしてログの詳細を表示します。

マテリアライズドビューのトラブルシューティング:

  1. ワークスペースの左側のナビゲーションバーにある ワークフローアイコン。 ジョブ & パイプライン ボタンをクリックします。
  2. リストでパイプラインの名前をクリックします。
  3. 更新のランに失敗した場合、UI の下部ペインにエラー(またはエラーリスト)が表示されます。
  4. ボタンをクリックして Logsを表示 するか、問題ペインをクリックして、エラーの詳細を確認してください。
  5. これにより、イベントログUIが開きます。各エラーには高レベルのメッセージとサマリーがあり、JSON tabに詳細が表示されます。Genie Codeに関する問題を修正するには、[ エラーの診断 ]をクリックします。

パイプラインモニタリングページの詳細については、 こちらを参照してください。

マテリアライズドビューの更新履歴に対してクエリーを実行する​

イベントログは、ワークスペース全体での更新ステータスや期間をモニタリングするダッシュボードを設定する場合、またはUIを使用するよりもプログラムによるモニタリングを希望する場合に役立ちます。スタンドアロンマテリアライズドビューは、イベントログをメタストアに保存することをサポートしていないため、マテリアライズドビューの所有者のみがイベントログを直接クエリーできます。

現在および過去の更新を含む、マテリアライズドビューに対する REFRESH 操作の状態を表示するには、パイプライン イベント ログをクエリーします。

SQL
SELECT *
FROM event_log(TABLE(<fully-qualified-table-name>))
WHERE event_type = "update_progress"
ORDER BY timestamp desc;

<fully-qualified-table-name> を、カタログやスキーマなど、マテリアライズドビューの完全修飾名に置き換えます。パイプラインの所有者でない場合は、まずイベント ログをクエリーするためのビューを作成する必要があるかもしれません。プログラムでイベント ログをクエリーするを参照してください。

マテリアライズドビューに対して発生した更新タイプをクエリーする​

一部のクエリーは増分的にリフレッシュできます。増分更新を実行できない場合は、代わりに完全更新が実行されます。

マテリアライズドビューの更新タイプを表示するには、イベントログに対してクエリーを実行します。

SQL
SELECT timestamp, message
FROM event_log(TABLE(my_catalog.my_schema.sales))
WHERE event_type = 'planning_information'
ORDER BY timestamp desc;

このコマンドの出力例:

    • timestamp
    • message
    • 2025-03-21T22:23:16.497+00:00
    • Flow 'sales' has been planned to be executed as ROW_BASED.

カスタムタグを使用してSQLウェアハウスにコストを割り当てる​

マテリアライズドビューまたはストリーミングテーブルの請求レコードにタグが関連付けられるには 2 つの方法があり、それぞれ異なる目的があります。

  • ウェアハウス タグ は SQL ウェアハウスから自動的に継承され、 system.billing.usage の custom_tags 列に伝播します。これらを使用して、マテリアライズドビュー/ストリーミングテーブルの更新コストをソース SQL Warehouse に属性付けします。これには手動結合は必要ありません。
  • カタログエクスプローラでマテリアライズドビューまたはストリーミングテーブルに追加された オブジェクトレベルのタグ は、コストを個々のテーブルに帰属させるため、チーム、プロジェクト、コストセンターなど、オブジェクト自体に定義するディメンションで支出をグループ化できます。これらのタグは、請求レコードに 自動的 に追加されることはありません。それらをコスト配分に使用するには、「オブジェクトレベルのタグを手動で結合する」の説明に従って、table_tagsシステムテーブルから手動で結合します。

自動warehouse タグのプロパゲーション​

Databricks SQLのマテリアライズドビューまたはストリーミングテーブルは、舞台裏のServerlessパイプラインで実行されます。そのパイプラインは、ステートメントを実行する囲み込みwarehouseからカスタムタグを自動的に取得するため、更新は他のSQLステートメントと同じ方法で属性が割り当てられ、コストをwarehouseにトレースするために追加の結合は必要ありません。これらのタグは、system.billing.usageのcustom_tags列に直接表示されます。

注記

warehouseのタグ伝播は、SQL Warehouseからステートメントがランされるマテリアライズドビューとストリーミングテーブルにのみ適用されます。Python で作成および更新されるスタンドアロンのマテリアライズドビューとストリーミングテーブルは、SQLウェアハウスではなくサーバレス汎用コンピュート上で実行されるため、タグを継承する対象のwarehouseが存在しません。スタンドアロンパイプラインでの Python の使用を参照してください。

どのwarehouseのタグが適用されるかは、更新がどのようにトリガーされるかによって異なります:

  • DDL 更新 は、DDL ステートメントを実行したwarehouseのタグを継承します(マテリアライズドビュー/ストリーミングテーブルを定義する CREATE または CREATE OR REPLACE)。
  • アドホック更新とLakeflow JobsのSQLタスクによってトリガーされる更新 は、その更新を実行するwarehouseのタグを継承します。

Serverless 予算ポリシーとwarehouse タグが同じタグ キーを定義している場合、使用ポリシー タグが優先されます。これは、Serverless ジョブの競合解決動作と一致します。

既存のマテリアライズドビューまたはストリーミングテーブルのタグを付け直すには、使用するタグを持つwarehouseから CREATE OR REPLACE (または CREATE OR REFRESH )をランします。スケジュールされた更新は、そのタグを取得します。

Databricks SQL で作成されたマテリアライズドビューとストリーミングテーブルは、billing_origin_product が SQL に設定され、 usage_metadata.dlt_pipeline_id が入力されて課金に表示されます。次のクエリーは、過去 30 日間のこれらのレコードについて、継承されたwarehouse タグと DBU 使用量を取得します。

SQL
SELECT
usage_metadata.dlt_pipeline_id,
custom_tags,
SUM(usage_quantity) AS dbus
FROM system.billing.usage
WHERE billing_origin_product = 'SQL'
AND usage_metadata.dlt_pipeline_id IS NOT NULL
AND usage_date >= DATEADD(day, -30, current_date)
GROUP BY ALL
ORDER BY dbus DESC;

オブジェクト レベルのタグを構成する​

カタログエクスプローラーでマテリアライズドビュー(またはストリーミングテーブル)に追加されたタグは、請求記録に自動的に追加されません。ただし、クエリーで請求情報に手動で結合することができます。

カタログエクスプローラで各マテリアライズドビュー(またはストリーミングテーブル)にタグを追加したら、 table_tags および billing システムテーブルを結合してマテリアライズドビューのコストを監視できます。これは、Databricks SQLで作成されたすべてのマテリアライズドビューとストリーミングテーブルの課金レコードを取得し、テーブルレベルのタグを追加するサンプルクエリーです。

SQL
SELECT
u.*,
tag_info.tags
FROM
system.billing.usage u
LEFT JOIN (
SELECT
t.catalog_name,
t.schema_name,
t.table_name,
collect_list(named_struct('tag_name', t.tag_name, 'tag_value', t.tag_value)) AS tags
FROM
main.information_schema.table_tags t
GROUP BY
t.catalog_name,
t.schema_name,
t.table_name
) tag_info
ON tag_info.catalog_name = u.usage_metadata.uc_table_catalog
AND tag_info.schema_name = u.usage_metadata.uc_table_schema
AND tag_info.table_name = u.usage_metadata.uc_table_name
WHERE usage_metadata.uc_table_name is not null;

この同じアイデアを使用して、 column_tags テーブルから列タグを結合することもできます。