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

Databricksレイクハウスは、Delta Lakeでクラウドオブジェクトストレージに保存されたデータを、データベース、テーブル、ビューなどの使い慣れた関係で整理します。このモデルは、エンタープライズ・データウェアハウスの利点の多くと、データレイクの拡張性および柔軟性を組み合わせたものです。このモデルの仕組みや、オブジェクトデータとメタデータの関係について詳しく学習することで、組織向けにDatabricksレイクハウスを設計・実装する際にベストプラクティスを適用できます。

Databricksレイクハウスに含まれるデータオブジェクトとは

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

  • カタログ: データベースのグループ。

  • データベース またはスキーマ: カタログ内のオブジェクトのグループ。 データベースには、テーブル、ビュー、および関数が含まれています。

  • 表: オブジェクト・ストレージにデータ・ファイルとして格納される行と列のコレクション。

  • ビュー: 通常、1 つ以上のテーブルまたは DATA に対して保存されたクエリ。

  • 関数: スカラー値または行のセットを返す保存されたロジック。

Unity Catalogのオブジェクトモデル図

Unity Catalogによるオブジェクトのセキュリティ保護に関する情報については、「 セキュリティ保護可能なオブジェクト モデル」を参照してください。

メタストアとは

メタストアには、レイクハウス内のデータオブジェクトを定義するすべてのメタデータが格納されています。Databricksは、以下のメタストアオプションを提供しています。

  • Unity Catalogメタストア：Unity Catalogは、一元化されたアクセス制御、監査、リネージ、およびデータディスカバリー機能を提供します。DatabricksアカウントレベルでUnity Catalogメタストアを作成すると、単一のメタストアを複数のワークスペースで使用できます。

    各 Unity Catalog メタストアは、Google クラウド アカウントの GCS バケット内のルート ストレージの場所で構成されます。 この格納場所は、マネージド テーブルのデータを格納するためにデフォルトによって使用されます。

    Unity Catalogでは、データはデフォルトで保護されます。最初は、ユーザーはメタストア内のデータにアクセスできません。アクセス権限は、メタストア管理者またはオブジェクトの所有者によって付与されます。Unity Catalogのセキュリティ保護可能なオブジェクトは階層構造で、権限は上位から下位に継承されます。Unity Catalogは、データアクセスポリシーを管理するための一元化された場所を提供します。ユーザーは、メタストアがアタッチされている任意のワークスペースから Unity Catalog内のデータにアクセスできます。詳細については、「Unity Catalogでの権限の管理」を参照してください。

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

    Hive metastoreは、Unity Catalogよりも一元化の程度が低いデータガバナンスモデルを提供します。デフォルトでは、クラスターに対してテーブルアクセスコントロールが有効になっていない限り、そのクラスターではワークスペースの組み込みHive metastoreによって管理されるすべてのデータに全ユーザーがアクセスできます。詳細については、「Hive metastoreテーブルアクセスコントロール（レガシー）」を参照してください。

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

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

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

カタログとは

カタログは、Databricksレイクハウスの関係モデルの中で最も抽象性が高い （または最も粒度が粗い）ものです。すべてのデータベースはカタログに関連付けられます。カタログはメタストア内のオブジェクトとして存在します。

Unity Catalogが導入される前は、Databricksでは2層の名前空間が使用されていました。カタログは、Unity Catalogの名前空間モデルの3番目の層です。

catalog_name.database_name.table_name

組み込みのHive metastoreは、唯一 hive_metastore のカタログのみをサポートします。

データベースとは

データベースとは、テーブルやビュー （「関係」とも呼ばれます）や関数などのデータオブジェクトのコレクションを指します。Databricksでは、「スキーマ」と「データベース」という用語が同じ意味で使用されます。一方、多くの関係システムでは、「データベース」はスキーマのコレクションを意味します。

データベースは必ずクラウドオブジェクトストレージ上のロケーションに関連付けられます。データベースを登録する際に、任意で LOCATION を指定できます。以下の点に注意してください。

  • データベースに関連付けられた LOCATION は、常にマネージドロケーションとみなされます。

  • データベースを作成しても、ターゲットのロケーションにはファイルは作成されません。

  • データベースの LOCATION によって、そのデータベースに登録されているすべてのテーブルのデータのデフォルトのロケーションが決まります。

  • データベースが正常に削除されると、マネージドロケーションに保存されているすべてのデータとファイルが再帰的に削除されます。

データベースによって管理されるロケーションとデータファイルの間のこの相互作用は非常に重要です。誤ってデータを削除しないようにするには、以下の点に注意してください。

  • 複数のデータベース定義でデータベースのロケーションを共有しないでください。

  • 既にデータが含まれるロケーションにデータベースを登録しないでください。

  • データベースとは独立してデータのライフサイクルを管理するには、データベースのロケーションの下にネストされていない場所にデータを保存します。

テーブルとは

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

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

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

注

テーブルの観点では、Delta Live Tables におけるライブテーブルとストリーミングライブテーブルの違いはありません。

マネージドテーブルとは

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")

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

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に相当します。DataFramesとは異なり、権限を持つユーザーはDatabricks製品のどの部分からでもビューをクエリーできます。ビューの作成では、データの処理や書き込みは行われません。クエリーテキストのみが関連付けられたデータベースのメタストアに登録されます。

一時ビューとは

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

  • ノートブックとジョブでは、一時ビューのスコープはノートブックまたはスクリプトレベルに限定されます。これらは、宣言されているノートブックの外部から参照することはできず、ノートブックがクラスターから切り離されると存在しなくなります。

  • Databricks SQLでは、一時ビューのスコープはクエリーレベルに設定されます。同じクエリー内の複数のステートメントで一時ビューを使用できますが、同じダッシュボード内であっても他のクエリーで一時ビューを参照することはできません。

  • グローバルな一時ビューはクラスターレベルにスコープされ、コンピューティングリソースを共有するノートブックやジョブ間で共有できます。Databricksでは、グローバルな一時ビューの代わりに適切なテーブルACLを持つビューを使用することを推奨しています。

関数とは

関数を使うと、ユーザー定義のロジックをデータベースに関連付けることができます。関数は、スカラー値または行のセットを返します。また、関数はデータを集約するために使用されます。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 操作のターゲットとして宣言されたテーブル名が含まれます。ビューは、対応する非表示テーブルにクエリーを実行して、結果をマテリアライズします。