1.3 再谈对Presto技术发展的理解

除非项目使用的技术是跨时代的，不然判断一个开源项目能不能持续流行时技术因素是起不到决定性作用的。《孙膑兵法·月战》说“天时、地利、人和，三者不得，虽胜有殃”，即天时、地利、人和共同决定了一个目标能不能达成。现在业界有数十个OLAP引擎可供用户选择，如果Presto项目希望自己能够持续流行且得到用户的青睐，它的天时、地利、人和是什么呢？天时，可以理解为Presto项目的出现及存在是否顺应当时用户的主流需求；地利，可以理解为Presto使用的技术及架构是否优秀；人和，可以理解为Presto的开源社区、研发及商业化运营的人员组织是否完整、高效、一致。

2013年前后业界只有基于MapReduce的离线批式计算的分布式Hive引擎和传统单机数据库，Presto的横空出世填补了大规模分布式快速内存计算的空白。Presto教科书式的分布式计算设计被后继者持续模仿，彼时顺应了天时。作为大数据领域从业者，2018年后，笔者观察到几个明显的趋势。

❑ OLAP引擎在数据探查分析上功能已经较完备。越来越多的企业用户对查询的延迟、并发能力提出了更高的要求，ClickHouse、Doris等项目迎合了这种趋势。

❑ OLAP引擎更趋向于统一的数仓存储与计算架构。通过Kafka、Spark、Flink这些流式或离线技术将原来分散在各种数据库、服务器、API服务的海量数据汇聚到同一个数据仓库中，使用统一的OLAP引擎来做查询计算。OLAP引擎对接同一个数据仓库不需要考虑如何对接多种数据源的难题，这种场景下，Presto支持接入多数据源连接器的优势被严重削弱——用户不需要对接多个数据源了。

在第一个趋势上，Presto还在纠结自己的定位是传统离线数据仓库还是HSAP，至少在国内，它错过了HTAP、HSAP的融合趋势；在第二个趋势上，Presto失去了自身的优势；在天时上，我们发现这些年Presto走得慢了，没跟上节奏。某个产品或项目不顺应天时意味着它将失去很多用户，而另外一些顺应天时的产品将从它手中抢走很多用户。

在地利上，有些读者在纠结Presto是不是已经落后于ClickHouse、Doris等。我的观点是完全没有，到目前为止Presto的设计实现仍然是很优秀的，ClickHouse、Doris、ES的技术一定程度上都参考借鉴了Presto，业界做OLAP引擎性能测试时也时常把Presto作为比较对象。简单地说，数据库领域已经有近20年没有出现跨时代的技术了，大家都是互相借鉴参考，都是一个层次的，就看谁能投入更多的资源把每个细节做好，在这方面Presto完全可以做到，就看它走得是否足够快了。在近5年的OLAP引擎技术发展上，下面几点给人的印象深刻。

❑ Presto的设计思想就如它几年前发布的论文标题一样“SQL on Everything”（所有计算需求都可以用SQL查询来执行），可将任意的数据源都抽象成关系型数据模型，并允许在不同的数据源上执行联合查询，类似的设计理念深深地影响了Spark、Flink这样的计算引擎。在这方面Presto一直走在最前面。

❑ 过去的20年，随着软硬件技术的发展，进行海量数据计算时数据读取、序列化和反序列化的IO瓶颈在减少，CPU的瓶颈在逐渐凸显，基于JVM构建的OLAP引擎在CPU运行效率上明显不如直接用C/C++语言开发并利用CPU SIMD指令的OLAP引擎执行效率高，典型的案例是用户普遍对ClickHouse查询的执行速度大加赞扬。Facebook将一个C++编写的Velox项目作为比JVM更偏系统底层的执行引擎（Native Execution Engine）来提高Presto的查询执行速度。“底层执行引擎”概念是相对基于JVM的Java编程的OLAP引擎来说的，像ClickHouse这种引擎其本身就是用C++编写的，所以就没有底层执行引擎的概念。

❑ 数据模型、数据分布、数据在存储介质中的编码方式（Encoding）也会较明显影响查询速度。如果你有深入优化OLAP引擎查询执行速度的经验，必定会认同这个观点：查询执行的快慢不仅是由Presto这样的计算层决定的，组织数据的数据模型、数据在存储中的分布特性也起到了关键作用。例如数据模型设计得不好会导致查询需要做更多的JOIN，性能自然会更差。再例如小数据量的表在存储中分区存储后分区过多，看起来可以增加计算的并发量，实际上整体执行效率反而更糟糕，这也是为什么在小数据量计算的场景中，MySQL这样的单机数据查询系统的延迟反而比Presto这种分布式执行的OLAP引擎小很多的。除了数据模型、数据分布这两个显著的影响因素，数据在存储介质中的编码方式对查询性能的影响也非同小可，例如列式格式、数据类型、数据分块、索引等。总而言之，存储和计算是要密切配合的，要协同优化。例如Doris、ClickHouse、Elasticsearch都在做类似的事情。查询慢要么是IO多或IO慢，要么是计算量大或者存在无意义的计算开销，其中IO问题往往比计算问题更显著。而Presto只是一个计算方案，从存储介质拉取数据的IO性能它完全无法干预，Presto在很多场景下成为存储IO的“背锅侠”！现在比较流行的存算分离与这里提到的存算密切合作并不矛盾：存储与计算可以分开部署，各自扩缩容，但是两者一定要协同优化，一起提高查询执行的IO效率与CPU效率。因此想要显著提升Presto查询速度或者让其支撑更多的查询QPS，研发好或者选择好对应的数据存储服务是非常重要的，单纯依靠HDFS绝对不是一个好的方案。

最后再谈谈人和。Presto的3位核心开发者之所以离开Facebook，原因可能是那几年Kafka、Elasticsearch、Spark、Flink等项目背后的公司融资的融资，上市的上市，赚得盆满钵满，而Presto在Facebook的发展不及预期；也可能是3位大佬与管理层对Presto在资源投入与发展路线方面无法达成一致。实际上大树下面不一定好乘凉，要看抱的是哪棵大树。做一个善意的假设，如果我是Presto的创始人，一定会在早时脱离Facebook，加入Apache的怀抱，因为这里孕育了Hadoop、Spark、Flink、Kafka、Doris等巨星。最后再谈谈商业化运行，这也算是人和，因为商业化拼的就是影响力、营销、本土化，这些都是与人相关的。现在技术同质化越来越严重，谁又能有明显的技术优势呢？用户很难会因为某个产品技术优秀而选择它，最终都会落到商业化运营上。现在Trino（原名PrestoSQL）已经在人和上努力了，加快节奏吧！

本书将回归Presto技术本身，让我们一起学习Presto像诗一样的设计与实现吧。