次の方法で共有

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

このドキュメントでは、Unity カタログを使用してデータ ガバナンスのニーズを最も効果的に満たすための推奨事項を示します。 Azure Databricks でのデータ ガバナンスの概要については、Azure Databricks を使用したデータ ガバナンスに関するページを参照してください。 Unity カタログの概要については、「 Unity カタログとは」を参照してください。

アイデンティティーズ

Unity Catalog のセキュリティ保護可能なオブジェクトに対する特権を割り当てるには、プリンシパル (ユーザー、グループ、およびサービス プリンシパル) を Azure Databricks アカウント レベルで定義する必要があります。 Databricks では、SCIM を使用して IdP から Azure Databricks アカウントにプリンシパルをプロビジョニングすることをお勧めします。

ベスト プラクティス:

  • ワークスペース レベルの SCIM プロビジョニングを回避 (および既存の SCIM プロビジョニングを無効にする) プリンシパルをワークスペースに直接プロビジョニングすることは、Unity カタログが有効になっていないレガシ ワークスペースに限定すべきです。 プロビジョニングはアカウント レベルで完全に管理する必要があります。

  • IdP でグループを定義および管理します。 これらは組織グループの定義と一致している必要があります。

    グループの動作は、ユーザーやサービス プリンシパルとは異なります。 ワークスペースに追加したユーザーとサービス プリンシパルは、Azure Databricksaccount と自動的に同期されますが、ワークスペース レベルのグループは同期されません。 ワークスペースローカル グループがある場合は、手動でアカウントに移行する必要があります。そのためには、必要に応じて IdP でレプリケートし、アカウントにプロビジョニングします。

  • グループを効果的に使用して、データやその他の Unity カタログのセキュリティ保護可能なリソースへのアクセスを許可できるように、グループを設定します。 可能な限り、ユーザーへの直接付与は避けてください。

  • グループを使用して、セキュリティ保護可能なほとんどのオブジェクトに所有権を割り当てます。

  • アカウントまたはワークスペースにユーザーを手動で追加しないでください。 Azure Databricks でのグループの変更を避ける: IdP を使用します。

  • サービス プリンシパルを使用してジョブを実行します。 サービス プリンシパルにより、ジョブの自動化が有効になります。 ユーザーを使用して運用環境に書き込むジョブを実行すると、誤って運用データが上書きされるリスクがあります。

詳細については、「ユーザー、サービス プリンシパル、グループの管理」および「SCIM を使用して Microsoft Entra ID からユーザーとグループを同期する」を参照してください。

管理者ロールと強力な特権

管理者ロールと、 ALL PRIVILEGES や MANAGE などの強力な特権を割り当てるには、次の注意が必要です。

  • 割り当てる前に、アカウント管理者、ワークスペース管理者、メタストア管理者の特権について理解します。 「Unity Catalog の管理者特権」に関する記事を参照してください。
  • 可能な限り、これらのロールをグループに割り当てます。
  • メタストア管理者は省略可能です。 必要な場合にのみ割り当てます。 ガイダンスについては、「 (省略可能) メタストア管理者ロールを割り当てる」を参照してください。
  • 特にオブジェクトが運用環境で使用されている場合は、オブジェクトの所有権をグループに割り当てます。 任意のオブジェクトの作成者は、最初の所有者です。 作成者は、所有権を適切なグループに再割り当てする必要があります。
  • オブジェクトに対する MANAGE 権限を持つメタストア管理者、所有者、およびユーザーのみが、そのオブジェクトに対する権限を付与できます。 親カタログとスキーマの所有者は、カタログまたはスキーマ内のすべてのオブジェクトに対する権限を付与することもできます。 所有権とMANAGE特権の割り当てをできるだけ控えめに行う。
  • ALL PRIVILEGESを除くすべての特権を含むMANAGEの割り当てを控えてください。

特権の割り当て

Unity Catalog のセキュリティ保護可能なオブジェクトは階層構造であり、権限は下位に継承されます。 この継承階層を使用して、効果的な特権モデルを開発します。

