LoginSignup
6
5

More than 1 year has passed since last update.

@manabian

Azrure Databricks Unity Catalog による全社的データガバナンス実践ガイドライン

Last updated at Posted at 2023-08-25

概要

Azure Databricks における Unity Catalog に関する情報を Azure 固有の状況を踏まえて整理します。

注意事項

本記事は2023年8月22日時点での情報に基づいたものであり、Unity Catalog の新機能が頻繁にリリースされるため、最新情報についてはドキュメントを確認してください。本資料内で「現時点」と記載した場合、2023年8月22日時点を指します。

Unity Catalog について

Unity Catalog とは

Unity Catalog とは、Databricks 上のオブジェクト（テーブルなど）のメタデータ管理機能であり、従来の Spark における Hive Metastore の代替となる機能です。Databricks のサイトでは、次のように説明されています。Unity Catalog と従来の Hive Metastore を併用して Databricks を利用することも可能です。

Unity Catalog は、主要なクラウド上のレイクハウスのファイル、テーブル、ML モデルなど、あらゆるデータと AI のための統合ガバナンスソリューションです。

引用元：Unity Catalog | Databricks

Unity Catalog には、以下のような特徴があります。

  • 1 回だけ定義し、すべての場所をセキュリティで保護: Unity Catalog は、すべてのワークスペースとペルソナに適用されるデータ アクセス ポリシーを管理するための単一の場所となります。
  • 標準に準拠しているセキュリティモデル: Unity Catalog のセキュリティ モデルは、標準の ANSI SQL に基づいています。管理者は、使い慣れた構文を使用して、既存のデータ レイク内で、カタログ、データベース (スキーマとも呼ばれます)、テーブル、ビューのレベルでアクセス許可を与えることができます。
    組み込みの監査と系列: Unity Catalog では、データへのアクセスを記録するユーザーレベルの監査ログが自動的にキャプチャされます。 さらに Unity Catalog では、すべての言語とペルソナでデータ資産がどのように作成され、どのように使用されているかを追跡する系列データもキャプチャされます。
  • データ検出: Unity Catalog を使用すると、データ資産にタグを付けてドキュメント化し、データ コンシューマーがデータを見つけるのに役立つ検索インターフェイスを提供できます。
  • システム テーブル (パブリック プレビュー): Unity Catalog を使用すると、監査ログ、課金対象の使用状況、系列など、アカウントのオペレーショナル データに簡単にアクセスしてクエリを実行できます。

引用元：Unity Catalog の概要 - Azure Databricks | Microsoft Learn

Unity Catalog 導入のメリット

Unity Catalog 導入のメリットとしては、次の点が挙げられます。データレイクを管理できる機能は他のサービスでもありますが、複数のクラウドベンダー（AWS や Azure など）上のストレージのデータをセキュア、かつ、高度に管理できる特徴があります。従来のデータベースのように管理ができるため、Unity Catalog の利用により運用コストの削減や容易な展開が可能になります。

  1. データレイク上のデータに対する権限管理だけでなく、データ処理内容に関するデータリネージの取得によりデータガバナンスの実施が可能
  2. データレイクのデータだけでなく、他データベースからのクエリフェデレーション（データ仮想化）が可能であり、SSOT（信頼できる唯一の情報源）の実現に近づくことが可能。
  3. Delta Sharing によるデータ共有や Lakehouse Monitoring などによるデータサイエンス実施の支援により、データの利活用の推進が可能。

Databricks Assistant に質問したところ、次のような回答でした。

Unity Catalogのメリットは、以下の通りです。

  1. セキュアなデータアクセス Unity Catalogでは、セキュリティ管理が簡単かつ効率的です。１つの場所でアクセスポリシーを定義でき、必要なときに編集できます。管理者は、既存のデータレイクで権限を付与できるため、操作性が高く、簡単に実装できます。
  2. データ監査とライングの確保 Unity Catalogには、ビューの作成と管理を追跡し、Apache SparkのUDFも管理できる機能があります。そのため、精度に欠陥のあるデータを特定できます。また、Apache Sparkのワークフロー検索機能により、データのライングを容易に確認できます。
  3. カタログの作成とテーブルの管理 Unity Catalogでは、データベース、テーブル、およびビューの作成と管理が簡単にできます。これにより、Redshift、S3、Databricksなど、複数のデータストアを管理する必要がある場合でも、1つのカタログで管理できます。
  4. 業界標準に適合 Unity Catalogのセキュリティモデルは、業界標準のANSI SQLに基づいています。したがって、データアクセスに必要な権限を、カタログ、データベース（スキーマ）、テーブル、およびビューのレベルで付与できます。
  5. 優れたデータ探索機能 Unity Catalogには、強力なデータ探索機能が搭載されています。たとえば、ビューを作成して異なるカタログのテーブルを結合することもできます。このため、多くのデータストアを持つ場合でも、1つの場所で容易にデータ分析ができます。

以上がUnity Catalogの主なメリットです。

Unity Catalog の構成要素

Unity Catalog の構成要素については、次の図が参考になります。

image.png

引用元：Unity Catalog の権限とセキュリティ保護可能なオブジェクト - Azure Databricks | Microsoft Learn

各オブジェクトの定義については、次のようにドキュメントに記載されています。

  • METASTORE: The top-level container for metadata. Each Unity Catalog metastore exposes a three-level namespace (catalog.schema.table) that organizes your data.
  • CATALOG: The first layer of the object hierarchy, used to organize your data assets. A foreign catalog is a special catalog type that mirrors a database in an external data system in a Lakehouse Federation scenario.
  • SCHEMA: Also known as databases, schemas are the second layer of the object hierarchy and contain tables and views.
  • TABLE: The lowest level in the object hierarchy, tables can be external (stored in external locations in your cloud storage of choice) or managed tables (stored in a storage container in your cloud storage that you create expressly for Azure Databricks).
  • VIEW: A read-only object created from one or more tables that is contained within a schema.
  • VOLUME: The lowest level in the object hierarchy, volumes can be external (stored in external locations in your cloud storage of choice) or managed (stored in a storage container in your cloud storage that you create expressly for Azure Databricks).
  • REGISTERED MODEL: An MLflow registered model that is contained within a schema.
  • FUNCTION: A user-defined function that is contained within a schema. See User-defined functions (UDFs) in Unity Catalog.
  • EXTERNAL LOCATION: An object that contains a reference to a storage credential and a cloud storage path that is contained within a Unity Catalog metastore.
  • STORAGE CREDENTIAL: An object that encapsulates a long-term cloud credential that provides access to cloud storage that is contained within a Unity Catalog metastore.
  • CONNECTION: An object that specifies a path and credentials for accessing an external database system in a Lakehouse Federation scenario.
  • SHARE: A logical grouping for the tables you intend to share using Delta Sharing. A share is contained within a Unity Catalog metastore.
  • RECIPIENT: An object that identifies an organization or group of users that can have data shared with them using Delta Sharing. These objects are contained within a Unity Catalog metastore.
  • PROVIDER: An object that represents an organization that has made data available for sharing using Delta Sharing. These objects are contained within a Unity Catalog metastore.

