Unity Catalog を Delta Live Tables パイプラインで使う

重要

Unity Catalog の Delta Live Tables サポートはパブリック プレビュー段階です。

Databricks では、Unity カタログを使用して Delta Live Tables パイプラインを構成することをお勧めします。

Unity カタログで構成されたパイプラインは、定義されたすべての具体化されたビューとストリーミング テーブルを、指定されたカタログとスキーマに発行します。 Unity カタログ パイプラインは、他の Unity カタログ テーブルとボリュームから読み取ることができます。

Unity Catalog パイプラインによって作成されたテーブルに対するアクセス許可を管理するには、GRANT と REVOKE を使用します。

要件

Delta Live Tables パイプラインから Unity カタログにテーブルを作成するために必要なアクセス許可:

• USE CATALOG ターゲット カタログに対する特権。
• CREATE MATERIALIZED VIEWパイプラインが具体化されたビューを作成する場合は、ターゲット スキーマに対する特権USE SCHEMAします
• CREATE TABLEパイプラインがストリーミング テーブルを作成する場合は、ターゲット スキーマに対する特権USE SCHEMA。
• パイプライン設定でターゲット スキーマが指定されていない場合は、ターゲット カタログ内の少なくとも 1 つのスキーマに対する CREATE MATERIALIZED VIEW 権限または CREATE TABLE 権限が必要です。

Unity カタログ対応パイプラインを実行するために必要なコンピューティング:

• 共有アクセス モード クラスター。 Unity カタログ対応パイプラインは、1 人のユーザー ("割り当て済み") クラスターでは実行できません。 Unity カタログ 共有アクセス モードの制限事項を参照してください。

Unity カタログ (ストリーミング テーブルや具体化されたビューを含む) を使用して Delta Live Tables パイプラインによって作成されたテーブルに対してクエリを実行するために必要なコンピューティングには、次のいずれかが含まれます。

• SQL ウェアハウス

• Databricks Runtime 13.3 LTS 以降の共有アクセス モード クラスター。

• シングル ユーザー (または "割り当て済み") アクセス モード クラスター。単一ユーザー クラスターできめ細かいアクセス制御が有効になっている場合 (つまり、クラスターが Databricks Runtime 15.4 以降で実行されており、ワークスペースに対してサーバーレス コンピューティングが有効になっています)。 詳細については、「 シングル ユーザー コンピューティングでの詳細なアクセス制御を参照してください。

• テーブル所有者がクエリを実行する場合にのみ、13.3 LTS から 15.3 の単一ユーザー (または "割り当て済み") アクセス モード クラスター。

追加のコンピューティング制限が適用されます。 次のセクションを参照してください。

制限事項

Delta Live Tables で Unity Catalog を使用する場合の制限事項を次に示します。

• 既定では、Unity カタログ対応パイプラインを実行するクラスターのドライバー ログを表示できるのは、パイプライン所有者とワークスペース管理者だけです。 他のユーザーがドライバー ログにアクセスできるようにするには、「 管理者以外のユーザーが Unity カタログ対応パイプラインからドライバー ログを表示するを参照してください。

• Hive メタストアを使用する既存のパイプラインは、Unity Catalog を使用するようにアップグレードすることはできません。 Hive メタストアに書き込む既存のパイプラインを移行するには、新しいパイプラインを作成し、データ ソースからデータを再取り込みする必要があります。

• Unity カタログパブリック プレビュー中に作成されたメタストアにアタッチされたワークスペースに、Unity カタログ対応パイプラインを作成することはできません。 「特権継承へのアップグレード」を参照してください。

• JAR はサポートされていません。 サードパーティの Python ライブラリのみがサポートされています。 ｢Delta Live Tables パイプラインの Python 依存関係を管理する」を参照してください。

• ストリーミング テーブルのスキーマを変更するデータ操作言語 (DML) クエリはサポートされていません。

• Delta Live Tables パイプラインで作成された具体化されたビューは、別のパイプラインやダウンストリーム ノートブックなど、そのパイプラインの外部のストリーミング ソースとして使用することはできません。

• パイプラインが保存場所が管理されているスキーマに発行を行う場合、以降の更新でスキーマを変更できます。ただし、更新されたスキーマが以前に指定されていたスキーマと同じ保存場所を使用する場合に限ります。