ベスト プラクティス:

  • USE CATALOG (またはUSE SCHEMA) とBROWSEの違いを理解します。

    • USE CATALOG | SCHEMA は、カタログまたはスキーマ内のデータを表示する機能を付与します。 これらの権限だけでは、カタログまたはスキーマ内のオブジェクトに対する SELECT や READ は付与されませんが、アクセス権をユーザーに付与するための前提条件となります。 これらの権限は、カタログまたはスキーマ内のデータを表示できるユーザーにのみ付与します。
    • USE CATALOG | SCHEMAでは、カタログまたはスキーマへのアクセスを制限することで、オブジェクトの所有者 (テーブル作成者など) が、アクセス権を持たないユーザーにそのオブジェクト (テーブル) へのアクセス権を誤って割り当てないようにします。 通常、チームごとにスキーマを作成し、そのチームにのみ USE SCHEMA と CREATE TABLE を付与します (親カタログの USE CATALOG と共に)。
    • BROWSE は、ユーザーがカタログ内のオブジェクトに関連付けられているメタデータを表示できるようにするために、カタログ レベルで幅広く付与できます。

  • オブジェクトの所有権と MANAGE 特権の違いを理解します。

    • オブジェクトの所有者には、テーブルの SELECT や MODIFY など、オブジェクトに対するすべての権限と、セキュリティ保護可能なオブジェクトに対する権限を他のプリンシパルに付与する権限、および他のプリンシパルに所有権を譲渡する権限があります。
    • 所有者は、オブジェクトの所有権を他のプリンシパルに委任する MANAGE 特権を付与できます。
    • カタログとスキーマの所有者は、カタログまたはスキーマ内の任意のオブジェクトの所有権を譲渡できます。
    • 所有権を構成するか、すべてのオブジェクトに対する MANAGE 特権を、オブジェクトの許可の管理を担当するグループに付与することをお勧めします。

  • サービス プリンシパルの実稼働テーブルへの直接 MODIFY アクセスを予約します。

詳細については、「 Unity カタログでの権限の管理」を参照してください。

メタストアーズ

メタストアを作成および管理するための規則とベスト プラクティスを次に示します。

  • 1 つのリージョンに使用できるメタストアは 1 つだけです。 そのリージョン内のすべてのワークスペースは、そのメタストアを共有します。 リージョン間でデータを共有するには、「 リージョン間およびクロスプラットフォーム共有」を参照してください。

  • メタストアはリージョン分離を提供しますが、データ分離の既定の単位としては意図されていません。 通常、データ分離はカタログ レベルで開始されます。 ただし、より一元化されたガバナンス モデルを使用する場合は、メタストア レベルのマネージド ストレージを作成できます。 推奨事項については、「 マネージド ストレージ」を参照してください。

  • メタストア管理者ロールはオプションです。 オプションのメタストア管理者を割り当てるかどうかに関する推奨事項については、「 管理者ロールと強力な特権」を参照してください。

Von Bedeutung

頻繁にアクセスされるテーブルは、複数のメタストアに外部テーブルとして登録しないでください。 その場合、メタストア A への書き込みの結果として発生するスキーマ、テーブルのプロパティ、コメント、およびその他のメタデータに対する変更は、メタストア B にまったく登録されません。Azure Databricks コミット サービスで整合性の問題が発生する可能性もあります。

カタログとスキーマ

カタログは、一般的な Unity Catalog データ ガバナンス モデルにおけるデータ分離の主要な単位です。 スキーマにより、組織のレイヤーが追加されます。

カタログとスキーマの使用に関するベスト プラクティス:

  • データと AI オブジェクトを、組織の部門とプロジェクトを反映するカタログとスキーマに整理します。 多くの場合、これは、カタログが環境スコープ、チーム、部署、またはこれらの組み合わせに対応することを意味します。 これにより、特権階層を使用してアクセスを効果的に管理しやすくなります。
  • 作業環境とデータの両方に同じ分離要件がある場合は、カタログを特定のワークスペースにバインドできます。 これが必要な場合は、限られたワークスペースセットにスコープを設定できるカタログを作成します。
  • 運用カタログとスキーマの所有権は、個々のユーザーではなく、常にグループに割り当てます。
  • USE CATALOGとUSE SCHEMAは、それらに含まれるデータを表示または照会できるユーザーにのみ付与します。

カタログとスキーマに対する権限の付与に関する詳細なアドバイスについては、「 特権の割り当て」を参照してください。

