Hive on Tezのベストプラクティス

Copyrig ht © 2017 Yahoo Japan Corporation. All Rig hts Reserved.
2017年9月15日
大竹隼人
Hive on Tezのベストプラクティス

アジェンダ
2
・自己紹介
・Hive on Tezとは
・適用システムについて
・性能改善のために
・安定稼働のために
・最後に

アジェンダ
3
・自己紹介
・最後に

自己紹介
4
大竹隼人
2013年新卒入社
入社以来、広告ログ集計システムの開発、運用を担当
- プロジェクト案件
- システム刷新
- PoC
- CI/CDの導入

アジェンダ
5
・自己紹介
・最後に

Hive on Tezとは
6
Hiveとは
HadoopエコシステムにおけるSQLエンジンの一つ
・SQLに似たHive Query Languageで大量のデータに対して高
速な処理が行える
・DWH向けのソフトウェア

Hive on Tezとは
7
Tezとは
Yarn上で動くデータ処理アプリのための処理エンジン
・Yarnを使ってリソースを管理
・データ処理アプリ向け（Hive,Pigなど）
・MapReduceの教訓を活かしてパフォーマンスの改善

アジェンダ
8
・自己紹介
・最後に

Hadoop
適用したシステム
9
Oracleテーブル
(OLTP)
配信
Data Pipeline
速報用集計
システム
Hiveテーブル
Hdfs
Hdfs
Hiveテーブル
Hdfs
MapReduce
Hive on Tez Sqoop
統計情報を集計するログ集計システム
広告主様

10
速報用の統計情報に求められてるもの
速報用の統計情報
30分毎に最新の統計情報を提供
→ 安定的に性能をだし続ける必要がある

Hadoop
11
Oracleテーブル
(OLTP)
配信
Data Pipeline
速報用集計
システム
Hiveテーブル
Hdfs
Hdfs
Hiveテーブル
Hdfs
MapReduce
Hive on Tez Sqoop
統計情報を集計するログ集計システム
広告主様

12
リリースまでの課題
・性能がでない
・安定的に動かない
・再実行を考慮した作りにできない

13
リリースまでの課題
・性能がでない
・安定的に動かない
・再実行を考慮した作りにできない

アジェンダ
14
・自己紹介
・最後に

性能改善のために
15
課題
ジョブのターンアラウンドタイムについて
・目標の性能が満たせてない
・性能が安定していない

NEW NEW_SAVING SUBMITTED ACCEPTED RUNNING FINAL_SAVING FINISHING
16
原因確認
ジョブのボトルネックを確認
|--------------- ジョブ実行時間 ---------------
>|

17
原因確認
Yarnログ
実行時間 : application_× State change from NEW to NEW_SAVING
実行時間 : application_× State change from NEW_SAVING to SUBMITTED
実行時間 : application_× State change from SUBMITTED to ACCEPTED
実行時間 : application_× State change from ACCEPTED to RUNNING
実行時間 : application_× State change from RUNNING to FINAL_SAVING
実行時間 : application_× State change from FINAL_SAVING to FINISHING
実行時間 : application_× State change from FINISHING to FINISHED

18
原因確認
クエリーのボトルネックを確認
・EXPLAIN
・hive.tez.exec.print.summary

19
原因確認
EXPLAIN

20
原因確認
hive.tez.exec.print.summary=true

21
原因と対策
原因対策
NameNodeの負荷でジョブのSUBMITが遅れている負荷をかけているクエリーのログ出力を停止
リソースを確保できていない時がある常に安定的な性能がでるようにリソースを確保
Inputデータ量が多すぎるデータの再設計
Reduceタスクが遅い Reducer数の調整

22
目標実行時間を満たす並列数を求める
直列時のクエリー実行時間
(CPU_TIME_MILLISの合計時間)
目標実行時間
実行時間
必要なcontainer数 = 直列時のクエリー実行時間 / 目標実行時間

23
並列数から必要なリソースを求める
確保するパーセンテージ =(必要なcontainer数/ 全体のcontainer数 ) * 100
container数
全体のcontainer数
必要なcontainer数

24
データの再設計
一度統計用のInputに特化したテーブルを作成するこ
とでInputレコード数を削減

25
Reducer数の調整
データ量に応じてスケールし、目標実行時間を満たせ
るような並列数にする
・hive.exec.reducers.bytes.per.reducer

26
性能をだすために必要なこと
・ボトルネックを明確にする
・リソースの確保
・Reducerの調整

アジェンダ
27
・自己紹介
・最後に

安定稼働のために
28
課題
正常終了するジョブを運用していくと、失敗
するケースが発生してきた

29
原因
1.Mapper数が過度に上がりリソースを取得できなかっ
た
2.Mapper数が少なく1Mapperで処理できるデータ量を
超えてしまった

30
原因１
対象とするInputデータに対して1Mapperあたりのデー
タサイズが小さすぎた為、Mapper数が過度に上がり
リソースを取得できなかった

31
原因１正常に終了するケース
Inputデータ
Map 1
Map 2
Map n
取得できるリソース

32
原因１エラーになるケース
Inputデータ
Map 1
Map 2
Map m

33
原因2
対象とするInputデータに対して1Mapperあたりのデー
タサイズが大きすぎた為、 Mapperで集約する際に
OutOfMemoryが発生してしまっていた

34
原因2 正常に終了するケース
Inputデータ
Map 1
Map 2
Map n
1Mapで扱えるデータ量

35
原因2 エラーになるケース
Inputデータ
Map 1
Map 2
Map m

36
対策
運用しながら1Mapperが扱うデータサイズを調整する
原因対策
Mapperが過度にあがる 1Mapperが扱う最小のデータ量を調整
tez.grouping.min-size
1Mapperが扱うデータ量が多い 1Mapperが扱う最大のデータ量を調整
tez.grouping.max-size

37
対策
Inputデータ
Map 1
Map 2
Map n

38
安定的に動かすために必要なこと
・1Mapperが扱うデータ量を設定する
・増加するデータ量に対応する設定を入れる
・実際のデータで運用してチューニングしていく
・チューニングパラメータの変更を容易にしておく

アジェンダ
39
・自己紹介
・最後に

最後に
40
再認識できたこと
デプロイメントサイクルを早くすることの重要性
・早くリリースし本番環境、本番のデータで運用していくこと
が重要
・予測できない事への修正、チューニングパラメータの迅速
な変更が重要

Hive on Tezのベストプラクティス

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (10)

Similar to Hive on Tezのベストプラクティス

Similar to Hive on Tezのベストプラクティス (20)

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

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

Recently uploaded

Recently uploaded (11)

Hive on Tezのベストプラクティス