メインコンテンツまでスキップ

DatabricksワークスペースをUnity Catalogにアップグレードする

このページでは、Unity Catalogを使用していないワークスペースをUnity Catalogにアップグレードする方法の概要を説明します。また、従来のHive metastore 、 DBFS 、およびサポート対象外のDatabricks Runtimeバージョンからの移行手順も記載されています。

アップグレード手順の概要

Unity Catalog にアップグレードするには、次のことを行う必要があります。

  1. プロビジョニング ID (ユーザー、グループ、サービスプリンシパル) を Databricks アカウントに直接行います (まだ行っていない場合)。 ワークスペース レベルの ID プロビジョニングをオフにします。
  2. ワークスペースローカルグループをアカウントレベルのグループに変換します。Unity Catalog は、アカウント レベルで ID 管理を一元化します。
  3. ワークスペースを Unity Catalog メタストアにアタッチします。ワークスペース リージョンにメタストアが存在しない場合は、アカウント管理者がメタストアを作成する必要があります。
  4. Hive metastore で管理されているテーブルとビューを Unity Catalogにアップグレードします。
  5. アカウントレベルのユーザー、グループ、またはサービスプリンシパルに、アップグレードされたテーブルへのアクセス権を付与します。
  6. クエリとジョブを更新して、古いHive metastore テーブルではなく新しいUnity Catalog テーブルを参照します。
  7. DBFSからファイル、ノートブック、スクリプトを移行します。
  8. アクティブなコンピュート リソースを、サポートされているDatabricks Runtimeバージョンにアップグレードします。
  9. ワークスペース内の旧機能へのアクセスを無効にします。ワークスペースでレガシー機能へのアクセスを無効にする方法については、こちらをご覧ください。

Databricks Labs プロジェクトである UCX には、Unity Catalog が有効化されていないワークスペースを Unity Catalog にアップグレードするのに役立つツールが用意されています。 UCX は、大規模な移行に適しています。 UCX ユーティリティを使用してワークスペースを Unity Catalog にアップグレードするを参照してください。

始める前に

開始する前に、メタストアや管理ストレージなど、Unity Catalog の基本的な概念について理解しておく必要があります。「Unity Catalog とは」を参照してください。

また、次の要件を満たしていることも確認する必要があります。

  • ほとんどのセットアップ手順では、Databricks アカウント管理者である必要があります。その後のタスクで他のアクセス許可要件がある場合は、タスク固有のドキュメントに記載されています。

Unity Catalog デモへのアップグレード

次の短いガイド付きデモを見て、主要なアップグレード タスクの動作を確認してください。各デモでは、特定の手順と、該当する場合は詳細なドキュメントへのリンクが記載されています。

または、デモ「 UCX を使用して Unity Catalog にアップグレードする」に従うこともできます。

アカウントへのユーザー、グループ、サービスプリンシパルのプロビジョン

Unity Catalog はアカウント レベルの ID を参照します。メタストアをワークスペースにアタッチする前に、次の操作を行う必要があります。

  • IdP からワークスペースまでプロビジョニング ユーザー、グループ、およびサービス プリンシパルにSCIM使用している場合は、SCIM をオフにして、代わりにDatabricksアカウントにプロビジョニングを設定します。 「ID プロバイダーからの ID の同期」および「ID」を参照してください。

  • ユーザー、グループ、サービスプリンシパルを管理するように構成されたオートメーション ( SCIM プロビジョニング コネクタや Terraform オートメーションなど) を更新して、ワークスペース エンドポイントではなくアカウント エンドポイントを参照するようにします。 アカウントレベルおよびワークスペースレベルの SCIM プロビジョニングを参照してください。

ワークスペースローカルグループをアカウントレベルのグループに変換する

ワークスペースローカル グループをアカウント グループに移行するを参照してください。

ワークスペースをメタストアにアタッチする

ワークスペースで Unity Catalog が有効になっていない (メタストアに接続されている) 場合、次の手順は、ワークスペース リージョンに Unity Catalog メタストアが既に定義されているかどうかによって異なります。

  • アカウントにワークスペース リージョンに対して Unity Catalog メタストアが既に定義されている場合は、ワークスペースを既存のメタストアに簡単にアタッチできます。Unity Catalog のワークスペースを有効にするに移動します。
  • ワークスペースのリージョンに Unity Catalog メタストアが定義されていない場合は、メタストアを作成してから、ワークスペースをアタッチする必要があります。Unity Catalog メタストアを作成するに移動します。

