2017-11-22 wed. 第 2 回 Google Cloud INSIDE Games & Apps 株式会社リクルートライフスタイル データエンジニア 南谷 和毅 氏の登壇スライドです。

1. データプロダクトを支える
ビッグデータ基盤
2017-11-22 @グーグル東京オフィス
リクルートライフスタイル データエンジニア
南谷 和毅

2. 自己紹介
南谷 和毅 Data Engineer
[略歴]
2015.4 リクルートホールディングス新卒入社
2015.7- リクルートライフスタイル
データ基盤チーム配属
他５つほどチームを兼務..
[業務]
新サービスの開発、ログ基盤の開発、運用
2

3. 会社紹介
3

4. 4
リクルートの事業会社の１つ

5. 5
本日お話すること

6. 本日お話しすること
について、リクルートライフスタイルのGCP上のデータパイプライン
と開発中の新規データプロダクト(クライアント向けのBIツール)を通
してお話しします
6
❖ データプロダクトを支えるビッグデータ基盤の設計
❖ GCPプロダクト選定の背景・使い分け
❖ 開発・運用してわかったノウハウ

7. 7
インフラ設計方針とGCPを選択
した背景

8. 8
データプロダクト基盤
を設計するうえで大きく意識した
３つの環境作り

9. データプロダクト基盤を設計する上で意識したこと
① データを自立的に活かし、
② データの利活用を通したPDCAを高速に回しながら、
③ 誰もがデータから価値を生み出せる基盤
9

10. ① 誰もがデータを自立的に活かせる基盤
Q1. このデータの意味は誰に聞けばわかるんだろう...
Q2. このデータをあるDBに入れたいんだけど、毎回お願いする
のが面倒だなあ...
Q3. データ処理したんだけど、負荷高いけど他ジョブに影響しな
いかなあ...
10
誰もがデータの発見、移動、処理、機械学習を自立してでき、また本
質的な作業に集中できている状態
データを扱う人の悩み

11. ② PDCAを高速に回しデータから価値を生む基盤
データの入力、処理、出力それぞれが疎結合で、柔軟に変更でき、
データの取り込みからユーザ提供までをトライ&エラーで一気貫通で
きるインフラ
11
データ
ロード
データ
クレンジ
ング
データ
マート
作成
加工
ML
・・・
DB・スト
レージ
への保
存
API
ユーザ
提供
一気貫通してトライ &エラーできる環境

12. 12
❖ 他領域への横展開が容易な基盤
弊社は多くのサービスを運営しており、データ利活用の潜在性が高い. 簡単に基
盤を横展開できるように、terraform, ansible, packerなどで構成管理
❖ 誰もがデータプロダクトを開発・運用できる基盤
十数行程度のコードでデータ加工された状態でユーザーに届く.
どんなエンジニアでも開発でき、もちろんAI系のエンジニアも活用できる
③ 誰もがデータから価値を生み出せる

13. ビッグデータを扱う環境が万人に開かれており、
フルマネージドで運用負荷がほとんどなく、
インフラ設計がシンプルで構築が比較的ラクな
GCPは今回の基盤設計方針と最も親和性が高い
13
３つの設計方針と最も親和性が高いGCPを採用

14. 14
アーキテクチャ

15. データプロダクト
社内共通
ETL基盤
Firewall
15
S3Oracle DB
Cloud
Functions
Container
Engine
BigQuery BigQuery
Cloud
Storage
Cloud
Storage
Data
store
Postgre
SQL
MySQL
global
LB社内環境
global
LB
Drone
GCE
Digdag
GCE
主要なデータフロー
主要なリクエストフロー
Dataflow
Datarobot
API
GAE

16. データプロダクト
社内共通
ETL基盤
Firewall
16
S3Oracle DB
Cloud
Functions
Container
Engine
BigQuery BigQuery
Cloud
Storage
Cloud
Storage
Data
store
Postgre
SQL
MySQL
global
LB社内環境
global
LB
Drone
GCE
Digdag
GCE
主要なデータフロー
主要なリクエストフロー
Dataflow
Datarobot
API
GAE
他サービスへ横展開可能なように、GCPのインフラをterraformで、ミ
ドルウェアレイヤーをpackerやansibleで構成管理

17. データプロダクト
社内共通
ETL基盤
Firewall
17
S3Oracle DB
Cloud
Functions
Container
Engine
BigQuery BigQuery
Cloud
Storage
Cloud
Storage
Data
store
Postgre
SQL
MySQL
global
LB社内環境
global
LB
Drone
GCE
Digdag
GCE
Dataflow
Datarobot
API
GAE
データの入力から出力までを、
一気貫通して１つのチームが
試行錯誤できるようにパイプラインを整備