引用元：Unity Catalog privileges and securable objects - Azure Databricks | Microsoft Learn

  • METASTORE: メタデータのトップレベルコンテナです。Unity Catalogメタストアは、データを整理するために(catalog.schema.table)の3レベルの名前空間を公開します。
  • CATALOG: オブジェクト階層の最初のレイヤーで、データアセットを整理するために使用されます。外部カタログは、Lakehouse Federationシナリオで外部データシステムのデータベースをミラーリングする特別なカタログタイプです。
  • SCHEMA: データベースとしても知られるスキーマは、オブジェクト階層の2番目のレイヤーで、テーブルとビューを含みます。
  • TABLE: オブジェクト階層の最下層で、テーブルは外部(選択したクラウドストレージに外部の場所に保存される)または管理されたテーブル(明示的にAzure Databricksのために作成したクラウドストレージ内のストレージコンテナに保存される)になります。
  • VIEW: 1つ以上のテーブルから作成された読み取り専用オブジェクトで、スキーマ内に含まれます。
  • VOLUME: オブジェクト階層の最下層で、ボリュームは外部(選択したクラウドストレージに外部の場所に保存される)または管理された(明示的にAzure Databricksのために作成したクラウドストレージ内のストレージコンテナに保存される)になります。
  • REGISTERED MODEL: スキーマ内に含まれるMLflow registered model です。
  • FUNCTION: スキーマ内に含まれるユーザー定義関数です。Unity Catalogのユーザー定義関数(UDF)を参照してください。
  • EXTERNAL LOCATION: ストレージ資格情報とUnity Catalogメタストア内に含まれるクラウドストレージパスへの参照を含むオブジェクトです。
  • STORAGE CREDENTIAL: Unity Catalogメタストア内に含まれるクラウドストレージへのアクセスを提供する長期的なクラウド資格情報をカプセル化するオブジェクトです。
  • CONNECTION: Lakehouse Federationシナリオで外部データベースシステムにアクセスするためのパスと資格情報を指定するオブジェクトです。
  • SHARE: Delta Sharingを使用して共有するテーブルの論理グループ化です。共有はUnity Catalogメタストア内に含まれます。
  • RECIPIENT: Delta Sharingを使用してデータを共有できる組織またはユーザーグループを識別するオブジェクトです。これらのオブジェクトはUnity Catalogメタストア内に含まれます。
  • PROVIDER: Delta Sharingを使用してデータを共有できるようにした組織を表すオブジェクトです。これらのオブジェクトはUnity Catalogメタストア内に含まれます。

上記の翻訳

Azure Databricks における Unity Catalog の制限

Azure では、次のようにドキュメントに記載されている通り、テナントごとリージョンごとに１つのメタストアが作成できます。社内で複数のクラウドベンダー、複数のテナントや複数のリージョンにて Unity Catalog を利用する場合には適切な運用設計が必要となります。私の経験では４極（*1）でシステムを運用していることがあり、それぞれの拠点との調整も行うことも検討する必要となりそうです。

Azure Databricks アカウント管理者は、運用するリージョンごとにメタストアを 1 つ作成し、同じリージョン内の Databricks ワークスペースにそれらを割り当てなければいけません。

引用元：Unity Catalog とは - Azure Databricks | Microsoft Learn

Azure Databricks アカウントには、リージョンごとに 1 つのメタストアのみを含めることができます

引用元：Unity Catalog GA リリース ノート - Azure Databricks | Microsoft Learn

異なるメタストアのデータを共有する方法として、現時点では次のような方法があります。複数のメタストアを利用する場合には、データの共有方法を検討したほうがようそうです。

  1. Databricks 間プロトコル Delta Sharing による共有 *2
  2. Databricks コネクターによるテーブルへの書き込み *3

次の方法では異なるメタストア間でのデータを共有することが難しいようです。

# 方法 却下理由
1 テーブルごとに Deep Clone によるテーブル同期 異なるメタストア上のテーブル間で DEEP CLONE を実施する方法を確認できなかったため。
2 メタストアに他のメタストアのテーブルを登録 ドキュメントにて非推奨である旨の記載があるため。*4

*1 次のような４つの拠点で、それぞれ拠点ごとにシステムが管理されていることがあります。

  1. APAC(Asia Pacific)
  2. AMER(Americas)
  3. EMEA(Europe,Middle-East,Africa)
  4. China

*2 ドキュメントにて次のように記載されいます。

Databricks 間共有を使用すると、AWS、Azure、GCP のいずれにあるかにかかわらず、他の Databricks アカウントのユーザーとデータを共有できます。 また、独自の Databricks アカウント内のさまざまな Unity Catalog メタストア間でデータを安全に共有する優れた方法でもあります。

引用元：Databricks 間 Delta Sharing とは - Azure Databricks | Microsoft Learn

*3 Databricks コネクタについては、次のドキュメントに記載されています。

*4 次のようにドキュメントに記載されています。

Databricks では、整合性の問題のリスクがあるため、テーブルを複数のメタストアの外部テーブルとして登録しないことを強くお勧めします。 たとえば、1 つのメタストアでスキーマを変更しても、2 番目のメタストアでは登録されません。 メタストア間でデータを共有するには、 Delta Sharing を使用します。 Share data securely using Delta Sharingを参照してください。

引用元：外部テーブルを使用するための推奨事項 - Azure Databricks | Microsoft Learn

Azure Databricks 固有の導入障壁

Azure Databricks に Unity Catalog を導入する際に、AWS の Databricks と比較すると、Azure 固有の導入障壁があります。Azure を社内利用する際には１つの会社（すべてのグループ会社を含む）に対して１つの Azure テナントで運用することが多く、Azure テナント内で１つしか Databricks アカウントを作成できない仕様が導入障壁の１つとなることがあります。 Databricks アカウント管理者が全社の中でどの部門が担うか、Unity Catalog へのオブジェクトの作成と権限付与を行うなどの運用指針を実施することが必要となります。特に全社での Databricks 導入を検討している場合には社内での調整が必要となり、導入までに時間がかかる場合がありそうです。

データカタログ（Microsoft Purviewデータガバナンス）の要否

