GBase8aMPP：一種新型關系數據庫的設計和實踐

李　瀚　天津南大通用數據技術股份有限公司解決方案技術總監

?

GBase8aMPP：一種新型關系數據庫的設計和實踐

李瀚天津南大通用數據技術股份有限公司解決方案技術總監

摘要：隨著行業大數據應用的迅速發展，對基于海量數據的行業大數據的存儲、處理和管理提出了更高要求，傳統的小機+存儲陣列的架構已經無法滿足海量數據增長和系統擴展性的要求。本文總結了一種基于MPP架構+列式存儲設計的新型關系數據庫技術的產品——GBase8aMPP的技術設計思路，這些技術有效解決了傳統架構下的擴展性問題和大規模并行計算問題，并且通過內部高可用機制實現在低價計算平臺上的大數據平臺可靠性。

關鍵詞：大數據；MPP（大規模并行計算）關系數據庫；列式存儲；關系運算

1　引言

關系數據庫是20世紀70年代基于關系代數理論發展的數據管理技術，它將數據以表為單位組織，每個表的數據表現為一個實體，并通過基于范式的數據組織和關聯運算使用SQL言語實現對數據的動態關系生成，這種數據管理概念最大程度反映了應用的實際需求，簡化了信息系統開發時從模型設計到計算程序開發的流程，所以在信息處理領域具有重大的意義。在過去40年的關系數據庫發展中，數據庫一直基于集中存儲和集中計算的計算模式來實現其架構，因為這種模式十分適合關系計算的特征。早期的關系數據庫應用主要適用于金融等典型的交易型領域，后隨著關系數據庫應用的發展，應運產生了數據倉庫應用和BI等相關領域，關系數據庫的應用到達了一個頂峰。隨之，數據量逐漸增大，企業在數據庫相關的基礎設施的投入上，負擔也越來越大，“小機+存儲陣列”模式的系統架構曾經一度成為大企業構建數據庫的標準平臺，對于這樣的平臺，企業動輒用數千萬元投資去維持系統對海量數據的支撐和管理。隨著大數據時代的到來，傳統架構和傳統數據庫所面臨的問題愈加顯著，系統面臨著數據庫系統可擴展性難題，企業開始對傳統數據庫能否管理好如此大規模的數據量，能否可以處理海量數據等發生了懷疑。

傳統數據庫所面臨的問題列舉如下：

（1）數據計算模式依存于集中存儲，而集中存儲的限制引起“小機+存儲陣列”模式無法承載更加大量數據的存儲和處理，并且造成I/O成為瓶頸。此模式下擴展性差，通過傳統Scale UP模式的系統能力幾乎到達極限。

（2）關系數據庫為了按照元組單位管理數據，建立了基于AVL樹的索引機制，這種平衡樹結構雖然引擎能夠保證按照最小路徑尋找數據，但當數據量增長后，索引結構的維護代價將隨著數據量的增加越來越大，導致大數據應用下的數據批量寫入自身就成為難以解決的問題。

（3）隨著數據量增加，更多的數據無法保證維持在內存中，I/O的瓶頸效應將進一步顯著化。

（4）為了保證數據庫數據的持久性和一致性，傳統數據庫管理系統提供基于日志的恢復機制，關系數據庫事務中對數據的更新需要首先記錄到日志中，而日志需要按照預先定義的策略（如WAL）更新到磁盤上，這個無疑會降低數據處理的性能。

（5）單一SMP服務器下的處理能力已經到達極限，對于海量數據條件下的關系運算的關聯運算和聚集運算所需要的計算能力難以滿足。

基于以上問題，從結構上調整傳統關系型數據庫的體系架構就成為必然。其中，NoSQL和NewSQL技術就是解決上述傳統關系數據庫問題時發展而來的新型技術，它們均采用了以ScaleOut為代表的橫向擴展性技術，并且在存儲結構上引入了列式存儲和I/O讀取時的智能過濾技術；在事務控制技術上，NoSQL和NewSQL技術都采用了一系列的弱化或者簡化措施，使得海量數據的處理一致性保障機制獲得一定簡化。

而NewSQL比較NoSQL，它保持了關系數據庫處理復雜關系運算的特性，使關系數據庫中的多表關聯和其他復雜的SQL運算等的高級功能在分布式結構上仍能得到實現，對于需要與結構化數據和關系計算相關的“高級功能”時，NewSQL就成為最佳的選擇。而除去互聯網等行業，對于廣大行業大數據應用而言，結構化數據的相關處理占據了70%以上的行業大數據市場，這也是以MPP數據庫為代表的NewSQL得以存在和發展的實質原因。

2　傳統關系數據庫的改造設計原則

