Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
技術力と現場力で実現! 乱立したETLジョブの削減事例
Search
Recruit
PRO
March 03, 2025
Technology
2
56
技術力と現場力で実現! 乱立したETLジョブの削減事例
2025/2/20に開催したRecruit Tech Conference 2025の森田のLT資料です
Recruit
PRO
March 03, 2025
Tweet
Share
More Decks by Recruit
See All by Recruit
問題解決に役立つ数理工学
recruitengineers
PRO
9
2.5k
Curiosity & Persistence
recruitengineers
PRO
2
140
結果的にこうなった。から見える メカニズムのようなもの。
recruitengineers
PRO
1
320
成長実感と伸び悩みからふりかえる キャリアグラフ
recruitengineers
PRO
1
130
リクルートの オンプレ環境の未来を語る
recruitengineers
PRO
3
150
LLMのプロダクト装着と独自モデル開発
recruitengineers
PRO
1
200
新規検索基盤でマッチング精度向上に挑む! ~『ホットペッパーグルメ』の開発事例 ビジネス編
recruitengineers
PRO
2
120
新規検索基盤でマッチング精度向上に挑む! ~『ホットペッパーグルメ』の開発事例 技術編
recruitengineers
PRO
0
130
大規模プロダクトにおける フロントエンドモダナイズの取り組み紹介
recruitengineers
PRO
5
110
Other Decks in Technology
See All in Technology
新卒エンジニアがCICDをモダナイズしてみた話
akashi_sn
2
250
Porting PicoRuby to Another Microcontroller: ESP32
yuuu
4
440
AWS Control Towerを 数年運用してきての気づきとこれから/aws-controltower-ops-tips
tadayukinakamura
0
160
クラウド開発環境Cloud Workstationsの紹介
yunosukey
0
180
ブラウザのレガシー・独自機能を愛でる-Firefoxの脆弱性4選- / Browser Crash Club #1
masatokinugawa
1
490
Dynamic Reteaming And Self Organization
miholovesq
3
570
クォータ監視、AWS Organizations環境でも楽勝です✌️
iwamot
PRO
1
320
Automatically generating types by running tests
sinsoku
2
3.4k
Conquering PDFs: document understanding beyond plain text
inesmontani
PRO
0
110
LLM as プロダクト開発のパワードスーツ
layerx
PRO
1
240
品質文化を支える小さいクロスファンクショナルなチーム / Cross-functional teams fostering quality culture
toma_sm
0
120
Goの組織でバックエンドTypeScriptを採用してどうだったか / How was adopting backend TypeScript in a Golang company
kaminashi
6
6.2k
Featured
See All Featured
Six Lessons from altMBA
skipperchong
27
3.7k
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
34
2.9k
The Psychology of Web Performance [Beyond Tellerrand 2023]
tammyeverts
47
2.7k
Fireside Chat
paigeccino
37
3.4k
How to Ace a Technical Interview
jacobian
276
23k
Put a Button on it: Removing Barriers to Going Fast.
kastner
60
3.8k
Keith and Marios Guide to Fast Websites
keithpitt
411
22k
CoffeeScript is Beautiful & I Never Want to Write Plain JavaScript Again
sstephenson
160
15k
The Cult of Friendly URLs
andyhume
78
6.3k
Writing Fast Ruby
sferik
628
61k
[RailsConf 2023] Rails as a piece of cake
palkan
54
5.4k
"I'm Feeling Lucky" - Building Great Search Experiences for Today's Users (#IAC19)
danielanewman
227
22k
Transcript
技術力と現場力で実現! 乱立したETLジョブの削減事例 RECRUIT TECH CONFERENCE 2025 森田 順也 株式会社リクルート データ推進室
Junya MORITA 経歴 / Career データマート設計 2019年 リクルート入社 クラウドDWHを使ったデータ分析基盤に対する dbt
等の データ変換ツールの導入、BIツールやアプリケーション での利用を想定したデータパイプライン構築、開発チー ムリードを担当。 = dbt と Composer で データマート開発をしています 趣味 / Hobbies データ推進室 結婚・旅行・自動車領域 アナリティクスエンジニア /テックリード
運用しているデータマート基盤の紹介 Data Lake Cloud Storage Data Mart BigQuery Data Warehouse
BigQuery クライアント様向け アプリ・基盤 カスタマー向け アプリ・基盤 データ抽出・ロード Cloud Composer Transform Extract Load マート生成 dbt Core / Cloud Composer レコメンドシステム 本日の主役となる マート生成ジョブ 事業の価値を最大化するためのデータ分析基盤 GCP環境を基盤に、dbt と Cloud Composer によるマート生成ジョブを運用 処理されるデータ量は数百TBオーダー
本日お話しすること(概要) データマート基盤で乱立している ジョブ を削減した話
データマート開発は Asset Centric の時代 どうしてジョブを減らしたいのか
データマート開発では、ジョブの依存が複雑になりやすい ソース1 ソース2 マートb マートa マートc ジョブ A ジョブ B
ジョブ C マートd ジョブ E マートf マートe ジョブ D 参照元を増やすと ジョブEがジョブBに 依存する
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の依存に着目 ↓ ジョブを見なくても シンプルに依存管理可能
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] の順でテーブルを生成
“超”複雑なパイプライン Asset Centric: “超”複雑なパイプライン運用が可能 ジョブの依存関係を考える必要が無くなり、より多数のテーブルが絡み合う、複 雑なデータ基盤を運用できる すべてのマートを生成する たった一つのジョブ ソース マート
ソース ソース マート マート マート マート マート マート マート マート マート マート マート マート ソース マート マート マート マート マート マート ソース ソース マート マート マート マート マート マート マート
“超”複雑なパイプライン Asset Centric: “超”複雑なパイプライン運用が可能 ジョブの依存関係を考える必要が無くなり、より多数のテーブルが絡み合う、複 雑なデータ基盤を運用できる すべてのマートを生成する たった一つのジョブ ソース マート
ソース ソース マート マート マート マート マート マート マート マート マート マート マート マート ソース マート マート マート マート マート マート ソース ソース マート マート マート マート マート マート マート はずだった…
現実のジョブは1つじゃない 処理が重いため 夜間の時間帯で実行 するジョブ 依存するデータが異 なるため切り出され たジョブ 様々な都合でジョブが増加し、32件まで増加。依存関係管理は残り、個々のジョ ブは多数のマートを作るため複雑化し、障害時の調査はむしろ難航。 ※画像は実際のジョブではなく、マスクしたデータで再現しています
※ジョブのモニタリングについては、https://blog.recruit.co.jp/data/articles/dbt_ジョブ _monitoring/ にて詳細を紹介しています。
現実のジョブは1つじゃない 処理が重いため 夜間の時間帯で実行 するジョブ 依存するデータが異 なるため切り出され たジョブ 様々な都合でジョブが増加し、32件まで増加。依存関係管理は残り、個々のジョ ブは多数のマートを作るため複雑化し、障害時の調査はむしろ難航。 ※画像は実際のジョブではなく、マスクしたデータで再現しています
※ジョブのモニタリングについては、https://blog.recruit.co.jp/data/articles/dbt_ジョブ _monitoring/ にて詳細を紹介しています。 Asset Centric やめようか…?
本日お話しすること(詳細) Asset Centric 主義を貫いて 複雑怪奇なデータパイプラインであっても 生産性高く運用するために 分析基盤で乱立している ジョブ を削減した話
ジョブの乱立はなぜおきる?
通常のジョブ設計 ソース 1 中間 マート 日次 マート ソース 2 最終
マート すべてのマートを生成する 汎用ジョブ
ジョブが増えていく2つの要因 大量 データ 中間 マート 日次 マート 14時 更新 最終
マート 汎用ジョブ ①処理負荷が大きい 処理負荷が大きく時間がかかる場合 事前計算するジョブが必要に ②ソースのデータ連携時刻が異なる 14時に連携されるソースがある場合 待ちあわせのジョブが必要に 夜間ジョブ 14時ジョブ
ジョブを増やさないために ①処理負荷が大きい 処理負荷が大きく時間がかかる場合 事前計算するジョブが必要に ②ソースのデータ連携時刻が異なる 14時に連携されるソースがある場合 待ちあわせのジョブが必要に モデリングによって ジョブの負荷を下げる データ提供元と調整し
データ連携時刻を早める 技術力 現場力
モデリングでジョブの負荷を削減する 技術力
負荷削減の基本:増分処理 例:日々のユニークユーザーを増分処理で集計する 過去時点のユーザー数は、将来に渡って変わらないため、処理しなくて良い 前々日の ユーザー数 前日の ユーザー数 当日の ユーザー数 当日のPVデータ
のみを参照する 前々日データ 前日PVデータ 当日PVデータ ジョブ 当日のユーザー数を算出し 日々積み上げる Point 処理対象のデータ量を いかに小さくするか 背景
実際に直面するジョブ:増分処理できるケースは多くない 例:過去364日間のユニークユーザー数を毎日計算し、移動平均を出す 増分処理が使えず、処理対象のデータを小さくできない 364日間 ユニークユー ザー数 364日前 PVデータ … 当日PVデータ
ジョブ 実際の処理負荷 • スロット消費量: 191 M slotMs • 実行時間/100slot: 30+min ← 統合するとジョブの実行時間が30分以上伸びる 課題
集約テーブルをモデリングしてデータ量を小さくする • データ量の大きなデータを日毎にユニーク化して積み上げ、データ量を削減 • 中間テーブルのデータ配置を用途に合わせて定義 • ユーザーidをハッシュ変換し、ユニーク化の計算量を削減 364日前 UUデータ …
当日UUデータ 364日前 PVデータ … 当日PVデータ ジョブ ジョブ 364日間 ユニークユー ザー数 単日のデータのみ 処理するため 負荷小 日次集約テーブル 集約済みテーブルを 処理するので 負荷小 打ち手
負荷削減量 計算量(スロット消費量) 191M slotMs → 2.7M slotMS ジョブ実行時間 30 min
→ 27 sec 夜間ジョブは不要になり インフラコストも大幅削減 成果
データ連携タイミングを早める 現場力
データのやりとりは組織間のやりとり 事業DB データ レイク 抽出/ 匿名加工 抽出/ 変換 データ マート
開発組織 分析組織 連携を前倒すには 開発組織の抽出処理を 変える必要がある 背景
なぜ前倒しが難しいのか:組織で優先するものが違う 事業DB データ レイク 抽出/ 匿名加工 抽出/ 変換 データ マート
開発組織 アプリ/データを安定して 運用することが最優先 分析組織 分析業務に集中するため 分析基盤の運用を効率化したい ジョブを 減らしたいよ スケジュール 変更に工数と れない… 機能開発で 手いっぱい... データ連携 前倒し したいな 課題
データ連携チームによるデータ連携の優先保守 事業DB データ レイク 抽出/ 匿名加工 抽出/ 変換 データ マート
開発組織 アプリ/データを安定して 運用することが最優先 スキーマや 更新頻度は 伝えるよ データ連携チーム 事業DBのアクセス権を持ち データ連携を優先保守 連携時刻 前倒ししたよ 分析組織 分析業務に集中するため 分析基盤の運用を効率化したい 打ち手 ジョブを 減らしたいよ
データ連携チーム体制による連携前倒しの成果 連携時刻 14:00 → 10:00 連携を早めたテーブルの数 74 テーブル 午後のジョブを午前10時台のジョブにマージでき 最新データで分析できるタイミングも4時間前倒し
成果
最後に
成果:どれだけ Asset Centric にできたのか ジョブの数: 32件 → 11件 1つのメインジョブで作られるマートの数: 150
→ 188(全体211)
成果:どれだけの価値に繋がったか インフラコスト: 10.5 G slotMs /day → 8 G slotMs
/day (-23%) 最新データを確認できる時刻: 17:00 → 11:00
まとめ マートのモデリングで処理負荷を解消し データ連携を専任する組織を立ててデータ連携時刻を前倒し 結果、ジョブを削減して Asset Centric 主義を貫くことで 効率的なETLジョブ基盤を維持した
© Recruit Co., Ltd. All Rights Reserved We are hiring!
カジュアル⾯談はこちらより お申し込みください データサイエンティスト 機械学習エンジニア データエンジニア アナリティクスエンジニア R&Dエンジニア データアプリケーションエンジニア クラウドエンジニア ご応募 お待ちしています!