概要

dbt モデルを変更するプルリクエスト (PR) を開くと、Data Observability の CI/CD チェックが自動的に実行されます。これらのチェックにより、変更をマージしても安全かどうかを判断するために必要な情報が得られます。

Datadog は結果を PR へのコメントとして投稿し、新しい変更をプッシュするたびにそのコメントが更新されます。詳細なレポートも Datadog 上で確認でき、PR のコメント内にそのレポートへのリンクが記載されます。

チェックの種類

Impact Lineage

Impact Lineage は、変更された dbt モデルの下流にあるすべての要素を含むグラフを構築します。マージ前にこの機能を使用して、変更による影響範囲を評価できます。変更したモデルに依存しているテーブル、ダッシュボード、その他のコンシューマーを特定し、適切な所有者にレビューを依頼することができます。

Datadog によるリネージグラフの構築や操作方法の詳細については、「リネージ」を参照してください。

Drift Detection

Drift Detection は、一連の統計的チェックを用いて、変更前後のモデルによって生成されるデータを比較します。この機能を使用することで、モデルの変更が期待どおりの出力を生成しているかを確認したり、行数の大幅な変動、NULL 率の変化、列の値のカーディナリティの変化といった意図しない副作用を検知したりできます。

セットアップ

1. ソース管理プロバイダーと dbt プロジェクトを接続する

1. ソース管理プロバイダーを接続します。CI/CD チェックは GitHub および GitLab をサポートしています。
2. dbt モデルが実行されるサポートされているデータソースアカウントを接続します。
3. dbt Cloud または dbt Core プロジェクトを Datadog に接続します。CI/CD チェックの設定中に dbt プロジェクトを接続することもできます。

2. dbt プロジェクトとリポジトリを選択する

1. CI/CD 設定から、[Add CI/CD Checks] をクリックします。
2. チェックを追加する dbt プロジェクトを選択します。
3. そのプロジェクトのメインのジョブを選択します。これは、dbt スキーマについて最も知識を持つジョブです。
4. Datadog がソース管理プロバイダーからリポジトリを自動的に推論できない場合は、手動で選択してください。

高度な設定

dbt プロジェクトがリポジトリのルートにない場合は、高度な設定で dbt プロジェクトへのパスを指定できます。

3. チェックの設定

各チェックは個別に有効にできます。すべてのチェックを有効にすると、最も詳細なレポートが得られます。

Impact Lineage

Impact lineage は、モデルの変更によって影響を受ける可能性のある下流のアセットのグラフを生成します。

一般設定

Drift Detection

ドリフト検出は、ブランチ上のデータの現在の状態をベースラインと比較し、差異があればフラグを立てます。Datadog は、CI パイプラインからの dbt 実行をドリフト検出チェックのトリガーとして使用します。dbt Core の場合、Datadog がこれらの実行を受信できるように、CI ジョブから OpenLineage イベントを送信する必要があります。「OpenLineage のセットアップドキュメント」を参照してください。dbt Cloud の場合、[dbt Cloud] セクションの [CI Job URL] 設定で、プルリクエスト時に実行される CI ジョブを構成します。

比較を行うには、Datadog が CI ジョブによって作成されたテーブルを読み取れる必要があります。Snowflake のセットアップ時に作成したロール (デフォルトでは DATADOG_ROLE) には、CI ジョブがモデルをマテリアライズするデータベースに対する USAGE および SELECT 権限が必要です。Datadog の Snowflake インテグレーション設定には grant_database_access プロシージャが含まれており、これにより対象データベース内のすべてのスキーマにある現在および将来のすべてのテーブルとビューに対して、これらの権限が付与されます。CI ジョブが書き込みを行うデータベースに対して、このプロシージャを実行します。

CALL grant_database_access('["<CI_DATABASE>"]', '<ROLE_NAME>');

CI がプルリクエストごとに一時的なデータベースを作成する場合は、新しいデータベースが読み取り可能になるように、そのプロビジョニングステップの一部として当該プロシージャを呼び出してください。プロシージャの定義については、「Snowflake セットアップ」を参照してください。このアクセス権がない場合、Datadog は CI 実行を受信しても CI テーブルをクエリできず、ドリフト検出は失敗します。

dbt Core の場合、ドリフト検出には、sourceCodeLocation ファセットを通じて OpenLineage イベントにプルリクエスト番号を付加することも必要です。これには、openlineage-dbt バージョン 1.46.0 以降と OPENLINEAGE__FACETS__SOURCE_CODE_LOCATION__DISABLED=false 環境変数が必要です。「環境変数の設定」を参照してください。dbt Core CI ジョブがコンテナ内で実行される場合は、追加の設定が必要です。「コンテナ内で dbt Core CI ジョブを実行する」セクションを参照してください。

一般設定

dbt Cloud

dbt Core

コンテナ内で dbt Core CI ジョブを実行する

dbt Core CI ジョブが CI ランナーによって起動されるコンテナ内で実行される場合 (例: docker run を使用してジョブを実行する GitHub Actions ワークフローなど)、コンテナは CI ランナーから git コンテキストを継承しません。その結果、リポジトリ URL、コミット SHA、プルリクエスト番号が自動的に検出されず、それらの情報が含まれない状態で sourceCodeLocation ファセットが送信されます。Datadog はこれらの値を使用して、実行と作成または更新したプルリクエストを照合するため、これらの値がないとプルリクエストにドリフト結果が表示されません。

以下の例では GitHub Actions を使用しています。他の CI プロバイダーでは環境変数名は異なりますが、アプローチは同じです。CI ランナー上で値を読み取り、それらをコンテナに明示的に渡します。

# On the CI runner, before launching the container:
PR_NUMBER=$(jq -r '.pull_request.number'  "$GITHUB_EVENT_PATH")
HEAD_SHA=$(jq -r '.pull_request.head.sha' "$GITHUB_EVENT_PATH")   # the pull request's head commit, not the merge commit
REPO_URL="${GITHUB_SERVER_URL}/${GITHUB_REPOSITORY}"

docker run \
  -e OPENLINEAGE__FACETS__SOURCE_CODE_LOCATION__DISABLED=false \
  -e OPENLINEAGE__FACETS__SOURCE_CODE_LOCATION__REPO_URL="$REPO_URL" \
  -e OPENLINEAGE__FACETS__SOURCE_CODE_LOCATION__PULL_REQUEST_NUMBER="$PR_NUMBER" \
  -e OPENLINEAGE__FACETS__SOURCE_CODE_LOCATION__VERSION="$HEAD_SHA" \
  <YOUR_IMAGE> <YOUR_DBT_OL_COMMAND>

ワークフローは、プルリクエストが開かれたとき、または更新されたときに実行される必要があります。

on:
  pull_request:
    types: [opened, synchronize, reopened]

参考資料

役立つドキュメント、リンク、記事:

Data Observability の概要ドキュメント データカタログドキュメント リネージドキュメント Quality Monitoringドキュメント Jobs Monitoringドキュメント