Hadoop/Spark 太重，esProc SPL 很輕

隨著大資料時代的來臨，資料量不斷增長，傳統小機上跑資料庫的模式擴容困難且成本高昂，難以支撐業務發展。很多使用者開始轉向分散式計算路線，用多臺廉價的 PC 伺服器組成叢集來完成大資料計算任務。

Hadoop/Spark 就是其中重要的軟體技術，由於開源免費而廣受歡迎。經過多年的應用和發展，Hadoop 已經被廣泛接受，不僅直接應用於資料計算，還發展出很多基於它的新資料庫，比如 Hive、Impala 等。

Hadoop/Spark 之重

Hadoop 的設計目標是成百上千臺節點的叢集，為此，開發者實現了很多複雜、沉重的功能模組。但是，除了一些網際網路巨頭企業、通訊運營商和大型銀行外，大多數場景的資料量並沒有那麼巨大。結果，經常能看到只有幾個到十幾個節點的 Hadoop 叢集。由於目標和現實的錯位，對很多使用者來講，Hadoop 成了一個在技術、應用和成本上都很沉重的產品。

技術之重

如果真的有幾千臺計算機組成的叢集，是不可能依靠手工個性化管理的。試想，將這些計算機羅列出來，運維人員看都看不過來，更別說管理和分配任務了。再說，這麼多機器，難免會不斷出現各種故障，怎麼保證計算任務順利執行?Hadoop/Spark 的開發者為了解決這些問題，編寫了大量程式碼，用於實現自動化節點管理、任務分配和強容錯功能。

但是，這些功能本身就要佔用很多計算資源(CPU、記憶體和硬碟等)，如果用到幾臺到十幾臺節點的叢集上，就太過沉重了。叢集本來就不大，Hadoop 還要佔用相當一部分的資源，非常不划算。

不僅如此，Hadoop 產品線很長，要把這些模組都放在一個平臺上執行，還要梳理好各個產品之間的相互依賴性，就不得不實現一個包羅永珍的複雜架構。雖然大多數場景只用其中一兩個產品，也必須接受這個複雜、沉重的平臺。

後來出現的 Spark 彌補了 Hadoop 對記憶體利用的不足，技術上是不是可以變輕呢?很遺憾，Spark 走向了另一個極端，從理論模型上就只考慮記憶體計算了。特別是 Spark 中的 RDD 採用了 immutable 機制，在每個計算步驟後都會複製出新的 RDD，造成記憶體和 CPU 的大量佔用和浪費，離開大記憶體甚至無法執行，所以技術上還是很重。

使用之重

Hadoop 技術上太過複雜，也就意味著安裝和運維會很麻煩。叢集只有幾臺計算機時，卻不得不使用為幾千臺節點叢集設計的節點管理、任務分配和容錯功能。可想而知，安裝、配置、除錯都很困難，日常執行的維護、管理工作也不容易。

即使克服這些困難讓 Hadoop 執行起來了，編寫大資料計算程式碼時還會面臨更大的麻煩。Hadoop 程式設計的核心框架是 MapReduce，程式設計師要編寫並行程式，只要寫 Map 和 Reduce 動作即可，用來解決求和、計數等簡單問題也確實有效。但是，遇到複雜一些的業務邏輯，用 MapReduce 程式設計就會變得非常困難。例如，業務計算中很常見的 JOIN 計算，就很難用 MapReduce 實現。再比如，很多和次序有關的運算實現起來也很困難。

Spark 的 Scala 語言具備一定的結構化資料計算能力，是不是能簡單一些呢?很可惜，Scala 使用難度很大，難學更難精。遇到複雜一些的運算邏輯，Scala 也很難寫出來。

MapReduce、Scala 都這麼難，所以 Hadoop/Spark 計算語法開始迴歸 SQL 語言。Hive 可以將 SQL 轉化為 MapReduce 所以很受歡迎，Spark SQL 的應用也比 Scala 廣泛的多。但是，用 SQL 做一些常規查詢還算簡單，用於處理多步驟過程計算或次序相關運算還是非常麻煩，要寫很複雜的 UDF。而且，許多計算場景雖然勉強能用 SQL 實現，但是計算速度卻很不理想，也很難進行效能調優。

