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適用場景
0.122017.05.08 22:08:12字數 593閱讀 4,046
經過評測：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/
http://hualong.iteye.com/blog/2102798