Presto DB 簡介
產生背景
簡介
歷史
架構
查詢流程和事例
IMPALA Presto HIVE
Presto TODO 9
Reference 9產生背景
數據量急速增長到了 PB 量級，查詢有這么大數據量的數據庫出現問題，我們需要運行更多的交互式查詢并快速獲得結果。雖然 HDFS 支持大數據存儲，但是不能通過面板或者 BI 工具直觀展現，因為 HIVE 太慢或者 ODBC 還不可用。
Presto 是由非死book開發的一個分布式SQL查詢引擎， 它被設計為用來專門進行高速、實時的數據分析。它支持標準的ANSI SQL，包括復雜查詢、聚合（aggregation）、連接（join）和窗口函數（window functions)。它采用 Java 實現。它的數據源包括 HIVE、HBase、關系數據庫，甚至專有數據存儲。
2012 年秋天 非死book 啟動 Presto 項目，目的包括交互式查詢、加速商業數據倉庫以及擴展 非死book 處理數據的規模。2013 年春季在整個 非死book 使用。2013 年冬天在 Github 上開源。在最初的 6 個月有 30 多個 contributor，其中還有 非死book 外部開發者。到現在有 99 個 contributor，包括 129 個Release，6000+ commits。
HDFS 一般數據分析框架：
非死book 希望做成這樣：
然后再擴充數據源：
Presto分布式框架：
下面的架構圖中展現了簡化的Presto系統架構。客戶端（client）將SQL查詢發送到Presto的協調員（coordinator）。協調員會進行語法檢查、分析和規劃查詢計劃。計劃員（scheduler）將執行的管道組合在一起，將任務分配給那些里數據最近的節點，然后監控執行過程。客戶端從輸出段中將數據取出，這些數據是從更底層的處理段中依次取出的。
Presto 的運行模型和 Hive 或 MapReduce 有著本質的區別。Hive 將查詢翻譯成多階段的 MapReduce 任務，一個接著一個地運行。每一個任務從磁盤上讀取輸入數據并且將中間結果輸出到磁盤上。然而Presto引擎沒有使用MapReduce。為支持 SQL 語法，它實現了一個定制的查詢、執行引擎和操作符。除了改進的調度算法之外，所有的數據處理都是在內存中進行的。不同的處理端通過網絡組成處理的流水線。這樣會避免不必要的磁盤讀寫和額外的延遲。這種流水線式的執行模型會在同一時間運行多個數據處理段，一旦數據可用的時候就會將數據從一個處理段傳入到下一個處理段。這樣的方式會大大的減少各種查詢的端到端延遲。
Presto 動態編譯部分查詢計劃為字節碼，使得 JVM 能夠優化并生成本地機器碼。
在擴展性方面，Presto 只設計了一種簡單的存儲抽象，使得能夠在多種數據源上進行 SQL 查詢。連接器只需要提供獲取元數據的接口，獲得數據地址后自動訪問數據。
至于缺點方面，Presto 對表的連接以及 group by操作有比較嚴格的大小限制，這可能是因為所有數據處理都是在內存中完成。另外 Presto 查詢的結果只會返回到客戶端，還不支持寫回到表。
查詢流程和事例
如果有2個worker：
IMPALA Presto HIVE
下面是 Hive、Impala、Presto 和 HDFS 交互的示意圖
總的來說，Hive 把 HiveQL 查詢語句轉換為一系列 MapReduce 任務，而 Impala 和 Presto 則受 Google Dremel 論文的啟發，實現了自己的分布式查詢引擎。
HiveQL
這三者之間的一個共同點是它們都支持稱為 HiveQL 的公共標準。盡管 HiveQL 是基于 SQL，但它并不嚴格支持 SQL-92。
?Hive 如何工作
Hive 維護它自己的元數據存儲，其中存儲了模式定義、表定義、數據保存所在節點等信息。有一個 Hive 元數據存儲客戶端，以服務的方式向外暴露元數據信息。它可以通過 Thrift 訪問，這使得 Hive 元數據存儲能方便地和外部系統交互。這也使得 Impala 和 Presto 可以使用現有的基礎在上面繼續開發（Impala 和 Presto 都可以使用 Hive 存儲元數據）。
Hive 獲取 HiveQL 查詢語句，經過語法解析形成一系列的 MapReduce 作業。
?Impala 和 Presto如何工作
Impala 和 Presto 都使用 Hive 元數據存儲引擎獲得節點信息。然后它們直接和name node 以及 hdfs 文件系統交互，并行執行查詢。然后合并結果并以流的形式返回給用戶。整個過程都在內存中完成，因此可以消除MapReduce作業帶來的磁盤IO延遲。
?Hive
| 優勢 | 缺點 |
| 已經發布5年，可以說是成熟的解決方案 | 由于使用了MapReduce，它有所有MapReduce的缺陷，例如昂貴的shuffle過程和巨大的IO開銷 |
| 運行在原生的MapReduce框架之上 | 仍然不支持多個reducers，使得group by、order by等查詢語句非常慢 |
| 高度支持用戶定義函數 | 和其它對手相比性能差的比較大 |
| 能輕易的和 HBase 等系統結合 |
?Cloudera Impala
| 優勢 | 缺點 |
| 輕量快速，支持幾乎近實時查詢 | 對運行的查詢無容錯處理，如果某個節點失敗，必須重新發送查詢請求，而不能從失敗的地方恢復繼續。 |
| 計算都在內存中完成，極大地減少了延遲和磁盤IO開銷 | UDF支持不完善 |
?非死book Presto
| 優勢 | 缺點 |
| 輕量快速支持近實時交互查詢 | New born，有待進一步觀察 |
| 在非死book得到廣泛使用，擴展性和穩定性毋容置疑 | 現在只支持Hive管理的表。盡管網站上說可以在Hbase上查詢，但這個功能還在開發狀態 |
| 自從開源以來發展勢頭強勁 | 還不支持UDF，這是最需要添加的功能 |
| 使用分布式查詢引擎，和傳統的MapReduce相比消除了延遲和磁盤IO開銷 | |
| 文檔完善 |
下面是第三方機構 Radiant Advisors 關于 Hive、Impala、Presto 和 InfiniDB的一個 Benchmark 對比：
| 支持查詢數/10 | 用時/s | |
| InfiniDB | 10 | 1.28-17.62 |
| Impala | 7 | 3.1-69.38 |
| Presto | 9 | 18.89-506.84 |
| Hive0.11 | 7 | 102.59-277.18 |
| Hive0.12 | 7 | 91.39-325.68 |
其中Hive支持的7個查詢中有3個由于資源問題沒有執行完成。
Presto TODO
?Huge JOIN 和 Group by
?Spill to Disk，Insert
?Task 恢復
現在某個task fail 時，所有 task 也會 fail，也就是 query fail（worker doesn’t die）；另外，內存不夠也會導致查詢失敗。
?create view
?本地存儲 cache host data
?Authentication and permission
Reference
Presto Official
Presto: Distributed sql query engine
Presto – Hadoop Conference Japan 2014
Presto Github
HIVE, IMPALA AND PRESTO – THE WAR ON SQL OVER HADOOP