針對以上傳統數據庫所面臨的在存儲、處理結構和事務處理機制上對于大數據應用場景的瓶頸，在新型關系數據庫設計之初，考慮了以下幾方面的技術設計思路，這些設計思路符合當前對關系型大數據平臺的架構設計的基本趨勢。

（1）為了實現存儲和處理能力的擴展性，采取MPP分布式架構，通過ScaleOut方式實現橫向擴展。

（2）通過分布式架構下的SharedNothing架構實現并行I/O，從物理上解決集中存儲所面臨的I/O瓶頸問題。同時，為了保證數據的快速讀取，應盡可能保證數據存儲規則和處理查詢規則的一致性，為了解決這個問題，采用Hash規則實現對各元組入庫時的規則擺放，從而實現SharedNothing架構下的數據快速定位。

（3）通過列式存儲和數據壓縮技術實現數據I/O量吞吐的減少，節約了緩存的消耗。

（4）隨著數據量增加，為了保持數據存取性能的線性，建立更加簡單的索引結構，通過對某一大小的數據單元生成摘要的方式，實現對數據條件的過濾，即從為數據精準定位的索引機制過渡到數據過濾機制，從基于元組的細粒度的索引過渡成為基于數據塊的粗粒度索引機制。

（5）充分考慮關系計算的各個特征，例如Select （Where）、Join、Group By、Order By、Distinct、窗口函數、Insert Into等，最大限度實現在分布式架構下對這些操作符的并行處理能力，并同時減少節點之間的網絡流量。

（6）對于大數據平臺，更新操作，系統內部實際通過Appendonly+有效標記位的位置實現，同時通過有效標記控制數據提交和讀取結果（系統內部可以通過保存多個版本的有效標記位數組來實現事務隔離），這樣可以簡化大數據處理下的事務控制。而數據的恢復，因為系統為了保證更新寫的性能，所以無法按照傳統數據庫的WAL機制實現細粒度日志，而是通過副本作為數據標準，實現故障恢復。這些機制既能保證大數據量下的數據寫的正確性，也能實現處理效率的提升。

3　傳統關系數據庫的分布式化設計中的課題

對于任何技術革新，在引入新技術設計概念的同時，都是有代價的——必然同時引入另一些的問題，對于MPP分布式關系型數據，則可以列舉以下問題：

（1）當一個關系數據庫集群規模擴大時，對于一個大規模集群控制所需的集群協議，協議執行的通信代價將以節點數的平方規模擴大，通信模式的復雜性將導致集群崩潰的可能性增大。

（2）對于關系計算，即使通過MPP+SharedNothing結構實現了數據的物理分離和在分布式存儲上的規則擺放，但很大程度上還是需要將數據層面當作一個整體看待，尤其對于多表Join處理，這就需要一個在分布式上透明實現相關能力的全局機制。

（3）數據劃分是按照Hash Sharding的分片方式實現，所以數據分布與節點個數存在緊耦合性，數據節點一旦出現變化，需要有Hash重新計算的過程，所以擴容實施代價高。

（4）同樣基于以上類似的原因，當一個Hash Sharding下的數據分片是一個按照某種規則連續擺放在一起的數據文件時，它的副本也必然是一個較大片連續的數據單元，這種單元比起單純物理上的文件塊要大很多，所以這就決定了副本分布的集中性，由此導致1臺服務器宕機后，存有和它同樣分片數據的服務器上要增加處理包括副分片在內的活動數據，從而使副分片上數據處理能力迅速降低從而導致“木桶效應”，進而引起集群整體的性能下降。這一點對于會頻繁發生故障的PCServer服務器所組成的大規模MPP集群尤其重要，因為PCServer服務器的故障率比小機類型要高出近10倍以上，并且隨著集群規模的增加，在整個集群中1臺PCServer發生故障的概率會明顯增加，而MPP集群的高可用結構造成1臺PCServer宕機就會引起全MPP集群能力的下降。

（5）數據在按照列式組織存儲時，導致實現表一級的鎖操作，從而導致鎖粒度的升高，造成并發能力的下降等。

4　GBase8　a MPP作為一種新型關系數據庫的技術設計思路

GBase8aMPP作為一種典型的NewSQL型的新型關系數據庫產品，是天津南大通用數據技術股份有限公司（簡稱“南大通用”）完全自主開發的一套國產化支撐結構化大數據處理的MPP型關系數據庫，它于2007年開始了產品開發立項；2010年正式發布第一代單機型列式存儲數據庫；2011年發布了MPP集群版數據庫；2012年參加了中國移動集團VGOP投標的大規模集群測試；于2013年之后，開始了GBase8a MPP在電信、金融等核心行業領域的國產MPP數據庫的實際應用；截至2016年1月，已經在全國70家行業中有過實際應用，共安裝部署節點超過1000臺，實際承載數據量達到5PB級別，對于50節點以上節點數的超大規模MPP集群，GBase8aMPP幾乎覆蓋了超大規模MPP集群部署和使用的主要案例。下面就GBase8aMPP集群的主要技術設計思路進行說明和介紹。

