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

1Mapで扱えるデータ量

Map m



36

対策

運用しながら1Mapperが扱うデータサイズを調整する原因対策

Mapperが過度にあがる 1Mapperが扱う最小のデータ量を調整tez.grouping.min-size

1Mapperが扱うデータ量が多い 1Mapperが扱う最大のデータ量を調整tez.grouping.max-size



37

対策

Inputデータ

Map 1

Map 2

Map n

1Mapで扱えるデータ量取得できるリソース



38

安定的に動かすために必要なこと

・1Mapperが扱うデータ量を設定する

・増加するデータ量に対応する設定を入れる

・実際のデータで運用してチューニングしていく

・チューニングパラメータの変更を容易にしておく


アジェンダ

39

・自己紹介





・最後に


最後に

40

再認識できたこと

デプロイメントサイクルを早くすることの重要性

・早くリリースし本番環境、本番のデータで運用していくことが重要

・予測できない事への修正、チューニングパラメータの迅速な変更が重要

hive on tezのベストプラクティス

Technology