1. Amazon Elastic MapReduce
with Hive/Presto ハンズオン(講義)
2015/5/13
Ryosuke Iwanaga
Solutions Architect, Amazon Data Services Japan

2. AWSでのビッグデータ

3. 3
ビッグデータの活⽤用
• 在庫情報
• 販売・売上実績
• POSデータ
• ユーザの⾏行行動分析
• ゲーム・タイトルの
KPI
• センサーや⾞車車載ナビ
からの⾛走⾏行行情報
GB TB
PB
ZB
EB
データ量量の劇的な増加

4. 4
AWSが提供するクラウドの特徴
• 事前の投資が不不要
• 従量量課⾦金金制の低価格な利利⽤用コスト
• 必要時に必要なリソースを瞬時に調達
• リリースまでの時間を短く、海外展開も迅速に
• 本来のビジネスにフォーカスできる

5. 5
オンとオフ 急成⻑⾧長やM&A
予測可能なピーク予測できないピーク
余剰キャパシティ
キャパシティ不不⾜足：機会損失
余剰キャパシティ
余剰キャパシティ
余剰キャパシティ
Before

6. 6
After
急成⻑⾧長やM&Aオンとオフ
予測可能なピーク予測できないピーク
IT余剰と不不⾜足からの開放

7. 7

8. 8
トランザクション
データを保存
ファイルデータ
を保存
ストリームデータ
を保存

9. 9
複雑な分析
ストリームを
イベント処理理

10. 10
Amazon EMRが
分析の中⼼心的存在

11. Amazon Elastic MapReduceの概要

12. 12
Amazon Elastic MapReduceとは？
• 1クリックでHadoopクラスタが⼿手に⼊入る
– 使い終わったらまとめて捨てるのも簡単
– スポットインスタンスを使ったコストカットも
• 設定済のアプリケーションがすぐ使える
– Application: Hive, Hue, Impalaなど
– Bootstrap Action: Presto, Sparkなど
• ⾏行行うべき処理理を簡単に設定できる
– ジョブが終わったらクラスタを消すところまで⾃自動化

13. 13
Task Node
Task Instance Group
Amazon EMRのアーキテクチャ
security group
security group
Master Node
Master Instance Group
Amazon
S3
DynamoDB
Amazon
Kinesis
Core Node
Core Instance Group
HDFS HDFS
HDFS HDFS
Task Node
Task Instance Group
スレーブ群を
管理理 HDFS
アクセス
AWSサービス
アクセス

14. 14
Amazon EMR Master Instance Group
• Master Nodeは1つ
– Failoverは⾮非対応
• いわゆるマスターの
役割を担う
– NameNodeや
JobTrackerなどが動く
– Core NodeやTask
Nodeの監視
Master Node
Master Instance Group
Hadoop1: JobTracker
Hadoop2: ResourceManager
HDFS: NameNode
Hive: HiveServer, MetaStore
Presto: Coordinator

15. 15
Amazon EMR Core Instance Group
• 1つ以上のCore Node
• いわゆるスレーブの
役割を担う
– TaskTrackerなど
– DataNodeが動きロー
カルディスクがHDFS
としても使われる
HDFS
Core Node
Core Instance Group
Hadoop1: TaskTracker
Hadoop2: NodeManager
HDFS: DataNode
Presto: Worker

16. 16
Amazon EMR Core Instance Group
• Core Node追加可能
– HDFS容量量増加
– CPU/RAM増設
• 但し、HDFSを持って
いるため、削減はで
きない
HDFS
Core Node
Core Instance Group
Hadoop1: TaskTracker
Hadoop2: NodeManager
HDFS: DataNode
Presto: Worker

17. 17
Amazon EMR Task Instance Group
• HDFSを持たない以外
はCoreと同じ役割
• HDFSのデータは
Core Nodeにアクセ
スする
• HDFSを持たないので
削除も⾃自由
Task Node
Task Instance Group
Hadoop1: TaskTracker
Hadoop2: NodeManager
Presto: Worker

18. 18
Amazon EMR Task Instance Group
• 複数Group設定可能
– Spotのbid価格を調整
– Instance Typeを調整
• 余っているRIを活⽤用
したり、市場価格に
合わせてSpotを調整
したりと柔軟に対応
Task Instance Group 2
Task Instance Group 1
c3.xlarge * 2
bid: $0.1
r3.xlarge * 2
bid: $0.5

19. 19
参考: スポットリクエストと課⾦金金
単価
時間
1h 1h
<1h
スポット価格
⼊入札額
課⾦金金額
②⼊入札額>スポット価格
となったので
インスタンス起動
④⼊入札額＜スポット価格
となったので
インスタンス終了了
⑥⼊入札額>スポット価格
となったので
インスタンス起動
①リクエスト
投⼊入
⑤強制終了了時の1時間
未満の利利⽤用分は⾮非課⾦金金
③1時間
単位の課⾦金金

