リクルート流データ基盤塾～鶴谷と学ぶ～

2024/09/19に、リクルート流データ基盤塾 ～鶴谷と学ぶ～＃data meet up!で発表した、鶴谷・芳賀・阿部・川合の資料です。

Transcript

1. © Recruit Co., Ltd. All Rights Reserved
2. © Recruit Co., Ltd. All Rights Reserved リクルート流データ基盤塾 ～鶴谷と学ぶ～ 19:00～19:05：オープニング 19:05～19:50：LT×3 19:50～20:00：クロージング
3. © Recruit Co., Ltd. All Rights Reserved • 質問について 登壇者ならびに事務局への質問は ZoomのQ＆Aにご記入ください。 特定の登壇者への質問は、冒頭に 【登壇者名】を記載いただけますと 回答がしやすくなります。 時間の関係上、質問への回答ができな い場合がございます。ご了承ください。 3
4. © Recruit Co., Ltd. All Rights Reserved 自己紹介 株式会社リクルート　データ推進室 データエンジニアリング部　部長 所属 2005/04 証券系SIer入社 2015/05 キャリア採用入社(リクルートID分析基盤担当) 2018/04 リクルートIDデータ基盤担当GM 2020/04 住まいデータ基盤担当GM 2022/04 旅行・飲食・美容・SaaSデータ基盤担当GM データエンジニアリング部 部長 2022/09 検索基盤担当GM 経歴 4 鶴谷　誠文 Masafumi Tsurutani
5. © Recruit Co., Ltd. All Rights Reserved 株式会社リクルートについて 5 選択・意思決定を支援する情報サービスを提供し、 「まだ、ここにない、出会い。より速く、シンプルに、もっと近くに。」を実現する
6. © Recruit Co., Ltd. All Rights Reserved リクルートのビジネスモデルについて 6 • リクルートにはユーザーとクライアントという2つのお客様が存在 • 「企業と人（B to C）」 「企業と企業（B to B）」 「人と人（C to C）」の間に立ち、 双方にとって最適なマッチングを図る「場」を提供 ユーザーとクライアントを新しい接点で結び、 「まだ、ここにない、出会い。より速く、シンプルに、もっと近くに。」の場を創造する リクルート マッチングプラット フォーム クライアントとユーザーを結びつける 対価としてクライアントからフィーを受領 ユーザー クライアント
7. © Recruit Co., Ltd. All Rights Reserved データ推進室について 7 z 職種・ 機能単位 プロダクト単位 アジリティテクノロジー部 データソリューションユニット データテクノロジーユニット HR 結婚 旅行 自動車 学習 飲食 美容 住宅 SaaS 横断 データプロダクト マネジメント1部 データプロダクト マネジメント2部 データプロダクト マネジメント3部 データサイエンス・機械学習エンジニアリング部 データエンジニアリング部 データマネジメント部 採用・育成による専門性強化に責任を持つ プロダクト戦略の実現のための活動に責任を持つ より高度な専門性を基に領域・横断の重要案件の支援を行う データ テクノロジー ラボ部 室直下 アドバンスド テクノロジーラボ部 イノベーティブテクノロジー 研究戦略部 各事業領域のデータ戦略立案・推進を行う領域特化ユニットと 領域横断で支援を行う専門職種のユニットが交差するマトリクス型組織
8. © Recruit Co., Ltd. All Rights Reserved 登壇者紹介 8 DTU DPM1部 DPM2部 DTL部 Megago n ATL部 事業横断の機能に責任を持つ 販促1 DSU (住まい) 販促2 DSU (結婚 旅行 自動車) 販促3 DSU (飲食 美容) 販促4 DSU (まなび) SaaS DSU HR DSU 各事業領域戦略の実現のための活動に責任を持つ 芳賀 宣仁 （はが のぶひと） 阿部 誠也 （あべ まさや） 川合 真大 （かわい まさひろ）
9. © Recruit Co., Ltd. All Rights Reserved リクルートのデータエンジニア データエンジニアリング部 鶴谷　誠文 2024/09/19
10. © Recruit Co., Ltd. All Rights Reserved リクルートのデータ基盤の特徴 • 事業領域単位でデータ基盤を構築することで事業の要件・スピード感に柔軟に対応 • 一方で領域横断で利用できるプロダクト・プラットフォームを整備して適材適所で 導入することでシステムの垂直立ち上げを実現するとともに車輪の再発明を防ぐ 10 環境面 販促1 DSU (住まい) 販促2 DSU (結婚 旅行 自動車) 販促3 DSU (飲食 美容) 販促4 DSU (まなび) SaaS DSU HR DSU DTU ワークフロー実行基盤 ターゲティングリスト抽出基盤 ・・・ 各事業領域で利用する・しないを選択
11. © Recruit Co., Ltd. All Rights Reserved リクルートのデータ基盤の特徴（続き） • パブリッククラウド（Google Cloud、AWS）を適材適所で使い分ける • データウェアハウスやパイプラインだけでなく、レコメンド基盤や検索基盤、BIツー ル、RAGシステムなどの開発も行う 11 技術面 ＜データ基盤の構成例＞ 専 用 線
 Webサービス、 事業システム のDB ETL処理 BigQuery BIツール RAGシステム Webサービス のフロント レコメンド基盤 検索基盤 ストリーミング パイプライン基盤 カスタマー 社内利用者 （ワークフロー実行基盤） （ターゲティングリスト抽出基盤）
