星火历史服务器ListBucket成本

Question

我们正在使用星火历史3.2.1监控我们的星火应用程序。

我们有数千个日常作业(运行在Kubernetes上)，它们将事件日志写入S3桶(在一个专用文件夹中)。

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

最近，我注意到我们在AWS计费资源管理器中的ListBucket API操作有所增加。这一成本高于StandardStorage的成本(我们为存储数据本身所付出的代价)。一个月就有几百人！

运行具有调试日志级别的历史服务器暴露了“问题”：每10s历史服务器列表中列出了获取所有日志的桶，然后遍历每个文件夹以获得它的内容。因此，如果我想保留最后的10,000个工作，我将不得不支付10,101个ListBucket请求每10！

这里有一个用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设置为更高的数量(比如3600 s左右)。当我们每天检查一次历史服务器时，这样做是过分的，不值得(按成本计算)。

• 为什么它每次扫描已完成的作业(一遍又一遍)，而不仅仅是新的工作？是否有方法来配置这样的行为以避免那些ListBucket操作？
• 如果我只关心已完成的任务，并且假设我可以等待几分钟才能看到列表，那么是否有一种模式可以只在我登录到UI时加载列表？(而不是无缘无故地定期做)。

P.S -我每隔几天使用AWS 生命周期规则清理这个文件夹(而不是服务器清理功能)，几天后由过期对象清理。

Answer 1

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

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

从spark-submit命令，成本现在恢复正常.我还写了关于它的这里。

@stevel谢谢你的回答--我会尽力做贡献并修复这个问题！:)

Answer 2

在s3中植树造林是(a)昂贵和(b)可怕的缓慢，特别是考虑到一个深树扫描存在。如果您想要修复这个问题，并且可以编写scala代码，请查看是否可以通过移动到FileSystem.listFiles(path, true)来修复服务器以切换到深度列表。是的，这涉及编码，但开放源码软件社区依赖于每个人解决自己的个人问题并分享结果。