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的企业案例：
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不适合做哪些事情？
- 完全替代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的能力，但是短期内必定不会有大的成效。
来源 https://zhuanlan.zhihu.com/p/260653669
