隨著大規(guī)模互聯(lián)網(wǎng)應(yīng)用的廣泛出現(xiàn)，分布式數(shù)據(jù)庫(kù)成為近兩年的一個(gè)熱門(mén)話題。同樣，在銀行業(yè)主推X86限制主機(jī)與小型機(jī)的背景下，傳統(tǒng)的單機(jī)數(shù)據(jù)庫(kù)逐漸出現(xiàn)了一些瓶頸，馬上會(huì)面臨是否引入分布式數(shù)據(jù)庫(kù)的問(wèn)題。

近期，我在個(gè)人公眾號(hào)就“銀行引入分布式數(shù)據(jù)庫(kù)的必要性”做過(guò)一些展望，并收到了一些朋友的反饋，除了對(duì)分布式數(shù)據(jù)庫(kù)具體技術(shù)探討外，還有一類(lèi)很有趣的建議，“能不能也講講Teradata、Greenplum這類(lèi)MPP，這些也是分布式數(shù)據(jù)庫(kù)，但老板總是認(rèn)為OLTP場(chǎng)景下的才算數(shù)”。

的確，為了解決OLAP場(chǎng)景需求，其實(shí)很早就出現(xiàn)了分布式架構(gòu)的產(chǎn)品和解決方案，其與目前的OLTP方案有很多共通的地方。而且我相信，今后OLAP和OLTP兩個(gè)分支技術(shù)的發(fā)展也必然是交錯(cuò)前行，可以相互借鑒的。

鑒于此，本文會(huì)將OLAP類(lèi)場(chǎng)景的分布式數(shù)據(jù)也納入進(jìn)來(lái)，從兩個(gè)維度對(duì)“分布式數(shù)據(jù)庫(kù)”進(jìn)行拆解，第一部分會(huì)橫向談?wù)劜煌?ldquo;分布式數(shù)據(jù)庫(kù)”，把它們分為五類(lèi)并對(duì)其中OLAP場(chǎng)景的三類(lèi)做概要分析；第二部分結(jié)合NoSQL與NewSQL的差異，縱向來(lái)談?wù)凮LTP場(chǎng)景“分布式數(shù)據(jù)庫(kù)”實(shí)現(xiàn)方案的關(guān)鍵技術(shù)要點(diǎn)，是前文的延伸，也是分布式數(shù)據(jù)庫(kù)專(zhuān)題文章的一個(gè)總綱，其中的要點(diǎn)也都會(huì)單獨(dú)撰文闡述。

首先，我們從橫向談?wù)劜煌?ldquo;分布式數(shù)據(jù)庫(kù)”：

一、萬(wàn)法同宗RDBMS

1990年代開(kāi)始，關(guān)系型數(shù)據(jù)庫(kù)（RDBMS）成為主流，典型的產(chǎn)品包括Sybase、Oracle、DB2等，同期大約也是國(guó)內(nèi)IT產(chǎn)業(yè)的起步階段。RDBMS的基本特征已有學(xué)術(shù)上的定義，這里不再贅述。

但從實(shí)際應(yīng)用的角度看，我認(rèn)為有兩點(diǎn)最受關(guān)注：

• 內(nèi)部以關(guān)系模型存儲(chǔ)數(shù)據(jù)，對(duì)外支持ANSI SQL接口；
• 支持事務(wù)管理ACID特性，尤其是強(qiáng)一致性（指事務(wù)內(nèi)的修改要么全部失敗要么全部成功，不會(huì)出現(xiàn)中間狀態(tài)）。

而后出現(xiàn)的各種“分布式數(shù)據(jù)庫(kù)”，大多都是在這兩點(diǎn)上做權(quán)衡以交換其他方面的能力。

“數(shù)據(jù)庫(kù)”雖然有經(jīng)典定義，但很多大數(shù)據(jù)產(chǎn)品或許是為了標(biāo)榜對(duì)傳統(tǒng)數(shù)據(jù)庫(kù)部分功能的替代作用，也借用了“數(shù)據(jù)庫(kù)”的名號(hào)，導(dǎo)致在實(shí)踐中這個(gè)概念被不斷放大，邊界越來(lái)越模糊。本文一個(gè)目標(biāo)是要厘清這些產(chǎn)品與經(jīng)典數(shù)據(jù)庫(kù)的差異與傳承，所以不妨先弱化“數(shù)據(jù)庫(kù)”，將其放大為“數(shù)據(jù)存儲(chǔ)”。