4.1GBase8aMPP的整體架構設計和構成元素

GBase8a MPP集群由GCluster、GNode和GCware 的3個處理要素構成，這3個要素構成了MPP集群的任務調度、實際數據的存儲和任務執行以及集群控制的3項基本要素，作為一個比喻，它們分別相當于MPP集群的“頭”、“腳”和“神經”，具體參見圖1。下面是3個構成要素的具體功能：

圖1　GBase 8a MPP功能架構圖

（1）GCluster集群

從GCware獲得節點的拓撲和節點數據分片的狀態，使用GCware提供的信息（包括集群結構、節點狀態、Eventlog等），并負責SQL解析、SQL優化、分布式執行計劃生成、執行調度。

（2）GCware集群

通過集群各節點之間的廣播通信協議，維持各節點間共享集群狀態信息（包括集群結構、節點狀態、節點資源：包含Scn、Tableid、集群鎖、Eventlog信息等），以及控制故障時的任務切換和故障恢復時的數據修復，并在多副本操作中控制各節點數據的一致性狀態。

（3）GNode集群

集群中最基本的存儲和計算單元。GNode負責集群數據在節點上的實際存儲，并從GCluster接收和執行GCluster產生的執行計劃，執行結果返回給GCluster。數據加載時，GNode直接從集群加載服務接收數據，寫入本地存儲空間。

4.2GBase8aMPP的海量數據的存儲設計

對于承載大規模海量數據的GBase8a MPP平臺，首先要解決海量數據在平臺上有效的存儲和管理，其中對于關系數據庫，一個重要的需要解決的問題就是數據定位，以及簡化存儲路徑的問題。

首先，GBase8a MPP在集群層次會依照在建表時指定的Hash規則，對數據進行在節點之間的精確擺放，數據的擺放原則，可以簡單理解為通過2層的映射，對數據確定準確的擺放節點。

設一個記錄的哈希鍵值為Hashkey，對應這條記錄的Hashvalue = Hash_func（Hashkey），繼而對應這條Hash Value的擺放節點為：HashNode = HashMap （Hashvalue）。

對于同一節點內部的數據定位，GBase8a MPP采取了數據列式存儲和智能索引技術。列式存儲下，各個列上的數據是按照列式文件的格式進行存儲的，也就是說數據列一旦確定，數據文件就可以確定，從某種意義上說，這就像行式存儲下的分區存儲，通過對邏輯上同一張表的數據在物理存儲上的分解，可以進一步確定一個數據的存儲區域。數據在按照列式存儲時，又以65536行作為一個I/O單位（GBase8a將這個單位叫做一個DataCell，即一個數據塊）對其進行壓縮和智能索引的編制工作。智能索引可以起到很好的數據過濾作用，并且它具有很好的空間和時間效率。這里將1 個DataCell數據塊中的數據作為1個集合，而智能索引使用一些標志性的摘要信息來表征一個數據塊中所包含數據的特征集合。實際數據讀取時，不需要直接掃描數據本身，而只需要查看智能索引中的特征集合，就可以判斷要查詢的數據是否在這個數據塊中存在，而特征集合的數據要大大小于存儲數據本身的數據量，并且這個特征集合生成的代價不會因為表內整體數據量的增加而不斷增大，即它是線形的，這與基于傳統關系庫的索引結構有本質不同，傳統數據庫的索引是與表整體的全局數據相關聯的，表的數據量越大，傳統關系庫的索引生成代價就越大。作為這個智能索引中包含的數據特征，在GBase8a中包含這樣幾個基本信息，數據的MaxValue，MinValue或者使用Hash函數構成的位數組等，但數據可能會產生誤判（即數據實際不在該數據塊中，但智能索引中的特征集合又表明數據可能存在于該數據塊中），為了減少誤判，就需要數據在入庫時盡量達到一定的有序性（即使是局部有序性，也可以達到減少誤判的效果）。

讀取數據時為了減少數據I/O吞吐，GBase8a利用列式存儲下數據的相似性，實現了3～30倍的數據高壓縮比（具體數據壓縮比還依存于數據自身的特征和所選擇的數據壓縮算法）。

對于不同的數據類型，GBase8a提供不同的壓縮算法。

（1）對數值類型的壓縮算法

●輕量級壓縮。

●PPM壓縮（壓縮速度快、解壓速度慢）。

