Impalaチューニングポイントベストプラクティス

Impalaチューニングポイント
ベストプラクティス
ヤフー株式会社
マーケティングソリューションカンパニー
開発本部業務開発部
杉⼭山朋広

⾃自⼰己紹介
杉⼭山朋広
（すぎやまともひろ）

2002年年ヤフー株式会社⼊入社
Yahoo!ウォレットやYahoo! JAPAN IDなどのIDサービスを経て
現在は広告関連システムを担当

Hadoopの経験は2012年年ごろから
Copyright (C) 2014 Yahoo Japan Corporation. All Rights Reserved. 無断引⽤用・転載禁⽌止

アジェンダ
単⼀一クエリがどれくらいの速度度か
ストレージフォーマット
パーティションとブロックサイズ

並列列クエリをどれくらい処理理できるか
並列列アクセスの注意点

その他
Hive,MapReduceのチューニング

Impalaについて
HDFSを直接readする低レイテンシなSQLエンジン

Evolution of Impala #hcj2014
http://www.slideshare.net/Cloudera_̲jp/evolution-‐‑‒of-‐‑‒impala-‐‑‒hcj2014

検証データ
以下のようなファイルをピックアップ
⾏行行数11億⾏行行/⽇日
サイズ12GB(gz)/⽇日
形式tsvファイル
蓄積期間396⽇日(13カ⽉月)
総⾏行行数11億⾏行行/⽇日 × 396⽇日＝約4,300億⾏行行
総サイズ12GB/⽇日 × 396⽇日＝約4,500GB

データ構造
⽇日付＞ID＞属性でユニーク
YYYYMMDDIDdevice...countrank…
2014010114135382791...863123…
2014010114135383201...128414…
2014010114135408703...413638…
：：::：：：
2014123114135382792...343862…

検証環境
以下の30ノードで検証環境を構築
Cloudera Expressをインストール
CPU6 core x 2
RAM64 G
DISK3T x 4
Nodes30 nodes (4 x Master + 26 x Slave)
CDH5.1

ストレージフォーマット

ストレージフォーマットとは
Hadoopの処理理に最適化されたフォーマット
RCFILE
SEQUENCEFILE
AVRO
PARQUET
デフォルトでTEXTのGzipやLZOがサポートされない
＝最初にストレージフォーマットを決める必要がある

主要ストレージフォーマット⽐比較
PARQUETを採⽤用
FormatCODECsizeCreatecount(*)
TEXTGzip11.4 GB-‐‑‒not support
AVROSnappy14.7 GB280 s1340 ms
SEQUENCEFILESnappy25.2 GB260 s1150 ms
RCFILESnappy16.4 GB270 s830 ms
PARQUETSnappy12.9 GB300 s730 ms
Hiveで作成・Impalaでカウント
1⽇日分（Gzip12GB・11億⾏行行）をサンプル

パーティションとブロックサイズ

ブロックサイズの最適化
HDFSのブロックサイズの他に
PARQUETのブロックサイズ設定もある

適切切な値を設定する事で
レスポンスの向上が期待できる

パーティションによる分割
特定のルールでデータをグループ化して別々に保存
透過的に１テーブルとして扱われる
HDFS
DIR
MyTable
HDFS
DIR2
HDFS
DIR1
MyTable
dt=20140101
dt=20140102
:
dt=20141231
select * from
MyTable
select * from
MyTable

チューニング
パーティションによりファイルの分割度度を調整
64分割
128分割
256分割

必ずHDFSのブロックサイズの⽅方を⼤大きくする
dfs.block.size ＞ parquet.block.size

検証クエリ（1⽇日分）
11億⾏行行→3,000⾏行行の絞り込み
サイズは300K程度度
select ID, device, sum(count), sum(...)
from mytable
where ID = 1413538320
group by ID, device;

ブロックサイズ⽐比較
検証データ1⽇日分（Gzip11.4GB）を分割数を変えて⽐比較
⼤大中⼩小
ファイル数64128256
HDFSブロックサイズ512 MB256 MB128 MB
PARQUETブロックサイズ256 MB128 MB64 MB
平均ファイルサイズ174 MB83 MB40 MB
最⼩小ファイルサイズ84 MB36 MB11 MB
最⼤大ファイルサイズ284 MB180 MB110 MB
最⼤大ファイルの応答時間6.11 s4.32 s3.05 s

検証クエリ（13ヶ⽉月分）
256分割で13ヶ⽉月分4,300億⾏行行のデータを⽣生成
4,300億⾏行行→3,000⾏行行の絞り込み
サイズは300K程度度
select ID, device, sum(count), sum(...)
from mytable
where ID = 1413538320
group by ID, device;

検証データ全量量テスト
検証データ全量量4,300億⾏行行に対する検証クエリの結果
試⾏行行数応答時間
1回⽬目351.8 s
２回⽬目 12.5 s
3回⽬目 11.7 s
4回⽬目 11.3 s
５回⽬目 11.5 s
メタ情報のリフレッシュ直後だけ5〜～6分かかる

