HiveテーブルをUnityカタログにアップグレードする方法

このブログでは、Hiveメタストア(HMS)*テーブルをUnityカタログ(UC)にシームレスにアップグレードする方法を、アップグレードするHMSテーブルのバリエーションに応じて異なる方法を使用して、例を挙げて説明します。

*注: Hiveメタストアは、デフォルト、外部メタストア、またはAWS Glue Data Catalogでもかまいません。 簡略化のため、本書では"Hive メタストア" という用語を使用します。

詳細を説明する前に、アップグレードの手順を説明しよう。

1. 評価- このステップでは、アップグレード対象として特定された既存の HMS テーブルを評価し、アップグレードの適切なアプローチを決定します。 このステップについては、このブログで説明します。
2. 作成- このステップでは、メタストア、カタログ、スキーマ、ストレージ資格情報、外部ロケーションなど、必要なUCアセットを作成します。 詳細については、ドキュメント（AWS、Azure、GCP）を参照してください。
3. アップグレード- このステップでは、ガイダンスに従ってテーブルをHMSからUCにアップグレードします。 このステップについては、このブログで説明します。
4. グラント- このステップでは、新しくアップグレードされたUCテーブルのグラントを校長に提供し、校長がUCテーブルにアクセスできるようにする必要があります。 詳細はドキュメントを参照 -AWS、Azure、GCP

現在、3つのクラウドプラットフォーム（AWS、Azure、GCP）すべてで一般的に利用可能なUnity Catalogは、以下の主要機能により、データのセキュリティとガバナンスを簡素化します：

• 一度定義すれば、どこでもセキュアに：Unity Catalogは、すべてのワークスペースに適用されるデータアクセスポリシーを管理するための単一の場所を提供します。
• 標準準拠のセキュリティモデル：Unity Catalogのセキュリティモデルは標準的なANSI SQLに基づいており、管理者は使い慣れた構文を使用して、カタログ、データベース（スキーマとも呼ばれる）、テーブル、およびビューのレベルで、既存のデータレイクに権限を付与することができます。
• 組み込みの監査とリネージ：Unity Catalogは、データへのアクセスを記録するユーザーレベルの監査ログを自動的に取得します。 Unity Catalogは、データ資産がどのように作成され、すべての言語で使用されたかを追跡するリネージデータも取得します。
• データの発見：Unity Catalogでは、データ資産にタグを付けて文書化し、検索インターフェイスを提供して、データ利用者がデータを見つけやすくします。
• システムテーブル（パブリックプレビュー）：Unityカタログを使用すると、監査ログ、請求可能な使用量、履歴など、アカウントの運用データに簡単にアクセスして照会できます。
• データ共有：Delta Sharingは、Databricksが開発したオープンなプロトコルで、使用するコンピューティング・プラットフォームに関係なく、他の組織と安全にデータを共有することができます。 Databricksは、Unity CatalogデータガバナンスプラットフォームにDelta Sharingを組み込み、データプロバイダと呼ばれるDatabricksユーザーが、データレシピエントと呼ばれる組織外の個人やグループとデータを共有できるようにした。

Unity Catalog (UC)ですぐに利用できるこれらの豊富な機能は、現在Hiveメタストアではなかなか利用できません。 さらに、Lakehouse Monitoring、Lakehouse Federation、LakehouseIQなど、Databricksの新機能のほとんど（すべてとは言いませんが）は、Unity Catalogを前提条件として構築され、Unity Catalogによって管理され、Unity Catalogが機能する必要があるため、HMSからUCへのデータ資産のアップグレードを遅らせると、これらの新機能を利用することが制限されます。

したがって、Unity Catalogが提供するすべての豊富な機能を利用できるように、既存のHiveメタストアに登録されているテーブルをUnity Catalogメタストアに簡単にアップグレードするにはどうすればよいかという疑問が浮かびます。 このブログでは、HMSテーブルをUCにアップグレードするための考慮事項や方法論について、例を挙げて説明します。

