2. 程式人生 > >HAWQ ——功能強大的SQL-on-Hadoop引擎

HAWQ ——功能強大的SQL-on-Hadoop引擎

阿新 • • 發佈：2019-01-12

分享主要分為以下五個部分：

  1. HAWQ基本介紹；

  2. HAWQ架構以及各重要元件的基本原理；

  3. HAWQ的中短期規劃；

  4. 如何貢獻到HAWQ和成為Apache Committer；

  5. Q & A。

一、HAWQ基本介紹

HAWQ是一個Hadoop原生大規模並行SQL分析引擎，針對的是分析性應用。和其他關係型資料庫類似，接受SQL，返回結果集。但它具有大規模並行處理很多傳統資料庫以及其他資料庫沒有的特性及功能。主要如下：

  1. 對標準的完善支援：ANSI SQL標準，OLAP擴充套件，標準JDBC/ODBC支援，比其他Hadoop SQL引擎都要完善。

  2. 具有MPP（大規模並行處理系統）的效能，比其他Hadoop裡面的SQL引擎快數倍。

  3. 具有非常成熟的並行優化器。優化器是並行SQL引擎的重要組成部分，對效能影響很多，尤其是對複雜查詢。

  4. 支援ACID事務特性：這是很多現有基於Hadoop的SQL引擎做不到的，對保證資料一致性很重要。

  5. 動態資料流引擎：基於UDP的高速網際網路絡。

  6. 彈性執行引擎：可以根據查詢大小來決定執行查詢使用的節點及Segment個數。

  7. 支援多種分割槽方法及多級分割槽：比如List分割槽和Range分割槽。分割槽表對效能有很大幫助，比如你只想訪問最近一個月的資料，查詢只需要掃描最近一個月資料所在分割槽。

  8. 支援多種壓縮方法：snappy，gzip，quicklz，RLE等。

  9. 多種UDF（使用者自定義函式）語言支援：java, python, c/c++, perl, R等。

  10. 動態擴容：動態按需擴容，按照儲存大小或者計算需求，秒級新增節點。

  11. 多級資源或負載管理：和外部資源管理器YARN整合；可以管理CPU，Memory資源等；支援多級資源佇列；方便的DDL管理介面。

  12. 支援訪問任何HDFS及其他系統的資料：各種HDFS格式（文字，SequenceFile，Avro，Parquet等等）以及其他外部系統（HBase等），並且使用者自己可以開發外掛來訪問新的資料來源。

  13. 原生的機器學習資料探勘庫MADLib支援：易於使用及高效能。

  14. 與Hadoop系統無縫整合：儲存、資源、安裝部署（Ambari）、資料格式、訪問等。

  15. 完善的安全及許可權管理：kerberos；資料庫，表等各個級別的授權管理。

  16. 支援多種第三方工具：比如Tableau，SAS，較新的Apache Zeppelin等。

  17. 支援對HDFS和YARN的快速訪問庫：libhdfs3和libyarn（其他專案也可以使用）。

  18. 支援在本地、虛擬化環境或者在雲端部署。

下面我來談一下HAWQ是原生Hadoop SQL引擎中“原生”的意思，“原生”主要體現在如下幾個方面：

  1. 資料都儲存在HDFS上，不需要使用connector模式。

  2. 高可擴充套件性：和其他Hadoop元件一樣，高可擴充套件。並且具有高效能。

  3. 原生的程式碼存取：和其他Hadoop專案一樣。HAWQ是Apache專案。使用者可以自由的下載，使用和做貢獻。區別與其他的偽開源軟體。

  4. 透明性：用Apache的方式開發軟體。所有功能的開發及討論都是公開的。使用者可以自由參與。

  5. 原生的管理：可以通過Ambari部署、資源可以從YARN分配，與其它Hadoop元件可以執行在同一個叢集。

HAWQ提供的主要好處：

  • HAWQ與同類開源和閉源產品比較，如圖1：


