Cloudera impala

Impalaの導入と検証
2012/11/26
Hadoopソースコードリーディング第13回

外道父@GedowFather
Copyright © DRECOM Co., Ltd All Rights Reserved. 1

導本と
入
し
番っ
環く CDH4？
て境に
あ
る
に
Impala？
ぜ
！


自己紹介


自己紹介

■私は
外道父@GedowFather
■所属
ドリコム
■職種
インフラエンジニア
■ブログ
http://blog.father.gedow.net/
Copyright © DRECOM Co., Ltd All Rights Reserved.
4

目次

1. 導入のコツ
2. ベンチマーク vs
3. 運用のミソ
4. 耐障害性
6

はじめに


飛説おまえら
ば明 Cloudera
すは
ぜ Impala
！知ってる
よな？


Cloudera Impalaの情報源

Tech Blog
http://linux.wwing.net/WordPress/
@kernel023

御大がまとめてくれてるから
ありがたく音読するんだぞ！

9

ビヘおまえら
ビイ
っヘもちろん
てイ CDH4
る
？導入ってる
よな？


CDH3からCDH4へのアップグレード

@GedowFather

外道父の匠
How to upgrade from CDH3 to CDH4 for Debian
http://blog.father.gedow.net/2012/08/31/how-to-upgrade-from-cdh3-to-cdh4-for-debian/

CDH4しか impala 使えないんだから
四の五の言わずにアップグレードせい！

11

導入


CentOS 6.2の場合

 GitHub :: cloudera / impala
https://github.com/cloudera/impala/
の README.md を見ればできる！

 Installing Impala – Cloudera Support
https://ccp.cloudera.com/display/IMPALA10BETADOC/Installing+Impala

 Cloudera Manager を使う
 yum を使う

RedHat系は
イージーモード

13

Debian Squeezeの場合

 How to install Cloudera Impala (Beta) on Debian
http://blog.father.gedow.net/2012/11/06/how-to-install-cloudera-impala-beta-on-debian/

外道父による３時間でできたら御の字な導入手順！

 Cloudera does not support yet
 試されるビルドセンス
 信じられるのは自分のみ

Debian系は
クソゲー

14

インストールの重要ポイント
 Dependsパッケージのインストール
 Thrift 7.0 のコンパイル
 LLVM + CLANG 3.0 のコンパイル
 thirdpartyソースの用意
 bin/impala-config.sh に必要なバージョンが書いてある
 SRPMを解凍するか ./download_thirdparty.sh を実行
 ビルドを実行
 ./buildall.sh や ./build_public.sh （やればわかるさ）
 ビルド中のエラー出力を解決しては再ビルド
 grep –r しまくり
 bash / cmake / c++ ファイルを見る

15

Debianパッケージ化の要点

 Depends パッケージ
libboost-thread1.42.0, libboost-regex1.42.0,
libboost-date-time1.42.0, libmysql-java,
sun-java6-jre, sun-java6-bin, sun-java6-jdk

 impalaユーザ作成
addgroup --system --quiet impala
adduser --quiet --system --no-create-home ¥
--home /usr/lib/impala --ingroup impala impala

 リンクで不足を補う
ln -nfs /usr/lib/libstdc++.so.6.0.15 /usr/lib/libstdc++.so.6
ln -nfs /usr/lib/jvm/java-6-sun-1.6.0.26/jre/lib/amd64/server/libjvm.so /usr/lib/libjvm.so

 ログとpidのディレクトリ
mkdir /var/log/impala /var/run/impala
chown impala:impala /var/log/impala /var/run/impala

16

Debianパッケージ化で楽な運用
 詳細ログのON/OFF
/etc/default/impala にログレベル環境変数を追加
export GLOG_v=0
1にすると /tmp/impala* や /var/log/impala に詳細が記録される

 NameNodeの自動指定
