我正在使用spark.wholeTextFiles()处理400MB的文件，并且我不断出现内存错误。我首先使用这个API和一个总共40MB的文件夹，我想知道我的代码是否适用于大文件，那就是大文件的位置。
这是配置，我认为我为堆提供了足够的RAM，但仍然没有运气，我只是在阅读文件夹然后用
写下来files.saveAsTextFile("data/output/no")
，命令是
spark-submit --driver-memory 4G --driver-java-options -Xms4096m --executor-memory 4G target / scala-2.11 / mz_2.11-1.0.jar
我比较了spark sql，sc.hadoopFile和sc.wholeTextFiles和 wholeTextFiles 是最快的，我认为这是因为wholeTextFiles尝试将整个文件夹加载到内存中一个节点，主人我猜，一切都发生在RAM，所以它很快。
HadoopFile（）按分区加载，即使文件较小且读取操作也很昂贵，也会与文件编号一样多。
spark sql 会将文件夹加载到分区，分区的大小可以用
定义spark.conf.set("spark.sql.files.maxPartitionBytes", 32000000)
但如果文件很小，则需要花费时间将文件充电到每个分区。
Q1。为什么我一直出现内存错误？
Q2。当spark通过分区加载文件夹/大文件并返回RDD时，如何 很多分区已被读入RAM？也许不是，火花等待 用于操作加载尽可能多的分区数 执行者（或核心？）每次治疗？在那种情况下，也许我们应该 加载大分区，如64MB或128MB而不是像小分区一样 32KB？
答案 0 :(得分：0)
你可以取悦整个代码吗？
当需要 filePath 和 fileContent 时，会使用wholeTextFile()。
像键 - ＆gt;之类的东西filePath（C：\\ fileName）和值 - ＆gt;实际的fileContent。
使用wholeTextFile()时的分区数取决于您拥有的执行程序核心数。
这里分区的数量将是1或更多。
除非调用某个操作，否则不会触发spark job。 这是一种自上而下的方法/懒惰评估。