HAWQ與同類開源和閉源產品比較，如圖2：

HAWQ的歷史和現狀：

  1. 想法和原型系統 (2011)：GOH階段（Greenplum Database On HDFS）。

  2. HAWQ 1.0 Alpha (2012): 多個國外大型客戶試用，當時客戶效能測試是Hive的數百倍。促進了HAWQ 1.0作為正式產品釋出。

  3. HAWQ 1.0 GA (2013年初): 改變了傳統MPP資料庫架構，包括事務，容錯，元資料管等。

  4. HAWQ 1.X版本 (2014-2015 Q2)：增加了一些企業級需要的功能，比如Parquet儲存，新的優化器，Kerberos，Ambari安裝部署。客戶覆蓋全球。

  5. HAWQ 2.0 Alpha釋出併成為Apache孵化器專案：針對雲環境的系統架構重新設計，數十個高階功能，包括彈性執行引擎，高階資源管理，YARN整合，秒級擴容等等。現在大家在Apache開源的是最新的2.0 Alpha版本。未來的開發都在Apache進行。

二、Apache HAWQ系統架構

下面我來介紹一下HAWQ的系統架構。圖3給出了一個典型的HAWQ叢集的主要元件。其中有幾個Master節點：包括HAWQ master節點，HDFS master節點NameNode，YARN master節點ResourceManager。現在HAWQ元資料服務在HAWQ master節點裡面，將來的版本會成為單獨的服務。其他節點為Slave節點。每個Slave節點上部署有HDFS DataNode，YARN NodeManager以及一個HAWQ Segment。HAWQ Segment在執行查詢的時候會啟動多個QE (Query Executor, 查詢執行器)。查詢執行器執行在資源容器裡面。




圖4是HAWQ內部架構圖：


可以看到在HAWQ master節點內部有如下幾個重要元件：查詢解析器（Parser/Analyzer），優化器，資源管理器，資源代理，HDFS元資料快取，容錯服務，查詢派遣器，元資料服務。在Slave節點上安裝有一個物理Segment，在查詢執行時，針對一個查詢，彈性執行引擎會啟動多個虛擬Segment同時執行查詢，節點間資料交換通過Interconnect（高速網際網路絡）進行。如果一個查詢啟動了1000個虛擬Segment，意思是這個查詢被均勻的分成了1000份任務，這些任務會並行執行。所以說虛擬Segment數其實表明了查詢的並行度。查詢的並行度是由彈性執行引擎根據查詢大小以及當前資源使用情況動態確定的。下面我逐個來解釋這些元件的作用以及它們之間的關係：

  1. 查詢解析器：負責解析查詢，並檢查語法及語義。最終生成查詢樹傳遞給優化器。

  2. 優化器：負責接受查詢樹，生成查詢計劃。針對一個查詢，可能有數億個可能的等價的查詢計劃，但執行效能差別很大。優化器的作用是找出優化的查詢計劃。

  3. 資源管理器：資源管理器通過資源代理向全域性資源管理器（比如YARN）動態申請資源。並快取資源。在不需要的時候返回資源。我們快取資源的主要原因是減少HAWQ與全域性資源管理器之間的互動代價。HAWQ支援毫秒級查詢。如果每一個小的查詢都去向資源管理器申請資源，這樣的話，效能會受到影響。資源管理器同時需要保證查詢不使用超過分配給該查詢的資源，否則查詢之間會相互影響，可能導致系統整體不可用。

  4. HDFS元資料快取：用於HAWQ確定哪些Segment掃描表的哪些部分。HAWQ是把計算派遣到資料所在的地方。所以我們需要匹配計算和資料的區域性性。這些需要HDFS塊的位置資訊。位置資訊儲存在HDFS NameNode上。每個查詢都訪問HDFS NameNode會造成NameNode的瓶頸。所以我們在HAWQ Master節點上建立了HDFS元資料快取。

  5. 容錯服務：負責檢測哪些節點可用，哪些節點不可用。不可用的機器會被排除出資源池。

  6. 查詢派遣器：優化器優化完查詢以後，查詢派遣器派遣計劃到各個節點上執行，並協調查詢執行的整個過程。查詢派遣器是整個並行系統的粘合劑。

  7. 元資料服務：負責儲存HAWQ的各種元資料，包括資料庫和表資訊，以及訪問許可權資訊等。另外，元資料服務也是實現分散式事務的關鍵。

  8. 高速網際網路絡：負責在節點之間傳輸資料。軟體實現，基於UDP。

