presto使用初探

前言 presto使用第一感觉： 真是快啊，百万数据秒级出结果
presto 文档： https://prestodb.io/docs/current/
参考文章https://blog.csdn.net/zhangmary/article/details/80287530

1 presto是什么：
是Facebook的开源的，完全基于内存的并⾏计算，分布式SQL交互式查询引擎
是一种大规模并行处理（MPP）架构，多节点管道式执行
⽀持任意数据源（通过扩展式连接器组件），数据规模GB〜PB级
使用的技术，如向量计算，动态编译执行计划，优化的ORC和Parquet Reader等
presto不太支持存储过程，支持部分标准SQL
presto的查询速度比hive快5-10倍
适合：PB级海量数据复杂分析，交互式SQL查询，⽀持跨数据源查询
不适合：多个大表的连接操作，因为急是基于内存的，多张大表在内存里可能放不下

2 presto和hive的对比
参考文章https://blog.csdn.net/zhangmary/article/details/80287530
hive是一个数据仓库，是一个交互式比较弱一点的查询引擎，交互式没有似的那么强，而且只能访问HDFS的数据

Presto是一个交互式查询引擎，可以在很短的时间内返回查询结果，秒级，分钟级，能访问很多数据源
Presto是一个分布式SQL查询引擎，它被设计为用来专门进行高速，实时的数据分析。
hive在查询的100Gb的级别的数据时，消耗时间已经是分钟级了

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

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

3 presto使用注意
(1) apply_no as “申请编号” ，其中别名使用的是双引号
(2) 数据类型不会隐式转换，需要手动cast( nums as int)
（3） SQL脚本最后不能使用分号
（4） SQL脚本不能使用tab键