Unity Catalog 導入後にデータカタログサービス（主に Microsoft Purviewデータガバナンス）を別途導入すべきであるかの相談がありますが、次の観点での検討に基づき判断することをおすすめします。Databricks だけでは要件を満たせない場合には、Microsoft Purviewデータガバナンスの導入も検討する必要があります。

  1. Databricks 外にあるメタデータの提供が必要であるか
  2. データの参照権限（SELECT権限）を付与していないユーザーがデータ所在の特定（データディスカバリー）を実施できる必要があるか

Databricks 外にあるメタデータには次のような項目があります。Microsoft Purview データガバナンスでは、エージェント（セルフ統合ランタイム）により異なるネットワーク上にあるメタデータの取得を容易に実施できます。

  1. データベースのメタデータ
  2. Azure Data Factory のコピーアクティビティとデータフローによるデータリネージ
  3. Power BI Services におけるデータリネージ

Unity Catalog の活用

Unity Catalog にて利用できる主な機能

Unity Catalog を有効化することで、次のような機能を利用できるようになります。

  1. アカウントレベルにおけるオブジェクトへの権限付与 *1
  2. テーブルに対する行単位と列単位でのデータの権限付与 *2
  3. 主キー情報や外部キー情報の設定 *3
  4. インフォメーションスキーマの利用 *4
  5. データリネージの取得 *5
  6. Volumes 、あるいは、外部ロケーションによるデータストレージへの権限付与 *6
  7. Lakehouse Federation によるデータハブ（データ仮想化）機能 *7
  8. Delta Sharing によるデータ共有 *8
  9. Databricks Lakehouse Monitoring による 監視 *9
  10. REGISTERED MODEL によるモデル管理 *10
  11. Databricks Assistant による開発支援 *11
  12. Databricks Marketplace から取得したデータの管理 *12

*1 詳細については、次のドキュメントに記載されています。

オブジェクトの削除を行うにはOWNER権限が必要であるため、上記リンク先に記載されている特権にOWNER権限も含めて権限付与の方針を検討する必要があります。

オブジェクトの所有者は、オブジェクトを削除することができます。

引用元：Unity Catalog オブジェクトの所有権を管理する - Azure Databricks | Microsoft Learn

現時点では、DENY権限を付与できません。

この関数は Unity Catalog ではサポートされていません。

引用元：DENY - Azure Databricks - Databricks SQL | Microsoft Learn

*2 動的ビューにより、行単位と列単位で参照できるデータに制限を実施することができます。詳細については、次のドキュメントに記載されています。単一ユーザー アクセス モードでは利用できないことに注意が必要です。

*3 情報提供を目的として、主キー、及び、、外部キーを設定できます。NOT NULL 制約や CHECK 制約とは異なり、制約として動作しません。

主キーと外部キーは情報提供のみを目的としており、適用されません。 外部キーは、別のテーブルの主キーを参照する必要があります。

引用元：主キーと外部キーのリレーションシップを宣言する | Microsoft Learn

*4 メタストア内のすべてのカタログのオブジェクトに関する次のようなデータを、インフォメーションスキーマから取得できます。取得できます。以前までは、Spark API、あるいは、Hive Metastore のデータベースを参照しないとテーブル定義を確認できませんでした。

image.png

引用元：情報スキーマ - Azure Databricks - Databricks SQL | Microsoft Learn

*5 Databricks 上での Python や SQL での処理結果から、テーブル間の依存関係をデータリネージ（系列）として可視化できます。データリネージを取得するためにプログラムを修正する必要はなく、通常の Spark のプログラムを実行するだけでデータリネージを取得できます。現時点では、30 日より前のデータが消えてしまうため、蓄積したい場合には別途データカタログやプログラムが必要となります。

image.png

引用元：Unity Catalog を使用したデータ系列のキャプチャと表示 - Azure Databricks | Microsoft Learn

系列は 30 日間のローリング ウィンドウで計算されるため、30 日よりも前に収集された系列は表示されません。 たとえば、ジョブまたはクエリがテーブル A からデータを読み取り、テーブル B に書き込んだ場合、テーブル A とテーブル B 間のリンクは 30 日間だけ表示されます。

引用元：Unity Catalog を使用したデータ系列のキャプチャと表示 - Azure Databricks | Microsoft Learn

*6 詳細については、次のドキュメントに記載されています。

外部ロケーションがメタストアの配下で管理されるのに対して、Volumes はスキーマの配下で管理されるため、Volumes の方が細かな権限管理が可能です。Volumes の想定ユースケースとしては、次のようなケースが紹介されています。データエンジニアリングを実施する際には、Volumes をソースとすることでデータリネージを取得できるようになります。

  • Running machine learning on large collections of unstructured data such as image, audio, video, or PDF files.
  • Persisting and sharing training, test, and validation data sets used for model training and defining locations for operational data such as logging and checkpointing directories.
  • Uploading and querying non-tabular data files in data exploration stages in data science.
  • Working with tools that don't natively support Cloud object storage APIs and instead expect files in the local file system on cluster machines.
  • Storing and providing secure access across workspaces to libraries, certificates, and other configuration files of arbitrary formats, such as .whl or .txt, before they are used to configure cluster libraries, notebook-scoped libraries, or job dependencies.
  • Staging and pre-processing raw data files in the early stages of an ingestion pipeline before they are loaded into tables, e.g., using Auto Loader or COPY INTO.
  • Sharing large collections of files with other users within or across workspaces, regions, clouds, and data platforms.

引用元：Announcing Public Preview of Volumes in Databricks Unity Catalog | Databricks Blog

  • 画像、音声、動画、PDF ファイルなどの非構造化データの大規模なコレクションでの機械学習の実行。
  • モデルトレーニングに使用されるトレーニング、テスト、および検証データセットの永続化と共有、およびログ記録やチェックポイントディレクトリなどの操作データの場所の定義。
  • データサイエンスのデータ探索段階での非表形式のデータファイルのアップロードとクエリ。
  • Cloud オブジェクトストレージ API をネイティブにサポートしていないツールでの作業。代わりに、クラスターマシンのローカルファイルシステムにファイルがあることを期待しています。
  • ライブラリ、証明書、およびその他の構成ファイルをワークスペース全体で安全に保存し、クラスターライブラリ、ノートブックスコープのライブラリ、またはジョブの依存関係を構成する前に、.whl や .txt などの任意の形式のファイルを使用する。
  • Auto Loader や COPY INTO を使用して、テーブルにロードされる前のインジェストパイプラインの初期段階で生のデータファイルをステージングおよび前処理する。
  • ワークスペース内またはワークスペース間、リージョン、クラウド、およびデータプラットフォームを横断して、大規模なファイルコレクションを他のユーザーと共有する。」

上記の翻訳

COPY INTO の利用方法については、次のドキュメントにて記載されています。

