dbtのリポジトリの新規作成時によくやる設定まとめ

会社のAdvent Calendarもdatatech-jp Advent Calendar 2024も枠がめでたく埋まってしまったので、12月感は特にないエントリです。

仕事でdbtのリポジトリの初期設定をすることが時々あるけど、ほぼ同じようなことをやっているので、さっと引用できるようにまとめておきます。この辺をやっておくと、大体安心して仕事ができる、という感覚になります。なお、dbtに関連ないチーム開発で必要な要素も入ってます。

優先度: 高い
優先度: 普通
優先度: 低い
- dbt-osmosisの設定をしておく
- elementaryの設定をしておく
まとめ

優先度: 高い

リポジトリの権限設定

Branch protection rulesやセキュリティ系の修正は気軽にされると困るので、リポジトリオーナーやセキュリティチームなど必要なメンバーに絞ります。

チーム開発をするのであれば、mainブランチへの直接のcommitを禁止にしておく、mergeする前にレビューを必須にしておく、などの設定もやっておくとよいでしょう。

CODEOWNERの設定

リポジトリのCODEOWNERを設定しておきましょう。CODEOWNERのレビュー必須化を入れることで意図せぬmergeを防いだり、他チームから見て誰とコミュニケーションを取ればよいかが明確になります。

Pull Requestテンプレートの導入

Pull Requestのdescriptionはかなり重要です。どういう意図で修正しようとしたか、などはcommitなどからは追いにくい場合もあります。人によらずdescriptionで必要な項目を入れてもらうために、Pull Requestテンプレートは初手で導入しておくのがよいでしょう。

リポジトリの設定初期はどうしてもコード量が多くなりがちで、git blameなどで歴史を遡ったりしている際に出くわすことが多いですが、その際にPull Requestのdescriptionが空だと虚無な気持ちになってしまうことが多いです。早い段階で導入しましょう。

sqlfmt / sqlfluffの導入

チーム開発をする上でSQLファイルのフォーマットが微妙に違うのはストレスの元になります。sqlfmt / sqlfluffは初期段階からGitHub Actionsなどで動くように設定しましょう。

sqlfmtのほうがお手軽ではあるので、どちらか一つ選べと言われたらsqlfmtを選ぶかなと思います。余力があればsqlfluffでリッチなルールを設定してもいいですね。

「なぜ導入するのか?」については同僚のtenajimaさんが昔エントリを書いてくれているので、そちらを参照してください。

優先度: 普通

READMEの記載

リポジトリの立ち上げ時期は一人で開発することも多いと思いますが、途中からメンバーが参加することも多いと思います。dbtのリポジトリでいえば、一人目はデータエンジニアがやっていたけど、二人目以降にアナリティクスエンジニアやアナリストがDWHやデータマートの開発に参加することになった、などですね。

そういった際に新規のメンバーが迷子にならないようにREADMEを記載しておきましょう。最初からREADMEをきっちり書くのは大変かもしれませんが、初期に記載すべき項目は例えば

このリポジトリはどういったものか、どういった目的やプロジェクトのためのものか
- 関連するNotionやwikiなどのページがあればリンクを貼る
- Design DocsやADRなどがあればそのリンクも貼る
dbt Cloudの設定(devおよびprod)
手元での動作方法
- dbtの場合はdbt deps && dbt runくらいで動くので、あんまり迷うことはないかな...
- 開発に必要な権限(例えばroles/bigquery.jobUserやroles/bigquery.dataEditor)などがまとまっているとつまづきポイントを減らせるでしょう

などでしょうか。README自体に内容を書くというより、簡潔なサマリーや重要なポインタへのリンクがあるといいですね。

リポジトリのREADMEはセキュリティチームなど他チームも見ることも多いので、そういったチームに対してもリポジトリの立ち位置が分かるようにしましょう。

dbt CloudでのCI/CDの設定

dbt Cloudを使うと、Pull Requestに伴なう差分のテストなどをCIで簡単に設定できます。コードだけでなく、実際のデータを使ったテストも行なわれているとレビューを安心して行なうことができるので、これも初期で設定しましょう。CDも同様ですね。