20. 20
Spot Instanceの活⽤用例例
Task Instance GroupCore Instance Group
予測されたコストでSLAを満たす 低コストでSLAを上回る
On-‐‑‒demandを
Core Nodeに利利⽤用
SLAを満たすだけの
キャパシティをOn-‐‑‒
demand価格で確保
Spot Instanceを
Task Nodeに利利⽤用
On-‐‑‒demandの最⼤大
90%引き程度度の価格
で追加のキャパシ
ティを確保

21. 21
EMRFS: Amazon S3をHDFSの様に扱う
• 計算資源とストレージを隔離離できる
• クラスタのシャットダウンが可能
– クラスタを消してもデータをロストしない
• 複数クラスタ間でデータ共有が簡単
– クラスタのバージョンアップ検証が並⾏行行できる
EMR
EMR
Amazon
S3

22. 22
EMRFSの特徴
• “s3://”と指定するだけで利利⽤用可能
• Amazon S3の機能がそのまま使える
– 例例: 古いデータはAmazon Glacierに⾃自動で移動させる
• Amazon S3のサーバサイド・クライアントサイ
ドの暗号化も利利⽤用可能
– 他のアプリでクライアント暗号化したAmazon S3データも読み
出し可能
• クラスタを消してもデータは消えない

23. 23
EMRFSのConsistent View
• Amazon S3は結果整合性
– 書き込み直後の読み取りは不不整
合の可能性
• EMRFSではConsistent View
を提供
– Amazon DynamoDBにメタデー
タを格納し整合性担保
• 結果としてオブジェクトのリ
スト取得も⾼高速に
Amazon S3
Amazon DynamoDB
EMRFSの
メタデータを格納

24. 24
Amazon EMRならではの使い⽅方
• 必要な時だけクラスタ起動
– 時間課⾦金金なので、消せばお
⾦金金はかからない
– 処理理が終わったら⾃自動で消
える設定も可能
• データは全てAmazon S3に
置く
– クラスタを消してもデータ
は消えない
– データを貯める段階なら
EMRすら不不要
t

25. 25
Amazon EMRの機能: Bootstrap Action
• 全てのNodeの起動時に実⾏行行されるスクリプト
– 実⾏行行可能ファイルであれば何でもOK
• Bash, Ruby, Python, etc.
– Amazon S3にファイルを置いて指定する
– コマンドライン引数も⾃自由に指定できる
• 任意のソフトウェアをインストールしたり、設
定したりできる
– AWS提供のものもいくつか存在する

26. 26
Amazon EMRの機能: Step
• クラスタが準備できたら始まる処理理
– クラスタ起動時に設定することもできるし、起動しているクラスタ
に後から追加することもできる
– 例例: ⽇日次のETL処理理を⾏行行うHiveQL実⾏行行
• Amazon S3のjarファイルを指定すると実⾏行行される
– Streaming, Hive, PigはEMRがサポート
• 必要なスクリプトをS3で指定するだけ
– script-‐‑‒runner.jarでbashスクリプトを実⾏行行させることも可能
• 最後のStepが終わったら⾃自動でクラスタを終了了させ
ることもできる(Auto-‐‑‒terminate)

27. 27
Amazon EMRの機能: Application
• いくつかのApplicationをサポート
– Hive, Pig, Hue, HBase, etc.
– 実体はBootstrap ActionとStepの組み合わせ
• 難しいことを覚えずに、分散処理理をすぐ使える
– 最近はMapReduceを直接書くより、⽤用途に合わせたアプリケー
ションを利利⽤用することでレイテンシ最適化を⾏行行うことが多い
– Bootstrap Action, Step, Applicationを組み合わせて、分散処
理理を簡単に扱える環境を提供するのが、Amazon EMR

28. 28
Amazon EMRまとめ
• 計算資源を簡単に利利⽤用可能
• 使った分だけのコスト(Spotも可能)
• Amazon S3と組み合わせて堅牢牢性⾼高く
• ⾃自由なソフトウェアを利利⽤用可能
• 終わったら廃棄するのも簡単
→ ビッグデータ分析の中⼼心的存在

29. Hiveの概要

30. 30
Hiveとは？
• SQL likeな宣⾔言的⾔言語で、ビッグデータに対する
処理理が⾏行行える仕組み
• HDFS上のファイル群に対してスキーマを定義す
ることでテーブルの様に扱える
– Amazon EMRではEMRFSでAmazon S3も扱え、加えてAmazon
DynamoDBやAmazon Kinesisもテーブルとして扱える
• 処理理の実際は実⾏行行エンジンによって異異なる
– MapReduce, Tez, Spark

