フェーズ3： Unity Catalogアーキテクチャの設計

このフェーズでは、データガバナンス、アクセス制御、レイクハウスのデータ編成をサポートするUnity Catalogストラクチャを設計します。

Unity Catalog 、2024 年 3 月 6 日以降に作成されたDatabricksアカウントのワークスペースで自動的に有効になります。これらのアカウントの場合、メタストアが自動的に作成され、ワークスペースに割り当てられます。

実装方法や高度な機能を含む包括的なUnity Catalogガイダンスについては、 Unity Catalogとは？を参照してください。

ガバナンス運用モデルを選択する

Unity Catalogアーキテクチャを設計する前に、組織構造とデータ文化に合ったガバナンス運用モデルを選択してください。ガバナンスモデルは、組織全体におけるデータ所有権、アクセス制御、およびポリシーの適用方法を決定するものです。

ガバナンスモデルの選択肢

中央集権型ガバナンス ：各事業部門またはドメインは異なる事業境界内で運営されますが、すべての部門は、すべてのデータおよびAI資産を管理する同一の運用境界の下にあります（マルチテナント）。単一のプラットフォームまたはデータガバナンスチームが、すべてのデータ資産、ポリシー、およびアクセスを管理します。
分散型ガバナンス ：各事業部門またはドメインは、独立した事業および運営上の境界を持つ（つまり、独自のテナントを持つ）。ガバナンスは各事業部門に委任され、各部門は中央からの監督を最小限に抑えつつ、独自にポリシーを策定・実施する。
連邦型ガバナンス ：各事業部門またはドメインは、独立した事業および運営上の境界を持つ。しかし、ガバナンスポリシーは中央のガバナンスオフィスによって策定され、各事業部門によって実施される。重要な資産は、ガバナンス部門によって管理されます（例えば、共有データ製品など）。
ハイブリッドガバナンス ：中央集権型と分散型の中間的なモデルで、各事業部門またはドメインが独自のデータを管理できるようにする（分散型）。しかし、重要なビジネスデータは、全員が利用できるよう一元的に収集・管理されます（集中管理）。

ガバナンスモデルに関するベストプラクティス

ほとんどの組織では、まず連邦型ガバナンスから始めるのが良いでしょう（統制と俊敏性のバランスが取れています）。
規制の厳しい業界（例えば、金融、医療、政府）には、中央集権的なガバナンスを採用する。
各ガバナンスモデルにおける役割と責任を明確に文書化する。
ガバナンスモデルを既存の組織構造に整合させる。
データプラットフォームの成熟度に応じて、ガバナンスモデルを見直し、調整してください。

	ガバナンスの一元化	分散型ガバナンス	連邦制ガバナンス	ハイブリッドガバナンス
定義	単一の中央機関が、組織全体のすべてのデータとAIを管理します。組織全体にわたって。	各事業部門は、それぞれ独立してデータおよびAIに関するポリシーを管理します。	中央チームがガイドラインと基準を設定し、各地域チームはそれらを実施する自主性を持つ。	コアデータとポリシーは一元的に管理され、各事業部門はそれぞれのドメイン固有のデータとポリシーを管理する。
意思決定	すべての意思決定は、トップダウン方式を採用した中央チームを通じて行われる。	各事業部門は、中央の調整なしに独自に意思決定を行う。	中央チームがガイドラインを策定し、現地チームがその枠組みの中で意思決定を行う。	中央チームがコアデータとインフラストラクチャに関する意思決定を行う。各事業部門は、それぞれの分野固有のニーズに基づいて独自の意思決定を行う。
データ所有権	中央チームがすべてのデータ資産を所有・管理する。	各チームまたは事業部門は、共有されたガバナンスなしに、それぞれ独自のデータを所有しています。	組織全体で複数のチームが所有権と責任を共有している。	中央チームがコアとなる共有データを管理しています。各事業部門は、それぞれのドメイン固有のデータを所有する。
スケーラビリティ	規模拡大は中央チームの能力に依存しており、組織の成長に伴ってボトルネックとなる可能性がある。	事業部門はそれぞれ独立して規模を拡大できるが、チーム間の連携は難しい場合がある。	組織は、確立されたガバナンス構造を通じて連携を維持しながら、規模を拡大することができる。	コアデータは中央リソースに応じて拡張されます。事業部門はそれぞれの領域において独立して規模を拡大する。
コンプライアンスとセキュリティ	組織全体で一貫して実施され、強力な中央監督下に置かれています。	実施方法はチームによって異なり、それがセキュリティ上の欠陥や一貫性のない運用につながる可能性がある。	中央チームがセキュリティ基準を設定し、各地域チームがそれぞれの管轄区域内でその基準を執行する。	コアデータは厳格なコンプライアンス規則に従います。各事業部門は、分野固有の要件に対応できる柔軟性を備えている。
運用効率の改善	業務自体は効率的だが、官僚的な手続きや承認プロセスによって遅延が生じる可能性がある。	チームは迅速に作業を進め、容易に適応できるが、作業が重複したり、部門間の壁ができたりする可能性がある。	組織は効率性と柔軟性のバランスを取ろうとするが、綿密な調整は意思決定を遅らせる可能性がある。	基幹業務にはボトルネックが存在する可能性がある。各事業部門は、それぞれの担当領域内で効率的に業務を遂行する。
ユースケースの適合性	金融や医療など、厳格な監督が求められる高度に規制された業界に最適です。	スピードを重視する、機敏なビジネス、スタートアップ企業、イノベーション主導型の組織に最適です。	中央集権的な基準と地域ごとの柔軟性の両方を必要とする大企業や多国籍企業に最適です。	コンプライアンス要件とイノベーションのバランスを取る必要があるフィンテック企業など、多様なニーズを持つ組織に最適です。

