presto配置

1、软件需求

（1）JDK1.8.0；

（2）maven3.6.3；

（3）MySQL5.7.35；

（4）presto0.257。

2、配置

（1）etc目录：

（2）catalog目录下是mysql.properties；

（3）config.properties：

（4）jvm.config：

（5）launcher：

（6）log.properties：

（7）node.properties：

（8）catalog/mysql.properties：

3台机器

CPU：Intel(R) Xeon(R) CPU E5-2640 v4 @ 2.40GHz   2U40核

MEM：256G

DISK：SSD

tidb环境为3台机器，3tikv+3pd+1tidb

    -- 1.1版本为1.1.0-alpha.1-77-g274a344

    -- 1.0版本为1.0.7

tispark配置为1master+2slave，tidb-ansible对应版本

presto为0.168 presto-mysql

mysql版本为5.7.20，innodb_buffer_pool_size为180G

测试工具为tpc-ds 2.7.0 scale为5

数据量如下：

(1)总结如下：

ANALYZE TABLE后1.1平均耗时为原耗时的80%，提升最大的SQL耗时仅为原来的45%

tidb1.1相比tidb1.0平均耗时为1.0耗时的50%，直接缩短一倍效率。。提升最大的SQL耗时仅为原来的18%

tidb1.1相比mysql平均耗时为mysql的40%，值得说明的是这个平均值是除去了很多mysql耗时10分钟以上的sql的，当然也有很多sql，mysql是优于tidb的

(2)详细如下：

1.图中 tidb1.1表示tidb1.1版本的结果， tidb1.1A表示tidb1.1版本执行ANALYZE TABLE后的结果， tispark为tispark执行结果， presto为presto执行结果，tidb1.0为tidb1.0版本执行结果，mysql为mysql执行结果

2.如果没有柱状图表示执行结果耗时10分钟以上

MapReduce不能满足大数据快速实时adhoc查询计算的性能要求，Facebook2012年开发，2013年开源

基于内存的并行计算，Facebook推出的分布式SQL交互式查询引擎 多个节点管道式执行

支持任意数据源 数据规模GB~PB 是一种Massively parallel processing（mpp）(大规模并行处理)模型

数据规模PB 不是把PB数据放到内存，只是在计算中拿出一部分放在内存、计算、抛出、再拿

多数据源、支持SQL、扩展性（可以自己扩展新的connector）、混合计算（同一种数据源的不同库 or表；将多个数据源的数据进行合并）、高性能、流水线（pipeline）

数据仓库 交互式略弱的查询引擎 只能访问HDFS文件 磁盘

但是presto是无法代替hive的

基于spark core mpp模式 详细课件spark sql一文

cube预计算

时序，数据放内存 索引 预计算

不适合多个大表的join *** 作，因为presto是基于内存的，太多数据内存放不下的

如果一个presto查询查过30分钟，那

就kill吧，说明不适合 也违背了presto的实时初衷

相当于MySQL的一个实例，

相当于MySQL的database

大内存、万兆网络、高计算能力

presto 查询引擎是一个Master-Slave的拓扑架构

中心的查询角色 接收查询请求、解析SQL 生成执行计划 任务调度 worker管理

coordinator进行是presto集群的master进程

执行任务的节点

presto以插件形式对数据存储层进行了抽象，它叫做连接器，不仅包含Hadoop相关组件的连接器还包括RDBMS连接器

具体访问哪个数据源是通过catalog 中的XXXX.properties文件中connector.name决定的

提取数据 负责实际执行查询计划

将coordinator和worker结合在一起服务；

worker节点启动后向discovery service服务注册

coordinator通过discovery service获取注册的worker节点

1、coordinator接到SQL后，通过SQL语法解析器把SQL语法解析变成一个抽象的语法树AST，只是进行语法解析如果有错误此环节暴露

2、语法符合SQL语法，会经过一个逻辑查询计划器组件，通过connector 查询metadata中schema 列名 列类型等，将之与抽象语法数对应起来，生成一个物理的语法树节点 如果有类型错误会在此步报错

3、如果通过，会得到一个逻辑的查询计划，将其分发到分布式的逻辑计划器里，进行分布式解析，最后转化为一个个task

4、在每个task里面，会将位置信息解析出来，交给执行的plan，由plan将task分给worker执行

1、如果某个worker挂了，discovery service 会通知coordinator

2、对于query是没有容错的，一旦worker挂了，query就执行失败了，与其在这里容错不如直接执行

3、coordinator 和discovery service 的单点故障问题还没有解决

---