摘要：前面我們簡單闡述了分布式數據庫的架構，并通過一條簡單的查詢語句解釋了分布式的執行計劃。

第八屆中國架構師大會（SACC2016）10月27號到29號在北京萬達索菲特大飯店成功舉辦。大會以“架構創新之路“為主題，云集了國內外頂尖專家，共同探討云計算和大數據等技術背景下，如何通過架構創新及各種IT新技術來帶動企業轉型增效。作為一家專注于云端數據倉庫的初創公司，酷克數據受邀在SACC2016 “數據庫平臺架構及變遷”分會場作了題為“數據倉庫架構及變遷”的演講。以下是這次演講的PPT。

這個日程安排同時也是我們公司核心團隊的技術進階史。公司創始團隊成員有幸以核心開發者的角色參與，從單機版的關系型數據庫（PostgreSQL），大規模并行處理（MPP）數據庫（Greenplum Database）到SQL on Hadoop解決方案（Apache HAWQ），以及最新的SQL on Cloud數據倉庫（HashData）。通過回顧這個技術演進的歷程，我們將闡述如何一步一步地解決聯機分析（OLAP）系統低延遲、高并發以及擴展性問題。

由于后面討論的所有的分布式數據庫，包括Greenplum Database，Apache HAWQ以及HashData云端數據倉庫，都是基于單機版關系型數據庫PostgreSQL的，所以我們首先簡單介紹一下PostgreSQL，作為后續討論的基礎。

每個PostgreSQL數據庫的實例包含一個PostMaster的damon進程和多個子進程,包括負責寫出臟數據的BG Writer進程，收集統計信息的Stats Collector進程，寫事務日志的WAL Writer進程，等等。

客戶端應用通過libpq協議連接到PostMaster進程；PostMaster收到連接請求后，fork出一個子進程Postgres Server來處理來自這個連接的查詢語句。Postgres Server進程的功能組件可以分成兩大類：查詢執行和存儲管理。查詢執行組件包括解析器、分析器、優化器以及執行器。在查詢執行過程中，需要訪問和更新系統狀態和數據，包括緩存，鎖，文件和頁面等等。

作為一個單機版的關系型數據庫，PostgreSQL更多地是作為聯機事務處理（OLTP）系統使用的。當然，由于其豐富的分析功能，很多企業也會基于PostgreSQL來構建數據倉庫，特別是在數據量不大的情況下。但是，隨著數據量的增大，基于單機PostgreSQL構建的數據倉庫就無法滿足企業用戶對查詢響應時間的要求：低延遲。

為了解決這個問題，MPP架構就被引入了。這是MPP架構分布式數據庫的簡單示意圖。MPP數據庫通過將數據切片分布到各個計算節點后并行處理來解決海量數據分析的難題。每個MPP數據庫集群由一個主節點（為了提供高可用性，通常還會有一個從主節點）和多個計算節點組成。主節點和每個計算節點都有自己獨立的CPU，內存和外部存儲。主節點負責接收客戶端的請求，生成查詢計劃，并將計劃下發到每個計算節點，協調查詢計劃的完成，最后匯總查詢結果返回給客戶端。計算節點負責數據的存儲以及查詢計劃的執行。計算節點之間是沒有任何共享依賴的（shared nothing）。查詢在每個計算節點上面并行執行，大大提升了查詢的效率。

我們接下來要講的開源Greenplum Database就是基于PostgreSQL的MPP數據庫。對應到這個架構圖，每個節點上面的數據庫實例可以簡單的認為是一個PostgreSQL實例。

我們首先通過一條簡單的查詢，感性地認識一下Greenplum Database是如何執行一條查詢的。

這是一條簡單的兩表等值連接語句。其中，customer表是維度表，表數據以cust_id作為hash分布的key；sales表是事實表，在這個例子中，我們可以認為它的表數據是round-robin的方式隨機分布的，不影響查詢的執行。

每個查詢執行是一個由操作符組成的樹。只看其中一個節點的話（如前面所說，每個計算節點就是一個PostgreSQL的實例），為了執行兩表的等值連接，我們首先會將兩表的數據分別掃描出來，然后基于維度表customer建立hash桶。對于每一條從sales表掃描出來的紀錄，我們都會到hash桶去查。如果滿足匹配條件，數據連接結果；否則，直接pass。

