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 以降の共有アクセスモードクラスター。

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

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

制限

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

デフォルトでは、パイプラインの所有者とワークスペース管理者のみが、Unity Catalog 対応パイプラインを実行するクラスターのドライバーログを表示できます。他のユーザーがドライバーログにアクセスできるようにするには、「管理者以外のユーザーが Unity Catalog 対応パイプラインからドライバーログを表示できるようにする」を参照してください。
Hive metastore を使用する既存のパイプラインは、 Unity Catalogを使用するようにアップグレードすることはできません。に書き込む既存のパイプラインを移行するには Hive metastoreに新しいパイプラインを作成し、データソースからデータを再取り込みする必要があります。

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

JAR はサポートされていません。サードパーティの Python ライブラリのみがサポートされています。「Delta Live Tables パイプラインの Python 依存関係の管理」を参照してください。
ストリーミングテーブルのスキーマを変更するデータ操作言語 (DML) クエリーはサポートされていません。
Delta Live Tables パイプラインで作成された具体化されたビューは、そのパイプラインの外部 (別のパイプラインやダウンストリームノートブックなど) のストリーミングソースとして使用することはできません。
パイプラインがマネージドストレージの場所を持つスキーマに発行する場合、スキーマは後続の更新で変更できますが、更新されたスキーマが以前に指定したスキーマと同じストレージの場所を使用している場合に限ります。
テーブルは、ターゲットスキーマのストレージロケーションに保存されます。スキーマの格納場所が指定されていない場合、テーブルはカタログの格納場所に格納されます。スキーマとカタログの保存場所が指定されていない場合、テーブルはメタストアのルートの保存場所に格納されます。
Catalog Explorer の [履歴 ] タブには、ストリーミングテーブルまたはマテリアライズドビューの履歴は表示されません。
LOCATION プロパティは、テーブルの定義時にはサポートされません。
Unity Catalog対応パイプラインは Hive metastoreに発行できません。

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

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 から削除されます。実際のデータは、誤って削除された場合に回復できるように、一定期間保持されます。データを回復するには、マテリアライズドビューまたは >st をパイプライン定義に追加し直します。
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 ステートメントの例を次に示します。

特定の 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 言語リファレンス」を参照してください。

振舞い

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

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

オブザーバビリティ

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

Delta Live Tablesパイプライン で Unity Catalog を使用する

要件

制限