Databricks レイクハウスのデータ オブジェクト

  • [アーティクル]

Databricks レイクハウスは、データベース、テーブル、ビューなどの使い慣れた関係を使用して、クラウド オブジェクト ストレージに Delta Lake と共に格納データを整理します。 このモデルは、エンタープライズ データ ウェアハウスの多くの利点と、データ レイクのスケーラビリティと柔軟性を組み合わせています。 このモデルのしくみと、オブジェクト データとメタデータの関係について詳しく説明します。これにより、組織は Databricks レイクハウスを設計および実装する際にベスト プラクティスを適用できます。

Databricks レイクハウスに存在するデータ オブジェクトは?

Databricks レイクハウスのアーキテクチャでは、クラウド オブジェクト ストレージ内の Delta Lake プロトコルと格納データを、メタストアに登録されたメタデータと組み合わせます。 Databricks レイクハウスには、次の 5 つの主要なオブジェクトがあります:

  • カタログ: データベースのグループ。
  • データベースまたはスキーマ: カタログ内のオブジェクトのグループ。 データベースには、テーブル、ビュー、関数が含まれています。
  • テーブル: オブジェクト ストレージにデータ ファイルとして保存されている行と列のコレクション。
  • ビュー: 通常、1 つ以上のテーブルまたはデータ ソースに対して保存されたクエリ。
  • 関数: スカラー値または行のセットを返す保存されたロジック。

Unity Catalog object model diagram

Unity カタログを使用してオブジェクトをセキュリティで保護する方法については、セキュリティ保護できるオブジェクト モデルを参照してください。

メタストアとは

メタストアには、レイクハウス内のデータ オブジェクトを定義するすべてのメタデータが含まれています。 Azure Databricks には、次のメタストア オプションが用意されています。

  • Unity Catalog メタストア: Unity Catalog は、一元化されたアクセス制御、監査、系列、およびデータ検出の機能を提供します。 Unity Catalog メタストアは Azure Databricks アカウント レベルで作成し、1 つのメタストアを複数のワークスペースで使用できます。

    各 Unity Catalog メタストアは、Azure アカウント内の Azure Data Lake Storage Gen2 コンテナー内のルートの保存場所を使用して構成されます。 この保存場所は、マネージド テーブルのデータの保存に既定で使用されます。

    既定では、Unity Catalog のデータはセキュリティ保護されています。 初期状態では、ユーザーはメタストア内のデータにアクセスできません。 アクセス権は、メタストア管理者またはオブジェクトの所有者が付与できます。 Unity カタログのセキュリティ保護可能なオブジェクトは階層構造であり、権限は下位に継承されます。 Unity Catalog には、データ アクセス ポリシーを管理するための単一の場所が用意されています。 ユーザーは、メタストアがアタッチされている任意のワークスペースから Unity Catalog のデータにアクセスできます。 詳細については、「Unity Catalog の特権の管理」を参照してください。

  • 組み込みの Hive メタストア (レガシ): 各 Azure Databricks ワークスペースには、組み込みの Hive メタストアがマネージド サービスとして含まれています。 メタストアのインスタンスは、各クラスターにデプロイされ、各顧客ワークスペースの中央リポジトリからメタデータに安全にアクセスします。

    Hive メタストアは、Unity Catalog よりも一元化度合いが低いデータ ガバナンス モデルを提供します。 既定では、クラスターは、そのクラスターに対してテーブル アクセス制御が有効になっていない限り、ワークスペースの組み込みの Hive メタストアによって管理されているすべてのデータへのアクセスをすべてのユーザーに対して許可します。 詳細については、「Hive メタストア テーブルのアクセス制御 (レガシ)」を参照してください。

    テーブル アクセス制御はアカウント レベルでは保存されないため、ワークスペースごとに個別に構成する必要があります。 Unity Catalog によって提供される一元化され合理化されたデータ ガバナンス モデルを利用するために、Databricks では、ワークスペースの Hive メタストアによって管理されるテーブルを Unity Catalog メタストアにアップグレードすることをお勧めします。

  • 外部 Hive メタストア (レガシ): Azure Databricks で独自のメタストアを使用することもできます。 Azure Databricks クラスターは、既存の外部 Apache Hive メタストアに接続できます。 テーブル アクセス制御を使用して、外部メタストアのアクセス許可を管理できます。 テーブル アクセス制御は外部メタストアには保存されないため、ワークスペースごとに個別に構成する必要があります。 Databricks では、ガバナンス モデルがシンプルでアカウント中心である Unity Catalog を代わりに使用することをお勧めします。