●RAPIDZ壓縮，適用于對性能要求較高的用戶場合。

（2）對字符類型的壓縮算法

●輕量級壓縮。

●PPM壓縮（壓縮速度快、解壓速度慢）。

●RAPIDZ壓縮，適用于對性能要求較高的業務場景。

在實際應用中，這些算法可以根據實際需要，去適應性地適配不同種類數據的壓縮，例如對大規模海量數據的存儲，可以根據歷史周期，對近期數據的存儲采用較輕量級壓縮算法；而對于沉淀較長的歷史數據，由于實際參與處理的機會較少，可以使用PPM算法對其壓縮，這樣會在提供高壓縮率的同時，會部分犧牲解壓處理時的性能等。

4.3GBase8aMPP集群的可擴展性設計

GBase8aMPP從設計之初，就充分考慮了作為集群數據庫的可擴展性。隨著行業大數據的飛速發展，單一集群的數據承載量正在從十TB級，到百TB級，再到PB級，所以早期的十數節點集群，和現在的數十節點集群很快就將無法滿足作為大數據處理平臺的MPP集群的規模需求，對于GBase8aMPP集群能否支撐上百節點乃至數百節點的MPP集群規模就成為設計關鍵。GBase8aMPP在設計上，從集群協議棧設計，和數據在節點之間的組織和重分部算法的兩個層面作了優化設計，使MPP集群解決了大規模節點支持的問題。

在架構設計上，GBase 8a MPP采用了Shared Nothing的聯邦分布式架構，由GCluster集群、GCware集群（實際上GCluster和GCware集群往往部署在1個物理集群上）和GNode集群組成。GCluster集群和GCware集群部署在相同的物理節點上，每個物理節點上部署GCluster服務和GCware服務，GCluster服務負責集群任務的調度，GCware服務用于各節點GCluster服務間共享信息。GNode集群的物理節點上部署GNode服務，每個GNode服務就是最基本的存儲和計算單元。

在聯邦架構的集群內部，無論是處理協調調度的GCluster層，還是實際進行數據存取處理的GNode層，都構成了各自處理層的集群結構，從而解決了集群的單點瓶頸或者單點故障問題。而對于集群內部的數據元數據和集群結構元數據的一致性范圍，在聯邦架構下，僅僅局限在了上層的主節點集群上（GCluster集群），這樣達成元數據一致性所需要的節點之間的廣播也將被約束到小范圍節點內，從而防止了因節點數增加而導致的節點間廣播量的膨脹，對于更大規模的處理工作集群（GNode集群），因為節點之間不需要達成共享元數據一致性，所以這一層集群的節點之間不存在復雜的廣播通信機制（節點之間除了副本數據同步，以及在執行Join或者Aggregation運算時的節點之間拉表處理等外，節點之間不存在P2P的通信）。作為GNode集群狀態的維護，主要通過上層集群（GCluster）節點與下層集群（GNode）節點之間的Heartbeat簡易通信機制來實現（簡易的HB機制是有別于集群層面的協議的，HB機制主要用于兩點之間的死活確認，而不需要在集群中的多個節點間具備達成狀態一致性的通信算法）。這樣聯邦架構下的可擴展性因素中，就突破了集群協議的規模限制，考慮GCluster節點上最大Socket張開數等物理限制條件和并發處理數等，最大合理的集群數可以達到300節點程度。

集群的可擴展性，還依存于數據在節點之間重分布的復雜度，對于MPP集群，當它在集群計算Join結果還是擴容時算出搬運結果集時，它都需要對各個紀錄進行HashValue的重計算，而這種重分布計算會嚴重影響數據搬運的速度，例如對于實際擴容處理來說，當考慮實際的HashValue重計算等因素，真正的數據在節點之間的搬運速度只有60MBytes/s左右，而理想的I/O的落地速度可以達到200MBytes/s，也就是說為了維持MPP集群內節點之間數據分布的Hash規則性，數據的搬運效率下降了近70%，這個也是MPP比較NoSQL或者Hadoop等非結構化的分布式平臺在擴展性上的天然不利因素。為了解決這一問題（其實這一問題和后來的高可用專題也有相關），即將每個MPP物理節點下的分片再進行細分，在數據第一次入庫時就將Hashvalue類似的數據列分布在同一列簇文件上，這個列簇文件的粒度越細，在進行數據重分布時，就越能減少Hashvalue重計算的壓力，甚至在一些情況下（如擴容時，當擴容后集群規模恰好是擴容前2倍時），可以將這些細粒度的分片列簇文件直接整片地傳輸到新的節點上，這樣擴容時數據搬運速度就會接近理想的磁盤I/O速度，此擴容方式參見圖2。

