MANABIYAでの発表資料です。 数十のプロダクトのデータを一手に集め、処理を回すリクルートライフスタイルのビックデータ分析基盤。本資料では、分析基盤の構成、ブロダクトの選定理由、課題解決の実例という3本立てでご紹介します。 リクルートライフスタイル　白子　佳孝 　　　　　　　　　　　　　　　　 秋本　大樹

1. リクルートライフスタイル流！
分析基盤との賢い付き合い⽅
⽩⼦ 佳孝
秋本 ⼤樹
ネットビジネス本部
データマネジメントグループ
データプラットフォームチーム

2. ⽩⼦ 佳孝 (シラコ ヨシタカ)
株式会社 リクルートライフスタイル
ネットビジネス本部
データマネジメントグループ
データプラットフォームT
Twitter: @y0shirak0
2012年5⽉
サンフランシスコ州⽴⼤学を卒業
2013年4⽉
新卒として中堅SIerに⼊社
客先に常駐し、システム運⽤・インフラ/ミドルウェア構築を
主に担当Treasure Dataや、RedHat Openstackといった
次世代インフラ導⼊案件にも携わる
2017年6⽉
リクルートライフスタイルに転職
社内分析基盤の運⽤チームリーダを担当

3. 分析基盤上の課題を運⽤で解決した話
本⽇お話しすること
リクルートライフスタイルの分析基盤ってどんなの？
各プロダクトの選定理由と利⽤⽤途は？
分析基盤上の課題をシステムを⽤いて解決した話
リクルートライフスタイルってどんな会社？

4. リクルートライフスタイル
ってどんな会社？

6. リクルートライフスタイルが持つデータ

7. リクルートライフスタイルの
分析基盤
ってどんなの？

8. SPSS Tableau
Mail
Publisher
Marketing
Cloud
Salesforce ・・・
事業DB SCログ 外部データ ⼿⼊⼒ Firebase ・・・
データ
プロデューサー
分析基盤
Datamart
DWH
データ
アナリスト
データ
サイエンティス
ト
CRM 営業
マーケティング最適化
KPIマネジメント
可視化
分析
集約・集計
⼊⼒
出⼒
出⼒拡⼤
⼊⼒拡⼤
組
織
拡
⼤
社内の現状

9. 増えるデータとデータソース
抱える課題は様々
増える利⽤者・組織
多様化する利⽤⽤途
増える連携先・出⼒先
求められるスピード・耐障害性

10. ⾊々な課題をクリアし、
30もあるサービスのデータ
を収集し計算している
分析基盤が

11. 構成図
HPB HPG
JLN
事業データ
CSV
外部データ
S3
Redshift (本番)
Redshift (退避)
BigQuery
アクセスログ
アプリログ Treasure Data
Exadata
Cloud Storage

12. 分析基盤の通称：XXX
世界最速の分析基盤になるという決意を込めて
世界最速のある⼈から名前を拝借

13. BLT (ボルト)

14. ⼊⼒ 出⼒処理
データ利活⽤の３⼤要素
「⼊⼒・処理・出⼒」

15. BLT分析基盤はリクルートライフスタイルの処理部分を⼀括で担っている
HPB HPG
JLN
事業データ
CSV
外部データ
S3
Redshift (本番)
Redshift (退避)
BigQuery
アクセスログ
アプリログ Treasure Data
Exadata
Cloud Storage
⼊⼒ 出⼒処理

16. ⾏動ログデータや事業データの
レコード総数
約4,500億件
BLT
ユーザアカウント数
1,200
クエリ数
20,000/day
テーブル数(データマートも含む)
約4,000
利⽤状況

17. 各プロダクト(DWH)の
選定理由と利⽤⽤途は？

18. 利⽤しているDWHたち
HPB HPG
JLN
事業データ
CSV
外部データ
S3
アクセスログ
アプリログ
Cloud Storage
Redshift (本番)
Redshift (退避)
BigQuery
Treasure Data
Exadata

19. Redshift (本番)
Redshift (退避)
BigQuery
Treasure Data
Oracle Exadata
HPB HPG
JLN
事業データ
CSV
外部データ
S3
アクセスログ
アプリログ
Cloud Storage
Exadata

