Spark History Server ListBucket 成本答案

【问题标题】：Spark History Server ListBucket costsSpark History Server ListBucket 成本
【发布时间】：2022-06-19 21:45:34
【问题描述】：

我们正在使用 Spark history 3.2.1 来监控我们的 Spark 应用程序。

我们有数以千计的日常作业（在 Kubernetes 上运行）将事件日志写入 S3 存储桶（在专用文件夹中）。

我们正在使用历史服务器来分析和比较已完成的作业（未完成的正在运行的作业从未出现在 UI 中，但现在不是必需的）。

最近我注意到 AWS 账单成本浏览器中的 ListBucket API 操作有所增加。这个成本高于StandardStorage 的成本（我们为存储数据本身支付的价格）。每月最多几百！

以 DEBUG 日志级别运行历史服务器暴露了“问题”：every 10s 历史服务器列出存储桶以获取所有日志，然后遍历每个文件夹以获取其内容。所以如果我想保留最后的 10,000 个工作，我将不得不为每 10 秒的 10,101 个 ListBucket 请求付费！

这是一个使用minio 作为 S3 在本地复制的示例（10k 中）：

22/02/20 06:44:31 DEBUG wire: http-outgoing-57 << "<ListBucketResult xmlns="http://s3.amazonaws.com/doc/2006-03-01/"><Name>local-audience</Name><Prefix>history-logs/eventlog_v2_spark-ffffdf5903c841259f28b53981746b76/</Prefix><KeyCount>2</KeyCount><MaxKeys>5000</MaxKeys><Delimiter>/</Delimiter><IsTruncated>false</IsTruncated><Contents><Key>history-logs/eventlog_v2_spark-ffffdf5903c841259f28b53981746b76/appstatus_spark-ffffdf5903c841259f28b53981746b76</Key><LastModified>2022-02-12T17:00:15.304Z</LastModified><ETag>&#34;d41d8cd98f00b204e9800998ecf8427e&#34;</ETag><Size>0</Size><Owner><ID></ID><DisplayName></DisplayName></Owner><StorageClass>STANDARD</StorageClass></Contents><Contents><Key>history-logs/eventlog_v2_spark-ffffdf5903c841259f28b53981746b76/events_1_spark-ffffdf5903c841259f28b53981746b76</Key><LastModified>2022-02-12T17:00:15.136Z</LastModified><ETag>&#34;f91cc774d92c6f6c2ca4d0e1a1e76e13&#34;</ETag><Size>868837</Size><Owner><ID></ID><DisplayName></DisplayName></Owner><StorageClass>STANDARD</StorageClass></Contents></ListBucketResult>"

为了确保费用来自历史服务器，我将其关闭了一天，此后ListBucket 不再收费：

为了缓解这个问题（因为我们仍然需要历史服务器），我可以将spark.history.fs.update.interval 设置为更高的数字（例如 3600s 左右）。因为我们每天检查一次历史服务器，所以它是多余的并且不值得（成本方面）。

为什么它每次都扫描已完成的作业（一遍又一遍），而不仅仅是新作业？有没有办法配置这种行为来避免那些ListBucket 操作？
如果我只关心已完成的作业，并假设我可以等待几分钟来查看列表，那么是否有一种模式可以仅在我登录 UI 时加载列表？（而不是定期白做）。

P.S - 我每隔几天使用 AWS lifecycle rules 清理这个文件夹（而不是服务器清理功能），几天后到期对象。

【问题讨论】：

标签： amazon-web-services apache-spark amazon-s3

【解决方案1】：

s3 中的 treewalking (a) 昂贵且 (b) 非常慢，尤其是考虑到存在深度树扫描。如果您想修复此问题并且可以编写 scala 代码，请查看是否可以通过移动到 FileSystem.listFiles(path, true) 来修复服务器以切换到深度列表。是的，这涉及到编码，但是 OSS 社区依赖于每个人解决自己的个人问题并分享结果

【讨论】：

【解决方案2】：

在深入研究了这个问题后，我决定暂时停止使用“滚动”功能 - 因为我的应用程序工作相对较小。我删除了：

spark.eventLog.rolling.enabled: true
spark.eventLog.rolling.maxFileSize: 16m

来自spark-submit 命令，成本现在恢复正常... 我也写了here。

@stevel 感谢您的回答 - 我会尽力做出贡献并修复它！ :)

【讨论】：