為了跟上所謂“大資料”技術的腳步，從兩年前開始著手實踐各種SQL-on-Hadoop技術，從最初的Hive，到SparkSQL，再到Impala，進行了一系列ETL、CDC、多維資料倉庫、OLAP的實驗。作為一名從業20年以上的DBA，從資料庫的角度看，我的總體感覺是這些技術與傳統的DBMS相比，功能不完善，效能差距很大，甚至很難找到一個可行的、相對完備的Hadoop資料倉庫解決方案。這使我在實際應用中使用這些產品的時候總是感到顧此失彼、捉襟見肘。也可能是我做資料庫的時間太長了，只會用錘子，所以拿什麼都跟釘子比。
        然而，在去年12月舉辦的BDTC大會上聽到常雷博士介紹HAWQ專案時，立即引起了我的興趣。從常博士的演講中得知，HAWQ支援事務、效能相對於其它SQL-on-Hadoop產品高很多。更為關鍵的是HAWQ與SQL的相容性非常好，甚至支援儲存過程，這是我以往所接觸過的產品中從未有過的。對於傳統資料庫的開發人員或DBA，使用HAWQ轉向大資料平臺的成本應該是很低的。於是當時就決定今年要系統研究一下HAWQ，也許它正是我所需要的。

一、常用SQL-on-Hadoop產品的不足

1. Hive

        Hive是最老牌的一款Hadoop資料倉庫產品，更夠部署在所有Hadoop發行版本之上。它在MapReduce計算框架上封裝一個SQL語義層，極大簡化了MR程式的開發。直到現在，Hive以其穩定性依然贏得大量使用者。
        但是Hive的缺點也很明顯——速度太慢。隨著技術的不斷進步，Hive的執行引擎也從最初的MapReduce一種，發展出Hive on Spark、Hive on Tez等。尤其是執行在Tez框架上的Hive，其效能有了長足改進。即便如此，Hive的速度還是比較適合後臺批處理應用場景，而不適合互動式即席查詢和聯機分析。

2. SparkSQL

        SparkSQL是Hadoop中另一個著名的SQL引擎，正如名字所表示的，它以Spark作為底層計算框架，實際上是一個Scala程式語言的子集。Spark基本的資料結構是RDD，一個分佈於叢集節點的只讀資料集合。傳統的MapReduce框架強制在分散式程式設計中使用一種特定的線性資料流處理方式。MapReduce程式從磁碟讀取輸入資料，把資料分解成鍵/值對，經過混洗、排序、歸併等資料處理後產生輸出，並將最終結果儲存在磁碟。Map階段和Reduce階段的結果均要寫磁碟，這大大降低了系統性能。也是由於這個原因，MapReduce大都被用於執行批處理任務。
        為了解決MapReduce的效能問題，Spark使用RDD作為分散式程式的工作集合，它提供一種分散式共享記憶體的受限形式。在分散式共享記憶體系統中，應用可以向全域性地址空間的任意位置進行讀寫操作，而RDD是隻讀的，對其只能進行建立、轉化和求值等操作。這種記憶體操作大大提高了計算速度。
        開發Spark的初衷是用於機器學習系統的培訓演算法，而不是SQL查詢。Spark宣稱其應用的延遲可以比MapReduce降低幾個數量級，但是我們的實際使用中，在20TB的資料集合上做SQL查詢也要10分鐘左右出結果，這個速度縱然是比Hive快了3倍，但顯然不能支撐互動查詢和OLAP應用。Spark還有一個問題是需要佔用大量記憶體，當記憶體不足時，容易出現OOM錯誤。

