Azure Databricks环境下使用R访问大规模数据的最佳实践咨询

问题解答 #

1. fread读取大文件云上耗时远高于本地的原因

你本地读取的是本地磁盘文件，而Databricks上直接用fread读云上存储的文件时，是走驱动节点单线程跨网络拉取Azure存储（ADLS/Blob）的数据，本身就存在网络开销。如果你的存储账户和Databricks工作区不在同一 Azure 区域，网络延迟会更高，3GB单文件单线程拉取数分钟是常见情况。

2. collect()报错的解决配置

你遇到的collect()报错本质是驱动节点内存不足：collect()会把分布式存储的全量Spark DataFrame数据全部拉取到驱动节点的R进程内存中，只要数据量超过驱动节点可用内存或R进程内存上限，不管读csv、Delta还是SparkSQL查询结果都会报错。可以调整以下配置解决：

• 升级驱动节点规格：选择内存优化型节点（如Azure E系列、DSv3系列），内存配置至少为你单批次处理数据量的3倍以上
• 修改集群Spark配置：在集群的「Spark 配置」页添加以下参数：

  spark.driver.memory 16g
  spark.r.driver.memory 12g
  spark.sql.execution.arrow.enabled true
  spark.sql.execution.arrow.maxRecordsPerBatch 10000
  

  开启Arrow序列化后，Spark转R数据框的效率会提升数倍，内存开销也会大幅降低。

3. 最优方案选择

根据你的数据规模分两种情况选择：

• 如果你的所有待处理数据都不超过单节点内存上限，且不想修改已验证的data.table代码：优先用「先把文件缓存到驱动节点本地再fread」的方案：
  先执行dbutils.fs.cp("云上存储路径/xxx.csv", "file:/tmp/xxx.csv")把文件拉到驱动本地磁盘，再用fread("/tmp/xxx.csv")读取，速度和本地运行基本一致。
• 如果后续要处理超过单节点内存的大规模数据：最优方案是把data.table的处理逻辑改写为SparkR分布式逻辑，所有过滤、聚合、转换操作都在分布式集群层完成，最后只collect最终的小结果集即可，完全避免全量拉取的内存问题，处理效率也最高。

额外操作建议

优先把csv格式的数据转换为Parquet或Delta格式存储：这两种是列式压缩存储格式，读性能是csv的5~10倍，压缩比可达1:5以上，还支持分区裁剪、列裁剪，不需要读全量文件就能拉取指定列/指定分区的数据。

内容的提问来源于stack exchange，提问作者Discus23