成本之重

雖然 Hadoop 軟體本身開源免費，但它技術複雜、使用困難，會帶來高昂的綜合成本。

前面說過，Hadoop 自身會佔用過多的 CPU、記憶體和硬碟，而 Spark 需要大記憶體支撐才能正常執行。所以不得不為 Hadoop/Spark 採購更高配置的伺服器，要增加硬體支出。

Hadoop/Spark 使用困難，就需要投入更多的人力去完成安裝、運維，保證 Hadoop/Spark 的正常運轉;還要投入更多的開發人員，程式設計實現各種複雜的業務計算，要增加人力資源成本。

由於使用過於困難，很多使用者不得不採購商業公司的收費版本 Hadoop/Spark，價格相當可觀，會大幅增加軟體採購成本。

既然 Hadoop 如此沉重，為什麼還有很多使用者會選擇它呢?答案很簡單：暫時找不到別的選擇，也只有 Hadoop 勉強可用，好歹知名度高一些。

如此一來，使用者就只能安裝、配置 Hadoop 的重型應用，並忍受 Hadoop 本身對計算資源的大量消耗。小規模叢集的伺服器數量本來就不多，Hadoop 又浪費了不少，小馬拉大車，最後執行的效果可想而知。花了大價錢採購、費事費力的使用 Hadoop，實際計算的效能卻不理想。

就沒有別的選擇了?

輕量級的選擇

開源的 esProc SPL 是輕量級大資料計算引擎，採用了全新的實現技術，可以做到技術輕、使用簡單、成本低。

技術輕

本文開頭說過，越來越大的資料量讓傳統資料庫撐不住，所以使用者只能轉向分散式計算技術。而資料庫之所以撐不住，是因為 SQL 難以實現高速演算法，大資料運算效能只能指望資料庫的最佳化引擎，遇到複雜計算時，最佳化引擎又常常無能為力。

所以，我們應該想辦法設計更高效的演算法，而不是一味地追求分散式計算。按照這個思路，SPL 提供了眾多高效能演算法(有許多是業界領先)以及高效的儲存方案，同等硬體環境下可以獲得遠超過資料庫的運算效能。安裝在單機上的 SPL 就可以完成很多大資料計算任務，架構比叢集簡單很多，從技術上自然就輕的多了。

SPL 的高效能演算法有下面這些：

對於資料量更大的情況，SPL 實現了輕量級叢集計算功能。這一功能的設計目標是幾臺到十幾臺節點的叢集，採用了與 Hadoop 完全不同的實現方法。

SPL 叢集不提供複雜沉重的自動化管理功能，而是允許對每個節點進行個性化配置。程式設計師可以根據資料特徵和計算目標來決定各節點儲存什麼樣的資料，完成哪些計算。這樣做，不僅大大降低了架構複雜度，也是提升效能的重要手段。

以訂單分析為例，訂單表很大，要透過產品號欄位與較小的產品表主鍵做關聯，再按照產品供應商分組彙總訂單金額。SPL 叢集可以很容易的將訂單表分段存放在各個節點的硬碟上，再將較小的產品表讀入每個節點的記憶體中。計算時，每個節點僅對本機上的訂單分段和產品資料做關聯、分組彙總，可以縮短總計算時間;再將結果傳輸到一個節點上做二次彙總。由於傳輸的是第一次彙總的結果，資料量小、網路傳輸時間較短。總體來說，這個方案可以獲得卓越效能，雖然程式設計師需要做一些更細緻的工作，但對於小規模叢集來說，增加的工作量並不大。

SPL 也不提供超強的容錯能力，不會像 Hadoop 那樣，在有節點故障的情況下，還要保證任何一個任務都會執行成功。實際上，大多數計算任務的執行時間都在幾個小時以內，而幾臺、十幾臺機器的叢集一般都能做到較長時間正常執行，不會這麼頻繁的出故障。即使偶爾出現節點故障導致任務執行失敗，再重新計算一遍也可以接受，畢竟這種情況不會經常發生。所以，SPL 的容錯能力只是保證有少數節點故障的時候，整個叢集還能繼續工作並接受新任務(包括重算的任務)，這就大大降低了 SPL 叢集的複雜度。