もちろん、dbt CloudではなくGitHub Actionsや独自のバッチ環境でCI/CDの設定を行なえると思うので、是非やりましょう(設定としてはdbt Cloudのほうが簡単ではあると思います)。

sqlfmt / sqlfluffの導入しているのであれば、CIでもチェックするようにしておくと安心です。

レイヤリングのルールを決めておく

最初期では決め切れないことがあるとは思いますが、ある程度形になってくる前までに決めておきたいのがレイヤリングのルールです。dbtのベストプラックティスに従うのか、それ以外の独自のレイヤリングにするのか、どのレイヤーからどのレイヤーは参照していいのか、ユーザーに公開するのはどのレイヤーにするか、などは本運用に乗る前には決めておきたいルールになるかと思います。

dbtのベストプラックティスやメダリオンアーキテクチャ、Data Vaultなど色々ありますが、該当リポジトリ特徴や開発で必要になる複雑さなどに応じて適切なものを選択しましょう。

レビュー依頼の通知設定

リポジトリを新規で作成した際は素早く開発を回したいことが多いでしょう。この際、Pull Requestのレビュー待ちが足枷になってはもったいないです。チーム内の朝/昼会などでレビュアーをアサインするでもよいですが、Slackに通知がくるようにしておくとよいでしょう。

Devcontainerの設定

個人的にはdbtでの開発はDevcontainerの設定を行なわずにローカル環境に入れてしまう人間ではあるのですが、それは置いといてもチーム開発ではエンジニアリングに慣れていないアナリストの方が開発に関わることも多いでしょう。その際、pythonやdbtの導入でつまづいてしまうのは時間がもったいないです。

dbtをDevcontainerの設定で動くようにする設定は難しくはないので、さっとやっておくとよいでしょう。sqlfmt / sqlfluffのインストールやPower User for dbtといった拡張のインストールもDevcontainerで済ませておくと、チーム内でのペアプロなどもはかどるでしょう。

コストの監視

新規のdbtのリポジトリを作成した際はCI/CDなどで新規のサービスアカウントを設定することになると思いますが、該当サービスアカウントがどれくらいコストを使っているかの監視をできるようにしておきましょう。リポジトリ毎に監視するのも大変なので、この辺は全社の基盤として設定しておくのがいいですね。

...えっ、既存のサービスアカウントを使い回す?将来の自分やチームメイトから殴られる原因になるので、本当にやめておきましょう。リポジトリが太り始めたり、本格運用になってからサービスアカウントを切り替えるのは大変になるだけです。悪いことは言わないから、今のうちにやっておくのです。

Renovateの設定を行ない、ライブラリのバージョンを上げやすくする

Renovateはライブラリのバージョンのアップデートを行なうPull Requestを作ってくれる頼もしいやつです。ライブラリを上げると何かが壊れることも多いので、アップデート作業はおっくうになりがちですが、溜め込むとさらにおっくうになります。アップデートを溜め込んでしまって、メジャーバージョンアップデートを含む大量の差分をアップデートしなければならない状況のことをビックバンアップデートと個人的に呼んでいますが、ビックバンアップデートをするときは大抵何かぶち壊れます。巨大な差分の中から関連する修正項目を探しにいくのは、その日の他の仕事のやる気を消し去ってしまうくらい面倒なことが多いです。差分が小さいうちに日頃から少しずつ上げておくと、いざというときにbitsecする範囲を狭くできるので、きちんとやっておきましょう。

Renovateは自分が好きなので書いてますが、同じようなことができるならdependabotでも何でもいいです。

dbt関連のライブラリは{sqlfluff, sqlfluff-templater-dbt}や{dbt-core, dbt-bigquery}など、グループでバージョンを上げたいものが多いと思うので、packageRulesの設定をしておくのがオススメです。

また、dbt-labs/dbt_utilsなどdbt depsでインストールできるdbtのパッケージを使うことも多いと思いますが、残念ながらrenovateはディフォルトではdbtのパッケージの面倒は見てくれません。しかし、カスタムデータソースを記述すればdbtのライブラリのバージョンアップも見てくれるようになるので、是非設定しましょう。