*7 Lakehouse Federation により他データストア上にあるデータを取得できるようになります。いわゆるデータ仮想化の実施ができるようになり、従来のデータ仮想化システムでは活用が進むとそのシステムのリソースがボトルネックとなることによる性能の課題がでてくるのですが、Databricks では並列処理が可能であるため同じような課題が発生する可能性は低いです。また、JDBC 経由でデータ取得するという既存の Spark 機能を拡張しているはずなので、データ仮想化ソフトウェアと比較すると低価格で利用できると推測しています。詳細については、ドキュメントを参照してください。

現時点での制約として、読み込みのみがサポートされているという制限があります。

このリリースでは、クエリは読み取り専用です。

引用元：Lakehouse フェデレーションを使用してクエリを実行する - Azure Databricks | Microsoft Learn

今後のリリース計画には、他データストアのアクセス管理も可能になる計画があるようです。

最後に、将来的には、Unityカタログで定義されたアクセスポリシーを連携データソースにプッシュして、データがアクセスされる場所で一貫した実施を行うこともできるようになります。これにより、異なるガバナンス・ツール間で冗長なポリシー定義を維持する必要がなくなる。

引用元：UnityカタログにLakehouseフェデレーション機能を導入 | Databricks Blog

*8 詳細については、次のドキュメントを参照してください。

*9 詳細については、次のドキュメントを参照してください。

Introduction to Databricks Lakehouse Monitoring - Azure Databricks | Microsoft Learn

サーバーレスコンピューターが要件であるため、現時点では展開されるリージョンに制限がありそうです。

Databricks Lakehouse Monitoring uses serverless jobs compute. Your account is billed for compute associated with these workloads.

引用元：Introduction to Databricks Lakehouse Monitoring - Azure Databricks | Microsoft Learn

Databricks Lakehouse Monitoring は、サーバーレスのジョブコンピュートを使用します。これらのワークロードに関連するコンピュートに対して、お客様のアカウントに請求が行われます

上記の翻訳

*10 モデルレジストリを、Databricks ワークスペース単位ではなく、Databricks アカウント単位で管理できるようになります。詳細については、次のドキュメントを参照してください。

*11 詳細については、次のドキュメントを参照してください。

*12 次のドキュメントが参考になります。

Unity Cataglog が利用できるコンピューターリソース

Unity Cataglog が利用できるコンピューターリソースとして、次のリソースが提示されています。単一ユーザーアクセスモードでは、ビュー、及び、動的ビューの参照や Delta Live Table で作成したテーブルの参照に制約があることに注意が必要です。制約の詳細については後述します。

  1. Databricsk SQL
  2. 共有アクセスモードの Databricks クラスター
  3. 単一ユーザーアクセスモードの Databricks クラスター

主な制限事項

ドキュメントにて記載されていた注目すべき制限事項を次に示します。

  • オブジェクト数に制限があること *1
  • オブジェクト名に制限があること *2
  • ユーザー数とサービスプリンシパルの上限が 10,000であり、グループの上限が 5000 個であること *3
  • オブジェクトのパスを重複できないこと *4
  • Volumes として登録したディレクトリに対してクラウド URI にて接続できなくなること *5
  • シングルユーザーアクセスモードのクラスターから接続する際に、ビュー、及び、動的ビューの利用時に制約があること *5
  • シングルユーザーアクセスモードのクラスターから Delta live table で作成したテーブルを参照できないこと *6
  • Kafka ソースおよびシンクの場合に制限があること *6
  • Delta live table を利用する際には、カタログストレージロケーション上にデータを保持する必要があること *9
  • 外部ロケーションに設定できるのは、Azure Data Lake Storage Gen2 のみであること *10
  • Azure ファイアウォール、あるいは、プライベート リンクで構成された Azure ストレージ アカウントによるボリュームのファイルをダウンロード、あるいは、アップロードできないこと *11
  • Unity Catalog と DBFS を利用したコードにて同一セル上で実行した場合にエラーとなるケースがあること *12
  • Delta Sharing にて共有できるオブジェクトと個数に上限があること *13

*1 オブジェクト数の上限については次のドキュメントに記載されています。

*2 オブジェクト名の制限については次のドキュメントに記載されています。

The following limitations apply for all object names in Unity Catalog:

  • Object names cannot exceed 255 characters.
  • The following special characters are not allowed:
    • Period (.)
    • Space ( )
    • Forward slash (/)
  • All ASCII control characters (00-1F hex)
  • The DELETE character (7F hex)
  • Unity Catalog stores all object names as lowercase.
  • When referencing UC names in SQL, you must use backticks to escape names that contain special characters such as hyphens (-).

引用元：General limitations - Azure Databricks | Microsoft Learn

Unity Catalogのすべてのオブジェクト名には、以下の制限が適用されます。

  • オブジェクト名は255文字を超えることはできません。
  • 次の特殊文字は使用できません。
    • ピリオド(.)
    • スペース( )
    • スラッシュ(/)
    • すべてのASCII制御文字(00-1F hex)
    • DELETE文字(7F hex)
  • Unity Catalogはすべてのオブジェクト名を小文字で保存します。
  • SQLでUC名を参照する場合、ハイフン(-)などの特殊文字を含む名前をエスケープするためにバッククォートを使用する必要があります。

上記の翻訳

レイクハウスフェデレーション利用時においても同様の制約がある旨が記載されています。

Unity Catalog で無効な名前を持つテーブルとスキーマはサポートされておらず、外部カタログの作成時に Unity Catalog によって無視されます。 命名規則と制限事項の一覧については、「制限事項」を参照してください。

引用元：Lakehouse フェデレーションを使用してクエリを実行する - Azure Databricks | Microsoft Learn

*3 次のドキュメントにて上限数が記載されていおります。

アカウントには、最大 10,000 個のユーザーとサービス プリンシパルの組み合わせ、および 5000 個のグループ含めることができます。 各ワークスペースには、最大 10,000 個のユーザーとサービス プリンシパルの組み合わせ、および 5000 個のグループを含めることができます。

引用元：Azure Active Directory からユーザーとグループを同期する - Azure Databricks | Microsoft Learn

ユーザー数の上限については、引き上げが可能である旨がドキュメントに記載されております。

Resource メトリック 制限 Scope (スコープ) リージョン 固定 メモ
クラスター アタッチされたノートブックまたは実行コンテキスト 145 クラスター All はい
ID グループ 5000 Account All はい
ID ユーザーとサービス プリンシパル 10000 Account All いいえ

引用元：制限 - Azure Databricks | Microsoft Learn

*4 次のようにドキュメントに記載されています。同一ディレクトリを参照したテーブルを複数作成することはできません。

  • You cannot define an external location within another external location.
  • You cannot define a volume within another volume.
  • You cannot define a table within another table.
  • You cannot define a table on any data files or directories within a volume.
  • You cannot define a volume on a directory within a table.