4.4GBase8aMPP內部復雜關系計算的實現設計

GBase8a MPP執行復雜查詢以及生成執行計劃時，要遵循以下幾個基本目標：

（1）最大程度地進行并行化。（2）最大化數據局部性，即計算離數據越近越好。（3）關聯（Join）運算的兩個表的數據，要符合“關聯臨近性”原則，實現在同一物理節點上進行。

在這里最終目標是為了盡可能減少MPP節點之間的網絡數據傳輸。

而對于MPP型的關系數據庫引擎，在生成執行計劃邏輯樹時，有一些基本的原則是與傳統關系數據庫相類似的，例如：

（1）盡可能將一元運算遷移到查詢樹的底部（樹葉部分），使之優先執行一元計算。

（2）利用投影和選擇的串接定律，縮減每一關系，以減少中間結果集數據尺寸。

（3）將葉子節點之前的選擇運算作用于所涉及的表，以減少后期運算的結果集。

（4）在查詢樹中，將連接運算下移到并運算（Union All）之前執行。

（5）消去不影響查詢運算的垂直片段。

遵循以上規則得到邏輯層的執行計劃，從計算邏輯上可以降低每個中間步驟的結果集，從而降低物理上的網絡傳輸量和I/O代價。

而GBase8a MPP在從上述原則得到最佳邏輯樹后，需要進一步將邏輯樹轉換成為物理執行樹，這其中關鍵就是要利用MPP集群的跨節點的并行計算能力，而針對關系數據庫的各個操作符的特點（包括Scan、HashJoin、HashAggregation、Union、TopN等），對操作符節點樹進行劃分，劃分為若干計劃分片，GBase8aMPP內部的邏輯執行計劃與物理執行計劃之間關系如圖3所示。下面是最典型的關系操作符的并行化策略：

（1）Join操作

采用靜態Hash或者動態Hash以及復制廣播方式，實現MPP集群下的數據并行關聯運算。所謂靜態Hash，就是關聯表之間的HashKey重合，并且關聯鍵與Hash Key重合，此時MPP數據庫的GCluster只要將關聯操作直接下發到各個單節點上，從各個單節點返回的結果集的合并結果就是關聯運算的結果集；而所謂動態Hash，就是關聯表之間的Hash Key不重合時，將對關聯鍵與Hash鍵不重合的表的數據按照關聯鍵進行重分布，從而使Hash重分布后的兩個表的數據成為HashKey重合的狀態（就是類似靜態Hash的數據分布狀態）；而作為復制廣播方式，也是在HashKey與關聯鍵不重合的方式下的使用的又一種關聯執行機制，這種方式下一般關聯的兩個表中一個表較小，即可以將這個小表通過廣播的方式向所有節點進行動態復制，這樣就可以保證在全節點上并行執行關聯操作。

圖2　基于分片文件搬運的擴容方式

（2）聚合操作

操作符節點首先在各個單節點上執行局部聚合，之后做全部聚合操作。有時也根據Group by鍵的Distinct個數，對于這個數字很大的Groupby鍵，則在聚合運算的第二階段，按照Groupby鍵將第一階段的聚合結果再次進行重分布，在第二階段以并行計算的方式繼續進行全局聚合結果。

（3）Orderby排序操作

操作符節點首先執行本地的Orderby操作，之后對局部排序后的信息進行全局的Order by操作。GBase8aMPP對Orderby可以進行局部排序與全局排序間的流水式并行。

GBase8aMPP作為關系數據庫同樣采用基于成本（CB-Cost Based）的執行計劃優化器方式（CBO），主要基于數據動態的統計特性，實現執行成本的估算。這些統計信息一般包括表數據的行數，生成中間關聯結果集的大小評估，各列的寬度，以及列的Distinct值等。GBase8a MPP的引擎會根據這些統計信息，在執行一個復雜SQL時，去估算一個查詢任務的代價，并且生成多條執行路徑以進行執行成本的比較，從其中選擇代價最小的執行路徑執行本次查詢任務。

4.5GBase8aMPP的可用性設計

圖3　MPP內部高度并行的執行計劃

MPP數據庫為了實現最大的并行，采用了計算和存儲緊密耦合的設計策略，這樣可以有效控制每行數據的存儲位置和每個數據塊的存儲格式，在統計分析場景中性能表現優越。

具體說，MPP分片是按照數學規則（如Hash函數）來分布的，所以數據的分片規則不能像Hadoop那樣按照數據塊（Block）這樣的小粒度單位任意實現（這種小粒度分片可以使1臺物理機上的數據分片的副本分散到多臺物理機上），這樣的數據集合單位無法實現更加細粒度的數據分離，而作為高可用的策略的數據副本的分布策略，也是依存上述的數據分片策略下的集合粒度。

