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

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

一

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

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

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

二

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

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

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

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

三

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

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

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

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