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.
オンプレ、クラウドを組み合わ
せて作るビックデータ基盤
-データ基盤の選び方-
builderscon tokyo 2017
08/04 2017
山田 雄
ネットビジネス本部
データ基盤チーム
1.自己紹介
2.リクルートライフスタイルの分析基盤
3.分析基盤(DWH)の比較
4.分析基盤の続け方
本日のアジェンダ
1.自己紹介
2.リクルートライフスタイルの分析基盤
3.分析基盤(DWH)の比較
4.分析基盤の続け方
本日のアジェンダ
■山田 雄(ヤマダ ユウ)
株式会社 リクルートライフスタイル
ネットビジネス本部
データ基盤T
Twitter:@nii_yan
GitHub:https://github.com/yu-yamada
・以前はメールマーケティング用基盤の作成...
会社紹介
Engineering
for data
Business
with data
技術でビジネスを
ドライブする
Stable Infrastructure Continual Innovation+
リクルートライフスタイルにおけるエンジニアの...
1.自己紹介
2.リクルートライフスタイルの分析基盤
3.分析基盤(DWH)の比較
4.分析基盤の続け方
本日のアジェンダ
リクルートライフスタイルの持つデータ
リクルートライフスタイルの分析基盤
DWH
HPB JLN
HPG
・・・
各事業データ
施策Batch用
Netezza
サイトログ保存用
TreasureData
Adhoc分析用
Redshift
外部データ
TSV CSV
3
行動ログ...
リクルートライフスタイルの分析基盤
DWH
HPB JLN
HPG
・・・
各事業データ
施策Batch用
Netezza
サイトログ保存用
TreasureData
Adhoc分析用
Redshift
外部データ
TSV CSV
3
行動ログ...
リクルートライフスタイルの分析基盤
DWH
HPB JLN
HPG
・・・
各事業データ
施策Batch用
Netezza
サイトログ保存用
TreasureData
Adhoc分析用
Redshift
外部データ
TSV CSV
3
行動ログ...
リクルートライフスタイルの分析基盤
DWH
HPB JLN
HPG
・・・
各事業データ
施策Batch用
Netezza
サイトログ保存用
TreasureData
Adhoc分析用
Redshift
外部データ
TSV CSV
3
行動ログ...
リクルートライフスタイルの分析基盤
DWH
HPB JLN
HPG
・・・
各事業データ
施策Batch用
Netezza
サイトログ保存用
TreasureData
Adhoc分析用
Redshift
外部データ
TSV CSV
3
行動ログ...
リクルートライフスタイルの分析基盤
DWH
HPB JLN
HPG
・・・
各事業データ
施策Batch用
Netezza
サイトログ保存用
TreasureData
Adhoc分析用
Redshift
外部データ
TSV CSV
3
行動ログ...
リクルートライフスタイルの分析基盤
DWH
HPB JLN
HPG
・・・
各事業データ
施策Batch用
Netezza
サイトログ保存用
TreasureData
Adhoc分析用
Redshift
外部データ
TSV CSV
3
行動ログ...
リクルートライフスタイルの分析基盤
DWH
HPB JLN
HPG
・・・
各事業データ
施策Batch用
Netezza
サイトログ保存用
TreasureData
Adhoc分析用
Redshift
外部データ
TSV CSV
3
行動ログ...
リクルートライフスタイルの分析基盤
DWH
HPB JLN
HPG
・・・
各事業データ
施策Batch用
Netezza
サイトログ保存用
TreasureData
Adhoc分析用
Redshift
外部データ
TSV CSV
3
行動ログ...
リクルートライフスタイルの分析基盤
DWH
HPB JLN
HPG
・・・
各事業データ
施策Batch用
Netezza
サイトログ保存用
TreasureData
Adhoc分析用
Redshift
外部データ
TSV CSV
3
行動ログ...
リクルートライフスタイルの分析基盤
DWH
HPB JLN
HPG
・・・
各事業データ
施策Batch用
Netezza
サイトログ保存用
TreasureData
Adhoc分析用
Redshift
外部データ
TSV CSV
3
行動ログ...
リクルートライフスタイルの分析基盤
DWH
HPB JLN
HPG
・・・
各事業データ
施策Batch用
Netezza
サイトログ保存用
TreasureData
Adhoc分析用
Redshift
外部データ
TSV CSV
3
行動ログ...
リクルートライフスタイルの分析基盤
DWH
HPB JLN
HPG
・・・
各事業データ
施策Batch用
Netezza
サイトログ保存用
TreasureData
Adhoc分析用
Redshift
外部データ
TSV CSV
3
行動ログ...
リクルートライフスタイルの分析基盤
DWH
HPB JLN
HPG
・・・
各事業データ
施策Batch用
Netezza
サイトログ保存用
TreasureData
Adhoc分析用
Redshift
外部データ
TSV CSV
3
行動ログ...
ETLフレームワーク
独自で実装した ETLのフレームワークを用意し、SQLと
YAMLを作るだけでデータの移動を出来るようにしている
フレームワークで出来ること
Meta情報管理
Meta情報管理
事業DBやDWH、Adobe Analyticsのメタデータを日次
で連携し、どのテーブルはどんな定義でどんなデータ
が入ってるいるのかを一元的に管理。
また、カラムに対してのコメント機能もあるため、単純
なDDLよりもわかり...
DynamoDB Lambda
API
Gateway
Kafka
on-premises
Configuration
Management
Monitoring
Grafana
リアルタイムデータを扱う基盤
DynamoDB Lambda
API
Gateway
on-premises
Configuration
Management
Monitoring
Grafana
Kafka
データハブ基盤
Lambda
API
Gateway
on-premises
Configuration
Management
Monitoring
Grafana
Kafka DynamoDB
ストリーム処理基盤
Kafka
on-premises
Configuration
Management
Monitoring
Grafana
DynamoDB Lambda
API
Gateway
データ提供部分(API)
1.自己紹介
2.リクルートライフスタイルの分析基盤
3.分析基盤(DWH)の比較
4.分析基盤の続け方
本日のアジェンダ
DWH(データウェアハウス)
直訳するとデータの倉庫
• 分析に特化した、データを貯める場所。
• 列指向の場合が多い。
• 基本的にデータは追記のみ行う(削除、更新は行わない)。
• レスポンスはそこまで早くない。
ざっくり言うとRDBよりレ...
1. 容量
2. 料金
3. スケール出来るか
4. データパイプラインは作りやすいか
5. 分析者の用途に合っているか
1. Crudができるか
2. 分析ツール、モデリングツールが使えるか(SPSSなど)
3. ODBCなどで接続出来るか
...
クラウド
or
オンプレ
クラウド
or
オンプレ
オンプレ
Hadoop
(Hive,Presto,Spark…)
Exadata , Netezza, Teradata
クラウド
AWS
Redshift
EMR
GCP BigQuery
Paas TreasureData
オンプレ:Hadoop(Hive,Presto,Spark)
容量 サーバ台数次第、上限はDCなどで決まる
料金 初期費用が高い
スケール サーバを増やせば出来るがしんどい
データパイプライン OSSが充実
crud パーティション単位でのde...
オンプレ:Hadoop(Hive)
容量 サーバ台数次第、上限はDCなどで決まる
料金 初期費用が高い
スケール サーバを増やせば出来るがしんどい
データパイプライン OSSが充実
crud × パーティション単位でのdelete,update...
オンプレ: Exadata,Netezza,Teradataなど
容量 最初の構成による。上限あり
料金 初期費用が高い
スケール ほぼ出来ないと思った方が良い
データパイプライン 一部OSSが対応してるものの、有償のもの以外は独自実装が
必要...
オンプレ: Exadata,Netezza,Teradataなど
容量 最初の構成による。上限あり
料金 初期費用が高い
スケール ほぼ出来ないと思った方が良い
データパイプライン 一部OSSが対応してるものの、有償のもの以外は独自実装が
必要...
クラウド: Amazon EMR(Hadoop)
容量 構成次第 上限なし
料金 構成次第 使わない際は落として節約可能
スケール 即時可能
データパイプライン DMS,GlueなどAWSのサービスで対応。その他OSSでも対応あり
crud d...
クラウド: AWS EMR(Hadoop)
容量 構成次第 上限なし?
料金 構成次第 使わない際は落として節約可能
スケール 即時可能
データパイプライン DMS,GlueなどAWSのサービスで対応。その他OSSでも対応あり
crud パーテ...
クラウド: Amazon Redshift
容量 構成次第 上限2PB,Spectrum使用で上限なし
料金 構成次第 スモールスタート可能
スケール 構成によってはスケールには時間がかかり、その間はselectの
み
データパイプライン DM...
クラウド: AWS Redshift
容量 構成次第 上限2PB
料金 構成次第 スモールスタート可能
スケール 構成によってはスケールには時間がかかり、その間はselectの
み
データパイプライン DMS,GlueなどAWSのサービスで対応...
クラウド: GCP BigQuery
容量 上限なし
料金 クエリ課金
スケール 裏側で勝手にしてくれる
データパイプライン DataflowなどGCPのサービスで対応。その他OSSでも対応あり
crud 基本的に対応(回数制限あり)
周辺分析...
クラウド: GCP BigQuery
容量 上限なし
料金 クエリ課金
スケール 裏側で勝手にしてくれる
データパイプライン DataflowなどGCPのサービスで対応。その他OSSでも対応あり
crud 基本的に対応(回数制限あり)
周辺分析...
クラウド: Paas TreasureData
容量 契約による上限あり
料金 データ量やリソースにより変動
スケール 契約を変えることにより可能
データパイプライン Fluentd,Embulkなど
crud update以外は対応(pres...
クラウド: Paas TreasureData
容量 契約による上限あり
料金 データ量やリソースにより変動
スケール 契約を変えることにより可能
データパイプライン Fluentd,Embulkなど
crud update以外は対応(pres...
まとめ
データ量、取得元データのある場所、データの分析方法な
ど様々な要因によって選ぶ基盤は変わってきます。
1つ選んでも今後ずっとその基盤が最適とは限りません。
データレイク構造にすることでデータは1カ所に集約、エ
ンジンは用途によって変える...
1.自己紹介
2.リクルートライフスタイルの分析基盤
3.分析基盤(DWH)の比較
4.分析基盤の続け方
本日のアジェンダ
#1
ユーザーファーストの基盤を作る
なぜユーザーファーストにするのか
使ってくれる人がいないと分析基盤は継続しないか
ら!
• とにかくユーザが使い易い基盤にする
• 新しい技術使いたいからとかエンジニア善がりの基盤
はNG(IFがAPIのみとか
• ユーザの声を常に聞ける環境を...
リクルートライフスタイルで取り組んでいること
• 問い合わせ用にslackのchannelを開設
• ユーザアンケートを行う
• 基盤を使う立場になる(マーケターに兼務で入るなど
• データを使うチームを近くに置く
• 毎月メルマガ発行をする
...
#2
売上の上がる施策バッチを走らせる
なぜ売上を上げないといけないか
売上を上げないと予算がつかないから!
• 分析基盤はとにかくお金がかかる
• 予算はほぼ毎年純増(データ量に相関する場合が多い
• 売上が上がれば予算がついて、より良い基盤が作れる
• さらに売上が上がるバッチを...
#3
運用コストを下げる
なぜ運用コストを下げたいのか
運用は人を幸せにしないから!
• キャパシティ管理をしなくていいように
• ビックデータ基盤で将来のデータ量予測はほぼ不可能
• 障害が起きた際に単純に再実行できるデータパイプラ
インを作る
• 冪等性を担保する
...
#4
ユーザの教育を行う
なぜユーザ教育を行うのか
双方の幸せのため
• DWHごとに最適なクエリの書き方があるが、ユーザは
特に意識せずに負荷の高いクエリを投げる場合がある
• DWH全体の負荷が上がり、ユーザ全員に影響する
• クエリ課金のエンジン使っていた際は目も...
リクルートライフスタイルで取り組んでいること
• 半期に1度の勉強会
• おもにその半年間の新規参画者向け
• Redshiftについて
• TreasureDataについて
• BigQueryについて
• Tableauについて
• Dat...
#5
データレイク構成にしておく
なぜデータレイク構成にしておくのか
進化を続けられる基盤になれる
• 新しいエンジンがどんどん出てきている
• 用途によって使いたいエンジンは違う
• スケールアウト出来る分析基盤に対応
• サイズ制限からの解放
データレイクにしておくことによ...
一緒にデータ基盤作ってくれる人募集中!!!
http://engineer.recruit-lifestyle.co.jp/recruiting/
ご清聴ありがとうございました
オンプレ、クラウドを組み合わせて作るビックデータ基盤  データ基盤の選び方
Upcoming SlideShare
Loading in …5
×

オンプレ、クラウドを組み合わせて作るビックデータ基盤 データ基盤の選び方

2,977 views

Published on

リクルートライフスタイルではじゃらん、ホットペッパーグルメ、ホットペッパービューティーなど約30のサービスを展開しています。
それらのデータを全社共通で使えるように、オンプレ、クラウドのハイブリッドでビックデータ基盤を構築しています。
メール配信に使われるバッチやアドホック分析、レポーティングなど様々な用途で使われる中、どうバッチに影響を出さない基盤を作るのか、なぜクラウドだけではなく、オンプレなど複数のDBを使っているのか、なぜその基盤を選んだのか、データ基盤の比較とともに紹介します。
山田 雄(株式会社リクルートライフスタイル)

Published in: Technology
  • Be the first to comment

オンプレ、クラウドを組み合わせて作るビックデータ基盤 データ基盤の選び方

  1. 1. オンプレ、クラウドを組み合わ せて作るビックデータ基盤 -データ基盤の選び方- builderscon tokyo 2017 08/04 2017 山田 雄 ネットビジネス本部 データ基盤チーム
  2. 2. 1.自己紹介 2.リクルートライフスタイルの分析基盤 3.分析基盤(DWH)の比較 4.分析基盤の続け方 本日のアジェンダ
  3. 3. 1.自己紹介 2.リクルートライフスタイルの分析基盤 3.分析基盤(DWH)の比較 4.分析基盤の続け方 本日のアジェンダ
  4. 4. ■山田 雄(ヤマダ ユウ) 株式会社 リクルートライフスタイル ネットビジネス本部 データ基盤T Twitter:@nii_yan GitHub:https://github.com/yu-yamada ・以前はメールマーケティング用基盤の作成からデータ分析まで関わる 現在はリクルートライフスタイルの共通分析基盤の開発、運用全般を担当 ビックデータ、Ruby、ビール、カップ焼きそばが好き。 自己紹介
  5. 5. 会社紹介
  6. 6. Engineering for data Business with data 技術でビジネスを ドライブする Stable Infrastructure Continual Innovation+ リクルートライフスタイルにおけるエンジニアの役割
  7. 7. 1.自己紹介 2.リクルートライフスタイルの分析基盤 3.分析基盤(DWH)の比較 4.分析基盤の続け方 本日のアジェンダ
  8. 8. リクルートライフスタイルの持つデータ
  9. 9. リクルートライフスタイルの分析基盤 DWH HPB JLN HPG ・・・ 各事業データ 施策Batch用 Netezza サイトログ保存用 TreasureData Adhoc分析用 Redshift 外部データ TSV CSV 3 行動ログ SDK Adhoc分析用 Redshift AWS S3 S3 S3 GCP 模索中 BigQuery
  10. 10. リクルートライフスタイルの分析基盤 DWH HPB JLN HPG ・・・ 各事業データ 施策Batch用 Netezza サイトログ保存用 TreasureData Adhoc分析用 Redshift 外部データ TSV CSV 3 行動ログ SDK Adhoc分析用 Redshift AWS S3 S3 S3 GCP 模索中 BigQuery 事業データや、サイトの行動ログを日次 DWHに連携し、横断的に分析できる環境を ユーザに提供
  11. 11. リクルートライフスタイルの分析基盤 DWH HPB JLN HPG ・・・ 各事業データ 施策Batch用 Netezza サイトログ保存用 TreasureData Adhoc分析用 Redshift 外部データ TSV CSV 3 行動ログ SDK Adhoc分析用 Redshift AWS S3 S3 S3 GCP 模索中 BigQuery 各事業のデータを日次バッチで連携 連携テーブル数2000以上 1度フラットファイルにしてから S3にuploadして、Redshiftにload
  12. 12. リクルートライフスタイルの分析基盤 DWH HPB JLN HPG ・・・ 各事業データ 施策Batch用 Netezza サイトログ保存用 TreasureData Adhoc分析用 Redshift 外部データ TSV CSV 3 行動ログ SDK Adhoc分析用 Redshift AWS S3 S3 S3 GCP 模索中 BigQuery DB以外のデータも連携し たいという要望があるの で、S3をIFとして連携
  13. 13. リクルートライフスタイルの分析基盤 DWH HPB JLN HPG ・・・ 各事業データ 施策Batch用 Netezza サイトログ保存用 TreasureData Adhoc分析用 Redshift 外部データ TSV CSV 3 行動ログ SDK Adhoc分析用 Redshift AWS S3 S3 S3 GCP 模索中 BigQuery サイトの行動ログは1度 TreasureDataに入れた後、 マートを作成し、マートのみ Redshift,Netezzaへ連携
  14. 14. リクルートライフスタイルの分析基盤 DWH HPB JLN HPG ・・・ 各事業データ 施策Batch用 Netezza サイトログ保存用 TreasureData Adhoc分析用 Redshift 外部データ TSV CSV 3 行動ログ SDK Adhoc分析用 Redshift AWS S3 S3 S3 GCP 模索中 BigQuery IFをS3に統一することに より、S3をデータレイク として使用
  15. 15. リクルートライフスタイルの分析基盤 DWH HPB JLN HPG ・・・ 各事業データ 施策Batch用 Netezza サイトログ保存用 TreasureData Adhoc分析用 Redshift 外部データ TSV CSV 3 行動ログ SDK Adhoc分析用 Redshift AWS S3 S3 S3 GCP 模索中 BigQuery Netezzaは売上に直 結する施策バッチ を走らせる環境 一般ユーザには解 放しないことに よってアドホック クエリの影響を受 けない環境を作っ ている
  16. 16. リクルートライフスタイルの分析基盤 DWH HPB JLN HPG ・・・ 各事業データ 施策Batch用 Netezza サイトログ保存用 TreasureData Adhoc分析用 Redshift 外部データ TSV CSV 3 行動ログ SDK Adhoc分析用 Redshift AWS S3 S3 S3 GCP 模索中 BigQuery Adohoc分析用に開放してい る環境 ds2.8xlarge * 11 日次更新されてデータ鮮度は 高いが、常にloadとupdate が走っているため負荷が高い ・1500tables load/day ・1000tables update/day 負荷が非常に高くて単純な selectにも時間がかか る・・・ Create tableに5分とか そこからのGrantに5分とか
  17. 17. リクルートライフスタイルの分析基盤 DWH HPB JLN HPG ・・・ 各事業データ 施策Batch用 Netezza サイトログ保存用 TreasureData Adhoc分析用 Redshift 外部データ TSV CSV 3 行動ログ SDK Adhoc分析用 Redshift AWS S3 S3 S3 GCP 模索中 BigQuery Adohoc分析用に開放している環境 左のクラスタのsnapshotから週次で作成 データ鮮度は古いがload,updateが走らないため負荷が低く、快適にクエリ が投げられる 使われないデータは削除し、データ量的に最小のクラスタ構成としている 鮮度は古いデータでもいいが、負荷の低い環境を使いたいユーザ向け クエリの実行テストにも使われる
  18. 18. リクルートライフスタイルの分析基盤 DWH HPB JLN HPG ・・・ 各事業データ 施策Batch用 Netezza サイトログ保存用 TreasureData Adhoc分析用 Redshift 外部データ TSV CSV 3 行動ログ SDK Adhoc分析用 Redshift AWS S3 S3 S3 GCP 模索中 BigQuery 鮮度の高いデータを付き合わせたい時の ために、slackでテーブル名を呟くとS3 のデータをloadしてくれるbotを用意 ユーザ主体でload出来ることによって運 用コスト削減
  19. 19. リクルートライフスタイルの分析基盤 DWH HPB JLN HPG ・・・ 各事業データ 施策Batch用 Netezza サイトログ保存用 TreasureData Adhoc分析用 Redshift 外部データ TSV CSV 3 行動ログ SDK Adhoc分析用 Redshift AWS S3 S3 S3 GCP 模索中 BigQuery サイトカタリストの生ログや アプリのSDKログをためてい る 毎月約100億レコード増加 運用は全て任せられるので、 運用コストが低い
  20. 20. リクルートライフスタイルの分析基盤 DWH HPB JLN HPG ・・・ 各事業データ 施策Batch用 Netezza サイトログ保存用 TreasureData Adhoc分析用 Redshift 外部データ TSV CSV 3 行動ログ SDK Adhoc分析用 Redshift AWS S3 S3 S3 GCP 模索中 BigQuery サイトカタリストのログ、 Redshiftに入っているデータ を入れ、TreasureData、 Redshiftを掛け合わせた環境 になれないか模索中 キャパシティ管理をしなくて 良いので運用コストが低い
  21. 21. リクルートライフスタイルの分析基盤 DWH HPB JLN HPG ・・・ 各事業データ 施策Batch用 Netezza サイトログ保存用 TreasureData Adhoc分析用 Redshift 外部データ TSV CSV 3 行動ログ SDK Adhoc分析用 Redshift AWS S3 S3 S3 GCP 模索中 BigQuery 約300人のユーザが、 自分にあった環境を使 い、日々データの分析 を行っている データサイエンティス ト、マーケター、ディ レクター、営業と様々 な職種の人が分析基盤 を使用 Tableauを用意するこ とにより、クエリが書 けない人でも利用が出 来る
  22. 22. リクルートライフスタイルの分析基盤 DWH HPB JLN HPG ・・・ 各事業データ 施策Batch用 Netezza サイトログ保存用 TreasureData Adhoc分析用 Redshift 外部データ TSV CSV 3 行動ログ SDK Adhoc分析用 Redshift AWS S3 S3 S3 GCP 模索中 BigQuery 約300人のユーザが、自分にあった環境を使い、 日々データの分析を行っている データサイエンティスト、マーケター、ディレクター、 営業と様々な職種の人が分析基盤を使用 Tableauを用意することにより、クエリが書けない 人でも利用が出来る 約300人のユーザが、自分にあった環境を使い、 日々データの分析を行っている データサイエンティスト、マーケター、ディレクター、 営業と様々な職種の人が分析基盤を使用 Tableauを用意することにより、クエリが書けない 人でも利用が出来る DWHに集まったデータを使 い、SPSSやRでデータ分析 をし、CMSなどに連携する ことで売り上げを上げる施 策を走らせている メルマガのOnetoOne ユーザ毎の広告の出しわけ ポイント付与など・・・
  23. 23. ETLフレームワーク 独自で実装した ETLのフレームワークを用意し、SQLと YAMLを作るだけでデータの移動を出来るようにしている
  24. 24. フレームワークで出来ること
  25. 25. Meta情報管理
  26. 26. Meta情報管理 事業DBやDWH、Adobe Analyticsのメタデータを日次 で連携し、どのテーブルはどんな定義でどんなデータ が入ってるいるのかを一元的に管理。 また、カラムに対してのコメント機能もあるため、単純 なDDLよりもわかりやすい情報が載っている。
  27. 27. DynamoDB Lambda API Gateway Kafka on-premises Configuration Management Monitoring Grafana リアルタイムデータを扱う基盤
  28. 28. DynamoDB Lambda API Gateway on-premises Configuration Management Monitoring Grafana Kafka データハブ基盤
  29. 29. Lambda API Gateway on-premises Configuration Management Monitoring Grafana Kafka DynamoDB ストリーム処理基盤
  30. 30. Kafka on-premises Configuration Management Monitoring Grafana DynamoDB Lambda API Gateway データ提供部分(API)
  31. 31. 1.自己紹介 2.リクルートライフスタイルの分析基盤 3.分析基盤(DWH)の比較 4.分析基盤の続け方 本日のアジェンダ
  32. 32. DWH(データウェアハウス) 直訳するとデータの倉庫 • 分析に特化した、データを貯める場所。 • 列指向の場合が多い。 • 基本的にデータは追記のみ行う(削除、更新は行わない)。 • レスポンスはそこまで早くない。 ざっくり言うとRDBよりレイテンシは大きいが膨大なデータを持てるシステム のこと。 そもそもDWHって?
  33. 33. 1. 容量 2. 料金 3. スケール出来るか 4. データパイプラインは作りやすいか 5. 分析者の用途に合っているか 1. Crudができるか 2. 分析ツール、モデリングツールが使えるか(SPSSなど) 3. ODBCなどで接続出来るか 4. ANSI準拠か 5. リソース分割出来るか 6. 運用面は楽か 分析基盤の検討軸
  34. 34. クラウド or オンプレ クラウド or オンプレ
  35. 35. オンプレ Hadoop (Hive,Presto,Spark…) Exadata , Netezza, Teradata クラウド AWS Redshift EMR GCP BigQuery Paas TreasureData
  36. 36. オンプレ:Hadoop(Hive,Presto,Spark) 容量 サーバ台数次第、上限はDCなどで決まる 料金 初期費用が高い スケール サーバを増やせば出来るがしんどい データパイプライン OSSが充実 crud パーティション単位でのdelete,updateは可能 周辺分析ツール 充実 接続ツール JDBC,ODBC,その他独自ツール ANSI準拠 実行するクエリーエンジン (Hive, Spark SQL, Presto 等) に準ずる が、基本的には対応しない リソース分割 可能 運用 ハード、ソフト共に体制組む必要あり
  37. 37. オンプレ:Hadoop(Hive) 容量 サーバ台数次第、上限はDCなどで決まる 料金 初期費用が高い スケール サーバを増やせば出来るがしんどい データパイプライン OSSが充実 crud × パーティション単位でのdelete,updateは可能 周辺分析ツール 充実 接続ツール JDBC,ODBC,その他独自ツール ANSI準拠 独自 リソース分割 可能 運用 × ハード、ソフト共に体制組む必要あり Hortonworksやclouderaの有償サポートをつけること でソフト面の運用を下げることは可能。 また、OSSなので、独自に改造したり、Prestoを組み合 わせることや、TezやSparkを使いHiveの高速化も出来 るが運用は辛い。 Hadoopは広く使われている技術なので、ドキュメント の多さでは優れている。 (でも色々自分でいじれるのは楽しい・・・)
  38. 38. オンプレ: Exadata,Netezza,Teradataなど 容量 最初の構成による。上限あり 料金 初期費用が高い スケール ほぼ出来ないと思った方が良い データパイプライン 一部OSSが対応してるものの、有償のもの以外は独自実装が 必要。Ora->Exaなど同じ会社のデータ以降は◎ crud 基本的に対応 周辺分析ツール SPSS(IBM)など、各社特化して対応 接続ツール JDBC,ODBCなどだが独自のためOS対応など必要な場合あり ANSI準拠 独自 リソース分割 可能 運用 ハード、ソフト共に体制組む必要あり
  39. 39. オンプレ: Exadata,Netezza,Teradataなど 容量 最初の構成による。上限あり 料金 初期費用が高い スケール ほぼ出来ないと思った方が良い データパイプライン 一部OSSが対応してるものの、有償のもの以外は独自実装が 必要。Ora->Exaなど同じ会社のデータ以降は◎ crud 基本的に対応 周辺分析ツール SPSS(IBM)など、各社特化して対応 接続ツール JDBC,ODBCなどだが独自のためOS対応など必要な場合あり ANSI準拠 独自 リソース分割 可能 運用 ハード、ソフト共に体制組む必要あり どのような分析用途で使いたいか? データ取得元のDBは何か?などによっては選択肢 に入ってくる場合もあり。 ハード的に早い(FPGA使ってるなど) ただ、数年使うことを見越すと初期のデータ見積もり が非常に重要。 オンプレはEOSLに注意
  40. 40. クラウド: Amazon EMR(Hadoop) 容量 構成次第 上限なし 料金 構成次第 使わない際は落として節約可能 スケール 即時可能 データパイプライン DMS,GlueなどAWSのサービスで対応。その他OSSでも対応あり crud delete,updateは制限あり、ファイルフォーマットや、オプションの 指定による 周辺分析ツール Tableasu,QuickSightなど 接続ツール JDBC,ODBC,その他独自ツール ANSI準拠 実行するクエリーエンジン (Hive, Spark SQL, Presto 等) に準ずる が、基本的には対応しない リソース分割 可能 運用 AWSにお任せ
  41. 41. クラウド: AWS EMR(Hadoop) 容量 構成次第 上限なし? 料金 構成次第 使わない際は落として節約可能 スケール 即時可能 データパイプライン DMS,GlueなどAWSのサービスで対応。その他OSSでも対応あり crud パーティション単位でのdelete,updateは可能 周辺分析ツール 充実 接続ツール JDBC,ODBC,その他独自ツール ANSI準拠 独自 リソース分割 可能 運用 AWSにお任せ オンプレのHadoopと比べて、データをS3にとっておけ るので、エンジン部分のみの停止、バージョンアップ、 移行、複数クラスタでのデータ共有が簡単に出来る のが魅力。 EC2ではHortonworks,clouderaが出しているクラウド 版を選ぶことも可能(EMRは不可)。 24時間動かし続けないとならない場合、オンプレより も高価になる場合もある。
  42. 42. クラウド: Amazon Redshift 容量 構成次第 上限2PB,Spectrum使用で上限なし 料金 構成次第 スモールスタート可能 スケール 構成によってはスケールには時間がかかり、その間はselectの み データパイプライン DMS,GlueなどAWSのサービスで対応。その他OSSでも対応あり crud 基本的に対応 周辺分析ツール Tableau,QuickSight,SPSSなど対応 接続ツール 独自 JDBC ドライバーを提供。 PostgreSQL準拠のためPosgreSQL対応のもので接続可能 ANSI準拠 PostgreSQL8.0.2準拠 リソース分割 可能 (一部cpuなど出来ない部分あり) 運用 AWSにお任せ
  43. 43. クラウド: AWS Redshift 容量 構成次第 上限2PB 料金 構成次第 スモールスタート可能 スケール 構成によってはスケールには時間がかかり、その間はselectの み データパイプライン DMS,GlueなどAWSのサービスで対応。その他OSSでも対応あり crud 基本的に対応 周辺分析ツール Tableau,SPSSなど対応 接続ツール PostgreSQL準拠のためPosgreSQL対応のもので接続可能 独自 JDBCも用意 ANSI準拠 PostgreSQL8.0.2準拠 リソース分割 可能 (一部cpuなど出来ない部分あり) 運用 AWSにお任せ RDBのように使えるのは魅力。ただ、indexやPKがな いなど使い方に注意が必要。 毎週パッチあてのための再起動が発生する可能性 があり、SLAは定義されていない。 クエリの同時実行数(commit数)が増えてくると顕著 にパフォーマンスが下がる場合がある。
  44. 44. クラウド: GCP BigQuery 容量 上限なし 料金 クエリ課金 スケール 裏側で勝手にしてくれる データパイプライン DataflowなどGCPのサービスで対応。その他OSSでも対応あり crud 基本的に対応(回数制限あり) 周辺分析ツール Tableau,DataStudioなど対応 接続ツール APIを使用してアクセスが主 ODBCはβ ANSI準拠 SQL:2011に準拠したものとBQ独自のクエリが使用可能 リソース分割 slot数の制限をかけることは可能 運用 GCPにお任せ
  45. 45. クラウド: GCP BigQuery 容量 上限なし 料金 クエリ課金 スケール 裏側で勝手にしてくれる データパイプライン DataflowなどGCPのサービスで対応。その他OSSでも対応あり crud 基本的に対応(回数制限あり) 周辺分析ツール Tableau,DataStudioなど対応 接続ツール APIを使用してアクセスが主 ODBCはβ ANSI準拠 SQL:2011に準拠したものとBQ独自のクエリが使用可能 リソース分割 slot数の制限をかけることは可能 運用 GCPにお任せ 容量を気にしなくて良いのでキャパシティー管理をし なくて良いのが特徴。 ただ、クエリ課金で予算がわかりにくため、クエリ放 題のようなプランが用意されている。 しかしそれを使うとslot数、データ量の縛りが出てしま いキャパシティー管理復活。ToT crudは出来るが回数制限があるので、注意が必要。 (1テーブルあたり1日更新1000回までなど)
  46. 46. クラウド: Paas TreasureData 容量 契約による上限あり 料金 データ量やリソースにより変動 スケール 契約を変えることにより可能 データパイプライン Fluentd,Embulkなど crud update以外は対応(presto) 周辺分析ツール Tableau,salesforce など対応 接続ツール JDBCやAPI ANSI準拠 ANSI準拠 + 独自UDF(presto) リソース分割 可能(presto) 対応予定(HIVE) 運用 Treasureにお任せ
  47. 47. クラウド: Paas TreasureData 容量 契約による上限あり 料金 データ量やリソースにより変動 スケール 契約を変えることにより可能 データパイプライン Fluentd,Embulkなど crud update以外は対応(presto) 周辺分析ツール Tableau,salesforce など対応 接続ツール JDBCやAPI ANSI準拠 ANSI準拠(presto) リソース分割 可能(presto) 対応予定(HIVE) 運用 Treasureにお任せ クエリエンジンにHiveとPrestoを選択可能。 Jobスケジューラがある。 Prestoの同時実行数は低めなので、接続人数が多い 場合は注意が必要。 独自sdkやJSと組み合わせてリアルタイムデータの取 得が可能。
  48. 48. まとめ データ量、取得元データのある場所、データの分析方法な ど様々な要因によって選ぶ基盤は変わってきます。 1つ選んでも今後ずっとその基盤が最適とは限りません。 データレイク構造にすることでデータは1カ所に集約、エ ンジンは用途によって変えるということができると柔軟性 のある基盤になるかと思います。
  49. 49. 1.自己紹介 2.リクルートライフスタイルの分析基盤 3.分析基盤(DWH)の比較 4.分析基盤の続け方 本日のアジェンダ
  50. 50. #1 ユーザーファーストの基盤を作る
  51. 51. なぜユーザーファーストにするのか 使ってくれる人がいないと分析基盤は継続しないか ら! • とにかくユーザが使い易い基盤にする • 新しい技術使いたいからとかエンジニア善がりの基盤 はNG(IFがAPIのみとか • ユーザの声を常に聞ける環境を整える
  52. 52. リクルートライフスタイルで取り組んでいること • 問い合わせ用にslackのchannelを開設 • ユーザアンケートを行う • 基盤を使う立場になる(マーケターに兼務で入るなど • データを使うチームを近くに置く • 毎月メルマガ発行をする • 社内散歩をする などなどを行いユーザと仲良くする!
  53. 53. #2 売上の上がる施策バッチを走らせる
  54. 54. なぜ売上を上げないといけないか 売上を上げないと予算がつかないから! • 分析基盤はとにかくお金がかかる • 予算はほぼ毎年純増(データ量に相関する場合が多い • 売上が上がれば予算がついて、より良い基盤が作れる • さらに売上が上がるバッチを走らせられる • ROIは計算しなくて良い • インフラってそんなもんだと思います • この基盤があるおかげでこんだけ売上の上がるバッチが走っ てるんだよ〜ぐらいで • KPIは持ちましょう
  55. 55. #3 運用コストを下げる
  56. 56. なぜ運用コストを下げたいのか 運用は人を幸せにしないから! • キャパシティ管理をしなくていいように • ビックデータ基盤で将来のデータ量予測はほぼ不可能 • 障害が起きた際に単純に再実行できるデータパイプラ インを作る • 冪等性を担保する • クラウドに任せるところは任せる • 魔改造しない • SLAを緩くする
  57. 57. #4 ユーザの教育を行う
  58. 58. なぜユーザ教育を行うのか 双方の幸せのため • DWHごとに最適なクエリの書き方があるが、ユーザは 特に意識せずに負荷の高いクエリを投げる場合がある • DWH全体の負荷が上がり、ユーザ全員に影響する • クエリ課金のエンジン使っていた際は目も当てられない • RedshiftなどRDBの用に使えるが、決して使ってはいけ ない • Index無い • 正規化しない方がいい • カラムナ?なにそれおいしいの? • パーティション?机の前にあるやつ? • order byとかcount(distinct)とかコストの高いクエリ多様
  59. 59. リクルートライフスタイルで取り組んでいること • 半期に1度の勉強会 • おもにその半年間の新規参画者向け • Redshiftについて • TreasureDataについて • BigQueryについて • Tableauについて • DataRobotについて・・・など数回に分けて実施
  60. 60. #5 データレイク構成にしておく
  61. 61. なぜデータレイク構成にしておくのか 進化を続けられる基盤になれる • 新しいエンジンがどんどん出てきている • 用途によって使いたいエンジンは違う • スケールアウト出来る分析基盤に対応 • サイズ制限からの解放 データレイクにしておくことによって、新しいエンジンや新 しいニーズが出てきた際も柔軟に対応出来る、進化を続 ける基盤となれる
  62. 62. 一緒にデータ基盤作ってくれる人募集中!!! http://engineer.recruit-lifestyle.co.jp/recruiting/
  63. 63. ご清聴ありがとうございました

×