從架構特色到功能缺陷，從新認識分析型分佈式數據庫

寫在前面

本文是分佈式數據庫的總綱文章的第一部分，主要探討分析性分佈式數據庫的發展和技術差別；第二部分則是交易性數據庫的一些關鍵特性分析。Ivan開始計劃的分佈式數據庫是不含分析場景的，因此嚴格來講本篇算是番外篇，後續待條件具有將以獨立主題的方式展開。

特別說明：本文是原創文章，首發在DBAplus社羣，轉載須得到做者贊成。

---

正文

隨着大規模互聯網應用的普遍出現，分佈式數據庫成爲近兩年的一個熱門話題。一樣，在銀行業主推X86限制主機與小型機的背景下，傳統的單機數據庫逐漸出現了一些瓶頸，立刻會面臨是否引入分佈式數據庫的問題。

近期，Ivan在我的公衆號就「銀行引入分佈式數據庫的必要性」作過一些展望，並收到了一些朋友的反饋，除了對分佈式數據庫具體技術探討外，還有一類頗有趣的建議，「能不能也講講Teradata、Greenplum這類MPP，這些也是分佈式數據庫，但老闆老是認爲OLTP場景下的纔算數」。

的確，爲了解決OLAP場景需求，其實很早就出現了分佈式架構的產品和解決方案，其與目前的OLTP方案有不少共通的地方。並且Ivan相信，從此OLAP和OLTP兩個分支技術的發展也必然是交錯前行，能夠相互借鑑的。

鑑於此，本文會將OLAP類場景的分佈式數據也歸入進來，從兩個維度對「分佈式數據庫」進行拆解，第一部分會橫向談談不一樣的「分佈式數據庫」，把它們分爲五類並對其中OLAP場景的三類作概要分析；第二部分結合NoSQL與NewSQL的差別，縱向來談談OLTP場景「分佈式數據庫」實現方案的關鍵技術要點，是前文的延伸，也是分佈式數據庫專題文章的一個總綱，其中的要點也都會單獨撰文闡述。

首先，Ivan們從橫向談談不一樣的「分佈式數據庫」：

###1、萬法同宗RDBMS

1990年代開始，關係型數據庫（RDBMS）成爲主流，典型的產品包括Sybase、Oracle、DB2等，同期大約也是國內IT產業的起步階段。RDBMS的基本特徵已有學術上的定義，這裏再也不贅述。

但從實際應用的角度看，Ivan認爲有兩點最受關注：

1. 內部以關係模型存儲數據，對外支持ANSI SQL接口；

2. 支持事務管理ACID特性，尤爲是強一致性（指事務內的修改要麼所有失敗要麼所有成功，不會出現中間狀態）。

然後出現的各類「分佈式數據庫」，大多都是在這兩點上作權衡以交換其餘方面的能力。

「數據庫」雖然有經典定義，但不少大數據產品或許是爲了標榜對傳統數據庫部分功能的替代做用，也借用了「數據庫」的名號，致使在實踐中這個概念被不斷放大，邊界愈來愈模糊。本文一個目標是要釐清這些產品與經典數據庫的差別與傳承，因此不妨先弱化「數據庫」，將其放大爲「數據存儲」。

那麼怎樣纔算是「分佈式數據存儲」系統？

「分佈式」是一種架構風格，用其實現「數據存儲」，最現實的目的是爲了打開數據庫產品的性能天花板，並保證系統的高可靠，進一步展開，「分佈式數據庫」的必要條件有兩點：

• 支持水平擴展，保證高性能

經過增長機器節點的方式提高系統總體處理能力，擺脫對專用設備的依賴，而且突破專用設備方案的性能上限。這裏的機器節點，一般是要支持X86服務器。

• 廉價設備+軟件，保證高可靠

在單機可靠性較低的前提下，依靠軟件保證系統總體的高可靠，又能夠細分爲「數據存儲的高可靠」和「服務的高可靠」。總之，任何單點的故障，可能會帶來短期、局部的服務水平降低，但不會影響系統總體的正常運轉。

將這兩點做爲「分佈式數據庫」的必要條件，Ivan大體概括了一下，至少有五種不一樣的「分佈式數據庫」：

• NoSQL

• NewSQL

• MPP

• Hadoop技術生態

• Like-Mesa

注：也許有些同窗會提到Kafka、Zookeeper等，這些雖然也是分佈式數據存儲，但由於具備鮮明的特色和適用場景，無需再歸入「數據庫」概念進行探討。