12. © Recruit Co., Ltd. All Rights Reserved • ノウハウやナレッジ流通のためのデータ室ALLの共有会 ex.)AlloyDB検索基盤技術検証、Databricksモデルサービング技術検証 • 品質担保のためのSP（シニアプロフェッショナル）・GM陣によるレビュー会 ex.)オンライン推論リファクタリングのアーキテクチャレビュー • 社内標準Githubでのソース共有やコンフルでの設計情報共有 リクルートのデータ基盤の進化の秘訣 12 仕組み面 参考）AlloyDBの技術検証資料 参考）オンライン推論リファクタリングの設計資料 参考）社内認証基盤連携の開発事例
13. © Recruit Co., Ltd. All Rights Reserved 住まい領域でカオスエンジニアリングベースの 障害訓練実施 コンフルで実際に使った障害訓練の資料や 振り返りを共有 ノウハウ活用して他の領域でも 障害訓練を実施 リクルートのデータ基盤の進化の秘訣（続き） 13 • 各グループがボトムアップでPoCや技術検証に取り組む • 他組織の成功／失敗事例を活用することで基盤の高度化や技術的負債解消を推進 • timesや勉強会などでのメンバー間での繋がりによる情報共有 文化面 URL:https://speakerdeck.com/recruitengineers/developerssummit ＜具体例＞
14. © Recruit Co., Ltd. All Rights Reserved リクルートのデータエンジニアの育成の仕組み 14 • マネージメントトラックとスペシャリストトラックのキャリアパスの整備 • 室横断での中途採用オンボーディングやキックオフにより事業領域内の繋がりだけ でなく、領域を跨いだ繋がりを創出 • 室横断での人材育成を起点とした案件アサイン 人事面 • クラウド環境勉強制度（AWS、Google Cloud）を使った専用環境でのクラウド技 術自己研鑽 • Github Copilot Businessの利用環境を整備 • 各領域でテックリードによるアーキテクチャレビューの実施 環境面
15. © Recruit Co., Ltd. All Rights Reserved SUUMOにおける データエンジニアの役割と成長 15 住まいデータエンジニアリングG 芳賀 宣仁 2024/09/19
16. © Recruit Co., Ltd. All Rights Reserved 自己紹介 データ推進室 住まいデータエンジニアリンググループ 所属 2016/04 新卒入社(住まいDSG) 2023/04〜　DEG マネージャー 経歴 16 芳賀　宣仁 Nobuhito HAGA Data Engineer (Group Manager)
17. © Recruit Co., Ltd. All Rights Reserved 不動産マッチングプラットフォーム SUUMOとは 17 家を探している ユーザ 不動産事業 クライアント ユーザとクライアント双方にとって 最適なマッチングを生み出す「場」を提供 進学に伴って 一人暮らしを始めたい 家族が増えたので マンションか戸建てを 買いたい 実家を リフォームしたい 賃貸仲介会社 マンションデベロッパー 売買仲介事業者 ハウスメーカー 工務店 リフォーム事業者
18. © Recruit Co., Ltd. All Rights Reserved 不動産マッチングプラットフォーム SUUMOとは 18 家を探している ユーザ 不動産事業 クライアント ユーザとクライアント双方にとって 最適なマッチングを生み出す「場」を提供 進学に伴って 一人暮らしを始めたい 家族が増えたので マンションか戸建てを 買いたい 実家を リフォームしたい 賃貸仲介会社 マンションデベロッパー 売買仲介事業者 ハウスメーカー 工務店 リフォーム事業者 本日のプロダクトはこっちの話！
19. © Recruit Co., Ltd. All Rights Reserved SUUMO営業のお仕事 不動産会社の事業成長に伴走する SUUMOというメディア媒体の広告営業を前提としつつ、 クライアントの事業成長に伴走する仕事 不動産の仕入れに関するアドバイスなどの深い介在含め クライアントの成長を支援する中で、SUUMOというメディア も手段の一つとして提案している。 不動産会社を顧客としたtoB営業 19 キャリア採用サイトにも 詳細載っているのでご興味あれば
20. © Recruit Co., Ltd. All Rights Reserved SUUMO営業の課題とその打ち手(KR※.1 Davis) 一番重要なコア業務であるクライアントの業績拡大に向けた伴走 に最大限時間を割きたいが そのために必要な定型分析や提案資料の作成がネックに 課題：深い介在を志向する中で時間が足りない 社内での分析業務やクライアントとの商談の場の 利用に耐えうる内製の分析Webアプリケーション Davisを作成 打ち手:分析〜可視化〜資料作成までできる分析プロダクトを作る 20 ※.1 KR = 戸建・流通
21. © Recruit Co., Ltd. All Rights Reserved データエンジニア（DE）の業務 サービスを安く・早く提供するための、データ基盤の開発・運用 DEのミッション • インフラ構築、CICDパイプラインの整備 • 開発ディレクション（アーキテクチャ検討、レビュー、開発管理など） 業務内容（KRDavis） 21
22. © Recruit Co., Ltd. All Rights Reserved 住まい領域においてはWF型の開発が一般的 22 住まい領域においてはウォーターフォール型(WF型)の開発が一般的であった しかし、Davis開発においては不確実性の高い要求が多く、企画として実際に効果が あるかどうかを事前に見積もることが難しい。一方でWF型の開発では検証完了ま でのリードタイムがかかりすぎてしまい、事業の期待に添うことができない 企画 検討 要件定義 開発 テスト （単体・内結・総合） 受け入れ （営業FB） リリース 一般的な住まい領域の開発フロー
23. © Recruit Co., Ltd. All Rights Reserved 分析アプリのシステム構築 23
24. © Recruit Co., Ltd. All Rights Reserved 開発手戻りをなくすための仕組み作り 24 企画 検討 要件定義 プロト開発 営業FB＆ 企画 プロト開発 営業FB＆ 企画 開発＆ テスト リリース プロトタイプが完成した時点で、開発環境にデプロイし、営業の受け入れ確認を開発 工程の早い段階から行い、開発の手戻りを無くした上で、短い期間でリリース 企画 検討 要件定義 開発 テスト （単体・内結・総合） 受け入れ （営業FB） リリース KRDavisの開発フロー 一般的な住まい領域の開発フロー
25. © Recruit Co., Ltd. All Rights Reserved まとめ • SUUMOメディアにおける対クライアント向けデータ活用 ◦ 社内での分析業務やクライアントとの商談の場で活用する分析Webアプリケーション ◦ 業務の型化からツール要件まで営業と一緒になって検討 • データエンジニア（DE）の進化/成長 ◦ サービスを安く・早く提供するための、データ基盤の開発 ◦ 住まい領域においてはWF型の開発スタイルが主流だったが、それでは事業要求に応え切れない ◦ データインフラ構築、CICD整備（各種自動化）、ディレクションなどを実施 ◦ 事業に近い場所でエンジニアとして仕事をするため、エンジニアの速度がそのまま事業成長の速 度になる とは言うものの... まだまだ開発速度は理想とはほど遠い。またLLMといった新規技術を用いた開発案件も求められるように なってきている。 そのため日々の失敗を糧にしてエンジニアとしての成長が求められる状態です 25
26. © Recruit Co., Ltd. All Rights Reserved 　　　Q&A
27. © Recruit Co., Ltd. All Rights Reserved データプロダクト 品質改善の取り組み データプロダクトエンジニアリング1グループ 阿部 誠也
28. © Recruit Co., Ltd. All Rights Reserved 自己紹介 阿部 誠也 Masaya Abe データ推進室 データテクノロジーユニットデータプロダクトマネジメント1部 データプロダクトエンジニアリング1グループ グループマネージャー 2019年にリクルートに新卒入社。 リクルートの複数の事業領域で活用されている横断データマート・データプロダクトの開発・推進を担当。 現在は横断データプロダクトを担当するデータプロダクトエンジニアリング1グループのマネージャーを務めている。 28
29. © Recruit Co., Ltd. All Rights Reserved 横断データプロダクト 29 データ推進室では複数領域で利用可能なプロダクトを開発、 領域・プロジェクトを超えて活用可能な「横断データプロダクト」を各領域へ展開。 横断データプロダクトを提供することで以下を図る。 • 複数領域への機能横展開 • 重複機能共通化によるコストダウン • 運営体制面含むサステナビリティ向上
30. © Recruit Co., Ltd. All Rights Reserved データプロダクトエンジニアリング1Gの管轄プロダクト 30 データプロダクトエンジニアリング1Gでは次の3つのプロダクトを管轄。 マーケティングターゲット設定ツール 簡単に機械学習・ドリフト検知等ができるMLツール 画像・言語データに対するアノテーションツール
31. © Recruit Co., Ltd. All Rights Reserved データプロダクトエンジニアリング1Gの管轄プロダクト 31 データプロダクトエンジニアリング1Gでは次の3つのプロダクトを管轄。 マーケティングターゲット設定ツール 本日は一番歴史の長い「Sugar」の品質改善の取り組み事例を紹介
32. © Recruit Co., Ltd. All Rights Reserved とは 32 GUIで簡単・安全にマーケティングターゲット設定ができるツール 属性情報 ターゲット選定 行動情報 ターゲット確認 ボリューム・ 統計量 システム連携 適切なフィルタリング
33. © Recruit Co., Ltd. All Rights Reserved の価値 33 SQLが書けなくても安全・簡単に施策実施が可能に。 これまで Sugar導入後
34. © Recruit Co., Ltd. All Rights Reserved 2020年頃の状況 34 新たなシステム連携等により、利用ニーズが変化・増加。 転換・成長期として、以下のような新機能の開発に注力していた。 • 新規のセグメント項目の開発 • UIの全面リニューアル 一方でプロダクトは2017年頃からあり負債も存在する中、ある出来事が発生。
35. © Recruit Co., Ltd. All Rights Reserved 発生した出来事 35 新規のセグメント項目開発の中で、同じ項目のデータ定義が異なることが発覚。 危うく利用者影響につながるところに。 発生した要因の1つは、過去経緯を含むデータの多重変換構造。 集計データ BigQuery 各領域データ BigQuery JSON GCS DB backend frontend ※ 過去 Oracle Exadata を利用 Elasticsearch
36. © Recruit Co., Ltd. All Rights Reserved 出来事を受けて 36 プロダクトの品質強化を一度立ち止まって実施。 継続的な品質改善の仕組みづくりにも注力。 • 妥当性テストなどによる品質担保 • データ変換構造のリアーキテクチャ • 「運用上の課題・リファクタリング」エピック運用の仕組み化
37. © Recruit Co., Ltd. All Rights Reserved 妥当性テストなどによる品質担保 37 単体テストに加え、以下のようなテストを拡充しデータの妥当性を担保。 • 各領域の元データと、Sugarの画面上で提供している値を項目単位で比較検証 (妥当性テスト) • E2Eテストと手動テストの組み合わせ 集計データ BigQuery 各領域データ BigQuery JSON GCS DB backend frontend テストSQL テスト条件 比較検証 妥当性テスト Elasticsearch
38. © Recruit Co., Ltd. All Rights Reserved データ変換構造のリアーキテクチャ 38 Elasticsearchを経由せず、直接DBとしてBigQueryを利用する構造に。 • クエリビルダ等バックエンドの改修 • 集計データマートのカラム構造の最適化 • パフォーマンステスト • 変更前後の変換結果の比較検証テスト 集計データ BigQuery 各領域データ BigQuery JSON GCS DB backend frontend 直接BigQueryを参照 Elasticsearch
39. © Recruit Co., Ltd. All Rights Reserved 「運用上の課題・リファクタリング」エピック運用の仕組み化 39 • 開発メンバーが誰でもチケット起票ができる、 「運用上の課題・リファクタリング」 エピックを用意。課題解消に取り組む。 • 毎週エピックのチケットをチームで確認、 当該エピックのチケット対応が一定割合で実施されるように。
40. © Recruit Co., Ltd. All Rights Reserved まとめ・改めて感じること 40 • 長く続くプロダクトは(当たり前に)負債が蓄積。 • 大きな新規開発が入るときこそ、一旦立ち止まって状況をみる。 逆に周辺を見直すことで効率性を上げるチャンスでもある。 • 定期的な見直しに加え、日々の継続的な改善が大切。 意識だけだと後回しになりがち、仕組みから作る。
41. © Recruit Co., Ltd. All Rights Reserved 引用リスト 41 1. https://icooon-mono.com/15835-%e4%ba%ba%e7%89%a9%e3%82%a2%e3%82%a4%e3%82%b3%e3%83%b3/ 2. https://icooon-mono.com/15681-%e5%88%86%e6%9e%90%e3%82%a2%e3%82%a4%e3%82%b3%e3%83%b3/ 3. https://icooon-mono.com/11048-%e3%83%8e%e3%83%bc%e3%83%88%e3%83%91%e3%82%bd%e3%82%b3%e3%83%b3 %e3%81%ae%e3%82%a2%e3%82%a4%e3%82%b3%e3%83%b3%e7%b4%a0%e6%9d%903/ 4. https://icooon-mono.com/10991-pc%e3%83%87%e3%82%a3%e3%82%b9%e3%83%97%e3%83%ac%e3%82%a4%e3%81% ae%e3%82%a2%e3%82%a4%e3%82%b3%e3%83%b3%e7%b4%a0%e6%9d%90-2/ 5. https://icooon-mono.com/12533-%e3%83%a1%e3%83%bc%e3%83%ab%e3%81%ae%e7%84%a1%e6%96%99%e3%82%a2 %e3%82%a4%e3%82%b3%e3%83%b3%e3%81%9d%e3%81%ae8/ 6. https://icooon-mono.com/12851-%e5%8f%8b%e9%81%94%e3%82%a2%e3%82%a4%e3%82%b3%e3%83%b32/ 7. https://docs.google.com/presentation/d/1fD1AwQo4E9Un6012zyPEb7NvUAGlzF6L-vo5DbUe4NQ/edit#slide=id.g5f77ca97a2_9 1_0 8. https://ja.m.wikipedia.org/wiki/%E3%83%95%E3%82%A1%E3%82%A4%E3%83%AB:Elasticsearch_logo.svg
42. © Recruit Co., Ltd. All Rights Reserved 　　　Q&A
43. © Recruit Co., Ltd. All Rights Reserved CDCデータパイプライン 導入による学び
44. © Recruit Co., Ltd. All Rights Reserved 自己紹介 株式会社リクルート　データ推進室 HRデータエンジニアリング1G グループマネージャー 所属 2017/04　SIer入社 2018/10　株式会社リクルートキャリア採用入社 2024/04　HR DE1G GM 経歴 44 川合 真大 Masahiro Kawai
45. © Recruit Co., Ltd. All Rights Reserved はじめに データ基盤でのChange Data Capture（CDC）パイプライン導入につ いてお話しします。 日次バッチ方式からCDC方式に移行した結果、なにを得られたのか。 なにを学んだかをシェアしたいと思います。
46. © Recruit Co., Ltd. All Rights Reserved CDCデータパイプライン導入背景 As Is • サービスのデータベースのデータは日次 ETLにより1日1回しか更新できない • 瞬時に反映される必要はないにしても、1 日待たないと使えないデータが多数存在 しており、それが制約となっている To Be • サービスのデータベースに対する更新 を随時かつ低遅延 (5-10min) で取 得する • 上記を都度の開発が不要な状態で実現 する 「データ鮮度による手段の制約を可能な限りなくしていきたい」
47. © Recruit Co., Ltd. All Rights Reserved 当時の状況 47 • ちょうど近いタイミングに複数のサービスが新しく AWS 上で稼働する予定が あり、データ基盤への ETL をどうするかという検討テーマが挙がっていた • サービス本体の構成が似通っているので、標準的な方法を確立できると、仕組 みを横展開することができ、一石 N 鳥な状況だった • 実現したい要件を考えると、CDC (Change Data Capture) を採用するこ との妥当性がありそうだった
48. © Recruit Co., Ltd. All Rights Reserved CDCデータパイプライン導入前の正直なお気持ち CDC導入によって選択肢は増える(はず)。だが検討事項は山積み。 • 社内に代表的なユースケースなし ※データ推進室内 • 技術検証 • 運用設計 ◦ 変更ログをどのように扱う？ ◦ サービス側の運用(スキーマ変更,etc)に耐えることができる？ ◦ サービス<->データ基盤とのI/Fは? • etc... 多くの時間を費やしリスクを冒してでも導入する価値があるのか...? 🧐
49. © Recruit Co., Ltd. All Rights Reserved CDC (Change Data Capture) ソースデータベースの変更操作 （挿入・更新・削除） をリアルタイムに追跡し、その内 容をターゲットのシステムに伝播する仕組み
50. © Recruit Co., Ltd. All Rights Reserved 実際にCDCで取得できる変更ログの具体イメージ I,2023-07-30T03:00:01.123+0000,101,Smith,Bob,4-Jun-14,New York I,2023-07-30T04:05:03.456+0000,102,Jones,Tom,3-Aug-07,Chicago U,2023-07-31T09:20:02.456+0000,101,Smith,Bob,8-Oct-15,Los Angeles U,2023-07-31T09:25:03.789+0000,102,Jones,Tom,17-Sep-09,Houston D,2023-08-01T12:00:04.752+0000,101,Smith,Bob,8-Oct-15,Los Angeles 操作 commit時刻 更新内容の値 変更ログは行単位で操作・変更内容示す情報が連携される。 サービスの1テーブルとしてデータ基盤上で利用したい場合、変更ログを組み立てて、最新snapshotを生成 などの工夫が必要 前 後 引用) https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Target.S3.html 最新の状態 = 「102,Jones,Tom,17-Sep-09,Houston」 1レコードのみ
51. © Recruit Co., Ltd. All Rights Reserved データ基盤とサービス間のデータ連携で典型的なのは1日1〜N回のバッチによる連携。 リクルート社内でもこのパターンがメジャー(現在) バッチでのETLとCDCの比較 観点 バッチ CDC データ鮮度 × 1時間 〜 1日 ◦ < 5min データ転送量 △ 毎回全件更新だと大きくなる。 差分抽出の場合は少なくできる が物理削除がわからないという 課題を抱える ◦ 差分データだけが転送されるの で全データをコピーする場合と 比較して少なくなる 運用コスト ◦ バッチなのでCDC比では低い △ 常に処理が動いているので高い
52. © Recruit Co., Ltd. All Rights Reserved バッチ方式によるETLパイプライン - 概要 ❶ RDBからデータ抽出 (日次連携) ❷ データをDWHへと連携 （全件洗い替えor差分更新）
53. © Recruit Co., Ltd. All Rights Reserved ❸ DWH(BigQuery) へと変更ログを連携&最 新snapshotを生成 ❷ 変更ログを取り込み DeltaLakeとして保存 CDCによるデータパイプライン - 概要 ❶ CDCを実行し CloudStorageに 変更ログを出力
54. © Recruit Co., Ltd. All Rights Reserved CDC導入によって得られたこと • データ鮮度という制約をほぼ取り払うことができた ◦ 6サービスからのデータ連携をCDC化 ◦ DWH(BigQuery)のデータは日次更新->1h程度で更新可能に ▪ Databricks上のデータは<5~10min程度の遅延 ◦ Event-Drivenな機能開発も容易に ▪ Spark(Databricks) + DeltaTableの組み合わせは表現力が高く、 できることの幅が広い • 物理削除を検知できる状態での差分更新ETL ◦ 変更が発生したレコードのみ連携されるため👛にやさしく、地味に助 かっている
55. © Recruit Co., Ltd. All Rights Reserved CDCパイプライン運用の難しさ バッチ方式と比較して運用は少し大変 • サービス側の変更がパイプラインへと直接影響しやすい ◦ 常に変更ログを連携しているのでバッチ方式よりも密結合 ◦ サービス側のリリースにデータ基盤側の対応を合わせることも • データ整合性の担保 ◦ 変更ログが「1行」でも欠けるとデータが壊れる ▪ 一方で日次全件更新方式の場合は翌日には復旧する ◦ 変更ログの取り込み漏れ監視、最新断面のPK一意性監視などで品質担保
56. © Recruit Co., Ltd. All Rights Reserved CDC導入によって「期せずして」得られたこと • 変更ログは調査タスクで大きな力を発揮する ◦ 各テーブルの最新snapshotだけでなく、変更ログも全てデータ 基盤に保持＆公開している※PIIはマスキング済 ◦ データの変更履歴を全て追うことができるので、データ調査、 障害調査においてかなり有用 ▪ データ基盤上のデータが壊れている旨の問い合わせをう け、変更ログを追ったところ、サービス側のバグだった...み たいなことも
57. © Recruit Co., Ltd. All Rights Reserved CDC導入を通じて得られた学び • データ鮮度向上による、データ基盤の価値向上は大きい ◦ できることが増える->想像できることも増える • 適切な技術スタックを採用することの重要性 ◦ ストリーム/バッチを使い分け、自由度が高くデータパイプラインを開 発できる技術選定は大事 • チャレンジングな物事に取り組むことの重要性 ◦ 日次バッチ方式では発生しなかった課題、問題に多く直面 ◦ 意図しなかった恩恵も多くあり、技術者としての学びは多い
58. © Recruit Co., Ltd. All Rights Reserved 　　　Q&A
59. © Recruit Co., Ltd. All Rights Reserved データ推進室採用サイトでは、 仕事の内容、働き方など さまざまな情報をお知らせします。 「リクルートデータ推進室」で検索！ https://www.recruit.co.jp/employment/mid-career/data_lp/ ご参加ありがとうございました！ 本日のイベントは終了いたしました
60. © Recruit Co., Ltd. All Rights Reserved Recruit Data Blogでは、 データ推進室で働くメンバーの 様々な取り組みを紹介しています。 「リクルートデータブログ」で検索！ https://blog.recruit.co.jp/data/ ご参加ありがとうございました！ 本日のイベントは終了いたしました
61. © Recruit Co., Ltd. All Rights Reserved データ推進室の発信情報を X（旧Twitter）にて 発信しています。 ぜひフォローお願いします！ 　　　　　　@Recruit_Data ご参加ありがとうございました！ 本日のイベントは終了いたしました
62. © Recruit Co., Ltd. All Rights Reserved 【情報登録フォームのご案内】 イベント等各種情報配信をご希望の方は 左記よりご登録ください！ ご参加ありがとうございました！ 本日のイベントは終了いたしました
63. © Recruit Co., Ltd. All Rights Reserved 【カジュアル面談フォームのご案内】 転職をお考えの方以外も大歓迎です！ 少しでもご興味お持ちいただけましたら 左記よりご登録ください！ ご参加ありがとうございました！ 本日のイベントは終了いたしました