Download as PDF, PPTX
![50
HiveでのORC File/Parquetの使い⽅方
• テーブル定義で指定
するだけ
• あとは何も意識識しな
くて良良い
CREATE TABLE t (
col1 STRING,
…
) STORED AS [ORC/PARQUET];
INSERT INTO t (…);
SELECT col1 FROM t;](https://image.slidesharecdn.com/20150513emr-handson-public-150515050024-lva1-app6892/85/Amazon-Elastic-MapReduce-with-Hive-Presto-50-320.jpg)
More Related Content
![[DI12] あらゆるデータをビジネスに活用! Azure Data Lake を中心としたビックデータ処理基盤のアーキテクチャと実装](https://cdn.slidesharecdn.com/ss_thumbnails/di12-170616053736-thumbnail.jpg?width=640&height=640&fit=bounds)
Similar to Amazon Elastic MapReduce with Hive/Presto ハンズオン(講義)
![[AWSマイスターシリーズ] Amazon Elastic MapReduce (EMR)](https://cdn.slidesharecdn.com/ss_thumbnails/20130925aws-meister-regenerate-emrpublic-130926030316-phpapp01-thumbnail.jpg?width=640&height=640&fit=bounds)
![[20220126] JAWS-UG 2022初頭までに葬ったAWSアンチパターン大紹介](https://cdn.slidesharecdn.com/ss_thumbnails/20220126-anti-220126190603-thumbnail.jpg?width=640&height=640&fit=bounds)
Amazon Elastic MapReduce with Hive/Presto ハンズオン(講義)
- 1. Amazon Elastic MapReduce with Hive/Presto ハンズオン(講義) 2015/5/13 Ryosuke Iwanaga Solutions Architect, Amazon Data Services Japan
- 2.
- 3. 3 ビッグデータの活⽤用 • 在庫情報 • 販売・売上実績 • POSデータ • ユーザの⾏行行動分析 • ゲーム・タイトルの KPI • センサーや⾞車車載ナビ からの⾛走⾏行行情報 GB TB PB ZB EB データ量量の劇的な増加
- 4. 4 AWSが提供するクラウドの特徴 • 事前の投資が不不要 • 従量量課⾦金金制の低価格な利利⽤用コスト • 必要時に必要なリソースを瞬時に調達 • リリースまでの時間を短く、海外展開も迅速に • 本来のビジネスにフォーカスできる
- 5.
- 6.
- 7.
- 8.
- 9.
- 10.
- 11.
- 12. 12 Amazon Elastic MapReduceとは？ • 1クリックでHadoopクラスタが⼿手に⼊入る – 使い終わったらまとめて捨てるのも簡単 – スポットインスタンスを使ったコストカットも • 設定済のアプリケーションがすぐ使える – Application: Hive, Hue, Impalaなど – Bootstrap Action: Presto, Sparkなど • ⾏行行うべき処理理を簡単に設定できる – ジョブが終わったらクラスタを消すところまで⾃自動化
- 13. 13 Task Node Task InstanceGroup 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 InstanceGroupCore 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.
- 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.
- 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.
- 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.
- 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.
- 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で堅牢牢な巨⼤大ストレージ – その他も沢⼭山のビッグデータを⽀支えるサービスがあります • 難しいことを覚える前に、まずは試してみま しょう！