3. Impala

        Impala是一個執行在Hadoop之上的大規模並行處理（MPP）查詢引擎，提供對Hadoop叢集資料的高效能、低延遲的SQL查詢，使用HDFS作為底層儲存。對查詢的快速響應使互動式查詢和對分析查詢的調優成為可能，而這些在針對處理長時間批處理作業的SQL-on-Hadoop傳統技術上是難以完成的。
        Impala的最大亮點在於它的執行速度。官方宣稱大多數情況下它能在幾秒或幾分鐘內返回查詢結果，而相同的Hive查詢通常需要幾十分鐘甚至幾小時完成，因此Impala適合對Hadoop檔案系統上的資料進行分析式查詢。Impala預設使用Parquet檔案格式，這種列式儲存對於典型資料倉庫場景下的大查詢是較為高效的。
        Impala的問題主要體現在功能上的欠缺。如不支援update、delete操作，不支援Date資料型別，不支援XML和JSON相關函式，不支援covar_pop、covar_samp、corr、percentile、 percentile_approx、histogram_numeric、collect_set等聚合函式，不支援rollup、cube、grouping set等操作，不支援資料抽樣（Sampling），不支援ORC檔案格式等等。其中分組聚合、取中位數等是資料分析中的常用操作，當前的Impala存在如此多的侷限，使它在易用性上大打折扣，在實際使用時要格外注意。

二、HAWQ的可行性

        剛才介紹了幾種SQL-on-Hadoop產品的主要問題，那麼重點來了，HAWQ是否有能力取而代之呢？下面從功能與效能兩方面，簡單分析一下使用HAWQ的主要特點。具有了這些特性，使用HAWQ在Hadoop上開發分析型資料倉庫應用是完全可行的。

1. 功能

（1）完全相容SQL標準
        HAWQ從程式碼級別上可以說是資料儲存在HDFS上的PostgreSQL資料庫，100%符合ANSI SQL規範並且支援SQL 92、99、2003。它支援內連線、外連線、全連線、笛卡爾連線、相關子查詢等所有表連線方式，支援並集、交集、差集等集合操作，並支援遞迴查詢。作為一個數據庫系統，提供這些功能很好理解。

（2）豐富的函式
        除了包含諸多字串、數字、日期時間、型別轉換等常規標量函式以外，HAWQ還包含豐富的視窗函式和高階聚合函式，這些函式經常被用於分析型資料查詢。視窗函式包括cume_dist()、dense_rank()、first_value(expr)、lag(expr [,offset] [,default])、last_valueexpr、lead(expr [,offset] [,default])、ntile(expr)、percent_rank()、rank()、row_number()等。高階聚合函式包括MEDIAN (expr)、PERCENTILE_CONT (expr) WITHIN GROUP (ORDER BY expr [DESC/ASC])、PERCENTILE_DISC (expr) WITHIN GROUP (ORDER BY expr [DESC/ASC])、sum(array[])、pivot_sum (label[], label, expr)等。具體的函式說明參見Using Functions and Operators。

（3）TPC-DS合規性
        TPC-DS針對具有各種操作要求和複雜性的查詢定義了99個模板，例如點對點、報告、迭代、OLAP、資料探勘等。成熟的基於Hadoop的SQL系統需要支援和正確執行多數此類查詢，以解決各種不同分析工作場景和使用案例中的問題。圖1所示的基準測試是通過TPC-DS中的99個模板生成的111個查詢來執行的。圖中顯示了4種基於SQL-on-Hadoop常見系統的合規等級，綠色和藍色分別表示：每個系統可以優化的查詢個數；可以完成執行並返回查詢結果的查詢個數。從圖中可以看到，HAWQ完成了所有查詢，表現遠優於其它系統。HAWQ雖然沒有提供update、delete等DML語句，但通過其強大的資料查詢功能，可以輕鬆實現多維資料倉庫中漸變維（SCD）的處理需求。
圖1
（4）分割槽表
        與傳統DBMS系統類似，HAWQ也支援多種分割槽方法及多級分割槽，如List分割槽和Range分割槽。分割槽表對查詢效能和資料可維護性都有很大幫助。

（5）過程化程式設計
        HAWQ支援內建的SQL、C、Java、Perl、pgSQL、Python、R等多種語言的過程化程式設計。參見Using Languages and Extensions in HAWQ。

（6）原生Hadoop檔案格式支援
        HAWQ支援HDFS上的AVRO、Parquet、平面文字等多種檔案格式，支援snappy、gzip、quicklz、RLE等多種資料壓縮方法。與Hive不同，HAWQ實現了schema-on-write（寫時模式）資料驗證處理，不符合表定義或儲存格式的資料是不允許進入到表中的，這點與DBMS系統保持一致。