• テーブルは、ターゲット スキーマの格納場所に格納されます。 スキーマストレージの場所が指定されていない場合、テーブルはカタログストレージの場所に格納されます。 スキーマとカタログのストレージの場所が指定されていない場合、テーブルはメタストアのルート ストレージの場所に格納されます。

• カタログ エクスプローラー History タブには、具体化されたビューの履歴は表示されません。

• テーブルを定義する場合、LOCATION プロパティはサポートされません。

• Unity Catalog 対応パイプラインは、Hive メタストアに発行できません。

• Python UDF のサポートはパブリック プレビュー段階です。

• Delta Live Tables の具体化されたビューや、Unity Catalog に発行されたストリーミング テーブルで Delta Sharing を使用することはできません。

• パイプラインまたはクエリで event_log テーブル値関数を使用して複数のパイプラインのイベント ログにアクセスすることはできません。

• event_log テーブル値関数に対して作成されたビューを他のユーザーと共有することはできません。

• 単一ノード クラスターは、Unity Catalog 対応パイプラインではサポートされていません。 Delta Live Tables では、小さいパイプラインを実行するために単一ノード クラスターが作成される可能性があるので、single-node mode を参照するエラー メッセージと共にパイプラインが失敗する可能性があります。 この場合は、コンピューティングの構成時に少なくとも 1 つの worker を指定します。 デルタ ライブ テーブル パイプライン コンピューティングの構成を参照してください。

Note

具体化されたビューをサポートする基になるファイルには、具体化されたビュー定義に表示されないアップストリーム テーブルのデータ (個人を特定できる情報を含む) が含まれる場合があります。 このデータは、具体化されたビューの増分更新をサポートするために、基になるストレージに自動的に追加されます。

具体化されたビューの基になるファイルは、具体化されたビュー スキーマの一部ではないアップストリーム テーブルからデータを公開する可能性があるため、Databricks では、基になるストレージを信頼関係のないダウンストリーム コンシューマーと共有しないことをお勧めします。

たとえば、具体化されたビュー定義に COUNT(DISTINCT field_a) 句が含まれているとします。 具体化されたビュー定義には集計 COUNT DISTINCT 句のみが含まれていますが、基になるファイルには field_a の実際の値の一覧が含まれています。

Hive メタストアと Unity カタログ パイプラインを一緒に使用できますか?

ワークスペースには、Unity カタログと従来の Hive メタストアを使用するパイプラインを含めることができます。 ただし、1 つのパイプラインで Hive メタストアと Unity カタログに書き込むことはできません。 Hive メタストアに書き込む既存のパイプラインは、Unity カタログを使用するようにアップグレードすることはできません。

Unity カタログを使用していない既存のパイプラインは、Unity カタログで構成された新しいパイプラインを作成しても影響を受けません。 これらのパイプラインは、構成されたストレージの場所を使用して Hive メタストアにデータを保持し続けます。

このドキュメントで特に指定がない限り、既存のすべてのデータ ソースと Delta Live Tables 機能は、Unity Catalog を使用するパイプラインでサポートされます。 Python と SQL の両方のインターフェイスは、Unity Catalog を使用するパイプラインでサポートされています。

既存の機能に対する変更

Delta Live Tables が Unity Catalog にデータを保持するように構成されている場合、テーブルのライフサイクルは Delta Live Tables パイプラインによって管理されます。 パイプラインはテーブルのライフサイクルとアクセス許可を管理するため、

• Delta Live Tables パイプライン定義からテーブルが削除されると、次のパイプライン更新時に、対応する具体化されたビューまたはストリーミング テーブルエントリが Unity Catalog から削除されます。 実際のデータは、誤って削除された場合に復旧できるように、一定期間保持されます。 データは、具体化されたビューを追加するか、パイプライン定義に >戻すことによって復旧できます。
• Delta Live Tables パイプラインを削除すると、そのパイプラインで定義されているすべてのテーブルが削除されます。 この変更により、Delta Live Tables UI が更新され、パイプラインの削除を確認するように求められます。
• 内部バッキング テーブル ( APPLY CHANGES INTOのサポートに使用されるものも含む) は、ユーザーが直接アクセスすることはできません。

Delta Live Tables パイプラインから Unity Catalog にテーブルを書き込む

Note

パイプラインに対してカタログとターゲット スキーマを選択しない場合、テーブルは、Unity Catalog に発行されず、同じパイプライン内のクエリによってのみアクセス可能となります。