那么怎樣才算是“分布式數(shù)據(jù)存儲(chǔ)”系統(tǒng)？

“分布式”是一種架構(gòu)風(fēng)格，用其實(shí)現(xiàn)“數(shù)據(jù)存儲(chǔ)”，最現(xiàn)實(shí)的目的是為了打開(kāi)數(shù)據(jù)庫(kù)產(chǎn)品的性能天花板，并保證系統(tǒng)的高可靠，進(jìn)一步展開(kāi)，“分布式數(shù)據(jù)庫(kù)”的必要條件有兩點(diǎn)：

• 支持水平擴(kuò)展，保證高性能

通過(guò)增加機(jī)器節(jié)點(diǎn)的方式提升系統(tǒng)整體處理能力，擺脫對(duì)專(zhuān)用設(shè)備的依賴(lài)，并且突破專(zhuān)用設(shè)備方案的性能上限。這里的機(jī)器節(jié)點(diǎn)，通常是要支持X86服務(wù)器。

• 廉價(jià)設(shè)備+軟件，保證高可靠

在單機(jī)可靠性較低的前提下，依靠軟件保證系統(tǒng)整體的高可靠，又可以細(xì)分為“數(shù)據(jù)存儲(chǔ)的高可靠”和“服務(wù)的高可靠”。總之，任何單點(diǎn)的故障，可能會(huì)帶來(lái)短時(shí)間、局部的服務(wù)水平下降，但不會(huì)影響系統(tǒng)整體的正常運(yùn)轉(zhuǎn)。

將這兩點(diǎn)作為“分布式數(shù)據(jù)庫(kù)”的必要條件，我大致歸納了一下，至少有五種不同的“分布式數(shù)據(jù)庫(kù)”：

• NoSQL 
• NewSQL
• MPP
• Hadoop技術(shù)生態(tài)
• Like-Mesa

注：也許有些同學(xué)會(huì)提到Kafka、Zookeeper等，這些雖然也是分布式數(shù)據(jù)存儲(chǔ)，但因?yàn)榫哂絮r明的特點(diǎn)和適用場(chǎng)景，無(wú)需再納入“數(shù)據(jù)庫(kù)”概念進(jìn)行探討。

這五類(lèi)中，前兩類(lèi)以支持OLTP場(chǎng)景為主，后三類(lèi)則以O(shè)LAP場(chǎng)景為主。我將按照時(shí)間線，主要對(duì)OLAP場(chǎng)景下的三類(lèi)進(jìn)行概要分析。

二、OLAP場(chǎng)景下的分布式數(shù)據(jù)庫(kù)

1990-2000年代，隨著應(yīng)用系統(tǒng)廣泛建設(shè)與深入使用，數(shù)據(jù)規(guī)模越來(lái)越大，國(guó)內(nèi)銀行業(yè)的“全國(guó)大集中”基本都是在這個(gè)階段完成。這期間，RDBMS得到了廣泛運(yùn)用，Oracle也擊敗Sybase成為數(shù)據(jù)庫(kù)領(lǐng)域的王者。

在滿足了基本的交易場(chǎng)景后，數(shù)據(jù)得到了累積，進(jìn)一步的分析性需求自然就涌現(xiàn)了出來(lái)。單一數(shù)據(jù)庫(kù)內(nèi)同時(shí)支持聯(lián)機(jī)交易和分析需求存在很多問(wèn)題，往往會(huì)造成對(duì)聯(lián)機(jī)交易的干擾，因此需要新的解決方案。這就為MPP崛起提供了機(jī)會(huì)。

1、MPP

MPP（Massively Parallel Processing）是指多個(gè)處理器（或獨(dú)立的計(jì)算機(jī)）并行處理一組協(xié)同計(jì)算[1]。

為了保證各節(jié)點(diǎn)的獨(dú)立計(jì)算能力，MPP數(shù)據(jù)庫(kù)通常采用ShareNothing架構(gòu)，最為典型的產(chǎn)品是Teradata（簡(jiǎn)稱(chēng)TD），后來(lái)也出現(xiàn)Greenplum（簡(jiǎn)稱(chēng)GPDB）、Vertica、Netezza等競(jìng)爭(zhēng)者。

