1つの DLT パイプライン内で 複数のカタログとスキーマに公開することが可能になりました！

Delta Live Tables（DLT） は、Databricks 内で 信頼性が高く、保守しやすく、テスト可能なデータ処理パイプラインを構築するための強力なプラットフォーム を提供します。宣言型フレームワーク を活用し、最適な サーバーレスコンピュートを自動プロビジョニング することで、ストリーミング処理やデータ変換、管理の複雑さを軽減し、現代のデータワークフローにおける スケーラビリティと効率性 を実現します。

待望の新機能：1つの DLT パイプラインで複数のスキーマとカタログにテーブルを公開

この機能により、運用の複雑さを軽減し、コストを削減しながら、データ管理を簡素化 できます。従来は メダリオンアーキテクチャ（Bronze, Silver, Gold） を複数のパイプラインに分割して管理していましたが、今回の機能強化により、1つの DLT パイプラインに統合 しながら、組織やガバナンスのベストプラクティスを維持できます。

この機能強化により、以下のメリットが得られます：

パイプライン構文の簡素化

• LIVE 構文不要：テーブル間の依存関係を明示するための LIVE 構文を使用せずに記述可能
• SQL に準拠した記述：完全修飾名や部分修飾名がサポートされ、USE SCHEMA や USE CATALOG コマンドを使用可能

運用の複雑さを軽減

• 単一の DLT パイプラインで全テーブルを処理・公開 できるため、スキーマやカタログごとに個別のパイプラインを作成する必要がなくなる

コスト削減

• ワークロードの統合により、インフラのオーバーヘッドを最小化 できる

可観測性の向上

• Unity Catalog メタストアにイベントログを標準テーブルとして公開 し、監視・ガバナンスを強化

この新機能により、Databricks ユーザーは よりシンプルかつ効率的なデータ管理 を実現でき、データパイプラインの運用負荷を軽減しながら、スケーラブルなデータ基盤を構築 できます。

「1つの DLT パイプラインから複数のカタログおよびスキーマに公開できる機能と、LIVE キーワードが不要になったことで、パイプラインのベストプラクティスを標準化し、開発の効率化を図ることができました。また、非 DLT ワークロードから DLT へのチームの移行が容易になり、大規模な企業でのツール導入の一環として非常に役立っています。」

— Ron DeFreitas, 主任データエンジニア、HealthVerity

はじめかた

パイプラインの作成

UI から作成したすべてのパイプラインは、複数のカタログとスキーマをサポート するようにデフォルト設定されています。パイプラインレベルで、UI、API、または Databricks Asset Bundles（DABs）を通じて、デフォルトのカタログとスキーマを設定できます。

UI からの操作方法：

1. 通常通り新しいパイプラインを作成します。
2. パイプライン設定でデフォルトのカタログとスキーマを設定します。

API からの操作方法

パイプラインをプログラムで作成する場合、PipelineSettings 内でスキーマフィールドを指定することによって、この機能を有効にできます。これにより、既存のターゲットフィールドが置き換えられ、データセットが複数のカタログとスキーマに跨って公開できるようになります。

この機能を有効にしたパイプラインを API 経由で作成するためのコードサンプルは以下の通りです（注：パーソナルアクセストークン 認証をワークスペースに対して有効にする必要があります）。

スキーマフィールドを設定することで、パイプラインは自動的にテーブルを複数のカタログとスキーマに公開できるようになり、LIVE キーワードは必要なくなります。

DAB からの操作方法

1. Databricks CLI のバージョンが v0.230.0 以上 であることを確認してください。もし古いバージョンの場合は、ドキュメンテーションに従って CLI をアップグレードしてください。
2. Databricks Asset Bundle（DAB）環境のセットアップ をドキュメンテーションに従って行います。この手順を踏むことで、Databricks CLI から生成された DAB ディレクトリが作成され、そこにすべての設定ファイルとソースコードファイルが含まれます。
3. 以下のパスにある YAML ファイル を見つけて、DLT パイプライン を定義します。
   <your dab folder>/<resource>/<pipeline_name>_pipeline.yml
4. パイプライン YAML ファイル内でスキーマフィールドを設定し、もし存在する場合はターゲットフィールドを削除します。
5. 「databricks bundle validate」コマンドを実行して、DAB の設定が正しいかを検証します。
6. 「databricks bundle deploy -t <environment>」コマンドを実行して、最初の DPM パイプラインをデプロイします！

「この機能は、私たちが期待していた通りに動作します！DLT 内で、異なるデータセットを ステージ、コア、UDM スキーマ（基本的にブロンズ、シルバー、ゴールドのセットアップ）に分割することができました。すべてを1つのパイプラインで実現できました。」

— Florian Duhme, エキスパートデータソフトウェア開発者、Arvato

複数のカタログとスキーマへのテーブルの公開

パイプラインがセットアップされたら、SQL と Python の両方で完全修飾名または部分修飾名を使用してテーブルを定義 できます。

SQLの例

Pythonの例

データセットの読み取り

データセットは、完全修飾名または部分修飾名を使用して参照できます。LIVE キーワードは後方互換性のためにオプションです。

SQLの例

Pythonの例

API の動作変更

この新しい機能により、主要な API メソッドが更新され、複数のカタログとスキーマをよりシームレスにサポート できるようになりました。

dlt.read() そして dlt.read_stream()

これらのメソッドは以前、現在のパイプライン内で定義されたデータセットのみを参照できました。しかし、今回の更新により、複数のカタログとスキーマをまたいだデータセット を参照できるようになり、必要に応じて依存関係を自動的に追跡します。これにより、異なる場所からデータを統合するパイプラインを、追加の手動設定なしで簡単に作成できるようになります。

spark.read() と spark.readStream()

これらのメソッドは以前、外部データセットを明示的に参照する必要があり、クロスカタログクエリが煩雑 でした。今回の更新により、依存関係が自動的に追跡され、LIVE スキーマがもはや必要なくなりました。これにより、単一のパイプライン内で複数のソースからデータを読み取るプロセスが簡素化されました。

USE CATALOGとUSE SCHEMAの使用

Databricks SQL 構文 は、アクティブなカタログとスキーマを動的に設定することをサポートし、複数の場所でデータを管理するのが容易 になりました。

SQLの例

Pythonの例

Unityカタログでのイベントログの管理

この機能により、パイプラインの所有者は Unity Catalog メタストア にイベントログを公開して、可観測性を向上 させることができます。これを有効にするには、パイプライン設定のJSONでevent_logフィールドを指定します。

例をいくつかご紹介します。

これにより、通常のテーブルと同様に、イベントログテーブルに対してGRANTSを発行することができます：

また、イベントログテーブル上にビューを作成することもできます：

上記すべてに加えて、イベントログテーブルからストリームすることも可能です：

今後の展望

今後、これらの機能強化は、UI、API、または Databricks Asset Bundles を通じて作成されたすべての新しいパイプラインのデフォルトとなります。さらに、既存のパイプラインを新しい公開モデルに移行するためのツール が近日中に提供される予定です。

詳細については、こちらのドキュメント をご覧ください。