はじめに
こんにちは。22卒アナリティクスエンジニアの井下田(@hiroki_igeta)です。
普段からデータ基盤の整備とDWH開発はもちろん、ダッシュボード作成、広告ロジック改善にも携わっています。
--
本記事は、Rettyのデータ分析チームが約3ヶ月間取り組んできた「dbtの導入」を中心テーマとした連載 #dbtでデータの民主化 の3記事目です。
dbtの導入背景については連載記事の1つ目、dbt移行のプロジェクト進行については2つ目をそれぞれご参照いただけますと幸いです。 (Rettyではdbt導入のためにプロジェクトを立ち上げ、dbt移行を推進しました。)
- 連載記事1つ目：データアナリストがdbtを使って育てるデータマネジメント
- 連載記事2つ目：dbt移行プロジェクトを振り返ってみた
連載3記事目の本記事では、「DWHの管理を内製ツールからdbtへ移行する際に工夫した点・反省点」 について記載していきます。
本記事の想定読者
本記事は主に、次のような方に向けて書いています。
- dbtの活用事例を知りたい方 - データモデル管理をdbtに移行することを検討されている方 - Rettyのデータ分析基盤に興味がある方
前提
dbt移行プロジェクトの概要
dbt移行プロジェクト(以下、PJ)の概要についてです。箇条書きでまとめると下記のようになります。
- PJ期間：6~8月(5月時点で開発環境などは構築済み)
- PJメンバー(合計5~6名)
- データアナリスト：
- PJリーダー(@daikichi)
- メンバー(@hiro_30_1000)
- メンバー(@js_qw)
- アナリティクスエンジニア(@hiroki_igeta) ※執筆者)
- 業務委託メンバー(週1稼働)：2名 (8月からジョインの1名含む）
- データアナリスト：
PJメンバーは5~6名(業務委託含む)と多いですが、各メンバーはデータ分析など別業務と並行してのPJ進行でした。 PJに割いたリソースとしてはデータアナリストは1~2日/週、アナリティクスエンジニアは2~3日/週程度でした。
dbt移行PJの対象
今回のPJのゴールは、データ分析チームが管理しているテーブルをすべてdbt管理下に移行することでした。分析チーム管理のテーブルは下記画像のprjテーブルを除くテーブルで、一部例外はありますがスノーフレークスキーマに沿って設計されています。
ちなみにprjテーブルは各種プロジェクトのための特定用途の分析に用いるために加工されたテーブルで、分析チームではなく各プロジェクトのメンバー(PMや派遣された分析チームメンバー)が管理という棲み分けとなっております。
工夫したこと
既存のDWHをdbt管理下に置くにあたって工夫したことについて、データ分析チームを代表してまとめます。
1. DesignDocを通じた認識合わせ 2. 移行前後の再現性テストの実施 - プルリクエスト作成時のチェックリストの作成 - クエリの同一性チェック 3. 段階的なリリースを可能にする環境分け - local・dev・prodの環境を分ける
1. DesignDocを通じた認識合わせ
開発効率を高めること、BigQuery利用者の利便性向上のため、既存のDWH開発に関するDesign Docに加えてdbtのものを社内wiki内に整備しました。Design Docは主に2つの観点から構成され、個別具体のTipsは別ドキュメントにまとめる形を取っています。
A.DataModel with dbt：データモデルの全体像・各層の責務と方針
現状では一方向の依存関係の元に、3層構造の処理の流れとしています。具体的には、data Lakeを管理するための層、データ分析用途のためのデータ統合と共通化を行う層、dbt移行前のテーブルスキーマと一致させるための層の3つから成ります。
ただし、SSOTとDRYが担保されてないテーブルが一部存在しているため、中長期的には全体設計を見直すことも検討しています。
B.Development with dbt：データモデル管理のための開発方針
環境構築や開発の手順、段階的なリリースに関する説明、ファイルやテーブル名などの命名規則を定めています。
2. 移行前後の再現性テストの実施
staging層で一部のクエリが共通化されたことで変更前後の結果に差分が生じる可能性があったため、内製テストをdbtに置き換えたうえで、BigQueryUI上で対称差テストを実行して差分がないことを確認したうえで移行を行いました。対称差テストは、@na0fu3yさんのBigQuery テーブル同士の一致判定の記事を参考にさせていただきました。
audit_helperのようなdbtパッケージも参考になると思います。
3. 段階的なリリースを可能にする環境分け
Rettyでは、dbt移行後の運用も見据えて開発と本番の環境を分ける方針としています。具体的には下記の通りです。
①開発は個人ブランチのlocal環境で行う
BigQueryUI上で挙動確認を行いたい場合は、dbt <command> --target local --select <file_name>することで個人の環境、および開発用のBigQueryプロジェクトにクエリをデプロイして検証を行えるよう環境構築しています。
②挙動確認はdev環境で行う
git pushを行ったタイミングで dbt compile と dbt test、dbt runが順番に実行され、開発用のBigQueryプロジェクトにクエリがデプロイされます。デプロイ後に、開発用のBigQueryプロジェクトで挙動確認を行いプルリクエスト内に挙動確認の結果を記載し、プルリクエストのレビューをメンバーに募るワークフローとなっています。
レビューを受けプルリクエストの内容がOKとなった後に、マージを行います。マージ後は自動で dev__{テーブル名} として開発用のBigQueryプロジェクトにデプロイされます。
③全社への提供はprod環境で行う
dev環境での動作確認が済んだら、GitHubのリリース機能を用いて本番環境に prod__{テーブル名} としてデプロイを行います。これによって、全社で利用している本番環境に新規作成および変更差分が反映されます。
ただし、dbt移行にあたり並行リファクタリングを採用しているため、本番反映後も既存のテーブルへの影響はない状態で移行作業を行なっています。
（並行リファクタリングの参考記事：Refactoring legacy SQL to dbt、レガシーなSQLからdbtのSQLへのリファクタリング｜dbt Cloudで始めるデータパイプライン構築のdbt入門）
以上のように開発と本番の環境を分けたりすることで、誤ったDWHがリリースされることを減らすだけでなく、BigQuery利用者が誤って開発用のテーブルを参照することを避けてdbt移行を進めました。
反省点・苦労したこと
PJで苦労したこと・反省点は3点あります。
ymlでのテストの記述方法
dbt標準・dbt_utilsに具体例が載っていないテストの実装を行う際に、ymlファイルでのテストの記述が誤っているためにエラーが出続け時間を取られたことがありました。(ex/クォーテーションマークやカッコを入れる箇所が誤っていたり、そもそも入れ損ねていたりしました。)
今後は同様のエラーに引っかかる人が減るように、社内Wikiの拡充やQita記事など外部への発信も増やしていこうと思います。
dbtへ移行前の環境で使っていた中間（物理）テーブル削除
dbt移行に伴いテーブル名の接頭に prod__をつけるようになったことに合わせ、中間(物理)テーブルもprod__始まりのテーブルと旧環境のテーブルと並行稼働させる期間を設け移行を行いました。分析チーム管理で依存しているテーブルがすべてdbt管理下に移り変わったタイミングで旧環境の中間（物理）テーブルを削除したところ、アドホッククエリや分析チーム管理外で作成されたバッチクエリでエラーが生じる事態が発生し、関係各所への事前の共有や全てのテーブルをdbtで管理する必要性を実感しました。
dbt移行のための工数確保
連載第2弾の記事でも言及されていましたが、Rettyのdbt移行PJはデータアナリストが担っていたため主業務のデータ分析と並行してdbt移行も進める必要があり苦労しました。各メンバーが依頼者と合意を取った上で、dbt移行のための日(dbt開発day)を週1日確保することでプロジェクトの進捗を生みやすくなりました。
学び
個人的な学びとしては、3点あります。
自身が初めて触るテーブルもあり、ドメイン知識が深まった点
使ったことがなかったテーブルを触る機会となりドメイン知識が深まっただけでなく、新たなDWH開発が必要な領域と十分整ってきた領域の解像度が上がりました。また、改善の必要があるテーブルもいくつか見つかったため、バックログに乗せて対応を行うこととしました。
ドキュメント化の重要性を感じた点
dbt開発で生じたつまづきポイントを社内wikiにコメントしていくことで、RettyにおけるDWH開発のキャッチアップコストを減少できるという手応えが得られました。実際にdbtを初めて触る業務委託の方がドキュメントを適宜参照することでday1からプルリクエストを投げられることにもつながりました。
依存関係やテーブル・スキーマ情報が可視化されることの利便性に気づけた点
新規でDWH開発を行う際やデータの欠損などが疑われた際の調査、触ったことがないテーブルの概要把握時に活用できる手応えを感じています。
さいごに（今後の動き）
直近でやっていきたいと考えている事だけでも大きく下記の5つがあります。これら全てをやりきるには、まだまだ人手が足りていない状態なので、採用募集も行っております。
ご興味ある方いればまずはmeetyのカジュアル面談にご連絡ください！！
dbtで生成したドキュメント・Linageのホスティング
分析の民主化やdbtの価値実感を高めるために行いたいと考えています。
やり方としては、公式ドキュメントで紹介されている方法を参考にする予定です。
データ分析チーム管理外の野良テーブルのdbt移行の検討
現状、野良テーブルの依存関係が把握できずクエリ変更や削除を行う際の影響範囲の調査が手間となるため、他チームとコミュニケーションを取りながら野良テーブルを減らしていく動きを取っていく予定です。
テーブルの説明文やテストの拡充
分析の民主化、データの信頼性の向上のためにも拡充と、拡充を行いやすい仕組みづくりを検討したいと考えています。
ロジックの誤りのリファクタリング
Linageで依存関係が把握しやすくなったこと、3層構造でクエリが管理されるようになったことで、クエリの小さなロジックの誤りも発見しやすくなったため、細かい既存のテーブルのロジック修正を行っていきたいと考えています。
共通化できるロジック部分のリファクタリング
まだまだ保守運用しづらいクエリも多いため、共通化できるロジック部分はマクロを駆使しながら共通化していきたいと考えています。
今回の記事の内容やそのほかRettyのデータ分析基盤に興味がある方がいらっしゃいましたら、meetyでもTwitterでも、ご連絡お待ちしております！
また、分析チームのマネージャーやデータアナリストのMeetyも公開されているのでこちらも併せてどうぞ！