架構(gòu)特點(diǎn)：

MPP是多機(jī)可水平擴(kuò)展的架構(gòu)，符合“分布式”的基本要求，其中TD采用外置集中存儲(chǔ)而GPDB直接使用本地磁盤(pán)，從這點(diǎn)來(lái)說(shuō)GPDB是更徹底的Share Nothing架構(gòu)。

考慮到TD商業(yè)策略上采用一體機(jī)方案，不具有開(kāi)放性，而GPDB具有較高的開(kāi)源程度，下文中通過(guò)分析后者架構(gòu)特點(diǎn)來(lái)分析MPP工作機(jī)制。

GPDB屬于主從架構(gòu)[2]，Slave稱(chēng)為Segment是主要的數(shù)據(jù)加工節(jié)點(diǎn)，是在PostgreSQL基礎(chǔ)上的封裝和修改，天然具備事務(wù)處理的能力，可進(jìn)行水平擴(kuò)展；集群內(nèi)有唯一Active狀態(tài)的Master節(jié)點(diǎn)，除了元數(shù)據(jù)存儲(chǔ)和調(diào)度功能外，同時(shí)承擔(dān)一定的工作負(fù)載，即所有外部對(duì)集群的數(shù)據(jù)聯(lián)機(jī)訪問(wèn)都要經(jīng)過(guò)Master節(jié)點(diǎn)。

在高可靠設(shè)計(jì)方面，首先設(shè)置了Standby Master節(jié)點(diǎn)，在Master節(jié)點(diǎn)宕機(jī)時(shí)接管其任務(wù)，其次將Segment節(jié)點(diǎn)則細(xì)分為兩類(lèi)不同角色Primary和Mirror，后者是前者的備節(jié)點(diǎn)，數(shù)據(jù)提交時(shí)在兩者間進(jìn)行強(qiáng)同步，以此保證Primary宕機(jī)時(shí)，Mirror可以被調(diào)度起來(lái)接替前者的任務(wù)。

數(shù)據(jù)分析性需求對(duì)IT能力的要求包括：

• 復(fù)雜查詢(xún)能力；
• 批量數(shù)據(jù)處理；
• 一定的并發(fā)訪問(wèn)能力。

MPP較好的實(shí)現(xiàn)了對(duì)上述能力的支撐，在前大數(shù)據(jù)時(shí)代得到了廣泛的應(yīng)用，但這個(gè)時(shí)期的數(shù)據(jù)總量相對(duì)仍然有限，普遍在TB級(jí)別，對(duì)應(yīng)的集群規(guī)模也通常在單集群百節(jié)點(diǎn)以下。

隨著數(shù)據(jù)價(jià)值關(guān)注度的不斷提升，越來(lái)越多的數(shù)據(jù)被納入企業(yè)分析范圍；同時(shí)實(shí)際應(yīng)用中考慮到數(shù)據(jù)存儲(chǔ)和傳輸成本，往往傾向于將數(shù)據(jù)集中在一個(gè)或少數(shù)幾個(gè)集群中，這樣推動(dòng)了集群規(guī)模的快速增長(zhǎng)。

在大規(guī)模集群（幾百至上千）的使用上，MPP從批處理和聯(lián)機(jī)訪問(wèn)兩個(gè)方面都顯現(xiàn)了一些不足。以下內(nèi)容主要借鑒了Pivotal（GPDB原廠）的一篇官方博客[3]。

注：有位同學(xué)給出的譯文也具有較好的質(zhì)量，推薦閱讀[4]。

缺陷：

• 批處理

MPP架構(gòu)下，工作負(fù)載節(jié)點(diǎn)（對(duì)GPDB而言是Segment節(jié)點(diǎn)）是完全對(duì)稱(chēng)的，數(shù)據(jù)均勻的存儲(chǔ)在這些節(jié)點(diǎn)，處理過(guò)程中每個(gè)節(jié)點(diǎn)（即該節(jié)點(diǎn)上的Executor）使用本地的CPU、內(nèi)存和磁盤(pán)等資源完成本地的數(shù)據(jù)加工。這個(gè)架構(gòu)雖然提供了較好的擴(kuò)展性，但隱藏了極大的問(wèn)題——Straggler，即當(dāng)某個(gè)節(jié)點(diǎn)出現(xiàn)問(wèn)題導(dǎo)致速度比其他節(jié)點(diǎn)慢時(shí)，該節(jié)點(diǎn)會(huì)成為Straggler。

