您可以捐助,支持我们的公益事业。

1元 10元 50元





认证码:  验证码,看不清楚?请点击刷新验证码 必填



  求知 文章 文库 Lib 视频 iPerson 课程 认证 咨询 工具 讲座 Model Center   Code  
会员   
   
 
     
   
 订阅
  捐助
presto 0.166概述
 
作者:Super_Orco
 
  507  次浏览      51
2020-6-12  
 
编辑推荐:
本文主要介绍了 Presto 的presto基本架构,Presto中SQL运行过程,Presto监控和配置,大数据OLAP引擎对比等相关内容。
本文来自csdn,由火龙果软件Anna编辑、推荐。

presto是什么

是Facebook开源的,完全基于内存的并?计算,分布式SQL交互式查询引擎

是一种Massively parallel processing (MPP)架构,多个节点管道式执?

持任意数据源(通过扩展式Connector组件),数据规模GB~PB级

使用的技术,如向量计算,动态编译执?计划,优化的ORC和Parquet Reader等

presto不太支持存储过程,支持部分标准sql

presto的查询速度比hive快5-10倍

上面讲述了presto是什么,查询速度,现在来看看presto适合干什么

适合:PB级海量数据复杂分析,交互式SQL查询,?持跨数据源查询

不适合:多个大表的join操作,因为presto是基于内存的,多张大表在内存里可能放不下

和hive的对比:

hive是一个数据仓库,是一个交互式比较弱一点的查询引擎,交互式没有presto那么强,而且只能访问hdfs的数据

presto是一个交互式查询引擎,可以在很短的时间内返回查询结果,秒级,分钟级,能访问很多数据源

hive在查询100Gb级别的数据时,消耗时间已经是分钟级了

但是presto是取代不了hive的,因为p全部的数据都是在内存中,限制了在内存中的数据集大小,比如多个大表的join,这些大表是不能完全放进内存的,实际应用中,对于在presto的查询是有一定规定条件的,比比如说一个查询在presto查询超过30分钟,那就kill掉吧,说明不适合在presto上使用,主要原因是,查询过大的话,会占用整个集群的资源,这会导致你后续的查询是没有资源进行查询的,这跟presto的设计理念是冲突的,就像是你进行一个查询,但是要等个5分钟才有资源继续查询,这是很不合理的,交互式就变得弱了很多

presto基本架构

在谈presto架构之前,先回顾下hive的架构

hive:client将查询请求发送到hive server,它会和metastor交互,获取表的元信息,如表的位置结构等,之后hive server会进行语法解析,解析成语法树,变成查询计划,进行优化后,将查询计划交给执行引擎,默认是MR,然后翻译成MR

presto:presto是在它内部做hive类似的逻辑

接下来,深入看下presto的内部架构

这里面三个服务:

Coordinator(考第内ter),是一个中心的查询角色,它主要的一个作用是接受查询请求,将他们转换成各种各样的任务,将任务拆解后分发到多个worker去执行各种任务的节点

1、解析SQL语句

2、?成执?计划

3、分发执?任务给Worker节点执?

Worker,是一个真正的计算的节点,执行任务的节点,它接收到task后,就会到对应的数据源里面,去把数据提取出来,提取方式是通过各种各样的connector:

1、负责实际执?查询任务

Discovery service,是将coordinator和woker结合到一起的服务:

1、Worker节点启动后向Discovery Server服务注册

2、Coordinator从Discovery Server获得Worker节点

coordinator和woker之间的关系是怎么维护的呢?是通过Discovery Server,所有的worker都把自己注册到Discovery Server上,Discovery Server是一个发现服务的service,Discovery Server发现服务之后,coordinator便知道在我的集群中有多少个worker能够给我工作,然后我分配工作到worker时便有了根据

最后,presto是通过connector plugin获取数据和元信息的,它不是?个数据存储引擎,不需要有数据,presto为其他数据存储系统提供了SQL能?,客户端协议是HTTP+JSON

Presto支持的数据源和存储格式

Hadoop/Hive connector与存储格式:

HDFS,ORC,RCFILE,Parquet,SequenceFile,Text

开源数据存储系统:

MySQL & PostgreSQL,Cassandra,Kafka,Redis

其他:

MongoDB,ElasticSearch,HBase

Presto中SQL运行过程:整体流程

1、当我们执行一条sql查询,coordinator接收到这条sql语句以后,它会有一个sql的语法解析器去把sql语法解析变成一个抽象的语法树AST,这抽象的语法书它里面只是进行一些语法解析,如果你的sql语句里面,比如说关键字你用的是int而不是Integer,就会在语法解析这里给暴露出来

2、如果语法是符合sql语法规范,之后会经过一个逻辑查询计划器的组件,他的主要作用是,比如说你sql里面出现的表,他会通过connector的方式去meta里面把表的schema,列名,列的类型等,全部给找出来,将这些信息,跟语法树给对应起来,之后会生成一个物理的语法树节点,这个语法树节点里面,不仅拥有了它的查询关系,还拥有类型的关系,如果在这一步,数据库表里某一列的类型,跟你sql的类型不一致,就会在这里报错

3、如果通过,就会得到一个逻辑的查询计划,然后这个逻辑查询计划,会被送到一个分布式的逻辑查询计划器里面,进行一个分布式的解析,分布式解析里面,他就会去把对应的每一个查询计划转化为task

