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

Databricksドキュメントは、 Unity Catalogを使用したデータオブジェクトの操作に焦点を当てていますが、ほとんどの手順は、従来の Hive metastoreに登録されているオブジェクトの操作にも適用されます。

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

Databricks では、すべてのデータを従来の Hive metastore から Unity Catalogに移行することをお勧めします。 「Hive のテーブルとビューを Unity Catalog にアップグレードする」を参照してください。

Hive metastoreデータガバナンスはどのように機能しますか?

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

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

Hive metastore では、テーブルアクセスコントロール (テーブル ACL) を使用して、データベースオブジェクトへのアクセスを管理します。 標準アクセスモードでコンピュートを使用する場合、テーブルアクセスコントロールは一部のサポートが残ります。 「Hive metastore テーブルアクセスコントロール (レガシー)」を参照してください。

注記

この記事で Hive metastoreのデータアクセス制御に言及している場合、従来のテーブルアクセスコントロールを参照しています。

hive_metastore カタログとは何ですか？

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

SQL

SELECT * FROM hive_metastore.schema_name.table_name

注記

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

Hive metastoreのスキーマ

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

Unity CatalogとHive metastoreの間には、次のような重要な違いがいくつかあります。

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

偶発的なデータ損失を避けるために、 Databricks では、 Hive metastore スキーマの場所で作業するときに次のことをお勧めします。

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

マネージドテーブル in Hive metastore

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

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

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

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

Hive metastore の外部テーブル

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

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

Databricks では Unity Catalog ほとんどの表形式データ ストレージにマネージドテーブルを推奨しています。 「マネージドテーブルの操作」を参照してください。

Hive metastoreのビュー

Hive metastoreでサポートされている任意のデータソースを基に、Databricks でビューを宣言できます。Unity Catalogでは、フォーリンテーブル、マテリアライズド ビュー、 Delta Sharing テーブルなどを含むUnity Catalogテーブルとビューに対してのみビューを宣言できます。

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

たとえば、次のことを考えてみます。

• テーブル my_table は、DBFS マウント・パス /mnt/my_tableを使用して定義します。

  • DBFS マウント資格情報はワークスペースに格納されるため、すべてのユーザーはデフォルトによってこのパスにアクセスできます。

• テーブル ACL は、 my_table へのアクセスをユーザーのグループに制限するために使用されます。

  • レガシ テーブル ACL は、標準アクセス モードまたはウェアハウス SQLコンピュートにのみ適用されます。

• ビュー my_view は、同じデータ ファイル ( 'gs://bucket/path/to/my_table') をサポートするクラウド URI に対して直接定義されます。

  • URI 資格情報は、 Spark セッションまたはコンピュート構成で定義されたアクセス ポリシーに依存します。

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

• クラウドオブジェクトストレージを /mnt/my_tableにマウントするために使用されるDBFSマウント資格情報は使用しません。
• コンピュートの設定に関係なく、 my_tableに設定されたテーブル ACL は考慮されません。
• これには、 コンピュート に設定されたデータ アクセス ポリシー が必要であり、 'gs://bucket/path/to/my_table'への読み取りアクセスを提供する必要があります。

注記

これは、発生する可能性のある予期しない動作の一例であり、従来の Hive metastoreのビューによって提示される可能性のあるすべての落とし穴を包括的に解決するものではありません。 Databricks では、すべてのビュー定義に Unity Catalog を使用することをお勧めします。

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

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

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

• Apache Hive の互換性
• Hive 形式で CREATE TABLE
• INSERT OVERWRITE DIRECTORY を Hive 形式で使用
• データの読み込み
• Hive UDF、UDAFs、および UDTF との統合