実際の運用におけるデーモンプロセスは
impalad -nn=host-of-namenode -nn_port=8020
initスクリプトで xmllint [in libxml2-utils] を用いて
core-site.xml から抜き出して指定するように改良

 impala-state-store の自動起動／停止
 impalad 起動前に impala-state-store が起動している必要がある
 プロセス名が impala-state-st なので注意
ps -C impala-state-st --no-heading || ¥
/bin/bash -c "/usr/bin/impala-state-store &“

 ログローテート
 設定：/etc/logrotate.d/impala
 ログファイル：/var/log/impala/impala.log
17

ベンチマーク


データ項目の説明

 X軸
データサイズ：倍々の容量と行数（ブロックサイズ：128MB）
ファイル数：容量100MB固定でデータファイル数を倍々
 Y軸：処理時間（秒）
Hive CPU ： Hiveの全javaプロセスのCPU処理時間合計
Hive Real ： time hive -e による実動時間
Impala CPU ： planner impaladプロセスのCPU処理時間
Impala Real ： time impala-shell -q による実動時間

 ジョブ／Mapper／Reducerの数
# of Jobs ： Hiveにおけるジョブの数
# of Mappers ： Hiveにおける全ジョブのMap数の合計
# of Reducers：Hiveにおける全ジョブのReduce数の合計

19

クエリとデータの種類
 全データ取得
SELECT * FROM main_table > /dev/null
 カウント
SELECT COUNT(*) FROM main_table
 結合
SELECT m.num FROM main_table m
JOIN join_table j (m.num = j.num)
ORDER BY m.num DESC LIMIT 1

 メインテーブル
SELECT * と SELECT COUNT(*) で単発利用
 結合用テーブル
JOINで利用。メインテーブルの 1/10 のサイズ
 どちらも TextFile & Raw
20

X軸：データサイズ
SELECT * ～


SELECT * … > /dev/null
360

320
※CPU time は計測不能なので省略
280

240

200
秒
160 Hive Real

120

80

40

0
10 20 40 80 160 320 640 1,280 2,560 5,120 (MB) : Main Size
52,000 102,000 204,000 408,000 820,000 1,620,000 3,265,000 6,520,000 13,000,000 26,000,000 # of Main Rows

 最小でも始動時間で10秒かかる
 ほぼサイズと実動時間が比例した形

22

SELECT * … > /dev/null
360

320
※1280MB～挙動が怪しくなったため、
280 SELECT num … に切り替えた
恐らく impala-shell 側のSWAPが原因
240

200
秒
Impala CPU
160
Impala Real

120

80

40

0
10 20 40 80 160 320 640 1,280 2,560 5,120 (MB) : Main Size
52,000 102,000 204,000 408,000 820,000 1,620,000 3,265,000 6,520,000 13,000,000 26,000,000 # of Main Rows

 最小だと1秒以内に完了する
 ほぼサイズと実動時間が比例する形
 CPU時間の伸びが急激になり、CPU時間と実働時間が逆転する
Impala Cross 現象 … impaladのメモリ量が関係？
23

vs SELECT * … > /dev/null
360

320

280

240

200
秒 Hive Real
160 Impala CPU
Impala Real
120

80

40

0
10 20 40 80 160 320 640 1,280 2,560 5,120 (MB) : Main Size
52,000 102,000 204,000 408,000 820,000 1,620,000 3,265,000 6,520,000 13,000,000 26,000,000 # of Main Rows

 途中で形勢逆転したが大差はない
 impalad or impala-shell (Mem : 2GB) のメモリ量が原因と予想
 impalaは大量の標準出力の処理が効率的ではない？
24

SELECT COUNT(*) ～


SELECT COUNT(*) …
240 30

220

200 25

180

160 20
# of Jobs
140
# of Mappers
秒 120 15
# of Reducers
100
Hive CPU
80 10
Hive Real
60

40 5

20

