Unity Catalogのベストプラクティス

本文書では、データガバナンスのニーズを満たすためにUnity CatalogとDelta Sharingを使用するための推奨事項を説明します。

Unity Catalog は、Databricks プラットフォーム上のデータと AI のためのきめ細かなガバナンスソリューションです。データアクセスを一元的に管理および監査する場所を提供することで、データのセキュリティとガバナンスを簡素化します。 Delta Sharing は、Databricks のデータを組織外のユーザーと共有できる安全なデータ共有プラットフォームです。 Unity Catalog を使用して、共有動作を管理および監査します。

データガバナンスとデータ分離の構成要素

組織に適したデータガバナンスモデルとデータ分離計画を開発するには、Databricksでデータガバナンスソリューションを作成するときに利用できる主要な構成要素を理解することが役立ちます。

次の図は、Unity Catalog のプライマリデータ階層を示しています (一部のセキュリティ保護可能なオブジェクトは、カタログで管理されるオブジェクトの階層を強調するために淡色表示されています)。

その階層内のオブジェクトには、次のものが含まれます：

モデルと関数:厳密に言えば、データ資産ではありませんが、登録されたモデルとユーザー定義関数もUnity Catalogで管理でき、オブジェクト階層の最下位レベルに存在します。 Unity Catalogでのモデルのライフサイクルの管理」およびUnity Catalogのユーザー定義関数 (UDF)」を参照してください。

データ分離モデルを計画する

組織がDatabricksのようなデータプラットフォームを使用する場合、多くの場合、環境間（開発と運用など）または組織の運用単位間にデータ分離境界を設ける必要があります。

分離基準は組織によって異なる場合がありますが、通常は次のことが期待されています：

ユーザーは、指定されたアクセスルールに基づいてのみデータにアクセスできる。
データは、指定された人物またはチームのみが管理できる。
データはストレージ内で物理的に分離されている。
データは指定された環境でのみアクセスできる。

データ分離の必要性により、環境がサイロ化され、データガバナンスとコラボレーションの両方が不必要に困難になる可能性があります。Databricksは、統一されたデータガバナンスプラットフォームを維持しながら、多数のデータ分離オプションを提供するUnity Catalogを使用してこの問題を解決します。このセクションでは、Databricksで利用できるデータ分離オプションと、集中型データガバナンスモデルを好むか、分散型データガバナンスモデルを好むかに応じたその使用方法について説明します。

ユーザーは、指定されたアクセスルールに基づいてのみデータにアクセスできる

ほとんどの組織では、内部要件や規制要件に基づいて、データアクセスに関する厳しい要件が定められています。安全性を確保しなければならないデータの典型例としては、従業員の給与情報やクレジットカードの決済情報などがあります。この種の情報へのアクセスは通常厳しく管理され、定期的に監査されます。Unity Catalogは、このような業界標準を満たすために、カタログ内のデータ資産をきめ細かく制御します。Unity Catalogが提供するコントロールにより、ユーザーは閲覧およびクエリーする権利があるデータのみを閲覧およびクエリーすることができます。

データは指定された人またはチームのみが管理できる

Unity Catalogを使用すると、集中型ガバナンスモデルと分散型ガバナンスモデルのどちらかを選択できます。

集中管理モデルでは、ガバナンス管理者はMetastoreの所有者であり、あらゆるオブジェクトの所有権を取得し、権限を付与および取り消すことができます。

分散ガバナンスモデルでは、カタログまたはカタログのセットがデータドメインとなります。そのカタログのオーナーは、すべてのアセットを作成して所有し、そのドメイン内のガバナンスを管理することができます。あるドメインの所有者は、他のドメインの所有者から独立して活動することができます。

データドメインとしてMetastoreを選択するかカタログを選択するかに関係なく、DatabricksではグループをMetastore管理者またはカタログ所有者として設定することを強くお勧めします。

データはストレージ内で物理的に分離されている

組織は、特定のタイプのデータをクラウドテナント内の特定のアカウントまたはバケット内に保存することを要求できます。

Unity Catalog では、このような要件を満たすために、メタストア、カタログ、またはスキーマレベルでストレージの場所を構成できます。