31. 31
Hiveの処理理例例
Metastore
HDFS
Cluster
Amazon
S3
Hiveserver
CREATE
TABLE
SELECT
FROM
1: テーブル定義
でHDFSやS3を
ソースに指定
2: テーブル定義
がメタデータとし
て保存される
3: 定義したテーブル
に対して処理理を実⾏行行
4: テーブルの
メタデータを
取得
5:クラスタに
処理理を依頼
6: 実際のデー
タソースから
読み出しつつ
指定された処
理理を⾏行行う Amazon
DynamoDB
Amazon
Kinesis

32. 32
Hiveの進化は⽌止まらない
• 初期は実⾏行行エンジンがMapReduceのみだった
– あくまでMapReduceを書きやすくするためのフレームワーク
– バッチ処理理がターゲットなのでインタラクティブ処理理は難しい
• Stinger Initiativeの完了了 = Hive 0.13
– インタラクティブ処理理が可能に
– Tez実⾏行行エンジン、列列指向ファイル、SQL標準に近づく、etc.
• Stinger.next = 1秒以下のクエリへ向けて
– Spark実⾏行行エンジン、ACIDトランザクション、SQL:2011

33. 33
Hive on Amazon EMR
• Applicationサポート
– クラスタ起動時に指定
– すぐに利利⽤用可能
• Metastore
– デフォルトではMaster上
のMySQLに保存
– hive-‐‑‒site.xmlを設定して任
意のMySQLも利利⽤用可能
$ aws emr create-cluster …
--applications Name=Hive
…

34. YARNの概要

35. 35
YARNとは？
• YARN = Yet-‐‑‒Another-‐‑‒Resource-‐‑‒Negotiator
• Hadoop2から導⼊入されたリソース管理理の仕組み
– 以前は全てJobTrackerが⾏行行っていた
• YARN対応アプリケーションであればマルチテ
ナントに動かすことが容易易
– MapReduceだけでなく、分散リソースを必要とする処理理をクラ
スタが許す限りいくらでも並列列に実⾏行行できる

36. 36
YARN: ResourceManager
• マスターサーバで稼働
• スレーブ群のリソース情
報を集約
– CPU, Memory, etc.
• 必要なリソースを探して
割り当ててくれる
• ジョブの管理理は⾏行行わない

37. 37
YARN: NodeManager
• スレーブサーバで稼働
• そのサーバのリソース情
報をRMに報告
• サーバ上のContainerの
管理理を⾏行行う
– 要求に答えてContainerを
起動する

38. 38
YARN: Container
• スレーブのリソースが切切
り出されたもの
• NMによって起動される
• 実⾏行行⽅方式
– DefaultContainerExecutor
• プロセス
– LinuxContainerExecutor
• cgroups
– DockerContainerExecutor
• Docker

39. 39
YARN: ApplicationMaster
• ジョブ全体を管理理する
Container
– 旧JobTrackerの様な存在
– ジョブ毎に1つのAM
• ジョブを分散処理理する
Container全体の進捗管
理理や監視を⾏行行う

40. 40
YARNがもたらしたもの
• クラスタのリソース管理理の抽象化
– 同様のものに、Mesos, Amazon EC2 Container Service等がある
• 分散処理理実⾏行行フレームワーク
– 実際の分散処理理の開発に注⼒力力できる
– YARN対応すれば全てをマルチテナント実⾏行行できる
• YARN上のフレームワークも
– Tez: DAG処理理を⾼高速にYARN上で実⾏行行する(詳細は後で)
– Twill: YARNアプリを簡単に書ける
– Slider: コード変えずに⻑⾧長期起動アプリをYARN上で動かせる

41. Tezの概要

42. 42
Tezとは？
• YARN上でDAG処理理を⾼高速実⾏行行するフレーム
ワーク
• Directed Acyclic Graph (DAG)
– Vertex(頂点): データ処理理を表す
• Map, Reduce, Joinなど
– Edge(辺): データの流流れを表す
• ProducerからConsumerへ
• SQL等の分散処理理はDAGで書ける
– DAGに変換できればTezで実⾏行行できる

43. 43
Tezを利利⽤用したアプリケーション例例
• Hive,Pig,Cascading
• MRより処理理速度度向上
– 処理理の最適化
– 中間結果をHDFSを介
さず渡す
– Containerを再利利⽤用
– Sessionでインタラク
ティブ処理理を⾼高速に

44. ORC File / Parquetの概要

45. 45
古典的なHiveのファイルフォーマット
• TEXTFILE
– 1⾏行行ずつテキストで保存する(CSVファイルも⼀一つの⽅方式)
• SEQUENCEFILE
– 1⾏行行ずつバイナリで保存する
→ いずれも⾏行行指向フォーマット
• 1カラムのSELECTでもレコード全体を読む
– カラムが多いと無駄が増える