アップグレードの考慮事項と前提条件

このセクションでは、次のセクションでアップグレードの方法論について詳しく説明する前に、アップグレードに関する考慮事項を確認します。

アップグレードに関する考慮事項

Hive Metastoreテーブルのバリエーションは、そのような考慮事項の1つです。 UnityカタログへのアップグレードとみなされるHiveメタストア テーブルは、以下の表に示す各パラメータのタイプを組み合わせて作成することができます。 たとえば、DBFSルートロケーションを使用してCSVマネージドテーブルを作成したり、Amazon S3ロケーションにParquet外部テーブルを作成したりすることができます。このセクションでは、さまざまなバリエーションのテーブルを作成するためのパラメータについて説明します。

上記のパラメータのバリエーションによって、採用されるアップグレード手法は異なる可能性があります。 詳細については、後述の「アップグレード方法」のセクションで説明します。

Azure DatabricksでHMSテーブルのUCへのアップグレードを開始する前に、もう一点考慮する必要があります：

AZUREクラウドの場合 - Blobストレージ(wasb)またはADLS gen 1(adl)に保存されているテーブルをADLS gen 2(abfs)にアップグレードする必要があります。 サポートされていないAzureクラウドストレージをUnityカタログで使用しようとすると、エラーが発生します。

エラーの例：テーブルはHiveメタストアからUnityカタログへのアップグレードの対象外です。 理由未サポートのファイルシステムスキームです。

アップグレードの前提条件

アップグレードプロセスを開始する前に、以下の手順に従って、ストレージ認証情報と外部ロケーションを作成する必要があります。

1. 対象のクラウドストレージにアクセスできるストレージクレデンシャルを作成します。
2. ストレージ・クレデンシャルを使用して、ターゲット・クラウド・ストレージを指す外部ロケーションを作成します。
   • 外部ロケーションは、UC外部テーブル、マネージド・カタログ、またはマネージド・スキーマを作成するために使用されます。

アップグレードの方法論

このセクションでは、さまざまなアップグレードオプションをマトリックス形式でご紹介します。 また、アップグレードの手順を示す図も使用しています。

アップグレードには、主に2つの方法があります。SYNCを使用する方法（サポートされているシナリオの場合）と、データレプリケーションを使用する方法（SYNCがサポートされていない場合）です。

• SYNCを使用する - サポートされているすべてのシナリオ（以下のアップグレードマトリックスセクションに示されています）では、SYNCを使用してHMSテーブルをUCにアップグレードします。 SYNCを使用することで、データのレプリケーションなしでテーブルをアップグレードすることができます。
• データ・レプリケーションの使用 - サポートされていないすべてのシナリオ（以下のアップグレード・マトリックス・セクションに示されている）では、CTAS（Create Table As Select）またはDEEP CLONE*のいずれかを使用します。 この方法では、データの複製が必要になります。

*注 - HMS ParquetおよびDeltaテーブルのディープクローンを使用して、HMSからUCにデータをコピーし、テーブルをアップグレードすることを検討してください。その他のファイル形式には、Create Table As Select（CTAS）を使用してください。

以下の図では、各手法のアップグレード手順を説明しています。 アップグレードのユースケースにどの方法を使用するかを理解するには、以下のアップグレードマトリックスのセクションを参照してください。

アップグレードの絵画的表現

図1 - SYNCを使用してHMSテーブルをUCにアップグレードする（データ・レプリケーションなし）

ダイアグラム・キー

1. HMSマネージドテーブルと外部テーブルは、クラウドオブジェクトストレージにファイルのディレクトリとしてデータを保存します。
2. SYNCコマンドは、HMSからUCへのテーブル・メタデータのアップグレードに使用される。ターゲットのUCテーブルは、ソースのHMSテーブル・タイプに関係なく外部です。
3. HMSからUCへのテーブルのアップグレードにSYNCコマンドを使用した場合、データはコピーされません。ソースのHMSテーブルで使用されている）同じクラウド・ストレージの場所が、ターゲットのUC外部テーブルで参照されます。
4. ストレージの資格情報は、クラウドテナントの保存データにアクセスするための認証・承認メカニズムです。
5. 外部ロケーションは、クラウド・ストレージ・パスと、そのクラウド・ストレージ・パスへのア クセスを認可するストレージ・クレデンシャルを組み合わせたオブジェクトです。