如前面提到的，在Greenplum Database中，每張表的數據按照hash分布或者隨機分布打散到每個計算節點上面。在這個例子中，由于sales表是隨機分布的，為了正確執行基于cust_id的等值連接，生成的執行計劃會在table scan上面添加一個Redistribution motion節點。這個motion節點根據cust_id的hash值對數據作重分布，類似MapReduce中的shuffling。由于hash join操作是在每個節點上面分布式執行的，在將結果返回給客戶端的時候，需要在主節點上面執行匯總操作。Gather motion的作用就在于將每個節點上面的中間結果集中到主節點上面。

對于這樣一個并行的查詢計劃，我們會根據數據重分布的操作將整棵查詢執行樹切割成不同的子樹。每個子樹對應查詢計劃的一個階段，我們稱為slice。查詢計劃和slice是邏輯上的概念。

在物理層面，對應的是并行執行計劃和gang。gang指的是執行同一個slice操作的一組進程。MPP數據庫的一個重要特征是，計算和存儲是緊耦合的。每一張表的數據打散存儲到每個計算節點上面。為了確保查詢結果的正確性，每個計算節點都需要參與每條查詢的執行中。在Greenplum Database的架構設計中，對于每個slice執行子樹，在每個計算節點中會啟動一個相應的Postgres Server進程（這里稱為QE進程）來執行對應的操作。執行同一個slice的一組QE進程我們稱為gang。對應于查詢計劃中的三個slice，在執行計劃中，相應有三組gang。其中底下的兩個gang，我們稱之為N-gang，因為這種類型的gang中，包含了每個計算節點上面啟動的一個QE進程。頂上的gang，我們稱之為1-gang，因為它只包含了一個進程。

一般來說，對于N張表的關聯操作，執行計劃中會包含2N個gang，其中1個1-gang，對應主節點上面的進程；2N-1個N-gang，對應每個計算節點上面啟動的2N-1個QE進程。在這2N-1個gang中，其中N個用于掃描N張表，中間N-1個gang用于兩表關聯。也就是說，對于一條涉及到N表關聯操作的查詢語句，我們需要在每個計算節點上面啟動2N-1個QE進程。

很多用戶在評估Greenplum Database的并發數，也就是支持的最大同時運行的查詢數量，首先會擔心主節點會成為瓶頸，直觀原因是所有用戶連接請求都首先會到主節點。其實，從資源使用的角度看，計算節點會首先成為瓶頸。因為在執行涉及多表關聯的復雜查詢時，計算節點上面啟動的進程數量會遠多于主節點。所以，Greenplum Database系統架構決定了它不能支持非常高的并發訪問。

前面我們簡單闡述了MPP分布式數據庫的架構，并通過一條簡單的查詢語句解釋了分布式的執行計劃。接下來我們深入討論一下Greenplum Database的重要組件。

首先是解析器。從使用者的角度看，Greenplum Database跟PostgreSQL沒有明顯差別。主節點作為整個分布式系統集群的大腦，負責接收客戶連接，處理請求。跟PostgreSQL一樣，對于每一個連接請求，Greenplum Database都會在主節點上面fork一個Postgres Server（我們稱之為QD）進程出來，負責處理這個連接提交的查詢語句。對于每一條進來的查詢語句，QD進程中的解析器執行語法分析和詞法分析，生成解析樹。雖然在一些DDL語句上面，Greenplum Database跟PostgreSQL會有一些語法上的小不同，例如建表語句可以指定數據進行hash分布的key，但總體上，在解析器這個組件上面，兩者的差別不大。

優化器根據解析器生成的解析樹，生成查詢計劃。查詢計劃描述了如何執行查詢。查詢計劃的優劣直接影響查詢的執行效率。對于同樣一條查詢語句，一個好的查詢執行效率比一個次好的查詢計劃快上100倍，也是一個很正常的事情。從PostgreSQL到MPP架構的Greenplum Database，優化器做了重大改動。雖然兩者都是基于代價來生成最優的查詢計劃，但是Greenplum Database除了需要常規的表掃描代價、連接和聚合的執行方式外，還需要考慮數據的分布式狀態、數據重分布的代價，以及集群計算節點數量對執行效率的影響，因為它最終是要生成一個分布式的查詢計劃。

