一，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 )