Hive metastore内のテーブルをUnity Catalogテーブルにアップグレード

ワークスペースが Unity Catalogで有効になる前にサービスに含まれていた場合、ワークスペースには、引き続き使用するデータが含まれている可能性が高い Hive metastore があります。 Databricks では、 Hive metastore によって管理されているテーブルを Unity Catalog メタストアにアップグレードすることをお勧めします。

オプション 1: フェデレートしてからフォーリンテーブルをアップグレードする

推奨されるアプローチは、最初にHive metastoreまたはAWS Glueカタログをフォーリンカタログとしてフェデレーションし、次にその場でフォーリンテーブルをアップグレードすることです。 この 2 段階のプロセスにより、テーブルの履歴、構成、権限、ビューを保持しながら、データを移動せずにテーブルを移行できます。

まず、 Hive metastoreまたはAWS GlueカタログをUnity Catalogのフォーリンカタログとしてフェデレーションします。 これによりUnity Catalogを通じて既存のテーブルにアクセスし、アップグレードの準備をすることができます。

Hive metastore統合する手順については、 Hive metastore統合: Unity Catalogを有効にしてHive metastoreに登録されたテーブルを管理できるようにする」を参照してください。

注記

テーブルをアップグレードせず、フェデレーション カタログを永続的に使用し続けることを選択した場合は、そうすることができます。ただし、Databricks では、Unity Catalog の機能を最大限に活用するためにアップグレードを完了することをお勧めします。

Hive metastoreまたはAWS Glueカタログをフェデレーションした後、データを移動せずにフォーリン テーブルをUnity Catalogテーブルにアップグレードできます。 このワークフローは、テーブルの履歴、構成、権限、およびビューを保持しながら、テーブルをその場でアップグレードします。

フォーリンテーブルをUnity Catalogマネージドテーブルにアップグレードするには、次のコマンドを実行します。

SQL
ALTER TABLE <foreign_catalog>.<schema>.<table_name> SET MANAGED;

Databricks 、自動メンテナンス (圧縮、クラスタリング、 vacuum ) とパフォーマンスの向上を含むUnity Catalog予測的最適化のロックを解除するために、マネージド テーブルにアップグレードすることをお勧めします。 代わりにフォーリンテーブルをUnity Catalog外部テーブルにアップグレードするには、次のコマンドを実行します。

SQL
ALTER TABLE <foreign_catalog>.<schema>.<table_name> SET EXTERNAL;

テーブルが移行され、外部カタログへのフェデレーションに依存しなくなったら、接続を削除できます。

SQL
ALTER CATALOG <foreign_catalog> DROP CONNECTION;

このワークフローの詳細については、 「フォーリンテーブルをマネージドUnity Catalogテーブルに変換する」を参照してください。

オプション2: テーブルを直接アップグレードする

フェデレーションベースのアップグレード ワークフローを使用しない場合は、 SYNCまたはCREATE TABLE AS SELECTを使用してテーブルを直接アップグレードできます。「Hive テーブルとビューを Unity Catalog にアップグレードする」を参照してください。

アップグレードされたテーブルまたはフェデレーテッドテーブルへのアクセスの許可

アカウントレベルのユーザー、グループ、またはサービスプリンシパルに、新しいテーブルへのアクセス権を付与します。Unity Catalog での特権の管理を参照してください。

アップグレードされたテーブルとデータへのパスを操作するためのクエリとジョブの更新

ワークスペースローカルHive metastoreからUnity Catalogに移行している間も、Hive metastoreに登録されているデータを参照するクエリとジョブを引き続き使用できます。 Hive metastoreフェデレーション(推奨) またはUnity Catalogと併用したレガシHive metastore システム の操作で説明されている構文を使用します。ただし、最終的には、Unity Catalog のテーブルと構文を使用するようにすべてのクエリとジョブを更新する必要があります。

同様に、ファイルへのパスベースのアクセスを使用するクエリとジョブを更新して、代わりに Unity Catalog ボリューム を使用します。

詳細な推奨事項については、「 従来のワークスペースを Unity Catalog にアップグレードするときにジョブを更新する」を参照してください。

DBFSへのアクセスを無効にする

