前言：
Presto是由 Facebook 推出的一个基于Java开发的开源分布式SQL查询引擎，适用于交互式分析查询，数据量支持GB到PB字节。Presto本身并不存储数据，但是可以接入多种数据源，并且支持跨数据源的级联查询。
为何是SQL查询引擎？而不是数据库
和Oracle、MySQL、Hive等数据库相比，他们都具有存储数据和计算分析的能力。如MySQL具有 InnoDB存储引擎和有SQL的执行能力；如Hive 有多种数据类型、内外表（且这么叫）的管理能力，且能利用MR、TEZ执行HQL。而Presto并不直接管理数据，他只有计算的能力。
Presto 支持的数据源
常见的RDBMS都支持，如：Oracle、MySQL、PG等；
NoSQL：MongoDB、Redis、ElasticSearch 等；
大数据：Hive、HBase（第三方）、Kudu、Kafka 等；
Presto 支持从多种数据源获取数据来进行运算分析，一条SQL查询可以将多个数据源的数据进行合并分析。如如下SQL：a可以来源于MySQL，b可以来源于Hive。
select a.*,b.* from a join b on(a.id = b.id)
Presto 优势&特点
1.多数据源、混合计算支持：支持众多常见的数据源，并且可以进行混合计算分析；
2.大数据：完全的内存计算，支持的数据量完全取决于集群内存大小。他不像SparkSQL可以配置把溢出的数据持久化到磁盘，Presto是完完全全的内存计算；
3.高性能：低延迟高并发的内存计算引擎，相比Hive（无论MR、Tez、Spark执行引擎）、Impala 执行效率要高很多。根据Facebook和京东的测试报告，至少提升10倍以上；
4.支持ANSI SQL：这点不像Hive、SparkSQL都是以HQL为基础（方言），Presto是标准的SQL。用户可以使用标准SQL进行数据查询和分析计算；
5.扩展性：有众多 SPI 扩展点支持，开发人员可编写UDF、UDTF。甚至可以实现自定义的Connector，实现索引下推，借助外置的索引能力，实现特殊场景下的 MPP；
6.流水线：Presto 是基于PipeLine进行设计，在大量数据计算过程中，终端用户(Driver)无需等到所有数据计算完成才能看到结果。一旦开始计算就可立即产生一部分结果返回，后续的计算结果会以多个Page返回给终端用户（Driver）。
Presto 应用场景
1.实时计算：Presto 性能优越，实时查询工具上的重要选择。
2.Ad-Hoc查询：数据分析应用、Presto 根据特定条件的查询返回结果和生成报表。
3.ETL：因支持的数据源广泛、可用于不同数据库之间迁移，转换 和 完成 ETL 清洗的能力。
4.实时数据流分析：Presto-Kafka Connector 使用 SQL对Kafka的数据流进行清洗、分析。
5.作为MPP：Presto Connector 有非常好的扩展性，可进行扩展开发，可支持其他异构非SQL查询引擎转为SQL，支持索引下推。
数据模型
Presto 使用 Catalog、Schema和Table 这3层结构来管理数据。如图：
1.Catalog：就是数据源。每个数据源连接都有一个名字，一个Catalog可以包含多个Schema，大家可以通过show catalogs 命令看到Presto已连接的所有数据源。
2.Schema：相当于一个数据库实例，一个Schema包含多张数据表。通过以下方式可列出catalog_name下的所有 Schema：
show schemas from 'catalog_name'
3.Table：数据表，与RDBMS上的数据库表意义相同。通过以下方式可查看’catalog_name.schema_name’下的所有表：
show tables from 'catalog_name.schema_name
在Presto中定位一张表，一般是catalog为根，例如：一张表的全称为 hive.test_data.test，标识hive(catalog)下的 test_data(schema)库中 test 表。
可以简理解为：数据源的类别.数据库.数据表。
可使用：show catalogs查看数据源；show schemas from hive查看数据库实例；show tables from default查看表。
切换当前使用的实例（在同一个数据源内切换无需指定catalog 前缀）：use hive.default
Presto接入方式
Presto的接入方式有多种：presto-cli，pyhive，jdbc，SQLAlchemy 等，其中presto-cli 是Presto官方提供的，下面以presto-cli为例展开说明(自行到https://prestosql.io/download.html下载，presto-cli 应和 presto-server 版本相匹配），下载后把 presto-cli-${ver}-executable.jar 移动到 presto_home/bin 下：
mv presto-cli-${ver}-executable.jar prestochmod +x presto
以连接hive数据源为例，在终端输入：
./presto --server host:8088 --catalog hive --schema default
先解释下各参数的含义：
- —server 是presto服务地址；
- —catalog 是默认使用哪个数据源，后面也可以切换；
- —schema hive 数据源内的 default 库，可切换；
Presto 采用 Connector 对接第三方数据源，一个 Connector 便能提供一种新的 catalog
Presto中文使用手册：http://prestodb.jd.com/docs/current/index.html
Presto 整体架构
1.Client：包括 prosto-cli 客户端以及 JDBC 驱动、ODBC 或 其他语言实现的Driver；
2.Discovery Service：是将 coordinator 和 worker 结合到一起的服务。Worker 节点启动后向Discovery Server 服务注册，Coordinator 从 Discovery Server 获得可以正常工作的 Worker 节点；
3.Coordinator：主要用于接收客户端提交的查询，解析查询语句，执行词法分析生成查询执行计划，并生成Stage 和 Task 进行调度；然后合并结果，把结果返回给客户端（Client）；
4.Worker：主要负责与数据的读写交互以及执行查询计划；
Coordinator 和 Worker 可一起启动，这样小规模的集群或伪分布式可以节省一些资源。
coordinator=truenode-scheduler.include-coordinator=truehttp-server.http.port=8088discovery-server.enabled=truediscovery.uri=http://server:8088
单独启动 Coordinator：
coordinator=truenode-scheduler.include-coordinator=falsehttp-server.http.port=8088discovery-server.enabled=truediscovery.uri=http://server:8088
另一台节点启动 Worker：
coordinator=false# 如果在同一节点启动两个服务，该端口号要换http-server.http.port=8088discovery.uri=http://server:8088
Presto SQL执行步骤
1.客户端通过 HTTP 发送一个查询语句给Presto集群的Coordinator；
2.Coordinator 接收到客户端传来的查询语句，对该语句进行解析、生成查询执行计划，并根据查询执行计划依次生成 SqlQueryExecution -> SqlStageExecution -> HttpRemoteTask；
3.Coordinator 将每个Task分发到所需要处理的数据所在的Worker上进行分析；
4.执行Source Stage 的 Task，这些Task通过Connector从数据源中读取所需要的数据；
5.处于下游的Stage中用的Task会读取上游的Stage产生的输出结果，并在该Stage的每个Task所在的Worker内存中进行后续的计算和处理；
6.Coordinator 从分发的Task之后，一直持续不断的从Single Stage 中的Task获得计算结果，并将结果写入到缓存中，直到所所有的计算结束；
7.Client 从提交查询后，就一直监听 Coordinator 中的本次查询结果集，立即输出。直到轮训到所有的结果都返回，本次查询结束；
实际上一个执行过程非常复杂，更过详细过程请见下期的《Presto查询执行过程和索引条件下推分析》文章。
为何 Presto 能有较高的查询性能？
1.得益于 YARN 调度的慢。YARN 的定位是一个通用的资源管理系统。但是无论是 Hive 采用 MR、TEZ 何种引擎，执行 SQL时，每个执行算子都在 Yarn Container 中运行，而 Yarn 拉起 Container 性能特别低（秒级）。这犹如应用程序在拉起进程和开启多线程一样。线程更轻量级，简单的运算开启线程的速度更快，加速更明显；而启用进程则要笨重的多，还容易受到操作系统限制。而 Presto 调度的确就是用了线程，而不是进程。
2.Presto 的Coordinator/Worker 架构更像 Spark Standalone 模式，只在两个进程和服务中完成。但是Spark更多侧重于 SparkRDD之间依赖关系，Stage失败线性恢复等功能导致有较大开销。Spark Input也直接依赖Hadoop InputFormat API，导致SparkSQL在运行时，并不能把 SQL 优化细节传导到 InputFormat。Presto 弃用 Hadoop InputFormat，但采用类似的数据分区技术，并且可以把 SQL 经过解析后，把Where 条件生成 TupleDomain 传递给 Connector。Connector 能根据字段元数据采用一定程度的索引下推，利用底层系统的索引能力，大大减少数据扫描区间和参与计算的数据量。
3.Presto 是完全基于内存的并行计算，他不像 Hive MR/TEZ 需要把中间数据写盘、Spark 需要把溢出的数据写盘，Presto 是完全假设数据能有效的放入内存。再者，得益于Presto流水线式的作业计算能力，在很多 SQL 执行时通过分析SQL的执行计划，能把立即展现的数据立即返回。这也是给用户一种很快的“假象”。但这种“假象”也是无可厚非的，我们即便是从一个结果中提取大量数据，也是遍历游标，等到我们遍历到那个位置，后续的结果数据已经源源不断的计算完成，并不影响我们获得结果。
Presto 发行版
Presto 到目前为止 Presto 有两大分支: PrestoDB 和 PrestoSQL。两个发行版都满足基本功能，只是在技术细节有细微差别。如底层通信方式、对部分文件的读取速度。总的来说，各有优劣。
PrestoDB: 根红苗正，有大厂支持；
PrestoSQL: Prestodb 之父的原班人马支持，社区更活跃；
在贸易战战火未消退的当下，也有很多企业关注License，两者都是 Apache V2 License。但是PrestoDB由 Facebook、Alibaba、Twitter等共同成立的基金会控制，PrestoSQL 是由新成立的Presto开源基金会管理，因此 PrestoSQL 也许更能符合国内企业选择。还有一个选择，Presto-JD（京东的分支版本）。
OLAP 众多，如何选型
OLAP 引擎，耳熟能详的当前有十几种之多，令人眼花缭乱。下图为第三方测试报告(来源：https://blog.csdn.net/weixin_33724659/article/details/89548867)。
通过编制综合对比分析表，这里采用5分为满分来比较，如下表：
综合来看，Presto 是一款不可多得的、开源的 OLAP 分析引擎工具。
精选提问：问1：presto在大数据平台中扮演什么角色，他对标的主流产品有哪些？答：这个问题应该先回答对标产品，有了定位才能确定角色。Presto 首先是一个 OLAP 引擎，从OLAP范围他可对标Hive，SparkSQL、Impala、Apache Kylin、Apache Kudu 这类。实际上Presto 可以代理多种数据源，因此可以作为多种数据库的代理层，尤其是需要夸多种数据源执行SQL的场景。问2：业界应用Presto的成熟架构方案可以介绍下嘛？答：国内京东、美团很早就在使用，Presto京东版本（http://prestodb.jd.com/），国外 Facebook、Dropbox等互联网公司。Presto目前中文技术资料已经很多，可以从互联网上获得。
若有收获，就点个赞吧
0 人点赞
