プラットフォームエンジニア ワークショップ/ platform-workshop

本ワークショップでは、Databricks におけるアカウント、ワークスペース、メタストア、カタログなどの主要な管理対象を中心に、プラットフォーム運用に必要な基礎知識を学びます。Databricks 管理者が主に担当する 7 つの管理トピックを扱い、全体像を整理しながら理解を深めます。

内容は座学中心に、簡単なアクティビティを交えた構成です。アカウント管理、アイデンティティ管理、カタログ管理、権限管理、計算資源管理、予実管理、監査・モニタリングまでを幅広くカバーし、今後の実務で必要な情報にアクセスするための出発点を提供します。

Transcript

1. Databricks プラットフォームエンジニア ワークショップ Databricks Japan 1
2. プラットフォームエンジニア ワークショップ Databricks、Unity CatalogはあらゆるデータAI資産を一元管理するための諸機能を有しています。 2時間のワー クショップを通じて、 Databricksプラットフォームの管理者 の皆様に、Databricksの管理機能の概要 を座学・ハ ン ズオン形式で理解いただきます。 主な対象者 • Databricksの管理者（IT管理者、ガバナンス担当、事業部 付きのガバナンス担当者など） • Databricksの概要についての事前知識がある ゴール 事前準備 アジェンダ 1. Databricks管理の7つのトピック（ 2h） ワークスペース管理、アイデンティティ管理、カタログ管理、 権限管理、計算資源管理、予実管理、その他 • Databricks上の主要な管理概念の全体像と基礎を把握し、 今後の実務において必要な情報へ円滑にアクセスするた めの出発点 を得る • 環境：お客様のDatabricks環境を利用
3. 始める前に • 本ワークショップでは、Databricksにおけるアカウント、ワークスペース、カタ ログなどの各種管理対象について、運用・統制を担うご担当者様 を主な対象 として、関連する基礎トピックを取り上げます。 • 本ワークショップの目的は、Databricks上の主要な管理概念の全体像と基礎 を把握し、今後の実務において必要な情報へ円滑にアクセスするための出 発点を得て いただくことです。 • 内容は座学中心+簡単なアクティビティとなります。理解の定着に向けて、特 に関心の高いテーマについては、後日あらためて資料を見返していただく こ とをお勧めします。 • より深い理解や体系的な知識の習得にあたっては、公式ドキュメントおよびト レーニングの活用 をご検討ください。
4. 4 質問 ★ Databricksを本番運用開始するまでに必要な 内容は何ですか？
5. 本ワークショップが扱う範囲 Databricksの管理者が主に担当する、7つのトピックを扱います。 カタログ管理 権限管理 その他 監査・モニタリング 計算資源管理 アカウント管理 アイデンティティ管理 予実管理 ◎ ◎ ◎ ◎ トピック アカウント管理者 Databricks全体の資産管理 基盤管理/中央Govチーム ◯ ワークスペース内アクションの監査 ◎ ◯ 作業環境への登録 ◯ 作業環境内の予実集計 ワークスペース管理者 特定の作業環境の管理 基盤管理/中央Govチーム /DevOpsチーム ◎ ◯ データセット全体の利用状況監視 メタストア管理者 データAI資産全体の管理 中央IT Gov/基盤管理チーム ◎ ◯ 特定データセットの品質監視 カタログ所有者 特定のデータ AI資産の管理 中央Govチーム/ 事業部Govチーム 責務 (黒: Databricks上の名称、緑: 想定される社内の職掌) 3 4 7 5 1 2 6
6. 本日扱わないトピック 高度なネットワーク設定、CI/CD、データ / LLM固有のモニタリングに関する設定は 本ワークショップの対象外とする。以下のドキュメントを参照。 1. 高度なネットワーク設定 ：コントロールプレーン / コンピュートプレーン / 社内リ ソース間の接続、およびプライベートリンク接続の方法 AWS / Azure / Google Cloud 2. CI/CD：Declarative Automation BundlesやTerraformを使用したDatabricksリ ソースのYAML定義と自動デプロイ AWS / Azure / Google Cloud 3. データ自体のモニタリング ：データ品質モニタリング機能による品質監視 AWS / Azure / Google Cloud 4. LLM / Agentのモニタリング ：Unity AI Gatewayによるトラフィック監視 / ガード レールなど AWS / Azure / Google Cloud
7. アカウント・ ワークスペース管理 プラットフォームエンジニア　ワークショップ
8. 8 質問 ★ Databricks アカウントとワークスペースの違い は何でしょうか？ ★ メタストアとは何でしょうか？また、何を確認で きますか？
9. アカウント、ワークスペース、メタストア 9 アカウントはDatabricks全体の管理単位であり、アカウント管理者がアカウントコン ソールから管理作業を行う アカウント ワークスペース #1 ワークスペース #2 メタストア #1 カタログ #1 カタログ #2 … … Databricks オブジェクト関係図 Databricks全体の管理単位 管理者：アカウント管理者 管理方法：アカウントコンソール 管理対象： • ワークスペース • メタストア • アイデンティティ • ネットワーク • 予算等 ユーザー アカウント …
10. アカウントコンソール画面 10 アカウントコンソール画面の例 AWS/Google Cloud: https://accounts.cloud.databricks.com/ Azure: https://accounts.azuredatabricks.net/ アカウント管理者 のみアクセス可
11. アカウント、ワークスペース、メタストア 11 ワークスペースはユーザーの作業場所であり、ユーザーが実務を行う他、ワークス ペース管理者が管理業務を行う アカウント ワークスペース #1 ワークスペース #2 メタストア #1 カタログ #1 カタログ #2 … … Databricks オブジェクト関係図 ユーザーが作業をする 実行環境 管理者：ワークスペース管理者 管理方法：ワークスペース設定 管理対象：計算資源やデータ /モデルを 操作・参照するオブジェクト その他：作成時にリージョンを選択 ユーザー ワークスペース … ◦ コンピュート ◦ ノートブック ◦ ジョブ ◦ ダッシュボード ◦ パイプライン ◦ アプリ ◦ 他
12. ワークスペース画面 12 ワークスペース画面の例（ skato-workspace ワークスペース） AWS/Google Cloud: https://<workspace-prefix>.cloud.databricks.com/ Azure: https://adb-<workspace-id>.<random-number>.azuredatabricks.net/
13. アカウント、ワークスペース、メタストア 13 メタストアはデータ、AI資産を管理する最上位のコンテナであり、メタストア管理者が 作業をする アカウント ワークスペース #1 ワークスペース #2 メタストア #1 カタログ #1 カタログ #2 … … Databricks オブジェクト関係図 Unity Catalogでデータ資産 を管理する最上位コンテナ 管理者：メタストア管理者 管理方法：アカウント / ワークスペース 管理対象：データ、メタデータ、アクセス 権限 その他：作成時にリージョンを選択 ユーザー メタストア … ◦ スキーマ ◦ テーブル ◦ ビュー ◦ モデル ◦ 関数 ◦ …
14. メタストア管理画面 14 メタストア管理画面の例 アカウント コンソール ※アカウント管理者のみ ワークスペース ※メタストア管理者のみ
15. アカウント、ワークスペース、メタストアの関係性 15 アカウント、メタストア配下のオブジェクト、ワークスペース配下のオブジェクトとその 関係性を理解する Account (Account console) Workspace Metastore Catalog Schema 1 0..n 1 0..n Table 0..n 1 0..n 1 Storage Credential, External Location, Share, Recipient, Provider, Connection, Clean Room View, Model, Function, Volume 1 0..n 0..n 0..n 0..1 n 1 m Compute, Job, Pipeline, Notebook, Dashboard, … 1 0..n ①アカウントには複数のメタストア を作成可能だが、クラウドリージョンごとに 1つまで ②ワークスペースには、 同じリージョンのメタストアを 1つだけ紐付けられる ③ワークスペースにはメタストア内の任意のカタログをアタッチできる （ワークスペースカタログバインディング） 1 2 3 * per 1 region * same region
16. ワークスペースカタログバインディング • カタログの [ワークスペース] タブから操作 • 既定は [すべてのワークスペー スがアクセス可能 ] • 厳密には同じメタストアに接 続されているすべてのワーク スペース • 2種類のアクセスレベル • Read & Write（読み書き） • Read Only（読み取り専用） 16 カタログへのアクセスを特定のワークスペースに制限できる機能。 カタログの所有者が実行できる
17. 主要な管理者ロール 17 アカウント、メタストア、ワークスペースには既定の管理者ロールが存在する アカウント管理者 (Account Admin) 能力 • (AWS/Google Cloudの場合) ワークスペース作成 • メタストア作成 & 設定 • ユーザー, グループ, サービスプリンシパル作成 • ユーザーへのワークスペースへのアクセス権を付与 担当者（推奨） • 基盤管理チーム / 中央ガバナンスチーム メタストア管理者 (Metastore Admin) 能力 • カタログ及びストレージ関連オブジェクト（EXTERNAL LOCATION, CREDENTIAL）の作成 • データ共有用オブジェクト（SHARE, RECIPIENT）の作成 • UCオブジェクトの所有者変更 担当者（推奨） • 基盤管理チーム / 中央ガバナンスチーム • ※データ（カタログ）所有者への権限移譲 ワークスペース管理者 (Workspace Admin) 能力 • ワークスペースにユーザーとグループを追加 • コンピュート & ポリシーの作成 • コンピュート、ジョブ、ノートブック、クエリ、ダッシュボード等の 所有者変更 担当者（推奨） • IT/基盤/DevOpsチーム カタログ所有者 (Catalog Owner) 能力 • カタログ内オブジェクト(CATALOG, SCHEMA, TABLE, VIEW, etc.)の所有者変更・削除 • 任意のプリンシパルに任意の特権を付与 担当者（推奨） • BUガバナンスチーム / 中央ガバナンスチーム • ※メタストア管理者からの権限移譲
18. 主要な管理者ロール 18 アカウント、メタストア、ワークスペースには既定の管理者ロールが存在する アカウント管理者 (Account Admin) 能力 • (AWS/GCの場合) ワークスペース作成 • メタストア作成 & 設定 • ユーザー, グループ, サービスプリンシパル作成 • ユーザーへのワークスペースへのアクセス権を付与 担当者（推奨） • 基盤管理チーム / 中央ガバナンスチーム メタストア管理者 (Metastore Admin) 能力 • カタログ及びストレージ関連オブジェクト（EXTERNAL LOCATION, CREDENTIAL）の作成 • データ共有用オブジェクト（SHARE, RECIPIENT）の作成 • UCオブジェクトの所有者変更 担当者（推奨） • 基盤管理チーム / 中央ガバナンスチーム • ※データ（カタログ）所有者への権限移譲 ワークスペース管理者 (Workspace Admin) 能力 • ワークスペースにユーザーとグループを追加 • コンピュート & ポリシーの作成 • コンピュート、ジョブ、ノートブック、クエリ、ダッシュボード等の 所有者変更 担当者（推奨） • IT/基盤/DevOpsチーム カタログ所有者 (Catalog Owner) • カタログ内オブジェクト(CATALOG, SCHEMA, TABLE, VIEW, etc.)の所有者変更・削除 • 任意のプリンシパルに任意の特権を付与 担当者（推奨） • BUガバナンスチーム / 中央ガバナンスチーム • ※メタストア管理者からの権限移譲 ベストプラクティス ★ アカウント / ワークスペース / メタストア管理者 は中央管理者が責務を持つ ★ カタログの所有者権限を中央管理者からデー タの所有者（事業部内チーム） に移管する
19. 19 アクティビティ (2min) 1. ワークスペースにログインしてみましょう 2. ワークスペースの設定画面を開き、どんな設定項目があるかを確 認しましょう - 右上名前アイコン -> 「設定」 - ※ワークスペース管理者の場合「ワークスペース管理者」メニューが表示されます 3. （アカウント / メタストア管理者のみ）ワークスペースおよびアカウ ントコンソールのメタストア管理導線を確認しましょう - ワークスペース: 「カタログ」-> ⚙アイコン -> メタストア - アカウントコンソール : 「カタログ」メニュー
20. アイデンティティ 管理 プラットフォームエンジニア　ワークショップ
21. 21 質問 ★ Databricksのアイデンティティ（人、システム ユーザー、他）の種類にはどのようなものがあ りますか？
22. 3種類のアイデンティティ 22 Databricksを操作する主体はユーザーとサービスプリンシパルの2種類が存在す る。グループは両者を束ねた集合体 項目 ユーザー サービスプリンシパル グループ 定義 人間の利用者 自動化・アプリ用の主体 複数の主体を束ねる入れ物 主な用途 画面ログインして操作 Jobs、スクリプト、CI/CD、API 実行 権限をまとめて付与 単位 通常はメールアドレス 自動化用ID (client id) ユーザー/サービスプリンシパ ル等の集合 管理単位 アカウント単位 で管理し、各 ワークスペースへ割当 同左 同左※ ※ワークスペースローカルグループは存在するが、レガシーのため非推奨
23. ワークスペースへの ID追加 23 アカウントに追加されたユーザーは、ワークスペース管理者設定またはアカウントコ ンソールからワークスペースに割り当てることが可能 ワークスペース管理画面 （for ワークスペース管理者 ) アカウントコンソール （for アカウント管理者）
24. エンタイトルメント ワークスペース内の特定の機能セットへのアクセス権を表す。コンシューマーアクセ ス、SQLアクセス、ワークスペースアクセスの3種が存在 ※ワークスペースにアクセスするには、ユーザーは少なくとも 1 つのアクセス権限を持っている必要がある ※権限は加算的に評価される https://docs.databricks.com/aws/ja/security/auth/entitlements
25. エンタイトルメントの設定 ワークスペース管理者により、ワークスペース x ユーザー(グループやSP含む)単位 で設定する
26. グループ単位の招待・アクセス制御 26 アカウント単位でグループを管理し、ワークスペースに招待・メタストア配下のデータ へのアクセス権限を制御する アカウント ワークスペース bu1_prod ワークスペース bu1_dev グループ bu1_users グループ bu1_authors • user aaa • SP xxx • Consumer Access • user aaa • SP xxx • SQL Access • Workspace Access メンバー エンタイトルメント メンバー エンタイトルメント メタストア カタログ xxx_prod カタログ xxx_dev SELECT MODIFY INVITE
27. グループ単位の招待・アクセス制御 27 アカウント単位でグループを管理し、ワークスペースに招待・メタストア配下のデータ へのアクセス権限を制御する アカウント ワークスペース bu1_prod ワークスペース bu1_dev グループ bu1_users グループ bu1_authors • user aaa • SP xxx • Consumer Access • user aaa • SP xxx • SQL Access • Workspace Access メンバー エンタイトルメント メンバー エンタイトルメント メタストア カタログ xxx_prod カタログ xxx_dev READ WRITE ATTACH ベストプラクティス ★ AIM (自動ID管理)を使用してIdPからユーザー を自動プロビジョニングする ★ 既定のエンタイトルメントをConsumer Accessにし権限を最小限にする
28. ユーザープロビジョニングの方式 方式 (推奨) AIM Automatic Identity Management SCIM System for Cross-domain Identity Management 概要 Databricks ネイティブ のユーザープロビジョニング方 式 標準プロトコル SCIM を使ったユーザープロビジョニ ング方式 導入のしやすさ シンプル、Azure では追加アプリ不要 SCIM アプリ設定、token / URL 設定が必要 ※アカウントレベルを推奨、ワークスペースレベルはレ ガシー設定 同期対象 • ユーザー、グループ、 (Azureのみ)サービスプリ ンシパル • ネストされたグループをサポート • ユーザー、グループ • ネストされたグループをサポートしない 反映タイミング JITあり。初回ログイン時に自動作成 定期同期ベース 対応 IdP Entra ID (Azure: GA, AWS / GC: PuPr) Okta (AWS / GC: PrPr) Entra ID、Okta、OneLoginなど 参考リンク AWS / Azure / Google Cloud AWS / Azure / Google Cloud どちらもIdPからDatabricksアカウントにアイデンティティを同期する方式であるが、 導入が軽く同期対象が広いAIMの利用を推奨
29. エンタイトルメントの使い分け ビジネスユーザーのエンタイトルメントをConsumer Accessに限定することで、利 用機能が限定されたシンプルなUI (Genie)を使用可能 データエンジニア、サイエンティスト、他 ビジネスユーザー 使用者 主な用途 推奨設定 作成済のデータプロダクト(アプリ, ダッシュボー ド, Genie Spaces)の閲覧 新規データプロダクトの作成、ノートブックやパイ プラインによるデータ加工分析 エンタイトルメントをConsumer Accessに限定 し、“Genie”画面を閲覧 ※デフォルト設定を推奨！ エンタイトルメントにWorkspace Access / SQL Accessを付与し、”Lakehouse” “App” など最適な画面を選択
30. Before After 既定エンタイトルメントの権限最小化 Workspace: X Group: users (default, workspace-local) Workspace Access SQL Access • 既定では、全てのユーザーはワークスペース のグループusersに所属する • ユーザーはusersグループのエンタイトルメン トを通して、ワークスペースアクセス権と SQL アクセス権を所有する Workspace: X Group: users (default, workspace-local) Consumer Access Group: authors-x (account-level) Workspace Access SQL Access グループクローニングにより以下 2つが実行され、 新規に追加されるユーザーが既定でコンシュー マーアクセス権のみを持つ ようになる 1. 既存usersグループを任意のアカウントグ ループに複製する　※ユーザーの元の権限 を維持する 2. usersグループのエンタイトルメントを Consumer Access権のみに変更 する New 1 2 グループクローニングにより、既存のユーザー権限を維持したまま新規ユーザーの 権限をConsumer Accessに限定することが可能 Group Cloning Doc：デフォルトのワークスペース アクセスをコンシューマー アクセスに変更する（AWS / Azure / Google Cloud）
31. 参考：Unified Login (Databricks on AWS) • 一元化された SSO管理：Databricksアカウントレベルで1回SSOの設定すれ ば、その設定をアカウントと全てのワークスペースに共通適用できる仕組み。 • 共通のログイン体験 ：Unified Login有効化後、エンドユーザーはアカウントと 全ワークスペースにSSOでログインする。 • 適用条件・前提 ：以下の条件に当てはまる多くのアカウントでは既定で有効 ◦ 2023-06-21 以降にアカウントが作成されている ◦ 2024-12-12 以前にSSO未設定である • 参考リンク： AWS
32. カタログ管理 プラットフォームエンジニア　ワークショップ
33. 33 質問 ★ Unity Catalogとはどのような機能ですか？ ★ Unity Catalogで管理するオブジェクトにはど のようなものがあるでしょうか？ ◦ メタストア、カタログ、...
34. 従来の カタログ Delta Lake Parquet Iceberg アクセス コントロール ディスカバリー リネージ 監査 安全・オープン データ共有 品質 モニタリング コスト コントロール ビジネス セマンティクス セキュリティ コラボレーション 品質 洞察 テーブル AIモデル ファイル ノートブック ダッシュボード あらゆる 外部データソース を接続 あらゆるツール、エンジン、プ ラットフォーム によるオープンアクセスとコラ ボレーション Unity Catalog すべてのData+AI の統合かつオープンなガバナンス 34
35. メタストア Metastore スキーマ Schema テーブル Table ビュー View ボリューム Volume 関数 Function カタログ Catalog 接続 Connection 外部 ロケーション External Location ストレージ 資格情報 Storage Credential クリーン ルーム Clean Room 共有者 Provider 受信者 Recipient 共有 Share サービス 資格情報 Service Credential 35 Unity Catalog セキュリティ保護可能なオブジェクト モデル Model
36. ②メタデータ管理 と権限制御 ③外部との共有 ①データソースとの接続 メタストア Metastore スキーマ Schema テーブル Table ビュー View ボリューム Volume 関数 Function カタログ Catalog 接続 Connection 外部 ロケーション External Location ストレージ 資格情報 Storage Credential クリーン ルーム Clean Room 共有者 Provider 受信者 Recipient 共有 Share サービス 資格情報 Service Credential 36 Unity Catalog セキュリティ保護可能なオブジェクト モデル Model
37. ストレージ /サービス資格情報 - Storage / Service Credential 37 資格情報 • クラウドリソースへの資格情 報をカプセル化する • ストレージ資格情報はクラウド ストレージ、サービス資格情 報はクラウドネイティブサービ スに対応 ①データソースとの接続
38. 外部ロケーション External Location 38 外部ロケーション • ストレージパスと、そのパスへ のアクセスを許可する資格情報 のセット • カタログ、スキーマのマネージド ロケーションとして登録 • テーブル/ボリュームの外部の 場所としても登録可能 CREATE EXTERNAL LOCATION `s3-remote` URL 's3://us-east-1/location' WITH (STORAGE CREDENTIAL `s3-remote-cred`) COMMENT 'Bucket for Finance business unit' ①データソースとの接続
39. 接続 - Connection 39 接続 • 外部システムやメタストアをミ ラーリングするフェデレーショ ン機能などで使用 • 接続オブジェクトで接続情報 を登録し、フォーリンカタログ としてデータを利用 CREATE CONNECTION your_connection_name TYPE POSTGRESQL OPTIONS ( host 'qf-postgresql-demo...com', port '1234', user secret('secrets.r.us', 'your_username'), password secret('secrets.r.us', 'your_password')) ; CREATE FOREIGN CATALOG IF NOT EXISTS my_foreign_catalog USING CONNECTION my_connection_name OPTIONS (database 'external_database_name') ; ①データソースとの接続
40. データエステートの統合ビューを構 築 データソースにまたがるデータの 保護 効率的な実行とキャッシュ 参考. レイクハウスフェデレーション ユーザー ダッシュボード PostgreSQL Google BigQuery Snowflake Redshift データの場所を問わず、すべてのデータを発見、クエリ、管理可能 40 ①データソースとの接続
41. その他のストレージ（Cloudflare、S3） External Location クラウドストレージ（S3、ADLS、GCS） External Location Unity Catalog my_metastore 資格情報、外部ロケーション、接続 Unity Catalog上での資格情報、クラウドファイル、サービスおよびシステムの管理 External Location Storage Credential Storage Credential Storage Credential External Location クラウドサービス（AWS／Azure SDK、…） Service Credential ソースシステム（Oracle、Salesforceなど） Connection ①データソースとの接続
42. クラウドストレージ （S3、ADLS、GCS） カタログ2 マネージド コンテナ／バケット 2) カタログで定義する オブジェクトへのストレージ割り当て メタストア/カタログ/スキーマのレベルで外部ロケーションを設定し、マネージドに指定さ れるクラウドストレージのパスを指定する デフォルトのマネージド コンテナ／バケット メタストア Unity Catalog スキーマ2 スキーマ1 カタログ1 1) メタストアに関連付けられたデ フォルトのストレージ マネージド コンテナ／バケット スキーマ3 3) スキーマで定義する オプション ①データソースとの接続 外部ロケーションの設定 外部ロケーションの 設定
43. クラウドストレージ（ S3、 ADLS、GCS） カタログ2 マネージド コンテナ／バケット 2) カタログで定義する オブジェクトへのストレージ割り当て メタストア/カタログ/スキーマのレベルで外部ロケーションを設定可能 デフォルトのマネージド コンテナ／バケット メタストア Unity Catalog スキーマ2 スキーマ1 カタログ1 1) メタストアに関連付けられたデ フォルトのストレージ マネージド コンテナ／バケット スキーマ3 3) スキーマで定義する オプション ①データソースとの接続 ベストプラクティス ★ カタログレベルで外部ロケーションを定義する ことで、明示的なストレージ構成を確保する ※物理的な分離が求められることが多い、複数のデプロイメント環 境（開発環境と本番環境）間でカタログを分離する場合に特に役立 つ
44. 44 カタログ、スキーマ • カタログは複数のスキーマを まとめる • 配下のオブジェクトを3階層の 名前空間で管理 カタログ、スキーマ - Catalog, Schema CREATE CATALOG IF NOT EXISTS my_catalog MANAGED LOCATION 's3://us-east-1/location/sub/path' ②メタデータ管理 と権限制御
45. データソース横断の管理された名前空間 クエリフェデレーションを利用したレガシーメタストアと外部データベースへのアクセ ス SELECT * FROM main.paul.red_wine; -- <catalog>.<database>.<table> SELECT * FROM hive_metastore.default.customers; default (データベース) customers (テーブル) モデル/ 関数 外部 スキーマ SELECT * FROM snowflake_warehouse.some_schema.some_table; 外部 テーブル hive_metastore (レガシー) Unity 　　　 Catalog 外部 カタログ スキーマ 1 External Table マネージド/外部 ボリューム ビュー マネージド/外部 テーブル カタログ 1 共有スキーマ 共有テーブル 共有カタログ ②メタデータ管理 と権限制御
46. 46 テーブル • 表形式データ • マネージドテーブル 、外部 テーブル、フォーリンテーブ ルが存在 テーブル - Table ②メタデータ管理 と権限制御 CREATE TABLE IF NOT EXISTS my_table (id INT, name STRING, age INT) COMMENT 'this is a comment' TBLPROPERTIES ('foo'='bar');
47. マネージド /外部ロケーション 47 ユーザー クラスターまたは SQLウェアハウス クラウドストレージ (S3, ADLS, GCS) 外部ロケーションのパス 外部ロケーションのパス ... 外部ロケーションと 資格情報 アクセスコントロー ル ボリューム テーブル 　Unity 　　　　 Catalog スキーマ/カタログ上のマ ネージドロケーション マネージド マ ネ ー ジ ド 外 部 外部 場所を指定せずに作られたテーブルやボリュームは”マネージド”として扱われ、外部 ロケーションを指定すると”外部”として扱われる ②メタデータ管理 と権限制御
48. Liquid Clusteringは、データスキップを最大化 するようにデータレイアウトを整理する 予測最適化により、パフォーマンスが自動的に向 上 マネージドテーブル - Managed Table シンプルで高性能なテーブル 変換はワンステップでシンプル！ 変換処理中に同時書き込みを処理しながら、テーブル履 歴と構成を保持する。読み取りと書き込みのダウンタイ ムを最小限に抑える ALTER TABLE catalog.schema.my_external_table SET MANAGED Spark Trino Flink Create table Delta Lake Iceberg AI-driven Predictive Optimization Read table Snowflake DBX Iceberg REST Unity REST Iceberg REST ②メタデータ管理 と権限制御
49. マネージド＋外部アセット 特徴 マネージド - Managed 外部 - External (Unmanaged) テーブルのタイププロパティ値 “MANAGED“ "EXTERNAL" DROP Tableのふるまい • DROPコマンドはメタデータを破棄し、基となるデータは 30日以内にストレージアカウントから削除される • UNDROPコマンドはテーブルの削除に使用できます • メタデータのみを破棄し、データは削除されない。データの削 除が必要な場合は、手動で行う必要がある Create Table構文 CREATE TABLE [<catalog>.][<schema>.]<table> ... CREATE TABLE [<catalog>.][<schema>.]<table> ... LOCATION ‘abfss:/cont@stacct.dfs.core.windows.net'; データファイルの保存場所 指定されているマネージドロケーションのうち、最初に見つかっ た場所：スキーマ -> カタログ -> メタストア。 LOCATIONキーワードで指定されたパス パフォーマンス最適化 予測的最適化による自動的な最適化（Optimize、Vacuum、 Analyze、…）の実行 手動管理 データフォーマットのサポート DELTA、ICEBERG DELTA、CSV、JSON、AVRO、PARQUET、ORC、TEXT テーブル作成と管理を簡素化 ②メタデータ管理 と権限制御
50. マネージド＋外部アセット 特徴 マネージド - Managed 外部 - External (Unmanaged) テーブルのタイププロパティ値 “MANAGED“ "EXTERNAL" DROP Tableのふるまい • DROPコマンドはメタデータを破棄し、基となるデータは 30日以内にストレージアカウントから削除される • UNDROPコマンドはテーブルの削除に使用できます • メタデータのみを破棄し、データは削除されない。データの削 除が必要な場合は、手動で行う必要がある Create Table構文 CREATE TABLE [<catalog>.][<schema>.]<table> ... CREATE TABLE [<catalog>.][<schema>.]<table> ... LOCATION ‘abfss:/cont@stacct.dfs.core.windows.net'; データファイルの保存場所 指定されているマネージドロケーションのうち、最初に見つかっ た場所：スキーマ -> カタログ -> メタストア。 LOCATIONキーワードで指定されたパス パフォーマンス最適化 予測的最適化による自動的な最適化（Optimize、Vacuum、 Analyze、…）の実行 手動管理 データフォーマットのサポート DELTA、ICEBERG DELTA、CSV、JSON、AVRO、PARQUET、ORC、TEXT テーブル作成と管理を簡素化 ②メタデータ管理 と権限制御 ベストプラクティス ★ マネージドテーブルから開始する パフォーマンスと操作性を最大限に高めるため、可能な限り マネージドテーブルを使用することを推奨
51. ビュー View 関数 Function 接続 Connection 外部 ロケーション External Location ストレージ 資格情報 Storage Credential クリーン ルーム Clean Room 共有者 Provider 受信者 Recipient 共有 Share サービス 資格情報 Service Credential 51 メタストア Metastore ボリューム • 表形式以外のオブジェクトを 管理するコンテナ • マネージドボリューム と外部 ボリューム が存在 スキーマ Schema カタログ Catalog テーブル Table ボリューム Volume ボリューム - Volume ②メタデータ管理 と権限制御
52. 52 Unity Catalogボリュームの活用 Unity Catalogガバナンスによるファイルへのアクセス、保存、整理、処理 • POSIXコマンドでアクセス dbutils.fs.ls(“s3://my_external_location/Volumes/catalog/schema/volum e123”) ls /Volumes/catalog/schema/volume123 • マネージドまたは外部ロケーションに作成され、リネージに表示される • 表形式でないデータセットに対するガバナンスを適用する ◦ 機械学習に使用される非構造化データ（画像、音声、動画、 PDFファイル） ◦ 機械学習モデルのトレーニングに使用される、半構造化されたトレーニング、検証、 テストデータセット ◦ アドホックまたは初期段階のデータ探索、または保存された出力に使用される生 データファイル ◦ ワークスペース間で使用されるライブラリまたは設定ファイル ◦ ロギングやチェックポイント出力ファイルなどの運用データ クラウドストレージ (S3, ADLS, GCS) マネージド / 外部 ロケーション 　ボリューム 　　ボリューム 　テーブル Data データ ②メタデータ管理 と権限制御
53. Delta Sharing - データ共有 53 リージョン/クラウドを跨ぐDatabricksワークスペース同士のデータ共有が 必要な場合、Databricks to DatabricksのDelta Sharingを利用する Delta Lake Delta Sharing + Unity Catalog + ✔ パーティションフィルタ ✔ 統合データガバナンス ✔ IPアクセス / クラウド リージョン制限 ✔ SQL API と UI Databricks-managed sharing connection Delta Sharing + Unity Catalog + ✔ SQL API と UI ✔ 統合データガバナンス ✔ 共有ビューにアクセス データ受信者（Recipient） データ提供者（Provider） ✔ トークンの交換 & 管理不要 ✔ ゼロコピー & ライ 　 ブ共有 Databricks on AWS Azure Databricks ③外部との共有
54. Delta Sharing 動作の裏側 54 備考 • 共有は Deltaのファイル単位で行われ、テーブル全体・特 定のパーティション・バージョン指定（タイムトラベル）にも対 応 • クライアント側はシステムに依存せず、 Parquetファイルを 読み取れるだけで利用可能 • Databricks では Sharing Server と Unity Catalog が統 合されており、一元管理が可能 Delta Table Delta Sharing サーバー Delta Sharing クライアント データ共有者 データ受信者 Delta Sharing Protocol Access Permissions Parquet files テーブルをリクエスト 署名付きの短時間 有効なURL オブジェクトストア内のファイル （Parquet形式）への直接アクセス Delta Sharing Protocol: 1. クライアントが Sharingサーバーに対して認証を行う 2. クライアントがテーブル（フィルタ条件付き）をリクエストする 3. サーバーがアクセス権限をチェックする 4. サーバーが署名付きの短時間有効な URLを生成・返却す る 5. クライアントはそのURLを使って、オブジェクトストレージか らファイルを直接読み込む Power BI データ受信者は、Delta Sharingサーバーに認証して共有テーブルを要求し、権限 確認後に返される署名付き短期URLでParquetファイルを直接読み取る ③外部との共有
55. Delta SharingとUCオブジェクト メタストアX カタログ A スキーマ A1 テーブル A1-1 共有 S スキーマ A1 テーブル A1-1 メタストアY 受信者Y (forメタストアY) 共有者X (forメタストアX) カタログ B スキーマ B1 テーブル B1-1 スキーマ B1 テーブル B1-1 共有カタログ S’ スキーマ A1’ テーブル A1-1’ スキーマ B1’ テーブル B1-1’ アカウントX (共有側) アカウントY (受信側) 55 受信者、共有者 • 共有側：受信者を識別する RECIPIENTを作成する。 • 受信側：共有後、メタストアには共 有者を示すPROVIDERが自動作 成される 共有 • 共有者：共有対象の資産を SHAREに紐づける • 受信者：受信したSHAREから共有 カタログを作成する ※自動作成 ③外部との共有
56. Delta SharingとUCオブジェクト メタストアX カタログ A スキーマ A1 テーブル A1-1 共有 S スキーマ A1 テーブル A1-1 メタストアY 受信者Y (forメタストアY) 共有者X (forメタストアX) カタログ B スキーマ B1 テーブル B1-1 スキーマ B1 テーブル B1-1 共有カタログ S’ スキーマ A1’ テーブル A1-1’ スキーマ B1’ テーブル B1-1’ アカウントX (共有側) アカウントY (受信側) 56 受信者、共有者 • 共有側：受信者を識別する RECIPIENTを作成する。 • 受信側：共有後、メタストアには共 有者を示すPROVIDERが自動作 成される 共有 • 共有者：共有対象の資産を SHAREに紐づける • 受信者：受信したSHAREから共有 カタログを作成する ※自動作成 ③外部との共有 ベストプラクティス ★ 他メタストア (リージョン / アカウント / クラウド 跨ぎ )のデータ共有には Delta Sharingを使用する ※メタストア内のデータ共有（ワークスペース間）はワークスペース とカタログのバインディングで対応可能
57. 57 アクティビティ (2min) 1. 「カタログ」メニューを押下し、カタログエクスプローラーを開きま しょう 2. 検索タブから、適当なテーブルを検索し、右側のエリアに表示しま しょう - 例：samples.nyctaxi.trips 3. 右側のタブ（概要、サンプルデータ、...）から、どのような情報を得 られるか確認しましょう 4. 他のオブジェクト（カタログ、スキーマ、その他）も確認しましょう
58. 権限管理 プラットフォームエンジニア　ワークショップ
59. 59 質問 ★ Unity Catalogで付与可能な権限にはどのよう な種類がありますか？ ★ Unity Catalogではどの粒度で権限を設定する ことが可能でしょうか？
60. • Unity Catalogメタストア内で 定義されたセキュリティ保護 対象オブジェクトに対して、プ リンシパル（ユーザー、グ ループなど）に権限を付与す ることができる • SQLを使用して、UI上および プログラム的に作成可能 集中アクセス制御 すべてのデータとAI資産を統合的に管理するガバナンス GRANT <privilege> ON <securable_type> <securable_name> TO `<principal>` GRANT CREATE TABLE ON SCHEMA my_catalog.my_schema TO `finance-team`; Unity Catalog権限モデルの概念 | Databricks on AWS
61. 所有者とMANAGE権限 “所有者”はそのUnity Catalogオブジェクトの真の管理者であるが、MANAGE権限の付 与によって管理業務を移譲することが可能 61 所有者（Owner） オブジェクトの本当の”管理者” - UCオブジェクトに対して設定される 単 一の主体（ユーザー、SP、グループ） - 全権限を暗黙的に持つのに加え、 権 限付与/剥奪、所有権移譲、削除 が可 能 MANAGE権限 ”管理作業だけ移譲”するための権限 - UCオブジェクトに対して設定可能な権 限の1つ - 複数の主体に付与可能 - 権限付与/剥奪、所有権移譲、削除 が 可能だが、それ自体はデータアクセス 権（SELECT等）を持たない
62. セルフサービスのための情報検索と BROWSE権限 62 メタデータのみ閲覧可能とするBROWSE権限と、アクセス要求機能を組み合わせ て、ユーザーのデータ探索の自由度を向上させる • カタログエクスプローラー、schemaブラウ ザ、検索結果、lineageグラフ、情報スキー マ、およびRESTAPIを使用して、オブジェク トのメタデータ を表示できる • この権限単体では、ユーザーはオブジェク トのサンプルデータを閲覧することはでき ない • カタログ、Clean Rooms、および外部拠点 のみに適用される • BROWSE権限でオブジェクトのメタデータ を表示すると、ユーザーは「アクセス要 求」ボタンを使用して、そのオブジェクトに 対するアクセス許可を要求できる • リクエストは、オブジェクトごとにカスタマイ ズ可能なアクセスリクエスト宛先にルー ティングされる • • BROWSE権限 アクセス要求 アクセスリクエストを管理する | Databricks on AWS
63. データ分類 ガバナンスタグを大規模に適用する • データ分類は、カタログ内のテーブルを自動的に分 類する機能。以下の用途で使用可能 • 機密データの検出 • 行レベル・列レベルのセキュリティ • テーブルレベルのセキュリティ • データ分類を有効にするには、 catalogに対して MANAGE, CREATE SCHEMA, SELECT権限 が必要 ※管理タグを使用するユースケースでは、タグに対して ASSIGN権限、テーブルに対して APPLY TAG権限も必 要 データ分類 | Databricks on AWS
64. 管理タグ • 管理対象タグはアカウントレベル で定義される • タグの割り当て権限（制限）を持 つユーザーは、USE CATALOG, USE SCHEMA, APPLY TAG権 限を持つオブジェクトにそのタグ を適用可能 • ABACによるアクセス管理、リ ソース使用状況、課金、および検 出に使用する タグの標準化と適用方法 管理タグ | Databricks on AWS
65. きめ細やかなセキュリティ 65 行・列単位のきめ細やかなアクセスコントロール 行：特定レコードのみにフィルタ 構文概要: CREATE FUNCTION <name> ( <parameter_name> <parameter_type> .. ) RETURN {booleanを返すフィルタ句 } 実装例:　 -- Adminグループは全行、他は USリージョンの行のみ表示 CREATE FUNCTION us_filter(region STRING) RETURN IF(IS_MEMBER(‘admin’), true, region=“US”); ALTER TABLE sales SET ROW FILTER us_filter ON region; グループメンバーシッ プをテスト 再利用可能なフィルター をテーブルに割り当て フィルター述語を指定 列：特定カラムのみにマスク 構文概要: CREATE FUNCTION <name> (<p_name>, <p_type>, [, <col>...]) RETURN {第1引数と同じ型の式 } 実装例: -- Adminグループ以外には ssnを****と表示されるようマスク CREATE FUNCTION ssn_mask(ssn STRING) RETURN IF(IS_MEMBER(‘admin’), ssn, “****”); ALTER TABLE users ALTER COLUMN ssn SET MASK ssn_mask; グループメンバーシップ をテスト 再利用可能なマスクを 列に割り当て マスクまたはマスク関数を 指定
66. 属性ベースのアクセスコントロール（ ABAC） ガバナンスポリシーの策定 • ポリシーはカタログ、スキーマ、テーブルに定義で き、親コンテナから継承される（スキーマはカタログ からポリシーを継承する） • ポリシー定義は、プリンシパル（ユーザー、グループ など）を対象とし、管理タグに基づいてオブジェクト に適用可能 • ポリシーの種類： • 利用可能：行フィルター／列マスク • 近日公開：GRANT / DENY • MANAGE権限を持つ所有者またはユーザーは、 Unity Catalogオブジェクトにポリシーを適用可能 Unity Catalogにおける属性ベースのアクセス制御 | Databricks on AWS
67. ABACのコンセプト ABACは属性でユーザーやデータを表現し、ルールでアクセス条件を定義し、それらを継 承して階層全体に一貫して適用するアクセス制御モデル 属性 Attributes ルール Rules 継承 Inheritance ポリシーが評価されるオ ブジェクトのコンテキスト （タグ、他） アクセスコントロールを定 めるルール ルールやタグは下位オ ブジェクトに加算的に継 承される
68. ABACによるスケーラブルなガバナンス txn_data Unity Catalog メタストア sales_prod business_unit カタログ ⇨ スキーマ ⇨ データ ⇨ SET Mask UDF ON Column WHEN has_tag(‘phone’) full_name cell_phone Todd G 321-123-**** Malik (データを生み出したい ) ルールを 作成 Juan (データを管理したい) タグを適用 (tags) マスクルールが 自動的に適用 *のみ参照可 1 2 3 データを読み 込み 4 5 Sarita (データをクエリしたい ) ⇶ full_name ⇶ cell_phone phone RULE
69. 69 アクティビティ (2min) 1. 「カタログ」メニューを押下し、カタログエクスプローラーを開きま しょう 2. 適当なテーブルを開いて「権限」タブを確認し、自身にどのような 権限が割り振られているかを確認しましょう
70. 計算資源管理 プラットフォームエンジニア　ワークショップ
71. 71 質問 ★ Databricksにおける”コンピュート”の役割は何 ですか？ ★ コンピュートには、どのような種類があります か？
72. サーバーレス コンピューティングプレーン コントロールプレーン 72 クラシック コンピューティングプレーン お客様クラウド 前提：インフラストラクチャ Unity Catalog Webアプリ、REST API ノートブック、SQLクエリ ユーザー コンピュート ストレージ クラウドストレージ ノートブック, ワークフロー, SDP SQLウェアハウス (Serverless) モデルサービング etc. 汎用コンピュート (Standard / ML) ジョブコンピュート (Standard / ML) SQLウェアハウス (Classic / Pro) … Databricksは、コントロールプレーンとコンピューティングプレーンで構成 コンピューティングプレーンは、サーバーレスおよびクラシックの二種類 AWS: VPC - EC2 Azure: Vnet - VM Google Cloud: VPC - VM AWS: S3 Azure: ADLS Google Cloud: GCS
73. コンピュートの役割 73 Databricks ワークスペース ノートブック / クエリ / ダッシュボード / … ユーザー コンピュート SQLクエリやPythonスクリプトの実行などの全ての計算処理はDatabricksのコン ピュート上で実行される Databricksによるデータ分析 データ (Unity Catalog)
74. Databricksコンピュートの提供価値 74 高性能のSpark環境を、安定した状態で、楽に使用可能 性能 安定・互換性 運用性 Apache Spark互換 & Photon エンジン で大規模データでもス ケーラブルに高速処理 Databricks Runtime によっ て、Spark本体・ライブラリ・最適 化が検証済みの形で提供され、 用途に応じて選択可能 サーバーレスコンピュート や自 動スケーリング により、クラスタ のサイジングや管理負荷を減ら しつつ、必要なときに必要な分 だけ使える
75. コンピュートと Databricksの費用の関係 ほとんどのワークロードにおいて、Databricksコストはコンピュートの起動時間中 に、秒単位の従量課金で発生する コスト発生タイミング（クラシックコンピュートの例） 75 DBU:Databricks Unit, Databricks内の課金単位
76. 最適なコンピュートの選択 使用者とワークロード別に最適に設計されたコンピュートを選んで使用可能 76 データ サイエンティスト 画像処理とディープラーニング データエンジニア 大規模データの加工処理 ジョブ / パイプライン データアナリスト / ビジネスユーザー データの集計・可視化 ジョブコンピュート 低単価 タスク完了時に停止 ノートブック 汎用コンピュート インタラクティブ開発向け 柔軟な設定項目 (GPU, Node, Instance) SQLウェアハウス SQL実行に特化 シンプルなサイジング SQLクエリ / ダッシュボード / Genie Spaces
77. コンピュートの種類 名称 サーバーレスコンピューティング クラシックコンピューティング 特徴 インフラ管理が不要 即時利用可能 お客様環境で資源が稼働 詳細な設定が可能 用途 ノートブックでの対話的分析 Serverless Interactive All Purpose Clusters (Standard / ML*1) ジョブ実行 Standard / Performance Optimized Jobs Classic Clusters (Standard / ML*1) パイプライン実行 Serverless Core / Pro / Advanced SQLウェアハウス SQL Warehouse (Serverless) SQL Warehouse (Pro / Classic) モデルサービング Agent Bricks Model Serving - ベクトル検索 Agent Bricks Vector Search*2 - Webアプリ構築 Databricks Apps - OLTPデータベース Lakebase Postgresインスタンス*2 - *1: Standard: ビッグデータ分析体験を最適化する Apache Sparkやその他多くのコンポーネントを事前設定済み。 ML: TensorFlowやKeras、PyTorch、XGBoost などの一般的な機械 学習ライブラリを事前設定済み *2: コンピュートに加え、データも Databricks環境で管理される Databricksのプロダクトの多くはコンピュート上で実行される 77
78. コンピュートの種類 名称 サーバーレスコンピューティング クラシックコンピューティング 特徴 インフラ管理が不要 即時利用可能 お客様環境で資源が稼働 詳細な設定が可能 用途 ノートブックでの対話的分析 Serverless Interactive All Purpose Clusters (Standard / ML*1) ジョブ実行 Standard / Performance Optimized Jobs Classic Clusters (Standard / ML*1) パイプライン実行 Serverless Core / Pro / Advanced SQLウェアハウス SQL Warehouse (Serverless) SQL Warehouse (Pro / Classic) モデルサービング Agent Bricks Model Serving - ベクトル検索 Agent Bricks Vector Search*2 - Webアプリ構築 Databricks Apps - OLTPデータベース Lakebase Postgresインスタンス*2 - *1: Standard: ビッグデータ分析体験を最適化する Apache Sparkやその他多くのコンポーネントを事前設定済み。 ML: TensorFlowやKeras、PyTorch、XGBoost などの一般的な機械 学習ライブラリを事前設定済み *2: コンピュートに加え、データも Databricks環境で管理される Databricksのプロダクトの多くはコンピュート上で実行される 78 ベストプラクティス ★ フルマネージドなサーバーレスコンピュート を 使用し、即時利用による生産性向上・アイドル 時間を削減し低コスト化を狙う ★ コンピュートポリシー によって、想定外のコスト 発生を防ぐガードレールを敷く
79. サーバーレスのメリット • 設定なし • パフォーマンスチューニン グ不要 • 容量管理不要 • 自動アップグレード およびパッチ • コンピュートの起動を待つ ことなく、ユーザーが クエリをすぐに開始 • 即時のスケーリングで 並列に処理可能なユー ザー、クエリを増加 管理不要 (フルマネージド ) ユーザーの 生産性の向上 • 消費した分だけ支払い、ア イドル クラスター時間を削 減 • リソースのオーバー プロビ ジョニングなし • 自動終了 (最後のクエリか ら一定期間経過後に アイドル容量を削除) 低コスト 79
80. コンピュートポリシーの設定 ユーザーがのコンピュートを作成するときに、使える設定や上限をルールで制御す る仕組み 80 • ユーザーがコンピュートを作成する際に設定の制限を加える機能 • ユーザー/グループ毎に異なるポリシーを割り当てることが可能 • 同一のユーザー/グループに複数のコンピュートポリシーを割り当て、用途に応 じてデフォルト設定として使用することも可能 • 利用例 ◦ 使用できるインスタンスタイプ、台数の制限 ◦ 特定のタグを強制的に付与 ◦ ライブラリやSpark Confの指定 ◦ 等々、コンピュート設定に出てくるものは基本的に全て制御可能 コンピュート ポリシーの作成と管理
81. コンピュートのモニタリング 「モニタリング」タブまたはシステムテーブルからコンピュートのメトリクスを監視し、最 適なコンピュート設計のインプットとする 81 コンピュートのモニタリングの例（ SQL Warehouse） All Purpose & Job (Classic): コンピュートメトリクスの表示 | Databricks on AWS SQL Warehouse: SQLウェアハウスを監視する | Databricks on AWS
82. 82 アクティビティ (2min) 1. 「コンピュート」メニューを押下し、コンピュートの一覧画面を開きま しょう 2. 各タブ（汎用コンピュート、ジョブコンピュート、...）を遷移し、どのコ ンピュートが作動しているかを確認しましょう 3. 「コンピュートを作成」を押下し、設定可能な値を確認しましょう ※設定値を確認するのみ。確認後は「キャンセル」を押すか、作成後にコンピュートを直 ちに停止する
83. 予実管理 プラットフォームエンジニア　ワークショップ
84. 84 質問 ★ Databricksのコストは、DBUを使ってどのよう に算出することが可能ですか？ ★ 予算を設定 / 実績を管理するにはどのような 機能を使用できますか？
85. Databricks 費用構造 Databricksは従量課金であり、ほとんどの機能の請求金額はコンピュートの処理単 価と実行時間の積算で決まる 費用 ($/月) 処理単価 ($/h) 実行時間 (h/月) 費用の計算式 85
86. Databricks 費用構造 - DBUとは 処理単価はDBU単価($/DBU)とDBU消費量(DBU/h)で正規化されている コンピュート費用は、DBU単価・DBU消費量・実行時間の積算で計算される 費用 ($/月) DBU単価 ($/DBU) DBU消費量 (DBU/h) 実行時間 (h/月) 費用の計算式 DBU（Databricks Unit）：Databricksの処理能力をクラウドや リージョン横断で規格化した単位 86
87. Databricks 費用構造 - 要素分解 DBU単価は用途と実行環境、DBU消費量はコンピュートの処理能力、実行時間は 処理能力や様々な要因で定まる 費用 ($/月) 費用の計算式 以下で構成される SKUで決定 ✓ プロダクト ✓ プラン ✓ クラウド ✓ リージョン コンピュートの 処理能力 で決定 ✓ ノード数 ✓ ノードの種類 ✓ Photon有無 ✓ その他 様々な要因が複雑 に作用 ✓ 処理能力 ✓ データ量 ✓ 処理の複雑性 ✓ その他 87 DBU単価 ($/DBU) DBU消費量 (DBU/h) 実行時間 (h/月)
88. Databricks 費用計算の例（ジョブ） 費用 ($/月) 費用の計算式 例1. AWS ap-northeast-1でJobs Classic Clusterを月80h(4h×20日)稼働 コンピュートはi3.xlargeの2ワーカー（Photonあり）を使用 $96 /月 $0.20/DBU 6 DBU/h 80h 88 DBU単価 ($/DBU) DBU消費量 (DBU/h) 実行時間 (h/月) 1 2 3 1 1 3 2
89. (1) DBU単価 DBU単価はプロダクトと実行環境（＝SKU）によって定まり、Pricingページから参照 することが可能 DBU単価 ($/DBU) クラウド リージョン プロダクト プラン コンピュートが対応するプロダクトや 実行環境（プラン・クラウド・リージョン） で決定 ※Commit契約時の割引金額も DBU単価に作用する Lakeflow Jobs | Databricks Pricingページ DBU単価の決定要因 参照方法 89 Enterprise Plan, AWS Tokyo Regionの Job Classic Clustersで$0.20/DBU
90. 参考. SKUの種類 課金メニューの単位はSKUとして定義されている。どのプロダクト／用途で、どのプラ ン・クラウド・リージョンを使うかを定める https://www.databricks.com/product/sku-groups 90
91. (2) DBU消費量 - All Purpose/Job DBU消費量はコンピュート処理能力をリージョンやクラウド間で統一した規格であり、 コンピュート作成時に確認することが可能 DBU消費量 (DBU/h) ノードタイプ Photonの 有無 ノード数 コンピュートの能力（ノード数や種類） で決定 All Purpose/Job Computeの場合 Databricksワークスペース コンピュート作成画面 DBU消費量の決定要因 参照方法 i3.xlargeの2ワーカー（Photonあり）で 6 DBU/h 91
92. (2) DBU消費量 - SQL Warehouse DBU消費量はコンピュート処理能力をリージョンやクラウド間で統一した規格であり、 コンピュート作成時に確認することが可能 DBU消費量 (DBU/h) スケーリング (Min x, Max x) クラスター サイズ (XXS, XS, S, …) コンピュートの 能力（サイズやスケーリング） で決定 SQL Warehouseの場合 Databricksワークスペース SQL Warehouse作成画面 DBU消費量の決定要因 参照方法 Mサイズ、最小1-最大2で24-48DBU/h 1クエリの処理時間に 影響 複数クエリの並列処理性能に 影響 92
93. (3) 実行時間 実行時間はコンピュートの性能、データ量、その他の要因が相互に・間接的に作用 する 実行時間 (h/月) データ量 その他 DBU消費量 実行時間の決定要因 処理 ファイル数 ファイル 当たり サイズ 処理の 複雑性 データ レイアウト 他 ノード数 ノードタイプ 他 93
94. 参考. 費用計上における特殊な例 ほとんどの費用はDBU単価・DBU消費量・実行時間の積算で決定されるが、一部の 例外を説明する 基盤モデル API Pay Per Token サーバーレス ストレージ Lakebase / Vector Search / Serverless Workspace マネージドサービス 入出力したトークン によってDBUを消費（DBU / 1M Token） コンピュート実行時の DBUに加えて、保管するデータ量 当たりでのDSU*1 を消費（$ / GB / month） 予測的最適化、データ分類の機能の実行時に DBUを消 費 Foundation Model Serving | Databricks Vector Search | Databricks Lakebase | Databricks Storage | Databricks Databricks Managed Services 1 2 4 例 費用計上方式 参考リンク # *1 DSU: Databricks Storage Unit *2 DBU単価はSKU “SERVERLESS_REAL_TIME_INFERENCE”で算出 *3 150 DBU / user / monthまで無料で使用可能 *4 Public/Private Connectivity は接続方式ごとの費用、 Data Egress はAZ・リージョン・クラウド外など転送先 /経路ごとの費用が計上 94 Genie Genie Code / Genie Spaces 入出力したトークン によってDBUを消費（DBU / 1M Token）*2 。Free Tier*3 あり - 3 サーバーレス ネットワーク通信 Databricksサーバーレスと顧客側リソースの間の特定経 路の通信*4 において費用計上 Data Transfer & Connectivity | Databricks 5
95. システムテーブル： Databricksのすべての運用データを格納す るDatabricksホスト型の分析ストア ウォームパスとして、以下を含むお客様の履 歴オブザーバビリティ（観測可能性）のために 使用される システムテーブル - レイクハウスの可観測性 95 このユーザーは過去 24時間で何にアクセスしたか？ SELECT request_params.table_full_name system.operational_data.audit_logs から取得 WHERE user_identity.email = "ifi.derekli@databricks.com" かつ service_name = "unityCatalog" AND action_name = "generateTemporaryTableCredential" AND datediff(now(), created_at) < 1; Cost/usage analytics Efficiency analytics Audit analytics Data Quality analytics システムテーブルはすぐに使用可能、データへの洞察力を高める
96. システムテーブル - 課金関連のテーブル名 96 usage で「どれだけ使ったか」list_prices で「1単位いくらか」を把握する 注： • billingスキーマの取得スコープは ”Databricks”のみ（クラウドプロバイダーのコストは含まない） • list_pricesには全社共通の Promotionの情報を含むが、アカウント個別の discount情報は含まない system.billing.usage 利用実績データ（何DBU使用したか） system.billing.list_prices 単価マスタ（1DBUあたりいくらか） どのワークスペース／ジョブ／エンドポイン トがどれだけ使ったかの分析・コスト配賦に 使用する usage 利用量をリスト価格で金額換算する ための単価マスタの履歴の確認に使用する - sku_name: SKU名（料金プラン） - usage_quantity: 利用量（DBU など） - usage_start_time / usage_end_time: 利用期間 - billing_origin_product: 製品種別（ALL_PURPOSE など） - sku_name: SKU名 - price_start_time / price_end_time: 価格の有効期 間 - pricing.effective_list.default: 有効なリスト単 価 テーブル 用途 代表 カラム
97. システムテーブル - コスト算出のクエリ例 97 -- 特定タグに紐づく当月のリスト価格ベースコスト SELECT SUM(usage.usage_quantity * list_prices.pricing.effective_list.default) AS total_list_cost_usd FROM system.billing.usage AS usage JOIN system.billing.list_prices AS list_prices ON usage.sku_name = list_prices.sku_name AND usage.cloud = list_prices.cloud AND usage.usage_unit = list_prices.usage_unit -- usage 期間が価格の有効期間内に入るように絞り込む AND usage.usage_end_time >= list_prices.price_start_time AND (list_prices.price_end_time IS NULL OR usage.usage_end_time < list_prices.price_end_time) WHERE usage.custom_tags [:key] = :value AND usage.usage_date BETWEEN DATE '2025-05-01' AND DATE '2025-05-31'; その他のクエリの参考： https://docs.databricks.com/aws/en/admin/usage/system-tables 量(DBU) x 単価($/DBU)で金 額を算出 skuで両方のテーブルを結合
98. 予算管理 98 アカウント管理者は予算設定を行い、費用のモニタリングとアラートを設定すること が可能 予算の設定 予算の確認 予算管理機能 アカウントコンソール -> 使用量 -> 予算 ✓ 対象ワークスペース の設定 ✓ 閾値の設定 ✓ 超過時の通知 ※自動停止は不可 予算の作成と監視 | Databricks on AWS
99. 使用状況ダッシュボード 99 システムテーブルを入力に作成されたコストモニタリング用のダッシュボードをイン ポートできる。AI/BI機能準拠のためカスタマイズも可能 使用状況ダッシュボード | Databricks on AWS ダッシュボードのセットアップ （アカウントコンソール） ダッシュボードの例
100. 使用状況ダッシュボード 100 システムテーブルを入力に作成されたコストモニタリング用のダッシュボードをイン ポートできる。AI/BI機能準拠のためカスタマイズも可能 使用状況ダッシュボード | Databricks on AWS ダッシュボードのセットアップ （アカウントコンソール） ダッシュボードの例 ベストプラクティス ★ カスタムタグ やサーバーレス使用量ポリシー を設定し、コンピュートの利用量を任意の分類 で識別する
101. カスタムタグ 101 カスタムタグをコンピュートに付与し、コスト分析時にタグベースで識別することが可 能 コンピュートや一部リソースに付ける、コスト按分・追跡用の任意の key-valueタグ 概要 All Purpose Compute, Job Compute, SQL Warehouse (Serverless含む), 他 対象 設定例 : SQLウェアハウス 設定例 設定例 : ジョブ タグを使用して使用状況を属性付けし、追跡する | Databricks on AWS
102. サーバーレス使用量ポリシー 102 サーバーレスコンピュートの利用識別はサーバーレス使用量ポリシーを通しせて設 定したカスタムタグを通して行う サーバーレスワークロードに対して、課金記録へ自動でタグを付与するための規則 概要 Serverless Notebook, Serverless Job, Serverless Pipelines, Model Serving Endpoint, 他 対象 設定画面（ワークスペース管理者設定） 設定例 設定例 : ジョブ (サーバーレス ) サーバーレス使用ポリシー内でカスタムタグを定義 ポリシーを通してタグも付与 （既存のジョブのカスタムタグは上書きする） サーバレスでの属性の使用ポリシー | Databricks on AWS
103. 使いすぎの防止 • ノートブック ：spark.databricks.execution.timeoutによるSparkクエリの実行 時間上限設定 ※For無限ループなど、Pythonコードのミスは停止しないことに留意 • SQLウェアハウス ：STATEMENT_TIMEOUTの設定（スクリプト / ワークスペー ス単位） • ジョブ：Job Timeoutの設定 • 基盤モデル API：Unity AI Gatewayによる分単位クエリ(QPM)・分当たりトーク ン数(TPM)の制御 103 意図しない利用によるコンピュートの長時間稼働や使いすぎを防止する
104. 104 アクティビティ (2min) 1. 料金計算ツール（AWS / Google Cloud, Azure）にアクセスしま しょう 2. プラン、クラウド、コンピュートの種類を選び、特定時間あたりの費 用を計算しましょう 例：SQL Warehouse (Serverless) 時間あたりコスト Databricks on AWS / Google Cloud • Enterpriseプラン • SQL Serverlessコンピュート • AP (Tokyo)リージョン • 2X-smallサイズ1インスタンス、1時 間 x 1日 Azure Databricks • Servlerless SQLワークロード • Premiumプラン • Japan Eastリージョン • Hour表示
106. その他 監視・モニタリング プラットフォームエンジニア　ワークショップ
107. 107 質問 ★ システムテーブルでは、利用実績(billing)以外 にどのようなことが確認できますか？
108. オブザーバビリティとは何か オブザーバビリティ（可観測性）はデータプラットフォームにおける重要な要素であ り、以下の役割を担う • プラットフォームの利用状況を詳細に可視化する • コストや支出の影響を、それぞれの利用ケースと紐付けて把握できるようにする • データプラットフォームへのアクセスに対するセキュリティ管理および監査を可能にする 108
109. モニタリングの対象の例 データ・オブザーバビリティ（可観測性） • 容量の大きいテーブルはどれか？ • 書き込み頻度が最も高いテーブルはどれか？ • クラスタリングを適用すべき列はどれか？ パフォーマンス／リソース活用状況 • 利用率が最も低いクラスターはどれか • 利用率は時間・分単位でどのような傾向にあるか 109 コスト • 最もコストがかかっているクラスターはどれか？ • 最もコストがかかっているジョブはどれか？ • 最もコストがかかっているプロジェクトはどれか？ セキュリティと監査 • データの分類に応じたユーザーやユーザーグループの アクセス状況を監視・追跡する • アカウントのログインと変更履歴を追跡する プラットフォーム利用状況とパイプライン状態 • 現在、パイプラインはどのような状態か？ • 毎月いくつの新しいジョブが追加されているか？ • 実行時間の長いジョブやクエリはどれか？ • どのようなクラスターやジョブの設定が使用されている か？ • ワークスペースには何人のユーザーがいるか？
110. システムテーブル： Databricksのすべての運用データを格納す るDatabricksホスト型の分析ストア ウォームパスとして、以下を含むお客様の履 歴オブザーバビリティ（観測可能性）のために 使用される システムテーブル - レイクハウスの可観測性 110 このユーザーは過去 24時間で何にアクセスしたか？ SELECT request_params.table_full_name system.operational_data.audit_logs から取得 WHERE user_identity.email = "ifi.derekli@databricks.com" かつ service_name = "unityCatalog" AND action_name = "generateTemporaryTableCredential" AND datediff(now(), created_at) < 1; Cost/usage analytics Efficiency analytics Audit analytics Data Quality analytics システムテーブルはすぐに使用可能、データへの洞察力を高める
111. 111 • 誰がこのテーブルにアクセスしたのか？ • 直近1日以内にどのユーザーがテーブルにアクセスした か？ • ユーザーがどのテーブルにアクセスしたか？ • すべてのパーミッションの変更を表示 • 最近実行したノートブックコマンドを表示 Audit Log (監査ログ） アカウント使用に関する一般的な質問に答える
112. 112 • DBU消費量の日次推移は？ • 今月、各SKUは何DBU使用されたか？ • あるワークスペースが6月1日に使用した各SKUの量は？ • 最もDBUを消費したジョブは？ • 特定のタグを持つリソースにどれだけの使用量を帰属さ せることができるか？ • 利用が伸びているSKUを示す • All Purpose Compute (Photon)の使用傾向は？ Billing usage (請求) usageテーブルを活用したDBU消費の分析と最適化
113. 113 2種類のリネージテーブル • system.access.table_lineage • system.access.column_lineage Table and Column Lineage (リネージ） リネージュ機能を利用して、リネージュをプログラムで照会し、意思決定やレポートの 作成に役立てる
114. Compute (コンピュート ) • クラスターはどのくらい稼働していたのですか？ • どのようなVMタイプを使用したのですか？ • どのように規模を拡大／縮小したのか スキーマ • system.compute.clusters • system.compute.node_timeline • system.compute.node_types • system.compute.warehouse_events 114 インフラの使用状況とスケーリングイベントを理解する
115. Query 115 データが誰にどのように照会されているかを理解する • 最も使用頻度の高いテーブル/カラムは？ • テーブルはどのようにクエリされるのか？ • 誰がどのデータを見るのか？
116. 116 アクティビティ (2min) 1. システムテーブルのドキュメント（AWS / Azure / Google Cloud）を参照 し、どのようなテーブルがあるかを見てみましょう 2. ワークスペースの「カタログ」メニューを押下し、systemカタログ（システ ムテーブル格納先）を探しましょう。その後、配下のスキーマ、テーブルの 情報とサンプルデータを見てみましょう ※表示されない / データ閲覧出来ない場合は、本アクティビティをスキップしてください
117. まとめ Well Architected Lakehouse プラットフォームエンジニア　ワークショップ
118. 本ワークショップが扱う範囲 Databricksの管理者が主に担当する、7つのトピックを扱います。 カタログ管理 権限管理 その他 監査・モニタリング 計算資源管理 アカウント管理 アイデンティティ管理 予実管理 ◎ ◎ ◎ ◎ トピック アカウント管理者 Databricks全体の資産管理 基盤管理/中央Govチーム ◯ ワークスペース内アクションの監査 ◎ ◯ 作業環境への登録 ◯ 作業環境内の予実集計 ワークスペース管理者 特定の作業環境の管理 基盤管理/中央Govチーム /DevOpsチーム ◎ ◯ データセット全体の利用状況監視 メタストア管理者 データAI資産全体の管理 中央IT Gov/基盤管理チーム ◎ ◯ 特定データセットの品質監視 カタログ所有者 特定のデータ AI資産の管理 中央Govチーム/ 事業部Govチーム 責務 (黒: Databricks上の名称、緑: 想定される社内の職掌) 3 4 7 5 1 2 6
119. 119 オペレーショナルエ クセレンス セキュリティ プライバシー コンプライアンス 信頼性 パフォーマンス 効率 コスト最適化 データ & AI ガバナンス 柱 Well-Architected Lakehouseとは ス コ ｜ プ 相互運用性と 使いやすさ レイクハウス固有 システムが 障害から復旧し、 継続的に機能する 能力 レイクハウスの 本番環境での安定稼働 を支えるすべての運用プ ロセス Databricksのアプリケー ション、顧客のワークロー ドおよびデータを脅威か ら保護 システムが 負荷の変化に 柔軟に対応する 能力 投資対効果を 最大化するための コスト管理 レイクハウスが ユーザーや他のシステム と効果的に連携する能力 データとAIが価値を生み 出し、ビジネス戦略を支 えることを保証するため の監視 Databricks Platform BI & データ ウェアハウス データ エンジニアリング データ ストリーミング ML & データ サイエンス Unity Catalog Delta Lake
120. Well-Architected Lakehouse オペレーショナルエ クセレンス セキュリティ 信頼性 パフォーマンス 効率 コスト最適化 持続可能性 AWS Well-Architected Framework Microsoft Azure Well-Architected Framework Google Cloud Architecture Framework Databricksレイクハウス BI & データ ウェアハウス データ エンジニアリング データ ストリーミング ML & データ サイエンス Unity Catalog Delta Lake クラウドデータレイク 120 クラウドのWell-Architected Frameworkをレイクハウスに拡張
121. 体系化された基本原則とベストプラクティス 121 基本原則とベストプラクティス オペレーショナル エクセレンス セキュリティ プライバシー コンプライアンス 信頼性 パフォーマンス 効率 コスト 最適化 データ & AI ガバナンス 相互運用性と 使いやすさ https://docs.databricks.com/ja/lakehouse-architecture/index.html https://docs.gcp.databricks.com/ja/lakehouse-architecture/index.html https://learn.microsoft.com/ja-jp/azure/databricks/lakehouse-architec ture
122. 7つの柱とそれぞれの基本原則 122 データ & AI ガバナンス データ品質 基準の確立 データ & AI 管理の一元化 データ & AI セキュリティの一 元化 相互運用性と使いやすさ 新規ユースケース 実装のシンプル化 統合の標準を 定義 オープンなフォー マットとインターフェ イス 一貫性と 使いやすさ オペレーショナルエクセレンス プロセスの 最適化 自動化 キャパシティ管 理 セキュリティ・コンプライアンス・プライバシー IDと 特権管理 データ セキュリティ ネットワークセ キュリティ コンプライアンスと プライバシー セキュリティ監 視 信頼性 データ品質の 管理 スケーリング 復旧手順 自動化 監視 パフォーマンス効率 パフォーマンステ スト サーバーレス サービス パフォーマンス設 計 パフォーマンス監 視 コスト最適化 コスト監視 最適な リソースの選択 リソースの 動的な割り当て コスト効率の高い ワークロード設計 監視 失敗に備えた 設計