ガバナンス運用モデルの選択は、メタストアの設計に影響を与えます。集中管理モデルでは、単一のメタストア管理者を割り当てることができます。分散型モデルでは、権限管理を個々の事業部門や環境管理者に委任するのではなく、自動化されたデプロイメントパイプライン（TerraformなどのCI/CDツールを使用）を通じて管理します。

メタストアアーキテクチャの設計

Unity Catalogメタストアは、メタデータとガバナンスのための最上位のリージョンコンテナです。各メタストアには、セキュリティ保護可能なオブジェクト（テーブル、ビュー、ボリューム、外部ロケーション、共有など）のメタデータと、それらへのアクセスを制御する権限が格納されます。メタストアは、Databricksのコントロールプレーン上でマルチテナントサービスとしてホストされます。

Unity Catalogでは、リージョンごとに1つのメタストアしか許可されておらず、そのメタストアは割り当てられたリージョン内でのみ使用できます。各ワークスペースは、必ず1つのメタストアに割り当てられなければなりません。

メタストア管理者ロール

ガバナンスモデルによっては、メタストアにメタストア管理者を設定することも可能です。Unity Catalogの自動有効化を使用する場合、この役割は設定されません。メタストアレベルでUnity Catalogオブジェクトのストレージを管理するには、メタストア管理者ロールが必要です。また、複数のメタストア間でデータを一元管理したい場合にも便利です。リージョン内。

集中管理モデル では、単一のメタストア管理者または指定グループを割り当てます。
分散型モデル では、個々の管理者に権限を委譲するのではなく、自動化されたデプロイメントパイプラインを通じて権限を管理します。

メタストア管理者を使用する場合は、単一のユーザーではなく、指定されたグループに役割を割り当てることを強くお勧めします。

隔離メカニズム

セキュリティや組織上の理由からエンタープライズグレードの分離をサポートするために、Unity Catalogは複数のレベルでの分離をサポートしています。

管理者の分離（管理の委任） ：データは、そのデータの目的または所有権に基づいて、指定された個人またはチームによって管理されるべきです。
ワークスペースバインディング ：データは、そのデータの目的に基づいて、指定された環境でのみアクセスされるべきです。
- 1 つのカタログ (または他のUnity Catalogオブジェクト) を複数のワークスペースにバインドできます。
- 1つのワークスペースは、同じメタストア内の複数のカタログ、認証情報、および外部ロケーションに紐付けることができます。
ストレージの分離 ：データはストレージ内で物理的に分離されるべきである。
Unity Catalogアクセス制御 ：ユーザーは、合意されたアクセスルールに基づいてのみ、データまたはメタデータにアクセスできる必要があります。

これらの分離メカニズムを使用して、ワークロード、チーム、またはビジネスユニットをリージョンごとに単一のメタストアに分離します。

メタストアの設計パターン

シングルクラウド、シングルリージョン展開

単一のクラウドリージョンで運用している組織の場合は、そのリージョンにメタストアを1つデプロイしてください。当該リージョン内のすべてのワークスペースは、このメタストアに割り当てられます。

単一クラウド、単一リージョンでのメタストア展開。

単一クラウド、複数リージョン展開