調度器是Greenplum Database在PostgreSQL上新增的一個組件，負責分配處理查詢需要的計算資源，將查詢計劃發送到每個計算節點。在Greenplum Database中，我們稱計算節點為Segment節點。前面也提過，每一個Segment實例實際上就是一個PostgreSQL實例。調度器根據優化器生成的查詢計劃確定執行計劃需要的計算資源，然后通過libpg（修改過的libpg協議)協議給每個Segment實例發送連接請求，通過Segment實例上的PostMaster進程fork出前面提到過的QE進程。調度器同時負責這些fork出來的QE進程的整個生命周期。

每個QE進程接收到從調度器發送過來的查詢計劃之后，通過執行器執行分配給自己的任務。除了增加一個新的稱謂Motion的操作節點（負責不同QE進程間的數據交換）之外，總體上看，Greenplum Database的執行器跟PostgreSQL的執行器差別不大。

MPP數據庫在執行查詢語句的時候，跟單機數據庫的一個重要差別在于，它會涉及到不同計算節點間的數據交換。在Greenplum Database系統架構中，我們引入了Interconnect組件負責數據交換，作用類似于MapReduce中的shuffling階段。不過與MapReduce基于HTTP協議不一樣，Greenplum Database出于數據傳輸效率和系統擴展性方面的考慮，實現了基于UDP協議的數據交換組件。前面在解析執行器的時候提到，Greenplum Database引入了一個叫Motion的操作節點。Motion操作節點就是通過Interconnect組件在不同的計算節點之間實現數據的重分布。

前面講到的解析器、優化器、調度器、執行器和Interconnect都是跟計算相關的組件，屬于無狀態組件。下面我們再看一下跟系統狀態相關的組件。首先是，系統表。系統表負責存儲和管理數據庫、表、字段等元數據。主節點上面的系統表是全局數據庫對象的元數據，稱為全局系統表；每個Segment實例上也有一份本地數據庫對象的元數據，稱為本地系統表。解析器、優化器、調度器、執行器和Interconenct等無狀態組件在運行過程中需要訪問系統表信息，決定執行的邏輯。由于系統表分布式地存儲在不同的節點中，如何保持系統表中信息的一致性是極具挑戰的任務。一旦出現系統表不一致的情況，整個分布式數據庫系統是無法正常工作的。

跟很多分布式系統一樣，Greenplum Database是通過分布式事務來確保系統信息一致的，更確切地說，通過兩階段提交來確保系統元數據的一致性。主節點上的分布式事務管理器協調Segment節點上的提交和回滾操作。每個Segment實例有自己的事務日志，確定何時提交和回滾自己的事務。本地事務狀態保存在本地的事務日志中。

介紹完Greenplum Database的查詢組件和系統狀態組件后，我們再看看它是如何提供高可用性的。首先是管理節點的高可用。我們采取的方式是，啟動一個稱為Standby的從主節點作為主節點的備份，通過同步進程同步主節點和Standby節點兩者的事務日志，在Standby節點上重做系統表的更新操作，從而實現兩者在全局系統表上面的信息同步。當主節點出故障的時候，我們能夠切換到Standby節點，系統繼續正常工作，從而實現管理節點的高可用。

計算節點高可用性的實現類似于管理節點，但是細節上有些小不同。每個Segment實例都會有另外一個Segment實例作為備份。處于正常工作狀態的Segment實例我們稱為Primary，它的備份稱為Mirror。不同于管理節點日志重放方式，計算節點的高可用是通過文件復制。對于每一個Segment實例，它的狀態以文件的形式保存在本地存儲介質中。這些本地狀態可以分成三大類：本地系統表、本地事務日志和本地表分區數據。通過以文件復制的方式保證Primary和Mirror之間的狀態一致，我們能夠實現計算節點的高可用。

Hadoop出現之前，MPP數據庫是為數不多的大數據處理技術之一。隨著Hadoop的興起，特別是HDFS的成熟，越來越多的數據被保存在HDFS上面。一個自然的問題出現了：我們怎樣才能高效地分析保存在HDFS上面的數據，挖掘其中的價值。4，5年前，SQL-on-Hadoop遠沒有現在這么火，市場上的解決方案也只有耶魯大學團隊做的Hadapt和Facebook做的Hive，像Impala，Drill，Presto，SparkSQL等都是后來才出現的。而Hadapt和Hive兩個產品，在當時無論是易用性還是查詢性能方面都差強人意。