たとえば、組織に、人的リソースに関連する本番運用データをバケット s3://mycompany-hr-prod に配置する必要がある会社のコンプライアンスポリシーがあるとします。 Unity Catalog では、カタログレベルで場所を設定し、 hr_prodなどと呼ばれるカタログを作成し、その場所 s3://mycompany-hr-prod/unity-catalog を割り当てることで、この要件を実現できます。つまり、 hr_prod カタログで作成されたマネージドテーブルまたはボリュームは (たとえば、 CREATE TABLE hr_prod.default.table …を使用して) s3://mycompany-hr-prod/unity-catalog にデータを格納します。必要に応じて、スキーマレベルの場所を指定して、 hr_prod catalog 内のデータをより詳細なレベルで整理できます。

このようなストレージの分離が不要な場合は、メタストアレベルでストレージの場所を設定できます。その結果、この場所は、メタストア内のカタログとスキーマにまたがってマネージドテーブルとボリュームを格納するための既定の場所として機能します。

システムは、スキーマからカタログ、メタストアまでのストレージの場所の階層を評価します。

たとえば、テーブル myCatalog.mySchema.myTable が my-region-metastoreで作成されている場合、テーブルの格納場所は次のルールに従って決定されます。

mySchemaの場所が提供されている場合は、そこに保存されます。
そうでなく、 myCatalogで場所が提供されている場合は、そこに保存されます。
最後に、 myCatalogで場所が指定されていない場合は、 my-region-metastoreに関連付けられた場所に保存されます。

指定された環境でのみデータにアクセス可能

多くの場合、組織やコンプライアンスの要件では、個人データなどの特定のデータには特定の環境でのみアクセスできるようにすることが規定されています。また、本番データを開発環境から隔離したり、特定のデータセットやドメインが決して結合されないようにしたい場合もあります。

Databricks では、ワークスペースが主要なデータ処理環境であり、カタログが主要なデータドメインです。 Unity Catalog を使用すると、メタストア管理者とカタログ所有者はカタログを特定のワークスペースに割り当てる (つまり「バインド」する) ことができます。これらの環境認識バインディングにより、ユーザーに付与されたデータオブジェクトに対する特定の権限に関係なく、ワークスペース内で特定のカタログのみが使用可能になることを保証できます。

ここで、ニーズを満たすためにUnity Catalogをセットアップするプロセスを詳しく見てみましょう。

Unity Catalog Metastoreを構成する

メタストアは、Unity Catalog 内のオブジェクトの最上位のコンテナーです。メタストアは、データ資産 (テーブル、ビュー、ボリューム) と、Unity Catalog によって管理されるその他のセキュリティ保護可能なオブジェクトを管理します。セキュリティ保護可能なオブジェクトの完全な一覧については、「 Unity Catalog のセキュリティ保護可能なオブジェクト」を参照してください。

この項では、メタストアを作成および構成するためのヒントを提供します。ワークスペースで Unity Catalog が自動的に有効になった場合は、メタストアを作成する必要はありませんが、このセクションに示す情報は引き続き役立つ場合があります。「 Unity Catalog の自動有効化」を参照してください。

Metastoreを構成するためのヒント：

「Unity Catalog Metastoreの作成」を参照してください。

外部ロケーションとストレージ認証情報を設定する

外部ロケーションを使用すると、Unity Catalogはユーザーに代わってクラウドテナント上のデータを読み書きできます。外部ロケーションは、クラウドストレージへのパスとして定義され、その場所へのアクセスに使用できるストレージ資格情報と組み合わされます。

外部ロケーションを使用して、Unity Catalogの外部テーブルおよび外部ボリュームを登録できます。これらのエンティティのコンテンツは、ユーザーがボリュームまたはテーブルを作成するときに参照される外部ロケーションのサブパスに物理的に配置されます。

ストレージ資格情報は、クラウドストレージにアクセスするための長期的なクラウド資格情報をカプセル化します。たとえば、AWSでは、S3バケットにアクセスするようにIAMロールを構成できます。

ヒント

外部ロケーションは、ストレージ資格情報とストレージパスを組み合わせることで、ストレージアクセスの強力な制御と監査可能性を提供します。ユーザーが Unity Catalog によって提供されるアクセス制御をバイパスしないようにするには、外部ロケーションとして使用されているバケットに直接アクセスできるユーザーの数を制限する必要があります。同じ理由で、ストレージアカウントが外部ロケーションとしても使用されている場合は、DBFS にマウントしないでください。 Databricks では、カタログエクスプローラーを使用して、クラウドストレージの場所にあるマウントを Unity Catalog の外部ロケーションに移行することをお勧めします。