此時(shí)，無(wú)論集群規(guī)模多大，批處理的整體執(zhí)行速度都由Straggler決定，其他節(jié)點(diǎn)上的任務(wù)執(zhí)行完畢后則進(jìn)入空閑狀態(tài)等待Straggler，而無(wú)法分擔(dān)其工作。導(dǎo)致節(jié)點(diǎn)處理速度降低的原因多數(shù)是磁盤(pán)等硬件損壞，考慮到磁盤(pán)本身的一定故障率（根據(jù)Google統(tǒng)計(jì)前三個(gè)月內(nèi)2%損壞率，第二年時(shí)達(dá)到8%）當(dāng)集群規(guī)模達(dá)到一定程度時(shí)，故障會(huì)頻繁出現(xiàn)使straggler成為一個(gè)常規(guī)問(wèn)題。

• 并發(fā)

由于MPP的“完全對(duì)稱(chēng)性”，即當(dāng)查詢(xún)開(kāi)始執(zhí)行時(shí)，每個(gè)節(jié)點(diǎn)都在并行的執(zhí)行完全相同的任務(wù)，這意味著MPP支持的并發(fā)數(shù)和集群的節(jié)點(diǎn)數(shù)完全無(wú)關(guān)。根據(jù)該文中的測(cè)試數(shù)據(jù)，4個(gè)節(jié)點(diǎn)的集群和400個(gè)節(jié)點(diǎn)的集群支持的并發(fā)查詢(xún)數(shù)是相同的，隨著并發(fā)數(shù)增加，這二者幾乎在相同的時(shí)點(diǎn)出現(xiàn)性能驟降。

傳統(tǒng)MPP的聯(lián)機(jī)查詢(xún)主要面向企業(yè)管理層的少數(shù)用戶，對(duì)并發(fā)能力的要求較低。而在大數(shù)據(jù)時(shí)代，數(shù)據(jù)的使用者從戰(zhàn)略管理層轉(zhuǎn)向戰(zhàn)術(shù)執(zhí)行層乃至一線人員，從孤立的分析場(chǎng)景轉(zhuǎn)向與業(yè)務(wù)交易場(chǎng)景的融合。對(duì)于聯(lián)機(jī)查詢(xún)的并發(fā)能力已經(jīng)遠(yuǎn)超MPP時(shí)代，成為OLAP場(chǎng)景分布式數(shù)據(jù)庫(kù)要考慮的一個(gè)重要問(wèn)題。

除上述兩點(diǎn)以外，GPDB架構(gòu)中的Master節(jié)點(diǎn)承擔(dān)了一定的工作負(fù)載，所有聯(lián)機(jī)查詢(xún)的數(shù)據(jù)流都要經(jīng)過(guò)該節(jié)點(diǎn)，這樣Master也存在一定的性能瓶頸。同時(shí)，在實(shí)踐中GPDB對(duì)數(shù)據(jù)庫(kù)連接數(shù)量的管理也是非常謹(jǐn)慎的。在我曾參與的項(xiàng)目中，Pivotal專(zhuān)家給出了一個(gè)建議的最大值且不會(huì)隨著集群規(guī)模擴(kuò)大而增大。

綜上，大致可以得出結(jié)論，MPP（至少是GPDB）在集群規(guī)模上是存在一定限制的。

2000-2010年代，大多數(shù)股份制以上銀行和少部分城商行都建立了數(shù)據(jù)倉(cāng)庫(kù)或ODS系統(tǒng)，主要采用了MPP產(chǎn)品?？梢哉f(shuō)，這十余年是MPP產(chǎn)品最輝煌的時(shí)代。到目前為止，MPP仍然是銀行業(yè)建設(shè)數(shù)據(jù)倉(cāng)庫(kù)和數(shù)據(jù)集市類(lèi)系統(tǒng)的主要技術(shù)選擇。為了規(guī)避MPP并發(fā)訪問(wèn)上的缺陷以及批量任務(wù)對(duì)聯(lián)機(jī)查詢(xún)的影響，通常會(huì)將數(shù)據(jù)按照應(yīng)用粒度拆分到不同的單體OLTP數(shù)據(jù)庫(kù)中以支持聯(lián)機(jī)查詢(xún)。

