- ビットキーでアナリティクスエンジニアをしている三河内です
- 2022年10月からdbtを用いたデータ分析基盤開発に取り組んでいます
- dbtのアドベントカレンダーが開催されるということで、現時点で日本語記事がなさそうな
カバレッジ周りに関して、記事を書いてみようと思います
想定読者
-
dbt Cloudを使っている方
dbt Coreを使われている方、この記事とは異なるアプローチになるかなと思うので、ご参考程度に🙇
TL;DR
-
テストやメタデータの付与を継続的に行うにはカバレッジ向上の仕組みが必要だと思っている - dbt Cloudにおいてはdbt_meta_testingというライブラリを用いるのが良さそう（なのでそれを紹介します）
- おまけで、dbt-coverageというPythonライブラリをgithub actionsで走らせて、
カバレッジを計測する方法を紹介します
目次
前提条件
本記事の背景
解決策：dbt Cloudでカバレッジ向上をするには
まとめ
さいごに採用的な話
前提条件：筆者の利用環境
- dbt Cloud
- なのでPythonライブラリが記事作成時点では使えません（たぶん・・・）
- デプロイ
- github × dbt Cloud上のCI環境
- その他
- github actionsを活用してます
- 本記事では、jaffle shopのデータとmodelをサンプルとして使っています（少し加工しつつ）
本記事の背景：テストやメタデータの付与を継続的に行うにはカバレッジ向上の仕組みが必要だよね
- dbtの代表的な導入目的の中に
テストやメタデータの付与があると思います - けど、いざ開発を始めると、これらって継続的に続けられるの？絶対なあなあになるよね って思いました
- なので、一定のガバナンスを利かせられないかなと思い、
カバレッジ向上の方法を模索してみました
注意：利用環境的な前提により、この後の解決策で取りうる手段がだいぶ異なってくるんじゃないかと思ってます
またライブラリ群もどんどん進化していくので、都度情報のアップデートが必要かなと思ってます・・・ご了承ください🙇
解決策：dbt Cloudでカバレッジ向上をするには
まず、テストとドキュメンテーションに関するガイドラインを定めましょう
- 今回のアプローチではrequiredとされるルールを定義し、それが遵守されているかチェックする形をとるためです
- この時点では社内ドキュメントか何かで残しておきます
- 今回のサンプル環境では以下のようなガイドラインを仮で定めました
- staging層では、いずれかの列に対して、ユニークチェックとnot nullチェックを必須とする
- mart層では、全カラムに対してdescriptionを残す
- 最後にガイドラインに則って、schema.ymlにテストやスキーマ情報を記載しておきます
次にこのガイドラインが守れているかをチェックできるように実装します
-
今回は、dbt_meta_testingというライブラリを使いました
-
導入方法
-
packages.ymlを定義し、dbt depsするだけです- 詳細はdbt_meta_testingのInstallの部分
-
-
次にチェックするルールを定義します
-
dbt_project.ymlに定義します
models: jaffle_shop: staging: # required_testsはmodelごとにチェックされる +required_tests: "unique.*": 1 "not_null": 1 materialized: view marts: # required_docsはcolumnレベルでチェックされる。全カラムにdescriptionを残すルールになっているマート層に適用する +required_docs: true- 詳細はdbt_meta_testingのConfigurationsの部分
- dbt Cloud上のCLIでチェックを走らせてみます
# テストに対するチェック $ dbt run-operation required_tests # ドキュメンテーションに対するチェック $ dbt run-operation required_docs- Passすると
Success: required_docs passed.こんなログが吐かれます- テストだと
Success. required_tests passed.
- テストだと
- 詳細はdbt_meta_testingの
Usageの部分。特定のmodelを指定してチェックするとかも可能です - 次にPull Request時に実行されるCI環境（dbtのjob側）でもチェックを走らせてみます
- まずはjobの設定で
dbt run-operationコマンドを追加します
- そうすると、以降のPRではチェックが走るようになります。問題ないと以下のようになる
- 例えばチェックがコケると以下のようになり、ガイドラインを遵守していない場合のマージを防ぐことができるようになります
- まずはjobの設定で
- この時点でカバレッジ向上を仕組みで実現できたことになりました！！！
-
おまけ：カバレッジ可視化する（本当は最初にやりたかったやつ）
- ここまでのアプローチはテストなどをrequiredにすることでカバレッジを向上するアプローチでした
- でも本当は素直にカバレッジを計測し、それをもとにガバナンスを効かせて行きたかったです
- それが実現できそうなのが、dbt-coverageというPythonライブラリでした
- dbt Coreの場合、柔軟な実装が可能なのでこのアプローチを取るかな？と思ってます
- 単純に計測してカバレッジを上げていくモチベを作るというアプローチをとるならこれでも良いかなと思います
- ただカラム数が分母に計算されるのが、残念かなあという所感はありますが
- 今回はdbt Cloudなのでマージ後にCIでカバレッジを計測する仕組みを紹介します
- github actionsで以下のように実装するだけで可能です
-
dbt docs generateをして最新のcatalog.jsonが必要なので、各々のやり方、github actions上で認証し実行しましょう
name: coverage checking on: push: branches: [main] jobs: # https://github.com/slidoapp/dbt-coverage coverage_check: name: coverage checking runs-on: ubuntu-latest steps: - uses: "actions/checkout@v3" - uses: "actions/setup-python@v2" with: python-version: "3.9" - name: Authenticate run: "hogehoge" - name: Install Install Library run: | pip install dbt-coverage dbt-bigquery dbt deps - name: dbt docs generate run: dbt docs generate - name: coverage doc run: "dbt-coverage compute doc --cov-report coverage-doc.json" # テストのほうが列レベルで計測、評価されるので、今回のガイドラインには適していない・・・ - name: coverage test run: "dbt-coverage compute test --cov-report coverage-test.json" # チェック対処を絞り込むなら - name: coverage doc path filter run: "dbt-coverage compute doc --cov-report coverage-doc.json --model-path-filter models/marts/"- mart層に対するカバレッジが100%であることを可視化できました
まとめ
- dbt_meta_testingを使うことでdbt Cloudでカバレッジ向上の仕組みを取り入れることができました
- dbt-coverageをCIで走らせることでカバレッジ計測することができました。良さげなライブラリなので今後に期待したいです
（さいごに採用的な話）今後のデータ分析基盤構築の展望 と devトークの紹介
- 社内のデータ分析のアジリティを更に上げていきたいと思っており、2023年はdbt開発を軸に以下に取り組んでいく予定です
- 全事業ドメインのデータをdbtに移行し、データ提供のアジリティを加速させる
- データ分析基盤をビジネス側にも提供していく。誰でも「
select * from hoge where〜」でデータを抽出し、分析が開始できるように
- 関連してデータパイプラインの品質のモニタリングと向上をしていきたいと思ってます（DRE的な活動）