技術力と現場力で実現！ 乱立したETLジョブの削減事例

2025/2/20に開催したRecruit Tech Conference 2025の森田のLT資料です

Transcript

1. 技術力と現場力で実現！ 乱立したETLジョブの削減事例 RECRUIT TECH CONFERENCE 2025 森田 順也 株式会社リクルート データ推進室
2. Junya MORITA 経歴 / Career データマート設計 2019年 リクルート入社 クラウドDWHを使ったデータ分析基盤に対する dbt 等の データ変換ツールの導入、BIツールやアプリケーション での利用を想定したデータパイプライン構築、開発チー ムリードを担当。 = dbt と Composer で データマート開発をしています 趣味 / Hobbies データ推進室 結婚・旅行・自動車領域 アナリティクスエンジニア /テックリード
3. 運用しているデータマート基盤の紹介 Data Lake Cloud Storage Data Mart BigQuery Data Warehouse BigQuery クライアント様向け アプリ・基盤 カスタマー向け アプリ・基盤 データ抽出・ロード Cloud Composer Transform Extract Load マート生成 dbt Core / Cloud Composer レコメンドシステム 本日の主役となる マート生成ジョブ 事業の価値を最大化するためのデータ分析基盤 GCP環境を基盤に、dbt と Cloud Composer によるマート生成ジョブを運用 処理されるデータ量は数百TBオーダー
4. 本日お話しすること(概要) データマート基盤で乱立している ジョブ を削減した話
5. データマート開発は Asset Centric の時代 どうしてジョブを減らしたいのか
6. データマート開発では、ジョブの依存が複雑になりやすい ソース1 ソース2 マートb マートa マートc ジョブ A ジョブ B ジョブ C マートd ジョブ E マートf マートe ジョブ D 参照元を増やすと ジョブEがジョブBに 依存する
7. Asset Centric: データに定義された情報で依存を管理 Asset Centric については、https://blog.recruit.co.jp/data/articles/dbt_ジョブ_monitoring/ にて詳細を紹介しています。 ソース マートB マートA マートC ジョブ A ジョブ B ソース マートB マートA マートC ジョブ Centric ジョブAとジョブBの依存に着目 Asset Centric マートA,B,Cの依存に着目 ↓ ジョブを見なくても シンプルに依存管理可能
8. dbt: Asset Centric なツール Asset Centric については、https://blog.recruit.co.jp/data/articles/dbt_ジョブ_monitoring/ にて詳細を紹介しています。 ソース マートB マートA マートC Asset Centric マートA,B,Cの依存に着目 ↓ ジョブを見なくても シンプルに依存管理可能 すべてのマートを生成する たった一つのジョブ テーブル定義から依存関係を解析し [マートA→マートC,マートB] の順でテーブルを生成
9. “超”複雑なパイプライン Asset Centric: “超”複雑なパイプライン運用が可能 ジョブの依存関係を考える必要が無くなり、より多数のテーブルが絡み合う、複 雑なデータ基盤を運用できる すべてのマートを生成する たった一つのジョブ ソース マート ソース ソース マート マート マート マート マート マート マート マート マート マート マート マート ソース マート マート マート マート マート マート ソース ソース マート マート マート マート マート マート マート
10. “超”複雑なパイプライン Asset Centric: “超”複雑なパイプライン運用が可能 ジョブの依存関係を考える必要が無くなり、より多数のテーブルが絡み合う、複 雑なデータ基盤を運用できる すべてのマートを生成する たった一つのジョブ ソース マート ソース ソース マート マート マート マート マート マート マート マート マート マート マート マート ソース マート マート マート マート マート マート ソース ソース マート マート マート マート マート マート マート はずだった…
11. 現実のジョブは1つじゃない 処理が重いため 夜間の時間帯で実行 するジョブ 依存するデータが異 なるため切り出され たジョブ 様々な都合でジョブが増加し、32件まで増加。依存関係管理は残り、個々のジョ ブは多数のマートを作るため複雑化し、障害時の調査はむしろ難航。 ※画像は実際のジョブではなく、マスクしたデータで再現しています ※ジョブのモニタリングについては、https://blog.recruit.co.jp/data/articles/dbt_ジョブ _monitoring/ にて詳細を紹介しています。
12. 現実のジョブは1つじゃない 処理が重いため 夜間の時間帯で実行 するジョブ 依存するデータが異 なるため切り出され たジョブ 様々な都合でジョブが増加し、32件まで増加。依存関係管理は残り、個々のジョ ブは多数のマートを作るため複雑化し、障害時の調査はむしろ難航。 ※画像は実際のジョブではなく、マスクしたデータで再現しています ※ジョブのモニタリングについては、https://blog.recruit.co.jp/data/articles/dbt_ジョブ _monitoring/ にて詳細を紹介しています。 Asset Centric やめようか…？
13. 本日お話しすること(詳細) Asset Centric 主義を貫いて 複雑怪奇なデータパイプラインであっても 生産性高く運用するために 分析基盤で乱立している ジョブ を削減した話
14. ジョブの乱立はなぜおきる？
15. 通常のジョブ設計 ソース 1 中間 マート 日次 マート ソース 2 最終 マート すべてのマートを生成する 汎用ジョブ
16. ジョブが増えていく2つの要因 大量 データ 中間 マート 日次 マート 14時 更新 最終 マート 汎用ジョブ ①処理負荷が大きい 処理負荷が大きく時間がかかる場合 事前計算するジョブが必要に ②ソースのデータ連携時刻が異なる 14時に連携されるソースがある場合 待ちあわせのジョブが必要に 夜間ジョブ 14時ジョブ
17. ジョブを増やさないために ①処理負荷が大きい 処理負荷が大きく時間がかかる場合 事前計算するジョブが必要に ②ソースのデータ連携時刻が異なる 14時に連携されるソースがある場合 待ちあわせのジョブが必要に モデリングによって ジョブの負荷を下げる データ提供元と調整し データ連携時刻を早める 技術力 現場力
18. モデリングでジョブの負荷を削減する 技術力
19. 負荷削減の基本:増分処理 例：日々のユニークユーザーを増分処理で集計する 過去時点のユーザー数は、将来に渡って変わらないため、処理しなくて良い 前々日の ユーザー数 前日の ユーザー数 当日の ユーザー数 当日のPVデータ のみを参照する 前々日データ 前日PVデータ 当日PVデータ ジョブ 当日のユーザー数を算出し 日々積み上げる Point 処理対象のデータ量を いかに小さくするか 背景
20. 実際に直面するジョブ：増分処理できるケースは多くない 例：過去364日間のユニークユーザー数を毎日計算し、移動平均を出す 増分処理が使えず、処理対象のデータを小さくできない 364日間 ユニークユー ザー数 364日前 PVデータ … 当日PVデータ ジョブ 実際の処理負荷 • スロット消費量: 191 M slotMs • 実行時間/100slot: 30+min ← 統合するとジョブの実行時間が30分以上伸びる 課題
21. 集約テーブルをモデリングしてデータ量を小さくする • データ量の大きなデータを日毎にユニーク化して積み上げ、データ量を削減 • 中間テーブルのデータ配置を用途に合わせて定義 • ユーザーidをハッシュ変換し、ユニーク化の計算量を削減 364日前 UUデータ … 当日UUデータ 364日前 PVデータ … 当日PVデータ ジョブ ジョブ 364日間 ユニークユー ザー数 単日のデータのみ 処理するため 負荷小 日次集約テーブル 集約済みテーブルを 処理するので 負荷小 打ち手
22. 負荷削減量 計算量(スロット消費量) 191M slotMs → 2.7M slotMS ジョブ実行時間 30 min → 27 sec 夜間ジョブは不要になり インフラコストも大幅削減 成果
23. データ連携タイミングを早める 現場力
24. データのやりとりは組織間のやりとり 事業DB データ レイク 抽出/ 匿名加工 抽出/ 変換 データ マート 開発組織 分析組織 連携を前倒すには 開発組織の抽出処理を 変える必要がある 背景
25. なぜ前倒しが難しいのか：組織で優先するものが違う 事業DB データ レイク 抽出/ 匿名加工 抽出/ 変換 データ マート 開発組織 アプリ/データを安定して 運用することが最優先 分析組織 分析業務に集中するため 分析基盤の運用を効率化したい ジョブを 減らしたいよ スケジュール 変更に工数と れない… 機能開発で 手いっぱい... データ連携 前倒し したいな 課題
26. データ連携チームによるデータ連携の優先保守 事業DB データ レイク 抽出/ 匿名加工 抽出/ 変換 データ マート 開発組織 アプリ/データを安定して 運用することが最優先 スキーマや 更新頻度は 伝えるよ データ連携チーム 事業DBのアクセス権を持ち データ連携を優先保守 連携時刻 前倒ししたよ 分析組織 分析業務に集中するため 分析基盤の運用を効率化したい 打ち手 ジョブを 減らしたいよ
27. データ連携チーム体制による連携前倒しの成果 連携時刻 14:00 → 10:00 連携を早めたテーブルの数 74 テーブル 午後のジョブを午前10時台のジョブにマージでき 最新データで分析できるタイミングも4時間前倒し 成果
28. 最後に
29. 成果:どれだけ Asset Centric にできたのか ジョブの数: 32件 → 11件 1つのメインジョブで作られるマートの数： 150 → 188(全体211)
30. 成果:どれだけの価値に繋がったか インフラコスト: 10.5 G slotMs /day → 8 G slotMs /day (-23%) 最新データを確認できる時刻: 17:00 → 11:00
31. まとめ マートのモデリングで処理負荷を解消し データ連携を専任する組織を立ててデータ連携時刻を前倒し 結果、ジョブを削減して Asset Centric 主義を貫くことで 効率的なETLジョブ基盤を維持した
32. © Recruit Co., Ltd. All Rights Reserved We are hiring! カジュアル⾯談はこちらより お申し込みください データサイエンティスト 機械学習エンジニア データエンジニア アナリティクスエンジニア R&Dエンジニア データアプリケーションエンジニア クラウドエンジニア ご応募 お待ちしています！