presto sql 报错_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过去了。