マネージド ストレージ

Unity カタログによってライフサイクルが完全に管理されているオブジェクトであるマネージド テーブルとボリュームは、既定のストレージの場所 ( マネージド ストレージと呼ばれます) に格納されます。 マネージド ストレージは、メタストア、カタログ、またはスキーマ レベルで設定できます。 データは、階層内の使用可能な最も低い場所に格納されます。 詳細については、「 マネージド ストレージの場所の階層 」および 「Unity カタログでのマネージド ストレージの場所の指定」を参照してください。

マネージド ストレージの場所のベスト プラクティス:

  • データ分離のプライマリ ユニットとして、カタログ レベルのストレージを優先します。

    初期の Unity カタログ環境ではメタストア レベルのストレージが必要でしたが、不要になりました。

  • メタストア レベルの管理場所を作成する場合は、専用コンテナーを使用します。

  • Unity カタログの外部からアクセスできるコンテナーは使用しないでください。

    外部のサービスまたはプリンシパルがマネージド ストレージの場所のデータにアクセスし、Unity カタログをバイパスすると、マネージド テーブルとボリュームに対するアクセス制御と監査可能性が損なわれます。

  • DBFS ルート ファイル システムに使用されているコンテナーまたは使用されたコンテナーは再利用しないでください。

  • ストレージを集中的に使用するワークロードがある場合は、マネージド ストレージやその他の外部の場所に 1 つのストレージ アカウントとコンテナーを使用しないでください。

    re:[ADLS] アカウントでは、既定で 1 秒あたり 20,000 要求がサポートされます。 これにより、ワークロードの調整と速度低下が発生する可能性があります。 同じストレージ アカウントで複数のコンテナーを使用しても、このアカウント全体の制限は変更されません。 そのため、ストレージを複数のストレージ アカウントにストライプ化する必要があります。

    このようなストライピングは、Unity カタログのエンドユーザーには見えません。

管理テーブルと外部テーブル

マネージド テーブル は Unity カタログによって完全に管理されます。つまり、Unity カタログは、各マネージド テーブルのガバナンスと基になるデータ ファイルの両方を管理します。 これらは常に Delta または Apache Iceberg 形式です。

外部テーブル とは、Azure Databricks からのアクセスが Unity カタログによって管理されているが、データ ライフサイクルとファイル レイアウトがクラウド プロバイダーやその他のデータ プラットフォームを使用して管理されるテーブルです。 Azure Databricks で外部テーブルを作成するときは、その場所を指定します。この場所は、Unity カタログの 外部の場所で定義されているパス上にある必要があります。

マネージド テーブルを使用する:

  • ほとんどのユースケースのために。 Databricks では、次のような Unity カタログ ガバナンス機能とパフォーマンス最適化を最大限に活用できるため、マネージド テーブルとボリュームをお勧めします。

    • 自動圧縮
    • 自動最適化
    • より高速なメタデータ読み取り (メタデータ キャッシュ)
    • インテリジェントなファイル サイズの最適化

    新しい Azure Databricks 機能により、マネージド テーブルが優先されます。

  • すべての新しいテーブルの場合。

外部テーブルを使用する:

  • 既にそれらを使用していて、Hive メタストアから Unity カタログにアップグレードする場合。

    • 外部テーブルを使用すると、データを移動することなく、迅速かつシームレスな "ワンクリック" アップグレードを実現できます。
    • Databricks では、最終的に外部テーブルをマネージド テーブルに移行することをお勧めします。

  • マネージド テーブルで満たすことができない、このデータのディザスター リカバリー要件がある場合。

    同じクラウド内の複数のメタストアにマネージド テーブルを登録することはできません。

  • 外部リーダーまたはライターが Databricks の外部からデータを操作できる必要がある場合。

    通常は、Unity カタログに登録されている外部テーブルへの外部アクセスを許可しないようにする必要があります。 これにより、Unity カタログのアクセス制御、監査、系列がバイパスされます。 より良い方法として、Delta Sharingを使ってマネージドテーブルを使用し、リージョンやクラウドプロバイダー間でデータを共有することです。 外部テーブルへの外部アクセスを許可する必要がある場合は、Azure Databricks と Unity カタログを介してすべての書き込みが行われ、読み取りに制限します。

  • Parquet、Avro、ORC などの非 Delta テーブルまたは Iceberg 以外のテーブルをサポートする必要があります。

