More Related Content
Similar to オンプレ、クラウドを組み合わせて作るビックデータ基盤 データ基盤の選び方 (20)
オンプレ、クラウドを組み合わせて作るビックデータ基盤 データ基盤の選び方
- 4. ■山田 雄(ヤマダ ユウ)
株式会社 リクルートライフスタイル
ネットビジネス本部
データ基盤T
Twitter:@nii_yan
GitHub:https://github.com/yu-yamada
・以前はメールマーケティング用基盤の作成からデータ分析まで関わる
現在はリクルートライフスタイルの共通分析基盤の開発、運用全般を担当
ビックデータ、Ruby、ビール、カップ焼きそばが好き。
自己紹介
- 34. 1. 容量
2. 料金
3. スケール出来るか
4. データパイプラインは作りやすいか
5. 分析者の用途に合っているか
1. Crudができるか
2. 分析ツール、モデリングツールが使えるか(SPSSなど)
3. ODBCなどで接続出来るか
4. ANSI準拠か
5. リソース分割出来るか
6. 運用面は楽か
分析基盤の検討軸
- 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と組み合わせてリアルタイムデータの取
得が可能。
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とかで早い
- 障害の話など
- ユーザが使い易い基盤を作らないと、あそこ使いにくいから独自で作ろうという子になり、同じような基盤が社内でいっぱいできたりする