4、在每一个task里面,他会把对应的位置信息全部给提取出来,交给执行的plan,由plan把对应的task发给对应的worker去执行,这就是整个的一个过程

这是一个通用的sql解析流程,像hive也是遵循类似这样的流程,不一样的地方是distribution planner和executor pan,这里是各个引擎不一样的地方,前面基本上都一致的

Presto中SQL运行过程:MapReduce vs Presto

task是放在每个worker上该执行的,每个task执行完之后,数据是存放在内存里了,而不像mr要写磁盘,然后当多个task之间要进行数据交换,比如shuffle的时候,直接从内存里处理

Presto监控和配置:监控

Web UI

Query基本状态的查询

JMX HTTP API

GET /v1/jmx/mbean[/{objectName}]

com.facebook.presto.execution:name=TaskManager

com.facebook.presto.execution:name=QueryManager

com.facebook.presto.execution:name=NodeScheduler

事件通知

Event Listener

query start, query complete

Presto监控和配置:配置

执行计划计划(Coordinator)

node-scheduler.include-coordinator

是否让coordinator运行task

query.initial-hash-partitions

每个GROUP BY操作使?的hash bucket(=tasks)最大数目(default: 8)

node-scheduler.min-candidates

每个stage并发运行过程中可使用的最大worker数目(default:10)

query.schedule-split-batch-size

每个split数据量

任务执行(Worker)

query.max-memory (default: 20 GB)

一个查询可以使用的最大集群内存

控制集群资源使用,防止一个大查询占住集群所有资源

使用resource_overcommit可以突破限制

query.max-memory-per-node (default: 1 GB)

一个查询在一个节点上可以使用的最大内存

举例

Presto集群配置: 120G * 40

query.max-memory=1 TB

query.max-memory-per-node=20 GB

query.max-run-time (default: 100 d)

一个查询可以运行的最大时间

防止用户提交一个长时间查询阻塞其他查询

task.max-worker-threads (default: Node CPUs * 4)

每个worker同时运行的split个数

调大可以增加吞吐率,但是会增加内存的消耗

队列(Queue)

任务提交或者资源使用的一些配置,是通过队列的配置来实现的

资源隔离,查询可以提交到相应队列中

资源隔离,查询可以提交到相应队列中

每个队列可以配置ACL(权限)

每个队列可以配置Quota

可以并发运行查询的数量

排队的最大数量

大数据OLAP引擎对比

Presto:内存计算,mpp架构

Druid:时序,数据放内存,索引,预计算

Spark SQL:基于Spark Core,mpp架构

Kylin:Cube预计算  

最后,一些零散的知识点s presto适合pb级的海量数据查询分析,不是说把pb的数据放进内存,比如一张pb表,查询count,vag这种有个特点,虽然数据很多,但是最终的查询结果很小,这种就不会把数据都放到内存里面,只是在运算的过程中,拿出一些数据放内存,然后计算,在抛出,在拿,这种的内存占用量是很小的,但是join这种,在运算的中间过程会产生大量的数据,或者说那种查询的数据不大,但是生成的数据量很大,这种也是不合适用presto的,但不是说不能做,只是会占用大量内存,消耗很长的时间,这种hive合适点

presto算是hive的一个补充,需要尽快得出结果的用presto,否则用hive

work是部署的时候就事先部署好的,work启动100个,使用的work不一定100个,而是根据coordinator来决定拆分成多少个task,然后分发到多少个work去

一个coordinator可能同时又多个用户在请求query,然后共享work的去执行,这是一个共享的集群

coordinator和discovery server可以启动在一个节点一个进程,也可以放在不同的node上,但是现在公司大部分都是放在一个节点上,一个launcher start会同时把上述两个启动起来

对于presto的容错,如果某个worker挂掉了,discovery server会发现并通知coordinator

但是对于一个query,是没有容错的,一旦一个work挂了,那么整个qurey就是败了

因为对于presto,他的查询时间是很短的,与其查询这里做容错能力,不如重新执行来的快来的简单

对于coordinator和discovery server节点的单点故障,presto还没有开始处理这个问题貌似

 
   
507 次浏览       51
相关文章

基于EA的数据库建模
数据流建模(EA指南)
“数据湖”:概念、特征、架构与案例
在线商城数据库系统设计 思路+效果
 
相关文档

Greenplum数据库基础培训
MySQL5.1性能优化方案
某电商数据中台架构实践
MySQL高扩展架构设计
相关课程

数据治理、数据架构及数据标准
MongoDB实战课程
并发、大容量、高性能数据库设计与优化
PostgreSQL数据库实战培训
最新课程计划
 
最新文章
大数据平台下的数据治理
如何设计实时数据平台(技术篇)
大数据资产管理总体框架概述
Kafka架构和原理
ELK多种架构及优劣
最新课程
大数据平台搭建与高性能计算
大数据平台架构与应用实战
大数据系统运维
大数据分析与管理
Python及数据分析
更多...   
成功案例
某通信设备企业 Python数据分析与挖掘
某银行 人工智能+Python+大数据
北京 Python及数据分析
神龙汽车 大数据技术平台-Hadoop
中国电信 大数据时代与现代企业的数据化运营实践
更多...