image.png

之前一直以为presto基于内存的计算可以加速关系数仓的性能，本地部署presto连接阿里云pg测试后发现他的运行机制是把pg的数据读取到presto再提供，这样增加了传输成本，用一个大表进行了测试，两个窗口叠加执行同一个脚本，发现也没有提高性能。后来在知乎上看到一个文章的场景应该能更好说明他的作用。 可能对我们最有用的作用1：是etl，统一数据源。 可能对我们最有用的作用2：低成本连接数据中台与业务库的实时数据，比如数仓维度表+业务系统实时表。

Presto的使用场景：

Presto是定位在数据仓库和数据分析业务的分布式SQL引擎，比较适合如下几个应用场景：

  • 加速Hive查询。Presto的执行模型是纯内存MPP模型，比Hive使用的磁盘Shuffle的MapReduce模型快至少5倍。
  • 统一SQL执行引擎。Presto兼容ANSI SQL标准，能够连接多个RDBMS和数据仓库的数据源，在这些数据源上使用相同的SQL语法和SQL Functions。
  • 为那些不具备SQL执行功能的存储系统带来SQL执行能力。例如Presto可以为HBase、Elasticsearch、Kafka带来SQL执行能力，甚至是本地文件、内存、JMX、HTTP接口，Presto也可以做到。
  • 构建虚拟的统一数据仓库，实现多数据源联邦查询。如果需要计算的数据源分散在不同的RDBMS，数据仓库，甚至其他RPC系统中，Presto可以直接把这些数据源关联在一起分析（SQL Join），而不需要从数据源复制数据，统一集中到一起。
  • 数据迁移和ETL工具。Presto可以连接多个数据源，再加上它有丰富的SQL Functions和UDF，可以方便的帮助数据工程师完成从一个数据源拉取(E)、转换(T)、装载(L)数据到另一个数据源。


    Presto的企业案例：

  1. Facebook

