SparkSQL CLIは内部でHiveQLを使用し、Hive on spark(Hive-7292)の場合、Hiveはspark=をバックエンドエンジンとして使用します。両方のアプローチの短所?
SparkSQLがHiveを使用する場合
SparkSQLはHiveMetastoreを使用して、HDFSに保存されているデータのメタデータを取得できます。このメタデータにより、SparkSQLは実行するクエリの最適化を改善できます。ここでSparkはクエリプロセッサです。
HiveがSpark JIRAエントリを参照:Hive-7292
ここでは、sparkを介してデータにアクセスします。また、Hiveはクエリプロセッサです。したがって、Spark Coreを利用するコアのすべての設計機能があります。ただし、これはHiveの大幅な改善であり、2016年2月2日現在「進行中」です。
SparkSQLでデータを処理する3番目のオプションがあります
Hiveを使用せずにSparkSQLを使用します。ここで、SparkSQLはHive Metastoreからのメタデータにアクセスできません。また、クエリの実行が遅くなります。オプション1と3を比較するパフォーマンステストをいくつか実行しました。結果は ここ です。
SparkSQL vs Spark RDBMSの世界にいると想像できるAPI:
SparkSQLは純粋なSQLであり、Spark APIはストアドプロシージャを記述するための言語です
Hive on SparkはSparkSQLに似ています。これは、実行エンジンとしてsparkを使用する純粋なSQLインターフェースであり、SparkSQLは言語として、Hiveの構文を使用します。彼らはほとんど同じだと言うでしょう。
ただし、Hive on Sparkは、Hive機能、特にhiveserver2とセキュリティ機能のサポートがはるかに優れています。SparkSQLのHive機能は本当にバグが多く、SparkSQLにはhiveserver2 implがありますが、 1.6.x)、SparkSQLのhiveserver2はhivevarおよびhiveconf引数を使用できなくなり、jdbcを介したログインのユーザー名も機能しなくなりました...
https://issues.Apache.org/jira/browse/SPARK-1398 を参照してください
sparkプロジェクトのHiveサポートは、非常に優先度の低いものです...
悲しいことにHive on spark統合はそれほど簡単ではありません、多くの依存関係の競合があります... https://issues.Apache.org/jira/browse/Hive -13301
そして、デバッグのためにspark統合でHiveを試しているときは、常に次のようにHive cliを起動しています。
export HADOOP_USER_CLASSPATH_FIRST=true
bin/Hive --hiveconf Hive.root.logger=DEBUG,console
要件はsparkをhiveserver2で安全な方法(認証と承認)で使用することです。現在、SparkSQLだけではこれを提供できません。Sparkでレンジャー/セントリー+ Hiveを使用しています。
これがどの方向に進むべきかをよりよく理解するのに役立つことを願っています。
これは、Hiveの公式サイトで見つけた関連する回答です。
1.3 SharkおよびSQLとの比較Spark:SharkおよびSQLでのHiveQLサポートを提供する、Sparkエコシステムに関連する2つのプロジェクトがあります。 ●「Shark」プロジェクトは、Hiveによって生成されたクエリプランを自身の表現に変換し、Sparkで実行します。 ●Spark SQLは、Sparkの機能です。 Hiveの「パーサー」をフロントエンドとして使用して、HiveのQLサポートを提供します。 Sparkアプリケーション開発者は、SQLでデータ処理ロジックを簡単に表現でき、他のSpark演算子でもコードで簡単に表現できます。 Spark SQLは、Hiveとは異なる用途をサポートしています。
SharkおよびSparkのSQLと比較して、設計によるアプローチは、Hive QL(および将来のあらゆる拡張)、Hiveの統合、承認、監視、監査、およびその他の運用ツールを含む、すべての既存のHive機能をサポートしています。
3.ハイブレベルの設計は、このプロジェクトで紹介されているように、Sparkのプリミティブを使用してSQLのセマンティクスを実装していないという意味で、SharkまたはSQLのSQLのアプローチとは異なるアプローチを取ります。反対に、MapReduceプリミティブを使用して実装します。ここでの唯一の新しいことは、これらのMapReduceプリミティブがSparkで実行されることです。実際には、Sparkのプリミティブのうちのごく一部のみが、この設計で使用されます。
実行中のHiveのMapReduceプリミティブは、SharkやSparkのSQLとは異なるものであるため、次の直接的な利点があります。1. 1。未来。 2.このアプローチは、Hiveの「Spark」実行エンジンでのカスタマイズ作業の必要性を回避または削減します。
3.Hive--on--SparkをHive-MapReduceとTezに一致させることにより、プロジェクトの範囲を制限し、長期的なメンテナンスを削減します。