0 0
10 20 40 80 160 320 640 1,280 2,560 5,120 (MB) : Main Size
52,000 102,000 204,000 408,000 820,000 1,620,000 3,265,000 6,520,000 13,000,000 26,000,000 # of Main Rows

 実動時間はデータサイズよりも緩やかな傾斜
 CPU時間はMap数に比例
 負荷分散により実動時間の短縮を見て取れる Hive Cross 現象

26

SELECT COUNT(*) …
240 30

220

200 25

180

160 20
# of Jobs
140
# of Mappers
秒 120 15
# of Reducers
100
Impala CPU
80 10
Impala Real
60

40 5

20

0 0
10 20 40 80 160 320 640 1,280 2,560 5,120 (MB) : Main Size
52,000 102,000 204,000 408,000 820,000 1,620,000 3,265,000 6,520,000 13,000,000 26,000,000 # of Main Rows

 あるデータサイズまでは激速
 それ以降は極端なCPU時間増加と、データサイズに比例した実動時間
 impalad のメモリRSSは 600～1000MB までしか増加しない
 impalad のメモリ設定を知る必要があるがオプションにない
27

vs SELECT COUNT(*) …
240 30

220

200 25

180
# of Jobs
160 20
# of Mappers
140
# of Reducers

秒 120 15 Hive CPU
100 Hive Real

80 10 Impala CPU
Impala Real
60

40 5

20

0 0
10 20 40 80 160 320 640 1,280 2,560 5,120 (MB) : Main Size
52,000 102,000 204,000 408,000 820,000 1,620,000 3,265,000 6,520,000 13,000,000 26,000,000 # of Main Rows

 あるデータサイズ以下ならば impala の圧勝
 恐るべし MapReduce のオーバーヘッド
 それ以降はどちらもCPU時間が逆転する
 特大サイズになると単サーバ処理である impala が苦しくなりそう
28

～ JOIN ～ ORDER BY ～


JOIN … ORDER BY … DESC LIMIT 1
600 35

550
30
500

450
25
400

350 # of Jobs
20
# of Mappers
300
# of Reducers
秒
250 15 Hive CPU
200 Hive Real
10
150

100
5
50

0 0
10 20 40 80 160 320 640 1,280 2,560 5,120 (MB) : Main Size
52,000 102,000 204,000 408,000 820,000 1,620,000 3,265,000 6,520,000 13,000,000 26,000,000 # of Main Rows
1 2 4 8 16 32 64 128 256 512 (MB) : Join Size
5,400 10,800 21,200 43,000 86,000 170,000 340,000 680,000 1,365,000 2,700,010 # of Join Rows

 COUNT(*)と同じ形
 JOIN分のMapReduce数が増えて、CPU時間もそれに連動
 JOINは遅い、と読み取れるものはない

30

JOIN … ORDER BY … DESC LIMIT 1
600 35

550
30
500

450
25
400

350 20
# of Jobs
300
秒 # of Mappers
250 15
# of Reducers
200 Impala CPU
10
150 Impala Real
100
5
50

0 0
10 20 40 80 160 320 640 1,280 2,560 5,120 (MB) : Main Size
52,000 102,000 204,000 408,000 820,000 1,620,000 3,265,000 6,520,000 13,000,000 26,000,000 # of Main Rows
1 2 4 8 16 32 64 128 256 512 (MB) : Join Size
5,400 10,800 21,200 43,000 86,000 170,000 340,000 680,000 1,365,000 2,700,010 # of Join Rows

 COUNT(*)と同じ形
 HiveのMaps数に対してCPU時間の傾斜が緩い
 JOINは遅い、と読み取れるものはない

31

vs JOIN … ORDER BY … DESC LIMIT 1
600 35

550
30
500

450
25
400
# of Jobs
350 20
# of Mappers
300
# of Reducers
秒
250 15
Hive CPU
200 Hive Real
10
150 Impala CPU
Impala Real
100
5
50

