digoal
2016-11-10
greenplum , hawq , postgresql , mpp , olap , hdfs , hadoop
本文是hashdata發表的關于greenplum, hawq的文章，内容很豐富，向作者緻敬，收藏。
hashdata是原pivotal hawq的開發團隊出去創業創辦的大資料産品公司。
轉自
<a href="https://segmentfault.com/a/1190000007419222?from=groupmessage&isappinstalled=0">https://segmentfault.com/a/1190000007419222?from=groupmessage&isappinstalled=0</a>
引言
第八屆中國架構師大會（sacc2016）10月27号到29号在北京萬達索菲特大飯店成功舉辦。大會以“架構創新之路“為主題，雲集了國内外頂尖專家，共同探讨雲計算和大資料等技術背景下，如何通過架構創新及各種it新技術來帶動企業轉型增效。作為一家專注于雲端資料倉庫的初創公司，酷克資料受邀在sacc2016 “資料庫平台架構及變遷”分會場作了題為“資料倉庫架構及變遷”的演講。以下是這次演講的ppt。
這個日程安排同時也是我們公司核心團隊的技術進階史。公司創始團隊成員有幸以核心開發者的角色參與，從單機版的關系型資料庫（postgresql），大規模并行處理（mpp）資料庫（greenplum database）到sql on hadoop解決方案（apache hawq），以及最新的sql on cloud資料倉庫（hashdata）。通過回顧這個技術演進的曆程，我們将闡述如何一步一步地解決聯機分析（olap）系統低延遲、高并發以及擴充性問題。
postgresql
由于後面讨論的所有的分布式資料庫，包括greenplum database，apache hawq以及hashdata雲端資料倉庫，都是基于單機版關系型資料庫postgresql的，是以我們首先簡單介紹一下postgresql，作為後續讨論的基礎。
每個postgresql資料庫的執行個體包含一個postmaster的damon程序和多個子程序,包括負責寫出髒資料的bg writer程序，收集統計資訊的stats collector程序，寫事務日志的wal writer程序，等等。
用戶端應用通過libpq協定連接配接到postmaster程序；postmaster收到連接配接請求後，fork出一個子程序postgres server來處理來自這個連接配接的查詢語句。postgres server程序的功能元件可以分成兩大類：查詢執行和存儲管理。查詢執行元件包括解析器、分析器、優化器以及執行器。在查詢執行過程中，需要通路和更新系統狀态和資料，包括緩存，鎖，檔案和頁面等等。
greenplum
作為一個單機版的關系型資料庫，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之間的狀态一緻，我們能夠實作計算節點的高可用。
hawq
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程序出錯将是必然的，特别是在一個資源共享的環境中。這時候，即使是重新送出查詢重跑，失敗還是必然的。換句話說，我們幾乎無法成功執行需要排程大量計算資源的查詢。
展望未來，我們希望實作帶檢查點的流水式執行引擎，進而使得系統能夠處理任意大的查詢（單個查詢需要同時排程成千上萬的計算資源）。