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
hive service hivestore 關於最後的乙個 告訴小白一下是後台執行的意思 presto所在的檔案中etc 自建 的catalog 自建 中hive.properties 自建檔案 中配置 connector.name hive hadoop2 這個聯結器的選擇要根據自身集群情況結合...
presto和hive的不同之處總結
1.一般用presto查詢資料，因為快，一般用hive開發資料 2.presto調取 的方式是 from a.b.c hive是from b.c 只需要庫.表 3.current date等日期相關的功能，presto可以用，但這類函式的寫法hive往往不通用，hive用的是 等。一些日期的不同，例...
Presto查詢hive欄位為json型別的方法
針對樣例資料做示例說明 hive employee表的xjson欄位，只有一條資料 select get json object xjson，0 age from employee limit 1 presto 我們分步操作，先用 json array get 取出jsonarray的第乙個元素 s...