同一クラウドの複数のリージョンで運用している組織の場合は、リージョンごとに1つのメタストアをデプロイしてください。各ワークスペースは、そのリージョン内のメタストアに割り当てられます。Databricks管理の（D2D） Delta Sharing使用して、リージョンをまたがるメタストア間でデータを共有します。

単一クラウド、複数リージョン対応のメタストア展開。

マルチクラウド、マルチリージョン展開

複数のクラウドプロバイダーとリージョンにまたがって事業を展開する組織の場合は、各クラウドのリージョンごとに1つのメタストアをデプロイしてください。Databricksで管理される (D2D) Delta Sharingを使用して、クラウドとリージョン全体のメタストア間でデータを共有します。

マルチクラウド、マルチリージョン対応のメタストア展開。

代替パターン

事業部門ごとに1つのメタストア ：事業部門がデータ共有を一切行わず、完全な分離を必要とする場合に適しています。
環境ごとに 1 つのメタストア : 開発、ステージング、および本番運用で厳密な環境分離のために別々のメタストアを使用する、あまり一般的ではないパターン。

複数地域における設計上の考慮事項

複数のリージョンでDatabricksを使用する場合、各リージョンに単一のUnity Catalogメタストアをデプロイする必要があります。ユーザーは、ログインしているワークスペースと同じリージョンにあるメタストアを操作できます。別のリージョンのメタストアで定義されたデータにアクセスするには、 Databricksが管理する（D2D） Delta Sharingお勧めします。

警告

共有テーブルを外部テーブルとして複数のメタストアに登録しないでください。リスクとしては、メタストアAへの書き込みによって発生したスキーマ、テーブルプロパティ、コメントへの変更が、メタストアBに全く反映されないことです。メタストアBのテーブルは、正しいスキーマを持つように再作成する必要があり、テーブルプロパティとコメントは完全に切り離された状態になります。これにより、 Deltaコミットサービスとの一貫性の問題が発生する可能性もあります。メタストア間でデータを共有するには、D2D Delta Sharing使用します。

複数地域設計におけるベストプラクティス

デフォルトのパターンとして、リージョンごとに1つのメタストアをデプロイします。
Databricksが管理するDelta Sharingを使用して、リージョン間でテーブルを共有します。
クラウドリージョン全体におけるデータアクセスの頻度と量を評価します。コストが高くなりすぎる場合は、リージョン間でテーブルを同期するためのパイプラインを構築することを検討してください。
リージョンをまたぐ構成の場合、パフォーマンス向上のため、メタストアのルートストレージはメタストアと同じリージョンに保存してください。

メタストア設計のベストプラクティス

運用上の簡便性を考慮し、デフォルトのパターンとして、リージョンごとに1つのメタストアを使用することをお勧めします。
同じリージョン内のワークスペースを同じメタストアに割り当てます。
メタストア内のカタログを使用して、環境またはドメインごとにデータを分離します。
Unity Catalogリソースを管理するための管理ワークスペースをリージョンごとに作成します。
メタストアの割り当てとリージョン境界をランブックに記録してください。

2024年3月6日以降に作成された新規アカウントについては、メタストアが自動的に作成され、割り当てられます。

管理対象オブジェクト、外部オブジェクト、外部オブジェクトを含むUnity Catalogストレージアーキテクチャの詳細については、「フェーズ 4: ストレージアーキテクチャの設計」を参照してください。

デザインカタログの構成

カタログは、メタストアにおける最初の組織化レイヤーです。それらにはスキーマが含まれており、スキーマにはテーブル、ビュー、ボリューム、関数が含まれています。カタログのデザインによって、データ資産の整理方法とアクセス方法が決まります。

カタログデザインパターン

環境ベースのカタログ

開発、ステージング、本番運用などのソフトウェア開発ライフサイクル (SDLC) 環境用の個別のカタログ (例: dev 、 staging 、 prod )。このパターンは、環境推進ワークフローをサポートし、本番運用の偶発的な変更を防ぎます。

Unity Catalogが提供する3階層の名前空間のカタログレベルで環境を分離します。

dev カタログには開発データの保存場所が記載されています。
prod カタログには本番運用データの場所が含まれています。
カタログは、SDLC とビジネスまたは組織単位名の組み合わせにすることができます。たとえば、 sales_dev 、 sales_prod 、 engineering_dev

ドメインベースのカタログ

ビジネス領域または組織単位ごとに個別のカタログを作成します（例： sales 、 marketing 、 finance 、 engineering ）。このパターンは、データメッシュアーキテクチャとドメイン所有権に合致する。