引用元：How do paths work for data managed by Unity Catalog? - Azure Databricks | Microsoft Learn

  • 別の外部ロケーション内に外部ロケーションを定義することはできません。
  • 別のボリューム内にボリュームを定義することはできません。
  • 別のテーブル内にテーブルを定義することはできません。
  • ボリューム内のデータ・ファイルまたはディレクトリーに表を定義することはできません。
  • テーブル内のディレクトリにボリュームを定義することはできません。

上記の翻訳

*5 ドキュメントにて、Volumes として登録したディレクトリに対してクラウド URI （abfss://<container_name>@<storage_account>.dfs.core.windows.net/<path>）で接続できなくなる旨の記載があります。既存のプログラムでクラウド URI で利用しているコードを、Volumes に修正する場合には修正漏れがないようにする必要があります。また、Volumes を作成する際に作成済みの volume のディレクトリ配下に volume を作成しようとするとエラーとなるため、ディレクトリ設計が重要です。

次の表に、Unity カタログ オブジェクトに許可されるアクセス方法を示します。

オブジェクト オブジェクト識別子 ファイルパス クラウド URI
外部の場所 いいえ いいえ はい
管理対象テーブル はい いいえ いいえ
外部テーブル はい いいえ はい
管理対象ボリューム いいえ はい いいえ
外部ボリューム いいえ はい いいえ

引用元：Unity カタログによって管理されるデータのパスはどのように機能しますか?- Azure Databricks |マイクロソフト ラーニング (microsoft.com)

*5 ドキュメントにて次のような記載があります。

ビューから読み取るには、すべての参照先テーブルとビューで SELECT が必要です。
動的ビューはサポートされません。 資格情報のパススルーはサポートされません。

引用元：クラスター アクセス モードとは? - Azure Databricks | Microsoft Learn

*6 次のドキュメントにて制限が記載がされています。

You cannot use a single user cluster to query tables created by a Unity Catalog-enabled Delta Live Tables pipeline, including streaming tables and materialized views created in Databricks SQL. To query tables created by a Delta Live Tables pipeline, you must use a shared cluster using Databricks Runtime 13.1 and above.

引用元：Single user access mode limitations | Microsoft Learn

Unity Catalogを使用したDelta Live Tablesパイプラインで作成されたテーブル、ストリーミングテーブル、およびDatabricks SQLで作成されたマテリアライズドビューをクエリする場合、また単一ユーザークラスタを使用することはできません。Delta Live Tablesパイプラインで作成されたテーブルをクエリするには、Databricks Runtime 13.1以降を使用した共有クラスタを使用する必要があります。

上記の翻訳

*7 次のドキュメントにて制限が記載がされています。

*8 ドキュメントにて次のような記載があります。

Publishing to schemas that specify a managed storage location is not supported. All tables are stored in the catalog storage location if the target catalog specifies one, otherwise, they are stored in the metastore root storage location.
The History tab in Data Explorer does not show history for streaming tables and materialized views.

引用元：Limitations - Azure Databricks | Microsoft Learn

管理されたストレージ場所を指定するスキーマに公開することはサポートされていません。ターゲットのカタログがストレージ場所を指定している場合、すべてのテーブルはカタログのストレージ場所に格納されます。それ以外の場合は、メタストアのルートストレージ場所に格納されます。 Data Explorer の履歴タブには、ストリーミングテーブルやマテリアライズドビューの履歴は表示されません。

上記の翻訳

*9 ドキュメントにて次のように記載されています。

外部の場所では、Azure Data Lake Storage Gen2 ストレージのみがサポートされます。

引用元：外部の場所とストレージの資格情報を管理する - Azure Databricks | Microsoft Learn

*10 ドキュメントにて次のように記載されています。Data Explorer の Volumnes UI にて GUI によりファイルのアップロードなどができなくなるため、ストレージへのアップロード方法をユーザーに提示する必要がありそうです。Azure Storage の場合には、ストレージエクスプローラーの利用を提示することになります。

Azure ファイアウォールまたはプライベート リンクで構成された Azure ストレージ アカウントによってサポートされるボリュームのファイルをアップロードまたはダウンロードすることはできません。

引用元：ボリュームを作成する - Azure データブリック |マイクロソフト ラーニング (microsoft.com)

*11 Unity Catalog の外部ロケーションと Hive Metastore を同時に利用した時にエラーとなる旨が次のドキュメントに記載されている。

たとえば、外部テーブル foo が a/b/c の場所の hive_metastore で定義され、外部の場所が a/b/ 上の Unity Catalog で定義されている場合、次のコードはエラーをスローします。

引用元： 複数パス アクセスに関する制限事項

*12 次のドキュメントに記載されています。

現時点では、ビューのの共有がサポートされておらず、共有ごとのテーブル数の上限が1000個となっています。

このリリースでは、ビューの共有はサポートされていません。

引用元：Delta Sharing を使用してデータを安全に共有する - Azure Databricks | Microsoft Learn

Hive メタストアのテーブルと Unity Catalog のテーブルの主な相違点

Hive メタストアのテーブルと Unity Catalog のテーブルとの主な相違点として次の項目があります。

  1. Hive メタストアではschema.tableの2レベルで管理されるが、Unity Catalog ではcatalog.schema.tableの3レベルで管理されること *1
  2. Hive メタストアではマネージドテーブルの DROP 時にデータも削除するが、Unity Catalog ではマネージドテーブルの DROP 時には 30 日以内にデータが削除されること *2
  3. Hive メタストアではマネージドテーブルのテーブル名がディレクトリ名のベースとなるが、Unity Catalog では 36 字のランダムな文字列（おそらく UUID）がディレクトリ名のベースとなっていること *3
  4. Hive メタストアでは同一のパスを参照したテーブルを複数作成できるが、Unity Catalog では同一メタストア内で同一のパスに対して１つのテーブルしか作成できない。 *4

*1 ドキュメントにて次のように記載されいています。

各メタストアでは、3 レベルの名前空間 (catalog.schema.table) が公開され、ここでデータが整理されます。

引用元：Unity Catalog とは - Azure Databricks | Microsoft Learn

*2 次のようにドキュメントに記載されています。

マネージド テーブルをドロップすると、基になるデータがクラウド テナントから 30 日以内に削除されます。

引用元：テーブルの作成 - Azure Databricks | Microsoft Learn

*3 。次表がメタストアごとのディレクトリ名のサンプルです。

# メタストア ディレクトリ名のサンプル
1 Hive メタストア dbfs:/user/hive/warehouse/dir_diff.db/table_01
2 Unity Catalog abfss://metastore@dbunitycatalogus.dfs.core.windows.net/84690733-be0b-4079-902b-8ae4d60b3515/tables/5c1c3b4a-45bd-46c0-8377-d8bd35920555

