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 方案,原因如下:

导入数据慢;

查询执行效率低;

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

你可能感兴趣的:(presto和hive的区别)