Unity Catalog移行の一環として、 Databricksワークスペース内のDBFSへのアクセスを無効にすることをお勧めします。 これにより、すべてのデータと がUnity Catalogによって管理され、 Unity Catalog機能を最大限に活用できるようになります。

Databricks Labs のDBFSスキャナ スクリプトを使用して、現在のDBFS使用状況をスキャンし、資産を所定の場所に登録するか (外部ロケーションを使用)、 Unity Catalogに移行するか、不要になった場合はアーカイブするかを決定できます。 Databricks Labs は、 Databricksによって直接サポートされていないパブリックGitHubリポジトリです。

以下のセクションでは、 DBFSからUnity Catalogへさまざまなアセットを移行する方法について説明します。

DBFSに保存されているファイルを移行する

Parquet 、 CSV 、 JSON 、イメージなどの生ファイルがDBFSルート (たとえば、 /FileStoreまたは他のDBFSルート ディレクトリの下) またはDBFSにマウントされたクラウド ストレージ ( /mnt/...の下) に保存されている場合は、 Unity Catalogボリュームを使用してそれらのファイルを移行し、外部ロケーションを使用してアクセスします。

以下は、 DBFSからUnity Catalogボリュームにファイルを移行する方法について説明します。 ボリュームとワークスペース ファイルを使用する場合の詳細については、 「ボリューム内のファイルとワークスペース ファイルの推奨事項」を参照してください。

ステップ 1: 外部位置をセットアップする

Unity Catalogにアセットを登録するには、ファイルが現在存在するクラウド ストレージ コンテナまたはパスのUnity Catalog外部ロケーションを設定します。 これを行うには、カタログ エクスプローラー、 SQLコマンド、 Terraform 、またはDatabricks CLIを使用します。

詳細な手順については、 「Unity Catalog を使用してクラウドオブジェクトストレージに接続する」を参照してください。

ステップ 2: ボリュームを作成する

Unity Catalogボリュームは、ファイルを整理するための体系的な方法を提供する。 Databricksは、すべての非表形式データを管理するためにボリュームを使用することを推奨しています。外部ロケーションのサブパスを参照するスキーマ内に外部ボリュームを作成できます。例えば:

SQL
USE CATALOG main;
USE SCHEMA data;
CREATE VOLUME IF NOT EXISTS raw_files
LOCATION 'my_data_loc/csv-files/';

そのパスの下にあるすべてのファイルは、外部ロケーションを通じてアクセスできるようになり、 Unity Catalog権限によって管理されるようになります。

詳細については、 Unity Catalogボリュームとは?」を参照してください。

ステップ 3: DBFSルートからファイルをコピーする

ファイルが以前DBFSルートに保存されていた場合は、クラウドストレージのパスにコピーしてください。例えば、ノートブックでは:

Python
dbutils.fs.cp(
"dbfs:/FileStore/tables/data.csv",
"/Volumes/main/data/raw_files/data.csv"
)
ヒント

ファイル数が非常に多い場合、またはファイルサイズが数GBを超える場合は、Databricks CLIを使用するか、Apache Sparkを使用した分散コピーによって移動を並列化することを検討してください。Databricks CLI fs cpコマンドはディレクトリを再帰的にコピーできます。

ステップ 4: 移行されたファイルを確認する

移行後、標準コマンドを使用してボリュームからファイルを一覧表示および読み取ります。

Python
# List files in the volume
dbutils.fs.ls("/Volumes/main/data/raw_files/")

# Read a CSV file into a DataFrame
df = spark.read.option("header", True).csv(
"/Volumes/main/data/raw_files/2024-01-01-data.csv"
)

このコードには、ボリュームまたは外部ロケーションに対する適切なUnity Catalog権限と、 Unity Catalogサポートするコンピュート リソースが必要です。 Unity Catalog は、ファイルを読み取るプリンシパルがボリュームまたは外部ロケーションに対してREAD権限を持っていることを強制します。

ステップ 5: DBFSマウントをクリーンアップする

新しい場所にあるファイルにアクセスできることを確認したら、混乱や誤使用を防ぐため、古いDBFSマウントポイントをアンマウントしてください。

Python
dbutils.fs.unmount("/mnt/oldpath")

DBFSルートのデータが移動された場合は、そのデータをロックダウンまたは削除することを検討してください。コピーを残しておくと、更新の不整合やセキュリティリスクにつながる可能性があります。

DBFSからワークスペースアセットを移行する