我們當時的想法是將Greenplum Database跟HDFS結合起來。與其他基于connector連接器的方式不同，我們希望讓HDFS，而不是本地存儲，成為MPP數據庫的數據持久層。這就是后來的Apache HAWQ項目。但在當時，我們把它叫做Greenplum on Hadoop，其實更準確的說法應該是，Greenplum on HDFS。當時的想法非常簡單，就是將Greenplum Database和HDFS部署在同一個物理機器集群中，同時將Greenplum Database中的Append-only表的數據放到HDFS上面。Append-only表指的是只能追加，不能更新和刪除的表，這是因為HDFS本身只能Append的屬性決定的。

除了Append-only表之外，Greenplum Database還支持Heap表，這是一種能夠支持增刪改查的表類型。結合前面提到的Segment實例的本地狀態，我們可以將本地存儲分成四大類：系統表、日志、Append-only表分區數據和非Append-only表分區數據。我們將其中的Append-only表分區數據放到了HDFS上面。每個Segment實例對應一個HDFS的目錄，非常直觀。其它三類數據還是保存在本地的磁盤中。

總體上說，相對于傳統的Greenplum Database， Greenplum on HDFS架構上并沒有太多的改動，只是將一部分數據從本地存儲放到了HDFS上面，但是每個Segment實例還是需要通過本地存儲保存本地狀態數據。所以，從高可用性的角度看，我們還是需要為每個實例提供備份，只是需要備份的數據少了，因為Append-only表的數據現在我們是通過HDFS本身的高可用性提供的。

Greenplum on HDFS作為一個原型系統，驗證了MPP數據庫和HDFS是可以很好地整合起來工作的。基于這個原型系統，我們開始將它當成一個真正的產品來打造，也就是后來的HAWQ。

從Greenplum on HDFS到HAWQ，我們主要針對本地存儲做了系統架構上的調整。我們希望將計算節點的本地狀態徹底去掉。本地狀態除了前面提到的系統表（系統表又可以細分成只讀系統表（系統完成初始化后不會再發生更改的元數據，主要是數據庫內置的數據類型和函數）和可寫系統表（主要是通過DDL語句對元數據的修改，如創建新的數據庫和表））、事務日志、Append-only表分區數據和非Append-only表分區數據，同時還有系統在執行查詢過程中產生的臨時數據，如外部排序時用到的臨時文件。其中臨時數據和本地只讀系統表的數據都是不需要持久化的。我們需要考慮的是如何在Segment節點上面移除另外四類狀態數據。

Append-only表分區數據前面已經提到過，交給HDFS處理。為了提高訪問HDFS的效率，我們沒有采用Hadoop自動的HDFS訪問接口，而是用C++實現了原生的HDFS訪問庫，libhdfs3。針對非Append-only表數據的問題，我們的解決方案就比較簡單粗暴了：通過修改DDL，我們徹底禁止用戶創建Heap表，因為Heap表支持更新和刪除。所以，從那時起到現在最新的Apache HAWQ，都只支持表數據的追加，不支持更新和刪除。沒有了表數據的更新和刪除，分布式事務就變得非常簡單了。通過為每個Append-only表文件對應的元數據增加一列，邏輯EoF，即有效的文件結尾。只要能夠保證EoF的正確性，我們就能夠保證事務的正確性。而且Append-only表文件的邏輯EoF信息是保存在主節點的全局系統表中的，它的正確性通過主節點的本地事務保證。為了清理Append-only表文件在追加新數據時事務abort造成的臟數據，我們實現了HDFS Truncate功能。

對于本地可寫系統表，我們的做法是將Segment實例上面的本地可寫系統表放到主節點的全局系統表中。這樣主節點就擁有了全局唯一的一份系統表數據。查詢執行過程中需要用到的系統元數據，我們通過Metadata Dispatch的方式和查詢計劃一起分發給每個Segment實例。

通過上述的一系列策略，我們徹底擺脫了Segment節點的本地狀態，也就是實現了無狀態Segment。整個系統的高可用性策略就簡單了很多，而且也不需要再為Segment節點提供Mirror了，系統的利用率大大提升。