20. Exadata間でのDataGuardのよる冗⻑構成
DBLINKでのOracleDBとのシームレスな接続
スタンダードなSQLが利⽤可能
もちろんCRUD処理もお⼿の物
選定理由
初期投資費⽤
ハードウェアやミドルウェアの運⽤が発⽣する
（Oracle職⼈が必要。。。）
スケールアウトが容易にできない
(あくまでオンプレなので)
⾟い点

21. 売上直結のバッチ処理専⽤環境
売上に直結するバッチ処理を動かしている
アドホッククエリが処理に影響しないよう、
⼀般ユーザには開放していない
事業側OracleDBとDBLINK経由でデータを抽出
利⽤⽤途

22. BigQuery
Treasure Data
Exadata
Amazon Redshift
HPB HPG
JLN
事業データ
CSV
外部データ
S3
アクセスログ
アプリログ
Cloud Storage
Redshift (本番)
Redshift (退避)

23. ODBC/JDBCを利⽤して
外部のBIツールとの接続が可能
CRUD処理が可能
マネージドサービス
他AWSサービスとの連携が容易
イニシャルコストを⼤幅削減
選定理由
メンテナンスの時間指定が曜⽇＋時間帯のみ
コンピュートノードを追加するとデータのリバランスが発⽣し、その
間の処理がRead Onlyに
キャパシティプランニングが必要
⾟い点

24. データマート作成およびアドホック分析環境
ユーザに⼀般開放
アドホック分析やデータマート作成に利⽤
TableauなどのBIツールでの分析
利⽤⽤途
※アドホック ＝ 特定の⽬的のための、その場限りの

25. Redshift (本番)
Redshift (退避)
Treasure Data
Exadata
Google BigQuery
HPB HPG
JLN
事業データ
CSV
外部データ
S3
アクセスログ
アプリログ
Cloud Storage
BigQuery

26. キャパシティプランニングが不要
他の組織、他社とでもデータ共有が容易
データロード処理とクエリ処理が影響し合わない
定額料⾦契約を使えば、料⾦を気にせずクエリを実⾏できる
SLAが99.9%
⽂字列型のバイト指定不要
選定理由
CRUD処理に制限
テーブル単位のアクセス制御ができない
BigQueryのエンジニアが少ない
⾟い点

27. ⾏動ログ収集およびアドホック分析環境
サイトカタリストの⾏動ログを収集
毎⽉約１００億レコード増加
Firebaseのログも連携開始中
アドホック分析⽤として⼀般ユーザにも開放中
利⽤⽤途
※アドホック ＝ 特定の⽬的のための、その場限りの

28. Redshift (本番)
Redshift (退避)
BigQuery
Exadata
Treasure Data
HPB HPG
JLN
事業データ
CSV
外部データ
S3
アクセスログ
アプリログ
Cloud Storage
Treasure Data

29. SDKが充実している
対応している連携サービスが多い
ハードやミドルウェアのメンテ不要
初期投資不要
選定理由
PrestoやHiveに若⼲クセがある
⽇付パーティションのタイムゾーンがUTCなので、
毎回JSTに変更が必要
(契約によるが)同時接続数がコア数に依存するため、
アドホックな分析環境としてユーザに開放するのが難しい
⾟い点

30. アプリのSDKログ収集環境
アプリのSDKログをストリームで取り込んでいる
Treasure Dataで収集・分析した結果を
RedshiftやBigQueryにも連携
利⽤⽤途

31. 利⽤⽤途まとめ

32. データマート作成およびアドホック分析環境
⾏動ログ収集およびアドホック分析環境
アプリのSDKログ収集環境
売上直結のバッチ処理専⽤環境Exadata

33. リクルートライフスタイルのBLT分析基盤では
⼀つの製品に固執するのではなく、
それぞれのDWHの強みを理解した上で、
組み合わせで最適な
マルチクラウド分析基盤を構成している
Conclusion

