媒体与新闻
转载本文需注明出处:微信公众号EAWorld,违者必究。
前言:
为何是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 优势&特点
Presto 应用场景
数据模型
Presto 使用 Catalog、Schema和Table 这3层结构来管理数据。如图:
1.Catalog:就是数据源。每个数据源连接都有一个名字,一个Catalog可以包含多个Schema,大家可以通过show catalogs 命令看到Presto已连接的所有数据源。
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
先解释下各参数的含义:
Presto 整体架构
coordinator=true node-scheduler.include-coordinator=true http-server.http.port=8088 discovery-server.enabled=true discovery.uri=http://server:8088
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 能有较高的查询性能?
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 发行版
OLAP 众多,如何选型
关于作者:震秦,普元资深开发工程师。专注于大数据开发 8 年,擅长 Hadoop 生态内各工具的使用、优化和部分定制开发。曾参与国内多省市公安项目实施,负责大数据数仓设计、批处理和调度工具实现。
关于EAWorld:微服务,DevOps,数据治理,移动架构原创技术分享。长按二维码关注!