2017-08-23 4 views
1

SparklyRライブラリの機械学習アルゴリズムをSparkサーバー上で実行しようとしています。スパークスタンドアロン:SparklyR:パフォーマンスの問題

  • 1クラスタ
  • 8コア
  • 24G RAM
  • のUbuntu 16.04
  • スパーク2.2
  • スタンドアロン構成
  • 1マスター/ 2労働エグゼキュータ当たり
  • メモリ:4G
  • 8コア/ワーカー
  • 4096実際には労働者

によってメモリ、Iは、非常に小さなデータセット(72×100)でml_decision_treeをテストします。 まず、R(read.csv)のCSVファイルから元のデータセット(72 x 7350)をローカルで読み取り、再構成してからSparkで結果(df_fin)をロードします(Sparkがインストールされています):

私は、新しく作成されたRDDをサーバーのUIで見ることができます。 「メモリ内のサイズ」は49.9 KB、「ディスク上のサイズ」はnullです。ヒープメモリ使用量では、私は見ることができます:49.9 KB(2004.6 MBの残り)。

その後、私のアプリはml_decision_treeの実行中に立ち往生しています。 私は私のコンソールにはエラーメッセージを持っていない、私のアプリの状態が「RUNNING」であり、次はまだ私のワーカーログに書き込まれます。

17/08/23 15:35:32 INFO ShuffleBlockFetcherIterator: Getting 0 non-empty blocks out of 200 blocks 
17/08/23 15:35:32 INFO ShuffleBlockFetcherIterator: Started 0 remote fetches in 0 ms 
17/08/23 15:35:32 INFO ShuffleBlockFetcherIterator: Getting 26 non-empty blocks out of 200 blocks 
17/08/23 15:35:32 INFO ShuffleBlockFetcherIterator: Started 1 remote fetches in 1 ms 
17/08/23 15:35:32 INFO Executor: Finished task 1.0 in stage 494.0 (TID 39532). 3082 bytes result sent to driver 
17/08/23 15:35:32 INFO Executor: Finished task 0.0 in stage 494.0 (TID 39531). 4073 bytes result sent to driver ... 

そして、35分後に、コンソールで:「*によって落とさない行 " na.omit 'call " 先が進むという意味です。

それでもまだ何かしていますが、何が理解できません。自分のコンピュータのRShinyで同じコードをローカルで実行すると、プロセスはかなり速く終了します(3〜4分)。私は、このJavaエラーが空き、多くのメモリをせずに、私のCPUのressourcesの大部分を使用して、ガベージコレクタから来ていると思います

Error: java.lang.OutOfMemoryError: GC overhead limit exceeded

...:最後に、私のプロセスは、次のエラーで+/- 50分後に終了しますしかし、それはどこから来ますか?

私はSparkの理解で何かを逃したと思います。通常Sparkはプロセスを高速化するべきですが、私の場合は最悪です。私は巨大なデータセットをそのように扱うことはできません。

また、Sparkでオリジナルのデータフレーム(72 x 7350)をロードして機械学習を実行したいと思います(スローネス問題が実際に解決されると...)。

どうすればよいですか? spark_read_csvを使用しますか?私はHDFSを使用しません。私は、Hadoopの能力を活用するのに十分なデータがないと考えました(Tb、それ以上ではありません)。私は、元のデータフレームをロードしようとしたとき

、私はこのエラーを得た:

Caused by: org.codehaus.janino.JaninoRuntimeException: Constant pool for class org.apache.spark.sql.catalyst.expressions.GeneratedClass$SpecificUnsafeProjection has grown past JVM limit of 0xFFFF

私は私は本当に理解していない

"We fixed a problem for the large number (e.g. 4000) of columns. However, we know that we have not solved a problem for the very large number (e.g. 12000) of columns."

よりSPARK-18016 JIRAで見ました。 SparkはBig Data用に設計されていますが、私の場合は7350 colmunsで失敗するのはなぜですか?

この問題について教えてもらえますか?それは私の騒ぎから来るのだろうか?私はもっ​​と労働者を加えるべきですか?

ありがとうございます!

答えて

0

I do not really understand. Spark has been designed for Big Data, why should it fail with (in my case) 7350 colmuns ?

すべての「ビッグデータ」が等しく、データの形状(ワイド、ロング、両方)によってデザインの選択が異なるわけではありません。ほとんどの場合、システムは細長いデータセットに焦点を当てています。これはSparkの場合です。

ここでの問題は、データの量ではなく、オプティマイザの複雑さです。 Spark MLでは、機能を組み合わせるためにSparkがVectorタイプを使用しているので大きな問題ではありません。十分でない場合は、常に低レベルのAPIを使用することができます。 sparklyrしかし、変換された機能を拡張するという不幸な決定をしました。これはうまく機能しません。

72 x 7350

このようなデータでスパークを使用することは意味がありません。あなたが実行できる場合:

df_tbl <- sdf_copy_to(sc,df_fin) 

それは、データがメモリに収まると分散処理のために必要がないことを意味します。

+0

お返事ありがとうございました。私はいくつかの精度を望んでいます。スパークリヤが不幸な決定を下すと言ったとき、あなたはどういう意味ですか? PythonやScalaで直接実装すると、自分のコードがうまく動作するでしょうか?また、Sparkを使用したかったのは、近い将来にこのようなデータフレームを大量に処理する必要があるためです(臨床データ、ロットの幅広いデータを意味しますが、イメージングデータもあり深い学習を行います)。これが私がSparkが有用な解決策であると推測した理由です。これに関するあなたの意見は何ですか? – NathJ