外部テーブルを使用するためのその他の推奨事項:

  • Databricks では、スキーマごとに 1 つの外部場所を使用して外部テーブルを作成することをお勧めします。
  • Databricks では、整合性の問題が発生する可能性があるため、テーブルを複数のメタストアに外部テーブルとして登録しないことを強く推奨します。 たとえば、あるメタストアのスキーマに対する変更は、2 番目のメタストアには登録されません。 メタストア間でデータを共有する場合は、Delta Sharingを使用します。 リージョン間およびクロスプラットフォーム共有を参照してください。

「Azure Databricks テーブルの概要」も参照してください。

マネージド ボリュームと外部ボリューム

マネージド ボリューム は Unity カタログによって完全に管理されます。つまり、Unity カタログは、クラウド プロバイダー アカウント内のボリュームのストレージの場所へのアクセスを管理します。 外部ボリュームは 、Azure Databricks の外部で管理されているが、Azure Databricks 内からのアクセスを制御および監査するために Unity カタログに登録されているストレージの場所にある既存のデータを表します。 Azure Databricks で外部ボリュームを作成するときは、その場所を指定します。この場所は、Unity カタログの 外部の場所で定義されているパス上にある必要があります。

マネージド ボリュームを使用する:

  • ほとんどのユース ケースでは、Unity カタログ のガバナンス機能を最大限に活用します。
  • COPY INTOまたは CTAS (CREATE TABLE AS) ステートメントを実行せずに、ボリューム内のファイルから始まるテーブルを作成する場合。

外部ボリュームを使用する:

  • ETL パイプラインやその他のデータ エンジニアリング アクティビティの初期段階での処理をサポートするために、外部システムによって生成された生データのランディング領域を登録します。
  • 自動ローダー、 COPY INTO、CTAS ステートメントなどを使用して、インジェストのステージング場所を登録します。
  • データ サイエンティスト、データ アナリスト、機械学習エンジニアが探索的データ分析やその他のデータ サイエンス タスクの一部として使用するファイル ストレージの場所を提供します(マネージド ボリュームがオプションではない場合)。
  • Azure Databricks ユーザーに、監視システムまたは IoT デバイスによってキャプチャされた大量の非構造化データ (画像、オーディオ、ビデオ、PDF ファイルなど) や、ローカル依存関係管理システムまたは CI/CD パイプラインからエクスポートされたライブラリ ファイル (JAR と Python ホイール ファイル) など、他のシステムによってクラウド ストレージに生成および保存された任意のファイルへのアクセスを許可します。
  • マネージド ボリュームがオプションではない場合に、ログ記録やチェックポイント 処理ファイルなどの操作データを格納する場合。

外部ボリュームを使用するためのその他の推奨事項:

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

ヒント

データが別の場所にコピーされるインジェストのユース ケース (自動ローダーや COPY INTOを使用するなど) には、外部ボリュームを使用します。 コピーを含まないテーブルとしてデータをクエリする場合は、外部テーブルを使用します。

マネージド ボリュームと外部ボリュームおよび外部の場所も参照してください。

外部の場所

外部の場所のセキュリティ保護可能なオブジェクトは、ストレージ資格情報とストレージ パスを組み合わせることで、ストレージ アクセスの強力な制御と監査を提供します。 Unity カタログによって提供されるアクセス制御をバイパスして、外部の場所として登録されているコンテナーにユーザーが直接アクセスできないようにすることが重要です。

