presto和hive的区别

Hive是把一个查询转化成多个MapReduce任务，然后一个接一个执行。执行的中间结果通过对磁盘的读写来同步。然而，Presto没有使用MapReduce，它是通过一个定制的查询和执行引擎来完成的。它的所有的查询处理是在内存中，这也是它的性能很高的一个主要原因。

经过测评，presto的平均性能是hive的十倍。

presto的优点：数据源具有完全解耦，高性能，以及对ansi sql的支持特性，使得presto在etl,实时数据计算、as-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的数据进行清洗，分析和计算，在实际场景中两种使用场景：

保留历史数据

真实的测试过程中，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 方案，原因如下：

导入数据慢；

查询执行效率低；

机器成本高，部署维护较复