ビットキーでアナリティクスエンジニアをしている三河内です
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ではチェックが走るようになります。問題ないと以下のようになる
  - 例えばチェックがコケると以下のようになり、ガイドラインを遵守していない場合のマージを防ぐことができるようになります
- この時点でカバレッジ向上を仕組みで実現できたことになりました！！！

おまけ：カバレッジ可視化する（本当は最初にやりたかったやつ）

ここまでのアプローチはテストなどをrequiredにすることでカバレッジを向上するアプローチでした
でも本当は素直にカバレッジを計測し、それをもとにガバナンスを効かせて行きたかったです
それが実現できそうなのが、dbt-coverageというPythonライブラリでした
- dbt Coreの場合、柔軟な実装が可能なのでこのアプローチを取るかな？と思ってます
- 単純に計測してカバレッジを上げていくモチベを作るというアプローチをとるならこれでも良いかなと思います
  - ただカラム数が分母に計算されるのが、残念かなあという所感はありますが

今回はdbt Cloudなのでマージ後にCIでカバレッジを計測する仕組みを紹介します

github actionsで以下のように実装するだけで可能です
dbt docs generateをして最新のcatalog.jsonが必要なので、各々のやり方、github actions上で認証し実行しましょう
- 例：https://docs.getdbt.com/docs/core/connect-data-platform/bigquery-setup

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的な活動）

ビットキーのデータ活用に興味がある方は是非devトークしましょう！

https://jobs.qiita.com/employers/240/dev_talks/441