18. 18
1. 入力

19. データプロダクト
社内共通
ETL基盤
Firewall
19
S3Oracle DB
Cloud
Functions
Container
Engine
BigQuery BigQuery
Cloud
Storage
Cloud
Storage
Data
store
API
GAE
Postgre
SQL
MySQL
global
LB社内環境
global
LB
Drone
GCE
Digdag
GCE
Dataflow
Datarobot
① じゃらんなど各サービスのOracle DBからのデータ取込み
(社内共通データパイプライン)
② 本サービスからのデータ取り込み

20. 1.1 Oracle DB→BigQuery
20
S3Oracle DB
Container
Engine
BigQuery
SQS
1. Oracle からデータをダンプして、 S3
に書き出す処理. putされたらSQSに
通知
2. GKEでS3 に書き出されたデータを
GCS へコピーする処理. 1.のSQSを
polling
3. GKEでGCS にコピーされたデータを
BigQuery へロードする処理. 2.の
SQSをpolling
4. GKEで差分更新のテーブルを洗い
替えする処理
①
② ③ ④
元々あったOracle→S3→Redshiftのパイプラインを利用し、
S3 → BigQueryのパイプラインを構築
Red
shift
Cloud
Storage
SQSのキューの長さでAuto Scaleするように設計

21. 1.2 本サービスからのデータ取り込み
21
① 右記のように共通のconfigファイルを
jsonで定義
② Config用バケットにおき
③ 後は所定のGCSのパスにputする
gs://bq-loader/:dataset/:table/**
bigquery-connector-gcsをcloud functionで開発
GCSにデータをputすると、BQにイベントドリブンでデータがロードさ
れる {
"bq_config": {
"load": {
"createDisposition":
"CREATE_IF_NEEDED",
"writeDisposition": "WRITE_TRUNCATE",
"encoding": "UTF-8",
"maxBadRecords": "0",
"ignoreUnknownValues": "false"
}
},
"job_config" : {
"timeout" : 30000
},
"slack" : {
"url" : "#slack.url#",
"channel" : "#slack.channel#"
}

22. 2. データ処理、加工、
機械学習
22

23. データプロダクト
ETL基盤
Firewall
23
S3Oracle DB
Cloud
Functions
Container
Engine
BigQuery BigQuery
Cloud
Storage
Cloud
Storage
Data
store
API
GAE
Postgre
SQL
MySQL
global
LB社内環境
global
LB
Drone
GCE
Digdag
GCE
Dataflow
他の会社様
DB
Datarobot
データ加工・MLをBigQuery/Dataflow/Datarobotで
2. データ処理、機械学習

24. 2. データ処理、機械学習
24
❖ コストを抑えるためにus-central-1リージョンを利用
多くのリソースが必要なビッグデータ処理については、極力コストを抑えるため
にus-central-1リージョンを利用. また使うときだけインスタンスをたてる
❖ 用途にあわせて最適なプロダクト/使い方を選ぶ
1. BigQuery (日次バッチ）
2. Dataflow
3. BigQuery (オンライン）
4. Datarobot (機械学習) ＊GCPサービスではないです

25. 2.1 BigQuery(日次バッチ)
コストとレイテンシーの観点から、事前に準備できるデータは日次で
BigQueryで処理し、Datastoreにロード. 本サービスのデータ処理
の９割がBigQueryで行われている.
25

26. 2.2 Cloud Dataflow
1) SQLでも書こうと思えば書けるが、将来の開発・運用面を考えた時
に、コードが冗長で可読性などが低く、修正などが辛い場合
2) BigQueryではパフォーマンスがでない場合
e.g., 対象レコードが数千万件のクロスジョインなど
26
1)の例 集客分析
種類Aj(時間帯) * Bk(来店経路) * Cl(人数)のすべての組み合わせにおける来客数を計算したい .
さらにDm(hoge)、En(fuga)と種類が増える可能性があり、さらに種類の中のパターン j, k, lも増え
る可能性がある

27. 2.2 Cloud Dataflow
27
❖ Apache Beamのドキュメントを参考に
Cloud Dataflowのドキュメントは最新のバージョンを追えていないことがあ
るので、Apache Beamのドキュメントを参考に.
❖ 開発/デバッグはDirectRunner(ローカル実行モード)
DirectRunnerで実行するとインスタンス起動のオーバーヘッドがなく、またデ
バッグログを手元で見れる. 以前はDataflowRunner(リモート実行モード)と
一部互換性がないバグがあったがv2.2.0で修正された
Dataflowで一般的に使われているJavaではなく、
データ処理に適したPythonを採用

