问题描述
关于应用程序有 4 个主要操作（jdbc 写入），并且很少计数，总共需要大约 4-5 分钟才能完成。 但应用程序的总正常运行时间约为 12-13 分钟。
我看到有些作业在 ThreadPoolExecutor.java 上运行：1149。就在这个作业反映在 Spark UI 上之前，发生了不可见的长时间延迟。
我想知道这些延迟的可能原因是什么。 我的应用程序正在读取 8-10 个 CSV 文件，从表中读取 5-6 个视图。加入的数量大约为 59，有几个带有 agg(sum) 的 groupBy，有 3 个联合。
我无法在 DEV/UAT env 中重现该问题，因为数据并不多。 它在我获得应用程序的生产环境中。由我的经理执行。
如果有人在他们的工作中遇到过这样的延迟，请分享您的经验，这可能是导致这种情况的潜在原因，目前我正在与工会合作，即缓存相关的数据帧并调用计数，以便从中受益在即将到来的联合中缓存（尚未测试，如果联合是延迟的原因）
同样，我尝试使用缓存和计数来打破长链的转换以打破长的血统。 时间从最初的18分钟减少到12分钟，但隐形延迟问题依然存在。
提前致谢
解决方法
我假设您的 Spark 作业之间没有 CPU 或 IO 繁重的代码。
所以它真的很有趣，99% 是 QueryPlaning 延迟。
您可以使用
spark.listenerManager.register(QueryExecutionListener) 检查查询计划性能的不同指标。