ハイブリッドカタログ

環境パターンとドメインパターンを組み合わせます（例： sales_prod 、 sales_dev 、 finance_prod 、 finance_dev ）。これにより、隔離と明確な所有権の両方が確保される。

データライフサイクルカタログ

異なるデータ成熟段階（例： raw 、 curated 、 analytics ）ごとに個別のカタログを作成します。このパターンは、カタログレベルでのメダリオンアーキテクチャの原則に従っています。

サンドボックスと開発エリア

多くのチームは、内部利用のための一時的なデータセットを作成するために、サンドボックス領域を必要としています。個人またはチームに、テーブルを追加できる専用のサンドボックス化されたスキーマを提供します。ただし、スキーマとカタログの所有権は持っていないため、チーム外の誰とも共有することはできません。

カタログ命名規則

カタログの命名規則は、ソフトウェア開発ライフサイクル環境（開発、テスト、本番）、メダリオンレベル（ブロンズ、シルバー、ゴールド）、またはビジネスユニット（請求、顧客、販売）など、特定の構成に合わせて選択してください。具体的な命名規則は、アーキテクチャチームが定めるべきです。

カタログデザインのベストプラクティス

ほとんどの組織では、環境ベースのカタログをデフォルトとして使用します。
データメッシュや連合型ガバナンスモデルには、ドメインベースのカタログを使用してください。
管理上の負担を軽減するため、カタログの数を制限してください（通常、メタストアごとに3～10個）。
すべてのカタログで一貫した命名規則を使用してください。
カタログの目的とデータの所有権については、カタログのコメント欄に記載してください。
カタログ権限を使用して、各カタログ内でスキーマとテーブルを作成できるユーザーを制御します。
個々のチームやプロジェクトごとに別々のカタログを作成することは避けてください（代わりにスキーマを使用してください）。

ストレージ認証情報戦略の設計

ストレージ認証情報は、Unity Catalogがユーザーに代わってクラウドストレージにアクセスできるようにする認証オブジェクトです。これらは、エンドユーザーと長期的な認証情報を共有することなく、Databricksに顧客管理のクラウドストレージへのアクセス権を安全に付与する方法を提供する。

ストレージ認証情報が必要な場合

クラウドストレージ（S3、ADLS Gen2、GCSなど）を指す外部ロケーションを作成します。
外部テーブルおよびボリューム用の顧客管理ストレージへのアクセス。
Unity Catalogによって管理されていないクラウドストレージからデータを読み取る。

ストレージ認証情報が不要な場合

Unity Catalogマネージドテーブルとボリューム ( Databricksによって管理されるストレージ) へのアクセス。
サーバレスワークスペースの安心ストレージを利用中。

GCPストレージ認証情報アーキテクチャ

GCPストレージの認証情報にはサービスアカウントを使用します。Unity Catalogでストレージ認証情報を作成すると、 DatabricksコントロールプレーンにGCPサービスアカウントを生成します。このサービスアカウントには、GCSバケットに対する適切なIAMロール（例：ストレージオブジェクトビューアー、ストレージオブジェクトクリエーター）を付与する必要があります。

認証フロー：

Unity Catalog は生成されたサービスアカウントを使用します
GCPはサービスアカウントとIAM権限を検証します
Unity Catalogはユーザーに代わってストレージにアクセスします
アクセスはIAMロールに基づいて許可または拒否されます。

ストレージ認証情報の設計パターン

異なるGCSバケットまたはデータドメインには、それぞれ別のサービスアカウントを使用してください。
IAM条件を使用して、最小権限のアクセス許可を適用します。
環境ごとに 1 つのストレージ資格情報を作成します (例: dev、staging、本番運用)。
データ分離が必要な場合は、事業部門ごとに1つのストレージ認証情報を作成してください。

GCPストレージ認証情報のベストプラクティス

異なるGCSバケットまたはデータドメインには、それぞれ別のサービスアカウントを使用してください。
IAM条件を使用して、最小権限のアクセス許可を適用します。
Google Cloud Logging を有効にして、 GCSバケットへのアクセスを監査します。
IAMポリシーを使用してサービスアカウントへのアクセスを制限します。

外部ロケーション戦略の設計

外部ロケーションは、ストレージ認証情報を特定のクラウドストレージパスにマッピングすることで、Unity CatalogがUnity Catalog管理ストレージ外に保存されているデータへのアクセスを制御できるようにします。各外部ロケーションは、ストレージ認証情報とクラウドストレージURLプレフィックスを組み合わせたものです。

