EMR Hiveの性能検証(TPC-HベンチマークでAuroraと比較)

Posted at 2019-04-17

TL;DR

Amazon EMRで構成したHiveの性能検証を，下記の観点で行いました．
- RDBベンチマークTPC-Hによる計算時間の計測
- AWS Auroraと，EC2上に構成したMariaDBを比較対象にしました
計測の結果，以下のことが明らかになりました
- EMR Hiveは，費用が高い上，計算開始のセットアップに時間を要するので，使用用途を選びます
- 一方で，より大きな問題に良いスケーラビリティを示すので，大規模データのバッチ処理に向いたクエリエンジンであると言えます
Auroraの性能検証（EC2との比較，データ量と計算時間の関係）の続編です
- この記事から読み始めることもできます

Auroraの性能検証（EC2との比較，データ量と計算時間の関係）と同じ計算を実施しました
- TPC-Hベンチマークを，ScaleFactor(SF)=1,4,8で実行し，計算に要する時間を計測しました

EMRマスターインスタンスで，Query1から22まで，順番に実行します
- Hiveの実行時オプション（データベース指定），および，クエリはHQLなるクエリ言語（MySQLと若干異なる）であることから，MySQLクライアントと若干祭があります

for i in `seq 1 22`;
do
    hive --database sf1 -f ${i}.sql
    hive -e "RESET QUERY CACHE;"
done

EMRは，小さな問題でも40秒程度の時間を要する（起動時間，計算セットアップ時間など）
Aurora, EC2は，クエリごと計算時間に関連がありそうな一方で，EMRは必ずしもそうではなさそう
- Aurora/EC2はQ3がQ1よりも計算時間が大きい一方で，EMRでは計算時間が小さい
計算を始めるまでのオーバヘッド（クエリをMapReduceできる形に変換し，データを分割して並列計算する処理）が大きいので，Hiveはトランザクション処理というよりは，BI（大きいデータの分析処理）に向いている

データ量に応じた計算時間を要する
- マルチノード構成で，メモリの総量が大きいので，極端に時間が掛かったクエリは無かった
計算時間はきれいにスケールするわけではないことも示された
- Q1はテーブルをスキャンする処理なので，（起動オーバヘッドが各データサイズで同程度とすると）スケールしているように見える
- Q4はSF=1とSF=4の計算時間の差に比べて，SF=4とSF=8の差が大きくなっている
- 一方で，Q7は逆に，SF=1とSF=4の差が大きく，SF=4とSF=8の差は小さい

サービス	インスタンスタイプ	USD/hour
EMR	m3.xlarge x 3	$0.385 \times 3 = 1.155 $
Aurora	db.r5.large	$0.152$

時間単価が約7.5倍($1.155 / 0.152 = 7.60$)あるので，基本的にはAuroraに軍配が上がります
8GB程度のデータを対象とした場合，Hiveは起動＋セットアップ時間の占める割合が大きく，良い効果を得にくいです
Auroraのデータサイズごとの計算時間から，Q14のように，メモリ量の関係から極端に計算時間が掛かるような処理に対応する際に，Hiveの効用が得られます
- SF=8ではAuroraは力不足が顕在化し，EMRの方が3倍程度速くなるQ20のようなものも出てきます