查詢執行

瞭解清楚各個元件之後，我們來看一下一個查詢的主要流程（請參見圖5）。


使用者通過JDBC/ODBC提交查詢之後，查詢解析器得到查詢樹，然後優化器根據查詢樹生成查詢計劃，派遣器和資源管理器打交道得到資源，分解查詢計劃，然後派遣計劃到Segment的執行器上面執行。最終結果會傳回給使用者。

下面我來簡單看一下並行查詢計劃長什麼樣。圖6給出了一個具體的例子。



這個查詢包含一個連線，一個表示式和一個聚集。圖中有兩個查詢計劃。簡單來看，並行查詢計劃和序列查詢計劃最不同的是多了一些Motion操作符。Motion負責在節點之間交換資料。底層是通過高速網際網路絡實現的。我們可以看到這裡有三種Motion：

  1. Redistribution Motion: 負責按照hash鍵值重新分佈資料

  2. Broadcast Motion: 負責廣播資料

  3. Gather Motion: 負責蒐集資料到一起。

左邊的查詢計劃表示瞭如果表lineitem和orders都使用了連線鍵進行分佈的情況。在這個例子中，lineitem按照l_orderkey進行hash分佈，orders表按照o_orderkey進行分佈。這樣的話兩個表做連線的時候是不需要進行重新分佈的。右邊的查詢計劃表示了一個需要重新分佈資料的例子。該查詢計劃和左邊的查詢計劃相比多了一個Motion節點。

彈性執行引擎

彈性執行引擎有幾個關鍵設計點：儲存和計算的完全分離，無狀態Segment以及如何使用資源。儲存和計算的分離使得我們可以動態的啟動任意多個虛擬Segment來執行查詢。無狀態Segment使得叢集更容易擴充套件。要想保證大規模叢集的狀態一致性是比較困難的問題，所以我們採用了無狀態的Segment。如何使用資源包括如何根據查詢的代價申請多少資源，並且如何有效的使用這些資源，比如如何使得資料區域性性最優。HAWQ內部針對每一個部分都進行了非常優化的設計。

元資料服務

元資料服務位於HAWQ Master節點。主要向其他元件提供元資料的儲存及查詢服務。對外的介面為CaQL(元資料查詢語言, Catalog Query Language)。CaQL支援的語言是SQL的一個子集，包括單表選擇，計數，多行刪除，單行插入更新等。把CaQL設計為SQL語言的一個子集的原因是，在未來我們希望把元資料從主節點分離出去，作為一個單獨的服務，支援一個簡單的子集作為元資料服務來說已經夠用了，並且容易擴充套件。

高速網際網路絡

高速網際網路絡的作用是在多個節點之間交換大量資料。HAWQ高速網際網路絡基於UDP協議。大家可能會問為什麼我們不使用TCP。其實我們同時支援TCP和UDP兩種協議。TCP協議早於UDP協議。就是因為我們遇到了TCP不能很好解決的問題，我們才開發了基於UDP的協議。圖7展示了一個高速網際網路絡的例子。



這個查詢包含一個連線，一個表示式和一個聚集。圖中有兩個查詢計劃。簡單來看，並行查詢計劃和序列查詢計劃最不同的是多了一些Motion操作符。Motion負責在節點之間交換資料。底層是通過高速網際網路絡實現的。我們可以看到這裡有三種Motion：

  1. Redistribution Motion: 負責按照hash鍵值重新分佈資料

  2. Broadcast Motion: 負責廣播資料

  3. Gather Motion: 負責蒐集資料到一起。