外部ロケーションの使用例

Unity Catalog導入以前にクラウドストレージに保存されていた既存データにアクセスする。
他のシステムで管理されているデータファイルを参照する外部テーブルを作成します。
ファイルへの直接アクセスを必要とする外部システムとデータを共有する。
Unity Catalogボリュームに、大規模な非構造化データ（例えば、動画、画像、PDFなど）を保存します。

外部ロケーションデザインパターン

外部ロケーションは、ロケーション数を最小限に抑えるため、最も高い共通パスプレフィックスで作成してください。
カタログまたはスキーマの境界に一致する外部ロケーションを使用します (たとえば、カタログごとに 1 つの外部ロケーション)。
環境ごとに外部ロケーションを分離します (例: 開発、ステージング、本番運用)。
必要に応じて、ビジネスユニットまたはデータドメインごとに外部ロケーションを分離します。

外部ロケーションのベストプラクティス

特定のクラウドストレージパスに残しておく必要があるデータには、外部ロケーションを使用します。
可能な場合は、外部ロケーションの代わりにUnity Catalogマネージドテーブルを使用します (よりシンプルなガバナンスと最適化)。
保存パスと目的を示す分かりやすい名前を使用してください（例： s3-sales-data-prod 、 adls-finance-reports-dev ）。
外部テーブルを作成する必要のあるユーザーのみに、外部ロケーションへのアクセス権を付与してください。
外部ロケーションの目的とデータ所有権を文書化する。

設計許可モデル

組織ごとに、データアクセス制御に関する要件は異なります。一般的な権限モデルでは、明確な役割と特定の権限を定義する。

権限モデルの例

データキュレーター ：すべてのデータ資産を管理します（例：所有権、作成、変更、削除権限）。
データ利用者 ：ほとんどのデータ資産への読み取り専用アクセス（権限を選択可能）。
データエンジニア ：開発環境およびステージング環境への読み書きアクセス権限。
アナリスト : 本番運用アナリティクスデータへの読み取り専用アクセス。

権限委譲

メタストア管理者は、ユーザーまたはグループの責任に基づいてアクセス権限を割り当てたり委任したりすることにより、権限ポリシーを確立し、適用します。例えば：

データキュレーターには、データセットを管理するための所有権または書き込み権限が付与される場合があります。
消費者はグループメンバーシップを通じて読み取りレベルの権限を取得します。
この構造により、一貫したガバナンスが確保され、メンテナンスが簡素化され、組織データのポリシーによるコンプライアンスがサポートされます。

権限モデルのベストプラクティス

管理を容易にするため、個々のユーザーではなくグループに権限を付与してください。
最小権限アクセス（必要最小限の権限のみを付与する）を使用してください。
アクセス制御ポリシーを文書化し、セキュリティチームと定期的に見直しを行う。
カタログおよびスキーマの権限付与を使用して、粗粒度のアクセス制御を行います。
きめ細かなアクセス制御には、テーブル権限とビュー権限を使用してください。
機密データには、動的ビューと行/列フィルターを使用してください。
システムテーブル（ system.access.audit ）を使用した監査アクセス。

ハブアンドスポーク設計パターン

ハブアンドスポーク設計パターンは、エンタープライズ向けUnity Catalog導入において一般的なアーキテクチャです。このパターンでは、共有データ資産をハブカタログに一元化しつつ、ドメイン固有のデータをスポークカタログに格納できるようにします。

ハブアンドスポーク特性

ハブカタログ ：組織全体で共有されるデータ資産（顧客マスターデータ、参照データ、中央で管理されるデータセットなど）が含まれています。
スポークカタログ : ビジネスユニットが所有および管理するドメイン固有のデータが含まれます (販売アナリティクス、マーケティングキャンペーンなど)。
ストレージの分離 ：ハブカタログとドメインカタログは、それぞれ専用のストレージと個別のストレージ認証情報を使用します。
マネージドテーブルの設定 : レイクハウス内の構造化データにはマネージドテーブルを使用します。
生データ用ボリューム ：ボリュームを使用して、着陸データ、生データ、または非構造化データにアクセスします（これらのデータは、通常、第三者がこれらのストレージ場所に直接アクセスする必要があるため、レイクハウスの外に保管できます）。
共有用の外部テーブル : 外部テーブルを使用して、レイクハウスの外部でデータを共有します ( Delta Sharing使用できない他のシステム、または保管場所に直接アクセスする必要がある他のシステムと)。