使用するメタストアに関係なく、Azure Databricks は、すべてのテーブル データをクラウド アカウントのオブジェクト ストレージに保存します。

カタログとは

カタログは、Databricks レイクハウスのリレーショナル モデルにおける最も高い抽象化 (または最高粒度) です。 すべてのデータベースがカタログに関連付けられます。 カタログはメタストア内のオブジェクトとして存在します。

Azure Databricks では、Unity カタログの導入前に 2 層名前空間を使用しました。 カタログは、Unity カタログ名前空間モデルの第 3 層です。

catalog_name.database_name.table_name

組み込みの Hive メタストアでは、1 つのカタログ (hive_metastore) のみがサポートされます。

データベースとは

データベースは、テーブルやビュー ("リレーション" とも呼ばれます) や関数などのデータ オブジェクトのコレクションです。 Azure Databricks では、"スキーマ" と "データベース" という用語が同じ意味で使用されます (一方、多くのリレーショナル システムにおいて、データベースはスキーマのコレクションです)。

データベースは常にクラウド オブジェクト ストレージ上の場所に関連付けられます。 必要に応じて、次の点に留意しながらデータベースの登録時に LOCATION を指定できます。

  • データベースに関連付けられている LOCATION は常に、管理されている場所と見なされます。
  • データベースを作成しても、ターゲットの場所にファイルは作成されません。
  • データベースの LOCATION によって、そのデータベースに登録されているすべてのテーブルのデータの既定の場所が決まります。
  • データベースを正常に削除すると、管理されている場所に格納されているすべてのデータとファイルが再帰的に削除されます。

データベースによって管理される場所とデータ ファイルとの間のこの相互作用は非常に重要です。 誤ってデータを削除しないようにするため、

  • 複数のデータベース定義間でデータベースの場所を共有しないでください。
  • データが既に含まれている場所にデータベースを登録しないでください。
  • データベースとは別にデータ ライフ サイクルを管理するには、データベースの場所の下にある入れ子になっていない場所にデータを保存します。

テーブルとは

Azure Databricks テーブル は、構造化データのコレクションです。 Delta テーブルは、クラウド オブジェクト ストレージ上のファイルのディレクトリとしてデータを格納し、カタログとスキーマ内のメタストアにテーブル メタデータを登録します。 Delta Lake は Azure Databricks で作成されたテーブルの既定のストレージ プロバイダーであるため、既定では Databricks で作成されるすべてのテーブルが Delta テーブルです。 Delta テーブルはクラウド オブジェクト ストレージにデータを格納し、メタストアを介してデータへの参照を提供するため、組織のすべてのユーザーは優先 API を使用してデータにアクセスできます。Databricks では、このデータには SQL、Python、PySpark、Scala、R が含まれます。

Databricks には Delta テーブル以外のテーブルを作成できます。 これらのテーブルは Delta Lake によってサポートされておらず、DELTA テーブルの ACID トランザクションと最適化されたパフォーマンスは提供されません。 このカテゴリに分類されるテーブルには、外部システムのデータに対して登録されたテーブルと、データ レイク内の他のファイル形式に対して登録されたテーブルが含まれます。 データ ソースへの接続に関するページを参照してください。

Databricks には、マネージド テーブルとアンマネージド テーブル (または外部テーブル) の 2 種類のテーブルがあります。

注意

Delta ライブ テーブルのライブ テーブルとストリーミング ライブ テーブルの違いは、テーブルの観点からは適用されません。

マネージド テーブルとは

Azure Databricks は、マネージド テーブルのメタデータとデータの両方を管理します。テーブルを削除すると、基になるデータも削除されます。 データ アナリストや、主に SQL で作業する他のユーザーは、この動作を好む場合があります。 マネージド テーブルは、テーブルの作成時の既定値です。 マネージド テーブルのデータは、そのデータが登録されているデータベースの LOCATION に存在します。 データの場所とデータベースの間のこのマネージド リレーションシップのため、管理テーブルを新しいデータベースに移動するには、すべてのデータを新しい場所に書き換える必要があります。

マネージド テーブルは、次のようなさまざまな方法で作成できます。

CREATE TABLE table_name AS SELECT * FROM another_table

CREATE TABLE table_name (field_name1 INT, field_name2 STRING)

df.write.saveAsTable("table_name")