這五類中，前兩類以支持OLTP場景爲主，後三類則以OLAP場景爲主。Ivan將按照時間線，主要對OLAP場景下的三類進行概要分析。

###2、OLAP場景下的分佈式數據庫

1990-2000年代，隨着應用系統普遍建設與深刻使用，數據規模愈來愈大，國內銀行業的「全國大集中」基本都是在這個階段完成。這期間，RDBMS獲得了普遍運用，Oracle也擊敗Sybase成爲數據庫領域的王者。

在知足了基本的交易場景後，數據獲得了累積，進一步的分析性需求天然就涌現了出來。單一數據庫內同時支持聯機交易和分析需求存在不少問題，每每會形成對聯機交易的干擾，所以須要新的解決方案。這就爲MPP崛起提供了機會。

####1. MPP

MPP（Massively Parallel Processing）是指多個處理器（或獨立的計算機）並行處理一組協同計算[1]。

爲了保證各節點的獨立計算能力，MPP數據庫一般採用ShareNothing架構，最爲典型的產品是Teradata（簡稱TD），後來也出現Greenplum（簡稱GPDB）、Vertica、Netezza等競爭者。

架構特色：

MPP是多機可水平擴展的架構，符合「分佈式」的基本要求，其中TD採用外置集中存儲而GPDB直接使用本地磁盤，從這點來講GPDB是更完全的Share Nothing架構。

考慮到TD商業策略上採用一體機方案，不具備開放性，而GPDB具備較高的開源程度，下文中經過分析後者架構特色來分析MPP工做機制。

GPDB屬於主從架構[2]，Slave稱爲Segment是主要的數據加工節點，是在PostgreSQL基礎上的封裝和修改，自然具有事務處理的能力，可進行水平擴展；集羣內有惟一Active狀態的Master節點，除了元數據存儲和調度功能外，同時承擔必定的工做負載，即全部外部對集羣的數據聯機訪問都要通過Master節點。

在高可靠設計方面，首先設置了Standby Master節點，在Master節點宕機時接管其任務，其次將Segment節點則細分爲兩類不一樣角色Primary和Mirror，後者是前者的備節點，數據提交時在二者間進行強同步，以此保證Primary宕機時，Mirror能夠被調度起來接替前者的任務。

<div align=center>  </div>

數據分析性需求對IT能力的要求包括：

• 複雜查詢能力；

• 批量數據處理；

• 必定的併發訪問能力。

MPP較好的實現了對上述能力的支撐，在前大數據時代獲得了普遍的應用，但這個時期的數據總量相對仍然有限，廣泛在TB級別，對應的集羣規模也一般在單集羣百節點如下。

隨着數據價值關注度的不斷提高，愈來愈多的數據被歸入企業分析範圍；同時實際應用中考慮到數據存儲和傳輸成本，每每傾向於將數據集中在一個或少數幾個集羣中，這樣推進了集羣規模的快速增加。

在大規模集羣（幾百至上千）的使用上，MPP從批處理和聯機訪問兩個方面都顯現了一些不足。如下內容主要借鑑了Pivotal（GPDB原廠）的一篇官方博客[3]。

注：有位同窗給出的譯文也具備較好的質量，推薦閱讀[4]。

缺陷：

• 批處理

MPP架構下，工做負載節點（對GPDB而言是Segment節點）是徹底對稱的，數據均勻的存儲在這些節點，處理過程當中每一個節點（即該節點上的Executor）使用本地的CPU、內存和磁盤等資源完成本地的數據加工。這個架構雖然提供了較好的擴展性，但隱藏了極大的問題——Straggler，即當某個節點出現問題致使速度比其餘節點慢時，該節點會成爲Straggler。

此時，不管集羣規模多大，批處理的總體執行速度都由Straggler決定，其餘節點上的任務執行完畢後則進入空閒狀態等待Straggler，而沒法分擔其工做。致使節點處理速度下降的緣由多數是磁盤等硬件損壞，考慮到磁盤自己的必定故障率（根據Google統計前三個月內2%損壞率，第二年時達到8%）當集羣規模達到必定程度時，故障會頻繁出現使straggler成爲一個常規問題。

• 併發

因爲MPP的「徹底對稱性」，即當查詢開始執行時，每一個節點都在並行的執行徹底相同的任務，這意味着MPP支持的併發數和集羣的節點數徹底無關。根據該文中的測試數據，4個節點的集羣和400個節點的集羣支持的併發查詢數是相同的，隨着併發數增長，這兩者幾乎在相同的時點出現性能驟降。

