Hive-sub-second-sql-on-hadoop-public

Apache Hive
Hadoop上のSub-second SQL
Yifeng Jiang
Solutions Engineer, Hortonworks Japan
2015/10/14
© Hortonworks Inc. 2011 – 2015. All Rights Reserved

アジェンダ
•  Hiveユースケース#1: 超⼤量データの⾼並列処理
•  Hiveユースケース#2: Hive LLAPによるオンラインレポーティング

© Hortonworks Inc. 2015. All Rights Reserved
Hiveユースケース#1:
超大量データの高並列処理
Page 3 © Hortonworks Inc. 2011 – 2015. All Rights Reserved

ユースケース #1
バッチレポーティング
超巨⼤なデータセット
•  １３ヶ⽉、５千億⾏以上
•  毎⽇１３億⾏が追加
⾼いスループットが求められます
•  ⼀⽇ 100,000 レポート
•  15,000クエリを１時間以内で完了しなけ
ればならない
Input Dataset

Hiveチューニング
４つの Hive チューニングポイント
•  パーティション
•  データロード
•  クエリ実⾏
•  並列のためのチューニング

パーティション
パーティションの数を最⼤化
•  パフォーマンスにとって基本的かつ最も重
要なポイント
•  必要なデータのみ読込み
合計数千パーティション以下になるように
•  Hiveはクエリを早く処理するための適切
な数
CREATE TABLE access_logs (
host string,
path string,
referrer string,
…
) PARTITIONED BY (
site int,
ymd date
)

データロード
データをORC形式のHiveテーブルにロード
３つの主なORCパラメータ
•  ファイルシステムのブロックサイズ:
256MB
•  ストライプサイズ: 64MB
•  圧縮: ZLIB
•  ZLIBは最近のHiveバージョンには⾼度に最適化さ
れている

データロード
ORCファイルは⼗分に⼤きいことを確認
•  可能なら１〜１０HDFSブロックぐらい
•  たくさんの reducers がすべてのパーティションへの書込みを避ける
•  Optimize sort dynamic partitioning を有効に
•  あるいは DISTRIBUTED BY 句を使う
•  細かいコントロールがきくため DISTRIBUTED BY を選んだ
INSERT INTO orc_sales PARTITION ( country ) SELECT FROM daily_sales
DISTRIBUTE BY country, gender;

クエリ実⾏
クエリ実⾏は最終的⼀連の組合せ
•  クライアントの実⾏ [ 正しくやれば 0s ]
•  オプティマイゼーション [HiveServer2] [~ 0.1s]
•  HCatalog問合せ [Hcatalog, Metastore] [ hive 0.14 は⾮常に早い ]
•  Application Master 作成 [4-5s]
•  コンテナ割当 [3-5s]
•  クエリ実⾏
YARN and HDFS
HiveServer2
Server #1
Client
Running testing tool
N connections
N connections
Metastore Metastore DB
HiveServer2
Server #2
Tez
AM
Tez
Container
Tez
Container
…

クエリ実⾏
コレクション作成がオーバヘッドが⾼い
•  １つのコレクション接続に⼤量のクエリを実⾏
•  標準なコレクションプールを利⽤
２つの HiveServer2 でクエリを分散
•  HiveServer2 が 8-15 queries/s でボトルネックになった
•  複数の HiveServer2 をAmbariからデプロイ
•  新しいバージョンではクエリの並列コンパイルを対応予定

クエリ実⾏
Tezセッションの再利⽤と暖機運転
•  Tezセッションの再⽣成が５秒以上かかる
•  Tezセッション再利⽤を有効に
•  暖機運転による事前⽣成も可能
•  暖機運転を有効にした場合、フルスピードは実質的に⼀瞬で出せる
Tezコンテナの再利⽤
•  コンテナの作成は３秒かかる
•  コンテナ再利⽤を有効に。短い間キープする。
•  キーは100%利⽤率を実現しながらリソースを無駄にしない

0
10
20
30
40
50
60
70
80
90
100
0
2
4
6
8
10
12
24 48 60 72 84 96 112 136 148 172 184 196 204 216 228
Queries Per Second
Cluster Utilization ( Memory )
並列処理のチューニング
実際のシナリオにとって最も重要なポイント
•  多くのチューニングに無視される場合が多いですが実に重要だ
•  多くの場合、単⼀のクエリは余分リソースの恩恵を受けるが、スループットが低減する
Tezメモリ設定が並列処理チューニングのキー
•  最適なTezメモリ設定で、クラスタのCPU利⽤率が 90% 以上に達成
Cluster UtilizationQueries Per
Second
Query
Concurrency

