次の方法で共有

レガシ Hive メタストア内のデータベース オブジェクト

  • [アーティクル]

Azure Databricks のドキュメントでは、Unity Catalogを使用したデータ オブジェクトの操作に重点を置いていますが、ほとんどの手順は、レガシ Hive メタストアに登録されているオブジェクトの操作にも適用されます。

この記事では、レガシ Hive メタストアに登録されているデータベース オブジェクトを操作する方法について説明します。 具体的には、この記事では、Hive メタストア オブジェクトの操作と Unity Catalog オブジェクトの操作の違いについて説明します。 また、予期しない可能性があるその他の動作についても説明します。

Databricks では、すべてのデータをレガシ Hive メタストア から Unity Catalog に移行することを推奨しています。 「Hive のテーブルとビューを Unity Catalog にアップグレードする」を参照してください。

Hive メタストア データ ガバナンスはどのように機能するのか。

Azure Databricksワークスペースには引き続きHiveメタストアが組み込まれていますが、Hiveメタストアを使用したデータガバナンスは非推奨です。 Databricks では、データ ガバナンスに Unity Catalog を使用することをお勧めします。 「Unity Catalog と従来の Hive メタストアの使用」を参照してください。

Unity Catalog のワークスペースを有効にしても、Hiveメタストアに登録済みのデータを操作する機能は低下しません。 レガシ Hive メタストアに登録されているすべてのデータ オブジェクトは、hive_metastore カタログの Unity Catalog インターフェイスに表示されます。 ハイブリッド Hive メタストアと Unity Catalog ワークスペースは、長年使用してきた Hive メタストア ワークスペースを移行するのに便利なモデルです。 ただし、Unity Catalogのデータ ガバナンスとパフォーマンスの利点は高く、できるだけ早くワークスペースを完全に移行する必要があります。

Hive メタストアでは、テーブル Access Control (テーブル ACL) を使用してデータベース オブジェクトへのアクセスを管理します。 共有アクセス モードでコンピューティングを使用する場合、テーブル アクセス制御の一部のサポートは残っています。 「Hive メタストア テーブルのアクセス制御 (レガシ)」を参照してください。

資格情報パススルーは、Hive メタストア データベース オブジェクトのデータ ガバナンスの非推奨のパターンです。 この記事では、資格情報のパススルーについては言及しません。 「資格情報のパススルー (レガシ)」を参照してください。

Note

この記事では、Hive メタストアでのデータ アクセス制御について言及しますが、これは、レガシ テーブルのアクセス制御を指しています。

hive_metastore カタログとはどのようなものですか。

Unity Catalogが有効になっているワークスペースでは、Hive メタストア内のすべてのスキーマは、Unity Catalog の 3 レベル名前空間の hive_metastore カタログの子として表示されます。 Hive メタストアは実際にはカタログを使用しないため、このコンストラクトは、Unity Catalog ユーザー向けのレガシ Hive メタストア内のテーブルへのエントリ ポイントを提供します。 次の構文を使用して、レガシ Hive メタストア内のテーブルにクエリを実行します。

SELECT * FROM hive_metastore.schema_name.table_name

Note

Unity Catalog 対応ワークスペースでは、必要に応じて、ワークスペースの既定値として hive_metastore カタログを設定できます。 「既定のカタログを管理する」を参照してください。

Hive メタストアのスキーマ

レガシ Hive メタストアでは、スキーマはデータ オブジェクト階層の最上位レベルです。

Unity Catalogと Hive メタストアには、次のような重要な違いがあります。　

  • カタログ エクスプローラーを使用して Hive メタストアにスキーマを作成することはできません。 スキーマのアクセス許可を表示および編集できます。
  • Hive メタストアで作成されたスキーマでは、名前に英数字の ASCII 文字とアンダースコアのみを使用できます。
  • Hive メタストアを使用すると、作成時にスキーマの LOCATION を宣言できます。 この機能は、Unity Catalogのマネージド保存場所と同様に機能しますが、動作上の違いは次のとおりです。
    • 場所を指定しない場合は、既定の位置 /user/hive/warehouse/<schema-name> が使用されます。 この場所は DBFS ルート上にあり、生産データの保存には推奨されません。
    • 指定されたパスには、クラウド URI、DBFS ルート、DBFS マウントなど、スキーマを作成するユーザーが使用できる任意のクラウド ストレージの場所を指定できます。
    • 場所へのアクセスは、Hive メタストアによって管理されません。
    • Hive メタストアでスキーマを削除すると、テーブルの種類（管理または外部）に関係なく、そのスキーマの場所内のすべてのファイルが再帰的に削除されます。

データが誤って失われるのを防ぐために、Hive メタストア スキーマの場所を操作する際、Databricks では次のことを推奨しています。

  • データが既に含まれているスキーマの場所を割り当てないでください。
  • スキーマの場所に外部テーブルを作成しないでください。
  • 複数のスキーマ間で場所を共有しないでください。
  • 別のスキーマの場所と重複するスキーマの場所を割り当てしないでください。 つまり、別のスキーマの場所の子であるパスを使用しないでください。
  • 外部テーブルの場所と重複するスキーマの場所を割り当てないでください。