Unity Catalog に接続できなくなった状況となった場合に、マネージドテーブルのディレクトリ名からテーブルを判断することが困難です。インフォメーションスキーマにおけるINFORMATION_SCHEMA.TABLESのバックアップを取得しておき、STORAGE_SUB_DIRECTORY列を参照できるように参照できるようにしておくことが望ましいです。

*4 ドキュメントにて次の記載があるように、Unity Catalog では同一のパスを参照したテーブルを複数作成できません。

Tables cannot overlap other tables.

引用元：How do paths work for data managed by Unity Catalog? - Azure Databricks | Microsoft Learn

テーブルを他のテーブルと重ねることはできません。

引用元：How do paths work for data managed by Unity Catalog? - Azure Databricks | Microsoft Learn

同一のディレクトリを参照したテーブルを作成しようとすると、次のエラーが発生します。

[RequestId=66a52dab-9896-450a-bc52-bb76ec71799a ErrorClass=INVALID_PARAMETER_VALUE.LOCATION_OVERLAP] Input path url 'abfss://external@dbucesat.dfs.core.windows.net/data/table_2' overlaps with other external tables or volumes within 'CreateTable' call

Unity Catalog を利用するために

前提事項

本ドキュメントでは、Databricks に関する運用業務の全体象を記載することを目的とせず、Azure Databricks に Unity Catalog 導入する上での追加業務を言及することを目的としています。

オブジェクト別利用指針

Catalog 、および、 Schemaの利用指針

次の利用方針を検討する必要があります。

  1. 権限付与をどのように行うか
  2. カタログとスキーマにストレージのロケーションを割り当てるか
  3. デプロイ環境に応じたカタログを作成するべきか
  4. メダリオンアーキテクチャに応じてスキーマを分けるべきか
  5. 機密レベルに応じてスキーマを分割するべきであるか

権限付与をどのように行うか

特定のドメインごとに次のようなグループを検討し、付与する権限を検討してください。権限対象としては、スキーマ、あるいは、カタログが望ましいです。

# 権限グループ 権限付与方針
1 管理者 OWENER権限を付与する。
2 データライター MODIFY権限やWRIRE FILE権限を付与する。
3 データリーダー SELECT権限やREAD FIEL権限を付与する。

カタログとスキーマにストレージのロケーションを割り当てるか

次の要件がある場合には、カタログ、あるいは、スキーマに、ストレージのロケーションを割り当てることを検討してください。

  1. セキュリティ要件から分離する必要がある
  2. 外部へデータ提供を実施する必要がある
  3. ストレージコストを配賦する必要がある

ドキュメントにおいても、ストレージのロケーションを割り当てる例が記載されています。

ただし、規制上の理由 (または、SDLC スコープ内やビジネス単位間で、またはコストの割り当て目的など) によってデータの物理的な分離が必要な組織の場合、物理的に分離されたデータ ストレージの場所をカタログおよびスキーマ レベルで割り当てることができます。

引用元：Unity Catalog のベスト プラクティス - Azure Databricks | Microsoft Learn

デプロイ環境に応じたカタログを作成するべきか

本番環境と開発環境を分ける必要がある場合には、デプロイ環境（本番環境、検証環境、テスト環境など）に応じたカタログを作成することを検討してください。ドキュメントにおいても、次のように例示されています。

image.png

引用元：Unity Catalog のベスト プラクティス - Azure Databricks | Microsoft Learn

ワークスペースごとに表示するカタログを切り替えることも検討してください。

image.png

引用元：(省略可能) 特定のワークスペースにカタログを割り当てる - Azure Databricks | Microsoft Learn

メダリオンアーキテクチャに応じてスキーマを分けるべきか

メダリオンアーキテクチャによりデータアーキテクチャを設計する際には、レイヤーごとにスキーマを分けるべきかを検討してください。

# レイヤー レイヤー詳細項目
0 Bronze Ingest
1 Bronze Landing
2 Bronze Raw
3 Silver Enriched
4 Gold Curated
5 Other Development

引用元：Databricks ( Spark ) における Spark テーブル（データレイク）のディレクトリ構成の検討 - Qiita

機密レベルに応じてスキーマを分割するべきであるか

機密レベルに応じてスキーマを分割するべきを検討してください。動的ビューを利用する場合には、テーブルを保持したスキーマと動的ビューを保持したスキーマに分割することが望ましいです。

Table の利用指針

次の利用方針を検討する必要があります。

  1. マネージドテーブルと外部テーブルのどちらを利用するか

マネージドテーブルと外部テーブルのどちらを利用するか

マネージドテーブルと外部テーブルの選択する際には要件に応じて切り替える必要があります。

  • マネージドテーブルの利用を検討すべき要件
    1. シンプルな運用を実施する必要がある
    2. Delta Live Table を利用する必要がある
  • 外部テーブルの利用を検討すべき要件
    1. Databricks 以外からのサービスでデータレイクを参照することが必要がある
    2. ディレクトリ構成を管理する必要がある
    3. Delta Lake 形式以外のファイルフォーマットを利用する必要がある

マネージドテーブルと外部テーブルの比較すると次のようになります。

  • マネージドテーブル
    • メリット
      • Delta Live table を利用できること
      • マネージドテーブルのディレクトリに関する情報をバックアップする必要がある
    • デメリット
      • Databricks 以外のサービスから参照する際にディレクトリから判断することができないこと
      • データベースの再現が困難であること
      • データが 30 日以内に削除されること
  • 外部テーブル
    • メリット
      • Databricks 以外のサービスからデータレイクを参照する際にディレクトリから判断することができること
      • データ削除を任意のタイミングで実施可能であること
      • データベースの再現が容易であること
    • デメリット
      • ディレクトリ設計が必要となること
      • Delta Live Table を利用できないこと

Volumes の利用指針

次の利用方針を検討する必要があります。

  1. マネージド Volumne と外部 Volumne のどちらを利用すべきであるか

マネージド Volumne と外部 Volumne のどちらを利用すべきであるか

マネージド Volumne と外部 Volumne の選択する際には要件に応じて切り替える必要があります。

  • マネージド Volumne の利用を検討すべき要件
    1. シンプルな運用を実施する必要がある
    2. Delta Live Table を利用する必要がある
  • マネージド外部 Volumne の利用を検討すべき要件
    1. 機密レベルが高いファイルを利用する必要がある
    2. Landing レイヤーのファイルを利用する必要がある

必要な業務

Unity Catalog を利用するためのプロセスの全体象

Unity Catalog を利用するためには、次のプロセスが必要です。

  1. 方針検討
  2. Unity Catalog 環境の構築
  3. オブジェクトの管理業務とモニタリング業務の実施