（7）外部資料整合
        HAWQ通過名為Pivotal eXtension Framework（PXF）的模組提供訪問HDFS上的Json檔案、Hive、HBase等外部資料的能力。而且PXF還允許使用者自定義：PXF提供框架API以便使用者為其自有資料堆疊開發新的聯結器，增強了資料引擎的鬆耦合程度。
        除了用於訪問HDFS檔案的PXF協議，HAWQ還提供了gpfdist檔案伺服器，它利用HAWQ系統並行讀寫本地檔案系統中的檔案。

2. 效能

（1）基於成本的SQL查詢優化器
        HAWQ採用基於成本的SQL查詢優化器，該查詢優化器以針對大資料模組化查詢優化器架構的研究成果為基礎而設計。
        HAWQ能夠制定執行計劃，可優化利用Hadoop 叢集的資源，還可以針對特定環境，如軟體版本、硬體型別、CPU、IOPS指標等資訊配置優化器。
        HAWQ已經驗證，能夠快速為涉及超過50個關聯表的高效能查詢找到理想的查詢計劃。因此可以將HAWQ用於大量資料分析的傳統企業資料倉庫工作負載要求。

（2）Dynamic pipelining
        SQL-on-Hadoop的主要設計目標是在Hadoop上執行SQL連線時最大程度地降低資料傳輸的開銷。HAWQ採用Dynamic pipelining來解決這一關鍵要求，使基於HDFS的資料適用於互動式查詢。Dynamic pipelining是一種並行資料流框架，結合了以下獨特的技術：

• 適應性高速UDP互聯技術。
• 操作執行時執行環境。這是所有SQL查詢的基礎，並針對大資料工作負載進行了調優。
• 執行時資源管理確保查詢的完整性。
• 無縫資料分配機制，將經常用於特定查詢的部分資料集集中起來。

        大資料模組化查詢優化器架構中突出的效能分析顯示，對於基於Hadoop的分析與資料倉庫工作負載，HAWQ要比現有Hadoop查詢引擎快一或兩個數量級。這些效能改進主要歸功於Dynamic pipelining和HAWQ內基於成本的查詢優化器的強大功能。

（3）與Impala的效能比較
        圖2是HAWQ提供的TPC-DS效能比較圖，可以看到HAWQ平均比Impala快4.55倍。
圖2
（4）與Hive的效能比較
        圖3是我在自己的實驗環境中所做的，HAWQ與Hive查詢效能對比圖。對於不同查詢，HAWQ比Hive快4-50倍。測試具體的軟硬體環境、資料模型、資料量、查詢語句等參見HAWQ與Hive查詢效能對比測試。
圖3

三、適合DBA的解決方案

        當初HAWQ最吸引我的地方是它支援SQL過程化程式設計。這是通過使用者自定義函式（user-defined functions，UDF）實現的。編寫UDF的語言可以是SQL、C、Java、Perl、Python、R和pgSQL。資料庫開發人員常用的自然是SQL和pgSQL，PL/pgSQL函式可以為SQL語言增加控制結構，執行復雜計算任務，並繼承所有PostgreSQL的資料型別（包括使用者自定義型別）、函式和操作符。
        HAWQ是我所使用過的SQL-on-Hadoop解決方案中唯一支援SQL過程化程式設計的，Hive、SparkSQL、Impala都沒有此功能。對於習慣了編寫儲存過程的DBA來說，這無疑大大提高了HAWQ的易用性。HAWQ的UDF提供以下特性：

• 給HAWQ內部函式起別名。
• 返回結果集的表函式。
• 引數個數可變的函式。
• 多型資料型別。

        HAWQ過程化程式設計例項參見用HAWQ輕鬆取代傳統資料倉庫（十） —— 過程語言。

四、HAWQ系統架構

        圖4是給出了一個典型的HAWQ叢集的主要元件。圖5是HAWQ內部架構圖。關於HAWQ的系統架構說明，參見解密Apache HAWQ ——功能強大的SQL-on-Hadoop引擎。
圖4
圖5