一,presto是什么:

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

是一种大规模并行处理(MPP)架构,多节点管道式执行

⽀持任意数据源(通过扩展式连接器组件),数据规模GB〜PB级

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

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

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

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

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

二,presto和hive的对比

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

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

Presto是一个分布式SQL查询引擎,它被设计为用来专门进行高速,实时的数据分析。

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

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



Presto的实现和Hive有着本质的不同:

Hive是把一个查询转化成多个stage的MapReduce的任务,然后一个接一个执行。执行的中间结果通过对磁盘的读写来同步。
然而,Presto没有使用MapReduce,它是通过一个定制的查询和执行引擎来完成的。它的所有的查询处理是在内存中,这也是它的性能很高的一个主要原因。所以在日常使用中,如果有大量的连接偶尔会发生内存不足的报错,一个常见的解决方法是生成中间表的方式来减少加入的次数。

三,presto中的行列转置函数
select mate, pv, uv from( select element_at(attr,'分类') fenlei, sum(pv) as pv,
count(distinct uv_id) as uv from shots.ad a left join hive.onetrue.f_t_traffic
b on a.ad_id =b.ad_id where transaction_date between date('2017-01-01') and
date('2018-04-30') group by element_at(attr,'分类') ) traffic cross join
unnest(split(traffic.fenlei,',')) as t ( mate )

友情链接
ioDraw流程图
API参考文档
OK工具箱
云服务器优惠
阿里云优惠券
腾讯云优惠券
华为云优惠券
站点信息
问题反馈
邮箱:ixiaoyang8@qq.com
QQ群:637538335
关注微信