DLT パイプラインで Unity Catalog を使用する

備考

プレビュー

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

Databricks では、Unity Catalog を使用して DLT パイプラインを構成することをお勧めします。

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

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

注記

この記事では、パイプラインの現在のデフォルト発行モードの機能について説明します。 2025 年 2 月 5 日より前に作成されたパイプラインでは、従来の発行モードと LIVE 仮想スキーマが使用される場合があります。 LIVE スキーマ (レガシー)を参照してください。

必要条件

Unity Catalogのターゲットスキーマにストリーミングテーブルとマテリアライズドビューを作成するには、スキーマと親カタログに対する次のアクセス許可が必要です。

• USE CATALOG ターゲット・カタログに対する権限。
• CREATE MATERIALIZED VIEW また、パイプラインがマテリアライズドビューを作成する場合は、ターゲットスキーマに対する権限USE SCHEMA。
• CREATE TABLE USE SCHEMA パイプラインがストリーミングテーブルを作成する場合は、ターゲット スキーマに対する権限。

パイプラインで新しいスキーマを作成する場合は、ターゲット カタログに対する USE CATALOG 権限と CREATE SCHEMA 権限が必要です。

Unity Catalog 対応のパイプラインを実行するために必要なコンピュート:

• 標準アクセス モード (以前の共有アクセス モード)。 Unity Catalog が有効なパイプラインは、専用のコンピュート (以前のシングル ユーザー コンピュート) では実行できません。 「Unity Catalog の標準アクセス モードの制限」を参照してください。

Unity Catalog を使用して DLT パイプラインによって作成されたテーブル (ストリーミングテーブルやマテリアライズドビューなど) をクエリするために必要なコンピュートには、次のいずれかが含まれます。

• SQLウェアハウス
• 標準アクセスモードコンピュート Databricks Runtime 13.3 LTS 以上。
• 専用アクセスモードは、専用コンピュートできめ細かなアクセス制御が有効になっている場合(つまり、 Databricks Runtime 15.4以降で実行されており、ワークスペースでサーバレスコンピュートが有効になっている場合)。 詳細については、「 Fine-grained access control on dedicated コンピュート (旧称 single user コンピュート)」を参照してください。
• 13.3 LTS から 15.3 の専用アクセスモード コンピュート (テーブルの所有者がクエリを実行した場合のみ)。

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

制限

DLT で Unity Catalog を使用する場合の制限事項は次のとおりです。

• デフォルトでは、パイプラインの所有者とワークスペース管理者のみが、Unity Catalog 対応のパイプラインを実行するコンピュートからのドライバー ログを表示できます。 他のユーザーがドライバー ログにアクセスできるようにするには、「 管理者以外のユーザーが Unity Catalog 対応パイプラインからドライバー ログを表示できるようにする」を参照してください。

• Hive metastore を使用する既存のパイプラインは、 Unity Catalogを使用するようにアップグレードすることはできません。Hive metastoreに書き込む既存のパイプラインを移行するには、新しいパイプラインを作成し、データソースからデータを再取り込む必要があります。「Unity CatalogパイプラインのクローニングによるHive metastore パイプラインの作成 」を参照してください。

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

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

• DLT パイプラインで作成されたマテリアライズドビュー は、そのパイプラインの外部 (別のパイプラインやダウンストリーム ノートブックなど) でストリーミング ソースとして使用することはできません。

• マテリアライズドビューとストリーミングテーブルのデータは、含まれているスキーマのストレージの場所に保存されます。 スキーマの格納場所が指定されていない場合、テーブルはカタログの格納場所に格納されます。 スキーマとカタログの保存場所が指定されていない場合、テーブルはメタストアのルートの保存場所に格納されます。

• カタログエクスプローラ の「履歴 」タブには、マテリアライズドビューの履歴は表示されません。

• LOCATION プロパティは、テーブルを定義するときにはサポートされていません。

• Unity Catalog対応パイプラインは Hive metastoreに発行できません。

• Python UDFs はサポートされていません。

• Delta SharingDLT マテリアライズドビュー または に公開されたストリーミングテーブルとUnity Catalog を使用することはできません。

注記

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

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

たとえば、マテリアライズドビューの定義に COUNT(DISTINCT field_a) 句が含まれているとします。 マテリアライズドビューの定義には aggregate COUNT DISTINCT 句のみが含まれていますが、基になるファイルには field_aの実際の値の一覧が含まれます。

Hive metastoreとUnity Catalogパイプラインを併用することはできますか?