図2 - データ・レプリケーションでHMSテーブルをUCにアップグレードする

ダイアグラム・キー

1. HMSマネージドテーブルと外部テーブルは、DBFSルートストレージロケーションにファイルのディレクトリとしてデータを保存します。
2. CTASまたはDeep Cloneは、HMSテーブルからUCターゲット・テーブルのメタデータを作成します。 HMSのテーブルタイプに関係なく、外部テーブルまたは管理テーブルにアップグレードすることができます。
3. CTASまたはDeep Cloneは、DBFSルート・ストレージからターゲット・クラウド・ストレージにデータをコピーします。
4. ストレージの資格情報は、クラウドテナントの保存データにアクセスするための認証・承認メカニズムです。
5. 外部ロケーションは、クラウド・ストレージ・パスと、そのクラウド・ストレージ・パスへのア クセスを認可するストレージ・クレデンシャルを組み合わせたオブジェクトです。

アップグレード・マトリックス

以下の表は、HMSテーブルからUCテーブルへのアップグレードの様々な可能性を示している。 各シナリオについて、アップグレードの手順をご紹介します。

DBFSルートストレージを使用したHMSストレージフォーマット

1.注意 - CTASでアップグレードする場合は、デルタに変更することをお勧めします。

HMSハイブ・サーデ・テーブル

2.注 - 基礎となるストレージ形式に関係なく、ハイブ SerDe は同じアップグレードパスに従います。
3.注 -CTAS を使用してアップグレードを行う場合は、Delta に変更することをお勧めします。

DBFSマウントストレージを使用したHMSストレージフォーマット

4.注意 - 外部テーブルへの変換後、HMSテーブルが個別に削除されることを確認してください。HMSデータベース/スキーマがロケーションで定義されており、カスケード・オプションでデータベースがドロップされた場合、基礎となるデータは失われ、アップグレードされたUCテーブルはデータを失います。

クラウド・オブジェクト・ストレージを使用したHMSストレージ・フォーマット

アップグレードの例

このセクションでは、上記の各シナリオの例をDatabricks ノートブックに示します。

まとめ

このブログでは、Hiveメタストア テーブルをUnityカタログ メタストアにアップグレードする方法を紹介しました。 ノートブックを参照して、さまざまなアップグレードオプションをお試しください。 アップグレードプロセスの自動化を開始するには、デモセンターを参照することもできます。 Hive MetastoreテーブルのUnity Catalogへのアップグレードを自動化するには、このDatabricks Labリポジトリの使用をお勧めします。

今すぐテーブルをUnity Catalogにアップグレードして、統合されたガバナンス機能の恩恵を受けましょう。 UCへのアップグレード後、不要になったHiveメタストア スキーマとテーブルは削除できます。 外部テーブルを削除しても、クラウド・テナント上のデータ・ファイルは変更されません。 マネージドテーブルやマネージドテーブルを持つスキーマを削除する際には、（このブログで説明されているような）注意が必要です。

付録

import org.apache.spark.sql.catalyst.catalog.{CatalogTable、
CatalogTableType}
import org.apache.spark.sql.catalyst.TableIdentifier
val tableName ="table"
 val dbName ="dbname"
 val oldTable：CatalogTable =
spark.sessionState.catalog.getTableMetadata(TableIdentifier(tableName、
Some(dbName))
val alteredTable：CatalogTable = oldTable.copy(tableType =
CatalogTableType.EXTERNAL)
spark.sessionState.catalog.alterTable(alteredTable)