左邊的查詢計劃表示瞭如果表lineitem和orders都使用了連線鍵進行分佈的情況。在這個例子中，lineitem按照l_orderkey進行hash分佈，orders表按照o_orderkey進行分佈。這樣的話兩個表做連線的時候是不需要進行重新分佈的。右邊的查詢計劃表示了一個需要重新分佈資料的例子。該查詢計劃和左邊的查詢計劃相比多了一個Motion節點。

彈性執行引擎

彈性執行引擎有幾個關鍵設計點：儲存和計算的完全分離，無狀態Segment以及如何使用資源。儲存和計算的分離使得我們可以動態的啟動任意多個虛擬Segment來執行查詢。無狀態Segment使得叢集更容易擴充套件。要想保證大規模叢集的狀態一致性是比較困難的問題，所以我們採用了無狀態的Segment。如何使用資源包括如何根據查詢的代價申請多少資源，並且如何有效的使用這些資源，比如如何使得資料區域性性最優。HAWQ內部針對每一個部分都進行了非常優化的設計。

元資料服務

元資料服務位於HAWQ Master節點。主要向其他元件提供元資料的儲存及查詢服務。對外的介面為CaQL(元資料查詢語言, Catalog Query Language)。CaQL支援的語言是SQL的一個子集，包括單表選擇，計數，多行刪除，單行插入更新等。把CaQL設計為SQL語言的一個子集的原因是，在未來我們希望把元資料從主節點分離出去，作為一個單獨的服務，支援一個簡單的子集作為元資料服務來說已經夠用了，並且容易擴充套件。

高速網際網路絡

高速網際網路絡的作用是在多個節點之間交換大量資料。HAWQ高速網際網路絡基於UDP協議。大家可能會問為什麼我們不使用TCP。其實我們同時支援TCP和UDP兩種協議。TCP協議早於UDP協議。就是因為我們遇到了TCP不能很好解決的問題，我們才開發了基於UDP的協議。圖7展示了一個高速網際網路絡的例子。


例子中各個節點上的執行器程序形成了一個數據交換的流水線。假設每個節點上有1000個程序。有1000個節點，這些程序需要相互互動，每個節點上就會有上百萬個連線。TCP是沒辦法高效地支援這麼多的連線數的。所以我們開發了基於UDP的互聯協議。針對UDP傳輸，作業系統是不能保證可靠性的，並且不能保證是有序傳遞的。我們的設計目標需要保持以下特性：

  1. 可靠性：能夠保證在丟包的情況下，重傳丟失的包

  2. 有序性：保證包傳遞給接受者的最終有序性

  3. 流量控制：如果不控制傳送者的速度，接收者可能會被淹沒，甚至會導致整個網路效能急劇下降

  4. 效能和可擴充套件性：效能和可擴充套件性是我們需要解決TCP問題的初衷

  5. 可支援多種平臺



這個查詢包含一個連線，一個表示式和一個聚集。圖中有兩個查詢計劃。簡單來看，並行查詢計劃和序列查詢計劃最不同的是多了一些Motion操作符。Motion負責在節點之間交換資料。底層是通過高速網際網路絡實現的。我們可以看到這裡有三種Motion：

  1. Redistribution Motion: 負責按照hash鍵值重新分佈資料

  2. Broadcast Motion: 負責廣播資料

  3. Gather Motion: 負責蒐集資料到一起。

左邊的查詢計劃表示瞭如果表lineitem和orders都使用了連線鍵進行分佈的情況。在這個例子中，lineitem按照l_orderkey進行hash分佈，orders表按照o_orderkey進行分佈。這樣的話兩個表做連線的時候是不需要進行重新分佈的。右邊的查詢計劃表示了一個需要重新分佈資料的例子。該查詢計劃和左邊的查詢計劃相比多了一個Motion節點。