34. 秋本 ⼤樹
株式会社 リクルートライフスタイル
ネットビジネス本部
データマネジメントグループ
データプラットフォームT
Facebook: daiki.akimoto.50
2011年 ユーザ系SIerに⼊社
• 客先常駐でインフラ構築のPM
• 購買データを⽤いたデータ分析
2014年 ゲーム会社に転職
• ゲームデータ分析基盤の構築
• 社内KPI算出の⾃動化
2017年12⽉より現職

35. 分析基盤の運⽤は
カンタン
だと思いますか？

36. 実は…
タイヘン
です！

37. Start Up
とりあえず分析できる環境
⽤意しといて
BigQueryとRedashで
サクッと作りました
神！
クラウドを利⽤すれば
⽐較的簡単に分析基盤は作れる

38. Recruit Lifestyle
とりあえずデータ
溜めといてよ
最近重くない？
今度はあのデータも
⼊れたいな
⻑年分析基盤の運⽤を続けると
様々な課題が積み上がる
増えるデータ
複雑な連携
増える負荷

39. 本⽇お話したいこと

40. 分析基盤上の課題を
システムと
運⽤で
どう解決していくか

41. システムでの解決
Data Lake

42. Data Lake

43. Data Lake
Single
Store
Various
Data
Data
Hub
様々なデータを⼀箇所に集めることで
⾊々なところに連携しやすくする

44. Data Lake
Single
Store
Various
Data
Data
Hub
様々なデータを⼀箇所に集めることで
⾊々なところに連携しやすくする
AWSとの親和性と安価なことから
当社はS3を採⽤

45. 増えるデータ
増える負荷
複雑な連携
Redshift Spectrum
Migaloo
(社内PJ)
BigQuery
退避Redshift
当社の分析基盤上の課題を解決する
DataLakeを⽤いた仕組みとは

46. 増えるデータの解決
Redshift Spectrum

47. HPB HPG
JLN
事業データ
CSV
外部データ
Redshift (退避)
BigQuery
アクセスログ
アプリログ Treasure Data
Exadata
Cloud Storage
Redshift Spectrum
Redshift (本番)
S3

48. Redshift Spectrum
5ドル/1TB
で参照可能
S3Redshift
クエリ
S3上の⼤量データを
今まで通りRedshiftへのクエリのみで
参照できるようになる仕組み

49. Redshift Spectrum
5ドル/1TB
で参照可能
S3Redshift
クエリ
⼤量データをS3に持たせることで
増えるデータの課題に対応できる
⼤量データ

50. Redshift Spectrum
Redshift S3
頻繁に使われるホットデータと
ユーザから⼀時参照が多いコールドデータで
使い分けることが⼤切
ホットデータ
定期的に
たくさん使われる
コールドデータ
ユーザからの
⼀時参照が多い

51. 複雑な連携の解決
Migaloo(社内PJ)

52. Redshift (退避)
アプリログ Treasure Data
Exadata
Migaloo(社内PJ)
HPB HPG
JLN
事業データ
CSV
外部データ
BigQuery
アクセスログ
Redshift (本番)
S3
Cloud Storage

53. Migaloo(社内PJ)
BigQuery
Redshift
BigQuery⽤
ロードサーバ
Redshift⽤
ロードサーバ
DB1
DB2
DB3
連携元が増えるとサーバごとに
設定する必要があり⼤変

54. Migaloo(社内PJ)
BigQuery
Redshift
S3
DB1
DB2
DB3
S3をデータハブとすると
連携元データを1つ追加するだけで良い

55. Migaloo(社内PJ)
BigQuery
Redshift
DB1
DB2
DB3
将来的に良い製品が出てくると
連携元の分だけ設定を増やす必要がある
とても良い
新製品
新製品⽤
ロードサーバ

56. Migaloo(社内PJ)
BigQuery
Redshift
S3
DB1
DB2
DB3
S3をデータハブとすると
S3からの連携のみ考えればよい
とても良い
新製品

57. 増える負荷の解決
BigQuery
退避Redshift

58. HPB HPG
JLN
事業データ
Exadata
Redshift (本番)
CSV
外部データ
アクセスログ
Redshift (退避)
アプリログ Treasure Data
BigQuery
BigQuery
S3
Cloud Storage