46. 46
ORC File / Parquet
• 列列指向ファイルフォーマット
– カラム毎にデータをまとめて保存する
– 特定の列列を扱う処理理ではファイル全体を読む必要がない
• Optimized Row Columnar(ORC) File
– Stinger Projectで実装、RCFileの後継
• Parquet
– Twitter/Clouderaからの提案
– GoogleのDremel論論⽂文から発想を得ている

47. 47
ORC Fileとは
• Stripeという単位で⾏行行をグループ化
– それぞれにIndexとFooterがつく
– Indexにはmin/max等の値と、Row
Dataのポジションが⼊入っている
• Fileの最後にメタデータが⼊入っている
– Footerにはファイル全体の配置や型情報、
⾏行行数や列列毎の統計情報が⼊入っている
• Hiveがデータを効率率率よく保存するた
めのフォーマットとして設計されて
いる

48. 48
Parquetとは
• ColumnChunkという単
位で列列指向で保存
– Thriftでシリアライズ
• ColumnChunkの集合と
してRow Groupに分割
• ファイルの最後にメタ
データが保存される
• 基本的にはORCと似た形

49. 49
列列指向フォーマットを使うメリット
• 特定列列のみの読み書きが効率率率的
– ビッグデータ分析では全列列を使うことは稀
– 単純な統計データならメタデータのみで完結する
• 列列毎には似たデータが続くので圧縮効率率率が良良い
• ⾏行行毎にグループ化されているので1⾏行行のデータ
は1つのファイルに収まっている
→ Hive 0.13ではORC/Parquet共に利利⽤用可能

50. 50
HiveでのORC File/Parquetの使い⽅方
• テーブル定義で指定
するだけ
• あとは何も意識識しな
くて良良い
CREATE TABLE t (
col1 STRING,
…
) STORED AS [ORC/PARQUET];
INSERT INTO t (…);
SELECT col1 FROM t;

51. 51
Hadoop/Hiveエコシステムまとめ
• SQL的な⾔言語でビッグデータを扱うことがデ
ファクトに
– 列列指向フォーマットでより効率率率化
• Hadoop2は全ての計算がYARN上で動く
– マルチテナント処理理が⾮非常に簡単に
• Hive⾃自体も⾼高速化・⾼高機能化を続けている
• これら全ての恩恵がAmazon EMRで享受可能

52. Hive以外の分散SQL実⾏行行環境

53. 53
Massively Parallel Processing (MPP) SQL
• ⼤大規模分散SQLを実⾏行行環
境はHiveだけではない
• HiveライクなMPP
– Presto, Impala, Spark
SQL, Drill
• DWH
– Amazon Redshift
• データ⾃自体もMPPに特化さ
せてAmazon Redshift内に
保持する
Amazon Redshift

54. 54
Hiveとの親和性
• Metastoreをsync/
shareしている
– Hiveで作ったテーブルを
そのまま利利⽤用可能
• Impala, Spark SQLは
HiveQL互換
– Presto, DrillはANSI
SQL対応
→同じデータを異異なるエ
ンジンから処理理できる Metastore
HDFS
Amazon
S3
テーブル定義を
共有
スキーマを利利⽤用しつつ
データにアクセス

55. Presto概要

56. 56
Prestoとは？
• MPP SQLエンジンの1つ
• ANSI SQL準拠のクエリ⾔言語
• 独⾃自のクラスタでSQLの⾼高速分散実⾏行行に特化
– メモリ上でデータをやり取り
– 今のところYARN等の対応は無い
• MySQLやPostgreSQL等にもクエリが可能
– 異異なるデータソースをJOINすることも可能

57. 57
Prestoのアーキテクチャ
• Coordinator
– マスター的役割
– クエリを受け付け、実
⾏行行計画を⽴立立てる
• Worker
– スレーブ的役割
– Coordinatorからタス
クが割り振られる
Amazon
S3

58. 58
Presto on Amazon EMR
• 2015年年4⽉月現在、Applicationサポートは無し
• Bootstrap Actionでのインストールが可能
– AWSから提供されるスクリプトが存在
– https://github.com/awslabs/emr-‐‑‒bootstrap-‐‑‒actions/tree/master/presto/latest
• PrestoはYARNと別でクラスタを組むのでリ
ソース競合に注意
– お互いがサーバのリソースを使いきる可能性
– Presto専⽤用のAmazon EMRクラスタとして使うのがベター

59. まとめ

60. 60
Amazon EMRでビッグデータ分析を始めよう！
• ビッグデータ分析に必須な環境がAWSなら簡単
に⼿手に⼊入る
– Amazon EMRで分散計算環境＋ソフトウェア
– Amazon S3で堅牢牢な巨⼤大ストレージ
– その他も沢⼭山のビッグデータを⽀支えるサービスがあります
• 難しいことを覚える前に、まずは試してみま
しょう！