2、Hadoop生態(tài)體系

MPP在相當(dāng)長(zhǎng)的一段時(shí)期內(nèi)等同于一體機(jī)方案（以TD為代表），其價(jià)格高昂到普通企業(yè)無(wú)法承受，多數(shù)在銀行、電信等行業(yè)的頭部企業(yè)中使用。2010年代，隨著大數(shù)據(jù)時(shí)代的開(kāi)啟，Hadoop生態(tài)體系以開(kāi)源優(yōu)勢(shì)，獲得了蓬勃發(fā)展和快速普及。

Hadoop技術(shù)體系大大降低了數(shù)據(jù)分析類(lèi)系統(tǒng)的建設(shè)成本，數(shù)據(jù)分析挖掘等工作由此步入“數(shù)據(jù)民主化”時(shí)代。在Hadoop生態(tài)體系中，分析需求所需要的能力被拆分為批量加工和聯(lián)機(jī)訪問(wèn)，通過(guò)不同的組件搭配實(shí)現(xiàn)。批量加工以MapReduce、Tez、Spark等為執(zhí)行引擎，為了獲得友好的語(yǔ)義支持，又增加了Hive、SparkSQL等組件提供SQL訪問(wèn)接口。

聯(lián)機(jī)訪問(wèn)部分，則從早期Hive過(guò)渡到Impala、Hawk以及Kylin、Presto等方案逐漸降低了訪問(wèn)延時(shí)。

架構(gòu)特點(diǎn)：

Hadoop生態(tài)體系下HDFS、Spark、Hive等組件已經(jīng)有很多文章介紹，本文不再贅述?？偟膩?lái)說(shuō)，其架構(gòu)的著力點(diǎn)在于數(shù)據(jù)高吞吐處理能力，在事務(wù)方面相較MPP更簡(jiǎn)化，僅提供粗粒度的事務(wù)管理。

缺陷：

Hadoop也有其明顯的缺陷，主要是三點(diǎn)：

• 批量加工效率較低

MPP的擁護(hù)者往往會(huì)詬病Hadoop計(jì)算引擎執(zhí)行效率低。的確，在同等規(guī)模的集群執(zhí)行相同的數(shù)據(jù)加工邏輯，即使與Spark對(duì)比，MPP所耗費(fèi)的時(shí)間也會(huì)明顯更少些[3]，其主要的原因在于兩者對(duì)于數(shù)據(jù)在磁盤(pán)和內(nèi)存中的組織形式不同。

MPP從RDBMS而來(lái)（例如Vertica和GPDB都是基于PostgreSQL開(kāi)發(fā)），對(duì)數(shù)據(jù)的組織形式更貼近傳統(tǒng)方式，按區(qū)、段、塊等單位組織，對(duì)數(shù)據(jù)進(jìn)行了預(yù)處理工作以提升使用時(shí)的效率；Hadoop生態(tài)體系以HDFS文件存儲(chǔ)為基礎(chǔ)，HDFS并不像傳統(tǒng)數(shù)據(jù)庫(kù)那樣獨(dú)立管理一塊連續(xù)的磁盤(pán)空間，而是將數(shù)據(jù)表直接映射成不同的數(shù)據(jù)文件，甚至表分區(qū)也以目錄、文件等方式體現(xiàn)。

HDFS最簡(jiǎn)單的txt格式干脆就是平鋪的數(shù)據(jù)文件，處理過(guò)程難免要簡(jiǎn)單粗暴一些，但隨著Avro、ORCFile、Parquet等很多新的存儲(chǔ)格式相繼被引入，基于HDFS的批處理也更加精細(xì)。從整體架構(gòu)來(lái)看，Hadoop更加看重大數(shù)據(jù)量批量處理的吞吐能力。