數據的高可用交給了HDFS來保證。當一個Segment節點出故障后，我們可以在任意一臺有空閑資源的機器上重新創始化一個新的Segment節點，加入到集群中替代原來出故障的節點，整個集群就能夠恢復正常工作。

我們也做到了計算和存儲物理上的解耦合，往徹底擺脫傳統MPP數據庫（例如Greenplum Database）計算和存儲緊耦合的目標邁出了有著實質意義的一步。

雖然在HAWQ 1.x的階段，我們做到了計算和存儲物理上的分離，但是邏輯上兩者還是集成的。原因是，在將本地表分區數據往HDFS上面遷移的時候，為了不改變原來Segment實例的執行邏輯流程，我們為每個Segment指定了一個其專有的HDFS目錄，以便跟原來本地數據目錄一一對應。每個Segment負責存儲和管理的數據都放在其對應的目錄的底下，而且該目錄底下的文件，也只有它自身能夠訪問。這種HDFS數據跟計算節點邏輯上的集成關系，使得HAWQ 1.x版本依然沒有擺脫傳統MPP數據庫剛性的并發執行策略：無論查詢的復雜度如何，所有的計算節點都需要參與到每條查詢的執行中。這意味著，系統執行一條單行插入語句所使用的計算資源，和執行一條對幾TB數據進行復雜多表連接和聚合的語句所使用的資源是一樣的。這種剛性的并行執行策略，極大地約束了系統的擴展性和吞吐量，同時與Hadoop基于查詢復雜度來調度計算資源的彈性策略也是相違背的。

我們決心對HAWQ的系統架構做一次大的調整，使其更加地Hadoop Native，Hadoop原生，而不僅僅是簡單地將數據放到HDFS上面。當時，我們內部成為HAWQ 2.0，也就是大家現在在github上面看到的Apache HAWQ。

其中最重要的一步是，我們希望計算和存儲不僅物理上分離，邏輯上也是分離。數據庫中的用戶表數據在HDFS上不再按照每個Segment多帶帶來組織，而是按照全局的數據庫對象來組織。舉個例子，我們將一張用戶表對應的多個數據文件（因為當往該表插入數據的時候，為了提高數據插入的速度，系統會啟動了多個QE進程同時往HDFS寫數據，每個QE寫一個多帶帶文件）放到同一個目錄底下，而不是像原來那樣，每個QE進程將文件寫到自己對應的Segment目錄底下。這種改變帶來的一個直觀結果就是，由于所有文件的數據文件都放一起了，查詢執行的時候，根據需要掃描的數據量不同，我們既可以使用一個Segment實例去完成表掃描操作，也可以使用多個Segment實例去做，徹底擺脫了原來只能使用固定個Segment實例來執行查詢的剛性并行執行策略。

當然，HDFS數據目錄組織的改變只是實現HAWQ 2.0彈性執行引擎的一步，但是卻是最重要的一步。計算和存儲的徹底分離，使得HAWQ可以像MapReduce一樣根據查詢的復雜度靈活地調度計算資源，極大地提升了系統的擴展性和吞吐量。

我們簡單比較一下HAWQ 1.x和HAWQ 2.0的資源調度。

左邊展現的是HAWQ 1.x在同時處理三個查詢（分別來自三個不同的會話）時的資源調度情況。與傳統的MPP數據庫一樣，無論查詢的復雜度怎樣，每個Segment實例都會參與到這條查詢的執行中。換句話說，每個Segment實例都會啟動一個QE進程處理分配給它的任務。在這種情況下，系統能夠支持的并發查詢數量，跟集群的計算節點數沒有任何關系，完全由一個計算節點決定（這里，我們先不考慮主節點成為瓶頸的問題）。一個4個節點的HAWQ集群能夠支持的并發查詢數量和一個400個節點的集群是一樣的。

