配置：
火花 3.0.1
Cluster Databricks（驱动程序 c5x.2xlarge，Worker (2) 与驱动程序相同）
来源：S3
格式：实木复合地板
大小：50 mb
文件数：2000（小文件太多，因为我们不能有更多的延迟 99）
问题陈述：我有 10 个作业，其配置和处理的数据量与上述类似。当我单独运行它们时，它们每个需要 5-6 分钟，包括集群启动时间。
但是当我一起运行它们时，它们似乎都停留在代码中的同一点，需要 40-50 分钟才能完成。
当我检查 spark UI 时，我发现所有作业在获取源计数时花费了 90% 的时间：
df = spark.read.parquet('s3a//..') df.cache() df.count() ----- 有问题的步骤....更多代码逻辑
现在我知道在缓存之前计算对于镶木地板文件应该更快，但是如果我在计算之前不缓存数据帧，它们会花费更多时间，可能是因为小文件数量庞大。< /p>
但我不明白的是，当一次运行一个作业时，作业的运行速度如何？
S3 是我的瓶颈吗？它们都从同一个桶中读取，但路径不同。
** 我使用 privecera 令牌进行身份验证。
答案 0 :(得分：1)
他们都将在工作节点中使用相同的 s3a 文件系统类实例，那里有一些关于 #of HTTP 连接的选项，fs.s3a.connection.maximum，默认为 48。如果一切正常针对同一个存储桶，将其设置为 2x+ 工作线程数。对“fs.s3a.max.total.tasks”执行相同的操作。
如果使用 hadoop 2.8+ 二进制文件将 s3a 客户端切换到随机 IO 模式，该模式可在查找镶木地板文件时提供最佳性能，fs.s3a.experimental.fadvise = random。
更改 #2 应该可以提高单个工作负载的速度，所以无论如何都要这样做
限制将显示为 503 响应，这些响应在 AWS 开发工具包中处理并且不会被收集/报告。我建议至少在调试时打开 S3 存储桶日志记录，并扫描日志中的 503 响应，这表明正在发生节流。这就是我所做的。提示：设置删除旧日志的规则，从而降低成本； 1-2 周的日志对我来说通常就足够了。
最后，很多小文件在 HDFS 上都是不好的，对于对象存储来说很糟糕，因为列出/打开的时间太长了。尝试使合并文件成为处理数据的第 1 步