同時(shí)，Hadoop具備MPP所缺失的批量任務(wù)調(diào)整能力，數(shù)據(jù)的多副本存儲(chǔ)使其具有更多“本地化”數(shù)據(jù)加工的備選節(jié)點(diǎn)，而且數(shù)據(jù)加工處理與數(shù)據(jù)存儲(chǔ)并不綁定，可以根據(jù)節(jié)點(diǎn)的運(yùn)行效率動(dòng)態(tài)調(diào)整任務(wù)分布，從而在大規(guī)模部署的情況下具有整體上更穩(wěn)定的效率。相比之下，MPP在相對(duì)較小的數(shù)據(jù)量下具有更好的執(zhí)行效率。

• 不能無(wú)縫銜接EDW實(shí)施方法論

在長(zhǎng)期的實(shí)踐中，企業(yè)級(jí)市場(chǎng)的主流集成商針對(duì)EDW項(xiàng)目沉淀了一套固定的實(shí)施方法，與MPP特性相匹配，但Hadoop并不能與之無(wú)縫對(duì)接。一個(gè)最典型的例子是歷史數(shù)據(jù)的存儲(chǔ)，傳統(tǒng)方法是采用“拉鏈表”的形式，即對(duì)于當(dāng)前有效的數(shù)據(jù)會(huì)記錄其生效的起始時(shí)間，在數(shù)據(jù)被更改或刪除后，在該行記錄的另外一列記錄失效時(shí)間。這樣，當(dāng)前數(shù)據(jù)即變更為歷史數(shù)據(jù)，通過(guò)這種增量的表述方式，節(jié)省了大量的存儲(chǔ)空間和磁盤(pán)IO。

可以看出，拉鏈表的設(shè)計(jì)思想其實(shí)與基于時(shí)間戳的MVCC機(jī)制是相同的。

HDFS作為Hadoop的存儲(chǔ)基礎(chǔ)，其本身不提供Update操作，這樣所有在數(shù)據(jù)操作層面的Update最終會(huì)被轉(zhuǎn)換為文件層面的Delete和Insert操作，效率上顯著降低。據(jù)我所知，在很多企業(yè)實(shí)踐中會(huì)將這種增量存儲(chǔ)轉(zhuǎn)換為全量存儲(chǔ)，帶來(lái)大量數(shù)據(jù)冗余的同時(shí)，也造成實(shí)施方法上的變更。

• 聯(lián)機(jī)查詢(xún)并發(fā)能力不足

對(duì)于聯(lián)機(jī)查詢(xún)場(chǎng)景，最常見(jiàn)的是SQL on Hadoop方案，將Impala、HAWQ等MPP引擎架設(shè)在HDFS基礎(chǔ)上，批量數(shù)據(jù)與聯(lián)機(jī)查詢(xún)共用一份數(shù)據(jù)。MPP引擎借鑒了MPP數(shù)據(jù)庫(kù)的設(shè)計(jì)經(jīng)驗(yàn)，相對(duì)Hive等組件提供了更低的延遲。但存在一個(gè)與MPP相同的問(wèn)題，即并發(fā)能力不足。

通過(guò)一些項(xiàng)目測(cè)試中，我發(fā)現(xiàn)在大體相同的數(shù)據(jù)量和查詢(xún)邏輯情況下， Impala并發(fā)會(huì)低于GPDB。其原因可能是多方面的，不排除存在一些調(diào)優(yōu)空間，但在系統(tǒng)架構(gòu)層面也有值得探討的內(nèi)容。例如在元數(shù)據(jù)讀取上，Impala復(fù)用了Hive MetaStore，但后者提供的訪問(wèn)服務(wù)延時(shí)相對(duì)較長(zhǎng)，這也限制了Impala的并發(fā)能力[7]。

3、Like-Mesa

Mesa是Google開(kāi)發(fā)的近實(shí)時(shí)分析型數(shù)據(jù)倉(cāng)庫(kù)，2014年發(fā)布了論文披露其設(shè)計(jì)思想[5]，其通過(guò)預(yù)聚合合并Delta文件等方式減少查詢(xún)的計(jì)算量，提升了并發(fā)能力。

