presto和hive的一些对比
1.本质区别
Hive是把一个查询转化成多个MapReduce任务，然后一个接一个执行。执行的中间结果通过对磁盘的读写来同步。然而，Presto没有使用MapReduce，它是通过一个定制的查询和执行引擎来完成的。它的所有的查询处理是在内存中，这也是它的性能很高的一个主要原因。
2.执行速度
presto由于是基于内存的，而hive是在磁盘上读写的，因此presto比hive快很多，但是由于是基于内存的当多张大表关联操作时易引起内存溢出错误
3.处理json类型的数据
presto处理如下：
select
json_extract_scalar(xx['custom'],'$.position')
from table
hive处理如下：
select
get_json_object(xx['custom'],'$.position')
from table
此外Presto还有一个函数json_extract是直接返回一个json串，根据需要自己需要选择函数
4.列转行
Hive
select student, score from tests lateral view explode(split(scores, ',')) t as score;
Presto
select student, score from tests cross json unnest(split(scores, ',') as t (score)
presto和hive适用场景
经过评测：presto的平均性能是hive的10倍
presto优点：数据源具有完全解耦，高性能，以及对ansi sql的支持特性，使得presto在etl，实时数据计算、ad-hoc查询和实时数据流分析等多个场景中能够发挥重要的作用。
hive和presto可以作为互补适用：
presto适合在单次扫描级别gb tb级别的数据
hive适合海量级别的数据的计算
presto分成两种场景：
基于数据快照的实时计算：
1、完成时间通常在200ms-20min
完全实时计算：
要完成实时计算，需要满足：
（1）适用的基准数据需要实时更新，时刻保持与线上的数据保持一直
（2）计算速度要够快速完成
presto基于t+1数据的计算，
在这种业务场景中，并不要求基准数据的实时更新，但要求数据查询要够快相应。
因此采用 Treasure Data 提供的基于 Presto-gres 中的 ODBC 驱动改造之后的 ODBC 驱动连接到 Presto 集群。
实时数据流分析：presto-kafka使用sql对kafka的数据进行清洗，分析和计算，在实际场景中两种使用场景：
1、保留历史数据
真实的测试过程中，Greenplum 表现并不理想，和 MySQL 对比，查询效率差了两个数量级。
为此，我们做了查询效率低效的分析，如下：
查询期间 Segment 节点 CPU 平均使用率峰值 14.67%，IO until 100%，内存使用率峰值 3.05%，网络流量峰值 0.03 Mbit/s，问题在于单机 IO 上；
导入数据时间间隔为 4 月 1 号到 4 月 25 号，而查询时间间隔同样为为 4 月 1 号到 4 月 25 号，手动做了分区消除；
分布键分布数据集中在单机，无法发挥 Greenplum 性能。
于是，我们放弃了 Greenplum 方案，原因如下：
导入数据慢；
查询执行效率低；
机器成本高，部署维护较复
https://dbarobin.com/2016/09/24/bi-scheme/
http://tech.dianwoda.com/2016/10/20/unt/