ワークスペースには、 Unity Catalog と従来の Hive metastoreを使用するパイプラインを含めることができます。 ただし、1 つのパイプラインで Hive metastore に書き込んで Unity Catalog. Hive metastore に書き込む既存のパイプラインをアップグレードして Unity Catalog.Hive metastoreに書き込む既存のパイプラインを移行するには、新しいパイプラインを作成し、データソースからデータを再取り込む必要があります。「Unity CatalogパイプラインのクローニングによるHive metastore パイプラインの作成 」を参照してください。

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

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

既存の機能の変更

DLT が Unity Catalog にデータを保持するように構成されている場合、DLT パイプラインはテーブルのライフサイクルとアクセス許可を管理します。その結果：

• パイプライン定義からテーブルが削除されると、次回のパイプライン更新では、対応するマテリアライズドビューまたはストリーミングテーブルエントリが非アクティブとしてマークされます。 非アクティブなテーブルは引き続きクエリを実行できますが、更新はされません。 マテリアライズドビューまたはストリーミングテーブルをクリーンアップするには、テーブルを明示的に DROP できます。

  • ドロップされたテーブルは、 UNDROP コマンドを使用して 7 日以内に回復できます。
  • 次回のパイプライン更新時にマテリアライズドビュー または ストリーミングテーブル エントリが Unity Catalog から削除される従来の動作を保持するには、パイプライン構成を "pipelines.dropInactiveTables": "true" に設定します。 実際のデータは、誤って削除された場合に回復できるように、一定期間保持されます。 データは、マテリアライズドビューまたはストリーミングテーブルをパイプライン定義に追加し直すことで、7日以内に回復できます。

• DLT パイプラインを削除すると、そのパイプラインで定義されているすべてのテーブルが削除されます。この変更により、DLT UI が更新され、パイプラインの削除を確認するように求められます。

• 内部バッキング・テーブル ( APPLY CHANGES INTOのサポートに使用されるものを含む) は、ユーザーが直接アクセスすることはできません。

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

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

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

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

• Unity Catalog マネージドテーブルと外部テーブル、ビュー、マテリアライズドビュー、ストリーミングテーブルがあります。
• Hive metastore テーブルとビュー。
• Auto Loader read_files()機能を使用して、外部ロケーションからの読み取り Unity Catalog 。
• Apache Kafka と Amazon Kinesis。

次に、 Unity Catalog テーブルと Hive metastore テーブルからの読み取りの例を示します。

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

SQL

SQL

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

Python

Python

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

Unity Catalogテーブルからのストリームの変更

SQL

SQL

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

Python

Python

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

Hive metastore からデータを取り込む

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

SQL

SQL

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

Python

Python

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

Auto Loader からデータを取り込む

SQL

SQL

CREATE OR REFRESH STREAMING TABLE table_name
AS SELECT *
FROM STREAM read_files(
  "/path/to/uc/external/location",
  format => "json"
)

Python

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での権限の管理」を参照してください。

テーブルに対する選択の付与

SQL

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

テーブルの選択を取り消す

SQL

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

create table または create マテリアライズドビュー 権限を付与する

SQL

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

View リネージ for a パイプライン

DLT パイプライン内のテーブルのリネージは、Catalog Explorer に表示されます。 Catalog Explorer リネージ UI には、Unity Catalog 対応パイプラインのマテリアライズドビュー またはストリーミングテーブルのアップストリーム テーブルとダウンストリーム テーブルが表示されます。 Unity Catalogリネージの詳細については、「Unity Catalogを使用したデータリネージのキャプチャと表示」を参照してください。

Unity Catalog 対応 DLT パイプラインのマテリアライズドビュー またはストリーミングテーブルの場合、Catalog Explorer リネージ UI は、マテリアライズドビュー またはストリーミングテーブルを生成したパイプラインにもリンクします (パイプラインが現在のワークスペースからアクセス可能な場合)。

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

データ操作言語 (DML) ステートメント (insert、update、delete、merge ステートメントなど) を使用して、Unity Catalogにパブリッシュされたストリーミングテーブルを変更できます。ストリーミングテーブルに対する DML クエリのサポートにより、EU 一般データ保護規則 (GDPR) を使用してコンプライアンスのテーブルを更新するなどのユースケースが可能になります。

注記

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

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

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

SQL

DELETE FROM my_streaming_table WHERE id = 123;

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

SQL

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

行フィルターと列マスクを使用したテーブルの公開

備考

プレビュー

この機能は パブリック プレビュー段階です。

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

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

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

マテリアライズドビューとストリーミングテーブルの行フィルタと列マスクは、 CREATE OR REFRESH 文を使用して追加、更新、または削除する必要があります。

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

振舞い

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

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

オブザーバビリティ

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