2017/03/29 Google Cloud はやわかりセミナー in 名古屋での、松田の講演資料になります

1. HadoopをBQに
マイグレしようとしてる話
Mar 29 2017
リクルートテクノロジーズ ビッグデータ部 松田徹也

2. 自己紹介
松田 徹也
まつだ てつや
2011.4 某通信キャリア入社
2011.6 新人研修で東海支店（名古屋 伏見）で1.5ヶ月営業OJT
2011.8 R&D組織配属
2015.8 リクルートテクノロジーズ入社
・ビッグデータクラウド基盤開発
・Hadoop運用
・A3RT開発
NEXTでもらいました！

3. リクルートのビジネスモデル
Matching
Business
HR
Bridal
Group
Buying
Used
Cars
Travel
Real
Estate
Beauty Gourmet
Social Games
E-Commerce
Ad Network
New
Business
Consumers Enterprise

4. リクルートの事業領域
「選択」をサポートするような情報サービスを展開
Life event area
斡旋領域
結婚領域
就職・転職領域
住宅領域
中古車領域
出産・育児領域
学習領域
Lifestyle Area
Travel
IT/ TrendLifestyle
Health & Beauty

5. リクルートテクノロジーズの立位置
Infrastructure
/Security
Big Data Solutions
Technology R&D
Systems
Development
Recruit
Holdings
Recruit Career
Recruit Sumai Company
Recruit Lifestyle
Recruit Jobs
Recruit Staffing
Recruit Marketing Partners
Staff service Holdings
Recruit Administration
Recruit Communications
Business/
Service
Function/
Support
Project
Management
UXD/SEO
Internet Marketing
Recruit Technologies

6. リクルートHadoopのイメージ

7. リクルートHadoop
クラスタを用途（サービス）毎に作って個別運用
● 大量（規模＋数）クラスタの運用
● リソース量の綿密なコントロール

8. Hadoop課題感
● 同時並列実行
● バージョンアップ
● 処理リソースとデータ量のバランス
● 運用労力

9. 課題1：同時並列実行
● バッチとアドホックの制御
○ 施策系のバッチ（レコメンドリスト作成・メール配信）が最優先
○ データサイエンティストはアドホックに常に分析したい
● バッチウインドウの調整
○ 新しい施策を回したいけど、差し込める幅が無い
● 利用用途・利用ユーザーの拡大
○ 非エンジニアの利用
○ 期末などに集計祭り

10. 課題2：バージョンアップ
● EOSL
○ ディストリベンダーのサポート期限
○ 新しい機能は欲しくなくても強制的にバージョンアップ
● クラスタ
○ 全クラスタを順番にバージョンアップ
○ 検証環境を同時には用意できない
● 運用チームは常にバージョンアップしている
○ 全てのバージョンが上がった頃には、すでに次の計画・・・

11. 課題3：処理リソースとデータ量のバランス
● クラスタ毎にHadoop用途が異なる
● データをどんどん溜めたいクラスタ
○ 処理リソースのお代わりはいらないのに・・・
● 処理リソースが欲しいクラスタ
○ データ量はいらなくても、処理能力だけ欲しい
○ 一時的（夜間・期末etc）に処理リソースを増やしたい

12. 課題4：運用労力
● パッチを1ヶ月がかりで全クラスタに適用・・・
● どのクラスタも余裕なくてカツカツ
● 構成管理
● 増減計画・発注

13. BQで解決できそう
※BQ = BigQuery
https://cloud.google.com/bigquery/

14. Hadoop課題感
● 同時並列実行
● バージョンアップ
● 処理リソースとデータ量のバランス
● 運用労力

15. Hadoop課題感
● 同時並列実行
クラスタ・リソース確保という概念がない
● バージョンアップ
● 処理リソースとデータ量のバランス
● 運用労力

16. Hadoop課題感
● 同時並列実行
クラスタ・リソース確保という概念がない
● バージョンアップ
バージョンアップ不要のはず！（Legacy SQL…）
● 処理リソースとデータ量のバランス
● 運用労力

17. Hadoop課題感
● 同時並列実行
クラスタ・リソース確保という概念がない
● バージョンアップ
バージョンアップ不要のはず！（Legacy SQL…）
● 処理リソースとデータ量のバランス
完全分離・どちらも無限
● 運用労力

18. Hadoop課題感
● 同時並列実行
クラスタ・リソース確保という概念がない
● バージョンアップ
バージョンアップ不要のはず！（Legacy SQL…）
● 処理リソースとデータ量のバランス
完全分離・どちらも無限
● 運用労力
フルマネージド

19. 試しに少しやってみた
HIVE文化の中
そもそもBQ自体が受け入れられるのか？

20. 試しに少しやってみた
HIVE文化の中
そもそもBQ自体が受け入れられるのか？
分析に使っているデータを一部BQに入れて
BQで分析をしてもらう

21. 試しに少しやってみた
“ ”
もうHiveには戻れないっす
某データサイエンティスト
“
さんざん甘い汁吸わしといて
やっぱりやめます
とか言わないでくださいよ
某データサイエンティスト

22. オンプレ
現状の構成
バッチ
サーバ
JP1
共有Storage
FTP
サーバ
OracleDB
Hive load
I/F files
ssh
・HQL
・MapReduce
・bash script
メールレポート

23. GCP
移行後の構成
オンプレ
共有Storage
OracleDB
BQサービス
バッチ
サーバ
JP1
loadI/F files
ssh
BigQuery
バッチサー
バ
・SQL
・bash script
・メール送信
・データ連携
FTP
サーバ
Nessie (データ連携)
メールレポート
FTP
サーバ

24. GCP
移行後の構成
オンプレ
共有Storage
OracleDB
BQサービス
バッチ
サーバ
JP1
loadI/F files
ssh
BigQuery
バッチサー
バ
・SQL
・bash script
・メール送信
・データ連携
FTP
サーバ
Nessie (データ連携)
メールレポート
FTP
サーバ

25. Nessie
ロゴ作成中
データ連携API
● データ連携用ワーカーのコントロール
● データ連携ジョブ管理
実装済連携
● Hiveテーブル→BQ連携
● Oracleテーブル→BQ連携

26. Nessieアーキテクチャー概要
Frontend
API
Worker
Queue
Worker
Monitor
Job Statut
Manager
Worker
Operator
DataTransfer
Worker
Nessie
https://www.flickr.com/photos/josek/2616023190

27. Nessieアーキテクチャー概要
Frontend
API
Worker
Queue
Worker
Monitor
Job Statut
Manager
Worker
Operator
DataTransfer
Worker
Nessie
https://www.flickr.com/photos/josek/2616023190

28. やってみた
アプリケーション（HQL, UDF, JAR）の移行
HQL→Standard SQL
UDF→UDF
MapReduce→クエリ化
Nessie・その他周辺機能
特に問題なし
Nessie性能
問題発生！

29. Nessieの性能
データ転送速度が遅すぎて、業務性能要件を満たさない
現状
Sqoop
Nessie
Embluk
性能差
tableA 12秒 54秒 22%
tableB 366秒 908秒 40%
tableC 1011秒 7264秒 14%
tableD 1841秒 ??? ???

30. What’s Next？
● Nessie高速化
○ Sqoop方式で検証
■ 高速化できることを確認済み（3.31）
● BQダッシュボード
○ 各テーブル毎諸々（データ量・最終アクセス日etc）
○ slot利用状況
● バックアップ機能
○ オペミス対策