1. 方針検討

次の管理方針を検討します。方針例については、後述します。

  1. Unity Catalog 利用方針
    1. Unity Catalog のデプロイ方針
    2. Unity Catalog における機能の利用方針
    3. Databricks アカウント管理者の方針
    4. アカウントの管理方針
    5. オブジェクトへの権限付与運用指針 *1
    6. モニタリング方針
  2. 既存の Databricks へのアップグレード方針
    1. ワークスペース ローカルのグループの利用方針
    2. 既存の Hive Metastore テーブルのアップグレードの実施有無
    3. Databricks ワークスペースへの Unity Catalog のアタッチの方針検討
  3. Unity Catalog に関わる管理業務の方針
    1. Databricks アカウントに関わる管理業務の方針
      1. Unity Catalog に関わるリソースのライフサイクル管理
      2. Unity Catalog 新機能の管理
      3. SCIM プロビジョニングの管理
      4. Databricks Workspace のアタッチ
    2. オブジェクトの管理業務方針
      1. オブジェクト利用に関するサポート対応
      2. オブジェクトの作成依頼・更新依頼への対応
      3. オブジェクトの削除依頼への対応
      4. オブジェクトに対するモニタリングと改善対応要求

*1 機密レベルを検討する際には、DMBOK（データマネジメント知識体系ガイド）にて例示されている項目が参考になります。

公開用：公衆を含む誰でも利用できる情報

社内向け：情報は従業員やメンバーに限定されるが、共有した場合のリスクは最小限である。

社外秘：適切に結ばれた機密保持契約やそれに類するものがない場合は、組織外で共有することができない情報。

制限付機密：「知る必要がある」一定のロールを持つ個人に限定された情報。

登録者限定機密：非常に機密レベルが高い情報で、データにアクセスするためには、情報にアクセスするすべての人が法的な合意に署名し、秘密のために責任を負わなければならない。

引用元：データマネジメント知識体系ガイド 第二版 第7章データセキュリティ

2. Unity Catalog 環境の構築

策定した方針に基づき、Unity Catalog 環境を構築します。次のような作業があります。

  1. Unity Catalog 環境の構築 *1
    1. Azure Databricks アクセスコネクタの構築
    2. Azure Storage の構築 *2
    3. Azure Databricks アクセスコネクタへの認証設定
    4. プリンシパル（ユーザーやグループなど）の登録
  2. 既存の Databricks オブジェクトを Unity Catalog へ移行元
    1. 移行元オブジェクトを特定
    2. 移行先 Unity Catalog オブジェクトへのマッピングを実施
    3. オブジェクト移行の実施
    4. 移行元オブジェクトの削除
    5. ストレージのマウント解除
    6. ストレージへのシークレットの削除

*1 次のリンクが参考となります。

*2 ストレージに対して次のような設定を行います。

  • ストレージのファイヤーウォールの設定
    • 利用想定の Databricks Workspace から参照できるように設定
    • Databricks SQL Serverless から参照できるように設定
  • CORS の設定

CORS の設定については、次のドキュメントが参考になります。

3. オブジェクトの管理業務とモニタリング業務の実施

Unity Catalog に関わる管理業務の方針に基づき、業務を実施します。

Unity Catalog 利用方針例

基本方針

基本原則

  1. データ利活用促進のため、カタログやスキーマなどのオブジェクトを連邦型による分散管理を行う。
  2. 機密レベルを考慮してデータの管理を行い、最小特権の原則に基づき権限付与を行う。
  3. プリンシパルに権限を付与する場合にはユーザーではなくグループに対して行い、システムの自動化を行う際にはシステムアカウントにより実施する。

主な管理者

Unity Catalog を運用するためには、次の管理者を特定する必要があります。

  • Databricks アカウント管理者
  • Unity Catalog におけるメタストア管理者
  • Unity Catalog における Catalog 管理者
  • Unity Catalog における Schema 管理者
  • Databricks ワークスペース管理者

機密レベルの方針

テーブルごとに機密レベルを設定し、次の方針によりデータ提供を実施する。

# 機密レベル confidentiality_level データの提供方法
1 公開用 general テーブルへのSELECT権限を付与する。
2 社内向け internal テーブルへのSELECT権限を付与する。
3 社外秘 Confidential テーブルへのSELECT権限を付与する。
4 制限付機密 restricted_confidential 動的ビューへのSELECT権限を付与する。
5 登録者限定機密 registered_confidential 動的ビューへのSELECT権限を付与する。

1. Unity Catalog 利用方針

1-1. Unity Catalog のデプロイ方針

デプロイ方針としては、次の環境の方針をそれぞれ提示する。

  1. 本番環境の方針
  2. 検証・本番の方針
  3. 他リージョン環境の方針

本番環境の方針

次のリージョンに Unity Catalog をデプロイすることとする。各 Unity Catalog については、Databricks 間の Delta Sharing 機能により連携を行うこととする。

# システム管理拠点 Unity Catalog デプロイ先クラウド環境 備考
1 APAC(Asia Pacific) Azure japaneast
2 AMER(Americas) Azure westus
3 EMEA(Europe,Middle-East,Africa) - 今後の検討事項とする
4 China - 今後の検討事項とする

検証・本番の方針

Unity Catalog の検証・開発を行う方法としては、以下の方法があるが、1 を採用することする。

# 方針 pros cons 備考
1 同一 Azure テナント上で、同一の Unity Catalog 上にて利用するカタログを制限したワークスペースを開発、検証などに利用する - 導入障壁が低い - 環境の設定ミスにより誤って検証時に本番環境へ影響を与える可能性があること
- 本番環境と同等の名称での検証ができなくなること
2 同一 Azure テナント上で、利用を想定していないリージョンを開発、検証などに利用する - 本番環境と分離して、検証や開発を行うことが可能 - 利用を想定しないリージョン
- Databricks アカウントの設定に関する検証ができないこと。
3 複数 Azure テナント上で、開発、検証の環境をデプロイ - 本番環境とは分離された Databricks アカウント上での検証・開発を行うことが可能 - Azure テナントの払出が必要となること

他リージョン環境の方針

上記以外のリージョンにおいては、Unity Catalog の導入を実施しないこととする。

1-2. Unity Catalog における機能の利用方針

次の機能を利用することとする。

# 機能 備考
1 アカウントレベルのグループ
2 Metastore
3 Catalog 、および、 Schema
4 Table、View、および、Function
5 Storage credential
6 External locaion
7 Volumes
8 Connection、および、Lakehouse Federation
9 Delta Sharing
10 REGISTERED MODEL
11 Databricks Assitant GA 後に価格が決定されるため、利用を停止する可能性あり

次の機能については、利用しないこととする。

