經(jīng)過評測：presto的平均性能是hive的10倍
presto優(yōu)點：數(shù)據(jù)源具有完全解耦眷蚓，高性能黎棠，以及對ansi sql的支持特性椎木，使得presto在etl，實時數(shù)據(jù)計算朝卒、ad-hoc查詢和實時數(shù)據(jù)流分析等多個場景中能夠發(fā)揮重要的作用证逻。
hive和presto可以作為互補適用：
presto適合在單次掃描級別gb tb級別的數(shù)據(jù)
hive適合海量級別的數(shù)據(jù)的計算
presto分成兩種場景：
基于數(shù)據(jù)快照的實時計算：
1、完成時間通常在200ms-20min
完全實時計算：
要完成實時計算抗斤，需要滿足：
（1）適用的基準(zhǔn)數(shù)據(jù)需要實時更新囚企，時刻保持與線上的數(shù)據(jù)保持一直
（2）計算速度要夠快速完成
presto基于t+1數(shù)據(jù)的計算丈咐，
在這種業(yè)務(wù)場景中，并不要求基準(zhǔn)數(shù)據(jù)的實時更新龙宏，但要求數(shù)據(jù)查詢要夠快相應(yīng)棵逊。
因此采用 Treasure Data 提供的基于 Presto-gres 中的 ODBC 驅(qū)動改造之后的 ODBC 驅(qū)動連接到 Presto 集群。
實時數(shù)據(jù)流分析：presto-kafka使用sql對kafka的數(shù)據(jù)進行清洗银酗，分析和計算辆影，在實際場景中兩種使用場景：
1、保留歷史數(shù)據(jù)
真實的測試過程中黍特，Greenplum 表現(xiàn)并不理想蛙讥，和 MySQL 對比，查詢效率差了兩個數(shù)量級灭衷。
為此次慢，我們做了查詢效率低效的分析，如下：
查詢期間 Segment 節(jié)點 CPU 平均使用率峰值 14.67%翔曲，IO until 100%迫像，內(nèi)存使用率峰值 3.05%，網(wǎng)絡(luò)流量峰值 0.03 Mbit/s部默，問題在于單機 IO 上侵蒙；
導(dǎo)入數(shù)據(jù)時間間隔為 4 月 1 號到 4 月 25 號，而查詢時間間隔同樣為為 4 月 1 號到 4 月 25 號傅蹂，手動做了分區(qū)消除纷闺；
分布鍵分布數(shù)據(jù)集中在單機，無法發(fā)揮 Greenplum 性能份蝴。
于是犁功，我們放棄了 Greenplum 方案，原因如下：
導(dǎo)入數(shù)據(jù)慢婚夫；
查詢執(zhí)行效率低浸卦；
機器成本高，部署維護較復(fù)
https://dbarobin.com/2016/09/24/bi-scheme/
http://tech.dianwoda.com/2016/10/20/unt/
http://hualong.iteye.com/blog/2102798
