Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

データプロダクトを支えるビッグデータ基盤

3,785 views

Published on

2017-11-22 wed.
第 2 回 Google Cloud INSIDE Games & Apps

株式会社リクルートライフスタイル データエンジニア 南谷 和毅 氏の登壇スライドです。

Published in: Engineering
  • Be the first to comment

データプロダクトを支えるビッグデータ基盤

  1. 1. データプロダクトを支える ビッグデータ基盤 2017-11-22 @グーグル東京オフィス リクルートライフスタイル データエンジニア 南谷 和毅
  2. 2. 自己紹介 南谷 和毅 Data Engineer [略歴] 2015.4 リクルートホールディングス新卒入社 2015.7- リクルートライフスタイル データ基盤チーム配属 他5つほどチームを兼務.. [業務] 新サービスの開発、ログ基盤の開発、運用 2
  3. 3. 会社紹介 3
  4. 4. 4 リクルートの事業会社の1つ
  5. 5. 5 本日お話すること
  6. 6. 本日お話しすること について、リクルートライフスタイルのGCP上のデータパイプライン と開発中の新規データプロダクト(クライアント向けのBIツール)を通 してお話しします 6 ❖ データプロダクトを支えるビッグデータ基盤の設計 ❖ GCPプロダクト選定の背景・使い分け ❖ 開発・運用してわかったノウハウ
  7. 7. 7 インフラ設計方針とGCPを選択 した背景
  8. 8. 8 データプロダクト基盤 を設計するうえで大きく意識した 3つの環境作り
  9. 9. データプロダクト基盤を設計する上で意識したこと ① データを自立的に活かし、 ② データの利活用を通したPDCAを高速に回しながら、 ③ 誰もがデータから価値を生み出せる基盤 9
  10. 10. ① 誰もがデータを自立的に活かせる基盤 Q1. このデータの意味は誰に聞けばわかるんだろう... Q2. このデータをあるDBに入れたいんだけど、毎回お願いする のが面倒だなあ... Q3. データ処理したんだけど、負荷高いけど他ジョブに影響しな いかなあ... 10 誰もがデータの発見、移動、処理、機械学習を自立してでき、また本 質的な作業に集中できている状態 データを扱う人の悩み
  11. 11. ② PDCAを高速に回しデータから価値を生む基盤 データの入力、処理、出力それぞれが疎結合で、柔軟に変更でき、 データの取り込みからユーザ提供までをトライ&エラーで一気貫通で きるインフラ 11 データ ロード データ クレンジ ング データ マート 作成 加工 ML ・・・ DB・スト レージ への保 存 API ユーザ 提供 一気貫通してトライ &エラーできる環境
  12. 12. 12 ❖ 他領域への横展開が容易な基盤 弊社は多くのサービスを運営しており、データ利活用の潜在性が高い. 簡単に基 盤を横展開できるように、terraform, ansible, packerなどで構成管理 ❖ 誰もがデータプロダクトを開発・運用できる基盤 十数行程度のコードでデータ加工された状態でユーザーに届く. どんなエンジニアでも開発でき、もちろんAI系のエンジニアも活用できる ③ 誰もがデータから価値を生み出せる
  13. 13. ビッグデータを扱う環境が万人に開かれており、 フルマネージドで運用負荷がほとんどなく、 インフラ設計がシンプルで構築が比較的ラクな GCPは今回の基盤設計方針と最も親和性が高い 13 3つの設計方針と最も親和性が高いGCPを採用
  14. 14. 14 アーキテクチャ
  15. 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. 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. 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 データの入力から出力までを、 一気貫通して1つのチームが 試行錯誤できるようにパイプラインを整備
  18. 18. 18 1. 入力
  19. 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. 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. 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. 22. 2. データ処理、加工、 機械学習 22
  23. 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. 24. 2. データ処理、機械学習 24 ❖ コストを抑えるためにus-central-1リージョンを利用 多くのリソースが必要なビッグデータ処理については、極力コストを抑えるため にus-central-1リージョンを利用. また使うときだけインスタンスをたてる ❖ 用途にあわせて最適なプロダクト/使い方を選ぶ 1. BigQuery (日次バッチ) 2. Dataflow 3. BigQuery (オンライン) 4. Datarobot (機械学習) *GCPサービスではないです
  25. 25. 2.1 BigQuery(日次バッチ) コストとレイテンシーの観点から、事前に準備できるデータは日次で BigQueryで処理し、Datastoreにロード. 本サービスのデータ処理 の9割がBigQueryで行われている. 25
  26. 26. 2.2 Cloud Dataflow 1) SQLでも書こうと思えば書けるが、将来の開発・運用面を考えた時 に、コードが冗長で可読性などが低く、修正などが辛い場合 2) BigQueryではパフォーマンスがでない場合 e.g., 対象レコードが数千万件のクロスジョインなど 26 1)の例 集客分析 種類Aj(時間帯) * Bk(来店経路) * Cl(人数)のすべての組み合わせにおける来客数を計算したい . さらにDm(hoge)、En(fuga)と種類が増える可能性があり、さらに種類の中のパターン j, k, lも増え る可能性がある
  27. 27. 2.2 Cloud Dataflow 27 ❖ Apache Beamのドキュメントを参考に Cloud Dataflowのドキュメントは最新のバージョンを追えていないことがあ るので、Apache Beamのドキュメントを参考に. ❖ 開発/デバッグはDirectRunner(ローカル実行モード) DirectRunnerで実行するとインスタンス起動のオーバーヘッドがなく、またデ バッグログを手元で見れる. 以前はDataflowRunner(リモート実行モード)と 一部互換性がないバグがあったがv2.2.0で修正された Dataflowで一般的に使われているJavaではなく、 データ処理に適したPythonを採用
  28. 28. 2.3 BigQuery (オンライン) サービスのユーザが複数の条件で詳細に分析をしたい場合は、事前 にデータを準備することが難しいので、オンラインでサービスのAPIか ら直接BigQueryにクエリを投げている 28 例) A,B,C店舗のD商品のE日とF日の売り上げを比較したい
  29. 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. 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. 31 3. データロード
  32. 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. 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. 34. Memcacheの更新について DataflowでDatatoreに日次でデータロードしているが、 Dataflow(Datastore Connector)がNDBを使えないので、毎度 キャッシュを強制的にflushしている. 34
  35. 35. 35 4. データ表示
  36. 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. 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. 38 5. メタデータの管理
  39. 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. 40 6. アーキテクチャのまとめ
  41. 41. アーキテクチャのまとめ 1. ユーザからのリクエストのレイテンシーを意識し、加工済み データをほぼすべてDatastore/memcacheに保存 2. データ処理は用途に合わせて最適なプロダクトを使う 3. データ移動は簡易ツールを作成し、誰でも自立してデータ活用 できる環境を整備 4. 入力から出力まで一気貫通してデータを分析できる環境を整 備 5. 開発に集中したいので極力フルマネージド製品を採用 41
  42. 42. 42 今後のGCPに期待すること
  43. 43. フルマネージドな”データパイプライン”に期待 bigquery-connector-gcs bigquery-connector-datastore bigquery-connector-datarobot など、データパイプラインを誰でも自立して活かせる環境を 構築してきたが、 プロダクト間のデータ移動もフルマネージドで扱えたら嬉しい 43
  44. 44. 44 最後に
  45. 45. 絶賛採用中 45 GCPでデータプロダクトを作りたい人を 絶賛募集中!
  46. 46. 46 質問タイム

×