レガシー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内のテーブルをクエリするには、次の構文を使用します。

SELECT * FROM hive_metastore.schema_name.table_name

注：

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

Hive metastoreのスキーマ

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

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

  • Catalog Explorer を使用して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スキーマの場所を操作するときに次のことを推奨しています。

  • 既にデータが含まれているスキーマの場所を割り当てないでください。

  • スキーマの場所に外部テーブルを作成しないでください。

  • 複数のスキーマ間で場所を共有しないでください。

  • 別のスキーマの場所と重複するスキーマの場所を割り当てないでください。 つまり、別のスキーマの場所の子であるパスは使用しないでください。

  • 外部テーブルの場所と重複するスキーマの場所を割り当てないでください。

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の外部テーブル

が導入される前に で作成されたほとんどのテーブルは、DatabricksUnity 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 機能について説明します。