經(jīng)過評測：presto的平均性能是hive的10倍

presto優(yōu)點(diǎn)：數(shù)據(jù)源具有完全解耦，高性能，以及對ansi sql的支持特性，使得presto在etl，實(shí)時(shí)數(shù)據(jù)計(jì)算、ad-hoc查詢和實(shí)時(shí)數(shù)據(jù)流分析等多個(gè)場景中能夠發(fā)揮重要的作用。

hive和presto可以作為互補(bǔ)適用：

presto適合在單次掃描級別gb tb級別的數(shù)據(jù)

hive適合海量級別的數(shù)據(jù)的計(jì)算

presto分成兩種場景：

基于數(shù)據(jù)快照的實(shí)時(shí)計(jì)算：

1、完成時(shí)間通常在200ms-20min

完全實(shí)時(shí)計(jì)算：

要完成實(shí)時(shí)計(jì)算，需要滿足：

（1）適用的基準(zhǔn)數(shù)據(jù)需要實(shí)時(shí)更新，時(shí)刻保持與線上的數(shù)據(jù)保持一直

（2）計(jì)算速度要夠快速完成

presto基于t+1數(shù)據(jù)的計(jì)算，

在這種業(yè)務(wù)場景中，并不要求基準(zhǔn)數(shù)據(jù)的實(shí)時(shí)更新，但要求數(shù)據(jù)查詢要夠快相應(yīng)。

因此采用 Treasure Data 提供的基于 Presto-gres 中的 ODBC 驅(qū)動改造之后的 ODBC 驅(qū)動連接到 Presto 集群。

實(shí)時(shí)數(shù)據(jù)流分析：presto-kafka使用sql對kafka的數(shù)據(jù)進(jìn)行清洗，分析和計(jì)算，在實(shí)際場景中兩種使用場景：

1、保留歷史數(shù)據(jù)

真實(shí)的測試過程中，Greenplum 表現(xiàn)并不理想，和 MySQL 對比，查詢效率差了兩個(gè)數(shù)量級。

為此，我們做了查詢效率低效的分析，如下：

查詢期間 Segment 節(jié)點(diǎn) CPU 平均使用率峰值 14.67%，IO until 100%，內(nèi)存使用率峰值 3.05%，網(wǎng)絡(luò)流量峰值 0.03 Mbit/s，問題在于單機(jī) IO 上；

導(dǎo)入數(shù)據(jù)時(shí)間間隔為 4 月 1 號到 4 月 25 號，而查詢時(shí)間間隔同樣為為 4 月 1 號到 4 月 25 號，手動做了分區(qū)消除；

分布鍵分布數(shù)據(jù)集中在單機(jī)，無法發(fā)揮 Greenplum 性能。

于是，我們放棄了 Greenplum 方案，原因如下：

導(dǎo)入數(shù)據(jù)慢；

查詢執(zhí)行效率低；

機(jī)器成本高，部署維護(hù)較復(fù)

https://dbarobin.com/2016/09/24/bi-scheme/

http://tech.dianwoda.com/2016/10/20/unt/

http://hualong.iteye.com/blog/2102798