如果1臺物理服務器上只設置1個分片，就會使單個分片和對應這個分片的副本的粒度過大，從而導致1臺服務器宕機后，持有副本的那一節點的負載成為故障切換前正常狀態的2倍。而對于MPP這樣的集群系統，系統的處理能力將取決于集群中處理最慢的那一節點，這種效應就是木桶效應，因為故障切換，導致Safegroup（是一種GBase8a MPP的高可用的舊機制）的另一節點的處理能力會下降一半，并根據上述的木桶效應，整個集群的處理也將會下降一半。

為了解決上述問題，GBase8a MPP實現了基于虛擬分片的副本分布機制：即1個物理節點可以部署多個邏輯分片，并且每個邏輯分片的副本分片可以部署在不同物理機上，這樣一臺物理機宕機后，這臺物理機上邏輯分片的副本因為分散到多臺節點上，所以可以保證宕機服務器的負載不僅可以實現故障轉移，而且可以實現故障服務器上負載在故障轉移后的負載均衡，具體基于虛擬分片的高可用機制實現如圖4所示。

圖4　GBase 8a PP的虛擬分片和副本技術

4.6GBase8aMPP下的事務控制設計

作為數據庫系統與文件系統的最大區別，就是數據庫系統要支持基于DML操作的數據更新，并且作為關系數據庫的又一關鍵特性就是要保證數據的一致性和在任務并發時的讀寫數據之間的邏輯一致性。傳統數據庫提出WAL（預寫日志記錄，Writeahead Log）機制保證了這種數據的邏輯一致性，但它的代價很大，因為這種機制會在執行任意更新時需要將更新永久化到磁盤的日志文件上。GBase8aMPP數據庫設計之初就是要考慮數百億，數千億行所組成的表的數據管理，所以它無法采用WAL式的做法，并且GBase8aMPP在內部進行任務數據寫處理時，包括load加載處理，還是insert，update操作，最終都是通過對各個列式數據文件（多個分片時，就被分割成為列簇文件）的Append處理實現的。與傳統數據庫不同，不可能對數據更新設置更大的Buffer區域，數據寫入磁盤的操作基本是按照之前說的數據塊（DataCell）單位進行的（也可以設置DC的Windows Size，這樣就可以按照Windows Size個數個DC進行批量寫入操作），數據更新基本就是按照寫滿1個DC之后（或是1個DC窗口），就永久化到磁盤的方式進行更新的。而一個MPP下的事務單位很大，有可能是成千上萬個DC，所以MPP為了標記已經一時寫入到磁盤上的DC的有效性，就設置了1個Valid_flag數據有效性標志，當途中不斷將數據寫入到磁盤時，數據的有效標志設置為“0”，這說明這個數據塊的數據暫時無效，如果同時發生讀操作時，這樣的數據是不會被讀到的。但當任務完成，數據集體提交時，各個數據上的Valid_flag會批量更新成“1”，從而使數據對其他任務也生效，可以讓其他任務開始讀取到這里提交的數據。對于Update這樣的操作，在將更新后的數據完成Append處理后，它還要進而對更新前數據進行Valid_flag=“0”的重置操作，最終才能進行提交操作（對更新后數據對應的Valid_flag置為“1”）。當然在整個過程中，如有出現系統故障，系統會保持更新操作前的Valid_flag狀態，從而保證數據更新到中途的內容不會被其他任務看到。GBase8aMPP內部的有效符機制如圖5所示。

圖5　GBase 8a MPP內部的有效標識符

而對于Valid_flag自身的更新操作，考慮其數據量較小，可以使用類似WAL預寫日志的方式，保證Valid_flag提交時的事務性。對于事務自身參照自身產生的數據時，則采用對Valid_flag的多版本管理（MVCCforValid_flag）機制實現對自身更新中數據的最新參照。

對于1個MPP集群系統來說，還必須考慮主分片與副分片之間的數據一致性，主副分片的一致性機制一般可以通過經典的預備提交（也稱兩階段提交）來實現，GBase8aMPP可以通過兩種方式實現：

（1）一種方式是在兩個分片上同時處理DML等關系數據庫操作，當主分片需要提交時（即按照上述的Valid_flag置位方式實現），會向副分片發出提交請求，如果副分片已經處理完本次任務，它會直接返回主分片一個ACK+消息，如果副分片還沒有完成本次任務，它會返回主分片一個ACK-消息，表明還需要等待（GBase8a MPP可以設置等待超時），當主分片接到從副分片發來的ACK+消息時，它會指示副分片一塊提交更新完的數據。

