Delta Live Tables パイプラインの開発とテストに関するヒント、推奨事項、および機能

この記事では、Delta Live Tables パイプラインの開発とテストに使用できるパターンについて説明します。 Delta Live Tables では、パイプラインの設定を通じて、開発、テスト、運用の各環境でパイプラインを分離するための構成を指定できます。 この記事の推奨事項は、SQL と Python のコード開発に適用されます。

Databricks では、パラメーターを使用して拡張可能な Delta Live Tables コードを記述することをお勧めします。 これは、開発、テスト、および prod 環境の間で移植可能なコードを記述する場合に特に便利です。 たとえば、コードの回復性をテストするために、既知の問題を含むテスト データでパイプラインをポイントできます。 「パラメーターを使用してデータ ソースを制御する」を参照してください。

開発モードを使用してパイプラインの更新を実行する

Delta Live Tables には、パイプラインの更新を開発モードと運用モードのどちらで実行するかを制御する UI トグルがあります。 このモードでは、以下を含むパイプラインの更新の処理方法を制御します。

  • 更新が成功または失敗した後、開発モードによってコンピューティング リソースが直ちに終了することはありません。 クラスターの起動を待たずに、同じコンピューティング リソースを再利用して複数のパイプライン更新を実行できます。
  • 開発モードでは、タスクの失敗時に自動的に再試行されません。これにより、パイプライン内の論理エラーまたは構文エラーをすぐに検出して修正できます。

Databricks では、開発およびテスト中に開発モードを使用することをお勧めします。 ただし、運用環境にデプロイする場合は、常に運用モードに切り替えてください。

開発と運用のモード」を参照してください。

テーブルの更新を待たずにパイプラインのソース コードをテストする

開発中やテスト中に、構文や分析のエラーなど、パイプラインのソース コードに関する問題を確認するには、更新の検証を実行できます。 更新の Validate は、テーブルに対する実際の更新を実行せずにパイプライン ソース コードの正しさのみを検証するため、実際のパイプライン更新を実行する前に、問題をより迅速に特定して修正できます。

開発ライフサイクルの全フェーズでターゲット スキーマを指定する

Delta Live Tables パイプライン内のすべてのデータセットは、パイプラインの外部からアクセスできない LIVE 仮想スキーマを参照します。 ターゲット スキーマが指定されている場合、LIVE 仮想スキーマはターゲット スキーマを指し示します。 更新中に各テーブルに書き出された結果を確認するには、ターゲット スキーマを指定する必要があります。

環境に固有のターゲット スキーマを指定する必要があり、 特定のスキーマ内の各テーブルは、単一のパイプラインでのみ更新できます。

これらの環境を分離するには、異なるターゲットを持つ開発、テスト、運用用に個別のパイプラインを作成します。 ターゲット スキーマ パラメーターを使用すると、文字列補間またはその他のウィジェットやパラメーターを使ってデータ ソースとターゲットを制御するロジックを削除できます。

Unity カタログを Delta Live Tables パイプラインと共に使用するおよび従来の Hive メタストアで Delta Live Tables パイプラインを使用するを参照してください。

Databricks Git フォルダーを使用して Delta Live Tables パイプラインを管理する

Databricks では、Delta Live Tables パイプラインの開発、テスト、運用環境へのデプロイ中に Git フォルダーを使用することが推奨されます。 Git フォルダーを使用すると、次のことが可能になります。

  • 時間の経過に伴うコードの変化の追跡。
  • 複数の開発者が行っている変更をマージする。
  • コード レビューなどのソフトウェア開発プラクティス。

Databricks では、パイプラインに関連するすべてのコードに対して単一の Git リポジトリを構成することをお勧めしています。

