Delta Live Tablesパイプライン で Unity Catalog を使用する
プレビュー
Unity Catalog Delta Live Tables のサポートは パブリック プレビュー 段階です。
Databricks では、Unity Catalog を使用して Delta Live Tables パイプラインを構成することをお勧めします。
Unity Catalog で構成されたパイプラインは、定義されたすべての具体化されたビューとストリーミング テーブルを、指定したカタログとスキーマに発行します。 Unity Catalog パイプラインは、他の Unity Catalog テーブルとボリュームから読み取ることができます。
Unity Catalog パイプラインによって作成されたテーブルに対するアクセス許可を管理するには、 GRANT と REVOKE を使用します。
要件
Delta Live Tables パイプラインから Unity Catalog でテーブルを作成するために必要なアクセス許可:
USE CATALOG
ターゲット・カタログに対する権限。CREATE MATERIALIZED VIEW
また、パイプラインが具体化されたビューを作成する場合は、ターゲット スキーマに対する権限をUSE SCHEMA
します。CREATE TABLE
また、パイプラインがストリーミング テーブルを作成する場合は、ターゲット スキーマに対するUSE SCHEMA
権限も付与されます。パイプライン設定でターゲットスキーマが指定されていない場合は、ターゲットカタログ内の少なくとも 1 つのスキーマに対する
CREATE MATERIALIZED VIEW
権限またはCREATE TABLE
権限が必要です。
Unity Catalog 対応のパイプラインを実行するために必要なコンピュート:
共有アクセス モード クラスター。 Unity Catalog 対応パイプラインは、1 人のユーザー ("割り当て済み") クラスターでは実行できません。 「Unity Catalog の共有アクセス モードの制限事項」を参照してください。
を使用してDelta Live Tables パイプラインによって作成されたテーブルUnity Catalog (ストリーミングテーブルやマテリアライズドビューを含む) をクエリするために必要なコンピュートには、次のいずれかが含まれます。
SQLウェアハウス
Databricks Runtime 13.3 LTS 以降の共有アクセス モード クラスター。
13.3 LTS 以上のシングルユーザー (または「割り当て済み」) アクセスモードクラスター (テーブル所有者がクエリを実行する場合のみ)。
追加のコンピュート制限が適用されます。 次のセクションを参照してください。
制限
Delta Live Tables でUnity Catalog を使用する場合の制限事項を次に示します。
デフォルトでは、パイプラインの所有者とワークスペース管理者のみが、Unity Catalog 対応パイプラインを実行するクラスターのドライバー ログを表示できます。 他のユーザーがドライバー ログにアクセスできるようにするには、「 管理者以外のユーザーが Unity Catalog 対応パイプラインからドライバー ログを表示できるようにする」を参照してください。
Hive metastore を使用する既存のパイプラインは、 Unity Catalogを使用するようにアップグレードすることはできません。に書き込む既存のパイプラインを移行するには Hive metastoreに新しいパイプラインを作成し、データソースからデータを再取り込みする必要があります。
JAR はサポートされていません。 サードパーティの Python ライブラリのみがサポートされています。 「Delta Live Tables パイプラインの Python 依存関係の管理」を参照してください。
ストリーミング テーブルのスキーマを変更するデータ操作言語 (DML) クエリー はサポートされていません。
Delta Live Tables パイプラインで作成された具体化されたビューは、そのパイプラインの外部 (別のパイプラインやダウンストリーム ノートブックなど) のストリーミング ソースとして使用することはできません。
パイプラインがマネージド ストレージの場所を持つスキーマに発行する場合、スキーマは後続の更新で変更できますが、更新されたスキーマが以前に指定したスキーマと同じストレージの場所を使用している場合に限ります。
テーブルは、ターゲットスキーマのストレージロケーションに保存されます。 スキーマの格納場所が指定されていない場合、テーブルはカタログの格納場所に格納されます。 スキーマとカタログの保存場所が指定されていない場合、テーブルはメタストアのルートの保存場所に格納されます。
カタログエクスプローラ の「履歴 」タブには、マテリアライズドビューの履歴は表示されません。
LOCATION
プロパティは、テーブルの定義時にはサポートされません。Unity Catalog対応パイプラインは Hive metastoreに発行できません。
Python UDFs はサポートされていません。
Unity Catalog に公開された Delta Live Tables マテリアライズド ビューまたはストリーミング テーブルではDelta Sharing を使用できません。
パイプラインまたはクエリーで
event_log
テーブル値関数 を使用して、複数のパイプラインのイベント ログにアクセスすることはできません。event_log
テーブル値関数 で作成されたビューを他のユーザーと共有することはできません。単一ノード クラスターは、Unity Catalog 対応パイプラインではサポートされていません。 Delta Live Tables は、より小さなパイプラインを実行するために単一ノードクラスターを作成する可能性があるため、パイプラインは失敗し、
single-node mode
を参照するエラーメッセージが表示される可能性があります。その場合は、コンピュートの設定時にワーカーを1名以上指定してください。 Delta Live Tables パイプラインのコンピュートの設定を参照してください。
注
マテリアライズドビューをサポートする基になるファイルには、マテリアライズドビューの定義に表示されないアップストリームテーブルのデータ (個人を特定できる可能性のある情報を含む) が含まれる場合があります。 このデータは、マテリアライズドビューの増分更新をサポートするために、基になるストレージに自動的に追加されます。
マテリアライズドビューの基になるファイルは、マテリアライズドビュー スキーマの一部ではないアップストリーム テーブルからのデータを公開するリスクがあるため、Databricks では、基になるストレージを信頼されていないダウンストリーム コンシューマーと共有しないことをお勧めします。
たとえば、マテリアライズドビューの定義に COUNT(DISTINCT field_a)
句が含まれているとします。 実体化ビュー (Materialized View) の定義には aggregate COUNT DISTINCT
句のみが含まれますが、基になるファイルには field_a
の実際の値のリストが含まれます。
Hive metastoreとUnity Catalogパイプラインを併用することはできますか?
ワークスペースには、 Unity Catalog と従来の Hive metastoreを使用するパイプラインを含めることができます。 ただし、1 つのパイプラインで Hive metastore に書き込んで Unity Catalog. Hive metastore に書き込む既存のパイプラインをアップグレードして Unity Catalog.
Unity Catalog を使用していない既存のパイプラインは、Unity Catalog で構成された新しいパイプラインを作成しても影響を受けません。 これらのパイプラインは、構成されたストレージの場所を使用して、 Hive metastore にデータを引き続き保持します。
このドキュメントで特に指定されていない限り、既存のデータ ソースと Delta Live Tables 機能はすべて、 Unity Catalogを使用するパイプラインでサポートされます。 Python インターフェイスと SQL インターフェイスはどちらも、 Unity Catalogを使用するパイプラインでサポートされています。
既存の機能に対する変更
Unity Catalog にデータを保持するように Delta Live Tables が構成されている場合、テーブルのライフサイクルは Delta Live Tables パイプラインによって管理されます。パイプラインはテーブルのライフサイクルとアクセス許可を管理するため、次のようになります。
テーブルが Delta Live Tables パイプライン定義から削除されると、対応する具体化されたビューまたはストリーミング テーブルのエントリは、次回のパイプライン更新時に Unity Catalog から削除されます。 実際のデータは、誤って削除された場合に回復できるように、一定期間保持されます。 データを復旧するには、マテリアライズド ビューまたはストリーミング テーブルをパイプライン定義に追加し直します。
Delta Live Tables パイプラインを削除すると、そのパイプラインで定義されているすべてのテーブルが削除されます。 この変更により、Delta Live Tables UI が更新され、パイプラインの削除を確認するように求められます。
内部バッキング・テーブル (
APPLY CHANGES INTO
のサポートに使用されるものを含む) は、ユーザーが直接アクセスすることはできません。
Delta Live Tables パイプライン から Unity Catalog のテーブルに書き込む
注
パイプラインのカタログとターゲット スキーマを選択しない場合、テーブルは 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 テーブルからのバッチ インジェスト
CREATE OR REFRESH MATERIALIZED VIEW
table_name
AS SELECT
*
FROM
my_catalog.my_schema.table1;
@dlt.table
def table_name():
return spark.read.table("my_catalog.my_schema.table")
Unity Catalog テーブルからのストリーム変更
CREATE OR REFRESH STREAMING TABLE
table_name
AS SELECT
*
FROM
STREAM(my_catalog.my_schema.table1);
@dlt.table
def table_name():
return spark.readStream.table("my_catalog.my_schema.table")
Hive metastore からデータを取り込む
Unity Catalog を使用するパイプラインは、 hive_metastore
カタログを使用して Hive metastore テーブルからデータを読み取ることができます。
CREATE OR REFRESH MATERIALIZED VIEW
table_name
AS SELECT
*
FROM
hive_metastore.some_schema.table;
@dlt.table
def table3():
return spark.read.table("hive_metastore.some_schema.table")
Auto Loader からデータを取り込む
CREATE OR REFRESH STREAMING TABLE
table_name
AS SELECT
*
FROM
read_files(
<path-to-uc-external-location>,
"json"
)
@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}")
)
テーブルの作成権限( CREATE TABLE )またはマテリアライズドビューの作成権限( CREATE MATERIALIZED VIEW )の付与
GRANT CREATE { MATERIALIZED VIEW | TABLE } ON SCHEMA
my_catalog.my_schema
TO
{ principal | user }
パイプラインのリネージを表示する
Delta Live Tables パイプライン内のテーブルのリネージは、カタログ エクスプローラに表示されます。Catalog Explorer リネージ UI には、Unity Catalog 対応パイプラインのマテリアライズドビューまたはストリーミングテーブルのアップストリームテーブルとダウンストリームテーブルが表示されます。 Unity Catalogリネージの詳細については、「Unity Catalogを使用したデータリネージのキャプチャと表示」を参照してください。
Unity Catalog対応の Delta Live Tables パイプラインのマテリアライズドビューまたはストリーミング テーブルの場合、パイプラインが現在のワークスペースからアクセス可能な場合、カタログ エクスプローラー リネージ UI は、マテリアライズドビューまたはストリーミング テーブルを生成したパイプラインにもリンクします。
ストリーミングテーブルのデータを追加、変更、または削除する
データ 操作言語 (DML) ステートメント (挿入、更新、削除、マージ ステートメントなど) を使用して、Unity Catalog に発行されたストリーミング テーブルを変更できます。 ストリーミングテーブルに対する DML クエリのサポートにより、EU 一般データ保護規則 (GDPR) のコンプライアンスのためにテーブルを更新するなどのユースケースが可能になります。
注
ストリーミングテーブルのテーブルスキーマを変更する DML ステートメントはサポートされていません。 DML ステートメントがテーブルスキーマを進化させようとしないことを確認します。
ストリーミング テーブルを更新する DML ステートメントは、Unity Catalog Databricks Runtime13.3LTS 以降を使用している共有 クラスターまたは SQL Server でのみ実行できます。
ストリーミングには追加専用のデータソースが必要なため、処理で (DML ステートメントなどによる) 変更を含むソース ストリーミング テーブルからのストリーミングが必要な場合は、ソース ストリーミング テーブルを読み取るときに skipChangeCommits フラグ を設定します。
skipChangeCommits
を設定すると、ソース テーブルのレコードを削除または変更するトランザクションは無視されます。処理にストリーミング テーブルが必要ない場合は、マテリアライズド ビュー (追加のみの制限がない) をターゲット テーブルとして使用できます。
ストリーミングテーブルのレコードを変更する DML ステートメントの例を次に示します。
行フィルターと列マスクを使用したテーブルの公開
プレビュー
この機能はパブリックプレビュー段階です。
行フィルタ を使用すると、テーブル・スキャンで行がフェッチされるたびにフィルタとして適用される関数を指定できます。 これらのフィルターにより、後続のクエリは、フィルター述部が true と評価された行のみを返すようにします。
カラム・マスク を使用すると、テーブル・スキャンでローがフェッチされるたびにカラムの値をマスクできます。 その列に対する今後のクエリでは、列の元の値ではなく、評価された関数の結果が返されます。 行フィルターと列マスクの使用の詳細については、「 行フィルターと列マスクを使用した機密性の高いテーブル データのフィルター処理」を参照してください。
行フィルタと列マスクの管理
マテリアライズド ビューとストリーミング テーブルの行フィルターと列マスクは、 CREATE OR REFRESH
ステートメントを通じて追加、更新、または削除する必要があります。
行フィルターと列マスクを使用してテーブルを定義する詳細な構文については、「 Delta Live Tables SQL 言語リファレンス 」と 「Delta Live Tables Python 言語リファレンス」を参照してください。
振舞い
Delta Live Tables パイプラインで行フィルターまたは列マスクを使用する場合の重要な詳細は次のとおりです。
所有者として更新: パイプラインがマテリアライズド ビューまたはストリーミング テーブルを更新すると、行フィルターおよび列マスク関数がパイプライン所有者の権限で実行されます。 つまり、テーブルの更新では、パイプラインを作成したユーザーのセキュリティ コンテキストが使用されます。 ユーザー コンテキストをチェックする関数 (
CURRENT_USER
やIS_MEMBER
など) は、パイプライン所有者のユーザー コンテキストを使用して評価されます。クエリ: マテリアライズド ビューまたはストリーミング テーブルをクエリする場合、ユーザー コンテキストをチェックする関数 (
CURRENT_USER
やIS_MEMBER
など) は、呼び出し元のユーザー コンテキストを使用して評価されます。 このアプローチでは、現在のユーザーのコンテキストに基づいて、ユーザー固有のデータセキュリティとアクセス制御が適用されます。行フィルターと列マスクを含むソース テーブルに対してマテリアライズド ビューを作成する場合、マテリアライズド ビューの更新は常に完全更新になります。 完全更新では、ソースで使用可能なすべてのデータが最新の定義で再処理されます。 このプロセスでは、ソース テーブルのセキュリティ ポリシーが評価され、最新のデータと定義を使用して適用されているかどうかを確認します。