0 0
10 20 40 80 160 320 640 1,280 2,560 5,120 (MB) : Main Size
52,000 102,000 204,000 408,000 820,000 1,620,000 3,265,000 6,520,000 13,000,000 26,000,000 # of Main Rows
1 2 4 8 16 32 64 128 256 512 (MB) : Join Size
5,400 10,800 21,200 43,000 86,000 170,000 340,000 680,000 1,365,000 2,700,010 # of Join Rows

 CPU・実動時間ともに impala が速い
 CPU時間：40.0x ～ 2.5x の差
 実動時間：90.0x ～ 5.0x の差
 Hiveとの総合的な性能差は噂の 2x～10x どころではない
32

X軸変更のお知らせ

 ここからX軸がファイル数になります

 テーブルサイズはブロック分割に影響されな
いよう、100MB 固定(＜ 128MB)

 JOIN用テーブルは 10MB固定です

 枚数簡略のため impala vs Hive 比較グラフ
のみ掲載します

33

X軸：ファイル数
SELECT * ～


vs SELECT * … > /dev/null
18
※データサイズは100MB固定
16

14

12

10
Hive Real
秒
8 Impala CPU
Impala Real
6

4

2

0
1 2 4 8 16 32 64 128 256 512 # of Main files
510,000 255,000 125,000 64,000 32,000 16,000 8,000 4,000 2,000 1,000 # of rows in Main 1file

 1データ100MB が1～512ファイルでさほど影響はない
 CPUも実動時間もせいぜい 1.5x 程度まで

35

SELECT COUNT(*) ～


vs SELECT COUNT(*) …
35 6

30
5

25 # of Jobs
4
# of Mappers
20 # of Reducers

秒 3 Hive CPU
15 Hive Real

2 Impala CPU
10 Impala Real

1
5

0 0
1 2 4 8 16 32 64 128 256 512 # of Main files

 どちらも実動時間への影響は少ない
 HiveのCPU時間はMap数に引きずられて増加する
 impalaのCPU時間は増える傾向があるも、なぜか256ファイル以降は
安定して減少した

37

～ JOIN ～ ORDER BY ～


vs JOIN … ORDER BY … DESC LIMIT 1
100 12

90
10
80

70
8 # of Jobs
60 # of Mappers

50 6 # of Reducers
秒 Hive CPU
40
Hive Real
4
30 Impala CPU
Impala Real
20
2
10

0 0
1 2 4 8 16 32 64 128 256 512 # of Main files
1 2 4 8 16 32 64 128 256 512 # of Join files
53,500 27,000 13,500 6,500 3,200 1,600 800 400 200 100 # of rows in Join 1file

 CPU時間がMap数に引きずられて最大3倍増加
 どちらも実動時間は1.5倍以内に収まる
 impala はファイル数にあまり影響されないといえる

39

速い理由


impalaがHiveより速い理由を予想

1. MapReduce開始の
オーバーヘッドがない
2. 処理が最適化されて
CPU利用量が減少
3. メモリ主体の処理
4. HDFSファイルの
読み込み最適化

41

HDFSファイルの読み込み最適化
 dfs.client.read.shortcircuit
HDFSファイルの短絡的な読み込みを許可している

 dfs.block.local-path-access.user
impala ユーザに許可

 dfs.client.read.shortcircuit.skip.checksum
チェックサム処理を省略してる

42

懸念点


CPUの限界
240

220

200

180
◯ 30

25

# of Jobs
160 20
# of Mappers
140
# of Reducers

秒 120 15 Hive CPU
100 Hive Real

80 10 Impala CPU
Impala Real
60

40 5

20

0 0
10 20 40 80 160 320 640 1,280 2,560 5,120 (MB) : Main Size
52,000 102,000 204,000 408,000 820,000 1,620,000 3,265,000 6,520,000 13,000,000 26,000,000 # of Main Rows

 Planner impalad が全処理をしており、Executer impalad は全く
動かないため、１サーバのCPU能力が最大速度となる
 分散処理はHiveの方が確実なので、データサイズが超巨大になった時
にHiveが勝る可能性が高い
44