Unity カタログにテーブルを書き込むには、ワークスペースを介して操作するようにパイプラインを構成する必要があります。 パイプラインを作成したらStorage オプションで Unity Catalog を選択しCatalog ドロップダウン メニューでカタログを選択し、既存のスキーマを選択するか、Target スキーマ ドロップダウン メニューに新しいスキーマの名前を入力します。 Unity Catalog カタログの詳細については、「Azure Databricks のカタログとは」を参照してください。 Unity Catalog のスキーマについては、「Azure Databricks のスキーマとは」を参照してください。

Unity Catalog パイプラインにデータを取り込む

Unity Catalog を使用するように構成されたパイプラインは、次の場所からデータを読み取ることができます。

• Unity Catalog のマネージド テーブルと外部テーブル、ビュー、具体化されたビュー、ストリーミング テーブル。
• Hive メタストアのテーブルとビュー。
• read_files() 関数を使用して Unity Catalog の外部の場所から読み取る自動ローダー。
• Apache Kafka と Amazon Kinesis。

Unity Catalog テーブルと Hive メタストア テーブルからの読み取りの例を次に示します。

Unity Catalog テーブルからのバッチ インジェスト

SQL

CREATE OR REFRESH MATERIALIZED VIEW
  table_name
AS SELECT
  *
FROM
  my_catalog.my_schema.table1;

Python

@dlt.table
def table_name():
  return spark.read.table("my_catalog.my_schema.table")

Unity Catalog テーブルから変更をストリーム配信する

SQL

CREATE OR REFRESH STREAMING TABLE
  table_name
AS SELECT
  *
FROM
  STREAM(my_catalog.my_schema.table1);

Python

@dlt.table
def table_name():
  return spark.readStream.table("my_catalog.my_schema.table")

Hive メタストアからデータを取り込む

Unity Catalog を使用するパイプラインでは、hive_metastore カタログを使用して Hive メタストア テーブルからデータを読み取ることができます。

SQL

CREATE OR REFRESH MATERIALIZED VIEW
  table_name
AS SELECT
  *
FROM
  hive_metastore.some_schema.table;

Python

@dlt.table
def table3():
  return spark.read.table("hive_metastore.some_schema.table")

自動ローダーからデータを取り込む

SQL

CREATE OR REFRESH STREAMING TABLE
  table_name
AS SELECT
  *
FROM
  read_files(
    <path-to-uc-external-location>,
    "json"
  )

Python

@dlt.table(table_properties={"quality": "bronze"})
def table_name():
  return (
     spark.readStream.format("cloudFiles")
     .option("cloudFiles.format", "json")
     .load(f"{path_to_uc_external_location}")
 )

具体化されたビューを共有する

既定では、パイプライン所有者のみが、パイプラインによって作成されたデータセットに対してクエリを実行するアクセス許可を持ちます。 GRANT ステートメントを使用すると他のユーザーにテーブルに対してクエリを実行する機能を付与できます。また、REVOKE ステートメントを使用するとクエリ アクセスを取り消すことができます。 Unity Catalog での権限の詳細については、「Unity Catalog の権限の管理」を参照してください。

テーブルに SELECT 権限を付与する

GRANT SELECT ON TABLE
  my_catalog.my_schema.table_name
TO
  `user@databricks.com`

テーブルの SELECT 権限を取り消す

REVOKE SELECT ON TABLE
  my_catalog.my_schema.table_name
FROM
  `user@databricks.com`

テーブルの作成または具体化されたビューの作成権限を付与する

GRANT CREATE { MATERIALIZED VIEW | TABLE } ON SCHEMA
  my_catalog.my_schema
TO
  { principal | user }

パイプラインの系列を表示する

Delta Live Tables パイプライン内のテーブルの系列は、カタログ エクスプローラーに表示されます。 カタログ エクスプローラーの系列 UI には、Unity カタログ対応パイプラインの具体化されたビューまたはストリーミング テーブルのアップストリームテーブルとダウンストリーム テーブルが表示されます。 Unity Catalog 系列の詳細については、「Unity Catalog を使用したデータ系列のキャプチャと表示」を参照してください。

Unity Catalog 対応 Delta Live Tables パイプラインの具体化されたビューまたはストリーミング テーブルの場合、カタログ エクスプローラー系列 UI は具体化されたビューまたはストリーミング テーブルを生成したパイプラインにも、そのパイプラインに現在のワークスペースからアクセスできる場合はリンクします。

ストリーミング テーブルのデータを追加、変更、または削除する