Mesa充分利用了現(xiàn)有的Google技術(shù)組件，使用BigTable來(lái)存儲(chǔ)所有持久化的元數(shù)據(jù)，使用了Colossus (Google的分布式文件系統(tǒng))來(lái)存儲(chǔ)數(shù)據(jù)文件，使用MapReduce來(lái)處理連續(xù)的數(shù)據(jù)。

Mesa相關(guān)的開(kāi)源產(chǎn)品為Clickhouse[6]（2016年Yandex開(kāi)源）和Palo[7]（2017年百度開(kāi)源）。

特點(diǎn)：

目前ClickHouse的資料仍以俄語(yǔ)社區(qū)為主，為便于大家理解和進(jìn)一步研究，下面主要以Palo為例進(jìn)行說(shuō)明。

Palo沒(méi)有完全照搬Mesa的架構(gòu)設(shè)計(jì)的思路，其借助了Hadoop的批量處理能力，但將加工結(jié)果導(dǎo)入到了Palo自身存儲(chǔ)，專(zhuān)注于聯(lián)機(jī)查詢(xún)場(chǎng)景，在聯(lián)機(jī)查詢(xún)部分主要借鑒了Impala技術(shù)。同時(shí)Palo沒(méi)有復(fù)用已有的分布式文件系統(tǒng)和類(lèi)BigTable系統(tǒng)，而是設(shè)計(jì)了獨(dú)立的分布式存儲(chǔ)引擎。雖然數(shù)據(jù)存儲(chǔ)上付出了一定的冗余，但在聯(lián)機(jī)查詢(xún)的低延遲、高并發(fā)兩方面都得到了很大的改善。

Palo在事務(wù)管理上與Hadoop體系類(lèi)似，數(shù)據(jù)更新的原子粒度最小為一個(gè)數(shù)據(jù)加載批次，可以保證多表數(shù)據(jù)更新的一致性。

整體架構(gòu)由Frontend和Backend兩部分組成，查詢(xún)編譯、查詢(xún)執(zhí)行協(xié)調(diào)器和存儲(chǔ)引擎目錄管理被集成到Frontend；查詢(xún)執(zhí)行器和數(shù)據(jù)存儲(chǔ)被集成到Backend。Frontend負(fù)載較輕，通常配置下，幾個(gè)節(jié)點(diǎn)即可滿足要求；而B(niǎo)ackend作為工作負(fù)載節(jié)點(diǎn)會(huì)大幅擴(kuò)展到幾十至上百節(jié)點(diǎn)。數(shù)據(jù)處理部分與Mesa相同采用了物化Rollup（上卷表）的方式實(shí)現(xiàn)預(yù)計(jì)算。

Palo和ClickHouse都宣稱(chēng)實(shí)現(xiàn)了MPP Data Warehouse，但從架構(gòu)上看已經(jīng)與傳統(tǒng)的MPP發(fā)生很大的變化，幾乎完全舍棄了批量處理，專(zhuān)注于聯(lián)機(jī)部分。

ClickHouse和Palo作為較晚出現(xiàn)的開(kāi)源項(xiàng)目，還在進(jìn)一步發(fā)展過(guò)程中，設(shè)定的使用場(chǎng)景以廣告業(yè)務(wù)時(shí)序數(shù)據(jù)分析為主，存在一定局限性，但值得持續(xù)關(guān)注。

以上是我對(duì)OLAP場(chǎng)景“分布式數(shù)據(jù)庫(kù)”橫向的概要分析，我們兩個(gè)拆解維度中的第一部分，對(duì)不同的“分布式數(shù)據(jù)庫(kù)”的橫向探討至此就告一段落了，其中還有很多有趣的話題，我們可以留待后續(xù)文章繼續(xù)討論。

至于第二部分——對(duì)“分布式數(shù)據(jù)庫(kù)”的縱向探討，我將結(jié)合NoSQL與NewSQL的差異，縱向來(lái)談?wù)凮LTP場(chǎng)景“分布式數(shù)據(jù)庫(kù)”實(shí)現(xiàn)方案的關(guān)鍵技術(shù)要點(diǎn)。感興趣的同學(xué)敬請(qǐng)繼續(xù)關(guān)注DBAplus社群后續(xù)文章的發(fā)布。

文獻(xiàn)參考：

[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] 對(duì)比MPP計(jì)算框架和批處理計(jì)算框架，

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