使用分布式集群來處理大數據是當前的主流，將一個大任務拆分成多個子任務分布到多個節點進行處理通常能獲得顯著的性能提升。因此，只要發現處理能力不足就可以通過增加節點的方式進行擴容，這也是很多擁躉者最樸素的想法。以至于當我們接觸一項新的大數據處理技術往往首先問的就是支不支持分布式以及能支持多大規模的集群，可見“分布式思維”已經根深蒂固。
那么分布式真是處理大數據的萬能藥嗎？
“萬能”當然不可能。沒有包治百病的靈藥，任何技術都有其適用場景，分布式也一樣。
能否使用分布式技術解決處理能力問題，要結合任務的特點來看。如果這個任務很容易拆分，就可以使用分布式；否則如果任務比較復雜，拆分后還要相互耦合引用甚至發生大量跨節點數據傳輸等情況就不一定適合使用分布式了，如果強行使用效果反而更差。
具體來說，大多數交易型（OLTP）場景都較為合適，單任務涉及數據量很小但并發很多，任務很容易拆分，適合使用分布式技術提升性能（雖然會面臨少量分布式事務，但目前已有成熟技術處理）。
對于分析型（OLAP）任務則要復雜一些。有些簡單查詢也適合分布式，比如帳戶明細查詢（中國近期流行的健康碼查詢就是此類）。這類查詢的總數據量巨大，但每個帳戶的數據量很少，而每個查詢任務也只要本帳戶的數據，并不涉及復雜計算，很類似上述OLTP場景中單任務涉及數據量小且相互無關的特點，因此很容易拆分，這時增加分布式節點就可以有效提升查詢效率。在這類場景下分布式也可以稱得上是靈藥了。
但對于復雜一些的計算場景就未必了。比如我們常見的關聯運算，在分布式環境下關聯運算會有的動作，要在節點之間交換數據，當節點數較多時數據交換造成的網絡延遲就會抵消多機分攤計算帶來的性能提升大規模圖數據的分布式處理，再增加節點性能不僅不會提升反而可能下降。很多分布式數據庫都會有節點數上限的指標，就是因為這個原因，而且這個上限還很低，通常也就幾十最多上百就達到了。
更重要的是，分布式集群算力也并不能線性擴展。集群由多個物理機組成，多機通過網絡進行通信。當集群中發生本機內存不足需要訪問其它節點的內存時就需要通過網絡，而網絡只適合批量訪問，但內存的使用常常是小量隨機式的。通過網絡進行跨節點內存訪問就會導致性能下降十分明顯，通常是一兩個數量級的。這就需要動用數倍甚至數十倍的硬件資源才能彌補性能的缺失。使用集群雖然能提升算力，但并不能線性地擴展，在有限的節點限制下能夠發揮的作用也十分有限。這時對于想要分布式發揮“無限算力”的小伙伴，分布式技術也只能遺憾了
我們實際業務中還有很多更復雜的計算場景，比如常見的跑批任務，就是每天空閑（如夜間）時間將業務數據加工成待用的結果，這類運算復雜度極高，不僅計算規則復雜并且有先后順序大規模圖數據的分布式處理，多步驟運算要按照順序逐次完成。處理時還會涉及大量歷史數據，可能要反復讀取并關聯，這會導致分布式技術應用困難。即使計算任務能夠拆分，在數據加工的過程中經常還會生成中間結果落地以便下一步繼續使用，這些臨時產生的中間結果由于無法及時分布到其他節點上（臨時產生的中間數據無法事先冗余），其他節點要計算就要借助網絡交換數據又會大幅降低性能。在這類復雜計算場景下，別說分布式節點限制，就是想利用分布式技術都不容易，靈藥就更談不上了。所以這類復雜業務常常還是使用大型單體數據庫實施，不僅成本高，容量隨著任務的增多也很容易達到上限。
那么，這種場景的計算性能碰到瓶頸，如果分布式不能解決，那又能怎么辦呢？
要解決問題，要先分析這類運算有什么特點，運算慢的原因到底在哪里。
其實，深入研究一下這類場景的特點就會發現，很多 “慢”運算涉及的數據量并不是很大。這類計算通常是基于以業務數據為核心的結構化數據進行的，數據總量雖然很大，但單次任務涉及的并不大，通常也就幾十到幾百GB，很少上TB的。比如一個典型的銀行跑批場景，假設有2000萬賬戶，每個賬戶每月一條匯總記錄，跑批通常會使用過去一年的歷史數據計算，總體算下來也不到3億行。假設每條記錄有100個統計值，每行按1K估算，物理大小也就300G左右，使用一些簡單技術也能壓縮到100G以內。這種數據規模單機通常就可以容納了。
數據量并不大，那為什么會跑這么慢呢？跑批要數小時的情況比比皆是。
主要原因有兩個。
一是計算復雜。數據量雖然不大，但計算過程中會反復關聯，計算量上來以后性能當然就變差了。我們舉個極端一點的例子，國家天文臺的天體聚類計算場景就是數據量不大但計算復雜度高導致性能低下的情況。該場景共有11 張照片（數據），每張有 500 萬天體，數據量總共不超過10G。現在要將位置（天文距離）鄰近的天體聚合成一個再計算屬性。這個任務的數據量雖然不大，但計算量非常大，和規模的平方成正比，天文距離的計算次數大約是500萬 *500萬 *10張=250萬億次，這真是個天文數字。這個任務用某分布式數據庫動用 100 個 CPU，僅處理 50 萬天體也需要 3.8 小時，處理 500 萬目標規模則需要 15 天（用戶期望是在數小時內處理完）。
二是單機計算性能沒有被充分發揮，換句話說就是硬件資源利用率低，這跟應用的數據處理技術密切相關。我們目前處理結構化數據還主要使用SQL（數據庫），這是無法發揮單機計算性能的重要原因。SQL由于缺乏一些關鍵的數據類型（如記錄類型）和基本運算（如有序計算）導致很多高性能算法都無法描述，結果只能使用慢算法。雖然現在很多數據庫在工程上有所優化，但也只能針對簡單的場景，情況復雜之后數據庫的優化器就會失效，解決不了根本問題。這也解釋了上面天文臺的例子使用SQL即使借助的集群計算時間仍然無法滿足需要的原因。
事實上，如果數據處理技術能夠根據實際計算場景因地制宜地使用適合的算法，就可以降低計算復雜度提升計算性能。這里的關鍵是，高性能算法不僅要能想出來，還要能寫出來。SQL就很難實現這個目標，即使能想出來也實現不了，最后只能干瞪眼。
除了SQL，像Spark這樣的新興計算技術也同樣存在性能差（資源利用率低）的問題。Spark中的 RDD 采用了機制，在每個計算步驟后都會復制出新的 RDD，造成內存和 CPU 的大量占用和浪費，資源利用率很低，想要達到性能要求就需要依靠大集群大內存。
因此，想要充分利用硬件資源提升計算效率就要再選用其他技術，這就要提到SPL了。
與SQL類似，SPL也是專門面向結構化數據的計算引擎。不同的是，SPL采用了更加開放的計算體系，內部提供了很多高性能算法實現機制（以及對應的高性能存儲），可以達到高效算法不僅能想出來還能實現的目標，甚至還很容易實現。這樣就可以將硬件資源發揮到極致，本來要用集群的運算也可以不用集群，大集群可以改用小集群。
還是拿上面天文臺的例子來說，如果一樣老老實實地對比250萬億次，SPL也沒法做到更快。但可以想辦法優化算法，具體到這個問題時，可以利用天體距離的單調性和有序性進行粗篩，用二分法迅速把可能匹配的天體定位到很小的范圍內，排除了絕大多數的比對計算；計算復雜度就可以減小到原來的1/500，再結合并行計算就可以有效提升計算效率。
前面我們說了，高性能算法不僅要能想出來，還要能實現。SPL實現這個優化后的算法要多少代碼呢？一共50行！效果怎么樣呢？500萬規模的全量數據使用16CPU可以在4小時內完成，整體相對SQL方案可以提速幾千倍。（具體案例細節可以參考： SPL 提速天體聚類任務 2000 倍）
細心的小伙伴可能發現了，在這個案例中要達到用戶要求的性能指標SPL使用的硬件資源很少，單機就可以滿足，并不需要分布式。這就是我們主張的：先把單機性能發揮到極致，不夠用再分布式。
SPL還實施過很多這樣單機頂級群的案例，比如在某商業銀行的手機銀行多并發賬戶查詢場景中，SPL使用單臺服務器就達到了原來6臺集群的查詢效率，同時解決了實時關聯的問題（案例詳情： 開源 SPL 將銀行手機賬戶查詢的預先關聯變成實時關聯）。還有在電商漏斗計算場景中，SPL使用8CPU可以跑出29秒的結果，而同樣的計算在 的 級服務器（4節點集群）上三分鐘未跑出結果（細節參考： SQL 提速：漏斗轉化分析）。
除了實現單機頂級群的效果外，對于原本在單體數據庫上跑得慢的任務，使用SPL充分發揮單機性能后也能提速很多倍，這樣就不必再求助于分布式了。比如，在某銀行的對公貸款業務計算中，原本使用AIX+DB2要計算1.5小時，改用SPL后不到10分鐘就可以完成，性能提升10倍（案例詳情： 開源 SPL 提速銀行貸款協議跑批 10+ 倍）。還有某大型保險公司的車險跑批場景中，使用SPL替代數據庫將跑批時間從原來的2個小時提升到17分鐘，提速7倍（案例詳情： 開源 SPL 優化保險公司跑批優從 2 小時到 17 分鐘）。類似的案例還有很多，對SPL高性能計算案例及原理感興趣的小伙伴可以參考： 快出數量級的性能是怎樣煉成的。
當然，這里并不是要反對分布式，而是希望不要“無腦”分布式，把單機性能充分發揮完不夠用再使用分布式才是解鎖大數據計算的正確姿勢。
SPL也提供了完善的分布式計算功能，有相應的負載均衡和容錯機制，針對不同的需求和計算場景可以使用不同的容錯方案（如冗余式容錯和備胎式容錯）。值得一提的是，SPL集群的定位是中小規模，集群節點最好不要超過32個。由于SPL具備極高的計算性能可以有效利用硬件資源，因此在實際應用中這個集群規模已經足夠用了，很多場景使用單機最多幾臺就都搞定了。當然，如果遇到極少數需要更大集群的應用場景就需要選用其他技術了。
總結一下，應用分布式的前提是任務易“拆”，更關鍵的是，先要充分發揮單機性能之后再分布式。
SPL資料