HDP 2.5.0 の Hive LLAP を試してみる

こんにちは。次世代システム研究室で Hadoop 周辺をよく触っている T.O. です。
Hadoop 周辺をよく触っているので、最近 Hadoop 周辺を触ってきて得た話などを書いていきます。

少し前に HDP 2.5.0 が正式にリリースされました。 HDP 2.5.0 では、 Hive LLAP が Technical Preview 扱いではありますが、用意されています。ということで、今回はその Hive LLAP を試してみました。

Hive LLAP の紹介

Hive LLAP については、下記のページやスライドを読むと、敢えてこのエントリでまとめなおすまでもなく、理解が進むと思います。

• https://cwiki.apache.org/confluence/display/Hive/LLAP
• LLAP: long-lived execution in Hive
• LLAP: Sub-Second Analytical Queries in Hive
• HIVE LLAP TECHNICAL PREVIEW ENABLES SUB-SECOND SQL ON HADOOP AND MORE
• Hiveを高速化するLLAP
• Apache Hiveの今とこれから

また、後述しますが、 Hive LLAP は Apache Slider を使っているので、 Slider についても多少、知っておく必要はあります。例えばこのあたりのスライドを読んでおくと良いです。

• Apache Slider

Ambari から Hive LLAP を使えるようにする

Hive LLAP は HDP 2.5.0 をふつうにセットアップしていっただけでは使えません。 Hortonworks が提供しているドキュメント Apache Hive Performance Tuning の Chapter 2. Interactive SQL Query with Apache Hive LLAP (Technical Preview) に示されている手順に従い設定していくと、使えるようになります。この手順を進めると、ふつうの LLAP 版ではない用の HiveServer2 とは別に、 LLAP 用の HiveServer2 が起動されます。恐らくまだ Technical Preview であることから、従来の Hive とは別の HiveServer2 にしておいた方が無難、ということからこうなっているのではないかと思われます。また、 LLAP daemon （org.apache.hadoop.hive.llap.daemon.impl.LlapDaemon クラス）も起動されます。

hive-testbench の紹介

漠然と試すのもだるい、というところで、また、 Hive LLAP には Hive クエリの処理速度向上を期待するわけですので、ベンチマークをやっていきます。ビッグデータ系のベンチマークなので TPC-DS をやります。Hive 向けの TPC-DS 用のデータ生成プログラムやクエリは、 hive-testbench があるので、これを使ってみます。

使い方は README.md に書いてあるのでよく読めば OK です。問題は、クエリを実行するスクリプトであるところの runSuite.pl で、これが hive コマンドで実行するものでした。しかし LLAP 版への接続は beeline からの JDBC 接続でないとダメなようなので、 runSuite.pl を適宜書き換えて、 beeline を使う版を用意することになります。参考までに私がざっと書いたものを貼り付けておきます。

#!/usr/bin/perl

use strict;

use Getopt::Long;

$| = 1;



my $suite;
my $scale;
my $script;
my $llap = 0;

GetOptions(
   'suite=s'  => \$suite,
   'scale=i'  => \$scale,
   'script=s' => \$script,
   'llap!'    => \$llap,
);

if (! defined $suite || ! defined $scale || ! defined $script) {
   die;
}



my $db = {
   'tpcds' => "tpcds_bin_partitioned_orc_$scale",
   'tpch'  => "tpch_flat_orc_$scale"
};



my $zkns = 'hiveserver2';
if ($llap) {
   $zkns = 'hiveserver2-hive2';
}

my $now = time;

my $zks = 'zk1.example.com:2181,zk2.example.com:2181,zk3.example.com:2181';

my $cmd = "beeline -u "jdbc:hive2://$zks/$db->{$suite};serviceDiscoveryMode=zooKeeper;zooKeeperNamespace=$zkns" -f $script -i sample-queries-$suite/testbench.settings -n root 2>&1 | tee $script-$suite-$scale-$llap-$now.log";
print $cmd, "\n";

open my $beeline, "$cmd |" or die;

my $query_name;
while (my $line = <$beeline>) {
   if ($line =~ /Completed executing command\(queryId=(.+)\); Time taken: (\d+\.\d+) seconds/) {
       print "$query_name = $2 seconds\n";
   } elsif ($line =~ /!run sample-queries-$suite\/(.+\.sql)/) {
       $query_name = $1;
       print "Current query = $query_name\n";
   }
}

close $beeline;

hive-testbench では、ベンチマークで使うデータ量を表す数値として “Scale Factor” というものがあります。 README.md にもありますが、これが 10 なら、プレーンテキスト形式でおよそ 10GB, 100 なら 100GB のデータ量のようです。今回はこのベンチマークをとりあえず Scale Factor = 10 のデータ量で実行します。ただし今回はプレーンテキストではなく ORC 形式で生成させたデータを使うので 3.2GB になっています。これを LLAP と非 LLAP それぞれで実行して試しての比較します。

ベンチマークの実行環境

