這好像是個多余的問題，大部分大數(shù)據(jù)平臺都把集群透明化作為一個基本目標在努力實現(xiàn)。

所謂集群透明化，是指把一個多臺機器的集群模擬得像一個巨大的單機，只是系統(tǒng)管理層面知道體系是由很多單機集群而成，應用程序則應當盡量少地感受到集群的存在，在概念上可以把整個集群理解成一臺機器，甚至在代碼級都可能和單機運算兼容。

一

透明化主要有兩個方面。一方面是數(shù)據(jù)存儲，提供統(tǒng)一的集群文件系統(tǒng)或者數(shù)據(jù)庫系統(tǒng)，應用程序不需要關(guān)心數(shù)據(jù)具體存放在哪里了，系統(tǒng)將自動尋找合適的節(jié)點，并提供一定的冗余容錯機制;內(nèi)存的透明化相對要困難一些，有時需要應用程序知道集群的存在。另一方面是任務分配，系統(tǒng)負責將大任務拆分成小任務并分配給各個節(jié)點機去執(zhí)行，在有節(jié)點故障時能再將任務分配給其它節(jié)點;有時任務拆分比較困難，也需要程序員事先設計好拆分方案。

透明化顯然有好處，可以降低理解難度，開發(fā)程序時和單機情況差不多，也能提高代碼的兼容性。從這個意義上講，只要能透明化就都應當去做，除非是實現(xiàn)難度太大(比如上面提到內(nèi)存和任務拆分)的情況。

那么，為什么還要提出該不該透明化的問題呢?

二

因為，透明化難以獲得***的性能，而高性能對于大數(shù)據(jù)計算又是一個關(guān)鍵的目標。

高性能計算方案因運算目標和數(shù)據(jù)特征而異，并沒有普適的優(yōu)化方法。好算法需要特定的數(shù)據(jù)分布及任務分配方案，而使用系統(tǒng)自動的機制就很可能無法實現(xiàn)了。有些優(yōu)化手段還是互相矛盾的，如果不做透明化則可以根據(jù)場景選用哪種。而實現(xiàn)透明化時，為了保證在任何情況都能正常工作，經(jīng)常只能選擇較保險的方案，常常這并不是性能***的方案。

比如在做JOIN運算時，我們可以從業(yè)務上區(qū)分維表和事實表，也事先知道維表的容量，如果維表數(shù)據(jù)量較小，則可以將維表主動存儲到所有節(jié)點中甚至讀入內(nèi)存，而只把事實表分段存儲到節(jié)點中，并按此分布設計更優(yōu)的算法能。而透明化方案不能做這些假定，要處理一般情況，就不能區(qū)分維表和事實表，也不能假定維表足夠小。有些計算平臺能夠臨時測定數(shù)據(jù)特征以采用更優(yōu)的計算 方案，針對JOIN這種被研究得很透的運算有可能做到，但更復雜的情況就不一定了。

另外，透明化體系一般都會有一個較復雜的框架來控制數(shù)據(jù)分布及實現(xiàn)任務調(diào)度，這個事并不簡單，本身也會消耗很多資源，而如果不搞透明化或透明化程度較弱時，則可以把這些資源本用到計算上。比如容錯機制，節(jié)點機可能有故障，集群體系要能在故障機數(shù)量不多時保證計算仍然可以進行下去，這需要重新設計數(shù)據(jù)的冗余方案，要求高時還要及時保存中間結(jié)果。

三

一定程度地犧牲透明化，可以換來更高的性能。數(shù)據(jù)存儲可以直接使用節(jié)點機的文件系統(tǒng)，程序員可以根據(jù)運算的特征以及節(jié)點的能力來決定數(shù)據(jù)的分布以及冗余方案，對應用層并不提供一個統(tǒng)一的網(wǎng)絡文件系統(tǒng)。任務分配也由程序員自行處理，也是根據(jù)運算特殊及數(shù)據(jù)分布以及節(jié)點能力來安排任務，養(yǎng)活框架消耗，將盡量多的資源都用到計算任務本身上。

當然，犧牲透明化會帶來程序的開發(fā)復雜度提高，與單機情況的兼容性變差，這也是需要權(quán)衡的問題。透明化與否，并不是非黑即白的選擇。完全透明化，可能得不到***的性能;徹底不透明，又會導致開發(fā)成本又過高。具體要透明到什么程度，根據(jù)實際場來選擇。

一般來講，規(guī)模較大的集群要做好透明化，小規(guī)模集群則可以實施個性化管理。

大集群的節(jié)點多，如果不采用透明化方案，每個節(jié)點都個性化管理，那復雜度會提升太多，雖然可能獲得一些性能提升，但帶來的麻煩度很可能更高。而小集群則實施每個節(jié)點的個性化管理是管得過來的，節(jié)點存儲的數(shù)據(jù)各有不同。對于容錯，大集群在很短的時間段內(nèi)就可能發(fā)生故障節(jié)點，一定要有較強的自動容錯能力，這時花在框架上的開銷是必須的;而小集群則沒有這個問題，幾個節(jié)點的集群保證連續(xù)正常工作許多天并不是個小概率事件，就沒必要在框架上消耗太多資源。