メインコンテンツまでスキップ
に最終更新

ストレージ・パスの競合を解決する

ストレージ パスの競合は、外部の場所がDatabricksアカウント内のいずれかのワークスペースのUnity Catalogストレージ パスと重複する場合に発生します。 この重複により、 Unity Catalogの一部の機能の内部処理が妨げられます。 アカウントのストレージパスに競合が発生している場合は、外部ロケーションの設定を更新する必要があります。

Unity Catalogロケーションが作成されたワークスペースだけでなく、 Databricksアカウントに登録されているすべてのストレージ構成に対して外部ロケーションを検証します。 その結果、同じアカウント内の複数のワークスペースが同じバケットを共有している場合、競合が発生する可能性があります。

競合の発生方法​

アカウント内のワークスペースの仮想Unity Catalogストレージ パスと重複する外部ロケーションを作成または更新すると、競合が発生します。 このデフォルトパスは、従来のワークスペース展開時にストレージ構成オブジェクトを使用して設定されます。ストレージ構成の作成を参照してください。例えば：

  • ワークスペースの作成に使用されるデフォルトのワークスペースストレージパス: s3://<your-bucket>/<region>/
  • 外部ロケーションの重複(競合): s3://<your-bucket>/

この重複により、Unity Catalogはワークスペースのストレージ場所を内部処理に使用できなくなり、Unity Catalogの一部の機能がブロックされます。内部ワークスペース データが外部ロケーションによって公開される可能性があるため、重複があるとデータガバナンスも弱まります。 したがって、外部ロケーション パスは、アカウント内のワークスペースのいずれかのUnity Catalogストレージ パスと重複してはなりません。

ただし、 DBFSルートの場所など、ワークスペースのストレージ パスの下のより具体的なパスに外部ロケーションを作成することもできます。 これは、 DBFSルートの場所がワークスペースの内部ストレージ パスの兄弟であり、競合が発生しないためです。

シナリオを特定する​

Databricks UI の カタログエクスプローラー で外部ロケーションを確認し、外部ロケーションパスにワークスペースのデフォルトストレージパスが含まれているか、それよりも広いかどうかを確認します。
例：

  • 外部ロケーション: s3://<your-bucket>/
  • ワークスペースのデフォルトのストレージパス: s3://<your-bucket>/<region>/

続行方法を決定するために、次のシナリオを検討してください。

シナリオ A: データを移動せずに外部ロケーションを更新する​

外部ロケーションは広範なパス ( s3://<customer-bucket>/など) で定義しますが、アクセスするデータは、より具体的な兄弟フォルダー ( s3://<customer-bucket>/<region>/<workspace-id>/に保存されている従来のDatabricksファイル システム データなど) にあります。

処置: (推奨) 既存の外部ロケーションをより具体的なパスに更新します。この変更により、競合が解決され、すべてのデータへのアクセスが引き続き許可されます。たとえば、パスを s3://<your-bucket>/ から s3://<your-bucket>/<region>/<workspace-id>/に更新します。これにより、ワークスペースの内部データの偶発的なデータ漏洩も防止されます。

シナリオ B: ルートバケットの場所に格納されているマネージドテーブル​

バケットのルートに外部ロケーション ( s3://<your-bucket>/など) を定義し、その直下にマネージドテーブル ( s3://<your-bucket>/__unity_storage/catalogs/<catalog_id>/tables/<table_id>など) を作成します。

この場合、パスの更新はできません。マネージドテーブルを新しい場所に移行する必要があります。

重要

以下のステップは推奨される手順であり、完全または保証された移行プランではありません。すべてのオブジェクトタイプ (例: ボリュームや登録済みモデル) やすべてのワークロードパターンは考慮されていません。移行の計画と検証はご自身の判断で行い、ご使用の環境に固有の問題については Databricks アカウントチームにご相談ください。

アクション: 競合を解決するために、以下のステップを完了します。

  1. 影響を受けるすべてのマネージドテーブルを特定します。メタストア管理者として、system.information_schema.tablesをクエリーして、すべてのカタログのマネージドテーブルの完全なリストを取得します：

    SQL
    SELECT table_catalog, table_schema, table_name
    FROM system.information_schema.tables
    WHERE table_type = 'MANAGED';

  2. 新しいメタストアのルートサブディレクトリを選択します。既存の内部ストレージパス（__unity_storageを含むパス）の親でないパスを選択します。例えば、s3://<your-bucket>/uc-root/。

  3. メタストアのマネージドストレージロケーションを更新します。既存のメタストアにマネージドストレージを追加するを参照してください。新しいマネージドテーブルは、この更新後に新しい場所に保存されます。既存のマネージドテーブルは自動的に移動されません。

  4. 移行する前に、影響を受ける各テーブルの特権付与をバックアップしてください。すべての権限が表示されるように、これをテーブルの所有者またはメタストア管理者として実行します：

    SQL
    SHOW GRANTS ON TABLE <catalog>.<schema>.<table_name>;

  5. 影響を受けるテーブルの読み取りまたは書き込みを行うすべてのワークロードを停止し、移行期間中はワークロードや管理者がそれらの権限を変更しないことを確認してください。テーブルをクローンした後に発生する書き込みまたは付与の変更はキャプチャされず、データの損失につながる可能性があります。

  6. 影響を受ける各テーブルを新しいマネージドストレージの場所で再作成します。Delta Lake テーブル履歴を保持するには、DEEP CLONE を使用します。

    SQL
    -- Recommended: deep clone preserves Delta history
    CREATE TABLE <catalog>.<schema>.<table_name>
    DEEP CLONE <old_catalog>.<schema>.<table_name>;

  7. 再作成されたテーブルにすべての権限を再適用してください：

    SQL
    GRANT <privilege> ON TABLE <catalog>.<schema>.<table_name> TO <principal>;

  8. 再作成されたテーブルを参照するように、すべての下流のワークロード (ジョブ、ノートブック、ダッシュボード) を更新します。切り替える前に、データリネージを使用して依存するワークロードを特定します。再作成されたテーブルを指すようになってからのみ、ワークロードを再開します。

  9. 再作成されたテーブルを確認し、その後、古いテーブルを削除します。

  10. シナリオAに記載されているように、外部ロケーションをより具体的で競合しないパスに更新します。

このページの見出し