HiveとImpalaと性能⽐較
Hive性能
•  殆どのSQLレスポンスが２０秒以内
•  ⼤きいクエリは最⼤７０秒
Impala性能
•  多くのSQLが３０〜９０秒かかった
•  ⼤きいクエリが１０分間以上
•  並列度を上げた場合の性能低下が⼤きい
Benchmark Blog
Number of queries by response time

© Hortonworks Inc. 2015. All Rights Reserved
Hiveユースケース#2:
Hive LLAPによるオンラインレポーティング

Hive性能を振返ってみる
Hiveは早い: インタラクティブな応答
•  ベクトル化の SQL エンジン
•  Tez 実⾏エンジン
•  ORC カラム型ファイルフォーマット
•  コストベースオプティマイザ (COB)
Hive 0.10
バッチ処理 100-150x 速度アップ
Hive 0.14
インタラクティブ
処理
(５秒)

Hiveユースケース#2
オンラインレポーティング
•  インタラクティブなオンラインレポート
•  巨⼤なデータセット
•  低レイテンシ：秒以下（sub-second）〜数秒（超巨⼤なデータの場合）
•  ⾼い並列度

Hive LLAP
HDFS
LLAPプロセスが複数のノードに実⾏し、Tezタスクを加速させる
Node
Hive
Query
Node NodeNode Node
LLAP LLAP LLAP LLAP
LLAP = Live Long And Process

Hive LLAP – 主な利点
パフォーマンスの利点
•  起動時間の短縮
•  データキャッシュ
•  常時稼働のため最適化しやすい： JIT、並列 I/O、など

LLAPクエリ実⾏
•  クライアントがHive Serverにクエリを投げ
る
•  Hiver Serverがクエリコンパイルや最適化を
行う
•  クエリ毎に１つのTez AMが独自してコー
ディネート
•  実際の処理はHiveオペレーターを利用
•  Tezコンテナは処理実行やデータ転送を行う
•  Hiveがクエリフラグメントの実行場所を決
める (LLAP, Container, AM)
HiveServer
Query/AM
Controller
Client(s) YARN Cluster
AM1
llapd llapd
llapd
Container AM1
Container AM1
llapd
Container AM2
AM2

実世界のLLAP パフォーマンス
0
10000
20000
1 3 5 7 9 11 13 15 17 19 21 23 25 27
⽇時集計クエリ
•  選んだレンジのなか、⼀⽇毎に１つの値を集計
•  平均実⾏時間：LLAP < Phoenix < Tez
Execution Time in Second
0
1
2
3
4
5
6
7
8
Average Tez Max Tez Average LLAP Max LLAP Average
Phoenix
Max Phoenix
One Day
One Week
One Month
One Year
SELECT account, yyyymmdd,
sum(total_imps),
sum(total_click),
...
FROM table_x
WHERE yyyymmdd >= xxx
AND yyyymmdd < xxx
AND account = xxx
...
GROUP BY account, yyyymmdd, ...;

Execution Time in seconds over time range
0
5
10
15
20
25
Average Tez Max Tez Average LLAP Max LLAP
One Day
One Week
One Month
One Year
0
50
100
150
200
250
300
Average
Phoenix
Max
Phoenix
One Day
One Week
One Month
Max Phoenix
Phoenix takes a long time for large ranges
更に細かい集計
•  選んだレンジのなか、⽇付よりも細かい集計
•  すべてのクエリにLLAPが⼀番早い。Phoenixはデータセットが⼤きくなると遅くなる

返す⾏数別のクエリ性能
•  LLAPは⾏数が少ない場合が著しく早い
•  Phoenixはスタートが良かったが、⼤きいデータセットの場合は⾮常に遅い
0
5
10
15
20
25
<100 100<1k 1k<10k 10k<100k >100k
Average Tez
Max Tez
Average LLAP
Max LLAP
0
50
100
150
200
250
300
Average Phoenix
Max Phoenix

まとめ

Hiveの今とこれから
Hive SQL on Hadoopの事実上の標準
•  １つのツールで、バッチやインタラクティブ処理
•  １つのツールで、すべてのビッグデータSQLユースケース
•  ETL、レポーティング、BI、ディープ分析など
•  LLAP が実現するSub-second Hive
•  実世界の超巨⼤スケールで証明されたパフォーマンス

Hive-sub-second-sql-on-hadoop-public

More Related Content

What's hot

Similar to Hive-sub-second-sql-on-hadoop-public

More from Yifeng Jiang

Hive-sub-second-sql-on-hadoop-public