MllibRandomForestを使用してデータをトレーニングするとエラーが発生します。私のデータセットは巨大で、デフォルトのパーティションは比較的小さいので。したがって、「サイズがInteger.MAX_VALUEを超えている」ことを示す例外がスローされ、元のスタックトレースは次のようになります。
15/04/16 14:13:03警告scheduler.TaskSetManager:ステージ6.0でタスク19.0が失われました(TID 120、10.215.149.47):Java.lang.IllegalArgumentException:サイズがInteger.MAX_VALUEを超えています
Sun.nio.ch.FileChannelImpl.map(FileChannelImpl.Java:828)at org.Apache.spark.storage.DiskStore.getBytes(DiskStore.scala:123)atorg.Apache.spark.storage。 DiskStore.getBytes(DiskStore.scala:132)at org.Apache.spark.storage.BlockManager.doGetLocal(BlockManager.scala:517)at org.Apache.spark.storage.BlockManager.getLocal(BlockManager.scala:432)at org .Apache.spark.storage.BlockManager.get(BlockManager.scala:618)at org.Apache.spark.CacheManager.putInBlockManager(CacheManager.scala:146)at org.Apache.spark.CacheManager.getOrCompute(CacheManager.scala:70 )
Integer.MAX_SIZEは2GBで、一部のパーティションのメモリが不足しているようです。そこで、rddパーティションを1000に再パーティション化して、各パーティションが以前よりもはるかに少ないデータを保持できるようにします。最後に、問題は解決されました!!!
だから、私の質問は:なぜパーティションサイズに2Gの制限があるのですか? Sparkの制限に設定された構成がないようです
sparkのブロックの基本的な抽象化はByteBuffer
ですが、残念ながらInteger.MAX_VALUE(〜2GB)の制限があります。
これは 重大な問題 であり、非常に大きなデータセットでsparkたとえば、変換の大きなチェーンがあり、その一部がデータを増やす可能性がある場合(flatMapなど)、またはデータが歪んでいる場合などに実行可能です。
提案された解決策は、ブロックのバイトバッファのリストをサポートできる LargeByteBuffer のような抽象化を考え出すことです。これは全体的なsparkアーキテクチャに影響を与えるため、かなり長い間未解決のままです。
問題は、Casandra、HBase、Accumuloなどのデータストアを使用する場合、ブロックサイズがデータストアの分割(10ギガを超える可能性がある)に基づいていることです。これらのデータストアからデータをロードするときは、2ギガの制限を超えずにデータを操作できるように、数千のパーティションですぐに再パーティション化する必要があります。
sparkを使用するほとんどの人は、実際には大きなデータを使用していません。 Excelが保持できるサイズが大きい場合、またはタブローが大きい場合は、ビッグデータです。ほとんどの場合、品質データを使用するか、制限を処理するのに十分小さいサンプルサイズを使用するデータサイエンティスト。
大量のデータを処理するときは、mapreduceに戻る必要がなくなり、データがクリーンアップされた後にのみsparkを使用します。これは残念なことですが、sparkコミュニティの大多数はこの問題に取り組むことに関心がありません。
簡単な解決策は、抽象化を作成し、デフォルトとしてbytearrayを使用することです。ただし、大きなジョブを処理するために、64ビットデータポインタでsparkジョブをオーバーロードできるようにします。
Spark 2.4.0リリース ブロックデータをストリームとして複製することにより、この制限を取り除きます。詳細については、 Spark-24926 を参照してください。