外部ロケーションを管理するためのベストプラクティスのリストについては、「外部ロケーション、外部テーブル、および外部ボリュームの管理」を参照してください。「外部ロケーションを作成してクラウドストレージを Databricks に接続する」も参照してください。

データを整理する

Databricks では、カタログを使用して、組織の情報アーキテクチャ全体で分離を提供することをお勧めします。多くの場合、これは、カタログがソフトウェア開発環境のスコープ、チーム、または部署に対応することを意味します。ワークスペースをデータ分離ツールとして使用する場合 (たとえば、運用環境と開発環境に異なるワークスペースを使用する場合や、機密性の高いデータを操作するために特定のワークスペースを使用する場合)、カタログを特定のワークスペースにバインドすることもできます。これにより、指定したデータのすべての処理が適切なワークスペースで処理されます。「 (オプション) 特定のワークスペースにカタログを割り当てる」を参照してください。

スキーマ (データベースとも呼ばれます) は、Unity Catalog の 3 レベルの名前空間の 2 番目のレイヤーであり、テーブル、ビュー、ボリュームを整理します。スキーマを使用して、アセットのアクセス許可を整理および定義できます。

Unity Catalogが管理するオブジェクトは、管理することも外部にすることもできます：

管理対象オブジェクトは、Unity Catalogでデータオブジェクトを作成するデフォルトの方法です。

Unity Catalog、これらのセキュリティ保護可能なリソースのライフサイクルとファイルレイアウトを管理します。Databricksの外部でツールを使用して、マネージドテーブルまたはボリューム内のファイルを直接オペレーションしないでください。

マネージドテーブルとマネージドボリュームは、特定のテーブルまたはボリュームのメタストア、カタログ、またはスキーマレベルで存在できる マネージドストレージに格納されます。ストレージ内でデータが物理的に分離されているを参照してください。

Managed Table and Volumesは、外部ロケーションとストレージ資格情報を作成および管理するためのオーバーヘッドなしに、コンテンツの管理された場所をプロビジョニングする場合に便利なソリューションです。

マネージドテーブルでは常にDeltaテーブル形式が使用されます。
外部オブジェクトは、データのライフサイクルとファイルレイアウトがUnity Catalogによって管理されないセキュリティ保護可能なリソースです。

外部ボリュームとテーブルは外部ロケーションに登録され、データコピーアクティビティを必要とせずにクラウドストレージにすでに存在する多数のファイルへのアクセスを提供します。他のシステムによって生成されたファイルがあり、Databricks内からアクセスできるようにステージングする場合、またはDatabricksの外部のツールがこれらのファイルに直接アクセスする必要がある場合は、外部オブジェクトを使用します。

外部テーブルは、Delta Lakeや、Parquet、JSON、CSVなどの他の多くのデータ形式をサポートしています。管理ボリュームと外部ボリュームの両方を使用して、任意の形式のファイルにアクセスして保存できます。データは構造化、半構造化、または非構造化のいずれかです。

テーブルとボリュームの作成の詳細については、「 Unity Catalog でのテーブルの作成」と「ボリュームの作成と操作」を参照してください。

外部の場所、外部テーブル、外部ボリュームを管理する

以下の図は、1つのストレージ資格情報を共有する4つの外部の場所を持つ、単一のクラウドストレージバケットのファイルシステム階層を表しています。

Unity Catalogで外部ロケーションを構成したら、外部ロケーション内のディレクトリに外部テーブルとボリュームを作成できます。その後、Unity Catalogを使用して、これらのテーブルとボリュームへのユーザーおよびグループのアクセスを管理できます。これにより、特定のユーザーまたはグループに特定のディレクトリとクラウド上のストレージバケットにあるファイルへのアクセスを提供できます。

注

ボリュームを定義すると、ボリュームパスの下のデータへのクラウド URI アクセスは、ボリュームの権限によって管理されます。

外部の場所を使用する場合の推奨事項

外部ロケーションに対するアクセス許可を付与するための推奨事項：

外部ロケーションを作成する権限は、Unity Catalogとクラウドストレージ間の接続を設定するタスクである管理者、または信頼できるデータエンジニアにのみ付与します。