アンマネージド テーブルとは

Azure Databricks は、アンマネージド (外部) テーブルのメタデータのみを管理します。テーブルを削除しても、基になるデータには影響がありません。 アンマネージド テーブルは、テーブルの作成時に常に LOCATION を指定します。データ ファイルの既存のディレクトリをテーブルとして登録することも、テーブルが最初に定義されるときにパスを指定することもできます。 データとメタデータは個別に管理されるため、データを移動することなく、テーブルの名前を変更したり、新しいデータベースに登録したりできます。 データ エンジニアは多くの場合、アンマネージド テーブルと、運用データに対して提供される柔軟性を優先します。

アンマネージド テーブルは、次のようなさまざまな方法で作成できます。

CREATE TABLE table_name
USING DELTA
LOCATION '/path/to/existing/data'

CREATE TABLE table_name
(field_name1 INT, field_name2 STRING)
LOCATION '/path/to/empty/directory'

df.write.option("path", "/path/to/empty/directory").saveAsTable("table_name")

ビューとは

ビューには通常、メタストア内の 1 つ以上のデータ ソースまたはテーブルに対するクエリのテキストが格納されます。 Databricks では、ビューはデータベース内のオブジェクトとして永続化された Spark DataFrame と同等です。 DataFrame とは異なり、Databricks 製品の任意の部分のビューに対してクエリを実行できます。これを行うアクセス許可があるとします。 ビューを作成しても、データが処理されたり書き込まれたりすることはありません。関連付けられたデータベース内のメタストアに登録されるのは、クエリ テキストのみです。

一時ビューとは

一時ビューのスコープと永続化には制限があり、スキーマまたはカタログには登録されません。 一時ビューの有効期間は、お使いの環境によって異なります。

  • ノートブックとジョブでは、一時ビューのスコープはノートブックまたはスクリプト レベルになります。 これらは、宣言されているノートブックの外部では参照できず、ノートブックがクラスターからデタッチされると存在しなくなります。
  • Databricks SQL では、一時ビューのスコープはクエリ レベルになります。 同じクエリ内の複数のステートメントで一時ビューを使用できますが、同じダッシュボード内であっても、他のクエリで参照することはできません。
  • グローバル一時ビューのスコープはクラスター レベルになり、コンピューティング リソースを共有するノートブックまたはジョブ間で共有できます。 Databricks では、グローバル一時ビューではなく、適切なテーブル ACL でビューを使用することをお勧めします。

関数とは

関数を使用すると、ユーザー定義のロジックをデータベースに関連付けることができます。 関数は、スカラー値または行のセットを返すことができます。 関数は、データを集計するために使用されます。 Azure Databricks を使用すると、実行コンテキストに応じてさまざまな言語で関数を保存でき、SQL は広くサポートされています。 関数を使用すると、Databricks 製品のさまざまなコンテキストでカスタム ロジックへのマネージド アクセスを提供できます。

Delta Live Tables でのリレーショナル オブジェクトのしくみ

Delta Live Tables では、宣言構文を使用して DDL、DML、インフラストラクチャのデプロイを定義および管理します。 Delta Live Tables では、ロジックのプランニングと実行の際に "仮想スキーマ" の概念が使用されます。 Delta Live Tables テーブルは、Databricks 環境内の他のデータベースとやり取りできます。Delta Live Tables では、パイプライン構成設定でターゲット データベースを指定することで、他の場所でクエリを実行するためのテーブルを公開および保持できます。

Delta Live Tables で作成されたすべてのテーブルは Delta テーブルです。 Delta Live Tables で Unity Catalog を使用する場合、すべてのテーブルは Unity Catalog マネージド テーブルです。 Unity Catalog がアクティブではない場合、テーブルはマネージド テーブルまたはアンマネージド テーブルとして宣言できます。

Delta Live Tables ではビューを宣言できますが、これらのビューはパイプラインをスコープとした一時ビューと考える必要があります。 Delta Live Tables の一時テーブルは一意の概念です。これらのテーブルはデータをストレージに保持しますが、ターゲット データベースにはデータを公開しません。

たとえば APPLY CHANGES INTO などの一部の操作では、テーブルとビューの両方がデータベースに登録されます。テーブル名はアンダースコア (_) で始まり、ビューにはテーブル名が APPLY CHANGES INTO 操作のターゲットとして宣言されます。 ビューは、対応する非表示テーブルを照会して結果を具体化します。