GMOインターネットのエンジニアは「GMOすごいエンジニア支援制度」の「サバろうぜ！」により、GMOインターネットの VPS やクラウドサービスを自由に使うことができます。次世代システム研究室では、この制度でGMOアプリクラウドを使っているので、ここでいくつかインスタンスをつくり、その上で HDP 2.5.0 を構築しています。今回はとりあえずの検証ということもあり、以下のような控えめな構成で臨んでいます。

• CPU: 1vCPU / メモリ: 4GB / HDD: 80GB x1 : Ambari 用
• CPU: 4vCPU / メモリ: 8GB / HDD: 160GB x4: マスタ系ノード用。NameNode や ResourceManager などが適当に動いている。
• CPU: 4vCPU / メモリ: 16GB / HDD: 320GB x4: スレーブ系ノード用。この 4 台すべてで DataNode と NodeManager が動いている。

実際のベンチマーク結果の概要と考察

ベンチマークの結果の詳細な検証は目下のところ実施中で、本ブログではあくまで現時点で言えそうな所感を述べるに留めたいと思います。

Hive LLAP は HDFS からの読み出しのキャッシュを持つようになっており、これのおかげで、 Hive LLAP での実行結果だけを見ても、わかりやすく「キャッシュに載ってれば速い」が実現されており、同じクエリを複数回実行した場合、2回目以降は概ねかなり早くなることが確認できました。クエリとデータ次第では、1回目の実行と2回目の実行以降で処理時間が半分以下になる、というようなケースもありました。

キャッシュが効いている状態の LLAP と、非 LLAP との比較でも、当然のごとく LLAP は概ね速く、半分以下で済んでいるようなケースもしばしばありました。ただし、稀に非 LLAP の方が高速なケースがあり、今回試したケースでは具体的には query22.sql がそれでした。実行結果を見てみたところ、どういうわけか、最初の map のタスク数が LLAP の方が非 LLAP に比べてかなり少なく、時間もかかっていたためでした。これは、そのクエリの性質上そうなるのか、あるいは、構成やパラメータの問題なのかは突き詰められてませんが、そういうことも起き得る、ということで…。

性能以外の話

ベンチマークのクエリをひととおり走らせてみたわけですが、「そもそも LLAP だとダメ」というような事例はぱっと見はなくて、「動くか否か」という点でいけば、問題ないっぽい、というところでした。

が、それを管理する側、つまり Ambari 側の対応具合は現時点だとやや難ありか、というところでした。 HDP 2.5 では、そもそも Technical Preview 扱いなので、このあたりは今後に期待するか、自分でなんとかするか、ということになります。

具体的には、例えば HiveServer2 Interactive の再起動がどうも安定して成功しない、という話があり、ログを見ると /usr/hdp/current/hive-server2-hive2/bin/hive --service llapstatus --name llap0 --findAppTimeout 0 の結果が 20 回試してもダメなまま、ということがしばしば見受けられました。また Ambari からセットアップすると YARN Capacity Scheduler で llap という名前のキューを LLAP 専用という感じで用意してくれるものの、 Hive 側の設定（”Interactive Query” の “% of Cluster Capacity”）が YARN Queue Manager でやる設定とリンクしていないようで、しかし YARN Queue Manager からの設定変更は、 ResourceManager の WebUI から確認してみると、適切に反映されている、というような話もありました。

ところで、私の前回のエントリ “最近触っていた Hadoop 周辺の話 ? Ambari 2.2.1.0 + HDP 2.4.0 でのセキュアな Hadoopを、編” で触れたようなセキュアな環境、つまり認証は Kerberos を使い、各種認可に Ranger を使っているような環境では Hive LLAP はどうなるのか、というところは大変気になります。自分ではまだ試していませんが、 15.2. Installing LLAP on a Secured Cluster では Kerberize されたクラスタでのセットアップについて触れられており、また、 HIVE LLAP TECHNICAL PREVIEW ENABLES SUB-SECOND SQL ON HADOOP AND MORE では “LLAP, along with Apache Ranger enables fine-grained security for the Hadoop ecosystem, including data masking and filtering, by providing interfaces for external clients like Spark to read.” と書かれているので、いけるようです。

まとめ

ということで、ごく簡単にではありますが、 HDP 2.5.0 の Hive LLAP を試してみました。現時点では Ambari からのコントロールに難がある、というところはありましたが、 Hive LLAP そのものとしては、そこそこには安定をしており性能向上も見込め、さらにキャッシュが効けば大幅な実行速度向上が見られました。 Hive LLAP はあくまで Hive なので、高速処理のために既存の Hive から Presto や Impala に置き換えるのとは違って、既存の Hive クエリを書き換える必要は基本的にないはず。これがより安定し、 production でも安心して使えるレベルになってくれば、より低コストに既存の処理の高速化、というところに持っていけて嬉しい、ということが言えそうです。

最後に

次世代システム研究室では、グループ全体のインテグレーションを支援してくれるアーキテクトを募集しています。
インフラ設計・構築経験者の方、次世代システム研究室にご興味を持って頂ける方がいらっしゃいましたら、
ぜひ 募集職種一覧 からご応募をお願いします。