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.
Amazon  Elastic  MapReduce
with  Hive/Presto  ハンズオン(講義)
2015/5/13
Ryosuke  Iwanaga
Solutions  Architect,  Amazon  Data  Se...
AWSでのビッグデータ
3
ビッグデータの活⽤用
•  在庫情報
•  販売・売上実績
•  POSデータ
•  ユーザの⾏行行動分析
•  ゲーム・タイトルの
KPI
•  センサーや⾞車車載ナビ
からの⾛走⾏行行情報
GB TB
PB
ZB
EB
データ量量の劇的...
4
AWSが提供するクラウドの特徴
•  事前の投資が不不要
•  従量量課⾦金金制の低価格な利利⽤用コスト
•  必要時に必要なリソースを瞬時に調達
•  リリースまでの時間を短く、海外展開も迅速に
•  本来のビジネスにフォーカスできる
5
オンとオフ 急成⻑⾧長やM&A
予測可能なピーク予測できないピーク
余剰キャパシティ
キャパシティ不不⾜足:機会損失
余剰キャパシティ
余剰キャパシティ
余剰キャパシティ
Before
6
After
急成⻑⾧長やM&Aオンとオフ
予測可能なピーク予測できないピーク
IT余剰と不不⾜足からの開放
7
8
トランザクション
データを保存
ファイルデータ
を保存
ストリームデータ
を保存
9
複雑な分析
ストリームを
イベント処理理
10
Amazon  EMRが
分析の中⼼心的存在
Amazon  Elastic  MapReduceの概要
12
Amazon  Elastic  MapReduceとは?
•  1クリックでHadoopクラスタが⼿手に⼊入る
–  使い終わったらまとめて捨てるのも簡単
–  スポットインスタンスを使ったコストカットも
•  設定済のアプリケーション...
13
Task Node
Task Instance Group
Amazon  EMRのアーキテクチャ
security group
security group
Master Node
Master Instance Group
Amazo...
14
Amazon  EMR  Master  Instance  Group
•  Master  Nodeは1つ
–  Failoverは⾮非対応
•  いわゆるマスターの
役割を担う
–  NameNodeや
JobTrackerなどが動...
15
Amazon  EMR  Core  Instance  Group
•  1つ以上のCore  Node
•  いわゆるスレーブの
役割を担う
–  TaskTrackerなど
–  DataNodeが動きロー
カルディスクがHDFS
...
16
Amazon  EMR  Core  Instance  Group
•  Core  Node追加可能
–  HDFS容量量増加
–  CPU/RAM増設
•  但し、HDFSを持って
いるため、削減はで
きない
HDFS
Core N...
17
Amazon  EMR  Task  Instance  Group
•  HDFSを持たない以外
はCoreと同じ役割
•  HDFSのデータは
Core  Nodeにアクセ
スする
•  HDFSを持たないので
削除も⾃自由
Task...
18
Amazon  EMR  Task  Instance  Group
•  複数Group設定可能
–  Spotのbid価格を調整
–  Instance  Typeを調整
•  余っているRIを活⽤用
したり、市場価格に
合わせてSp...
19
参考:  スポットリクエストと課⾦金金      
単価
時間
1h 1h
<1h
スポット価格
⼊入札額
課⾦金金額
②⼊入札額>スポット価格
となったので
インスタンス起動
④⼊入札額<スポット価格
となったので
インスタンス終了了
...
20
Spot  Instanceの活⽤用例例
Task Instance GroupCore Instance Group
予測されたコストでSLAを満たす 低コストでSLAを上回る
On-‐‑‒demandを
Core  Nodeに利利⽤用...
21
EMRFS:  Amazon  S3をHDFSの様に扱う
•  計算資源とストレージを隔離離できる
•  クラスタのシャットダウンが可能
–  クラスタを消してもデータをロストしない
•  複数クラスタ間でデータ共有が簡単
–  クラスタ...
22
EMRFSの特徴
•  “s3://”と指定するだけで利利⽤用可能
•  Amazon  S3の機能がそのまま使える
–  例例:  古いデータはAmazon  Glacierに⾃自動で移動させる
•  Amazon  S3のサーバサイド...
23
EMRFSのConsistent  View
•  Amazon  S3は結果整合性
–  書き込み直後の読み取りは不不整
合の可能性
•  EMRFSではConsistent  View
を提供
–  Amazon  DynamoDBに...
24
Amazon  EMRならではの使い⽅方
•  必要な時だけクラスタ起動
–  時間課⾦金金なので、消せばお
⾦金金はかからない
–  処理理が終わったら⾃自動で消
える設定も可能
•  データは全てAmazon  S3に
置く
–  ク...
25
Amazon  EMRの機能:  Bootstrap  Action
•  全てのNodeの起動時に実⾏行行されるスクリプト
–  実⾏行行可能ファイルであれば何でもOK
•  Bash,  Ruby,  Python,  etc.
– ...
26
Amazon  EMRの機能:  Step
•  クラスタが準備できたら始まる処理理
–  クラスタ起動時に設定することもできるし、起動しているクラスタ
に後から追加することもできる
–  例例:  ⽇日次のETL処理理を⾏行行うHive...
27
Amazon  EMRの機能:  Application
•  いくつかのApplicationをサポート
–  Hive,  Pig,  Hue,  HBase,  etc.
–  実体はBootstrap  ActionとStepの組...
28
Amazon  EMRまとめ
•  計算資源を簡単に利利⽤用可能
•  使った分だけのコスト(Spotも可能)
•  Amazon  S3と組み合わせて堅牢牢性⾼高く
•  ⾃自由なソフトウェアを利利⽤用可能
•  終わったら廃棄するのも...
Hiveの概要
30
Hiveとは?
•  SQL  likeな宣⾔言的⾔言語で、ビッグデータに対する
処理理が⾏行行える仕組み
•  HDFS上のファイル群に対してスキーマを定義す
ることでテーブルの様に扱える
–  Amazon  EMRではEMRFSでA...
31
Hiveの処理理例例
Metastore
HDFS
Cluster
Amazon
S3
Hiveserver
CREATE
TABLE
SELECT
FROM
1:  テーブル定義
でHDFSやS3を
ソースに指定
2:  テーブル定義
...
32
Hiveの進化は⽌止まらない
•  初期は実⾏行行エンジンがMapReduceのみだった
–  あくまでMapReduceを書きやすくするためのフレームワーク
–  バッチ処理理がターゲットなのでインタラクティブ処理理は難しい
•  St...
33
Hive  on  Amazon  EMR
•  Applicationサポート
–  クラスタ起動時に指定
–  すぐに利利⽤用可能
•  Metastore
–  デフォルトではMaster上
のMySQLに保存
–  hive-‐‑...
YARNの概要
35
YARNとは?
•  YARN  =  Yet-‐‑‒Another-‐‑‒Resource-‐‑‒Negotiator
•  Hadoop2から導⼊入されたリソース管理理の仕組み
–  以前は全てJobTrackerが⾏行行っていた
•...
36
YARN:  ResourceManager
•  マスターサーバで稼働
•  スレーブ群のリソース情
報を集約
–  CPU,  Memory,  etc.
•  必要なリソースを探して
割り当ててくれる
•  ジョブの管理理は⾏行行わ...
37
YARN:  NodeManager
•  スレーブサーバで稼働
•  そのサーバのリソース情
報をRMに報告
•  サーバ上のContainerの
管理理を⾏行行う
–  要求に答えてContainerを
起動する
38
YARN:  Container
•  スレーブのリソースが切切
り出されたもの
•  NMによって起動される
•  実⾏行行⽅方式
–  DefaultContainerExecutor
•  プロセス
–  LinuxContaine...
39
YARN:  ApplicationMaster
•  ジョブ全体を管理理する
Container
–  旧JobTrackerの様な存在
–  ジョブ毎に1つのAM
•  ジョブを分散処理理する
Container全体の進捗管
理理や監...
40
YARNがもたらしたもの
•  クラスタのリソース管理理の抽象化
–  同様のものに、Mesos,  Amazon  EC2  Container  Service等がある  
•  分散処理理実⾏行行フレームワーク
–  実際の分散処理...
Tezの概要
42
Tezとは?
•  YARN上でDAG処理理を⾼高速実⾏行行するフレーム
ワーク
•  Directed  Acyclic  Graph  (DAG)
–  Vertex(頂点):  データ処理理を表す
•  Map,  Reduce, ...
43
Tezを利利⽤用したアプリケーション例例
•  Hive,Pig,Cascading
•  MRより処理理速度度向上
–  処理理の最適化
–  中間結果をHDFSを介
さず渡す
–  Containerを再利利⽤用
–  Session...
ORC  File  /  Parquetの概要
45
古典的なHiveのファイルフォーマット
•  TEXTFILE
–  1⾏行行ずつテキストで保存する(CSVファイルも⼀一つの⽅方式)
•  SEQUENCEFILE
–  1⾏行行ずつバイナリで保存する
→  いずれも⾏行行指向フォーマ...
46
ORC  File  /  Parquet
•  列列指向ファイルフォーマット
–  カラム毎にデータをまとめて保存する
–  特定の列列を扱う処理理ではファイル全体を読む必要がない
•  Optimized  Row  Columnar...
47
ORC  Fileとは
•  Stripeという単位で⾏行行をグループ化
–  それぞれにIndexとFooterがつく
–  Indexにはmin/max等の値と、Row  
Dataのポジションが⼊入っている
•  Fileの最後にメ...
48
Parquetとは
•  ColumnChunkという単
位で列列指向で保存
–  Thriftでシリアライズ
•  ColumnChunkの集合と
してRow  Groupに分割
•  ファイルの最後にメタ
データが保存される
•  基...
49
列列指向フォーマットを使うメリット
•  特定列列のみの読み書きが効率率率的
–  ビッグデータ分析では全列列を使うことは稀
–  単純な統計データならメタデータのみで完結する
•  列列毎には似たデータが続くので圧縮効率率率が良良い
•...
50
HiveでのORC  File/Parquetの使い⽅方
•  テーブル定義で指定
するだけ
•  あとは何も意識識しな
くて良良い
CREATE TABLE t (
col1 STRING,
…
) STORED AS [ORC/PAR...
51
Hadoop/Hiveエコシステムまとめ
•  SQL的な⾔言語でビッグデータを扱うことがデ
ファクトに
–  列列指向フォーマットでより効率率率化
•  Hadoop2は全ての計算がYARN上で動く
–  マルチテナント処理理が⾮非常に...
Hive以外の分散SQL実⾏行行環境
53
Massively  Parallel  Processing  (MPP)  SQL
•  ⼤大規模分散SQLを実⾏行行環
境はHiveだけではない
•  HiveライクなMPP
–  Presto,  Impala,  Spark  ...
54
Hiveとの親和性
•  Metastoreをsync/
shareしている
–  Hiveで作ったテーブルを
そのまま利利⽤用可能
•  Impala,  Spark  SQLは
HiveQL互換
–  Presto,  DrillはA...
Presto概要
56
Prestoとは?
•  MPP  SQLエンジンの1つ
•  ANSI  SQL準拠のクエリ⾔言語
•  独⾃自のクラスタでSQLの⾼高速分散実⾏行行に特化
–  メモリ上でデータをやり取り
–  今のところYARN等の対応は無い
• ...
57
Prestoのアーキテクチャ
•  Coordinator
–  マスター的役割
–  クエリを受け付け、実
⾏行行計画を⽴立立てる
•  Worker
–  スレーブ的役割
–  Coordinatorからタス
クが割り振られる
Ama...
58
Presto  on  Amazon  EMR
•  2015年年4⽉月現在、Applicationサポートは無し
•  Bootstrap  Actionでのインストールが可能
–  AWSから提供されるスクリプトが存在
–  http...
まとめ
60
Amazon  EMRでビッグデータ分析を始めよう!
•  ビッグデータ分析に必須な環境がAWSなら簡単
に⼿手に⼊入る
–  Amazon  EMRで分散計算環境+ソフトウェア
–  Amazon  S3で堅牢牢な巨⼤大ストレージ
– ...
Upcoming SlideShare
Loading in …5
×

Amazon Elastic MapReduce with Hive/Presto ハンズオン(講義)

11,755 views

Published on

Published in: Internet

Amazon Elastic MapReduce with Hive/Presto ハンズオン(講義)

  1. 1. Amazon  Elastic  MapReduce with  Hive/Presto  ハンズオン(講義) 2015/5/13 Ryosuke  Iwanaga Solutions  Architect,  Amazon  Data  Services  Japan
  2. 2. AWSでのビッグデータ
  3. 3. 3 ビッグデータの活⽤用 •  在庫情報 •  販売・売上実績 •  POSデータ •  ユーザの⾏行行動分析 •  ゲーム・タイトルの KPI •  センサーや⾞車車載ナビ からの⾛走⾏行行情報 GB TB PB ZB EB データ量量の劇的な増加
  4. 4. 4 AWSが提供するクラウドの特徴 •  事前の投資が不不要 •  従量量課⾦金金制の低価格な利利⽤用コスト •  必要時に必要なリソースを瞬時に調達 •  リリースまでの時間を短く、海外展開も迅速に •  本来のビジネスにフォーカスできる
  5. 5. 5 オンとオフ 急成⻑⾧長やM&A 予測可能なピーク予測できないピーク 余剰キャパシティ キャパシティ不不⾜足:機会損失 余剰キャパシティ 余剰キャパシティ 余剰キャパシティ Before
  6. 6. 6 After 急成⻑⾧長やM&Aオンとオフ 予測可能なピーク予測できないピーク IT余剰と不不⾜足からの開放
  7. 7. 7
  8. 8. 8 トランザクション データを保存 ファイルデータ を保存 ストリームデータ を保存
  9. 9. 9 複雑な分析 ストリームを イベント処理理
  10. 10. 10 Amazon  EMRが 分析の中⼼心的存在
  11. 11. Amazon  Elastic  MapReduceの概要
  12. 12. 12 Amazon  Elastic  MapReduceとは? •  1クリックでHadoopクラスタが⼿手に⼊入る –  使い終わったらまとめて捨てるのも簡単 –  スポットインスタンスを使ったコストカットも •  設定済のアプリケーションがすぐ使える –  Application:  Hive,  Hue,  Impalaなど –  Bootstrap  Action:  Presto,  Sparkなど •  ⾏行行うべき処理理を簡単に設定できる –  ジョブが終わったらクラスタを消すところまで⾃自動化
  13. 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. 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. 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. 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. 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. 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. 19 参考:  スポットリクエストと課⾦金金       単価 時間 1h 1h <1h スポット価格 ⼊入札額 課⾦金金額 ②⼊入札額>スポット価格 となったので インスタンス起動 ④⼊入札額<スポット価格 となったので インスタンス終了了 ⑥⼊入札額>スポット価格 となったので インスタンス起動 ①リクエスト 投⼊入 ⑤強制終了了時の1時間 未満の利利⽤用分は⾮非課⾦金金 ③1時間 単位の課⾦金金
  20. 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. 21 EMRFS:  Amazon  S3をHDFSの様に扱う •  計算資源とストレージを隔離離できる •  クラスタのシャットダウンが可能 –  クラスタを消してもデータをロストしない •  複数クラスタ間でデータ共有が簡単 –  クラスタのバージョンアップ検証が並⾏行行できる EMR EMR Amazon S3
  22. 22. 22 EMRFSの特徴 •  “s3://”と指定するだけで利利⽤用可能 •  Amazon  S3の機能がそのまま使える –  例例:  古いデータはAmazon  Glacierに⾃自動で移動させる •  Amazon  S3のサーバサイド・クライアントサイ ドの暗号化も利利⽤用可能 –  他のアプリでクライアント暗号化したAmazon  S3データも読み 出し可能 •  クラスタを消してもデータは消えない
  23. 23. 23 EMRFSのConsistent  View •  Amazon  S3は結果整合性 –  書き込み直後の読み取りは不不整 合の可能性 •  EMRFSではConsistent  View を提供 –  Amazon  DynamoDBにメタデー タを格納し整合性担保 •  結果としてオブジェクトのリ スト取得も⾼高速に Amazon S3 Amazon DynamoDB EMRFSの メタデータを格納
  24. 24. 24 Amazon  EMRならではの使い⽅方 •  必要な時だけクラスタ起動 –  時間課⾦金金なので、消せばお ⾦金金はかからない –  処理理が終わったら⾃自動で消 える設定も可能 •  データは全てAmazon  S3に 置く –  クラスタを消してもデータ は消えない –  データを貯める段階なら EMRすら不不要 t
  25. 25. 25 Amazon  EMRの機能:  Bootstrap  Action •  全てのNodeの起動時に実⾏行行されるスクリプト –  実⾏行行可能ファイルであれば何でもOK •  Bash,  Ruby,  Python,  etc. –  Amazon  S3にファイルを置いて指定する –  コマンドライン引数も⾃自由に指定できる •  任意のソフトウェアをインストールしたり、設 定したりできる –  AWS提供のものもいくつか存在する
  26. 26. 26 Amazon  EMRの機能:  Step •  クラスタが準備できたら始まる処理理 –  クラスタ起動時に設定することもできるし、起動しているクラスタ に後から追加することもできる –  例例:  ⽇日次のETL処理理を⾏行行うHiveQL実⾏行行 •  Amazon  S3のjarファイルを指定すると実⾏行行される –  Streaming,  Hive,  PigはEMRがサポート •  必要なスクリプトをS3で指定するだけ –  script-‐‑‒runner.jarでbashスクリプトを実⾏行行させることも可能 •  最後のStepが終わったら⾃自動でクラスタを終了了させ ることもできる(Auto-‐‑‒terminate)
  27. 27. 27 Amazon  EMRの機能:  Application •  いくつかのApplicationをサポート –  Hive,  Pig,  Hue,  HBase,  etc. –  実体はBootstrap  ActionとStepの組み合わせ •  難しいことを覚えずに、分散処理理をすぐ使える –  最近はMapReduceを直接書くより、⽤用途に合わせたアプリケー ションを利利⽤用することでレイテンシ最適化を⾏行行うことが多い –  Bootstrap  Action,  Step,  Applicationを組み合わせて、分散処 理理を簡単に扱える環境を提供するのが、Amazon  EMR
  28. 28. 28 Amazon  EMRまとめ •  計算資源を簡単に利利⽤用可能 •  使った分だけのコスト(Spotも可能) •  Amazon  S3と組み合わせて堅牢牢性⾼高く •  ⾃自由なソフトウェアを利利⽤用可能 •  終わったら廃棄するのも簡単 →  ビッグデータ分析の中⼼心的存在
  29. 29. Hiveの概要
  30. 30. 30 Hiveとは? •  SQL  likeな宣⾔言的⾔言語で、ビッグデータに対する 処理理が⾏行行える仕組み •  HDFS上のファイル群に対してスキーマを定義す ることでテーブルの様に扱える –  Amazon  EMRではEMRFSでAmazon  S3も扱え、加えてAmazon   DynamoDBやAmazon  Kinesisもテーブルとして扱える •  処理理の実際は実⾏行行エンジンによって異異なる –  MapReduce,  Tez,  Spark
  31. 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. 32 Hiveの進化は⽌止まらない •  初期は実⾏行行エンジンがMapReduceのみだった –  あくまでMapReduceを書きやすくするためのフレームワーク –  バッチ処理理がターゲットなのでインタラクティブ処理理は難しい •  Stinger  Initiativeの完了了  =  Hive  0.13 –  インタラクティブ処理理が可能に –  Tez実⾏行行エンジン、列列指向ファイル、SQL標準に近づく、etc. •  Stinger.next  =  1秒以下のクエリへ向けて –  Spark実⾏行行エンジン、ACIDトランザクション、SQL:2011
  33. 33. 33 Hive  on  Amazon  EMR •  Applicationサポート –  クラスタ起動時に指定 –  すぐに利利⽤用可能 •  Metastore –  デフォルトではMaster上 のMySQLに保存 –  hive-‐‑‒site.xmlを設定して任 意のMySQLも利利⽤用可能 $ aws emr create-cluster … --applications Name=Hive …
  34. 34. YARNの概要
  35. 35. 35 YARNとは? •  YARN  =  Yet-‐‑‒Another-‐‑‒Resource-‐‑‒Negotiator •  Hadoop2から導⼊入されたリソース管理理の仕組み –  以前は全てJobTrackerが⾏行行っていた •  YARN対応アプリケーションであればマルチテ ナントに動かすことが容易易 –  MapReduceだけでなく、分散リソースを必要とする処理理をクラ スタが許す限りいくらでも並列列に実⾏行行できる
  36. 36. 36 YARN:  ResourceManager •  マスターサーバで稼働 •  スレーブ群のリソース情 報を集約 –  CPU,  Memory,  etc. •  必要なリソースを探して 割り当ててくれる •  ジョブの管理理は⾏行行わない
  37. 37. 37 YARN:  NodeManager •  スレーブサーバで稼働 •  そのサーバのリソース情 報をRMに報告 •  サーバ上のContainerの 管理理を⾏行行う –  要求に答えてContainerを 起動する
  38. 38. 38 YARN:  Container •  スレーブのリソースが切切 り出されたもの •  NMによって起動される •  実⾏行行⽅方式 –  DefaultContainerExecutor •  プロセス –  LinuxContainerExecutor •  cgroups –  DockerContainerExecutor •  Docker
  39. 39. 39 YARN:  ApplicationMaster •  ジョブ全体を管理理する Container –  旧JobTrackerの様な存在 –  ジョブ毎に1つのAM •  ジョブを分散処理理する Container全体の進捗管 理理や監視を⾏行行う
  40. 40. 40 YARNがもたらしたもの •  クラスタのリソース管理理の抽象化 –  同様のものに、Mesos,  Amazon  EC2  Container  Service等がある   •  分散処理理実⾏行行フレームワーク –  実際の分散処理理の開発に注⼒力力できる –  YARN対応すれば全てをマルチテナント実⾏行行できる •  YARN上のフレームワークも –  Tez:  DAG処理理を⾼高速にYARN上で実⾏行行する(詳細は後で) –  Twill:  YARNアプリを簡単に書ける –  Slider:  コード変えずに⻑⾧長期起動アプリをYARN上で動かせる
  41. 41. Tezの概要
  42. 42. 42 Tezとは? •  YARN上でDAG処理理を⾼高速実⾏行行するフレーム ワーク •  Directed  Acyclic  Graph  (DAG) –  Vertex(頂点):  データ処理理を表す •  Map,  Reduce,  Joinなど –  Edge(辺):  データの流流れを表す •  ProducerからConsumerへ •  SQL等の分散処理理はDAGで書ける –  DAGに変換できればTezで実⾏行行できる
  43. 43. 43 Tezを利利⽤用したアプリケーション例例 •  Hive,Pig,Cascading •  MRより処理理速度度向上 –  処理理の最適化 –  中間結果をHDFSを介 さず渡す –  Containerを再利利⽤用 –  Sessionでインタラク ティブ処理理を⾼高速に
  44. 44. ORC  File  /  Parquetの概要
  45. 45. 45 古典的なHiveのファイルフォーマット •  TEXTFILE –  1⾏行行ずつテキストで保存する(CSVファイルも⼀一つの⽅方式) •  SEQUENCEFILE –  1⾏行行ずつバイナリで保存する →  いずれも⾏行行指向フォーマット •  1カラムのSELECTでもレコード全体を読む –  カラムが多いと無駄が増える
  46. 46. 46 ORC  File  /  Parquet •  列列指向ファイルフォーマット –  カラム毎にデータをまとめて保存する –  特定の列列を扱う処理理ではファイル全体を読む必要がない •  Optimized  Row  Columnar(ORC)  File –  Stinger  Projectで実装、RCFileの後継 •  Parquet –  Twitter/Clouderaからの提案 –  GoogleのDremel論論⽂文から発想を得ている
  47. 47. 47 ORC  Fileとは •  Stripeという単位で⾏行行をグループ化 –  それぞれにIndexとFooterがつく –  Indexにはmin/max等の値と、Row   Dataのポジションが⼊入っている •  Fileの最後にメタデータが⼊入っている –  Footerにはファイル全体の配置や型情報、 ⾏行行数や列列毎の統計情報が⼊入っている •  Hiveがデータを効率率率よく保存するた めのフォーマットとして設計されて いる
  48. 48. 48 Parquetとは •  ColumnChunkという単 位で列列指向で保存 –  Thriftでシリアライズ •  ColumnChunkの集合と してRow  Groupに分割 •  ファイルの最後にメタ データが保存される •  基本的にはORCと似た形
  49. 49. 49 列列指向フォーマットを使うメリット •  特定列列のみの読み書きが効率率率的 –  ビッグデータ分析では全列列を使うことは稀 –  単純な統計データならメタデータのみで完結する •  列列毎には似たデータが続くので圧縮効率率率が良良い •  ⾏行行毎にグループ化されているので1⾏行行のデータ は1つのファイルに収まっている →  Hive  0.13ではORC/Parquet共に利利⽤用可能
  50. 50. 50 HiveでのORC  File/Parquetの使い⽅方 •  テーブル定義で指定 するだけ •  あとは何も意識識しな くて良良い CREATE TABLE t ( col1 STRING, … ) STORED AS [ORC/PARQUET]; INSERT INTO t (…); SELECT col1 FROM t;
  51. 51. 51 Hadoop/Hiveエコシステムまとめ •  SQL的な⾔言語でビッグデータを扱うことがデ ファクトに –  列列指向フォーマットでより効率率率化 •  Hadoop2は全ての計算がYARN上で動く –  マルチテナント処理理が⾮非常に簡単に •  Hive⾃自体も⾼高速化・⾼高機能化を続けている •  これら全ての恩恵がAmazon  EMRで享受可能
  52. 52. Hive以外の分散SQL実⾏行行環境
  53. 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. 54 Hiveとの親和性 •  Metastoreをsync/ shareしている –  Hiveで作ったテーブルを そのまま利利⽤用可能 •  Impala,  Spark  SQLは HiveQL互換 –  Presto,  DrillはANSI   SQL対応 →同じデータを異異なるエ ンジンから処理理できる Metastore HDFS Amazon S3 テーブル定義を 共有 スキーマを利利⽤用しつつ データにアクセス
  55. 55. Presto概要
  56. 56. 56 Prestoとは? •  MPP  SQLエンジンの1つ •  ANSI  SQL準拠のクエリ⾔言語 •  独⾃自のクラスタでSQLの⾼高速分散実⾏行行に特化 –  メモリ上でデータをやり取り –  今のところYARN等の対応は無い •  MySQLやPostgreSQL等にもクエリが可能 –  異異なるデータソースをJOINすることも可能
  57. 57. 57 Prestoのアーキテクチャ •  Coordinator –  マスター的役割 –  クエリを受け付け、実 ⾏行行計画を⽴立立てる •  Worker –  スレーブ的役割 –  Coordinatorからタス クが割り振られる Amazon S3
  58. 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. 59. まとめ
  60. 60. 60 Amazon  EMRでビッグデータ分析を始めよう! •  ビッグデータ分析に必須な環境がAWSなら簡単 に⼿手に⼊入る –  Amazon  EMRで分散計算環境+ソフトウェア –  Amazon  S3で堅牢牢な巨⼤大ストレージ –  その他も沢⼭山のビッグデータを⽀支えるサービスがあります •  難しいことを覚える前に、まずは試してみま しょう!

×