ハブアンドスポーク設計の例

Metastore (region: us-east-1)
├── Hub Catalog (prod_hub)
│   ├── Storage credential: hub-prod-credential
│   ├── External location: s3://company-hub-prod/
│   └── Schemas: customers, products, reference_data
│
├── Sales Domain Catalog (sales_prod)
│   ├── Storage credential: sales-prod-credential
│   ├── External location: s3://company-sales-prod/
│   └── Schemas: transactions, forecasts, reports
│
└── Engineering Domain Catalog (engineering_prod)
    ├── Storage credential: engineering-prod-credential
    ├── External location: s3://company-engineering-prod/
    └── Schemas: telemetry, monitoring, logs

ハブアンドスポーク設計のベストプラクティス

複数のドメインが利用する組織全体の共有データには、ハブカタログを使用してください。
事業部門が所有するドメイン固有のデータには、スポークカタログを使用してください。
ハブと各スポークのストレージ資格情報と外部ロケーションを分離します。
Databricksが管理するDelta Sharingを使用して、ハブからスポークへデータを共有します。
ハブアンドスポークカタログのデータ所有権とリネージを文書化します。
注：メタストアストレージは現在オプションであり、使用しないことを推奨します。

Unity Catalogのアーキテクチャに関する推奨事項

推奨

Unity Catalogメタストアにおいて、3階層ネームスペースのカタログレベルでSDLC環境を分離します。
Unity Catalogの分離レベルを使用して、ワークロード、チーム、およびビジネスユニットを分離します。
Databricksが管理するDelta Sharingを使用して、クラウド間およびリージョン間でテーブルを共有します。
リージョンをまたぐ構成の場合は、クラウドリージョン間でのデータアクセス頻度と量を評価してください。コストが高くなりすぎる場合は、リージョン間でテーブルを同期するためのパイプラインを構築することを検討してください。
Unity Catalogマネージドテーブルを使用し、バケットへのストレージレベルのアクセスを提供しません。
Unityカタログで保護されたPOSIX（Portable Operating System Interface）形式のファイルパスにはボリュームを使用してください。
クラウドストレージやインスタンスプロファイルのマウントなど、従来のデータアクセスパターンは可能な限り避けてください。
保存データの制御を強化するために、顧客が管理する暗号化キー（マネージドサービスとストレージの両方）が必要かどうかを評価します。

避ける

Unityカタログ対応ワークスペースでは、標準または専用以外のアクセスモードを使用しないでください。
本番運用データをDBFS ( Databricks File System) に保存しないでください。
リージョン（メタストア）をまたいで外部テーブルを登録しないでください。
ルートバケット（DBFS）を顧客データの保存に使用しないでください。ルートバケットに関するリスクと回避策を必ず理解しておいてください。

第3相試験の結果

フェーズ3を完了すると、以下のものが得られます。

ガバナンスモデルは、組織構造（中央集権型、分散型、連邦型、またはハイブリッド型）に基づいて選択されます。
メタストアのアーキテクチャが設計されています（通常はリージョンごとに1つ）。
Unity Catalogストレージアーキテクチャを設計しました（管理対象オブジェクト、外部オブジェクト、外部オブジェクト）。
カタログ構造は、環境ベース、ドメインベース、またはハイブリッドパターンを使用して定義されます。
ストレージ認証情報戦略は、異なる環境またはドメインごとに個別の認証情報を使用するように設計されています。
Unity Catalogによるガバナンスを必要とする既存のクラウドストレージ向けに設計された外部ロケーション戦略。
明確な役割（例えば、キュレーター、消費者、エンジニア、アナリストなど）に基づいて設計された権限モデル。
共有データとドメイン固有データを扱うエンタープライズ環境への導入を想定し、ハブアンドスポーク設計を評価した。

次のフェーズ ：フェーズ4：ネットワークアーキテクチャの設計

実装ガイド ： Unity Catalogデザインを実装するための手順については、 Unity Catalogとは？」を参照してください。

ガバナンス運用モデルを選択する​

メタストアアーキテクチャの設計​

メタストア管理者ロール​

隔離メカニズム​

メタストアの設計パターン​

複数地域における設計上の考慮事項​

デザインカタログの構成​

カタログデザインパターン​

サンドボックスと開発エリア​

カタログ命名規則​

ストレージ認証情報戦略の設計​

外部ロケーション戦略の設計​

設計許可モデル​

ハブアンドスポーク設計パターン​

Unity Catalogのアーキテクチャに関する推奨事項​

第3相試験の結果​