梁堰波：主流SQL on Hadoop框架選擇

在“YARN還是Mesos討論之后（圓桌討論：YARN & Mesos，論集群資源管理所面臨的挑戰；深度分享：Mesos資源調度與管理的深入分享與交流）”，CSDN Spark用戶群迎來了大數據專家——明略數據梁堰波，就當前主流的SQL on Hadoop框架進行了深入分析，在給出了選擇建議后并與用戶進行了40分鐘的互動與交流。

---

梁堰波，現就職于明略數據，開源愛好者，Apache Hadoop & Spark contributor。北京航空航天大學計算機碩士，曾就職于Yahoo!、美團網、法國電信，具備豐富的大數據、數據挖掘和機器學習領域的項目經驗。

---

下為討論實錄

在批處理時代，Hive一枝獨秀；在實時交互式查詢時代，呈現出的則是百花齊放的局面。Hive on Tez、Hive on Spark、Spark SQL等等，目前來看也沒有誰干掉誰的趨勢。所以大家在實際項目中就會遇到疑惑，我的項目該使用哪種SQL on Hadoop的解決方案。因此，做選擇之前，相關人員首先得充分了解“后Hive時代”主要的幾種SQL on Hadoop 產品。

著眼當下的SQL on Hadoop產品，最吸引人的無疑是下面幾個：Hive系的Hive on Tez，也就是我們經常說的Stinger；Spark系的Spark SQL/DataFrame；Hive on Spark；Impala/Drill；Presto。

Hive on Tez & Hive on Spark

Hive/Tez/Stinger目前的主要推動者是Hortonworks和Yahoo!。剛剛結束的2015 Hadoop Summit（San Jose）上，Yahoo!分享了他們目前生產環境中Hive on Tez的一些情況。顯示和Hive 0.10（RCFile）相比，目前的Hive on Tez在1TB的數據量查詢的加速比平均為6.2倍。目前的Hive on Tez已經是production-ready。Tez這個執行引擎和Spark比較類似，原來的MR只能執行Map和Reduce兩種操作，現在的 Tez可以把Job解析成DAG來執行。除此之外還有一些進一步優化Hive執行效率的工作，例如Vectorized Execution和ORCFile等。Dropbox也透露他們的Hive集群下一步的升級目標就是Hive on Tez。而據悉，Yahoo！內部的很多集群已經升級為默認的Tez作為Hive的執行引擎了。

Hive on Spark目前的主要推動者是Cloudera，可以認為是Hive社區這邊搞的“Hive on Spark”。剛剛release了第一個使用版本，還不能用于生產環境。Hive on Spark既能利用到現在廣泛使用的Hive的前端，又能利用到廣泛使用的Spark作為后端執行引擎。對于現在既部署了Hive，又部署了Spark的公司來說，節省了運維成本。

現在看起來Spark很火，大家都往Spark上靠。但是我們在實際項目應用中還得考慮這個東西是不是適合。對于上面提到的Hive on Tez和Hive on Spark兩種系統都具備的優點是：

1.現存的Hive jobs可以透明、無縫遷移到Hive on ***平臺，可以利用Hive現有的ODBC/JDBC，metastore, hiveserver2, UDF，auditing, authorization, monitoring系統，不需要做任何更改和測試，遷移成本低。

2.無論后端執行引擎是MapReduce也好，Tez也好，Spark也好，整個Hive SQL解析、生成執行計劃、執行計劃優化的過程都是非常類似的。而且大部分公司都積累了一定的Hive運維和使用經驗，那么對于bug調試、性能調優等環 節會比較熟悉，降低了運維成本。

同時，因為目前大多數跟大數據有關的公司和team都部署了Hadoop和Hive，而且都有一定的這方面的運維和使用經驗，所以說Hive on Tez和Hive on Spark在這方面優勢明顯，使得我們的項目風險降低不少。

Spark SQL

Spark SQL主要的推動者是Databricks。提到Spark SQL不得不提的就是Shark。Shark可以理解為Spark社區這邊搞的一個“Hive on Spark”，把Hive的物理執行計劃使用Spark計算引擎去執行。這里面會有一些問題，Hive社區那邊沒有把物理執行計劃到執行引擎這個步驟抽象 出公共API，所以Spark社區這邊要自己維護一個Hive的分支，而且Hive的設計和發展不太會考慮到如何優化Spark的Job。但是前面提到的 Hive on Spark卻是和Hive一起發布的，是由Hive社區控制的。