外部の場所を効果的に使用するには:

  • 外部の場所として使用されているコンテナーに直接アクセスできるユーザーの数を制限してください。

  • 外部の場所としても使用されている場合は、ストレージ アカウントを DBFS にマウントしないでください。 Databricks では、 カタログ エクスプローラーを使用して、クラウド ストレージの場所のマウントを Unity カタログの外部の場所に移行することをお勧めします。

  • Unity カタログとクラウド ストレージ間の接続の設定を任されている管理者、または信頼できるデータ エンジニアにのみ外部の場所を作成する権限を付与します。

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

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

    特定のワークスペースにバインドすることで、外部の場所へのアクセスを制御することもできます。 「(省略可能) 外部の場所を特定のワークスペースに割り当てる」を参照してください。

  • 外部の場所に対する一般的な READ FILES や WRITE FILES のアクセス許可をエンド ユーザーに付与しないでください。

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

    表形式以外のデータへのパスベースのアクセスには、ボリュームを使用します。 ボリューム パスの下にあるデータへのクラウド URI アクセスは、ボリュームが格納されている外部の場所で付与された特権ではなく、ボリュームに付与された特権によって制御されます。

    ボリュームを使用すると、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コマンドを使用して、外部テーブルとボリュームを登録します。
  • 場所をマネージド ストレージとして登録します。 CREATE MANAGED STORAGE 特権が前提条件です。
  • 特定のプレフィックスで外部テーブルまたはボリュームを作成する前に、クラウド ストレージ内の既存のファイルを調べる。 READ FILES 特権が前提条件です。 この特権を控えめに割り当てます。 詳細については、前の一覧の推奨事項を参照してください。

外部の場所と外部ボリューム

ボリュームがリリースされる前に、一部の Unity カタログ実装では、データ探索のために外部の場所へのアクセスが直接割り当てられることがありました。 構造化データ、半構造化データ、非構造化データなど、任意の形式でファイルを登録するボリュームが使用可能であるため、テーブル、ボリューム、または管理された場所を作成する以外に外部の場所を使用する本当の理由はありません。 外部の場所を使用するタイミングとボリュームを使用するタイミングの詳細については、「 管理対象ボリュームと外部ボリュームと外部 の場所」を参照してください。

リージョン間およびクロスプラットフォーム共有

1 つのリージョンに使用できるメタストアは 1 つだけです。 異なるリージョンのワークスペース間でデータを共有するには、Databricks-to-Databricks Delta Sharing を使用します。

ベスト プラクティス:

  • 開発、テスト、運用、販売、マーケティングなど、すべてのソフトウェア開発ライフサイクル スコープとビジネス ユニットに対して、単一リージョンのメタストアを使用します。 頻繁な共有データ アクセスを必要とするワークスペースが同じリージョンに配置されていることを確認します。
  • クラウド リージョン間またはクラウド プロバイダー間で Databricks 間の Delta Sharing を使用します。
  • アクセス頻度の低いテーブルにはデルタ共有を使用してください。クラウドリージョン間のエグレス料金は利用者が負担することになります。 リージョンまたはクラウド プロバイダー間で頻繁にアクセスされるデータを共有する必要がある場合は、「 差分共有エグレス コストの監視と管理 (プロバイダーの場合)」を参照してください。

Databricks 間での共有を利用する際には、次の制限事項に注意してください。

  • 系列グラフはメタストア レベルで作成され、リージョンやプラットフォームの境界を越えないでください。 これは、同じ Databricks アカウント内のメタストア間でリソースが共有されている場合でも適用されます。ソースからの系列情報は宛先に表示されません。その逆も同様です。
  • アクセス制御はメタストア レベルで定義され、リージョンやプラットフォームの境界を越えません。 リソースに割り当てられた特権があり、そのリソースがアカウント内の別のメタストアに共有されている場合、そのリソースの特権は宛先共有には適用されません。 共有先で、対象の共有に対する特権を付与する必要があります。

コンピューティング構成

Databricks では、コンピューティング ポリシーを使用して、一連のルールに基づいてクラスターを構成する機能を制限することをお勧めします。 コンピューティング ポリシーを使用すると、Unity カタログ対応クラスター、特に標準アクセス モード (以前の共有アクセス モード) または専用アクセス モード (以前のシングル ユーザーまたは割り当てアクセス モード) を使用するクラスターを作成するようにユーザーを制限できます。

Unity カタログ内のデータにアクセスできるのは、これらのアクセス モードのいずれかを使用するクラスターのみです。 すべてのサーバーレス コンピューティングと DBSQL コンピューティングは、Unity カタログをサポートします。

Databricks では、すべてのワークロードに対して標準アクセス モードが推奨されます。 必要な機能が標準アクセス モードでサポートされていない場合にのみ、専用アクセス モードを使用します。 「アクセス モード」を参照してください。