なぜ単純なWebフレームワークではなく、Livyやspark-jobserverですか？

Question

私はApache Sparkの上にRESTful APIを構築しています。​​で次のPythonスクリプトを提供して正常に動作するようです：

import cherrypy 
from pyspark.sql import SparkSession 

spark = SparkSession.builder.appName('myApp').getOrCreate() 
sc = spark.sparkContext 

class doStuff(object): 
    @cherrypy.expose 
    def compute(self, user_input): 
     # do something spark-y with the user input 
     return user_output 

cherrypy.quickstart(doStuff()) 

しかし、グーグルでは、私の周りにはLivyとspark-jobserverのようなものを参照してください。私はこれらのプロジェクトのドキュメントとチュートリアルを読んでいますが、CherryPyやFlaskなどのWebフレームワークを使った簡単なスクリプトでLivyやspark-jobserverの利点を十分に理解することはできません。それはスケーラビリティについてですか？コンテキスト管理？私はここで何が欠けていますか？私が欲しいのは、多くのユーザーがいない単純なRESTful APIで、Livyやspark-jobserverが問題になるのでしょうか？もしそうなら、なぜですか？

Answer 1

​​を使用する場合は、手動でJARファイルをクラスタにアップロードし、コマンドを実行する必要があります。実行前にすべてを準備する必要があります

Livyまたはspark-jobserverを使用すると、プログラムでファイルをアップロードしてジョブを実行できます。同じクラスタに接続し、次のジョブでjarをアップロードするアプリケーションを追加することができます

さらに、LivyとSpark-JobServerでは、Spark-submitを使用するのが難しい対話モードでSparkを使用できます。）

Answer 2

は、私は、具体的リウィウスまたは火花ジョブサーバを使用してについてはコメントしませんが、あなたのアプリケーションで直接スパークコンテキストを埋め込む回避するために、少なくとも三つの理由です：クラスタの露出を減らすことに主な焦点と

• セキュリティ外の世界に。アプリケーションを制御できる攻撃者は、クラスタが正しく構成されていないと、クラスタ上の任意のコードを実行するためにデータにアクセスすることと、クラスタ上の任意のコードを実行することとの間に何かを行うことができます。

• 安定性。スパークは複雑なフレームワークであり、長期的なパフォーマンスと安定性に影響を与える可能性のある多くの要素があります。 Sparkのコンテキストとアプリケーションを分離することで、アプリケーションの完全な停止時間なしにSparkの問題を正常に処理できます。

• 応答性。ユーザーが直面しているSpark APIは主に（PySparkのみで）同期しています。外部サービスを使用すると、基本的にこの問題が解決されます。

Answer 3

スパーク・ジョブ・サーバーまたは類似の種類の機能は、Apache Spark自体の一部である必要があります。 Apark Stormと同じですが、同様の目的でUIとRESTのインターフェースがあります。