所以后來Spark社區就停止了Shark的開發轉向Spark SQL（“坑了”一部分當時信任Shark的人）。Spark SQL是把SQL解析成RDD的transformation和action，而且通過catalyst可以自由、靈活的選擇最優執行方案。對數據庫有深 入研究的人就會知道，SQL執行計劃的優化是一個非常重要的環節，Spark SQL在這方面的優勢非常明顯，提供了一個非常靈活、可擴展的架構。但是Spark SQL是基于內存的，元數據放在內存里面，不適合作為數據倉庫的一部分來使用。所以有了Spark SQL的HiveContext，就是兼容Hive的Spark SQL。它支持HiveQL, Hive Metastore, Hive SerDes and Hive UDFs以及JDBC driver。

這樣看起來很完美，但是實際上也有一些缺點：Spark SQL依賴于Hive的一個snapshot，所以它總是比Hive的發布晚一個版本，很多Hive新的feature和bug fix它就無法包括。而且目前看Spark社區在Spark的thriftserver方面的投入不是很大，所以感覺它不是特別想朝著這個方向發展。還有一個重要的缺點就是Spark SQL目前還不能通過分析SQL來預測這個查詢需要多少資源從而申請對應的資源，所以在共享集群上無法高效地分配資源和調度任務。

這里面提到的Spark SQL目前還不能通過分析SQL來預測這個查詢需要多少資源從而申請對應的資源的問題，我想很多運維Hadoop和Hive集群的同學都有感觸。因為大多 數ETL都是晚上跑，如果資源估計不合理，第二天早晨老板晨會的時候看不到數，那么大家的KPI就……

所以這個也是Hive的優勢，目前Spark SQL的成熟度也不如Hive高，所以如果大家現有的ETL等服務，在Hive上跑的還不錯，那就先跑著，先別折騰新東西，而且是Hive社區也在不斷發展進步，性能各方面也在提升。

特別是目前Spark社區把Spark SQL朝向DataFrame發展，目標是提供一個類似R或者Pandas的接口，把這個作為主要的發展方向。DataFrame這個功能使得Spark 成為機器學習和數據科學領域不可或缺的一個組件，但是在數據倉庫（ETL，交互式分析，BI查詢）領域感覺已經不打算作為他們主要的發展目標了。

Spark SQL和DataFrame特別適合數據挖掘和機器學習前面的數據準備的工作，大家做過機器學習的同學都知道，算法只是其中的一小部分工作。而且大部分人 是不會自己寫新的算法的，更多的是用別人的算法，所以主要的工作量就集中在數據預處理上。現在Spark里面的MLlib提供了一個新的機器學習 pipeline 叫ML，ML是完全基于DataFrame來實現的了，完全看不到RDD的影子了。

Impala

位于New York的大數據廣告公司Collective內部的一個reporting service使用Impala，Spark，Parquet技術，運行在一個165的節點的YARN+Impala的集群上，有13 billion行的數據。這個是今年9月份在美國紐約舉辦的Impala meetup上即將的一個分享。

在國內，我們明略數據可以算是在這方面最優發言權的了。因為我們面對的客戶大多是金融、政府、公安等，這些行業的特點是數據查詢的實時性要求非常 高，特別是查詢性能，而且對SQL的支持也要比較標準，例如SQL99標準等。我們在Impala上自己動手改了一個新的引擎，讓Impala可以查詢 RDBMS的數據。這對于很多企業內部有多重數據源的整合查詢，而且要求很快查詢性能，而且要求SQL標準的場景，Impala還是非常適合的。我們自己 的Impala改進版，后面有機會可以和大家分享。

Impala主要的推動者是Cloudera，自從推出以來一直不溫不火。Impala是一種MPP架構的執行引擎，查詢速度非常快，是交互式BI 查詢最好的選擇，即使是在并發性非常高的情況下也能保證查詢延遲，所以在multi-tenant, shared clusters上表現比較好。Impala的另外一個重要的優點就是支持的SQL是在以上這些系統中是最標準的，也就是跟SQL99是最像的，所以對于 傳統企業來說可能是個不錯的選擇。Impala的主要缺點是社區不活躍，由C++開發，可維護性差，目前系統穩定性還有待提高。

像Presto，Tajo，Drill也有很多公司用。Presto是非死book開發的，目前也得到了Teradata的支持。目前 Presto的主要使用者還是互聯網公司，像非死book，Netflix等。像Presto，Tajo，Drill也有很多公司用。

這些東西都列在這了，我說下我個人的選擇依據（個人意見，歡迎討論）。

SQL on Hadoop解決方案選擇

