標籤:markdown issues jar extend user pool distrib addclass ati
近期 有網友看我的“整合Kafka到Spark Streaming——代碼示範範例和挑戰”文章,
講 kafka對象 放到 pool 並通過broadcast廣播出去:
然後 在開發測試階段 報錯例如以下:
然後就找我,說“代碼都跟你的差點兒相同呀,為什麼就報這個錯呢?”
事實上 對於廣播操作。spark 肯定要序號的,還有盡量不要把大對象廣播出去,
後來 把代碼要過來看了下。發現 createKafkaProducerPool這種方法 ,單獨建立了一個類,同一時候這個類 extends Serializable 。我當時的感覺就是,假設createKafkaProducerPool方法 。寫在main方法 or Driver端 應該就肯定不會有這個問題,我也建議這樣搞的。還有 我懷疑 叢集是啟用了Kryo序號方式。而createKafkaProducerPool方法所在類居然 extends Serializable ,不解
important:
The closures (anon function going inside RDD.map(…)) are serialized by Spark before distributing them. Hadoop does not have this problem because it binary-serializes the whole .jar and copies it over the network. Spark uses JavaSerialization by default, but it is very slow compared to, say, Kryo. So we use Kryo to do that by using a wrapper (Spark doesn’t support kryo-serde for closures, not yet).
And uptill now the org.dbpedia.extraction.spark.serializeKryoSerializationWrapper class has been working perfectly. Some freak extractors seem to fail though.
依據這個錯誤檢索的文章
- https://github.com/dbpedia/distributed-extraction-framework/issues/9
- http://stackoverflow.com/questions/27277015/sparkcontext-broadcast-jedispool-not-work
- http://apache-spark-user-list.1001560.n3.nabble.com/why-does-quot-com-esotericsoftware-kryo-KryoException-java-u-til-ConcurrentModificationException-quo-tc23067.html
假設大家有遇到這樣問題或者什麼好想法,請回複,THX ~
com.esotericsoftware.kryo.kryoexception java.util.ConcurentModificationException