CPU処理の偏り

 クエリやデータサイズによっては、impaladの
CPU利用率が 30～80%しか動かない時や、
1000～1500% 稼働する場合がある

 特にデータサイズが大きい時に見られるため、
Disk readがボトルネックになってCPU待機が発
生しているかもしれない
（iowaitは観測できていないのでネットワーク転送？）

45

Executer impaladのCPU処理

 基本的にクエリを受けた impalad以外の impaladは
ほとんど稼働しない

 まれに Executer impalad と impala-state-store の
異常なCPU利用率を観測できた
impalad : 18,000% / s
impala-state-store : 6,200% / s

 出現条件が不明だが、まともな処理によるものではな
いことは確かで、注意が必要

46

impalad のメモリ使用量

 impalad 起動時はメモリRSSは 300MB

 VSLは 16GB

 ベンチマーク後（最大5GB + 0.5GBのJOIN）
 Planner impalad のRSSは最大 1.2GB まで増加
 Exec impalad は300MBのまま
 JOIN側が大きい場合が怪しいらしい

 impalad のメモリ設定が無いので注意
 SWAP
 OOM Killer先生発動

 最低でもMem2GBは空きが必要っぽい

47

運用


TextFile + GZIP が欲しいです・・・

@GedowFather

外道父の匠
Cloudera Impala (Beta) File format & Compression codec
http://blog.father.gedow.net/2012/11/12/cloudera-impala-file-format-compression-codec/

SequenceFileは圧縮対応してるのに！
TextFileの解凍くらいさせてくれよっ！

49

refreshコマンドの仕様
 Hiveで作成した新規テーブルは refresh しないと見えない
 SELECTするとデータファイルパスをキャッシュする
 refreshの効果
 テーブルリストを再取得する
 キャッシュしたデータファイルパスを削除する（仮）
 impalad毎（SLAVE毎）に打つ必要がある
 データファイルパスを記憶する弊害
 INSERT ～ OVERWRITE INTO の上書きのみは1fileだから大丈夫
 データ追加の場合 refresh しないと追加分を参照できない
 追加 => OVERWRITE は2つ目以降のファイルを参照できずエラー

ジョブの最初に必ず
refresh を仕込むこと

50

HiveQLとの互換性

 field as alias が利用できないので、ORDER BY alias ではなく
ORDER BY COUNT(*) になる

 ORDER BY には LIMIT をつけないとエラーになる
ERROR: ORDER BY without LIMIT currently not supported

 末尾にカンマ ; はいらない

51

出力形式

 int の小数点
Hive : 1234.0
impala : 1234

 int の指数
Hive : 1.23456E7
impala : 12345678
 tab, 改行は一緒

52

ログ

[ログレベル（仮）]
 export GLOG_v=0
0 ： WARN以上が記録される
1 ： INFOも記録される

[保存パス]
 /var/log/impala/impala.log
 /tmp/impala-state-store.$HOSTNAME.$USER.INFO.*
 impala-state-store.INFO が最新へのリンク
 /tmp/impalad.$HOSTNAME.$USER.[INFO|WARNING|ERROR].*
 impalad.[INFO|WARNING|ERROR] が最新へのリンク

53