（2）作為另一種方式，是先更新主分片上數據，再由主分片將數據轉發到副分片上，這個數據轉發機制可以保證更新數據按照增分傳輸的方式，準確傳輸到副分片上，而當主分片完成數據更新后，它會按照與上面第一種DML提交同樣的方式，提交本次更新。GBase 8a MPP內部的副本生成機制如圖6所示。

實際MPP集群對副本的一致性進行了一定的緩和，即當主副分片中有任意一個分片無法工作的時刻，集群可以允許主副分片之間的數據非一致性，并允許集群整體的事務可以強制提交，這時集群的GCware會在健康的分片上保留1個Eventlog事件日志，記錄故障分片上丟失的那個操作（這個操作可能是一個DML數據更新操作，也可能是一個DDL操作），而此后當故障節點上的那個分片恢復正常的時候，GCware會從Eventlog的事件日志中探測出需要恢復的操作，進而調用相關進程完成故障節點分片向健康分片上數據的數據追平，從而完成故障后數據恢復。

此外，對于GBase8aMPP集群，為了完成并發下的事務正確的執行能力，采用了適合于MPP和列式存儲的并發控制策略。作為GBase8aMPP采用的最簡單的并發控制方式，是采用表級鎖機制，之后采用對DCWindowssize內的連續數據塊的DC鎖機制從而減少鎖粒度，這種機制實際上就是在內存區域上設置了針對各個事務的獨立的數據更新區域，既提高了寫操作的速度，也同時提高并發的處理能力。隨著GBase 8aMPP的分片文件自身的細化，數據分片將變得更小，將數據從內存中的DC寫入到分片文件時，由于分片文件存在多個，1個Hash段內的DC數據在向對應分片數據寫入數據時，如果遇到文件被鎖住的情況，它還可以將另一Hash段內的DC數據寫入其他分片文件上，這樣就減少了因鎖而導致的數據寫性能的下降。

圖6　GBase 8a MPP內部的副本生成機制

5　GBase8　aMPP數據庫的應用實踐

GBase8a MPP作為一種分布式的列式關系數據庫，已經應用到了電信和金融等核心行業，從實際項目中我們總結了大量項目經驗，這些經驗對于充分發揮MPP數據庫的能力是十分有益的。

5.1基于MPP+Hadoop的混搭技術

MPP作為一種基于分布式列式關系數據庫，能夠支撐在海量結構化數據基礎之上的關系運算，但作為非結構化數據的處理和關系型運算以外的算法，MPP并不擅長，而作為實際的大數據應用，則發現大數據的4V特性經常會同時成為需求特征，這就需要構建一個綜合的大數據平臺，而從實際工程中，總結了MPP+ Hadoop的混搭結構能夠有效解決此類問題。作為一個最典型的場景，Hadoop作為MPP的前端ETL平臺，可以對非結構化數據進行結構化轉換和低層匯總，或者是從圖像等完全非結構化數據中提取特征量等，之后將提煉的結構化數據結果集載入MPP，利用MPP庫內強大的數據表的關聯能力，將Hadoop平臺的生成數據與載入MPP的從其他業務系統數據源載入的數據進行關聯融合，從而得到傳統數據倉庫下無法實現的深度分析能力。對于一個電信運營商的大數據系統，就經常使用這一模式構建大數據平臺，使用Hadoop對信令和位置信息進行結構化轉換和低層匯總。另外，從BOSS、CRM等業務系統整合而來的業務結構化數據同Hadoop加工后的數據結果一并放入GBase 8a MPP，在GBase8aMPP庫內綜合客戶資料和用為行為軌跡以及上網行為等的全用戶圖像信息（這些信息可以適用于精準營銷場景中）。

5.2Hashkey的合理選擇

合理設置數據表的Hash Key對于提高MPP的計算并行度以及減少節點之間的數據傳輸至關重要，所以HashKey的選擇在GBase8aMPP工程實施過程中，是作為數據模型設計階段最重要的工作被認知，根據眾多工程經驗，總結以下因素是在建立HashKey時最重要的考慮因素。

●盡量選擇Count（Distinct）值大的列做Hash分布列，讓數據均勻分布，避免數據傾斜產生木桶效應。

●優先考慮大表間的Join，盡量讓大表Join條件的列為Hash分布列（相關子查詢的相關Join也可以參考此原則），以使得大表間的Join可以直接分布式執行。

●其次考慮Groupby，盡量讓Groupby帶有Hash分布列，讓分組聚合一步完成。

●通常是等值查詢的列，并且使用的頻率很高的應考慮建立為Hash分布列。

5.3列式存儲下寬表的使用