28. 2.3 BigQuery (オンライン)
サービスのユーザが複数の条件で詳細に分析をしたい場合は、事前
にデータを準備することが難しいので、オンラインでサービスのAPIか
ら直接BigQueryにクエリを投げている
28
例) A,B,C店舗のD商品のE日とF日の売り上げを比較したい

29. 2.4 Datarobot (機械学習)
bigquery-connector-datarobotをpythonで開発
YAMLを書くだけで、BigQueryのデータを使って誰でも簡単に予測
が可能に
29
digdag / nginx
Compute Engine
predction
BigQuery
コマンダー
datarobot:
prediction_name: 'prediction'
project_id: 1234
model_id: '5678'
pred_type: 'FLOAT'
keep_cols:
- 'id'
bigquery:
query: 'SELECT * FROM `fuga.pred`'
predicted:
table: hoge.predicted
Datarobot

30. Digdag on GCE
- Ansible, Packerで構成管理
- gcloud beta compute
instance-groups managed
rolling-action replaceでローリング
アップデート
- Auto Scaleを設定
30
digdag / nginx
Compute Engine
Postgres
SQL
Cloud SQL
Global LB
Cloud Load Balancing

31. 31
3. データロード

32. データプロダクト
ETL基盤
Firewall
32
S3Oracle DB
Cloud
Functions
Container
Engine
BigQuery BigQuery
Cloud
Storage
Cloud
Storage
Data
store
API
GAE
Postgre
SQL
MySQL
global
LB社内環境
global
LB
Drone
GCE
Digdag
GCE
Dataflow
他の会社様
DB
Datarobot
レイテンシーを意識し、
BigQueryなどで加工したデータはDatastoreへ保存
3. データロード

33. 3. データロード
33
BigQueryのデータをDatastoreにロードできる
bigquery-connector-datastoreをDataflowで開発
- 右記のようなYAMLファイルに定
義を書いて実行するだけ
- BQのデータ型に基づいて、最適
なDatastoreのプロパティの型
に変換してロード
dataflow:
job_name: 'sales-job'
bigquery:
query: 'SELECT * FROM processed.sales
datastore:
namespace: test
kind: Sales
key:
- 'id'
indexed:
- 'sales'
- 'b_date'

34. Memcacheの更新について
DataflowでDatatoreに日次でデータロードしているが、
Dataflow(Datastore Connector)がNDBを使えないので、毎度
キャッシュを強制的にflushしている.
34

35. 35
4. データ表示

36. データプロダクト
ETL基盤
Firewall
36
S3Oracle DB
Cloud
Functions
Container
Engine
BigQuery BigQuery
Cloud
Storage
Cloud
Storage
Data
store
API
GAE
Postgre
SQL
MySQL
global
LB社内環境
global
LB
Drone
GCE
Digdag
GCE
Dataflow
他の会社様
DB
4. データ表示
十数行のコードでデータ加工されたデータがユーザーに届くよう
にAPIを設計.
誰でも簡単にプロダクトアウトプット可能にするため、運用負荷が
ほとんどないApp Engine (SE) を使用

37. Memcache
Cloud
DNS
Cloud
Datastore
BigQuery
React / Flask
App Engine
4. データ表示
37
- フロントはReact
- アプリケーションは
Flask/Python
- データ層はdatastore、
BigQuery、Memcache
App Engine + Datastore + Memcache + BigQuery

38. 38
5. メタデータの管理

39. {
"description": "予約ID",
"mode": "NULLABLE",
"name": "reserve_id",
"type": "STRING"
},
・・・
bq query -t reserve_mart
-s schema/reserve.json
-f sql/reserve.sql
・・・
テーブル作成時にSchemaの定義を付与. 必ず目を通す場所にメ
タデータを記す
5. メタデータの管理
reserve.json

40. 40
6. アーキテクチャのまとめ

41. アーキテクチャのまとめ
1. ユーザからのリクエストのレイテンシーを意識し、加工済み
データをほぼすべてDatastore/memcacheに保存
2. データ処理は用途に合わせて最適なプロダクトを使う
3. データ移動は簡易ツールを作成し、誰でも自立してデータ活用
できる環境を整備
4. 入力から出力まで一気貫通してデータを分析できる環境を整
備
5. 開発に集中したいので極力フルマネージド製品を採用
41

42. 42
今後のGCPに期待すること

43. フルマネージドな”データパイプライン”に期待
bigquery-connector-gcs
bigquery-connector-datastore
bigquery-connector-datarobot
など、データパイプラインを誰でも自立して活かせる環境を
構築してきたが、
プロダクト間のデータ移動もフルマネージドで扱えたら嬉しい
43

44. 44
最後に

45. 絶賛採用中
45
GCPでデータプロダクトを作りたい人を
絶賛募集中！

46. 46
質問タイム