impalad オプション
--dump_ir=false --statestore_subscriber_timeout_seconds=10
--module_output= --statestore_max_missed_heartbeats=5
--be_port=22000 --statestore_num_server_worker_threads=4
--classpath= --statestore_suspect_heartbeats=2
--hostname=hostname-of-imapald --state_store_host=localhost
--ipaddress=127.0.0.1 --state_store_port=24000
--keytab_file= --state_store_subscriber_port=23000
--planservice_host=localhost --kerberos_reinit_interval=60
--planservice_port=20000 --kerberos_ticket_life=0
--principal= --sasl_path=/usr/lib/sasl2:/usr/lib64/sasl2:/usr/local/lib/sasl2
--randomize_scan_ranges=false --web_log_bytes=1048576
--port=20001 --log_filename=impalad
--num_disks=0 --rpc_cnxn_attempts=10
--num_threads_per_disk=1 --rpc_cnxn_retry_interval_ms=2000
--read_size=8388608 --webserver_interface=
--enable_webserver=true --webserver_port=25000
--use_statestore=true --flagfile=
--nn=hostname-of-namenode --fromenv=
--nn_port=20500 --tryfromenv=
--serialize_batch=false --undefok=
--status_report_interval=5 --tab_completion_columns=80
--be_service_threads=64 --tab_completion_word=
--default_num_nodes=1 --help=false
--fe_port=21000 --helpfull=false
--fe_service_threads=64 --helpmatch=
--load_catalog_at_startup=false --helpon=
--use_planservice=false --helppackage=false
--helpshort=false
--helpxml=false
 INFOで /tmp/ に記録 --version=false
 メモリ関連がない…
 ***_threadsでCPU抑えられる？
54

耐障害性


アーキテクチャ
Cloudera Impala: Real-Time Queries in Apache Hadoop, For Real
En: http://blog.cloudera.com/blog/2012/10/cloudera-impala-real-time-queries-in-apache-hadoop-for-real/
Ja: http://www.cloudera.co.jp/blog/cloudera-impala-real-time-queries-in-apache-hadoop-for-real.html

Executer Planner Executer
とでも呼んでおく
56

障害時の挙動
 Plannerのダウン
 既にダウンしているimpaladへの接続
Could not connect to host-of-impalad:21000
 接続後にダウンしてからクエリ発行
Error communicating with impalad: TSocket read 0 bytes
 クエリ実行中にダウン
Unknown Exception : [Errno 104] Connection reset by peer
Query aborted, unable to fetch data
Could not execute command: select count(*) from …
 Executerのダウン
 ダウン後のクエリ発行（Planner以外全てダウンさせた）
 クエリが正常終了する … Why?
 クエリ実行中にダウン（同上）
 クエリが正常終了する … Why?

 Planner -> remote Executer は利用していない？
 Planner はHDFSデータかき集めて local Executer で処理してるだけ？

57

耐障害性の第一歩～ impalaクエリの再試行

Client

impalad
HDFS + NM

結果がエラーになったら
再試行する仕組みにする
58

構成案その１ – SSH Proxy

① localのproxyにSSH接続

Client ② proxyは sshd と impalad
proxy のヘルスチェックを行う

sshd sshd sshd sshd sshd
impalad impalad impalad impalad impalad
HDFS + NM HDFS + NM HDFS + NM HDFS + NM HDFS + NM

③ SLAVEは localhost の impalad を利用して
impala-shell を実行する

59

構成案その２ – 独自スクリプト

① localのスクリプトにクエリを渡して実行

Client ② hdfs-site.xml からSLAVE
script リストを取得してランダムに
impalad に接続

impalad impalad impalad impalad impalad
HDFS + NM HDFS + NM HDFS + NM HDFS + NM HDFS + NM

60

構成案その３ – CPUリスク回避

 NodeManagerを停止する
Client
 impalad を入れる
proxy

 impalad は入れずに通常運用

sshd sshd
impalad impalad
HDFS + NM HDFS + NM HDFS + NM
HDFS HDFS

一部の NodeManger を停止し、
MapReduceジョブと impalaジョブを分担する

61

まとめ


まとめ

 インストールは頑張ってね

 負荷分散・再試行は自前で構成 Cloudera
する必要がある Impala

 中規模（MB単位）までは
impala が安定して速い

 大規模（GB以上）でも速い
が、負荷分散／耐障害性の点で
※画像はイメージです
Hiveが有利になる可能性が高い

63

落ネはこれ読んだら
ちーい CDH4と
たム、 Impalaを
ぁノ
！ー導入しないと
ド呪われるぞ…

fin

Cloudera impala

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Destacado

Destacado (20)

Similar a Cloudera impala

Similar a Cloudera impala (20)

Cloudera impala