59. BigQuery
S3 Redshift
DB
WEBサーバ
アクセスログ
DBデータ
Redshiftに対し
アクセスログとDBデータを両⽅⼊れると
負荷が上がる
アクセスログ
DBデータ

60. BigQuery
S3
Redshift
DB
WEBサーバ
DBデータ
BigQueryを導⼊し
アクセスログはBigQueryに⼊れることで
負荷を分散する
BigQuery
アクセスログ
アクセスログ
DBデータ

61. BigQueryへのロードの仕組み
最新の技術を取り⼊れ
マルチクラウドをうまく活⽤して
BigQueryへのロードを実現

62. HPB HPG
JLN
事業データ
Exadata
Redshift (本番)
CSV
外部データ
アクセスログ
BigQuery
S3
Cloud Storage
アプリログ Treasure Data
退避Redshift
Redshift (退避)

63. 本番Redshift
S3
本番
Redshift
⼀⽇⼀回
ロード
データの
鮮度
新鮮な
データ
負荷 ⾼い
レスポンス 遅い
⼀⽇⼀回のロードで
ユーザは新鮮なデータを使えるが
レスポンスは遅い

64. 退避Redshift
S3
本番
Redshift
⼀⽇⼀回
ロード
退避
Redshift
毎週⼟曜
同期
毎週⼟曜に本番Redshiftの
スナップショットを⽤いて
退避Redshiftを作成する

65. 退避Redshift
S3
本番
Redshift
⼀⽇⼀回
ロード
鮮度を求めないデータに関しては
退避を使うことで
ユーザはレスポンスを早くできる
退避
Redshift
毎週⼟曜
同期
本番Redshift
(⼀⽇⼀回)
退避Redshift
(毎週⼟曜)
データの
鮮度
新鮮なデータ 古いデータ
負荷 ⾼い 低い
レスポンス 遅い 速い

66. 運⽤での解決
Not Data Swamp

67. Not Data Swamp

68. Not Data Swamp
いかにデータを使うか
溜め続けるだけだと
データは濁る

69. Chatbotの利⽤
George(社内PJ)

70. HPB HPG
JLN
事業データ
Exadata
Redshift (本番)
CSV
外部データ
アクセスログ
BigQuery
Cloud Storage
アプリログ Treasure Data
George(社内PJ)
Redshift (退避)
S3

71. George(社内PJ)
本番Redshift
(⼀⽇⼀回)
退避Redshift
(毎週⼟曜)
データの
鮮度
新鮮なデータ 古いデータ
負荷 ⾼い 低い
レスポンス 遅い 速い
新鮮なデータとレスポンスの速さを
両⽴してほしいという
ユーザからの要望がある

72. George(社内PJ)
本番Redshift
(⼀⽇⼀回)
退避Redshift
(毎週⼟曜)
データの
鮮度
新鮮なデータ
負荷 ⾼い 低い
レスポンス 遅い 速い
ユーザがSlackで呟くことで
S3を介して新鮮なデータが
退避Redshiftにも⼊る
呟く
Slack
S3
新鮮なデータ

73. ユーザライクな操作
Event Driven Upload

74. Redshift (退避)
HPB HPG
JLN
事業データ
Exadata
アクセスログ
BigQuery
Cloud Storage
アプリログ Treasure Data
Event Driven Upload
Redshift (本番)
CSV
外部データ
S3

75. Event Driven Upload
①S3への
アップロード
②Redshift
へのロード
CSV
S3 Redshift
ユーザがRedshiftに
データを⼊れるためには
ある程度専⾨的な知識が必要だった

76. S3 Redshift
Event Driven Upload
簡単な
ブラウザ上の
操作
Event
Driven
Upload
CSV
複雑なことを裏で⾃動的に⾏うので
ブラウザ上での簡単な操作のみで
ユーザはデータを⼊れることができる

77. Conclusion
Data Lake
増える課題に対応
Not Data Swamp
いかにデータを使うか

78. http://engineer.recruit-lifestyle.co.jp/recruiting/
⼤募集！！
⼀緒に分析基盤を作ろう！