一部のワークスペースには、ノートブック、コードファイル、または参照スクリプトがDBFSに保存されています。これらには以下が含まれる可能性があります。

  • ノートブックは共有用に/FileStoreにHTMLまたはDBCファイルとして保存されます。
  • Databricksジョブで使用されるPythonスクリプトまたはJARファイル
  • コンピュートスコープの init スクリプト (例: dbfs:/databricks/init/... )

ノートブックとコードは、DBFSではなく、ワークスペースファイルまたはGitフォルダに保存する必要があります。DBFSはファイルごとのアクセス制御を提供しないため、ソースコードやノートブックには使用しないでください。

  • ノートブック : DBFS上にファイルとしてノートブックがある場合は、それらをDatabricksワークスペースにインポートします。 これは、UIのインポート機能を使用するか、CLIを使用して手動で行うことができます。ワークスペース内のノートブックのアクセス許可が、チームアクセス用に適切に設定されていることを確認してください。今後は、ノートブックをワークスペースオブジェクトまたはGitフォルダに保存し、バージョン管理にはGitを使用してください。
  • ジョブ スクリプト : DBFSからPythonスクリプトを実行するようにジョブが構成されている場合 (たとえば、タスク タイプがdbfs:/mnt/scripts/my_etl.pyを参照する「 Pythonスクリプト」のジョブ)、それらのスクリプトをワークスペース ファイルに移動します。 バージョン管理と変更履歴の追跡のために、それらをGitフォルダで管理してください。
  • アーティファクトとライブラリのビルド : JARファイルやPythonホイールなどのアセットは、 Unity Catalogボリュームに保存する必要があります。
  • コンピュート スコープの init スクリプト : コンピュート スコープの init スクリプトはUnity Catalogボリュームに保存する必要があります。 「init スクリプトとは何ですか?」を参照してください。 。

コンピュートを見つけて、サポートされているDatabricks Runtimeバージョンとアクセス モードに移行する

注記

このセクションには、 system.compute.clustersテーブルにアクセスするクエリが含まれています。このシステム テーブルにアクセスするには、 Databricksアカウント管理者であるか、 computeシステム スキーマに対するUSEおよびSELECT権限を付与されている必要があります。 システムテーブルへのアクセス権の付与を参照してください。

Unity Catalog移行の一環として、 DatabricksすべてのコンピュートとジョブをDatabricks Runtime 13.3 LTS以降にアップグレードし、 Unity Catalogアクセス モードを使用することをお勧めします。

ワークスペースのコンピュートを手動で確認するには、ワークスペースの コンピュート ページに移動します。 [汎用コンピュート] セクションで、各コンピュートのDatabricks Runtimeバージョンを確認します。 バージョンで並べ替えまたはフィルタリングして、バージョン13.3 LTSより前のバージョンを実行しているクラスターを特定します。特定のDatabricks Runtimeバージョンを使用するようにジョブを構成することもできるため、 ジョブのコンピュート セクションでもこの手順を繰り返します。

13.3 LTSより前のバージョンを実行しているコンピュートをプログラムで検索するには、 system.compute.clustersテーブルをクエリします。 例えば:

SQL
SELECT
workspace_id,
cluster_id,
dbr_version
FROM system.compute.clusters
WHERE
TRY_CAST(SPLIT(dbr_version, '\\.')[0] AS INT) < 13
OR (
TRY_CAST(SPLIT(dbr_version, '\\.')[0] AS INT) = 13
AND TRY_CAST(SPLIT(dbr_version, '\\.')[1] AS INT) < 3
);

これにより、13.3 LTSより前のバージョンを実行している汎用コンピュートおよびジョブ コンピュート リソースのリストが返されます。

コンピュートをサポートされているアクセス モードにアップグレードする

まだ非分離共有アクセス モードでコンピュートを実行している場合は、サポートされているアクセス モードにアップグレードできます。 アクセスモードを参照してください。非分離共有アクセス モードで実行されているコンピュートをクエリするには、 system.compute.clustersテーブルをクエリします。 例えば:

SQL
SELECT
workspace_id,
cluster_id,
dbr_version,
data_security_mode
FROM system.compute.clusters
WHERE data_security_mode IN ('NONE','NO_ISOLATION')
LIMIT 100;

ワークスペースでレガシー機能へのアクセスを無効にする

上記の移行ステップを完了したら、ワークスペースの従来の機能へのアクセスを無効にすることができます。