# 機能 棄却理由
1 Databricks SQL Serverless Databricks SQL Serverless が利用できなたいめ。
2 Databricks Lakehouse Monitoring Databricks SQL Serverless が利用できなたいめ。
3 Databricks Marketplace 利用要件がないため。

アカウントレベルのグループの利用基本方針

SCIM プロビジョニングによる Azure AD グループを連携すること前提とし、グループの作成やユーザーの割合を実施しない。

Metastoreの利用基本方針

メタストア管理者に対してOWNER権限を付与する。

Catalog 、および、 Schema の利用基本方針

申請内容に基づき、オブジェクトを作成後、依頼者が提示したグループに対してOWNER権限を付与する。

Table、View、および、Function の利用基本方針

払出済み Catalog、あるいは、払出済み Schema 上でオブジェクトを作成することを前提として、Table、View、あるいは、Function への権限付与については実施しない。

Volumes の利用基本方針

払出済み Catalog、あるいは、払出済み Schema 上でオブジェクトを作成することを前提として、Volumes への権限付与については実施しない。

Storage credential の利用基本方針

Databricks アカウント管理者が管理を行い、その他のユーザーに対して権限付与を行わない。

External locaion の利用基本方針

申請内容に基づき、Databricks アカウント管理者が作成を行い、依頼者が提示したグループに対してALL PRIVILEGES権限付与する。

Connection、および、Lakehouse Federation の利用基本方針

申請内容に基づき、Databricks アカウント管理者がConnectionの作成を行い、依頼者が提示したグループに対してOWNER権限付与する。依頼者が申請内容に基づき、外部カタログの作成を実施する。

Delta Sharing の利用基本方針

Databricks アカウント管理者が管理を行い、その他のユーザーに対して権限付与を行わない。

Delta Sharing には次の２種類あるが、Unity Catalog 間の連携を目的として 2 のみを利用する。

  1. Delta Sharing オープン共有プロトコルによる Delta Sharing
  2. Databricks 間 Delta Sharing

1-3. Databricks アカウント管理者の方針

Databricks アカウント管理者が管理を行う。

1-4. アカウントの管理方針

Databricks アカウントにて設定できる次の方針を定める。

  1. ワークスペースの管理方針
  2. メタストアの管理方針
  3. プリンシパルの管理方針
  4. Databricks アカウント設定の管理方針

ワークスペースの管理方針

Unity Catalog デプロイ先となっているリージョンにおける Databricsk Workspace の割当状況を台帳にて管理する。

メタストアの管理方針

リージョンごとの Unity Catalog におけるメタストア管理者が管理を行う。

プリンシパルの管理方針

プリンシパル（ユーザー、グループ、及び、サービスプリンシパル）については、Microsoft Entra ID との SCIM（System for Cross-domain Identity Management）により管理することとする。プリンシパルの作成・更新・削除に関する依頼については、Microsoft Entra ID チームへの依頼とする。

Databricks アカウント設定の管理方針

機能の有効化に関して次の設定値とする。

# 機能 設定値 備考
1 Personal Compute Enable for all
2 Web Terminal Default to Off
3 Enable Admin Protection for “No Isolation Shared” Clusters Disabled
4 Enable Admin Protection for “No Isolation Shared” Clusters Enable for all

1-5. オブジェクトへの権限付与運用指針

アカウント管理者が申請内容に基づいて Unity Catalog へのオブジェクトへの権限付与を行うが、その配下のオブジェクトへの権限付与を実施しない。

1-6. モニタリング方針

申請内容に基づき、次の項目をモニタリングする。

  • オブジェクト数
  • データ容量
  • オブジェクトのオーナー

2. 既存の Databricks へのアップグレード方針

ToDo Volume への移行を記載

2-1. ワークスペースローカルのグループの利用方針

Databricks ワークスペース管理者が、Microsoft Entra ID にて移行が必要となるグループを作成する。

2-2. 既存の Hive Metastore テーブルのアップグレードの実施有無

Databricks ワークスペース管理者が Unity Catalog のオブジェクトに移行を実施するかを判断する。

2-3. Databricks ワークスペースへの Unity Catalog のアタッチの方針検討

申請内容に基づき、Databricks アカウント管理者が対象の Databricks ワークスペースをアタッチする。

2-4. ストレージへの参照を VolumeS への切り替えの実施有無

Databricks ワークスペース管理者が ストレージへの参照を、 VolumeS へ切り替えるかを判断する。

3. Unity Catalog に関わる管理業務の方針

3-1. Databricks アカウントに関わる管理業務の方針

Databricks アカウント管理者が、次の業務を実施する。

  1. Unity Catalog に関わるリソースのライフサイクル管理
  2. Unity Catalog 機能の管理
  3. SCIM プロビジョニングの管理
  4. Databricks Workspace のアサイン／リムーブ
  5. メタストア管理者へのサポート対応

Unity Catalog に関わるリソースのライフサイクル管理

Unity Catalog に関わる次のリソースの管理を行う。

  • Databricks アクセスコネクター
  • メタストア用 Azure Storage

Unity Catalog 機能の管理

Unity Catalog 機能の利用の有無を検討し、Databricks アカウント設定の管理方針を変更を行う。

SCIM プロビジョニングの管理

Microsoft Entra ID からの SCIM プロビジョニングの実施を行い、継続的な同期が実施されていることの監視を行う。

Databricks Workspace のアサイン／リムーブ

Databricks Workspace をメタストアへのアサイン、あるいは、リムーブを行う。

メタストア管理者へのサポート対応

メタストア管理者からの問い合わせ対応を実施する。

3-2. メタストアに関わる管理業務方針

リージョンごとの Unity Catalog におけるメタストア管理者が次の業務を実施する。

  1. メタストア利用に関するサポート対応
  2. メタストアの作成依頼・更新依頼への対応
  3. メタストアの削除依頼への対応
  4. メタストアに対するモニタリングと改善対応要求

メタストア利用に関するサポート対応

メタストア利用者からの問い合わせ対応を実施する。

メタストアの作成依頼・更新依頼への対応

利用申請には次の申請があり、それぞれの申請に応じた対応を実施する。

  1. Catalog 、および、 Schema の利用申請
  2. External locaion の利用申請
  3. Connection、および、Lakehouse Federation の利用申請

オブジェクトの削除依頼への対応方法

オブジェクトの削除を、基本的には申請者が実施する。ただし、セキュリティ上の懸念な場合やオーナーが不明確な場合には削除を行う。

オブジェクトに対するモニタリングと改善対応要求

モニタリング方針に応じてモニタリングを行い、、必要に応じて改善対応要求を実施する。

参考リンク集

ベストプラクティスに関するドキュメント

Unity Catalog に関する検証記事

6
5
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
6
5