傳統MPP的聯機查詢主要面向企業管理層的少數用戶，對併發能力的要求較低。而在大數據時代，數據的使用者從戰略管理層轉向戰術執行層乃至一線人員，從孤立的分析場景轉向與業務交易場景的融合。對於聯機查詢的併發能力已經遠超MPP時代，成爲OLAP場景分佈式數據庫要考慮的一個重要問題。

除上述兩點之外，GPDB架構中的Master節點承擔了必定的工做負載，全部聯機查詢的數據流都要通過該節點，這樣Master也存在必定的性能瓶頸。同時，在實踐中GPDB對數據庫鏈接數量的管理也是很是謹慎的。在Ivan曾參與的項目中，Pivotal專家給出了一個建議的最大值且不會隨着集羣規模擴大而增大。

綜上，大體能夠得出結論，MPP（至少是GPDB）在集羣規模上是存在必定限制的。

2000-2010年代，大多數股份制以上銀行和少部分城商行都創建了數據倉庫或ODS系統，主要採用了MPP產品。能夠說，這十餘年是MPP產品最輝煌的時代。到目前爲止，MPP仍然是銀行業建設數據倉庫和數據集市類系統的主要技術選擇。爲了規避MPP併發訪問上的缺陷以及批量任務對聯機查詢的影響，一般會將數據按照應用粒度拆分到不一樣的單體OLTP數據庫中以支持聯機查詢。

####2. Hadoop生態體系

MPP在至關長的一段時期內等同於一體機方案（以TD爲表明），其價格高昂到普通企業沒法承受，多數在銀行、電信等行業的頭部企業中使用。2010年代，隨着大數據時代的開啓，Hadoop生態體系以開源優點，得到了蓬勃發展和快速普及。

Hadoop技術體系大大下降了數據分析類系統的建設成本，數據分析挖掘等工做由此步入「數據民主化」時代。在Hadoop生態體系中，分析需求所須要的能力被拆分爲批量加工和聯機訪問，經過不一樣的組件搭配實現。批量加工以MapReduce、Tez、Spark等爲執行引擎，爲了得到友好的語義支持，又增長了Hive、SparkSQL等組件提供SQL訪問接口。

聯機訪問部分，則從早期Hive過渡到Impala、Hawk以及Kylin、Presto等方案逐漸下降了訪問延時。

• 架構特色：

Hadoop生態體系下HDFS、Spark、Hive等組件已經有不少文章介紹，本文再也不贅述。總的來講，其架構的着力點在於數據高吞吐處理能力，在事務方面相較MPP更簡化，僅提供粗粒度的事務管理。

• 缺陷：

Hadoop也有其明顯的缺陷，主要是三點：

• 批量加工效率較低

MPP的擁護者每每會詬病Hadoop計算引擎執行效率低。的確，在同等規模的集羣執行相同的數據加工邏輯，即便與Spark對比，MPP所耗費的時間也會明顯更少些[3]，其主要的緣由在於二者對於數據在磁盤和內存中的組織形式不一樣。

MPP從RDBMS而來（例如Vertica和GPDB都是基於PostgreSQL開發），對數據的組織形式更貼近傳統方式，按區、段、塊等單位組織，對數據進行了預處理工做以提高使用時的效率；Hadoop生態體系以HDFS文件存儲爲基礎，HDFS並不像傳統數據庫那樣獨立管理一塊連續的磁盤空間，而是將數據表直接映射成不一樣的數據文件，甚至表分區也以目錄、文件等方式體現。

HDFS最簡單的txt格式乾脆就是平鋪的數據文件，處理過程不免要簡單粗暴一些，但隨着Avro、ORCFile、Parquet等不少新的存儲格式相繼被引入，基於HDFS的批處理也更加精細。從總體架構來看，Hadoop更加看重大數據量批量處理的吞吐能力。

同時，Hadoop具有MPP所缺失的批量任務調整能力，數據的多副本存儲使其具備更多「本地化」數據加工的備選節點，並且數據加工處理與數據存儲並不綁定，能夠根據節點的運行效率動態調整任務分佈，從而在大規模部署的狀況下具備總體上更穩定的效率。相比之下，MPP在相對較小的數據量下具備更好的執行效率。

• 不能無縫銜接EDW實施方法論

在長期的實踐中，企業級市場的主流集成商針對EDW項目沉澱了一套固定的實施方法，與MPP特性相匹配，但Hadoop並不能與之無縫對接。一個最典型的例子是歷史數據的存儲，傳統方法是採用「拉鍊表」的形式，即對於當前有效的數據會記錄其生效的起始時間，在數據被更改或刪除後，在該行記錄的另一列記錄失效時間。這樣，當前數據即變動爲歷史數據，經過這種增量的表述方式，節省了大量的存儲空間和磁盤IO。

