摘要：前面我們簡單闡述了分布式數(shù)據(jù)庫的架構(gòu)，并通過一條簡單的查詢語句解釋了分布式的執(zhí)行計劃。

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

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

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

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

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

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

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

我們接下來要講的開源Greenplum Database就是基于PostgreSQL的MPP數(shù)據(jù)庫。對應(yīng)到這個架構(gòu)圖，每個節(jié)點上面的數(shù)據(jù)庫實例可以簡單的認為是一個PostgreSQL實例。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Greenplum on HDFS作為一個原型系統(tǒng)，驗證了MPP數(shù)據(jù)庫和HDFS是可以很好地整合起來工作的?；谶@個原型系統(tǒng)，我們開始將它當成一個真正的產(chǎn)品來打造，也就是后來的HAWQ。

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

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

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

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

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

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

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

我們決心對HAWQ的系統(tǒng)架構(gòu)做一次大的調(diào)整，使其更加地Hadoop Native，Hadoop原生，而不僅僅是簡單地將數(shù)據(jù)放到HDFS上面。當時，我們內(nèi)部成為HAWQ 2.0，也就是大家現(xiàn)在在github上面看到的Apache HAWQ。

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

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

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

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

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

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

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

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

這是一個云端數(shù)據(jù)倉庫的架構(gòu)圖。其實，我們在HashData希望通過云端數(shù)據(jù)倉庫解決企業(yè)用戶使用數(shù)據(jù)倉庫時碰到的多種難題，包括商業(yè)上和技術(shù)上。在這里，我們只關(guān)注技術(shù)上的。

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

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

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

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

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

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

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