More Related Content What's hot Hadoop最新情報 - YARN, Omni, Drill, Impala, Shark, Vertica - MapR CTO Meetup 2014... Hadoop最新情報 - YARN, Omni, Drill, Impala, Shark, Vertica - MapR CTO Meetup 2014... MapR Technologies Japan
Similar to Amazon Elastic MapReduce@Hadoop Conference Japan 2011 Fall Similar to Amazon Elastic MapReduce@Hadoop Conference Japan 2011 Fall (20) More from Shinpei Ohtani (16) Amazon Elastic MapReduce@Hadoop Conference Japan 2011 Fall4. アマゾンの3つのビジネス
一般消費者様 Eコマース
向けサービス (Amazon.co.jp)
マーケットプレイス
セラー様向け 物流サービス提供
サービス (Amazon Services)
開発者様& クラウド
コンピューティング
IT プロ様向け (Amazon Web Services)
サービス
5. Amazon Web Services(AWS)とは
ミッションステートメント
あらゆるビジネスが必要とするスケーラブル
で、高度なアプリケーションを作るための
プラットフォームの提供
• 現在クラウドコンピューティングと呼ばれる
10年以上にわたるAmazonのプラットフォーム構築・
運用のノウハウを結集させ、汎用的にサービスとしてご
提供
6. The “Living” AWS Cloud
Tools to access
services
Cross Service
features
High-level
building blocks
Low-level
building blocks
7. 何故Big dataがそんなに大変なのか?
以下の組み合わせによる困難さ:
• 桁違いのデータ量を扱わなくてはいけない
• 複数のデータソースと複数のフォーマット
• 様々なデータ構造
• 即時性が求められる
現状のシステムではスケールしない (意図されていない)
• インフラの調達だけで非常に時間がかかる
• 特殊なデータベースの専門家が必要
• 非常に高価で伸縮性のないソリューション
Big Dataを扱うためのソリューションが必要
8. あるインターネット小売でのデータウェア
ハウスの要求
今までの要求 – うまく定義されたスキーマ
売り上げレコード、顧客レコード、商品レコード
新しい要求 – 半構造データ/スキーマなし、継続的に進化
クリックストリームログ、エラーログ、検索ログ – 顧客動向を探る手
がかり
レビュー結果、like/don’t like、レーティング、フィード – 顧客の心
象を探る手がかり
ソーシャルコミュニケーション – ソーシャルな中への広がり
既存データに加えて、新しいデータは半構造で
とめどなく膨張しており、かつ有効なデータ
10. Hadoopとは?
Big Dataを扱うためには下記の2つが必要:
– スケーラブルな分散ストレージ
– 低価格で柔軟に行うことが出来る分析
Apache Hadoop とは上記を満たすオープンソース
のフレームワーク
– HDFSは耐障害性のある分散ファイルシステムでコモディ
ティサーバ用に特化
– MapReduceプログラムによって、巨大なデータに対して
の網羅的な分析を実施
顧客が受けるメリット
– 誰でも入手可能 – Cost / TB is a fraction of traditional options
– スケーラブル – PBオーダまではリニアにスケール可能で既に実績多数。
– 柔軟性 – データはスキーマのある/なしで両方保存可能
12. Amazon Elastic MapReduceとは
大規模データ処理基盤をあらゆる開発者に!
Hadoopクラスタをオンデマンドで好きなだけ実行可能
• 数ノードから数千ノードまで
• AWSのスケーラブルなインフラストラクチャの上で実行
分析・解析アプリケーションに集中できる
オンプレミスから修正なしにMapReduceアプリケーションを持込可能
複数のバージョンから選択可能で、AWSがパッチ適用とテストを行い、ク
ラウドに最適化したHadoopが利用可能
S3による入力・出力データを保護
インプットデータ及びアウトプットデータは非常に高い堅牢性を誇る
S3に保存するのでデータを欠損する事がない
13. Amazon Elastic MapReduceとは(2)
Big Data処理のための煩雑な事を肩代わり
Hadoopクラスタの適切なサイズ見積もりも、サーバ調達も難しい
Hadoopのチューニングは更に難しい
ネットワークを最適化するのは更に難しい
Hadoopクラスタのデバッグも難しい
AWSサービスとのインテグレーション
パフォーマンスの最適化
クラウド環境下でのネットワークプロビジョニングと最適化
クラスタサイズの動的な拡張と伸縮
14. EMRがサポートするHadoopスタック
• Hadoop 0.18 • Hadoop 0.20
• Pig 0.3 • Pig 0.6
• Hive 0.4 • Hive 0.5/0.7
• Cascading 1.1 • Cascading 1.1
16. EMRを支えるAWSプラットフォーム
Amazon EC2
スケーラブルなコンピュートプラットフォーム
柔軟でスケールアップ、スケールアウト可能
EMRのMasterノード、Coreノード、タスクノードを展開
Amazon S3
スケーラブルなWebストレージサービス
99.999999999%の堅牢性、非常に安価
EMRのデータ及びアプリケーションのアップロード先
SimpleDB
Amazonの管理不要で可用性を重視したNoSQLサービス
カラム指向で簡易クエリも付属
EMRのジョブ状態情報を維持
17. EMRを中心としたアーキテクチャ
Amazon S3
巨大なデータセットや、
Amazon S3
膨大なログをアップロード
データ Input
ソース Data
Output
Data
Task
Amazon Elastic Node
MapReduce Amazon SimpleDB
MapReduce
Code/ コード Master Task
Service Metadata
Scripts HiveQL Node Node
Pig Latin
Cascading 複数のジョブフローの
ステップを実行 Core HiveQL
Node Pig Latin
アドホック
クエリ
Core
Node
HDFS
BI Apps
JDBC
Amazon Elastic MapReduce ODBC
Hadoop Cluster
19. EMR機能: 稼働中ジョブフローの拡張
利用シナリオ: ジョブフローの高速化
要件変更によるジョブフローの実行速度の向上
ジョブの再起動なしに、ジョブにかけるコストとパフォーマンス対比を
変更できる
Job Flow
Job Flow
Job Flow
4ノード 9ノードへ 25ノードへ
起動 拡張 更に拡張
残り時間
残り時間
14 Hours
7 Hours
残り時間
3 Hours
20. EMR機能: 稼働中ジョブフローの拡張/伸縮
利用シナリオ: 柔軟なデータウェアハウスクラスター
クラスタサイズをリソースの必要性に応じて変更
(例:日中のクエリ実施 vs 夜間バッチ処理)
コスト削減とクラスタ利用シーンに応じた柔軟性の確保を両立
データウェアハウス
(バッチ処理中)
データウェアハウス データウェアハウス
(通常時) (通常時)
9ノード 25ノードへ 9ノードへ
起動 拡張 戻す
21. EMR + Spotインスタンスの活用
EMRを活用し始めると、更にアドホックなクエリをどんどん
実行したくなる
しかし、コスト的に抑えておきたい
EMRとSpotインスタンスのインテグレーション
Spotインスタンスって???
22. 課金モデルのイノベーション
オンデマンド リザーブドイ スポットイン 占有インスタ
インスタンス ンスタンス スタンス ンス
• 従量課金制 • 初期費用 + • 指定した価 • マルチテナ
従量課金 格で従量課 ントを単一
• 1年コミット 金 顧客が占有
• 時間あたり で$56、時間 • 時間当たり • $10/リー
$0.03開始 当たり $0.01 $0.005という ジョン、 時
から開始 場合も 間あたり
$0.105
規制や、コン
スパイク対応 本番利用 アドホックな
プライアンス
評価検証 定常的な利用 用途
対策
AWS EC2インフラストラクチャ
25. EMR機能: Spotインスタンスの活用
スポットインスタンス=利用者が指値を入れるインスタンス
利用シナリオ: ジョブフローのランニングコストを抑えたい
オンデマンドのm2.xlarge 4ノードで開始
処理の高速化のためスポットインスタンスで5ノード追加
Job Flow
スポットなしのコスト
Job Flow 4 instances *14 hrs * $0.50 = $28
Spot
4ノードで
5ノード
スポットありのコスト
起動 4 instances *7 hrs * $0.50 = $13 +
追加
5 instances * 7 hrs * $0.25 = $8.75
Total = $21.75
残り時間
残り時間
14時間
7時間 時間の削減効果: 50%
コスト削減効果: ~22%
26. その他の機能
クラスタインスタンスタイプのサポート
US東海岸のみ
通常のインスタンスと比較して速度が大幅に向上するケースも
AWS固有設定を施したワークフロー
メモリインテンシブ設定など
ブートストラップアクション
起動時にユーザがHadoop及び周辺をカスタマイズできる
Hive 0.7
HAVING句、IN句の導入
ローカルモードクエリのパフォーマンス向上、カラム圧縮効率の向上、
動的パーティショニング
S3 マルチパートアップロードによるアップロード時間の短縮
29. クリックストリーム分析 – Razorfish
Razorfishが巨大小売店向けに開発
一日35億レコード, 7100万ユニーククッキー, 170万広告
ユーザは最近
ホームシア
ターシステム ターゲット広告
を購入し、ビ
デオゲームを (一日170万)
見ている
• EMRとS3を利用
– オンデマンドで100ノードクラスタを実行
– 処理時間が2日間から8時間へ減尐
30. Razorfishの事例 –その効果-
顧客のEMR導入前
SANストレージ/30サーバ/ハイエンドのSQLサーバ3台
初期費用:40,000,000円
運営費も甚大なコスト
調達にかかった時間:2か月
処理にかかる時間:48時間
EMR導入後の費用対効果
EMR/S3/オープンソースのCascadingを利用
初期費用:0円
運営費:約100万円(コスト↓)
調達にかかった時間:0(ただし評価検証に6週間)
処理にかかる時間:8時間
ROAS(広告費用対効果)を500%改善
31. Razorfishの事例 –アーキテクチャ-
Aggregate Log File Export
APIs Ad Serving
data
Files
Internet
Client Data Sources
Provided
Data
Presentation Layer
Direct Analytics
Processing via
Web Application Layer
Talend Data Flow Manager EMR
Cache Edge
OLAP Provisioning
DB
ODBC
Cloud Storage S3 Elastic MapReduce
HBase/SDB
32. Sonetの事例
広告配信ログの分析
1日平均10GB、年間3.65TB
1年分5TBデータをS3にアップロードしてからEMRを利用
オンプレミスでの試算:初期費用だけで数千万円単位
EMR+S3での実際:毎月50万円(年間600万円)
• 20分の1以下の支出で実現
スポットインスタンスを活用して、アドホック分析
• コストを50%削減
36. Q.オンプレミスHadoopの方が早い
物理ハードウェア vs 仮想化
確かに物理ハードウェアの方が早い場合が多い
大事な点はEMRのもたらす柔軟性・拡張性
EMR=スケーラブルなインフラ(EC2/S3)+スケーラブルなフ
レームワーク(Hadoop)
特にHadoop固有の性質としてスケールアウトが非常に有効
37. Q.オンプレミスHadoopの方が安い
物理ハードウェアは最近本当に安い
Hadoopであれば高価なハードウェアは要らない
HDFSによるレプリケーション
調達の時間的コストは別
ハードウェア調達して、インストール・設定するコストは無駄
膨大に増え続けるデータ量に比例してハードウェアを買い続
けるのも非効率
ハードウェアを購入すると、分析・解析が制限されてしまう
HDFSの堅牢性(HDFSだけで本当に大丈夫か)
バックアップの取得、またはマスタからロードしたくなる
• そこまで含めてコスト・運用効率があるか
EMRであれば、S3の堅牢性で全て解決
38. S3のスケール
Peak Requests: 449 Billion
290,000+
per second
262 Billion
102 Billion
40 Billion
2.9 Billion 14 Billion
Q4 2006 Q4 2007 Q4 2008 Q4 2009 Q4 2010 Q2 2011
Total Number of Objects Stored in Amazon S3
42. Beyond Hadoop
Hadoopだけが問題なのではない
HadoopへのIN/OUT含めて、システム全体が
• スケーラブルであること
• フレキシビリティの確保
• コスト/機能が選択可能で、基本的に低コスト
Hadoopは非常に重要なコンポーネント
ただし近視眼的になってはいけない
• データをロストしない
• 運用をやりやすくする
• Hadoopのスケーラビリティに追従可能な仕組み
44. クラウド上での大量データ処理の概要モデル
データの生
成・保存、
並列分析 インデクシ (ニア)
構造化データ データ保存 リアルタイム
処理 ング、アグ
半構造化データ リゲーショ 分析
ン
Batch Tier Speed Tier
S3 Hadoop HBase
EMR SimpleDB
Cassandra
MongoDB
RDBMS