能夠看出，拉鍊表的設計思想其實與基於時間戳的MVCC機制是相同的。

HDFS做爲Hadoop的存儲基礎，其自己不提供Update操做，這樣全部在數據操做層面的Update最終會被轉換爲文件層面的Delete和Insert操做，效率上顯著下降。據Ivan所知，在不少企業實踐中會將這種增量存儲轉換爲全量存儲，帶來大量數據冗餘的同時，也形成實施方法上的變動。

• 聯機查詢併發能力不足

對於聯機查詢場景，最多見的是SQL on Hadoop方案，將Impala、HAWQ等MPP引擎架設在HDFS基礎上，批量數據與聯機查詢共用一份數據。MPP引擎借鑑了MPP數據庫的設計經驗，相對Hive等組件提供了更低的延遲。但存在一個與MPP相同的問題，即併發能力不足。

經過一些項目測試中，Ivan發如今大致相同的數據量和查詢邏輯狀況下， Impala併發會低於GPDB。其緣由多是多方面的，不排除存在一些調優空間，但在系統架構層面也有值得探討的內容。例如在元數據讀取上，Impala複用了Hive MetaStore，但後者提供的訪問服務延時相對較長，這也限制了Impala的併發能力[7]。

####3. Like-Mesa

Mesa是Google開發的近實時分析型數據倉庫，2014年發佈了論文披露其設計思想[5]，其經過預聚合合併Delta文件等方式減小查詢的計算量，提高了併發能力。

Mesa充分利用了現有的Google技術組件，使用BigTable來存儲全部持久化的元數據，使用了Colossus (Google的分佈式文件系統)來存儲數據文件，使用MapReduce來處理連續的數據。

Mesa相關的開源產品爲Clickhouse[6]（2016年Yandex開源）和Palo[7]（2017年百度開源）。

架構特色：

目前ClickHouse的資料仍以俄語社區爲主，爲便於你們理解和進一步研究，下面主要以Palo爲例進行說明。

Palo沒有徹底照搬Mesa的架構設計的思路，其藉助了Hadoop的批量處理能力，但將加工結果導入到了Palo自身存儲，專一於聯機查詢場景，在聯機查詢部分主要借鑑了Impala技術。同時Palo沒有複用已有的分佈式文件系統和類BigTable系統，而是設計了獨立的分佈式存儲引擎。雖然數據存儲上付出了必定的冗餘，但在聯機查詢的低延遲、高併發兩方面都獲得了很大的改善。

Palo在事務管理上與Hadoop體系相似，數據更新的原子粒度最小爲一個數據加載批次，能夠保證多表數據更新的一致性。

總體架構由Frontend和Backend兩部分組成，查詢編譯、查詢執行協調器和存儲引擎目錄管理被集成到Frontend；查詢執行器和數據存儲被集成到Backend。Frontend負載較輕，一般配置下，幾個節點便可知足要求；而Backend做爲工做負載節點會大幅擴展到幾十至上百節點。數據處理部分與Mesa相同採用了物化Rollup（上卷表）的方式實現預計算。

<div align=center>  </div>

Palo和ClickHouse都宣稱實現了MPP Data Warehouse，但從架構上看已經與傳統的MPP發生很大的變化，幾乎徹底捨棄了批量處理，專一於聯機部分。

ClickHouse和Palo做爲較晚出現的開源項目，還在進一步發展過程當中，設定的使用場景以廣告業務時序數據分析爲主，存在必定侷限性，但值得持續關注。

---

文獻參考：

[1] http://en.wikipedia.org/wiki/Massively_parallel

[2] http://greenplum.org/gpdb-sandbox-tutorials/introduction-greenplum-database-architecture/#ffs-tabbed-11

[3] Apache HAWQ: Next Step In Massively Parallel Processing,

https://content.pivotal.io/blog/apache-hawq-next-step-in-massively-parallel-processing

[4] 對比MPP計算框架和批處理計算框架，

http://blog.csdn.net/rlnLo2pNEfx9c/article/details/78955006

[5] A. Gupta and et al., 「Mesa: Geo-replicated, near real-time, scalabledata warehousing,」PVLDB, vol. 7, no. 12, pp. 1259–1270, 2014.

[6] http://clickhouse.yandex

[7] http://github.com/baidu/palo