データ操作言語 (DML) ステートメント (挿入、更新、削除、マージステートメントなど) を使用して、Unity カタログに発行されたストリーミング テーブルを変更できます。 ストリーミング テーブルに対する DML クエリのサポートにより、一般データ保護規則 (GDPR) に準拠するためにテーブルを更新するなどのユース ケースが可能になります。

Note

• ストリーミング テーブルのテーブル スキーマを変更する DML ステートメントはサポートされていません。 DML ステートメントがテーブル スキーマの進化を試みないことを確認します。
• ストリーミング テーブルを更新する DML ステートメントは、Databricks Runtime 13.3 LTS 以降を使用する共有 Unity Catalog クラスターまたは SQL ウェアハウスでのみ実行できます。
• ストリーミングには追加専用のデータソースが必要なため、処理で (DML ステートメントなどによる) 変更を伴うソース ストリーミング テーブルからのストリーミングが必要な場合は、ソース ストリーミング テーブルを読み取るときに skipChangeCommits フラグを設定します。 skipChangeCommits が設定されていれば、ソース テーブルのレコードを削除または変更するトランザクションは無視されます。 処理にストリーミング テーブルが必要ない場合は、具体化されたビュー (追加専用の制限がない) をターゲット テーブルとして使用できます。

ストリーミング テーブル内のレコードを変更する DML ステートメントの例を次に示します。

特定の ID を持つレコードを削除します。

DELETE FROM my_streaming_table WHERE id = 123;

特定の ID を持つレコードを更新します。

UPDATE my_streaming_table SET name = 'Jane Doe' WHERE id = 123;

行フィルターと列マスクを使用してテーブルを発行する

重要

この機能はパブリック プレビュー段階にあります。

行フィルターを使用すると、テーブル スキャンで行がフェッチされるたびにフィルターとして適用される関数を指定できます。 これらのフィルターにより、後続のクエリでフィルター述語が true と評価される行のみが返されるようになります。

列マスクを使用すると、テーブル スキャンで行がフェッチされるたびに列の値をマスクできます。 その列の今後のクエリでは、列の元の値でなく、評価された関数の結果が返されます。 行フィルターと列マスクの使用の詳細については、「 行フィルターと列マスクを使用して機密テーブル データをフィルター処理する」を参照してください。

行フィルターと列マスクの管理

具体化されたビューとストリーミング テーブルの行フィルターと列マスクは、CREATE OR REFRESH ステートメントを通じて追加、更新、または削除する必要があります。

行フィルターと列マスクを使用したテーブルの定義の詳細な構文については、「 Delta Live Tables SQL 言語リファレンス および Delta Live Tables Python 言語リファレンスを参照してください。

Behavior

Delta Live Tables パイプラインで行フィルターまたは列マスクを使用する場合の重要な詳細情報を次に示します。

• 所有者権限で更新する: 具体化されたビューまたはストリーミング テーブルがパイプラインの更新によって更新されると、行フィルターと列マスクの関数はパイプライン所有者の権限で実行されます。 つまり、テーブルの更新では、パイプラインを作成したユーザーのセキュリティ コンテキストが使用されます。 (CURRENT_USER や IS_MEMBER などの) ユーザー コンテキストをチェックする関数は、パイプライン所有者のユーザー コンテキストを使用して評価されます。
• クエリ: 具体化されたビューまたはストリーミング テーブルに対してクエリを実行する際に、(CURRENT_USER や IS_MEMBER などの) ユーザー コンテキストをチェックする関数は、呼び出し側のユーザー コンテキストを使用して評価されます。 このアプローチでは、現在のユーザーのコンテキストに基づいて、ユーザー固有のデータ セキュリティとアクセス制御が適用されます。
• 行フィルターと列マスクを含むソース テーブルに対する具体化されたビューを作成する場合、具体化されたビューの更新は常に完全更新になります。 完全更新では、最新の定義を使用して、ソースで使用可能なすべてのデータが再処理されます。 このプロセスでは、ソース テーブルのセキュリティ ポリシーが最新のデータと定義に基づいて評価され、適用されていることを確認します。

可観測性

DESCRIBE EXTENDED、INFORMATION_SCHEMA、またはカタログ エクスプローラーを使用して、特定の具体化されたビューまたはストリーミング テーブルに適用される既存の行フィルターと列マスクを調べます。 この機能により、ユーザーは具体化されたビューとストリーミング テーブルのデータ アクセスと保護対策を監査および確認できます。