Hive メタストアのマネージド テーブル

Hive メタストアのマネージド テーブルには、Unity Catalog のマネージド テーブルのパフォーマンス上の利点はありません。 Unity Catalog のマネージド テーブルと同様に、Hive メタストア マネージド テーブルでは既定では Delta Lake を使用します。 ただし、Hive メタストアでは、Unity Catalogとは異なり、Azure Databricks でサポートされている他のほとんどのデータ形式を使用してマネージド テーブルを作成することもできます。

Hive メタストアのマネージド テーブルは、常に、スキーマを含む保存場所に作成されます。 マネージド テーブルのクエリに使用するコンピューティングは、保存場所にアクセスできる必要があります。

Hive メタストアでは、Unity Catalog と同様に、マネージド テーブルのデータ レイアウトは管理されません。 Hive メタストアでマネージド テーブルを削除すると、基礎となるすべてのデータ ファイルが直ちに削除されます。 一方、Unity Catalog では、マネージド テーブルを 7 日間 UNDROP でき、データは 30 日以内に完全に削除されます。

パスベースのアクセスを使用して Hive メタストア マネージド テーブルのデータの読み取りまたは書き込みを行うことができますが、Unity Catalog ではその必要はありません。

Hive メタストアの外部テーブル

Unity Catalog の導入前に Azure Databricks で作成されたほとんどのテーブルは、Hive メタストアの外部テーブルとして構成されていました。 外部テーブルを優先する従来の推奨事項は、通常、いくつかの重要な側面に重点を置いていました。

  • クラウド オブジェクト ストレージ内の既存のデータの上に外部テーブルを登録できます。
  • 外部システムから外部テーブルのデータ ファイルに直接アクセスして、読み取りまたは書き込みを行うことができます。
  • テーブルが誤って削除された場合、データ ファイルは削除されませんでした。
  • 外部テーブルには LOCATION が必要であるため、生産データが誤って DBFS ルートに入る可能性は低くなりました。

Azure Databricks では、現在ほとんどの表形式データ ストレージに対して Unity Catalogの管理 テーブルが推奨されるようになりました。 「マネージド テーブルの操作」を参照してください。

Hive メタストアのビュー

Azure Databricks でサポートされている任意のデータ ソースにバックアップされた Hive メタストアでビューを宣言できます。 Unity Catalogでは、外部テーブル、具体化されたビュー、Delta 共有テーブルなど、Unity Catalogのテーブルとビューに対してのみビューを宣言できます。

非表形式のデータソースに対してビューを宣言できるため、非表形式以外のデータ ソースに対してビューを宣言できるため、Hive メタストアのビューは、ユーザー環境の他のアクセス構成と組み合わせて、予期しないアクセスや意図しないデータへのアクセスを許可する可能性があります。

たとえば、次のことを考慮してください。

  • テーブル my_table は、DBFS マウント パス /mnt/my_tableを使用して定義されます。
    • DBFS マウント認証情報はワークスペースに格納されるため、既定ではすべてのユーザーはこのパスにアクセスできます。
  • テーブル ACL は、my_table へのアクセスをユーザーのグループに制限するために使用されます。
    • レガシ テーブル ACL は、共有アクセス モードまたは SQL ウェアハウスで構成されたコンピューティングにのみ適用されます。
  • ビュー my_view は、同じデータ ファイル 'abfss://container-name@storage-account-name.dfs.core.windows.net/my_table' をバックアップするクラウド URI に対して直接定義されます。
    • URI 資格情報は、Spark セッションまたはコンピューティング構成で定義されているアクセス ポリシーに依存します。

ビュー my_view には、次のプロパティがあります。

  • /mnt/my_tableにクラウド オブジェクト ストレージをマウントするために使用される DBFS マウント資格情報は使用されません。
  • コンピューティング構成に関係なく、my_table に設定されているテーブル ACL は尊重されません。
  • 'abfss://container-name@storage-account-name.dfs.core.windows.net/my_table' への読み取りアクセスを提供するコンピューティング用に構成されたデータ アクセス ポリシーが必要です。

Note

これは、あなたが遭遇する可能性のある予期しない動作の一例であり、レガシ Hive メタストアのビューによって提示される潜在的な落とし穴をすべて包括するものではありません。 Databricks では、すべてのビュー定義に Unity Catalog を使用することをお勧めします。

従来の Hive テーブルと HiveQL のサポート

Azure Databricks には、Hive テーブルと HiveQL 機能に関するレガシ サポートがいくつか含まれています。 この機能は、Azure Databricks の初期バージョンとツールの Apache Hadoop エコシステムの名残の部分です。 Databricks では、Hive テーブルやその他の Hive 機能の使用は推奨されませんが、この機能は最適化されておらず、一部のコンピューティング構成ではサポートされていないためです。

次の記事では、従来の Hive 機能について説明します。