淺析大數據即席查詢工具 Presto
本文轉載自微信公眾號「匠心獨運維妙維效」，作者侯強。轉載本文請聯系匠心獨運維妙維效公眾號。
數據業務現狀
隨著業務數據量越來越大、數據任務越來越多以及數據計算類型越來越豐富，G行的原有以Hadoop、MPP為核心的數據平臺現有組件表現出了一定的局限性。例如：大數據平臺和數據倉庫上任務總量已經達到了3萬以上，而且還在急劇增長。由于數據存放在了不同數據源中，對于需要對多種數據源的查詢任務，首先要進行數據遷移操作，匯總到MPP或Hadoop后進行查詢操作，這一過程耗時費力，已經很難滿足用戶快捷數據查詢的需求。
而數據平臺建設的一個重要目標就是滿足用戶方便快捷的使用數據，用戶不需要關心數據的存放方式，能夠使用標準的數據調用接口，隨時使用自己關心的數據。為滿足對上述的多數據源無差別的查詢，使用遠端數據完成交互式查詢，G行選擇的方式是Presto。
Presto提供豐富的Connector，通過Connector機制可以將所連接的數據SQL化。Presto的Connector可以連接傳統的RDBMS數據庫，也可以連接HBase、Hive等大數據的開源軟件，還可以使用FileConnector連接本地文件。有了Connector，可以直接在Presto的客戶端發起查詢請求，通過Presto解析查詢語句對不同的數據源發起數據查詢。通過Connector的方式，避免了數據搬移，節省了大量的數據存儲空間，也避免了時間消耗。這個場景非常適合數據科學家對多種數據分析的需求。
Presto架構特點
執行效率方面，Presto是一個開源的基于內存的分布式SQL查詢的執行引擎，可以支持TB到PB級數據量的秒級到分鐘級的快速響應。在查詢效率方面，比MapReduce的查詢引擎有很大的提升。
Presto查詢引擎是一個Master-Slave的架構，由一個Coordinator節點，多個Worker節點組成。Coordinator負責解析SQL語句，生成執行計劃，Coordinator將一個完整的Query，拆分成了多個Stage，每個Stage拆分出多個可以并行的Task，分發執行任務給Worker節點執行。
Worker節點負責實際執行查詢Task。通過配置外部數據源的Connector，部分Task負責到外部存儲系統拉取數據，這部分Task會先執行，之后再執行那些負責計算的Task。Worker節點的數量影響到Presto執行效率，可以通過增加worker節點的數量，提升數據查詢的的效率。而Coordinator在Presto只有一個，需要使用高可用的部署方法，進行災備保護。
Presto是一個原生的計算和存儲分離的分布式的SQL框架。Presto負責SQL的解析和執行，數據本身都由外部數據源進行存儲和維護。這種存儲和計算分離的架構，在進行資源擴容時可以分別對存儲資源和計算資源進行單獨擴容，非常符合當今云計算的架構和發展方向。在設備選型時，可以針對IO密集型和CPU密集型采購不同的設備來滿足需求。
Presto提供了豐富的Connector，可以連接多種流行的數據源，比如MySql、Hive、Elasticsearch等。同時Presto還提供了API接口，開發人員可以根據自己的實際情況開發自己的應用接口。例如openlookeng，這個軟件提供了高斯數據庫的訪問接口，可以完成Hive和高斯數據庫之間的跨數據源的聯合查詢。
Presto存在的問題
Presto是一個完全基于內存的SQL計算框架，在運行過程中采用高并發的查詢方式。當處理數據過于龐大、SQL需要的內存超出了物理服務器承受能力時，會出現內存溢出。如果需要穩定運行長時間的任務，可以使用Hive的SQL引擎。此外，由于Presto在設計初始，就是為了OLAP業務而進行開發，Presto雖然支持delete和insert，但內部結構不適合頻繁的數據修改操作。
Presto未來發展
許多企業在大數據建設道路上都產生了相類似的多數據源匯總查詢的問題，數據分布在多種數據產品中，各種數據產品之間沒有直接交互的方法，需要通過數據遷移完成數據分析工作。而Presto的出現，解決了多數企業面臨的問題。G行的即席查詢系統正是以Presto技術為核心構建的。隨著Presto應用范圍的擴大，穩定性將隨之不斷的改善，相信會給各個企業在數據業務方面帶來更多的便利性。
