SQL on Hadoop系統的最新進展(3)

　　Cloudera Manager 4.6以后會有slow query的分析功能

　　Runtime Code Generation http://blog.cloudera.com/blog/2013/02/inside-cloudera-impala-runtime-code-generation/

　　impala可以直接使用硬盤上的數據而不經過hdfs

　　缺點：

　　impala不會按照group by的列排序

　　目前不支持UDF，impala 1.2即將支持Hive UDFs(Java寫的)和Impala native UDFs and UDAs(接口類似PosgreSQL)

　　不支持像Hive的Serializer/Deserializer，從而使得它做從非結構化到結構化數據的ETL工作比較麻煩。所以本質上講Impala適合MR配合做ETL之后的查詢工作。

　　由于Impala的設計初衷是short query，所以不支持fault tolerance。如果參與查詢的某個node出錯，Impala將會丟棄本次查詢。

　　安全方面的支持還比較差。impalad之間傳輸的數據沒有加密，不支持表或者列級別的授權。

　　每個PlanFragment執行盡量并行化，但是有的時候并不是很容易。例如Hash Join需要等到其中一個表完全Scan結束才能開始。

　　雖然有這么多缺點，但是很多公司還是開始嘗試Impala了。以百度為例，百度嘗試把MySQL接入Impala的后端作為存儲引擎，同時實現相應操作對應的PlanFragment，那么用戶來的query還是按照原來的解析方法解析成各種PlanFragment，然后直接調度到對應的節點(HDFS DataNode/HBase RegionServer/MySQL)上執行。會把某些源數據或者中間數據放到MySQL中，用戶的query涉及到使用這部分數據時直接去MySQL里面拿。

　　Shark/Spark

　　由于數據能放到內存盡量放到內存，使用內存非常aggressive。優點是做JOIN時會比較快，缺點是占用內存太大，且自行管理內存，占用內存后不會釋放。

　　由于Shark借用了Hive的codebase，所以在SQL，SerDes，UDF支持方面和Hive是完全兼容的。

　　支持fault tolerance

　　性能：

　　特別簡單的select…where查詢，shark性能的提升不明顯。(因為hive也不怎么費時間)

　　但是如果查詢比較復雜select…join…where…group by，hive的job數目會比較多，讀寫HDFS次數增多，時間自然會變長。當內存還足夠大的時候shark性能是最好的，如果內存不夠裝下所有的數據時性能會下降，但還是會比Hive好很多。

　　SQL on Hadoop產品需要向傳統數據倉庫學習的地方

　　以開源數據倉庫brighthouse(基于MySQL的數據倉庫存儲引擎)為例。

　　VLDB 2008 論文 <>

　　brighthouse的SQL解析用的是MySQL的代碼，開發了brighthouse專用的optimizer,executor以及storage engine

　　brighthouse的數據存儲通過三層來組織：Data Pack, Data Pack Node, Knowledge Node

　　DP(Data Pack):brighthouse是列存儲的，每個DP存儲一列中64K個單元的數據。

　　DPN(Data Pack Node):DPN和DP是一對一的關系，DPN中記錄每個DP數據對應的一些統計值(max,min,count,sum)

　　KN(Knowledge Node):DP的更詳細的數據信息和DP之間關系的信息

　　KN又分為一下三個部分：

　　HISTs(Histograms):數值類型列的統計直方圖，能夠快速判斷這個DP是否符合查詢條件。

　　CMAPs(Character Maps):文本類型的位圖，用于快速查找字符。(優化關鍵字like)

　　Pack-To-Pack:等值JOIN操作時產生的兩個列(DP)之間關系的位圖。

　　DPN和KN相當于DP的一些統計信息，占整個DP的1%的存儲空間，所以可以輕松裝入內存。他們是為了快速定位哪些DP是跟這個query相關(relevant)的，哪些是不相關(irrelevant)的，哪些是可能相關(suspect)的。從而減小IO讀取的數據量，提高性能。

　　性能測試：http://www.fuchaoqun.com/tag/brighthouse/

　　從這個性能測試中可以看出：

　　1，壓縮率：infobright比MyISAM/tar.gz的壓縮率都要高很多

　　2，查詢性能：跟建了索引的MyISAM表相比，查詢速度也要快3-6倍

　　總之，大家都缺少的是：

　　1，workload management or query optimization

　　多個表的JOIN如何執行，例如3個表的JOIN會有6種執行策略，那么哪一種才是效率最高的呢。顯然要通過計算每種執行順序的開銷來獲得。在傳統數據庫或者數據倉庫領域(Oracle/Teradata/PostgreSQL)都有非常好的查詢優化器，而在分布式系統中該如何衡量這些指標(磁盤IO，網絡帶寬，內存)與最后查詢效率之間的關系是個需要認真研究的問題。

　　2，關聯子查詢correlated sub-queries還是沒有誰能夠實現。

　　在TPC-H中又很多關聯子查詢的例子，但是現在的SQL on Hadoop產品都不支持。聽Impala的人說，他們客戶對這個的需求不是很強烈，大部分關聯子查詢可以轉化成JOIN操作。但是目前的商業產品像Hawq/Greenplum都是支持關聯子查詢的。

原文轉自：http://yanbohappy.sinaapp.com/?p=381