在記憶體計算方面，SPL 沒有使用 Spark RDD 的 immutable 機制，而是採用了指標式複用機制，利用地址(指標)訪問記憶體，在資料結構沒有改變的情況下，直接用原資料的地址形成結果集，不必每個計算都將資料複製一遍，僅僅多儲存一個地址(指標)，可以同時減少 CPU 和記憶體的消耗，執行起來要比 Spark 輕很多了。並且，SPL 改進了當前的外存計算演算法體系，降低了複雜度並擴大了適應範圍，可以做到內外存計算結合，充分提升計算效能的同時，還不像 Spark 那樣依賴大記憶體。

使用簡單

SPL 採用輕量級技術，自然更容易安裝、配置和執行維護。SPL 不僅可以作為獨立伺服器使用，還很容易整合到需要高效能運算的應用中，比如即時查詢系統，只要引入幾個 jar 包即可。Hadoop 則很難整合，只能在邊上作為一個資料來源執行。有些臨時性資料需要隨時進行處理，則可使用 SPL 的桌面整合開發環境視覺化地計算，快速得到結果。如果要安裝部署 Hadoop，那麼等環境搭建好時臨時資料任務已經過期了。

前面展示的眾多 SPL 高效能演算法，也能讓大資料計算程式設計變得簡單。程式設計師可以在較短時間內掌握這些演算法函式，學習成本相對較低。而且，使用這些現成的函式很容易實現各種複雜的計算需求，不僅比 MapReduce/Scala 簡單，比 SQL 也簡單很多。

成本低

與 Hadoop 相同，SPL 也是開源軟體，不同的是 SPL 不僅軟體免費，綜合成本也非常低。

SPL 安裝、配置、運維很容易，可以大大降低支援人員的人力資源成本。同時，由於 SPL 降低了大資料計算程式設計的難度，程式設計師很容易實現各種複雜的計算，開發效率顯著提高，也就節省了程式設計師的人力資源成本。

而且，由於 SPL 技術體系非常輕，平臺自身佔用的 CPU、記憶體和硬碟很少，可以讓更多的資源用於業務計算，能大幅提高硬體利用率。SPL 也不像 Spark 那樣依賴大記憶體，總體來說，大大減少了硬體採購成本。

SPL 既輕且快

SPL 技術輕、自身消耗小，而且還提供了眾多高效能演算法，所以，在幾個到幾十個節點的叢集，甚至單機的情況下，比 Hadoop/Spark 有更好的效能表現。

案例 1：某電商漏斗分析計算。

Spark：6 節點，每節點 4CPU 核，平均計算時間：25 秒。

SPL：單機，8 執行緒計算，平均計算時間可達 10 秒。程式碼量僅有 Spark Scala 的一半。

案例 2：某大型銀行使用者畫像分析。

Hadoop 上某 OLAP 伺服器：虛擬機器 100CPU 核，計算時間：120 秒。

SPL：虛擬機器 12CPU 核，計算時間：僅 4 秒。效能提高 250 倍。

案例 3：某商業銀行的手機銀行 APP，活期明細查詢，資料量大且高併發。

基於 Hadoop 的某商用資料倉儲：高併發時無法達到秒級的響應速度，只好換用 6 臺 ES 叢集。

SPL 單機：達到 6 臺 ES 叢集同樣的併發和響應能力。

總結來說，Hadoop/Spark 是源自頭部網際網路企業的重型解決方案，適合需要有超大規模叢集的巨大企業。很多場景的資料雖然也不少，但小叢集甚至無叢集就足夠處理，遠沒多到這些巨大企業的規模，也沒有那麼多的硬體裝置和維護人員。這種情況下，輕量級的大資料計算引擎 SPL 是首選，投入很低的成本，就可以做到技術輕、使用簡便，而且還能提高開發效率、達到更高的效能。