Facebook 在全球有超过10亿的用户，它的数据仓库中数据的规模非常大，在2013年就已经超过30PB。这些数据的用途非常广泛，从离线批处理到图计算、机器学习，还有交互式查询。
2008年，Facebook开源了Apache Hive，计算模型基于MapReduce，使用SQL来表达计算落，算是海量数据计算的一次非常大的进步。Hive在Facebook内部也有大规模的应用，Hive的优势是能够应对超海量数据、运行稳定、吞吐量大。
然而，对于数据分析师、PM、工程师来说，查询的速度越快（不要等一杯茶的时间），能够处理数据越多，交互式能力越强，他们的数据分析效率也就更高。基于海量数据的快速交互式查询的需求，越来越迫切。
2013年，Facebook完成了Presto的研发及生产环境的落地，搭建了几十个Presto集群，总节点数超过10000，为300PB的数据赋予了快速交互式查询的能力。
据公开披露的Facebook官方Presto论文描述，Presto在Facebook的几个主要使用场景如下：
（1）交互式分析
Facebook工程师和数据分析师经常需要在一些数据集(一般压缩后有50GB到3TB)上分析，验证猜想，绘制图表等。单个Presto集群需要至少支持50-100的并发查询，秒级的查询时延。这些交互式分析需求的用户，更关系查询执行的快慢，而不是占用资源的多少。
（2）ETL
数据仓库经常需要定时根据SQL逻辑从上游表生成下游表（例如数据仓库中的分层设计中，从ODS表到DW表，从DW表到DM表），在这种场景下，Presto可以用来执行长时间运行的SQL ETL Query，任务的计算逻辑需要完全用SQL来表达。类似下面的SQL：
INSERT INTO dw_order_analysis … SELECT category, region, sum(price) as price_sum, count(1) as order_cnt FROM ods_order_detail WHERE country = ‘China’ GROUP BY category, region ORDER BY price_sum
当你这么使用Presto的时候，其实与跑SparkSQL，FlinkSQL没有太大区别。这里需要有一个任务调度系统来定时调起Presto SQL。类似的ETL Query在Facebook很常见，它们经常处理TB级别的数据，占用比较多的CPU和内存资源，Query执行耗时不像交互式Query那样重要，更重要的是提高数据处理的吞吐。
（3）A/B测试
A/B测试是企业用来量化产品中不同功能带来不同影响的方法。在Facebook，大部分A/B测试的基础设施都构建在Presto之上。分析师和PM需要需要在A/B测试结果上做多种分析，这些分析很难通过数据预先聚合的方式来提高查询速度。
（4）开发者/广告主分析
有很多面向Facebook外部开发者和广告主的报表工具是基于Presto建设的。例如Facebook Analytics3，它是给那些使用Facebook Platform构建应用的开发者分析数据用的。类似的应用，因为暴露出的是特定的WebUI查询入口，Query的模式基本上是固定的，大部分有Join、聚合、窗口函数中的一种。虽然整体数据量非常大，但是Query中的Filter条件过滤后，实际参与计算的数据不多，如广告主只能查看他自己的广告，有一种特例就是遇到了大广告主。为这些开发者或者广告主提供的数据分析服务，查询时延要求一般都是在50ms到5s之间，Presto集群必须要保证5个9的可用性，并且要支持几百个Query不同用户并发请求。
2. Amazon Athena
Amazon Athena 是基于Presto搭建的一种交互式查询服务，运训用户使用标准 SQL 分析 Amazon S3 中的数据，具备 SQL 技能的任何人都可以轻松快速地分析大规模数据集，查询结果一般都在数秒内返回，在AWS上Athena作为一个大数据商业服务提供给商业付费客户。
类似的，阿里云也对外开放了商业化的Presto服务，支持即买即用分分钟完成上百节点的Presto集群搭建，并且与阿里云的其他产品如EMR完美结合，支持处理存储在OSS的数据。
3. 京东
在Ad-Hoc需求中，京东起初调研过SparkSQL、Impala和Presto，最终选择了Presto，并持续改进源码，迭代出了京东自己的JD-Presto版本，后续也有部分功能回馈了社区，JD-Presto团队时国内首批Presto源码的贡献者。在京东企业内部，有近二十多个系统在使用JD-Presto版本，尤其是在精准营销平台中JD-Presto作为大数据Ad-Hoc计算平台，启动了关键性作用，极大提升了采销部门进行精准营销活动的效果和效率。JD-Presto团队出版过可能是世界上唯一一本专门介绍Presto原理和源码的书籍《Presto技术内幕》。庆幸的是，在2021年，笔者计划出版世界上第二本深入Presto的书籍，希望通过它让读者能够更加全面深入了解Presto。
4. 美团
美团在2014年在Hadoop集群上搭建了Presto来服务于公司内部的分析师、PM、工程师。他们曾经选取了平时的5000个Hive查询，通过Presto查询的对比发现Presto的总查询时间消耗是Hive的1/5左右，这个效果还是很明显的。
5. 乐视云计算
笔者曾经在乐视的云计算公司，负责搭建、维护生产环境1500+台Hadoop集群，上面的YARN节点上跑了有几十个Presto集群（集群规模从5个节点到400个节点都有）。不同的Presto集群为不同的业务服务，有CDN运维质量分析、风控安全、视频服务的数据分析等，Presto用于支撑这些业务的Ad-Hoc查询以及报表类查询，查询响应Pct99在3s以内。
在这里也说明一下Presto本身是不支持直接在YARN上的，需要使用Slider来部署，为了在同一台YARN宿主机上部署多个Presto节点，笔者修改了Slider生成Presto配置的方式，支持了多端口部署。
6. 其他公司
其实国内国外还有很多公司在生产环境中使用Presto，如Twitter，Airbnb、滴滴、小米等，因为公司信息安全问题，他们大多没有对外纰漏详情，如果你感兴趣，可以参加InfoQ等大型技术会议，来获取最新动态。

Presto不适合做哪些事情？

  1. 完全替代HiveSQL（MapReduce）

