How to Deploy Metric Views with DABsの翻訳です。
本書は著者が手動で翻訳したものであり内容の正確性を保証するものではありません。正確な内容に関しては原文を参照ください。
イントロダクション
Unity Catalogのメトリックビューは、YAMLとSQLを用いてDatabricksでセマンティックレイヤーを構築する能力を提供します。これによって、あなたのカタログへのセマンティックレイヤーはカタログ側にシフトされ、データにより近い位置に移動します。これによって、セマンティックレイヤーをBIツールの中にサイロ化することを避けることができ、開発や維持に独自の言語を使う必要性も回避することができます。
メトリックビューを作成したら、テストやプロダクションのようなより高位の環境にデプロイするための、シンプルかつ繰り返し可能な方法が必要となります。この記事では、Databricksアセットバンドル(DAB)を用いたディメンションモデル、UCメトリックビュー、AI/BIダッシュボードのデプロイメント方法を説明します。ここでは、DABによるメトリックビューのデプロイ方法だけではなく、エンドツーエンドの分析ソリューションでこれらを活用する方法を説明します。この例では、システムテーブルのデータを用いて、Databricks SQLの使用量とクエリー履歴に対するメトリックビューを作成します。Databricksの管理者は、自身のデータでDBSQLのトレンドを探索するためにこのパターンを活用することができます。
主要コンポーネント
このソリューションは、ディメンションモデル、セマンティックレイヤー、BIツールの典型的なパターンに従います。Databricksジョブがソリューション全体をオーケストレーションすることに加えて、キーとなるコンポーネントがどのようにフィットするのかをわかりやすく表示します。
- ファクトとディメンションテーブル: 大部分をDatabricksのシステムテーブルから導出したDBSQLの使用量とクエリー履歴ににフォーカスしたシンプルなディメンションモデル。
- UCメトリックビュー: メトリックとモデルのリレーションシップが定義されるセマンティックレイヤーとして機能。
- AI/BIダッシュボード: メトリクスの可視化と探索で使用。
1. ファクトとディメンションテーブル
ディメンションモデルは、我々の分析ソリューションの基盤となり明日。カレンダーディメンションによって、日、週、月などの時間期間ごとフィルタリング、集計が可能となります。コンピュートディメンションには、タイプ、サイズ、スケーリング設定などのウェアハウスの属性が含まれています。ワークスペースディメンションは、IDに限らず馴染みのあるワークスペース名を提供してくれます。
使用量と履歴のファクトテーブルには、対応するメトリクスが含まれます。メトリクスには、DBUでの使用量、クエリーに関する豊富なメトリクス(期間、ステータス、ソースなど)が含まれています。テーブルのリスト、それらのソース、それらの関係性を示す図は以下となり間sう。
- dim_calendar: Time at the Lakehouseのカレンダー/日付ディメンション。
- dim_compute: system.compute.warehousesのDBSQLウェアハウスデータ。シンプルにするためにSCD1で設定。他のコンピュートタイプに拡張可能。
- dim_workspace: system.access.workspaces_latestのDatabricksワークスペースデータ。
- fct_usage: system.billing.usageの課金使用量。
- fct_query_history: system.query.historyのクエリー履歴データ。
UCメトリックビューのためのディメンションモデル
DABによるテーブルのデプロイ
CREATE文を含むノートブックやSQLジョブタスクを用いたり、パラメーターマーカーでカタログやスキーマを設定することで異なる環境にテーブルをデプロイすることができます。USE文やパラメーターを用いてカタログやスキーマを設定することで、同一のDDL文を異なる環境で簡単に実行することができます。DABを用いることで、カタログやスキーマの値は、DABのターゲット定義で指定したり、デプロイメント時に上書きすることができます。
use catalog identifier(:catalog);
use schema identifier(:schema);
create or replace table dim_workspace (
workspace_key string comment 'The primary key (PK) of the table. This is the currently the same as the workspace_id, but enables using a surrogate key in the future without changing relationships.',
account_id string comment 'The ID of the parent account of this workspace.',
workspace_id string comment 'The ID of the workspace.',
workspace_name string comment 'The human-readable name of the workspace.',
workspace_url string comment 'URL of the databricks workspace.',
create_time timestamp comment 'Timestamp of when the workspace was created.',
status string comment 'Lifecycle status of the workspace: NOT_PROVISIONED | PROVISIONING | RUNNING | FAILED | BANNED',
primary key (workspace_key) rely
)
comment 'Workspace dimension sourced from system.access.workspaces_latest.'
cluster by (workspace_id);
主キー制約を用いたクエリーの最適化
ディメンションモデルは高速であることを目的としているので、主キー(PK)、外部キー(FK)リレーションシップを追加し、ディメンションモデルでRELYを使用しましょう。これによって、いくつかの共通的なクエリータイプを最適化し、リレーションシップを明文化するという重要なメリットをもたらすことになります。
RELYと主キー
primary key (workspace_key) rely
ファクトテーブルでのPK/FKリレーションシップの定義
constraint fk_fct_usage_dim_calendar foreign key (calendar_key) references dim_calendar(calendar_key),
constraint fk_fct_usage_dim_compute foreign key (compute_key) references dim_compute(compute_key),
constraint fk_fct_usage_dim_workspace foreign key (workspace_key) references dim_workspace(workspace_key)
テーブルのリレーションシップを定義すると、リレーションシップのFK側で「関係を参照」をクリックしてUnity Catalogで参照が可能です。
Unity Catalogでのテーブルリレーションシップの参照
Unity Catalogにおけるテーブルリレーションシップ
2. UCメトリックビュー
メトリックビューによって、Unity Catalogにおいて集中管理されたセマンティックレイヤーを構築することができます。ここでは、BIやAIツールで利用するためのディメンション、メジャー、テーブルリレーションシップを定義します。メトリクスはディメンションとは独立に定義できるので、ユーザーは実行時にこれらを集計することができます。
Unity Catalogにおけるメトリックビュー
Unity Catalogにおけるメトリックビュー
DABによるメトリックビューのデプロイ
メトリックビューはDABでサポートされているリソースではないので、SQL文を用いてデプロイする必要があります。ここではテーブルと同様に、カタログとスキーマに対するパラメーターマーカーを使用します。しかしこれは、メトリックビューのロケーションを設定するだけです。YAML定義ではソースおよび結合されるテーブルに完全修飾名が必要となります。これは、SQL文を動的に作成してEXECUTE IMMEDIATEを実行する必要があることを意味します。
-- In the YAML definition, fully qualified names are required for the source and joined tables
use catalog identifier(:catalog);
use schema identifier(:schema);
declare or replace qry_str string;
set var qry_str =
"create or replace view metv_usage
(
Date comment 'Date of the usage record, this field can be used for faster aggregation by date.',
`Account ID` comment 'The ID of the Databricks account.',
`Workspace Name` comment 'The name of the workspace.',
`Warehouse Name` comment 'The name of the SQL warehouse.',
`Usage Unit` comment 'Unit this usage is measured in. Possible values include DBUs.',
`Usage Type` comment 'The type of usage attributed to the product or workload for billing purposes. Possible values are COMPUTE_TIME, STORAGE_SPACE, NETWORK_BYTES, API_CALLS, TOKEN, or GPU_TIME.',
`Billing Origin Product` comment 'The product that originated the usage. Some products can be billed as different SKUs. For possible values, see [View information about the product associated with the usage](https://docs.databricks.com/en/admin/system-tables/billing.html#features).',
`SKU Name` comment 'Name of the SKU',
`Sum of Usage` comment 'Number of units consumed for this record.'
)
with metrics
language yaml
as $$
version: 0.1
source: " || :catalog || '.' || :schema || ".vw_fct_usage
joins:
- name: calendar
source: " || :catalog || '.' || :schema || ".vw_dim_calendar
on: calendar.calendar_key = source.calendar_key
- name: compute
source: " || :catalog || '.' || :schema || ".vw_dim_compute
on: compute.compute_key = source.compute_key
- name: workspace
source: " || :catalog || '.' || :schema || ".vw_dim_workspace
on: workspace.workspace_key = source.workspace_key
dimensions:
- name: Date
expr: calendar.calendar_date
- name: Account ID
expr: workspace.account_id
- name: Workspace Name
expr: workspace.workspace_name
- name: Warehouse Name
expr: compute.warehouse_name
- name: Usage Unit
expr: usage_unit
- name: Usage Type
expr: usage_type
- name: Billing Origin Product
expr: billing_origin_product
- name: SKU Name
expr: sku_name
measures:
- name: Sum of Usage
expr: SUM(usage_quantity)
$$";
execute immediate qry_str;
3. AI/BIダッシュボード
メトリックビューを作成すると、AI/BIダッシュボードをデプロイすることができます。また、メトリックビューは、Genieスペースやアラートなどの他のツールからクエリーすることもできます。
DABによるAI/BIダッシュボードのデプロイ
ダッシュボードはlvdash.jsonファイルからデプロイされます。下書きモードでダッシュボードを参照する際、ファイルアクション -> エクスポートをクリックすることでjsonファイルをエクスポートすることができます。
AI/BIダッシュボードのエクスポート
このファイルはバンドルのダッシュボードとして参照されることになります。
resources:
dashboards:
dbsql_metrics_dashboard:
display_name: 'DBSQL Metrics'
file_path: ../src/dbsql_metrics.lvdash.json
warehouse_id: ${var.warehouse_id}
ダッシュボードやその他のリソースが準備できたら、DABをデプロイすることができます。
$ databricks bundle deploy --target dev --profile DEFAULT
# OR for PROD
$ databricks bundle deploy --target prod --profile PROD
以下は、過去60日におけるウェアハウスごとのDBSQLの使用量を表示する(ウェアハウス名が除外された)サンプルダッシュボードです。日付範囲フィルターを用いることで、過去N日間を自動的にデフォルトにすることができます。
AI/BIにおけるDatabricks SQLの使用量の可視化
クエリー履歴のメトリックビューを用いることで、クエリー期間のパーセンタイルのようなメトリクスを探索することができます。
AI/BIにおけるDatabricksクエリー期間のパーセンタイルの可視化
まとめ
この記事では、DABによるUCメトリックビューおよび関連リソースのデプロイ方法をデモンストレーションしました。このパターンによって、Databricksにエンドツーエンドの分析ソリューションを簡単かつ一貫性を持ってデプロイすることができ、本番運用への道を加速します。
この記事で説明されているソリューションは、https://github.com/databricks-solutions/databricks-dab-examples/tree/main/knowledge-base/metric-views リポジトリでアクセスできます。