隨著大數(shù)據(jù)時代的來臨，數(shù)據(jù)量不斷增長，傳統(tǒng)小機上跑數(shù)據(jù)庫的模式擴容困難且成本高昂，難以支撐業(yè)務發(fā)展。很多用戶開始轉向分布式計算路線，用多臺廉價的 PC 服務器組成集群來完成大數(shù)據(jù)計算任務。
Hadoop/Spark 就是其中重要的軟件技術，由于開源免費而廣受歡迎。經(jīng)過多年的應用和發(fā)展，Hadoop 已經(jīng)被廣泛接受，不僅直接應用于數(shù)據(jù)計算，還發(fā)展出很多基于它的新數(shù)據(jù)庫，比如 Hive、Impala 等。Hadoop 的設計目標是成百上千臺節(jié)點的集群，為此，開發(fā)者實現(xiàn)了很多復雜、沉重的功能模塊。但是，除了一些互聯(lián)網(wǎng)巨頭企業(yè)、國家級通信運營商和大型銀行外，大多數(shù)場景的數(shù)據(jù)量并沒有那么巨大。結果，經(jīng)常能看到只有幾個到十幾個節(jié)點的 Hadoop 集群。由于目標和現(xiàn)實的錯位，對很多用戶來講，Hadoop 成了一個在技術、應用和成本上都很沉重的產(chǎn)品。如果真的有幾千臺計算機組成的集群，是不可能依靠手工個性化管理的。試想，將這些計算機羅列出來，運維人員看都看不過來，更別說管理和分配任務了。再說，這么多機器，難免會不斷出現(xiàn)各種故障，怎么保證計算任務順利執(zhí)行？Hadoop/Spark 的開發(fā)者為了解決這些問題，編寫了大量代碼，用于實現(xiàn)自動化節(jié)點管理、任務分配和強容錯功能。但是，這些功能本身就要占用很多計算資源（CPU、內(nèi)存和硬盤等），如果用到幾臺到十幾臺節(jié)點的集群上，就太過沉重了。集群本來就不大，Hadoop 還要占用相當一部分的資源，非常不劃算。不僅如此，Hadoop 產(chǎn)品線很長，要把這些模塊都放在一個平臺上運行，還要梳理好各個產(chǎn)品之間的相互依賴性，就不得不實現(xiàn)一個包羅萬象的復雜架構。雖然大多數(shù)場景只用其中一兩個產(chǎn)品，也必須接受這個復雜、沉重的平臺。后來出現(xiàn)的 Spark 彌補了 Hadoop 對內(nèi)存利用的不足，技術上是不是可以變輕呢？很遺憾，Spark 走向了另一個極端，從理論模型上就只考慮內(nèi)存計算了。特別是 Spark 中的 RDD 采用了 immutable 機制，在每個計算步驟后都會復制出新的 RDD，造成內(nèi)存和 CPU 的大量占用和浪費，離開大內(nèi)存甚至無法運行，所以技術上還是很重。Hadoop 技術上太過復雜，也就意味著安裝和運維會很麻煩。集群只有幾臺計算機時，卻不得不使用為幾千臺節(jié)點集群設計的節(jié)點管理、任務分配和容錯功能?？上攵惭b、配置、調試都很困難，日常運行的維護、管理工作也不容易。即使克服這些困難讓 Hadoop 運行起來了，編寫大數(shù)據(jù)計算代碼時還會面臨更大的麻煩。Hadoop 編程的核心框架是 MapReduce，程序員要編寫并行程序，只要寫 Map 和 Reduce 動作即可，用來解決求和、計數(shù)等簡單問題也確實有效。但是，遇到復雜一些的業(yè)務邏輯，用 MapReduce 編程就會變得非常困難。例如，業(yè)務計算中很常見的 JOIN 計算，就很難用 MapReduce 實現(xiàn)。再比如，很多和次序有關的運算實現(xiàn)起來也很困難。Spark 的 Scala 語言具備一定的結構化數(shù)據(jù)計算能力，是不是能簡單一些呢？很可惜，Scala 使用難度很大，難學更難精。遇到復雜一些的運算邏輯，Scala 也很難寫出來。MapReduce、Scala 都這么難，所以 Hadoop/Spark 計算語法開始回歸 SQL 語言。Hive 可以將 SQL 轉化為 MapReduce 所以很受歡迎，Spark SQL 的應用也比 Scala 廣泛的多。但是，用 SQL 做一些常規(guī)查詢還算簡單，用于處理多步驟過程計算或次序相關運算還是非常麻煩，要寫很復雜的 UDF。而且，許多計算場景雖然勉強能用 SQL 實現(xiàn)，但是計算速度卻很不理想，也很難進行性能調優(yōu)。雖然 Hadoop 軟件本身開源免費，但它技術復雜、使用困難，會帶來高昂的綜合成本。前面說過，Hadoop 自身會占用過多的 CPU、內(nèi)存和硬盤，而 Spark 需要大內(nèi)存支撐才能正常運行。所以不得不為 Hadoop/Spark 采購更高配置的服務器，要增加硬件支出。Hadoop/Spark 使用困難，就需要投入更多的人力去完成安裝、運維，保證 Hadoop/Spark 的正常運轉；還要投入更多的開發(fā)人員，編程實現(xiàn)各種復雜的業(yè)務計算，要增加人力資源成本。由于使用過于困難，很多用戶不得不采購商業(yè)公司的收費版本 Hadoop/Spark，價格相當可觀，會大幅增加軟件采購成本。既然 Hadoop 如此沉重，為什么還有很多用戶會選擇它呢？答案很簡單：暫時找不到別的選擇，也只有 Hadoop 勉強可用，好歹知名度高一些。如此一來，用戶就只能安裝、配置 Hadoop 的重型應用，并忍受 Hadoop 本身對計算資源的大量消耗。小規(guī)模集群的服務器數(shù)量本來就不多，Hadoop 又浪費了不少，小馬拉大車，最后運行的效果可想而知?；舜髢r錢采購、費事費力的使用 Hadoop，實際計算的性能卻不理想。開源的 esProc SPL 是輕量級大數(shù)據(jù)計算引擎，采用了全新的實現(xiàn)技術，可以做到技術輕、使用簡單、成本低。本文開頭說過，越來越大的數(shù)據(jù)量讓傳統(tǒng)數(shù)據(jù)庫撐不住，所以用戶只能轉向分布式計算技術。而數(shù)據(jù)庫之所以撐不住，是因為 SQL 難以實現(xiàn)高速算法，大數(shù)據(jù)運算性能只能指望數(shù)據(jù)庫的優(yōu)化引擎，遇到復雜計算時，優(yōu)化引擎又常常無能為力。所以，我們應該想辦法設計更高效的算法，而不是一味地追求分布式計算。按照這個思路，SPL 提供了眾多高性能算法（有許多是業(yè)界首創(chuàng)）以及高效的存儲方案，同等硬件環(huán)境下可以獲得遠超過數(shù)據(jù)庫的運算性能。安裝在單機上的 SPL 就可以完成很多大數(shù)據(jù)計算任務，架構比集群簡單很多，從技術上自然就輕得多了。
對于數(shù)據(jù)量更大的情況，SPL 實現(xiàn)了輕量級集群計算功能。這一功能的設計目標是幾臺到十幾臺節(jié)點的集群，采用了與 Hadoop 完全不同的實現(xiàn)方法。
SPL 集群不提供復雜沉重的自動化管理功能，而是允許對每個節(jié)點進行個性化配置。程序員可以根據(jù)數(shù)據(jù)特征和計算目標來決定各節(jié)點存儲什么樣的數(shù)據(jù)，完成哪些計算。這樣做，不僅大大降低了架構復雜度，也是提升性能的重要手段。以訂單分析為例，訂單表很大，要通過產(chǎn)品號字段與較小的產(chǎn)品表主鍵做關聯(lián)，再按照產(chǎn)品供應商分組匯總訂單金額。SPL 集群可以很容易的將訂單表分段存放在各個節(jié)點的硬盤上，再將較小的產(chǎn)品表讀入每個節(jié)點的內(nèi)存中。計算時，每個節(jié)點僅對本機上的訂單分段和產(chǎn)品數(shù)據(jù)做關聯(lián)、分組匯總，可以縮短總計算時間；再將結果傳輸?shù)揭粋€節(jié)點上做二次匯總。由于傳輸?shù)氖堑谝淮螀R總的結果，數(shù)據(jù)量小、網(wǎng)絡傳輸時間較短?？傮w來說，這個方案可以獲得最佳性能，雖然程序員需要做一些更細致的工作，但對于小規(guī)模集群來說，增加的工作量并不大。SPL 也不提供超強的容錯能力，不會像 Hadoop 那樣，在有節(jié)點故障的情況下，還要保證任何一個任務都會執(zhí)行成功。實際上，大多數(shù)計算任務的執(zhí)行時間都在幾個小時以內(nèi)，而幾臺、十幾臺機器的集群一般都能做到較長時間正常運行，不會這么頻繁的出故障。即使偶爾出現(xiàn)節(jié)點故障導致任務執(zhí)行失敗，再重新計算一遍也可以接受，畢竟這種情況不會經(jīng)常發(fā)生。所以，SPL 的容錯能力只是保證有少數(shù)節(jié)點故障的時候，整個集群還能繼續(xù)工作并接受新任務（包括重算的任務），這就大大降低了 SPL 集群的復雜度。在內(nèi)存計算方面，SPL 沒有使用 Spark RDD 的 immutable 機制，而是采用了指針式復用機制，利用地址（指針）訪問內(nèi)存，在數(shù)據(jù)結構沒有改變的情況下，直接用原數(shù)據(jù)的地址形成結果集，不必每個計算都將數(shù)據(jù)復制一遍，僅僅多保存一個地址（指針），可以同時減少 CPU 和內(nèi)存的消耗，運行起來要比 Spark 輕很多了。并且，SPL 改進了當前的外存計算算法體系，降低了復雜度并擴大了適應范圍，可以做到內(nèi)外存計算結合，充分提升計算性能的同時，還不像 Spark 那樣依賴大內(nèi)存。SPL 采用輕量級技術，自然更容易安裝、配置和運行維護。SPL 不僅可以作為獨立服務器使用，還很容易集成到需要高性能計算的應用中，比如即時查詢系統(tǒng)，只要引入幾個 jar 包即可。Hadoop 則很難集成，只能在邊上作為一個數(shù)據(jù)源運行。有些臨時性數(shù)據(jù)需要隨時進行處理，則可使用 SPL 的桌面集成開發(fā)環(huán)境可視化地計算，快速得到結果。如果要安裝部署 Hadoop，那么等環(huán)境搭建好時臨時數(shù)據(jù)任務已經(jīng)過期了。前面展示的眾多 SPL 高性能算法，也能讓大數(shù)據(jù)計算編程變得簡單。程序員可以在較短時間內(nèi)掌握這些算法函數(shù)，學習成本相對較低。而且，使用這些現(xiàn)成的函數(shù)很容易實現(xiàn)各種復雜的計算需求，不僅比 MapReduce/Scala 簡單，比 SQL 也簡單很多。比如，以電商網(wǎng)站常見的漏斗分析為例，用 SQL 實現(xiàn)三步漏斗的代碼大致如下：with e1 as (
select gid,1 as step1,min(etime) as t1
from T
where etime>= to_date('2021-01-10', 'yyyy-MM-dd') and etime<to_date('2021-01-25', 'yyyy-MM-dd')
and eventtype='eventtype1' and …
group by 1
),
with e2 as (
select gid,1 as step2,min(e1.t1) as t1,min(e2.etime) as t2
from T as e2
inner join e1 on e2.gid = e1.gid where e2.etime>= to_date('2021-01-10', 'yyyy-MM-dd') and e2.etime<to_date('2021-01-25', 'yyyy-MM-dd')
and e2.etime > t1
and e2.etime < t1 + 7
and eventtype='eventtype2' and …
group by 1
),
with e3 as (
select gid,1 as step3,min(e2.t1) as t1,min(e3.etime) as t3
from T as e3
inner join e2 on e3.gid = e2.gid
where e3.etime>= to_date('2021-01-10', 'yyyy-MM-dd') and e3.etime<to_date('2021-01-25', 'yyyy-MM-dd')
and e3.etime > t2
and e3.etime < t1 + 7
and eventtype='eventtype3' and …
group by 1
)
select
sum(step1) as step1,
sum(step2) as step2,
sum(step3) as step3
from
e1
left join e2 on e1.gid = e2.gid
left join e3 on e2.gid = e3.gid
SQL 寫出來要三十多行，理解起來有相當?shù)碾y度。如果用 MapReduce/Scala 來寫，會更加困難。即使是用 SQL 實現(xiàn)，寫出來的這段代碼和漏斗的步驟數(shù)量相關，每增加一步就要再增加一段子查詢。相比之下，SPL 就簡單得多，處理任意步驟數(shù)都是下面這樣簡潔的代碼：
| | |
| =["etype1","etype2","etype3"] | =file("event.ctx").open() |
| =B1.cursor(id,etime,etype;etime>=date("2021-01-10") && etime<date("2021-01-25") && A1.contain(etype) && …) |
| =A2.group(id).(~.sort(etime)) | =A3.new(~.select@1(etype==A1(1)):first,~:all).select(first) |
| =B3.(A1.(t=if(#==1,t1=first.etime,if(t,all.select@1(etype==A1.~ && etime>t && etime<t1+7).etime, null)))) |
| =A4.groups(;count(~(1)):STEP1,count(~(2)):STEP2,count(~(3)):STEP3) |
SPL 集群計算的代碼也非常簡單，比如前面提到的訂單分析計算，具體要求是：大訂單表分段存儲在 4 個節(jié)點上，小產(chǎn)品表則加載到每個節(jié)點的內(nèi)存中，兩表關聯(lián)之后要按照產(chǎn)品供應商分組匯總訂單金額。用 SPL 寫出來大致是下面這樣：
| A | B |
1 | ["192.168.0.101:8281","192.168.0.102:8281",…, "192.168.0.104:8281"] |
2 | fork to(4);A1 | =file("product.ctx").open().import() |
3 |
| >env(PRODUCT,B2) |
4 | =memory(A1,PRODUCT) |
5 | =file("orders.ctx":to(4),A1).open().cursor(p_id,quantity) |
6 | =A5.switch(p_id,A4) |
7 | =A7.groups(p_id.vendor;sum(p_id.price*quantity)) |
這段代碼執(zhí)行時，任務管理（內(nèi)存加載、任務拆分、合并等）所需要的計算資源，遠遠小于關聯(lián)和分組匯總計算的消耗。如此輕便的任務管理功能，可以在任意節(jié)點、甚至是集成開發(fā)環(huán)境 IDE 上執(zhí)行。
與 Hadoop 相同，SPL 也是開源軟件，不同的是 SPL 不僅軟件免費，綜合成本也非常低。SPL 安裝、配置、運維很容易，可以大大降低支持人員的人力資源成本。同時，由于 SPL 降低了大數(shù)據(jù)計算編程的難度，程序員很容易實現(xiàn)各種復雜的計算，開發(fā)效率顯著提高，也就節(jié)省了程序員的人力資源成本。而且，由于 SPL 技術體系非常輕，平臺自身占用的 CPU、內(nèi)存和硬盤很少，可以讓更多的資源用于業(yè)務計算，能大幅提高硬件利用率。SPL 也不像 Spark 那樣依賴大內(nèi)存，總體來說，大大減少了硬件采購成本。SPL 技術輕、自身消耗小，而且還提供了眾多高性能算法，所以，在幾個到幾十個節(jié)點的集群，甚至單機的情況下，比 Hadoop/Spark 有更好的性能表現(xiàn)。Spark：6 節(jié)點，每節(jié)點 4CPU 核，平均計算時間：25 秒。SPL：單機，8 線程計算，平均計算時間可達 10 秒。代碼量僅有 Spark Scala 的一半。Hadoop 上某 OLAP 服務器：虛擬機 100CPU 核，計算時間：120 秒。SPL：虛擬機 12CPU 核，計算時間：僅 4 秒。性能提高 250 倍。 案例 3：某商業(yè)銀行的手機銀行 APP，活期明細查詢，數(shù)據(jù)量大且高并發(fā)。基于 Hadoop 的某商用數(shù)據(jù)倉庫：高并發(fā)時無法達到秒級的響應速度，只好換用 6 臺 ES 集群。SPL 單機：達到 6 臺 ES 集群同樣的并發(fā)和響應能力。總結來說，Hadoop/Spark 是源自頭部互聯(lián)網(wǎng)企業(yè)的重型解決方案，適合需要有超大規(guī)模集群的巨大企業(yè)。很多場景的數(shù)據(jù)雖然也不少，但小集群甚至無集群就足夠處理，遠沒多到這些巨大企業(yè)的規(guī)模，也沒有那么多的硬件設備和維護人員。這種情況下，輕量級的大數(shù)據(jù)計算引擎 SPL 是首選，投入很低的成本，就可以做到技術輕、使用簡便，而且還能提高開發(fā)效率、達到更高的性能。就可以做到技術輕、使用簡便，而且還能提高開發(fā)效率、達到更高的性能。
簡單好用的SPL開源啦！
為了給感興趣的技術人員提供一個相互交流的平臺，
特地開通了交流群（群完全免費，不廣告不賣課）