各開発者は、開発用に独自の Databricks Git フォルダーを構成する必要があります。 開発中に、ユーザーは Databricks Git フォルダーから独自のパイプラインを構成し、開発データセットと分離されたスキーマおよび場所を使用して新しいロジックをテストします。 開発作業が完了すると、ユーザーは変更をコミットして中央の Git リポジトリのブランチにプッシュし、テストまたは QA ブランチに対するプル要求を開きます。

結果のブランチは Databricks Git フォルダーでチェックアウトする必要があり、テスト データセットと開発スキーマを使用してパイプラインを構成する必要があります。 ロジックが想定どおりに実行されると仮定すると、変更を運用にプッシュするための pull request またはリリース ブランチを準備する必要があります。

Git フォルダーを使用して複数の環境でコードを同期できますが、パイプライン設定は手動で最新の状態に維持するか、Terraform などのツールを使用する必要があります。

このワークフローは、すべての Databricks ジョブで CI/CD に Git フォルダーを使用するのと似ています。 「Git と Databricks Git フォルダー (Repos) を使用した CI/CD 手法」を参照してください。

インジェストと変換の手順のソース コードをセグメント化する

Databricks では、データをエンリッチして検証する変換ロジックから、データを取り込むクエリを分離することをお勧めしています。 運用データ インジェスト ロジックとは別のディレクトリ内の開発データ ソースまたはテスト データ ソースからデータを取り込むためのソース コードを整理する場合は、それらの環境に固有のデータセットを使用して、さまざまな環境のパイプラインを構成できます。 たとえば、テストに小さなデータセットを使用して開発を高速化できます。 「開発およびテスト用のサンプル データセットを作成する」を参照してください。

パラメーターを使用して、開発、テスト、運用向けのデータ ソースを制御することもできます。 「 デルタ ライブ テーブル パイプラインでパラメーターを使用するを参照してください。

Delta Live Tables パイプラインでは、すべてのデータセット リレーションシップを管理するために LIVE 仮想スキーマが使用されるため、サンプル データを読み込むインジェスト ソース コードを使用して開発パイプラインとテスト パイプラインを構成することで、運用テーブル名を使用してサンプル データセットを置き換えてコードをテストできます。 すべての環境で同一の変換ロジックを使用できます。

開発およびテスト用のサンプル データセットを作成する

Databricks では、開発データセットとテスト データセットを作成して、予想されるデータと、形式が正しくないレコードや破損している可能性のあるレコードを含むパイプライン ロジックをテストすることをお勧めします。 開発とテストに役立つデータセットを作成するには、次を含む複数の方法があります。

  • 運用データセットからデータのサブセットを選択する。
  • PII を含むソースには、匿名化されたデータや人為的に生成されたデータを使用する。
  • ダウンストリーム変換ロジックに基づいて、適切に定義された結果を含むテスト データを作成する。
  • データ スキーマの想定から外れるレコードを作成し、潜在的なデータの破損、形式に誤りがあるレコード、アップストリーム データの変更を予測する。

たとえば、次のコードを使用してデータセットを定義するノートブックがあるとします。

CREATE OR REFRESH STREAMING TABLE input_data AS SELECT * FROM read_files("/production/data", "json")

次のようなクエリを使用して、特定のレコードを含むサンプル データセットを作成できます。

CREATE OR REFRESH MATERIALIZED VIEW input_data AS
SELECT "2021/09/04" AS date, 22.4 as sensor_reading UNION ALL
SELECT "2021/09/05" AS date, 21.5 as sensor_reading

次の例は、パブリッシュされたデータをフィルター処理して、開発またはテストのために運用データのサブセットを作成する方法を示しています。

CREATE OR REFRESH MATERIALIZED VIEW input_data AS SELECT * FROM prod.input_data WHERE date > current_date() - INTERVAL 1 DAY

こうしたさまざまなデータセットを使用するには、変換ロジックを実装するノートブックを使用して複数のパイプラインを作成します。 各パイプラインは LIVE.input_data データセットからデータを読み取ることができますが、環境に固有のデータセットを作成するノートブックを含めるように構成されています。