Presto在提供更高的并发Query，更低的查询延迟上，确实比Hive强很多，大部分测试都显示Presto执行SQL的速度，是Hive的5倍以上。然而，这并不意味着Hive就应该退出历史，毕竟Presto的计算主要依靠内存，当数据量非常大时，超过了整个Presto集群中单个Query允许的内存大小，Presto容易出现OOM，相比之下Hive更稳定。虽然Presto官方正在做Spill To Disk的功能，但是如果数据计算过程中有大量的Spill To Disk操作，磁盘IO势必会成为瓶颈，而大大影响Query的执行速度。Presto之所以快，是需要给到足够的CPU和内存资源的，对于那些对时延要求不高的Query，Hive可以使用非常小的资源持续稳定的运行数小时甚至数天最终给出结果，而这点Presto做不到。Hive仍然是数据计算高吞吐、低成本、高稳定性的代言，所以建议在生产环境中，让Presto和Hive形成合理分工，优势互补，而不是由谁来淘汰谁。
2. 分析型的在线服务
分析型的在线服务指的是某类数据统计服务，但是它查询模式相对固定（虽然是多维度，多指标，但是维度指标相对固定），这个服务的用户基数比较大（一般到10W以上）。如：广告主的广告投放分析，比特币交易平台的C端用户交易统计，淘宝店主的生意参谋、销售数据分析等。在这些系统，用户并发查询的QPS还是蛮高的。
分析型的在线服务的特点是它需要查询引擎能够做到高并发、低延迟。高并发指的是单集群QPS能够支撑到1000以上，查询延迟Pct99一般在800ms以下（如果查询超过800ms，再加上系统的其他时间开销，用户看到的页面加载会很慢，体验不好）。
这些在线服务的用户的查询特征是相对简单的多维度条件过滤、多指标聚合 ，没有特别复杂的逻辑（如复杂的Join）。这种场景下，使用Druid，Elasticsearch更靠谱，用Presto不合适。理由是Druid，Elasticsearch的Query执行模型是scatter-gather（相当于一次Map，一次Reduce），比较简单，也没有复杂的执行计划生成和优化逻辑，任务的调度很简单，整体花在查询调度的CPU和线程开销较小。Presto是基于SQL的MPP模型，Query执行模型相对复杂。
3. OLTP
Presto是OLAP引擎，它的设计决定了不能当作MySQL来用。首先Presto要操作的Connector实现了相关接口，它是可以支持Insert和Delete的，但是不支持Update。其次当数据在Presto Worker的内存中被传输和处理时，它是以列示存储的方式存在的，这不便于执行OLTP系统中对整行的CRUD操作。最后，Presto对事务的支持并不好，而这是MySQL的基本能力。
有的技术方案，如TiDB和阿里的AnalyticDB，尝试融合OLTP与OLAP系统，形成HTAP，即兼备了两种系统的功能，两边好处都占上，但是其本质仍然是很大程度上分别实现了OLTP和OLAP。说实话，在大部分生产环境中，很少有必须要用HTAP的理由。
4. 替代Spark、Flink
Spark和Flink是很难被Presto替代的，反过来，Presto也很难替代Spark和Flink。归根结底，他们不是同类型的技术，解决的不是完全相同的问题，虽然确实是有重叠的部分，例如三者都可以在各种数据源上执行SQL。
Spark、Flink擅长的是提供比SQL更丰富的编程API完成业务计算逻辑，他们有一个突出的强项是流式计算。你也可以启动长期运行的Spark或者Flink集群，接入交互式的SQL客户端，但是至少目前为止，他们调度和执行SQL的时延都比Presto要长，而且能够支撑的QPS也比Presto更少。目前为止，还没有听说哪家企业把BI报表应用直接跑在Spark和Flink集群上。在2019年的Flink Forward Asia大会上，阿里的Flink官方宣布也在尝试参考Presto来增加OLAP的能力，但是短期内必定不会有大的成效。