単一のDLTパイプラインから複数のカタログとスキーマに発行

DLTは、Databricks内で信頼性が高く、保守可能で、テスト可能なデータ処理パイプラインを構築するための堅牢なプラットフォームを提供します。宣言型のフレームワークと最適なサーバーレスコンピューティングの自動プロビジョニングを活用することで、DLTはストリーミング、データ変換、および管理の複雑さを簡素化し、最新のデータワークフローにスケーラビリティと効率性をもたらします。

この度、待望の機能強化を発表できることを嬉しく思います。それは単一のDLTパイプライン内で複数のスキーマとカタログにテーブルを発行できる機能です。この機能により、運用上の複雑さが軽減され、コストが削減され、メダリオンアーキテクチャ（Bronze、Silver、Gold）を単一のパイプラインに統合しながら、組織的およびガバナンスのベストプラクティスを維持できるため、データ管理が簡素化されます。

この機能強化により、以下のことが可能になります。

• パイプライン構文の簡素化 – テーブル間の依存関係を示すためにLIVE構文を使用する必要がなくなりました。標準SQLと同様に、完全修飾名および部分修飾名、およびUSE SCHEMAとUSE CATALOGコマンドがサポートされます。
• 運用上の複雑さの軽減 – スキーマまたはカタログごとに個別のパイプラインを作成する必要がなくなり、単一のDLTパイプライン内ですべてのテーブルを処理および発行できます。
• コストの削減 – 複数のワークロードを単一のパイプラインに統合することで、インフラストラクチャのオーバーヘッドを最小限に抑えます。
• オブザーバビリティの向上 – イベントログをUnity Catalogメタストアの標準テーブルとして発行し、監視とガバナンスを強化します。

“1つのDLTパイプラインから複数のカタログとスキーマに発行でき、LIVEキーワードが不要になったことで、パイプラインのベストプラクティスを標準化し、開発作業を合理化し、大規模なエンタープライズでのツールの導入の一環として、チームが非DLTワークロードからDLTへ簡単に移行できるようになりました。” —Ron DeFreitas, Principal Data Engineer, HealthVerity

はじめに

パイプラインの作成

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

UIから:

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

APIから:

プログラムでパイプラインを作成する場合、PipelineSettingsのschemaフィールドを指定することでこの機能を有効にできます。これは既存のtargetフィールドを置き換えるもので、データセットが複数のカタログやスキーマに発行されることを保証します。

API経由でこの機能を持つパイプラインを作成するには、次のコードサンプルに従ってください（注意: ワークスペースでPersonal Access Token認証が有効になっている必要があります）:

schemaフィールドを設定することで、LIVEキーワードを必要とせずに、パイプラインは自動的に複数のカタログとスキーマへのテーブル発行をサポートします。

DABから

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

“この機能は期待どおりに動作します！DLT内のさまざまなデータセットを、単一のパイプライン内でステージング、コア、UDMスキーマ（基本的にブロンズ、シルバー、ゴールドのセットアップ）に分割できました。” —Florian Duhme, Expert Data Software Developer, 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 Catalog でのイベントログの管理

この機能により、パイプラインオーナーはイベントログを Unity Catalog メタストアに発行して、オブザーバビリティを向上させることができます。これを有効にするには、パイプライン設定 JSON で event_log フィールドを指定します。例:

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

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

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

今後の予定

今後、これらの機能強化は、UI、API、または Declarative Automation Bundles を介して作成されたすべての新規パイプラインでデフォルトで有効になります。さらに、既存のパイプラインを新しい発行モデルに移行するための移行ツールも近日中に提供される予定です。

ドキュメントで詳細を読む こちら。

(このブログ記事はAI翻訳ツールを使用して翻訳されています) 原文記事