目前來看Hive依然是批處理/ETL 類應用的首選。Hive on Spark能夠降低Hive的延遲，但是還是達不到交互式BI查詢的需求。目前交互式BI查詢最好的選擇是Impala。Spark SQL/DataFrame是Spark用戶使用SQL或者DataFrame API構建Spark pipeline的一種選擇，并不是一個通用的支持交互式查詢的引擎，更多的會用在基于Spark的機器學習任務的數據處理和準備的環節。

最后，大家選擇SQL on Hadoop產品，主要的目的可以說是構建大數據時代的數據倉庫。我推薦大家看一本書，當然這本書現在還沒有發表，大家可以等到他發表的時候再看，http://www.manning.com/ramachandran/ ，暫時還沒有完結。

QA——選集（限于篇幅）

問題1：明略目前impala最大的規模多少？性能如何？

梁堰波：因為我們的客戶都是政府、金融方面的，所以我們最大的Impala集群今天我不能透露有多大，但是性能上我們可以透露就是比原生的要快1-2倍。當然這個主要的性能優化點是我們接了RDBMS集群。

我們做這個事情的主要初衷并不是比原來的Impala快，因為原來的就很快了。我們做這件事的目的是支持異構的RDBMS作為Impala的數據源。因為RDBMS的擴展性不夠，我們是結合了Impala和RDBMS各自的優點。

問題2：剛你說到Spark做ETL的痛點，可否詳細說說，除下資源預測，還有哪些？

梁堰波：Spark做ETL的痛點，除了資源預測以外，還有SQL支持。Spark的SQL支持沒有Hive更全面，bug也相對較多，畢竟是比較新的項目，而且主要是從Spark社區的角度，他們也不是很重視這一方面。Spark SQL的thriftserver的發展也比較慢，因為社區可能更多資源在DataFrame那邊。

問題3：我最近在做金融數據，要求達到近實時處理（interactive query）的，吞吐量1G/s，選哪種比較合適？數據量比較大，目前是在MYSQL上，讀寫性能達不到要求，時間序列數據。原來想在HBase上做嘗 試，但還沒實施，股票交易類數據，并發性要求較高。

梁堰波：那這個你可以嘗試下Parquet列式存儲。原來的MySQL是單機的，拿到分布式上之后，IO自然就并發了，這個是顯而易見的。但是更多的提升來自像Parquet列式存儲，SQL引擎的predictive pushdown，這個在目前主流的SQL on Hadoop上面都支持。這個在目前主流的SQL on Hadoop上面都支持。并發查詢多的時候，Impala優勢明顯。

問題4：可以這樣理解嗎，根據應用場景不同，sql on hadoop架構還是混合模型的，就是多重組件同時存在？

梁堰波：是的。至少我認為是這樣的。其實還是用最合適的工具解決對應的問題是最好的。例如Spark最大的優勢是迭代式機器學習，例如Logistic Regression，性能提升非常大。但是像NaiveBayes這樣的，提升就沒那么明顯。SQL on Hadoop也是這樣的，如果你的業務用Hive跑的好好的，沒啥問題，千萬別瞎折騰。數據也是分層了，底層的ETL和上層的interactive query或者OLAP，所查詢的數據量是不一樣的，性能要求也不一樣，所以選擇不同的工具也是正常的。

問題5：apache phoenix進入cloudera lab能說明什么嗎？

梁堰波：這個其實cloudera的人回答更好，我說下我的觀點：說明phoenix是個備選，還是要看具體的業務類型。 Phoenix適合那種對HBase有很多技術積累的公司。而且phoenix一個重要的特點就是數據不是immutable的了，所以對于很多數據治理 的場景是有很大幫助的。

問題6：對于交互式BI查詢場景，把一些中間層數據用phoenix存起來，再提供查詢，怎么看這種用法？

梁堰波：交互式BI查詢，很多數據可以通過預先計算，然后存起來。這個前提就是你的很多維度 、 組合可以預先計算，而且存儲空間夠用。其實這種場景你不用phoenix，直接用HBase也行。當然phoenix更方便。因為這種類似OLAP的查 詢，基本上不會有太多的JOIN。大部分是select from where group by這樣的查詢。但是這個的特點就是，他只是OALP，不能做interactive query。

直播&提問方式

1.掃碼加入Spark微信討論組2。（注：CSDN Spark用戶微信群1已滿500，正在清理，后續我們會邀請2群朋友進入）

2. 加入CSDN Spark技術交流QQ群，群號：213683328。

3.  CSDN高端專家微信群，采取受邀加入方式，不懼高門檻的請加微信號“zhongyineng”或掃描下方二維碼，PS：帶上你的BIO。