彈性執行引擎

彈性執行引擎有幾個關鍵設計點：儲存和計算的完全分離，無狀態Segment以及如何使用資源。儲存和計算的分離使得我們可以動態的啟動任意多個虛擬Segment來執行查詢。無狀態Segment使得叢集更容易擴充套件。要想保證大規模叢集的狀態一致性是比較困難的問題，所以我們採用了無狀態的Segment。如何使用資源包括如何根據查詢的代價申請多少資源，並且如何有效的使用這些資源，比如如何使得資料區域性性最優。HAWQ內部針對每一個部分都進行了非常優化的設計。

元資料服務

元資料服務位於HAWQ Master節點。主要向其他元件提供元資料的儲存及查詢服務。對外的介面為CaQL(元資料查詢語言, Catalog Query Language)。CaQL支援的語言是SQL的一個子集，包括單表選擇，計數，多行刪除，單行插入更新等。把CaQL設計為SQL語言的一個子集的原因是，在未來我們希望把元資料從主節點分離出去，作為一個單獨的服務，支援一個簡單的子集作為元資料服務來說已經夠用了，並且容易擴充套件。

高速網際網路絡

高速網際網路絡的作用是在多個節點之間交換大量資料。HAWQ高速網際網路絡基於UDP協議。大家可能會問為什麼我們不使用TCP。其實我們同時支援TCP和UDP兩種協議。TCP協議早於UDP協議。就是因為我們遇到了TCP不能很好解決的問題，我們才開發了基於UDP的協議。圖7展示了一個高速網際網路絡的例子。


圖8展現了我們實現UDP高速網際網路絡的狀態機。並且設計時還需要考慮死鎖的消除。詳細資訊可以參考參考文獻。

事務管理

事務是資料管理系統一個非常重要的屬性。大部分Hadoop裡面的SQL引擎不支援事務。讓程式設計師自己保證事務和資料的一致性，基本上是非常困難的事。

HAWQ支援事務的所有ACID屬性，支援Snapshot Isolation。事務發生由Master節點協調和控制。採用的是一種泳道模型。比如併發的插入各個查詢使用各自的泳道，互不衝突。在事務提交的時候通過記錄檔案邏輯長度的方式來保證一致性。如果事務失敗的時候，需要回滾，刪除檔案末尾的垃圾資料。起初HDFS是不支援truncate的，現在HDFS剛支援的truncate功能是根據HAWQ的需求做出的。

資源管理器

HAWQ支援三級資源管理：

  1. 全域性資源管理：可以整合YARN，和其他系統共享叢集資源。未來會支援Mesos等

  2. HAWQ內部資源管理：可以支援查詢，使用者等級別的資源管理

  3. 操作符級別資源管理：可以針對操作符分配和強制資源使用

現在HAWQ支援多極資源佇列。可以通過DDL方便的定義和修改資源佇列定義。下面是HAWQ資源管理器的主要架構圖：



這個查詢包含一個連線，一個表示式和一個聚集。圖中有兩個查詢計劃。簡單來看，並行查詢計劃和序列查詢計劃最不同的是多了一些Motion操作符。Motion負責在節點之間交換資料。底層是通過高速網際網路絡實現的。我們可以看到這裡有三種Motion：

  1. Redistribution Motion: 負責按照hash鍵值重新分佈資料

  2. Broadcast Motion: 負責廣播資料

  3. Gather Motion: 負責蒐集資料到一起。

左邊的查詢計劃表示瞭如果表lineitem和orders都使用了連線鍵進行分佈的情況。在這個例子中，lineitem按照l_orderkey進行hash分佈，orders表按照o_orderkey進行分佈。這樣的話兩個表做連線的時候是不需要進行重新分佈的。右邊的查詢計劃表示了一個需要重新分佈資料的例子。該查詢計劃和左邊的查詢計劃相比多了一個Motion節點。