オンプレ、クラウドを組み合わせて作るビックデータ基盤 データ基盤の選び方
•Download as PPTX, PDF•
5 likes•5,192 views
リクルートライフスタイルではじゃらん、ホットペッパーグルメ、ホットペッパービューティーなど約３０のサービスを展開しています。 それらのデータを全社共通で使えるように、オンプレ、クラウドのハイブリッドでビックデータ基盤を構築しています。 メール配信に使われるバッチやアドホック分析、レポーティングなど様々な用途で使われる中、どうバッチに影響を出さない基盤を作るのか、なぜクラウドだけではなく、オンプレなど複数のDBを使っているのか、なぜその基盤を選んだのか、データ基盤の比較とともに紹介します。 山田 雄（株式会社リクルートライフスタイル）
Recommended
More Related Content
What's hot
What's hot (20)
Similar to オンプレ、クラウドを組み合わせて作るビックデータ基盤 データ基盤の選び方
Similar to オンプレ、クラウドを組み合わせて作るビックデータ基盤 データ基盤の選び方 (20)
More from Yu Yamada
Recently uploaded
Recently uploaded (9)
オンプレ、クラウドを組み合わせて作るビックデータ基盤 データ基盤の選び方
- 1. オンプレ、クラウドを組み合わ せて作るビックデータ基盤 -データ基盤の選び方- builderscon tokyo 2017 08/04 2017 山田 雄 ネットビジネス本部 データ基盤チーム
- 4. ■山田 雄（ヤマダ ユウ） 株式会社 リクルートライフスタイル ネットビジネス本部 データ基盤T Twitter:@nii_yan GitHub:https://github.com/yu-yamada ・以前はメールマーケティング用基盤の作成からデータ分析まで関わる 現在はリクルートライフスタイルの共通分析基盤の開発、運用全般を担当 ビックデータ、Ruby、ビール、カップ焼きそばが好き。 自己紹介
- 6. 会社紹介
- 7. Engineering for data Business with data 技術でビジネスを ドライブする Stable Infrastructure Continual Innovation+ リクルートライフスタイルにおけるエンジニアの役割
- 17. リクルートライフスタイルの分析基盤 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に５分とか そこからのGrantに５分とか
- 25. フレームワークで出来ること
- 26. Meta情報管理
- 29. DynamoDB Lambda API Gateway on-premises Configuration Management Monitoring Grafana Kafka データハブ基盤
- 30. Lambda API Gateway on-premises Configuration Management Monitoring Grafana Kafka DynamoDB ストリーム処理基盤
- 33. DWH(データウェアハウス） 直訳するとデータの倉庫 • 分析に特化した、データを貯める場所。 • 列指向の場合が多い。 • 基本的にデータは追記のみ行う（削除、更新は行わない）。 • レスポンスはそこまで早くない。 ざっくり言うとRDBよりレイテンシは大きいが膨大なデータを持てるシステム のこと。 そもそもDWHって？
- 34. 1. 容量 2. 料金 3. スケール出来るか 4. データパイプラインは作りやすいか 5. 分析者の用途に合っているか 1. Crudができるか 2. 分析ツール、モデリングツールが使えるか(SPSSなど) 3. ODBCなどで接続出来るか 4. ANSI準拠か 5. リソース分割出来るか 6. 運用面は楽か 分析基盤の検討軸
- 36. オンプレ Hadoop (Hive,Presto,Spark…) Exadata , Netezza, Teradata クラウド AWS Redshift EMR GCP BigQuery Paas TreasureData
- 37. オンプレ：Hadoop(Hive,Presto,Spark) 容量 サーバ台数次第、上限はDCなどで決まる 料金 初期費用が高い スケール サーバを増やせば出来るがしんどい データパイプライン OSSが充実 crud パーティション単位でのdelete,updateは可能 周辺分析ツール 充実 接続ツール JDBC,ODBC,その他独自ツール ANSI準拠 実行するクエリーエンジン (Hive, Spark SQL, Presto 等) に準ずる が、基本的には対応しない リソース分割 可能 運用 ハード、ソフト共に体制組む必要あり
- 38. オンプレ：Hadoop(Hive) 容量 サーバ台数次第、上限はDCなどで決まる 料金 初期費用が高い スケール サーバを増やせば出来るがしんどい データパイプライン OSSが充実 crud × パーティション単位でのdelete,updateは可能 周辺分析ツール 充実 接続ツール JDBC,ODBC,その他独自ツール ANSI準拠 独自 リソース分割 可能 運用 × ハード、ソフト共に体制組む必要あり Hortonworksやclouderaの有償サポートをつけること でソフト面の運用を下げることは可能。 また、OSSなので、独自に改造したり、Prestoを組み合 わせることや、TezやSparkを使いHiveの高速化も出来 るが運用は辛い。 Hadoopは広く使われている技術なので、ドキュメント の多さでは優れている。 (でも色々自分でいじれるのは楽しい・・・)
- 39. オンプレ： Exadata,Netezza,Teradataなど 容量 最初の構成による。上限あり 料金 初期費用が高い スケール ほぼ出来ないと思った方が良い データパイプライン 一部OSSが対応してるものの、有償のもの以外は独自実装が 必要。Ora->Exaなど同じ会社のデータ以降は◎ crud 基本的に対応 周辺分析ツール SPSS(IBM)など、各社特化して対応 接続ツール JDBC,ODBCなどだが独自のためOS対応など必要な場合あり ANSI準拠 独自 リソース分割 可能 運用 ハード、ソフト共に体制組む必要あり
- 40. オンプレ： Exadata,Netezza,Teradataなど 容量 最初の構成による。上限あり 料金 初期費用が高い スケール ほぼ出来ないと思った方が良い データパイプライン 一部OSSが対応してるものの、有償のもの以外は独自実装が 必要。Ora->Exaなど同じ会社のデータ以降は◎ crud 基本的に対応 周辺分析ツール SPSS(IBM)など、各社特化して対応 接続ツール JDBC,ODBCなどだが独自のためOS対応など必要な場合あり ANSI準拠 独自 リソース分割 可能 運用 ハード、ソフト共に体制組む必要あり どのような分析用途で使いたいか？ データ取得元のDBは何か？などによっては選択肢 に入ってくる場合もあり。 ハード的に早い(FPGA使ってるなど) ただ、数年使うことを見越すと初期のデータ見積もり が非常に重要。 オンプレはEOSLに注意
- 41. クラウド： Amazon EMR(Hadoop) 容量 構成次第 上限なし 料金 構成次第 使わない際は落として節約可能 スケール 即時可能 データパイプライン DMS,GlueなどAWSのサービスで対応。その他OSSでも対応あり crud delete,updateは制限あり、ファイルフォーマットや、オプションの 指定による 周辺分析ツール Tableasu,QuickSightなど 接続ツール JDBC,ODBC,その他独自ツール ANSI準拠 実行するクエリーエンジン (Hive, Spark SQL, Presto 等) に準ずる が、基本的には対応しない リソース分割 可能 運用 AWSにお任せ
- 42. クラウド： AWS EMR(Hadoop) 容量 構成次第 上限なし？ 料金 構成次第 使わない際は落として節約可能 スケール 即時可能 データパイプライン DMS,GlueなどAWSのサービスで対応。その他OSSでも対応あり crud パーティション単位でのdelete,updateは可能 周辺分析ツール 充実 接続ツール JDBC,ODBC,その他独自ツール ANSI準拠 独自 リソース分割 可能 運用 AWSにお任せ オンプレのHadoopと比べて、データをS3にとっておけ るので、エンジン部分のみの停止、バージョンアップ、 移行、複数クラスタでのデータ共有が簡単に出来る のが魅力。 EC2ではHortonworks,clouderaが出しているクラウド 版を選ぶことも可能(EMRは不可)。 24時間動かし続けないとならない場合、オンプレより も高価になる場合もある。
- 43. クラウド： Amazon Redshift 容量 構成次第 上限2PB,Spectrum使用で上限なし 料金 構成次第 スモールスタート可能 スケール 構成によってはスケールには時間がかかり、その間はselectの み データパイプライン DMS,GlueなどAWSのサービスで対応。その他OSSでも対応あり crud 基本的に対応 周辺分析ツール Tableau,QuickSight,SPSSなど対応 接続ツール 独自 JDBC ドライバーを提供。 PostgreSQL準拠のためPosgreSQL対応のもので接続可能 ANSI準拠 PostgreSQL8.0.2準拠 リソース分割 可能 （一部cpuなど出来ない部分あり) 運用 AWSにお任せ
- 44. クラウド： 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数)が増えてくると顕著 にパフォーマンスが下がる場合がある。
- 45. クラウド： GCP BigQuery 容量 上限なし 料金 クエリ課金 スケール 裏側で勝手にしてくれる データパイプライン DataflowなどGCPのサービスで対応。その他OSSでも対応あり crud 基本的に対応(回数制限あり） 周辺分析ツール Tableau,DataStudioなど対応 接続ツール APIを使用してアクセスが主 ODBCはβ ANSI準拠 SQL:2011に準拠したものとBQ独自のクエリが使用可能 リソース分割 slot数の制限をかけることは可能 運用 GCPにお任せ
- 46. クラウド： GCP BigQuery 容量 上限なし 料金 クエリ課金 スケール 裏側で勝手にしてくれる データパイプライン DataflowなどGCPのサービスで対応。その他OSSでも対応あり crud 基本的に対応(回数制限あり） 周辺分析ツール Tableau,DataStudioなど対応 接続ツール APIを使用してアクセスが主 ODBCはβ ANSI準拠 SQL:2011に準拠したものとBQ独自のクエリが使用可能 リソース分割 slot数の制限をかけることは可能 運用 GCPにお任せ 容量を気にしなくて良いのでキャパシティー管理をし なくて良いのが特徴。 ただ、クエリ課金で予算がわかりにくため、クエリ放 題のようなプランが用意されている。 しかしそれを使うとslot数、データ量の縛りが出てしま いキャパシティー管理復活。ToT crudは出来るが回数制限があるので、注意が必要。 (1テーブルあたり1日更新1000回までなど)
- 47. クラウド： Paas TreasureData 容量 契約による上限あり 料金 データ量やリソースにより変動 スケール 契約を変えることにより可能 データパイプライン Fluentd,Embulkなど crud update以外は対応(presto) 周辺分析ツール Tableau,salesforce など対応 接続ツール JDBCやAPI ANSI準拠 ANSI準拠 + 独自UDF(presto) リソース分割 可能(presto) 対応予定(HIVE) 運用 Treasureにお任せ
- 48. クラウド： Paas TreasureData 容量 契約による上限あり 料金 データ量やリソースにより変動 スケール 契約を変えることにより可能 データパイプライン Fluentd,Embulkなど crud update以外は対応(presto) 周辺分析ツール Tableau,salesforce など対応 接続ツール JDBCやAPI ANSI準拠 ANSI準拠(presto) リソース分割 可能(presto) 対応予定(HIVE) 運用 Treasureにお任せ クエリエンジンにHiveとPrestoを選択可能。 Jobスケジューラがある。 Prestoの同時実行数は低めなので、接続人数が多い 場合は注意が必要。 独自sdkやJSと組み合わせてリアルタイムデータの取 得が可能。
- 52. なぜユーザーファーストにするのか 使ってくれる人がいないと分析基盤は継続しないか ら！ • とにかくユーザが使い易い基盤にする • 新しい技術使いたいからとかエンジニア善がりの基盤 はNG(IFがAPIのみとか • ユーザの声を常に聞ける環境を整える
- 53. リクルートライフスタイルで取り組んでいること • 問い合わせ用にslackのchannelを開設 • ユーザアンケートを行う • 基盤を使う立場になる(マーケターに兼務で入るなど • データを使うチームを近くに置く • 毎月メルマガ発行をする • 社内散歩をする などなどを行いユーザと仲良くする！
- 55. なぜ売上を上げないといけないか 売上を上げないと予算がつかないから！ • 分析基盤はとにかくお金がかかる • 予算はほぼ毎年純増(データ量に相関する場合が多い • 売上が上がれば予算がついて、より良い基盤が作れる • さらに売上が上がるバッチを走らせられる • ROIは計算しなくて良い • インフラってそんなもんだと思います • この基盤があるおかげでこんだけ売上の上がるバッチが走っ てるんだよ〜ぐらいで • KPIは持ちましょう
- 56. #3 運用コストを下げる
- 57. なぜ運用コストを下げたいのか 運用は人を幸せにしないから！ • キャパシティ管理をしなくていいように • ビックデータ基盤で将来のデータ量予測はほぼ不可能 • 障害が起きた際に単純に再実行できるデータパイプラ インを作る • 冪等性を担保する • クラウドに任せるところは任せる • 魔改造しない • SLAを緩くする
- 58. #4 ユーザの教育を行う
- 59. なぜユーザ教育を行うのか 双方の幸せのため • DWHごとに最適なクエリの書き方があるが、ユーザは 特に意識せずに負荷の高いクエリを投げる場合がある • DWH全体の負荷が上がり、ユーザ全員に影響する • クエリ課金のエンジン使っていた際は目も当てられない • RedshiftなどRDBの用に使えるが、決して使ってはいけ ない • Index無い • 正規化しない方がいい • カラムナ？なにそれおいしいの？ • パーティション？机の前にあるやつ？ • order byとかcount(distinct)とかコストの高いクエリ多様
- 60. リクルートライフスタイルで取り組んでいること • 半期に１度の勉強会 • おもにその半年間の新規参画者向け • Redshiftについて • TreasureDataについて • BigQueryについて • Tableauについて • DataRobotについて・・・など数回に分けて実施
- 61. #5 データレイク構成にしておく
- 62. なぜデータレイク構成にしておくのか 進化を続けられる基盤になれる • 新しいエンジンがどんどん出てきている • 用途によって使いたいエンジンは違う • スケールアウト出来る分析基盤に対応 • サイズ制限からの解放 データレイクにしておくことによって、新しいエンジンや新 しいニーズが出てきた際も柔軟に対応出来る、進化を続 ける基盤となれる
- 64. ご清聴ありがとうございました
Editor's Notes
- 弊社の特徴として、エンジニアがビジネスのとても近くにいるというのがあります。 図のようにエンジニアの役割は技術によってビジネスをドライブさせることになります。 エンジニアからビジネス側へ提案することが多くある。 あとは、毎年エンジニアがビジネスプランを発表するコンテストもありますし、技術とビジネス両方学べる良い環境だと思います。 リクルートライフスタイルとエンジニアが結びつかない人も多数いるとは思いますが、技術でビジネスをドライブしてる実績が認められ最近はエンジニアを増やすことに注力しています。
- うちで言うユーザとはデータサイエンティストなどの分析者やマーケター、ディレクター営業など
- ETLフレームワークを独自実装
- 様々な部署からの要望に応えられるよう構築
- まず、データハブ基盤です。 オンプレミス環境にあるデータはFluentdを介してAWSクラウド上に送られます。 Fluentdから送られたデータはKafkaに保存され、ここがデータハブとして機能しています。 Kafka 0.8 SSL対応してないため、publisherとaggrigator用意 今後は0.9を使ってsslで通信
- 次にKafkaに保存されたデータを、Spark Streamingが取り出し、データを加工・集計します。 ここがストリーム処理基盤として機能しています。
- Spark-Streamingが加工・集計したデータは、DynamoDBに保存され、Key-Valueの形で保存されます。 エンドユーザーとなるデータ利用者は、APIゲートウェイ・Lambdaを介して取得することで リクエストに対するキャパシティを担保した状態でデータを提供することが可能となります。
- どこまでがRDBでどこからDWHなの？という明確な線引きはないため、今回はデータ基盤の比較として出てきそうなものをピックアップして比較してみます
- ここら辺の検討軸を主眼に置きつつ幾つかの基盤を見ていきましょう ちなみにビックデータ人材の採用ページ見ると日本だとHadoopという単語が多く見られ、海外だとAWSやGCPなどの単語が多く見られます。
- FPGAとかで早い
- 障害の話など
- ユーザが使い易い基盤を作らないと、あそこ使いにくいから独自で作ろうという子になり、同じような基盤が社内でいっぱいできたりする