右邊展現的是HAWQ 2.0在同樣并發查詢下的資源調度情況。和Hadoop的MapReduce一樣，我們能夠根據查詢的復雜度決定需要調度多少計算資源參與到每條查詢的執行中。為了簡化闡述，我們這里假設每條查詢只需要兩個計算資源單元。而且，執行單元可以根據資源管理器的調度算法分配到不同的物理計算節點上面。這兩點靈活性：計算資源的數量可變和計算資源的位置可變，正是HAWQ 2.0彈性執行引擎的核心。在這種情況下，系統能夠支持的并發查詢數量，跟集群的計算節點數量呈線性關系：計算節點越多，系統能夠支持的并發查詢數量越多（再次提醒，這里，我們先不考慮主節點成為瓶頸的問題）。

所以，可以說，HAWQ 2.0成功解決了傳統MPP數據倉庫中計算節點首先成為吞吐量瓶頸的問題。同時，由于并不是所有計算節點都需要參與到每條查詢的執行中，HAWQ 2.0同時也解決了傳統MPP數據庫由于單個計算節點性能下降直接影響整個集群性能的問題（這導致MPP集群不能包含太多的計算節點，因為根據概率，集群節點到達一定值后，出現單個計算節點性能下降的概率將會非常高），從而也很大程度上解決了擴展性問題。

通過將計算和存儲徹底分離成功解決了計算節點成為系統吞吐量瓶頸的問題后，現在系統的唯一瓶頸就剩下主節點。

如前面提到，主節點的功能主要分成兩類：元數據管理，包括系統表存儲和管理、鎖管理和分布式事務等等，和計算資源調度管理和執行。前者我們可以看成是狀態管理，后者是沒有狀態的組件。通過將狀態管理提取出來成為多帶帶一個功能層，我們讓主節點跟計算節點一樣變得沒有狀態。這樣，我們能夠根據系統并發查詢的變化，動態增加或者減少主節點的數量。這個設計借鑒了Hadoop YARN的設計，將原來的Job Manager的功能分成了Resource Manager和Application Manager，從而解決Hadoop集群吞吐量的問題。

這是一個云端數據倉庫的架構圖。其實，我們在HashData希望通過云端數據倉庫解決企業用戶使用數據倉庫時碰到的多種難題，包括商業上和技術上。在這里，我們只關注技術上的。

在這個系統架構中，我們將管理即元數據、計算和存儲三者分離了，每一層都能多帶帶動態伸縮，在解決系統吞吐量和擴展性問題的同時，提供了多維度的彈性。

我們利用云平臺的對象存儲服務，如AWS的S3和青云QingCloud的QingStor，作為系統數據的持久層。除了按需付費的經濟特性外，云平臺的對象存儲服務在可擴展性、穩定性和高可用性等方面遠勝于我們自己維護的分布式文件系統（如HDFS）。雖然對象存儲的訪問延遲遠高于本地磁盤訪問，但是我們可以通過本地緩存的策略很大程度減輕延遲問題。

同樣的，我們利用云平臺提供的虛擬機作為我們的計算資源，也能夠一定程度上實現資源的隔離，從而保證不同的工作負載之間沒有相互影響。

云平臺提供的近乎無限的計算和存儲資源（相對于數據倉庫應用來說），使得云端數據倉庫能夠存儲和處理的數據達到一個全新的高度。

最后，我們做一個簡單的總結。從PostgreSQL到Greenplum Database，我們通過大規模并行處理（MPP）技術，實現了處理海量數據時的低延遲目標。從Greenplum Database到Apache HAWQ，通過計算和存儲分析的策略，我們提升了系統的并發處理能力和擴展性。從Apache HAWQ到Cloud Data Warehouse，我們借助云平臺近乎無限的計算資源和存儲資源，以及管理、計算和數據三者分離，還有計算資源嚴格隔離，我們能夠取得近乎無限的并發處理能力和擴展性。

MPP數據庫采取的是流水式的執行引擎，中間的每個階段是不帶檢查點的。這意味著，只有有一個參與到查詢執行的QE進程出錯，整條查詢將會失敗，只能從頭開始重新執行這條查詢。而我們知道，當參與到查詢執行的QE進程達到一定數量的時候，QE進程出錯將是必然的，特別是在一個資源共享的環境中。這時候，即使是重新提交查詢重跑，失敗還是必然的。換句話說，我們幾乎無法成功執行需要調度大量計算資源的查詢。

展望未來，我們希望實現帶檢查點的流水式執行引擎，從而使得系統能夠處理任意大的查詢（單個查詢需要同時調度成千上萬的計算資源）。