为什么Presto比Spark SQL更快

Question

为什么Presto比Spark SQL更快？Presto和Spark SQL在计算架构和内存管理方面有什么区别？

Answer 1

一般来说,很难说Presto肯定比Spark SQL更快或更慢.这实际上取决于您正在执行的查询类型,环境和引擎调整参数.但是,我在业界看到的(Uber,Neflix示例)Presto用作ad-hock SQL分析而Spark用于ETL/ML管道. 

一种可能的解释是,为Presto安排查询没有太多开销.Presto协调器始终处于启动状态并等待查询.另一方面,Spark正在做懒惰的方法.驱动程序需要时间与集群管理器协商资源,复制jar并开始处理.

另一个是Presto架构非常简单.它有一个协调器,可以执行SQL解析,计划,调度和一组执行物理计划的工作人员.

另一方面,Spark核心之间有更多层.除了Presto拥有的阶段之外,Spark SQL还必须应对RDD的弹性构建,为作业进行资源管理和协商.

另请注意,Spark SQL具有基于成本的优化程序,可在复杂查询上执行更好的操作.虽然Presto(0.199)有一个遗留的基于规则的优化器.目前正在努力将CBO引入Presto,这可能有可能击败Spark SQL性能.

Answer 2

我认为关键的区别在于Presto的体系结构与MPP SQL引擎非常相似.这意味着仅针对SQL查询执行进行了高度优化,而Spark是一个通用执行框架,能够运行多个不同的工作负载,如ETL,机器学习等.

此外,Presto的一个权衡因素是实现SQL查询的较低延迟,而不关心中间查询容错.如果其中一个Presto工作节点出现故障(例如,关闭),则大多数情况下正在进行的查询将中止并需要重新启动.另一方面,Spark支持中间查询容错并且可以从这种情况中恢复但是为了做到这一点,它需要做一些额外的簿记并且基本上"计划失败".当您的群集没有遇到任何故障时,这种开销会导致性能降低.

Answer 3

立场：Presto强调查询，但引发对计算的强调。

内存存储：都是内存存储和计算，当无法获得足够的内存时，spark会将数据写入磁盘，但会导致OOM。

任务，资源：spark在每个阶段实时提交任务并实时申请资源（与presto相比，此策略可能会导致处理速度稍慢）；Presto申请所有必需的资源，并一次提交所有任务。

数据处理：在Spark中，数据需要经过完全处理才能进入下一阶段。Presto是一种批处理（页面）管道处理模式。只要页面完成，就可以将其发送到下一个任务（此方法大大减少了各种查询的端到端响应时间）。

数据容错性：如果spark失败或丢失数据，将根据亲属关系重新计算。但是presto将导致查询失败。