並列列アクセスの注意点

並列列クエリ
Impaladの各ノードに並列列にクエリを発⾏行行
Impalad
Query Planner
Query Coordinator
Query Exec Engine
Impalad
Query Planner
Query Coordinator
Query Exec Engine
Impalad
Query Planner
Query Coordinator
Query Exec Engine
select …
where
ID = 1413538320 and
YYYYMMDD = 20140101
select …
where
ID = 1413538320 and
YYYYMMDD = 20140101
select …
where
ID = 1413538320 and
YYYYMMDD = 20140101

並列列クエリ：結果
20
18
16
14
12
10
8
6
4
2
0
最⼤大25並列列で、5秒程度度の遅延
12345678910111213141516171819202122232425
avg
sec
parallel reqs

遅延の原因
同じブロックへのアクセス集中
Impalad
Query Planner
Query Coordinator
Query Exec Engine
Impalad
Query Planner
Query Coordinator
Query Exec Engine
Impalad
Query Planner
Query Coordinator
Query Exec Engine
blk-‐‑‒X
select …
where
ID = 1413538320 and
YYYYMMDD = 20140101
select …
where
ID = 1413538320 and
YYYYMMDD = 20140101
select …
where
ID = 1413538320 and
YYYYMMDD = 20140101
同じブロックへの並列列クエリは
ホットスポットを⽣生む

並列列クエリの注意点
できるだけ別々のブロックにアクセスする
Impalad
Query Planner
Query Coordinator
Query Exec Engine
Impalad
Query Planner
Query Coordinator
Query Exec Engine
Impalad
Query Planner
Query Coordinator
Query Exec Engine
blk-‐‑‒b
select …
where
ID = 1413530001 and
YYYYMMDD = 20140101
select …
where
ID = 1413530002 and
YYYYMMDD = 20140101
select …
where
ID = 1413530003 and
YYYYMMDD = 20140101
blk-‐‑‒ablk-‐‑‒c

結果⽐比較
20
15
10
5
0
25並列列での遅延を3秒くらい軽減できた
12345678910111213141516171819202122232425
avg
sec
parallel reqs
同ブロックアクセス別ブロックアクセス

Hive,MapReduceのチューニング

Hiveの利利⽤用
Metastoreの作成は⽐比較的⻑⾧長い
（数10分くらい）

MapReduceやOozieで制御

但しHiveMetastoreとImpalaStateStoreの
同期オペレーションが必要
RawData(tsv)
Hive
(MapReduce)
Refresh
ImpalaStateStore
※⼿手オペ

Hiveジョブのエラー
ParquetテーブルをHiveで作成
Hiveジョブのreducerがエラー
Examining task ID: task_1407388082801_0126_r_000014 (and more) from job job_1407388082801_0126
Examining task ID: task_1407388082801_0126_r_000027 (and more) from job job_1407388082801_0126
Task with the most failures(4):
-----
Task ID:
task_1407388082801_0126_r_000009
URL:
http://test1.yahoo.co.jp:8088/taskdetails.jsp?
jobid=job_1407388082801_0126tipid=task_1407388082801_0126_r_000009
-----
Diagnostic Messages for this Task:
Error: Java heap space

原因：メモリ不不⾜足
parquet.block.size
Parquet x 1ファイルあたりの割当メモリ
default : 134,217,728(128MB)

パーティション数分のメモリが必要
クラスタ全体：128MB x 256partitions = 32GB
ノード当たり：32GB ÷ 26nodes = 約1.23GB

初期のメモリ設定値が1GB/ノードだった

対処
以下のパラメータを⾒見見直して解消
mapreduce.map.memory.mb
mapreduce.map.java.opts.max.heap
mapreduce.reduce.memory.mb
mapreduce.reduce.java.opts.max.heap

ブロックサイズの引き下げでもOK
パーティションあたりの平均ファイルサイズが⼩小さい場合
例例）parquet.block.size = 67,108,864

Parquetの作成にはメモリが必要

まとめ

処理理時間のイメージ
Impala：数秒〜～数10秒 ※
MapReduce：数分〜～数時間
HBase：ミリ秒〜～数秒

※）但しリフレッシュ後の初回は数分

並列列クエリの注意点
同⼀一ブロックへの並列列アクセスは避ける

同⼀一クエリを避けてノード数を増やせば
並列列性能が期待できる

向いているサービス

時系列列データの参照系
明細
履履歴情報

今後の課題・関⼼心
どこまでスケールするか？
100 nodes? 1000 nodes?

Impala 2.0

Impala + HBase

ご清聴ありがとうございました

Impalaチューニングポイントベストプラクティス

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (9)

Similar to Impalaチューニングポイントベストプラクティス

Similar to Impalaチューニングポイントベストプラクティス (20)

More from Yahoo!デベロッパーネットワーク

More from Yahoo!デベロッパーネットワーク (20)

Impalaチューニングポイントベストプラクティス