Spark 进行昂贵的 S3 API 调用答案

【问题标题】：Spark making expensive S3 API callsSpark 进行昂贵的 S3 API 调用
【发布时间】：2020-06-20 18:35:25
【问题描述】：

我有一个 spark 作业，它接收大约 100k 个文件的列表，每 10 分钟调用一次。这些文件在 s3 中。路径如下所示：

s3://<bucket>/<folder>/<file_name>

文件是这样加载的：

df = spark.read.option("mergeSchema", "true").schema(schema).parquet(*files)

在幕后，spark 似乎对每个文件进行了 LIST 和 HEAD API 调用。这是非常浪费的，因为这些是文件而不是目录，并且由于工作的性质而保证存在。我查看了 spark 代码库，似乎这种行为是InMemoryFileIndex 的一部分。有没有办法配置 spark 直接进行 GET 调用并跳过列表/头部调用？

【问题讨论】：

我不确定 [databricks] 会带来什么，但我认为您需要研究如何让“s3a://”协议在您的 Spark 应用程序中运行。
你确定mergeSchema 选项不需要需要额外的I/O来确保 Spark实际上是预先合并 schema？只是说...
请记住，S3 不是文件系统；它是一个对象存储，您使用它是因为它便宜并且具有内置的地理复制功能，但是您不能期望尝试从中模拟文件系统的“连接器”具有良好的性能。即使使用 HDFS，读取一堆小文件也是灾难的根源——Hadoop 和 Spark 是为大数据构建的，即一些可以拆分为逻辑块的大文件。
Databricks 声称他们在自己的 S3 连接器中进行了“优化”，因此据称与 EMR 连接器 (s3:) 和 Hadoop 连接器 (s3a:) 不同，所以......答案可能在他们的文档中，因为该连接器不是开源 AFAIK。

标签： apache-spark amazon-s3 databricks

【解决方案1】：

这是相当浪费的，因为这些是文件而不是目录，并且由于工作的性质而保证存在。

这里的问题是文件系统层不知道“工作的性质”，所以它有时会进行自己的探测

看起来 InMemoryFileIndex.scala 的效率也很低；除了 HDFS 的一些硬编码位之外，它会执行自己的 treewalk，并且似乎会重新扫描刚刚再次列出的所有文件。

是的，正如开源项目所说，还有改进的余地。但正如他们也倾向于说“请提交补丁”

【讨论】：