列存以列為單位組織底層文件存儲，在Select投影列一定的情況下，表寬對查詢性能沒有影響，并且考慮數據壓縮等優勢，利用寬表設計可在無任何負面影響的前提下，提升關系計算結果集生成時的效率。工程項目現場總結的經驗：對于需要大表關聯生成查詢結果的一些場景（多個大表關聯并有一些過濾條件），在數據膨脹率可接受的情況下可以將大表關聯提前進行預處理，并將預處理結果保存為一張寬表，將原來的基于大表多表關聯的查詢轉化為基于預處理結果表的單表查詢，可以有效提升這類SQL查詢的執行效率，同時提高此類查詢的并發能力。

5.4合理利用壓縮算法

壓縮在節省存儲空間的同時，可減少I/O吞吐，從而提升性能。但考慮解壓等因素等，壓縮在某種場景下，如果使用不合理，可能會導致性能的“不生而降”。

對于GBase8aMPP的實際應用場景，總結了以下經驗：

●如果對存儲空間要求高，對性能不太要求時，建議使用高壓縮比壓縮算法。

●如果對存儲空間要求不高，對性能要求高時，建議使用一般壓縮比壓縮算法。

5.5提高數據質量以提高處理效率

GBase8aMPP處理的效率直接依存于入庫時的數據質量，數據質量的惡劣可能導致數據Hash分布的無效性或者智能索引的無效性。下面是針對GBase8a MPP在實際項目中運用時，總結的一些和數據質量控制相關的最佳經驗。

●數值類型的處理性能比字符串要好，建議選擇數值類型。

●對于表間關聯常用的字段，各表應該設計成同樣的字段類型。

●在表關聯運算中，如果對各表的Hash分布列加Rtrim、ltrim函數會改變Hash Join的執行計劃，必須去掉。為回避此類情形，必須保證加載入庫前的數據文件內的數據質量，以保證字段數據的正確性。

類似經驗還很多，出于文章篇幅原因，這里不再一一講解。但有一點要注意，就是GBase8aMPP雖然作為一種關系數據庫，由于其存儲架構和處理架構上的不同，所導致數據庫設計規范會與傳統關系數據庫有所差別，從傳統數據庫遷移到GBase8aMPP時，需要考慮相關的調整因素，以充分發揮遷移到MPP后的應用性能的改善效果。

6　結束語

GBase8aMPP作為一款在國內行業大數據市場最廣泛使用的新型關系型數據庫（NewSQL），在設計上根本突破了傳統型關系數據庫的限制，在列式存儲架構和MPP+Shared Nothing大規模處理并行架構設計上作了各種富有創造性的功能特性開發，在充分發揮MPP型列式數據庫的處理優勢同時，回避了由于MPP分布式和列式存儲等所導致的新派生問題，并且保證了系統的可靠性。

同時，GBase8a MPP在進入行業市場的近6年時間里，從工程實施到實際運用部署，積累了大量的實踐經驗，這些都有力消化了新技術在向實際行業應用導入時的各項風險，并且通過迅速的技術迭代，GBase8a MPP正在成為大數據行業最有競爭力的逐步成熟的大數據平臺級產品。

參考文獻

［1］舍恩伯格.大數據時代［M］.杭州：浙江人民出版社，2012.

［2］.張俊林.大數據日知錄：架構和算法［M］.北京：電子工業出版社，2014.

［3］陸嘉恒.大數據挑戰與NoSQL數據庫技術［M］.北京：電子工業出版社，2013.

［4］邵佩英.分布式數據庫系統及其應用［M］.北京：科學出版社，2005.

［5］George Coulouris，Jean Dollimore，Tim Kindberg，Gordon Blair.分布式系統：概念與設計（原書第5版）［M］.北京：機械工業出版社，2013.

［6］BonifatA，ChrysanthisPK，OukselAM.Distributeddatabases and peer to peer database：past and present［J］. SIGMOD record，2008.

［7］Copeland GP，Khoshafian SN.Adecompositionstoragemodel ［C］.ProcofThe1985ACMSIGMODInternationalconferenceon ManagementofData，1985.

AnewSQLtechniques’s architecture design and practice for relational database

LIHan

Abstract:With the rapid development of the industrial big data， the Big Data applications in industrial fields have proposed more higher demands for data management techniques such as data storage and data processing.As traditional architecture of mini-computer and array storage，it has limited the capacity and scalability ofDBMSsystem. This paper have summarized the key techniques a kind of NewSQLDBMS-GBase 8a MPPbased on MPPand column-oriented architecture. By the advanced techniques of GBase 8aMPP， we can effectively solve the restrications faced by traditional database such as scalability， parallel computing capacity for massive data， and high availability under inexpensive hardware conditions.

Keywords:big data； massive parallel processing； relational database； column-orientedDBMS；relational operator

收稿日期：（2016-03-28）