2.分布式架構(gòu)應(yīng)用現(xiàn)狀

　　當(dāng)前主流的分布式應(yīng)用有兩種：分布式數(shù)據(jù)庫和Hadoop分布式系統(tǒng)。兩種解決方案對(duì)比如表1所示。

　　表1. 分布式數(shù)據(jù)庫和Hadoop分布式系統(tǒng)的對(duì)比

　　MPP分布式數(shù)據(jù)庫較Hadoop分布式系統(tǒng)，在復(fù)雜邏輯的結(jié)構(gòu)化數(shù)據(jù)處理上具有一定的優(yōu)勢(shì)，且可基于SQL開發(fā)，對(duì)于有較豐富SQL經(jīng)驗(yàn)的系統(tǒng)開發(fā)者，開發(fā)與運(yùn)維更容易。當(dāng)然，業(yè)界MPP分布式數(shù)據(jù)庫產(chǎn)品價(jià)格也要高于Hadoop這個(gè)源于開源社區(qū)的產(chǎn)品。

　　這是否意味著MPP分布式數(shù)據(jù)庫就是大數(shù)據(jù)處理的最佳解決方案呢？我們以銀行系統(tǒng)數(shù)據(jù)的價(jià)值密度和數(shù)據(jù)特征為例來考慮這個(gè)問題。對(duì)于銀行系統(tǒng)數(shù)據(jù)，我們基本可以達(dá)成這樣一個(gè)共識(shí)：銀行系統(tǒng)數(shù)據(jù)中，結(jié)構(gòu)化數(shù)據(jù)價(jià)值密度通常高于非結(jié)構(gòu)化或半結(jié)構(gòu)化數(shù)據(jù)，而在銀行數(shù)據(jù)中非結(jié)構(gòu)化數(shù)據(jù)占用了大量的存儲(chǔ)資源。這是因?yàn)殂y行系統(tǒng)中結(jié)構(gòu)化數(shù)據(jù)以賬務(wù)數(shù)據(jù)為主，而非結(jié)構(gòu)化數(shù)據(jù)則主要集中在憑證影像等數(shù)據(jù)。當(dāng)然結(jié)構(gòu)化數(shù)據(jù)中也包括部分日志信息等價(jià)值密度不高的數(shù)據(jù)。

　　數(shù)據(jù)存儲(chǔ)與處理技術(shù)在由"一種架構(gòu)支持所有應(yīng)用"向"多種架構(gòu)支持多類應(yīng)用"轉(zhuǎn)變。同樣對(duì)于數(shù)據(jù)消費(fèi)層數(shù)據(jù)處理技術(shù)，也應(yīng)根據(jù)數(shù)據(jù)價(jià)值密度及數(shù)據(jù)特征等因素采用與之相匹配的架構(gòu)來支持。對(duì)于數(shù)據(jù)消費(fèi)層數(shù)據(jù)中那些價(jià)值密度高的交易及賬務(wù)數(shù)據(jù)可采用MPP分布式數(shù)據(jù)庫構(gòu)建數(shù)據(jù)處理平臺(tái)，而對(duì)于那些價(jià)值密度不高的結(jié)構(gòu)化數(shù)據(jù)和非（半）結(jié)構(gòu)化數(shù)據(jù)則可以采用Hadoop分布式系統(tǒng)作為處理平臺(tái)。

　　3.分布式局限性：CAP理論

　　如圖2所示，CAP原理中有三個(gè)要素：一致性（Consistency），可用性（Availability）和分區(qū)容忍性（Partition tolerance）

　　圖2.CAP原理示意圖

　　CAP原理指的是在分布式系統(tǒng)中這三個(gè)要素最多只能同時(shí)實(shí)現(xiàn)兩點(diǎn)，不可能三者兼顧。因此在進(jìn)行分布式架構(gòu)設(shè)計(jì)時(shí)，必須做出取舍。而對(duì)于分布式數(shù)據(jù)系統(tǒng)，分區(qū)容忍性是基本要求，否則就失去了價(jià)值。因此設(shè)計(jì)分布式數(shù)據(jù)系統(tǒng)，就是在一致性和可用性之間取一個(gè)平衡。對(duì)于大多數(shù)Web應(yīng)用，其實(shí)并不需要強(qiáng)一致性， 因此犧牲一致性而換取高可用性，是目前多數(shù)分布式數(shù)據(jù)庫產(chǎn)品的方向。

　　從客戶端角度，多進(jìn)程并發(fā)訪問時(shí)，更新過的數(shù)據(jù)在不同進(jìn)程如何獲取的不同策略，決定了不同的一致性。對(duì)于關(guān)系型數(shù)據(jù)庫，要求更新過的數(shù)據(jù)能被后續(xù)的訪問都能看到，這是強(qiáng)一致性。如果能容忍后續(xù)的部分或者全部訪問不到，則是弱一致性。如果經(jīng)過一段時(shí)間后要求能訪問到更新后的數(shù)據(jù)，則是最終一致性。

　　但Web應(yīng)用也有例外，比如支付寶系統(tǒng)，就要求數(shù)據(jù)（銀行賬戶）的強(qiáng)一致性，而且面對(duì)大量淘寶用戶，可用性要求很高，因此只能犧牲數(shù)據(jù)的分區(qū)冗余。

　　對(duì)于MPP DB而言，雖說是宣稱Scale out（橫向擴(kuò)展），但是這種out一般到100，而Hadoop一般可以到1000+。在我們的測(cè)試中，也發(fā)現(xiàn)線性擴(kuò)展性一項(xiàng)即使是在較小的節(jié)點(diǎn)數(shù)方面，也并未達(dá)到絕對(duì)的直線的性能。

　　這是為什么呢？我們大致可以從CAP理論上來找到一些理由。因?yàn)镸PP DB始終還是DB，一定要考慮C（Consistency），其次考慮A（Availability），最后才在可能的情況下盡量做好P（Partition-tolerance）。而Hadoop就是為了并行處理和存儲(chǔ)設(shè)計(jì)的，所以優(yōu)先考慮的是P，然后是A，最后再考慮C。所以后者的可擴(kuò)展性當(dāng)然好于前者。