我们用alluxio 对spark 进行基准测试，用alluxio 对presto 进行基准测试。为了评估性能，我们采用了 5 个不同的查询（带有一些连接、分组和排序）并在 orc 中的 650GB 数据集上运行它。
Spark 执行环境的设置方式是我们有一个一直在运行的 Spark 上下文，并且我们使用 REST api（Jetty 服务器）提交查询。我们没有考虑此负载测试的第一批执行时间，因为由于任务反序列化等原因，它花费的时间不多。
我们在评估时观察到，当我们运行单个查询甚至同时执行所有这 5 个查询时，与 presto 相比，spark 的性能非常好，并且完成所有执行的时间是 presto 的一半。
但是对于实际的负载测试，我们执行了 10 批（一批是这 5 个查询同时提交），批间隔为 60 秒。在这一点上，presto 的表现比 spark 好很多。Presto 在约 11 分钟内完成了所有工作，而 Spark 需要约 20 分钟才能完成所有任务。
我们尝试了不同的配置来提高 spark 并发性，例如
- 使用具有相同资源分配的 20 个池并以循环方式提交作业。
- 尝试使用一个 FAIR 池并将所有作业提交到此默认池，并让 spark 决定资源分配
- 调整一些火花属性，如
spark.locality.wait和其他一些与内存相关的火花属性。 - 所有任务都是 NODE_LOCAL（我们在 alluxio 中复制了数据来实现这一点）
- 还尝试过使用执行器内存分配，例如尝试使用 35 个小型执行器（5 核，30G），也尝试使用（60core，200G）执行器。
但所有这些都会导致相同的执行时间。我们dstat在所有工作人员上使用以查看 spark 执行任务时发生了什么，我们可以看到没有或看到最小的 IO 或网络活动。并且 CPU 总是在 95%+（看起来它受限于 CPU）。（用 presto 看到几乎相似的 dstat）
有人可以向我推荐一些我们可以尝试达到与 presto 相似或更好的结果的东西吗？
以及为什么 presto 在并发方面表现优于 spark 的任何解释？我们观察到 presto 的第一批比后续批次花费的时间更多。presto 是否在内存中缓存了一些 spark 丢失的数据？还是 presto 的资源管理/执行计划比 spark 好？
注意：两个集群都使用相同的硬件配置运行