首发于城南旧事

PrestoDB VS PrestoSQL发展比较

最近PrestoDB成立了依托于Linux Fundation之下的一个基金会,到此为止Presto的两大分支: PrestoDB和PrestoSQL都成立了自己的基金会,我比较好奇在这分道扬镳的一年时间内两个分支发展的究竟怎么样,因此从公开的信息做了一些收集统计。


项目活跃度

首先我们从项目活跃度的角度看看两个项目的各项指标,第一个是分道扬镳之后各自的提交次数:

再看看参与贡献的人数

再看看发布的新版本的个数


从以上三个指标可以看出,在项目活跃度上PrestoSQL要比PrestoDB更活跃。

重要的功能特性

Coordinator和Worker之间支持了二进制的通信方式[PrestoDB]

二进制的通信方式使得通信的效率更高,降低Coordinator的CPU和内存的使用率,当集群的QPS上升之后Coodinator与Worker之间通信方式的优化对于查询Latency的降低很重要。

SPI更新支持更多的pushdown[PrestoSQL, PrestoDB]

PrestoDB和PrestoSQL最近都在做的一件事情是把更多的计算pushdown到底层存储,因为底层存储比如mysql都具有一定的计算能力,通过把一些计算pushdown到底层存储可以使得从底层拉取的数据更少,提高整体查询的性能。

更快的S3读取速度 [PrestoSQL]

Presto在云上一个很大的应用场景就是对保存在Object Store里面的数据进行分析,社区发现Presto从S3实际读取的数据量比引擎统计出来的多好多倍,可见是什么地方多读了数据。David Phillips经过一番调研之后发现Presto在读取Parquet数据的时候会指定要读取的数据的具体的字节范围,从哪里开始读,到哪里结束。但是S3文件系统的实现没有做到这一点,它在实际向S3请求数据的时候只传了开始位置,没有传结束位置,因此从S3读取的数据并不是精确的那么多,会造成多读。而且这种Streaming的读取请求,在读取到足够数据之后没办法结束掉,只能把整个连接关掉,使得连接无法被复用,进一步降低了查询性能。PrestoSQL社区对这个问题的修复是实现了精确的按照指定区间读取,降低了扫描数据量的同时也使得连接可以复用。

ORC Reader的进一步优化[PrestoSQL]

在大数据处理里面,特别这种计算存储分离的场景,一个大数据计算相当的时间是花在从存储上扫描数据上,PrestoSQL对于ORC的数据读取进行了进一步优化,主要的优化点在于:

  • 对于之前每次单条读取改成了尽量批量读取
  • 对于循环中的方法调用避免dynamic dispatch

这些优化之后测试发现在TPC-H, TPC-DS上,读取速度提升了4% - 5%, CPU使用率降低了8% - 9%。

总结

从上面的分析可以看出,从各个方面的活跃度来看,PrestoSQL要比PrestoDB更活跃一点。两个社区各自都做了一些重大的更新,同时我们也看到两个社区也不是完全隔离的,一个社区作出了一个号的好的改进另外一个社区会及时的吸收过去,比如PrestoSQL对S3的读取速度进行了优化,PrestoDB也Cherry Pick过去了。

编辑于 2019-10-20

文章被以下专栏收录