外部ロケーションは、Unity Catalog 内からクラウドストレージ内の広範な場所 (バケットまたはコンテナー全体 (s3://mybucket) や広範なサブパス (s3://mybucket/alotofdata) など) へのアクセスを提供します。その目的は、クラウド管理者がいくつかの外部ロケーションの設定に関与し、それらの場所を管理する責任を組織内の Databricks 管理者に委任できるようにすることです。その後、Databricks 管理者は、外部ロケーションの下の特定のプレフィックスで外部ボリュームまたは外部テーブルを登録することで、外部ロケーションをより詳細なアクセス許可を持つ領域にさらに整理できます。

外部ロケーションは非常に包括的であるため、Databricksでは、Unity Catalogとクラウドストレージ間の接続を設定するタスクである管理者、または信頼できるデータエンジニアにのみCREATE EXTERNAL LOCATIONアクセス許可を付与することをお勧めします。他のユーザーにより詳細なアクセスを提供するために、Databricksでは、外部ロケーションの上に外部テーブルまたはボリュームを登録し、ボリュームまたはテーブルを使用してデータへのアクセス権をユーザーに付与することをお勧めします。テーブルとボリュームはカタログとスキーマの子であるため、カタログ管理者またはスキーマ管理者はアクセス許可を最終的に制御できます。
外部ロケーションに対する一般的なREAD FILESまたはWRITE FILESアクセス許可をエンドユーザーに付与しないでください。

ボリュームが利用できるようになったため、ユーザーはテーブル、ボリューム、または管理された場所の作成以外に外部ロケーションを使用しないでください。データサイエンスやその他の表形式以外のデータのユースケースのパスベースのアクセスに外部ロケーションを使用しないでください。

ボリュームは、SQLコマンド、dbutils、Spark API、REST API、Terraformを使用したファイルオペレーションのサポートと、ファイルの参照、アップロード、ダウンロードのためのユーザーインターフェイスを提供します。さらに、ボリュームは、/Volumes/<catalog_name>/<schema_name>/<volume_name>/の下のローカルファイルシステム上でアクセスできるFUSEマウントを提供します。FUSEマウントを使用すると、データサイエンティストやMLエンジニアは、多くの機械学習やオペレーティングシステムライブラリで必要とされるローカルファイルシステム内にあるかのようにファイルにアクセスできます。

外部ロケーションにあるファイルへの直接アクセスを許可する必要がある場合（たとえば、ユーザーが外部テーブルまたはボリュームを作成する前にクラウドストレージ内のファイルを探索する場合）、READ FILESを付与できます。WRITE FILESを付与するユースケースはまれです。

外部ロケーションを使用して、次のオペレーションを行う必要があります：

外部テーブルとボリュームを登録するには、CREATE EXTERNAL VOLUMEコマンドまたはCREATE TABLEコマンドを使用します。
特定のプレフィックスで外部テーブルまたはボリュームを作成する前に、クラウドストレージ内の既存のファイルを探索します。READ FILES特権は前提条件です。
Metastoreルートバケットの代わりに、カタログとスキーマの管理ストレージとして場所を登録します。CREATE MANAGED STORAGE特権は前提条件です。

外部ロケーションを使用するためのその他の推奨事項：

パスの重複の競合を回避する：外部ロケーションのルートに外部ボリュームまたはテーブルを作成しないでください。

外部の場所のルートに外部ボリュームまたは外部テーブルを作成する場合、その外部の場所に追加の外部ボリュームまたは外部テーブルを作成することはできません。代わりに、外部の場所内のサブディレクトリに外部ボリュームまたは外部テーブルを作成します。

外部ボリュームの使用に関する推奨事項

外部ボリュームを使用して、次のことを行う必要があります：

外部システムによって生成された生データのランディングエリアを登録して、ETLパイプラインやその他のデータエンジニアリング活動の初期段階での処理をサポートします。
たとえば、Auto Loader、COPY INTO、またはCTAS（CREATE TABLE AS）ステートメントを使用して、インジェストするステージング場所を登録します。
管理ボリュームがオプションではない場合に、データサイエンティスト、データアナリスト、機械学習エンジニアが探索的データ分析やその他のデータサイエンスタスクの一部として使用できるファイルストレージの場所を提供します。
Databricksユーザーに、他のシステムによって作成されクラウドストレージに保存された任意のファイル (たとえば、監視システムやIoTデバイスによってキャプチャされた非構造化データの大規模なコレクション (画像、音声、ビデオ、PDF ファイルなど)、またはライブラリファイル ( JAR およびPython wheelファイル) は、ローカルの依存関係管理システムまたはCI/CDパイプラインからエクスポートされます。
管理対象ボリュームがオプションにならない場合、ロギングファイルやチェックポイントファイルなどの運用データを保管します。

外部ボリュームの使用に関するその他の推奨事項：

Databricksでは、1つのスキーマ内の1つの外部ロケーションから外部ボリュームを作成することをお勧めします。

ヒント

データが別の場所にコピーされる取り込みユースケース（たとえばAuto LoaderやCOPY INTOを使用する）の場合は、外部ボリュームを使用します。コピーを使用せずに、テーブルとしてその場でデータをクエリーする場合は、外部テーブルを使用します。

外部テーブルの使用に関する推奨事項

管理テーブルを作成できない場合は、クラウドストレージに保存されているデータに対する通常のクエリーパターンをサポートするために外部テーブルを使用する必要があります。

外部テーブルの使用に関するその他の推奨事項：

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

アクセスコントロールの設定

Unity Catalog内のセキュリティ保護可能なオブジェクトにはそれぞれ所有者がいます。オブジェクトを作成したプリンシパルは、そのオブジェクトの最初の所有者となります。オブジェクトの所有者は、テーブルに対するSELECTやMODIFYなど、オブジェクトに対するすべての権限を持ち、また、セキュリティ保護可能なオブジェクトに対する権限を他のプリンシパルに付与する権限も持ちます。セキュリティ保護可能なオブジェクトの所有者のみが、そのオブジェクトに対する権限を他のプリンシパルに付与する権限を持ちます。したがって、ベストプラクティスは、すべてのオブジェクトの所有権を、オブジェクトに対する許可の管理を担当するグループに構成することです。所有者とMetastore管理者の両方が、セキュリティ保護可能なオブジェクトの所有権をグループに譲渡できます。さらに、オブジェクトがカタログ（テーブルやビューなど）内に含まれている場合、カタログとスキーマの所有者はオブジェクトの所有権を変更できます。

Unity Catalog 内のセキュリティ保護可能なオブジェクトは階層構造であり、特権は下位に継承されます。つまり、カタログまたはスキーマに対する特権を付与すると、カタログまたはスキーマ内の現在および将来のすべてのオブジェクトに特権が自動的に付与されます。詳細については、「継承モデル」を参照してください。

テーブルまたはビューからデータを読み取るには、ユーザーは次の権限を持っている必要があります：

SELECT テーブルやビュー
USE SCHEMA テーブルを所有するスキーマ
USE CATALOG スキーマを所有するカタログ

USE CATALOG 権限付与対象ユーザーが子オブジェクトにアクセスするためにカタログを走査できるようにし USE SCHEMA 、権限付与対象ユーザーが子オブジェクトにアクセスするためにスキーマを走査できるようにします。たとえば、テーブルからデータを選択するには、そのテーブルに対する SELECT 権限、親カタログに対する USE CATALOG 権限、および親スキーマに対する USE SCHEMA 権限が必要です。したがって、この特権を使用して、データ名前空間のセクションへのアクセスを特定のグループに制限できます。一般的なシナリオは、そのチームだけがスキーマに USE SCHEMA と CREATE を持つチームごとにスキーマを設定することです。つまり、チームメンバーが作成したテーブルは、チーム内でのみ共有できます。

次のSQL構文を使用して、テーブルへのアクセスを保護できます：

GRANT USE CATALOG ON CATALOG < catalog_name > TO < group_name >;
GRANT USE SCHEMA ON SCHEMA < catalog_name >.< schema_name >
TO < group_name >;
GRANT
SELECT
  ON < catalog_name >.< schema_name >.< table_name >;
TO < group_name >;

次のSQL構文に示すように、セカンダリスキーマのダイナミックビューを使用して列へのアクセスを保護できます：

CREATE VIEW < catalog_name >.< schema_name >.< view_name > as
SELECT
  id,
  CASE WHEN is_account_group_member(< group_name >) THEN email ELSE 'REDACTED' END AS email,
  country,
  product,
  total
FROM
  < catalog_name >.< schema_name >.< table_name >;
GRANT USE CATALOG ON CATALOG < catalog_name > TO < group_name >;
GRANT USE SCHEMA ON SCHEMA < catalog_name >.< schema_name >.< view_name >;
TO < group_name >;
GRANT
SELECT
  ON < catalog_name >.< schema_name >.< view_name >;
TO < group_name >;

次のSQL構文に示すように、セカンダリスキーマの動的ビューを使用して行へのアクセスを保護できます：

CREATE VIEW < catalog_name >.< schema_name >.< view_name > as
SELECT
  *
FROM
  < catalog_name >.< schema_name >.< table_name >
WHERE
  CASE WHEN is_account_group_member(managers) THEN TRUE ELSE total <= 1000000 END;
GRANT USE CATALOG ON CATALOG < catalog_name > TO < group_name >;
GRANT USE SCHEMA ON SCHEMA < catalog_name >.< schema_name >.< table_name >;
TO < group_name >;
GRANT
SELECT
  ON < catalog_name >.< schema_name >.< table_name >;
TO < group_name >;

また、行フィルターと列マスクを使用して、テーブルへの安全なアクセスをユーザーに付与することもできます。詳細については、「行フィルターと列マスクを使用して機密テーブルデータをフィルター処理する」を参照してください。

Unity Catalogのすべての権限の詳細については、「 Unity Catalogでの権限の管理」を参照してください。

クラスター構成の管理

Databricksでは、クラスターポリシーを使用して、一連のルールに基づいてクラスターを構成する機能を制限することをお勧めします。クラスターポリシーを使用すると、Unity Catalogが有効なクラスターの作成のみにアクセスを制限できます。クラスターポリシーを使用すると、利用可能な選択肢が減り、ユーザーのクラスター作成プロセスが大幅に簡素化され、データにシームレスにアクセスできるようになります。クラスターポリシーを使用すると、クラスターごとの最大コストを制限することでコストを制御することもできます。

アクセス制御の整合性を確保し、強力な分離保証を適用するために、Unity Catalog ではコンピュートリソースにセキュリティ要件が課されます。このため、Unity Catalog ではクラスターのアクセスモードの概念が導入されています。 Unity Catalog は default によってセキュリティで保護されています。クラスターが適切なアクセスモードで構成されていない場合、クラスターは Unity Catalog 内のデータにアクセスできません。「 Unity Catalog でサポートされているコンピュートとクラスターのアクセスモード」を参照してください。

Databricks では、クラスターを共有する場合は共有アクセスモードを使用し、自動ジョブと機械学習ワークロードにはシングルユーザーアクセスモードを使用することをお勧めします。

以下のJSONは、共有アクセスモードを使用したクラスターのポリシー定義を提供します：

{
"spark_version": {
    "type": "regex",
    "pattern": "1[0-1]\\.[0-9]*\\.x-scala.*",
    "defaultValue": "10.4.x-scala2.12"
},
"access_mode": {
    "type": "fixed",
    "value": "USER_ISOLATION",
    "hidden": true
}
}

以下のJSONは、シングルユーザーアクセスモードでの自動ジョブクラスターのポリシー定義を提供します。

{
"spark_version": {
    "type": "regex",
    "pattern": "1[0-1]\\.[0-9].*",
    "defaultValue": "10.4.x-scala2.12"
},
"access_mode": {
    "type": "fixed",
    "value": "SINGLE_USER",
    "hidden": true
},
"single_user_name": {
    "type": "regex",
    "pattern": ".*",
    "hidden": true
}
}

監査アクセス

完全なデータガバナンスソリューションには、データへのアクセスを監査し、警告機能と監視機能を提供する必要があります。Unity CatalogはMetastoreに対して実行されたアクションの監査ログをキャプチャし、これらのログはDatabricksの監査ログの一部として配信されます。

システムテーブルを使用してアカウントの監査ログにアクセスできます。監査ログシステムテーブルの詳細については、「監査ログシステムテーブルリファレンス」を参照してください。

Databricks Data Intelligence Platform に関連する重要なイベントを完全に可視化する方法の詳細については、「監査ログを使用した Databricks Data Intelligence プラットフォーム」を参照してください。