标签：ice ase nec 架构 数据仓库 bsp service 限制 redis
是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架构之前，先回顾下hive的架构
hive：client将查询请求发送到hive server，它会和metastor交互，获取表的元信息，如表的位置结构等，之后hive server会进行语法解析，解析成语法树，变成查询计划，进行优化后，将查询计划交给执行引擎，默认是MR，然后翻译成MR
presto：presto是在它内部做hive类似的逻辑
接下来，深入看下presto的内部架构
这里面三个服务：
Coordinator，是一个中心的查询角色，它主要的一个作用是接受查询请求，将他们转换成各种各样的任务，将任务拆解后分发到多个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
Hadoop/Hive connector与存储格式：
HDFS，ORC，RCFILE，Parquet，SequenceFile，Text
开源数据存储系统：
MySQL & PostgreSQL，Cassandra，Kafka，Redis
其他：
MongoDB，ElasticSearch，HBase
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就是败了
对于coordinator和discovery server节点的单点故障，presto还没有开始处理这个问题貌似
标签：ice ase nec 架构 数据仓库 bsp service 限制 redis
原文地址：http://www.cnblogs.com/sorco/p/7060166.html
