國(guó)產(chǎn)數(shù)據(jù)庫(kù)，計(jì)算性能太強(qiáng)了！
隨著大數(shù)據(jù)時(shí)代的來(lái)臨，數(shù)據(jù)量不斷增長(zhǎng)，傳統(tǒng)小機(jī)上跑數(shù)據(jù)庫(kù)的模式擴(kuò)容困難且成本高昂，難以支撐業(yè)務(wù)發(fā)展。很多用戶開(kāi)始轉(zhuǎn)向分布式計(jì)算路線，用多臺(tái)廉價(jià)的 PC 服務(wù)器組成集群來(lái)完成大數(shù)據(jù)計(jì)算任務(wù)。Hadoop/Spark 就是其中重要的軟件技術(shù)，由于開(kāi)源免費(fèi)而廣受歡迎。經(jīng)過(guò)多年的應(yīng)用和發(fā)展，Hadoop 已經(jīng)被廣泛接受，不僅直接應(yīng)用于數(shù)據(jù)計(jì)算，還發(fā)展出很多基于它的新數(shù)據(jù)庫(kù)，比如 Hive、Impala 等。
對(duì)于數(shù)據(jù)量更大的情況，SPL 實(shí)現(xiàn)了輕量級(jí)集群計(jì)算功能。這一功能的設(shè)計(jì)目標(biāo)是幾臺(tái)到十幾臺(tái)節(jié)點(diǎn)的集群，采用了與 Hadoop 完全不同的實(shí)現(xiàn)方法。SPL 集群不提供復(fù)雜沉重的自動(dòng)化管理功能，而是允許對(duì)每個(gè)節(jié)點(diǎn)進(jìn)行個(gè)性化配置。程序員可以根據(jù)數(shù)據(jù)特征和計(jì)算目標(biāo)來(lái)決定各節(jié)點(diǎn)存儲(chǔ)什么樣的數(shù)據(jù)，完成哪些計(jì)算。這樣做，不僅大大降低了架構(gòu)復(fù)雜度，也是提升性能的重要手段。以訂單分析為例，訂單表很大，要通過(guò)產(chǎn)品號(hào)字段與較小的產(chǎn)品表主鍵做關(guān)聯(lián)，再按照產(chǎn)品供應(yīng)商分組匯總訂單金額。SPL 集群可以很容易的將訂單表分段存放在各個(gè)節(jié)點(diǎn)的硬盤(pán)上，再將較小的產(chǎn)品表讀入每個(gè)節(jié)點(diǎn)的內(nèi)存中。計(jì)算時(shí)，每個(gè)節(jié)點(diǎn)僅對(duì)本機(jī)上的訂單分段和產(chǎn)品數(shù)據(jù)做關(guān)聯(lián)、分組匯總，可以縮短總計(jì)算時(shí)間；再將結(jié)果傳輸?shù)揭粋€(gè)節(jié)點(diǎn)上做二次匯總。由于傳輸?shù)氖堑谝淮螀R總的結(jié)果，數(shù)據(jù)量小、網(wǎng)絡(luò)傳輸時(shí)間較短?？傮w來(lái)說(shuō)，這個(gè)方案可以獲得最佳性能，雖然程序員需要做一些更細(xì)致的工作，但對(duì)于小規(guī)模集群來(lái)說(shuō)，增加的工作量并不大。SPL 也不提供超強(qiáng)的容錯(cuò)能力，不會(huì)像 Hadoop 那樣，在有節(jié)點(diǎn)故障的情況下，還要保證任何一個(gè)任務(wù)都會(huì)執(zhí)行成功。實(shí)際上，大多數(shù)計(jì)算任務(wù)的執(zhí)行時(shí)間都在幾個(gè)小時(shí)以內(nèi)，而幾臺(tái)、十幾臺(tái)機(jī)器的集群一般都能做到較長(zhǎng)時(shí)間正常運(yùn)行，不會(huì)這么頻繁的出故障。即使偶爾出現(xiàn)節(jié)點(diǎn)故障導(dǎo)致任務(wù)執(zhí)行失敗，再重新計(jì)算一遍也可以接受，畢竟這種情況不會(huì)經(jīng)常發(fā)生。所以，SPL 的容錯(cuò)能力只是保證有少數(shù)節(jié)點(diǎn)故障的時(shí)候，整個(gè)集群還能繼續(xù)工作并接受新任務(wù)（包括重算的任務(wù)），這就大大降低了 SPL 集群的復(fù)雜度。在內(nèi)存計(jì)算方面，SPL 沒(méi)有使用 Spark RDD 的 immutable 機(jī)制，而是采用了指針式復(fù)用機(jī)制，利用地址（指針）訪問(wèn)內(nèi)存，在數(shù)據(jù)結(jié)構(gòu)沒(méi)有改變的情況下，直接用原數(shù)據(jù)的地址形成結(jié)果集，不必每個(gè)計(jì)算都將數(shù)據(jù)復(fù)制一遍，僅僅多保存一個(gè)地址（指針），可以同時(shí)減少 CPU 和內(nèi)存的消耗，運(yùn)行起來(lái)要比 Spark 輕很多了。并且，SPL 改進(jìn)了當(dāng)前的外存計(jì)算算法體系，降低了復(fù)雜度并擴(kuò)大了適應(yīng)范圍，可以做到內(nèi)外存計(jì)算結(jié)合，充分提升計(jì)算性能的同時(shí)，還不像 Spark 那樣依賴大內(nèi)存。使用簡(jiǎn)單SPL 采用輕量級(jí)技術(shù)，自然更容易安裝、配置和運(yùn)行維護(hù)。SPL 不僅可以作為獨(dú)立服務(wù)器使用，還很容易集成到需要高性能計(jì)算的應(yīng)用中，比如即時(shí)查詢系統(tǒng)，只要引入幾個(gè) jar 包即可。Hadoop 則很難集成，只能在邊上作為一個(gè)數(shù)據(jù)源運(yùn)行。有些臨時(shí)性數(shù)據(jù)需要隨時(shí)進(jìn)行處理，則可使用 SPL 的桌面集成開(kāi)發(fā)環(huán)境可視化地計(jì)算，快速得到結(jié)果。如果要安裝部署 Hadoop，那么等環(huán)境搭建好時(shí)臨時(shí)數(shù)據(jù)任務(wù)已經(jīng)過(guò)期了。前面展示的眾多 SPL 高性能算法，也能讓大數(shù)據(jù)計(jì)算編程變得簡(jiǎn)單。程序員可以在較短時(shí)間內(nèi)掌握這些算法函數(shù)，學(xué)習(xí)成本相對(duì)較低。而且，使用這些現(xiàn)成的函數(shù)很容易實(shí)現(xiàn)各種復(fù)雜的計(jì)算需求，不僅比 MapReduce/Scala 簡(jiǎn)單，比 SQL 也簡(jiǎn)單很多。比如，以電商網(wǎng)站常見(jiàn)的漏斗分析為例，用 SQL 實(shí)現(xiàn)三步漏斗的代碼大致如下：
Hadoop/Spark 之重
Hadoop 的設(shè)計(jì)目標(biāo)是成百上千臺(tái)節(jié)點(diǎn)的集群，為此，開(kāi)發(fā)者實(shí)現(xiàn)了很多復(fù)雜、沉重的功能模塊。但是，除了一些互聯(lián)網(wǎng)巨頭企業(yè)、國(guó)家級(jí)通信運(yùn)營(yíng)商和大型銀行外，大多數(shù)場(chǎng)景的數(shù)據(jù)量并沒(méi)有那么巨大。結(jié)果，經(jīng)常能看到只有幾個(gè)到十幾個(gè)節(jié)點(diǎn)的 Hadoop 集群。由于目標(biāo)和現(xiàn)實(shí)的錯(cuò)位，對(duì)很多用戶來(lái)講，Hadoop 成了一個(gè)在技術(shù)、應(yīng)用和成本上都很沉重的產(chǎn)品。技術(shù)之重如果真的有幾千臺(tái)計(jì)算機(jī)組成的集群，是不可能依靠手工個(gè)性化管理的。試想，將這些計(jì)算機(jī)羅列出來(lái)，運(yùn)維人員看都看不過(guò)來(lái)，更別說(shuō)管理和分配任務(wù)了。再說(shuō)，這么多機(jī)器，難免會(huì)不斷出現(xiàn)各種故障，怎么保證計(jì)算任務(wù)順利執(zhí)行？Hadoop/Spark 的開(kāi)發(fā)者為了解決這些問(wèn)題，編寫(xiě)了大量代碼，用于實(shí)現(xiàn)自動(dòng)化節(jié)點(diǎn)管理、任務(wù)分配和強(qiáng)容錯(cuò)功能。但是，這些功能本身就要占用很多計(jì)算資源（CPU、內(nèi)存和硬盤(pán)等），如果用到幾臺(tái)到十幾臺(tái)節(jié)點(diǎn)的集群上，就太過(guò)沉重了。集群本來(lái)就不大，Hadoop 還要占用相當(dāng)一部分的資源，非常不劃算。不僅如此，Hadoop 產(chǎn)品線很長(zhǎng)，要把這些模塊都放在一個(gè)平臺(tái)上運(yùn)行，還要梳理好各個(gè)產(chǎn)品之間的相互依賴性，就不得不實(shí)現(xiàn)一個(gè)包羅萬(wàn)象的復(fù)雜架構(gòu)。雖然大多數(shù)場(chǎng)景只用其中一兩個(gè)產(chǎn)品，也必須接受這個(gè)復(fù)雜、沉重的平臺(tái)。后來(lái)出現(xiàn)的 Spark 彌補(bǔ)了 Hadoop 對(duì)內(nèi)存利用的不足，技術(shù)上是不是可以變輕呢？很遺憾，Spark 走向了另一個(gè)極端，從理論模型上就只考慮內(nèi)存計(jì)算了。特別是 Spark 中的 RDD 采用了 immutable 機(jī)制，在每個(gè)計(jì)算步驟后都會(huì)復(fù)制出新的 RDD，造成內(nèi)存和 CPU 的大量占用和浪費(fèi)，離開(kāi)大內(nèi)存甚至無(wú)法運(yùn)行，所以技術(shù)上還是很重。使用之重Hadoop 技術(shù)上太過(guò)復(fù)雜，也就意味著安裝和運(yùn)維會(huì)很麻煩。集群只有幾臺(tái)計(jì)算機(jī)時(shí)，卻不得不使用為幾千臺(tái)節(jié)點(diǎn)集群設(shè)計(jì)的節(jié)點(diǎn)管理、任務(wù)分配和容錯(cuò)功能?？上攵?，安裝、配置、調(diào)試都很困難，日常運(yùn)行的維護(hù)、管理工作也不容易。即使克服這些困難讓 Hadoop 運(yùn)行起來(lái)了，編寫(xiě)大數(shù)據(jù)計(jì)算代碼時(shí)還會(huì)面臨更大的麻煩。Hadoop 編程的核心框架是 MapReduce，程序員要編寫(xiě)并行程序，只要寫(xiě) Map 和 Reduce 動(dòng)作即可，用來(lái)解決求和、計(jì)數(shù)等簡(jiǎn)單問(wèn)題也確實(shí)有效。但是，遇到復(fù)雜一些的業(yè)務(wù)邏輯，用 MapReduce 編程就會(huì)變得非常困難。例如，業(yè)務(wù)計(jì)算中很常見(jiàn)的 JOIN 計(jì)算，就很難用 MapReduce 實(shí)現(xiàn)。再比如，很多和次序有關(guān)的運(yùn)算實(shí)現(xiàn)起來(lái)也很困難。Spark 的 Scala 語(yǔ)言具備一定的結(jié)構(gòu)化數(shù)據(jù)計(jì)算能力，是不是能簡(jiǎn)單一些呢？很可惜，Scala 使用難度很大，難學(xué)更難精。遇到復(fù)雜一些的運(yùn)算邏輯，Scala 也很難寫(xiě)出來(lái)。MapReduce、Scala 都這么難，所以 Hadoop/Spark 計(jì)算語(yǔ)法開(kāi)始回歸 SQL 語(yǔ)言。Hive 可以將 SQL 轉(zhuǎn)化為 MapReduce 所以很受歡迎，Spark SQL 的應(yīng)用也比 Scala 廣泛的多。但是，用 SQL 做一些常規(guī)查詢還算簡(jiǎn)單，用于處理多步驟過(guò)程計(jì)算或次序相關(guān)運(yùn)算還是非常麻煩，要寫(xiě)很復(fù)雜的 UDF。而且，許多計(jì)算場(chǎng)景雖然勉強(qiáng)能用 SQL 實(shí)現(xiàn)，但是計(jì)算速度卻很不理想，也很難進(jìn)行性能調(diào)優(yōu)。成本之重雖然 Hadoop 軟件本身開(kāi)源免費(fèi)，但它技術(shù)復(fù)雜、使用困難，會(huì)帶來(lái)高昂的綜合成本。前面說(shuō)過(guò)，Hadoop 自身會(huì)占用過(guò)多的 CPU、內(nèi)存和硬盤(pán)，而 Spark 需要大內(nèi)存支撐才能正常運(yùn)行。所以不得不為 Hadoop/Spark 采購(gòu)更高配置的服務(wù)器，要增加硬件支出。Hadoop/Spark 使用困難，就需要投入更多的人力去完成安裝、運(yùn)維，保證 Hadoop/Spark 的正常運(yùn)轉(zhuǎn)；還要投入更多的開(kāi)發(fā)人員，編程實(shí)現(xiàn)各種復(fù)雜的業(yè)務(wù)計(jì)算，要增加人力資源成本。由于使用過(guò)于困難，很多用戶不得不采購(gòu)商業(yè)公司的收費(fèi)版本 Hadoop/Spark，價(jià)格相當(dāng)可觀，會(huì)大幅增加軟件采購(gòu)成本。既然 Hadoop 如此沉重，為什么還有很多用戶會(huì)選擇它呢？答案很簡(jiǎn)單：暫時(shí)找不到別的選擇，也只有 Hadoop 勉強(qiáng)可用，好歹知名度高一些。如此一來(lái)，用戶就只能安裝、配置 Hadoop 的重型應(yīng)用，并忍受 Hadoop 本身對(duì)計(jì)算資源的大量消耗。小規(guī)模集群的服務(wù)器數(shù)量本來(lái)就不多，Hadoop 又浪費(fèi)了不少，小馬拉大車，最后運(yùn)行的效果可想而知?；舜髢r(jià)錢采購(gòu)、費(fèi)事費(fèi)力的使用 Hadoop，實(shí)際計(jì)算的性能卻不理想。就沒(méi)有別的選擇了？輕量級(jí)的選擇
開(kāi)源的 esProc SPL 是輕量級(jí)大數(shù)據(jù)計(jì)算引擎，采用了全新的實(shí)現(xiàn)技術(shù)，可以做到技術(shù)輕、使用簡(jiǎn)單、成本低。技術(shù)輕本文開(kāi)頭說(shuō)過(guò)，越來(lái)越大的數(shù)據(jù)量讓傳統(tǒng)數(shù)據(jù)庫(kù)撐不住，所以用戶只能轉(zhuǎn)向分布式計(jì)算技術(shù)。而數(shù)據(jù)庫(kù)之所以撐不住，是因?yàn)?SQL 難以實(shí)現(xiàn)高速算法，大數(shù)據(jù)運(yùn)算性能只能指望數(shù)據(jù)庫(kù)的優(yōu)化引擎，遇到復(fù)雜計(jì)算時(shí)，優(yōu)化引擎又常常無(wú)能為力。所以，我們應(yīng)該想辦法設(shè)計(jì)更高效的算法，而不是一味地追求分布式計(jì)算。按照這個(gè)思路，SPL 提供了眾多高性能算法（有許多是業(yè)界首創(chuàng)）以及高效的存儲(chǔ)方案，同等硬件環(huán)境下可以獲得遠(yuǎn)超過(guò)數(shù)據(jù)庫(kù)的運(yùn)算性能。安裝在單機(jī)上的 SPL 就可以完成很多大數(shù)據(jù)計(jì)算任務(wù)，架構(gòu)比集群簡(jiǎn)單很多，從技術(shù)上自然就輕的多了。SPL 的高性能算法有下面這些：對(duì)于數(shù)據(jù)量更大的情況，SPL 實(shí)現(xiàn)了輕量級(jí)集群計(jì)算功能。這一功能的設(shè)計(jì)目標(biāo)是幾臺(tái)到十幾臺(tái)節(jié)點(diǎn)的集群，采用了與 Hadoop 完全不同的實(shí)現(xiàn)方法。SPL 集群不提供復(fù)雜沉重的自動(dòng)化管理功能，而是允許對(duì)每個(gè)節(jié)點(diǎn)進(jìn)行個(gè)性化配置。程序員可以根據(jù)數(shù)據(jù)特征和計(jì)算目標(biāo)來(lái)決定各節(jié)點(diǎn)存儲(chǔ)什么樣的數(shù)據(jù)，完成哪些計(jì)算。這樣做，不僅大大降低了架構(gòu)復(fù)雜度，也是提升性能的重要手段。以訂單分析為例，訂單表很大，要通過(guò)產(chǎn)品號(hào)字段與較小的產(chǎn)品表主鍵做關(guān)聯(lián)，再按照產(chǎn)品供應(yīng)商分組匯總訂單金額。SPL 集群可以很容易的將訂單表分段存放在各個(gè)節(jié)點(diǎn)的硬盤(pán)上，再將較小的產(chǎn)品表讀入每個(gè)節(jié)點(diǎn)的內(nèi)存中。計(jì)算時(shí)，每個(gè)節(jié)點(diǎn)僅對(duì)本機(jī)上的訂單分段和產(chǎn)品數(shù)據(jù)做關(guān)聯(lián)、分組匯總，可以縮短總計(jì)算時(shí)間；再將結(jié)果傳輸?shù)揭粋€(gè)節(jié)點(diǎn)上做二次匯總。由于傳輸?shù)氖堑谝淮螀R總的結(jié)果，數(shù)據(jù)量小、網(wǎng)絡(luò)傳輸時(shí)間較短?？傮w來(lái)說(shuō)，這個(gè)方案可以獲得最佳性能，雖然程序員需要做一些更細(xì)致的工作，但對(duì)于小規(guī)模集群來(lái)說(shuō)，增加的工作量并不大。SPL 也不提供超強(qiáng)的容錯(cuò)能力，不會(huì)像 Hadoop 那樣，在有節(jié)點(diǎn)故障的情況下，還要保證任何一個(gè)任務(wù)都會(huì)執(zhí)行成功。實(shí)際上，大多數(shù)計(jì)算任務(wù)的執(zhí)行時(shí)間都在幾個(gè)小時(shí)以內(nèi)，而幾臺(tái)、十幾臺(tái)機(jī)器的集群一般都能做到較長(zhǎng)時(shí)間正常運(yùn)行，不會(huì)這么頻繁的出故障。即使偶爾出現(xiàn)節(jié)點(diǎn)故障導(dǎo)致任務(wù)執(zhí)行失敗，再重新計(jì)算一遍也可以接受，畢竟這種情況不會(huì)經(jīng)常發(fā)生。所以，SPL 的容錯(cuò)能力只是保證有少數(shù)節(jié)點(diǎn)故障的時(shí)候，整個(gè)集群還能繼續(xù)工作并接受新任務(wù)（包括重算的任務(wù)），這就大大降低了 SPL 集群的復(fù)雜度。在內(nèi)存計(jì)算方面，SPL 沒(méi)有使用 Spark RDD 的 immutable 機(jī)制，而是采用了指針式復(fù)用機(jī)制，利用地址（指針）訪問(wèn)內(nèi)存，在數(shù)據(jù)結(jié)構(gòu)沒(méi)有改變的情況下，直接用原數(shù)據(jù)的地址形成結(jié)果集，不必每個(gè)計(jì)算都將數(shù)據(jù)復(fù)制一遍，僅僅多保存一個(gè)地址（指針），可以同時(shí)減少 CPU 和內(nèi)存的消耗，運(yùn)行起來(lái)要比 Spark 輕很多了。并且，SPL 改進(jìn)了當(dāng)前的外存計(jì)算算法體系，降低了復(fù)雜度并擴(kuò)大了適應(yīng)范圍，可以做到內(nèi)外存計(jì)算結(jié)合，充分提升計(jì)算性能的同時(shí)，還不像 Spark 那樣依賴大內(nèi)存。使用簡(jiǎn)單SPL 采用輕量級(jí)技術(shù)，自然更容易安裝、配置和運(yùn)行維護(hù)。SPL 不僅可以作為獨(dú)立服務(wù)器使用，還很容易集成到需要高性能計(jì)算的應(yīng)用中，比如即時(shí)查詢系統(tǒng)，只要引入幾個(gè) jar 包即可。Hadoop 則很難集成，只能在邊上作為一個(gè)數(shù)據(jù)源運(yùn)行。有些臨時(shí)性數(shù)據(jù)需要隨時(shí)進(jìn)行處理，則可使用 SPL 的桌面集成開(kāi)發(fā)環(huán)境可視化地計(jì)算，快速得到結(jié)果。如果要安裝部署 Hadoop，那么等環(huán)境搭建好時(shí)臨時(shí)數(shù)據(jù)任務(wù)已經(jīng)過(guò)期了。前面展示的眾多 SPL 高性能算法，也能讓大數(shù)據(jù)計(jì)算編程變得簡(jiǎn)單。程序員可以在較短時(shí)間內(nèi)掌握這些算法函數(shù)，學(xué)習(xí)成本相對(duì)較低。而且，使用這些現(xiàn)成的函數(shù)很容易實(shí)現(xiàn)各種復(fù)雜的計(jì)算需求，不僅比 MapReduce/Scala 簡(jiǎn)單，比 SQL 也簡(jiǎn)單很多。比如，以電商網(wǎng)站常見(jiàn)的漏斗分析為例，用 SQL 實(shí)現(xiàn)三步漏斗的代碼大致如下：
with e1 as (
select gid,1 as step1,min(etime) as t1
fromT
whereetime>=to_date('2021-01-10','yyyy-MM-dd')andetime<to_date('2021-01-25','yyyy-MM-dd')
andeventtype='eventtype1'and…
groupby1
),
withe2as(
selectgid,1asstep2,min(e1.t1)ast1,min(e2.etime)ast2
fromTase2
innerjoine1one2.gid=e1.gidwheree2.etime>=to_date('2021-01-10','yyyy-MM-dd')ande2.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
),
withe3as(
selectgid,1asstep3,min(e2.t1)ast1,min(e3.etime)ast3
fromTase3
innerjoine2one3.gid=e2.gid
wheree3.etime>=to_date('2021-01-10','yyyy-MM-dd')ande3.etime<to_date('2021-01-25','yyyy-MM-dd')
and e3.etime > t2
and e3.etime < t1 + 7
and eventtype='eventtype3' and …
groupby1
)
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 寫(xiě)出來(lái)要三十多行，理解起來(lái)有相當(dāng)?shù)碾y度。如果用 MapReduce/Scala 來(lái)寫(xiě)，會(huì)更加困難。即使是用 SQL 實(shí)現(xiàn)，寫(xiě)出來(lái)的這段代碼和漏斗的步驟數(shù)量相關(guān)，每增加一步就要再增加一段子查詢。相比之下，SPL 就簡(jiǎn)單得多，處理任意步驟數(shù)都是下面這樣簡(jiǎn)潔的代碼：| A | B | |
| 1 | =["etype1","etype2","etype3"] | =file("event.ctx").open() |
| 2 |
=B1.cursor(id,etime,etype;etime>=date("2021-01-10") && etime |
|
| 3 | =A2.group(id).(~.sort(etime)) | =A3.new(~.select@1(etype==A1(1)):first,~:all).select(first) |
| 4 |
=B3.(A1.(t=if(#==1,t1=first.etime,if(t,all.select@1(etype==A1.~ && etime>t && etime |
|
| 5 | =A4.groups(;count(~(1)):STEP1,count(~(2)):STEP2,count(~(3)):STEP3) | |
SPL 集群計(jì)算的代碼也非常簡(jiǎn)單，比如前面提到的訂單分析計(jì)算，具體要求是：大訂單表分段存儲(chǔ)在 4 個(gè)節(jié)點(diǎn)上，小產(chǎn)品表則加載到每個(gè)節(jié)點(diǎn)的內(nèi)存中，兩表關(guān)聯(lián)之后要按照產(chǎn)品供應(yīng)商分組匯總訂單金額。用 SPL 寫(xiě)出來(lái)大致是下面這樣：
|
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í)行時(shí)，任務(wù)管理（內(nèi)存加載、任務(wù)拆分、合并等）所需要的計(jì)算資源，遠(yuǎn)遠(yuǎn)小于關(guān)聯(lián)和分組匯總計(jì)算的消耗。如此輕便的任務(wù)管理功能，可以在任意節(jié)點(diǎn)、甚至是集成開(kāi)發(fā)環(huán)境 IDE 上執(zhí)行。
成本低與 Hadoop 相同，SPL 也是開(kāi)源軟件，不同的是 SPL 不僅軟件免費(fèi)，綜合成本也非常低。SPL 安裝、配置、運(yùn)維很容易，可以大大降低支持人員的人力資源成本。同時(shí)，由于 SPL 降低了大數(shù)據(jù)計(jì)算編程的難度，程序員很容易實(shí)現(xiàn)各種復(fù)雜的計(jì)算，開(kāi)發(fā)效率顯著提高，也就節(jié)省了程序員的人力資源成本。而且，由于 SPL 技術(shù)體系非常輕，平臺(tái)自身占用的 CPU、內(nèi)存和硬盤(pán)很少，可以讓更多的資源用于業(yè)務(wù)計(jì)算，能大幅提高硬件利用率。SPL 也不像 Spark 那樣依賴大內(nèi)存，總體來(lái)說(shuō)，大大減少了硬件采購(gòu)成本。SPL 既輕且快
SPL 技術(shù)輕、自身消耗小，而且還提供了眾多高性能算法，所以，在幾個(gè)到幾十個(gè)節(jié)點(diǎn)的集群，甚至單機(jī)的情況下，比 Hadoop/Spark 有更好的性能表現(xiàn)。案例 1：某電商漏斗分析計(jì)算。Spark：6 節(jié)點(diǎn)，每節(jié)點(diǎn) 4CPU 核，平均計(jì)算時(shí)間：25 秒。SPL：?jiǎn)螜C(jī)，8 線程計(jì)算，平均計(jì)算時(shí)間可達(dá) 10 秒。代碼量?jī)H有 Spark Scala 的一半。案例 2：某大型銀行用戶畫(huà)像分析。Hadoop 上某 OLAP 服務(wù)器：虛擬機(jī) 100CPU 核，計(jì)算時(shí)間：120 秒。SPL：虛擬機(jī) 12CPU 核，計(jì)算時(shí)間：僅 4 秒。性能提高 250 倍。 案例 3：某商業(yè)銀行的手機(jī)銀行 APP，活期明細(xì)查詢，數(shù)據(jù)量大且高并發(fā)。基于 Hadoop 的某商用數(shù)據(jù)倉(cāng)庫(kù)：高并發(fā)時(shí)無(wú)法達(dá)到秒級(jí)的響應(yīng)速度，只好換用 6 臺(tái) ES 集群。SPL 單機(jī)：達(dá)到 6 臺(tái) ES 集群同樣的并發(fā)和響應(yīng)能力。總結(jié)來(lái)說(shuō)，Hadoop/Spark 是源自頭部互聯(lián)網(wǎng)企業(yè)的重型解決方案，適合需要有超大規(guī)模集群的巨大企業(yè)。很多場(chǎng)景的數(shù)據(jù)雖然也不少，但小集群甚至無(wú)集群就足夠處理，遠(yuǎn)沒(méi)多到這些巨大企業(yè)的規(guī)模，也沒(méi)有那么多的硬件設(shè)備和維護(hù)人員。這種情況下，輕量級(jí)的大數(shù)據(jù)計(jì)算引擎 SPL 是首選，投入很低的成本，就可以做到技術(shù)輕、使用簡(jiǎn)便，而且還能提高開(kāi)發(fā)效率、達(dá)到更高的性能。GitHub：https://github.com/SPLWare/esProc
聲明：本文內(nèi)容及配圖由入駐作者撰寫(xiě)或者入駐合作網(wǎng)站授權(quán)轉(zhuǎn)載。文章觀點(diǎn)僅代表作者本人，不代表電子發(fā)燒友網(wǎng)立場(chǎng)。文章及其配圖僅供工程師學(xué)習(xí)之用，如有內(nèi)容侵權(quán)或者其他違規(guī)問(wèn)題，請(qǐng)聯(lián)系本站處理。
舉報(bào)投訴
-
cpu
+關(guān)注
關(guān)注
68文章
10904瀏覽量
213023 -
數(shù)據(jù)庫(kù)
+關(guān)注
關(guān)注
7文章
3846瀏覽量
64686 -
大數(shù)據(jù)
+關(guān)注
關(guān)注
64文章
8908瀏覽量
137798
原文標(biāo)題：國(guó)產(chǎn)數(shù)據(jù)庫(kù)，計(jì)算性能太強(qiáng)了！
文章出處：【微信號(hào)：芋道源碼，微信公眾號(hào)：芋道源碼】歡迎添加關(guān)注！文章轉(zhuǎn)載請(qǐng)注明出處。
發(fā)布評(píng)論請(qǐng)先 登錄
相關(guān)推薦
數(shù)據(jù)庫(kù)廠商都怕低價(jià)競(jìng)爭(zhēng)？阿里云說(shuō)并不可懼
，我們來(lái)看看云原生數(shù)據(jù)庫(kù)由內(nèi)而外有哪些具體的與眾不同?經(jīng)過(guò)優(yōu)化的計(jì)算和存儲(chǔ)引擎使得POLARDB讀性能可達(dá)百萬(wàn)QPS，寫(xiě)性能超過(guò)13萬(wàn)QPS;采用計(jì)
發(fā)表于 05-11 11:02
最新國(guó)產(chǎn)數(shù)據(jù)庫(kù)排名
最新國(guó)產(chǎn)數(shù)據(jù)庫(kù)排名，本篇文章約14000字，包含如下5部分內(nèi)容：1.開(kāi)篇2.國(guó)產(chǎn)數(shù)據(jù)庫(kù)產(chǎn)品清單，包括產(chǎn)品名稱，產(chǎn)品類別及廠商名稱；3.國(guó)產(chǎn)
發(fā)表于 07-28 08:06
數(shù)據(jù)庫(kù)性能評(píng)測(cè)指標(biāo)及其測(cè)試方法
近些年來(lái)，國(guó)產(chǎn)數(shù)據(jù)庫(kù)得到了快速的發(fā)展，但是針對(duì)其性能的測(cè)試方法和測(cè)試指標(biāo)卻參差不齊。針對(duì)上述問(wèn)題，中國(guó)軟件評(píng)測(cè)中心在大量數(shù)據(jù)庫(kù)測(cè)試的基礎(chǔ)之上，參考國(guó)際
發(fā)表于 03-17 15:22
?79次下載
提高Oracle的數(shù)據(jù)庫(kù)性能
在Oracle數(shù)據(jù)庫(kù)設(shè)計(jì)中長(zhǎng)期受到設(shè)計(jì)人員重視的是如何更好更快地提高Oracle數(shù)據(jù)庫(kù)性能的問(wèn)題。其中對(duì)數(shù)據(jù)庫(kù)表現(xiàn)有較大關(guān)聯(lián)的是兩個(gè)因素，一是執(zhí)行SQL語(yǔ)句的速度問(wèn)題；二是
發(fā)表于 11-11 18:16
?4次下載
分布式數(shù)據(jù)庫(kù)聚合計(jì)算性能優(yōu)化
針對(duì)分布式數(shù)據(jù)庫(kù)在分析應(yīng)用方面的聚合計(jì)算性能較低的問(wèn)題，以MongoDB數(shù)據(jù)庫(kù)為研究實(shí)例，提出了一種基于片鍵和索引的數(shù)據(jù)庫(kù)
發(fā)表于 12-03 11:01
?0次下載
數(shù)據(jù)庫(kù)教程之如何進(jìn)行數(shù)據(jù)庫(kù)設(shè)計(jì)
本文檔的主要內(nèi)容詳細(xì)介紹的是數(shù)據(jù)庫(kù)教程之如何進(jìn)行數(shù)據(jù)庫(kù)設(shè)計(jì)內(nèi)容包括了：1 數(shù)據(jù)庫(kù)設(shè)計(jì)概述 ，2 數(shù)據(jù)庫(kù)需求分析 ，3 數(shù)據(jù)庫(kù)結(jié)構(gòu)設(shè)計(jì) ，4
發(fā)表于 10-19 10:41
?21次下載
Serverless 解惑—函數(shù)計(jì)算如何訪問(wèn) MySQL 數(shù)據(jù)庫(kù)
任務(wù)，并提供日志查詢、性能監(jiān)控和報(bào)警等功能。借助函數(shù)計(jì)算，您可以快速構(gòu)建任何類型的應(yīng)用和服務(wù)，并且只需為任務(wù)實(shí)際消耗的資源付費(fèi)。 訪問(wèn) MySQL 數(shù)據(jù)庫(kù)是指在函數(shù)計(jì)算中通過(guò)編寫(xiě)代碼調(diào)
發(fā)表于 03-09 16:52
?742次閱讀
國(guó)產(chǎn)數(shù)據(jù)庫(kù)真的迎來(lái)轉(zhuǎn)折點(diǎn)了嗎？
下一步，永遠(yuǎn)比這一步更難。 數(shù)據(jù)庫(kù)與操作系統(tǒng)、中間件是計(jì)算機(jī)基礎(chǔ)的三大軟件。 “缺芯少魂”之痛常讓人為國(guó)產(chǎn)操作系統(tǒng)的不足捏一把汗，而數(shù)據(jù)庫(kù)卻更像藏在水面之下的冰山，甚少有人關(guān)注?，F(xiàn)在，
華為云數(shù)據(jù)庫(kù)\-GaussDB for MySQL數(shù)據(jù)庫(kù)
華為云更可靠，技術(shù)強(qiáng)、創(chuàng)新快、資源多的特點(diǎn)。華為云采用了最新的DFV分布式存儲(chǔ)技術(shù)，架構(gòu)方面使用了計(jì)算存儲(chǔ)分離架構(gòu)，存儲(chǔ)還最高支持128TB的海量存儲(chǔ)，可以實(shí)現(xiàn)超百萬(wàn)級(jí)QPS吞吐，還支持跨AZ部署，故障秒級(jí)切換，既擁有商業(yè)數(shù)據(jù)庫(kù)的性能
國(guó)產(chǎn)自研數(shù)據(jù)庫(kù)是更新?lián)Q代首選
了極為重要的轉(zhuǎn)型升級(jí)。特別是在自主創(chuàng)新的時(shí)代背景下，國(guó)產(chǎn)數(shù)據(jù)庫(kù)的快速崛起更是令人側(cè)目。那么作為國(guó)產(chǎn)數(shù)據(jù)庫(kù)的代表之一，華為云數(shù)據(jù)庫(kù)對(duì)此有著怎樣
數(shù)據(jù)庫(kù)建立|數(shù)據(jù)庫(kù)創(chuàng)建的方法？
數(shù)據(jù)庫(kù)是一個(gè)存儲(chǔ)關(guān)鍵數(shù)據(jù)的文件系統(tǒng)。利用數(shù)據(jù)庫(kù)管理系統(tǒng)建立每個(gè)人的數(shù)據(jù)庫(kù)可以更好地提供安全。 數(shù)據(jù)庫(kù)建立|
python讀取數(shù)據(jù)庫(kù)數(shù)據(jù) python查詢數(shù)據(jù)庫(kù) python數(shù)據(jù)庫(kù)連接
python讀取數(shù)據(jù)庫(kù)數(shù)據(jù) python查詢數(shù)據(jù)庫(kù) python數(shù)據(jù)庫(kù)連接 Python是一門(mén)高級(jí)編程語(yǔ)言，廣泛應(yīng)用于各種領(lǐng)域。其中，Python在
數(shù)據(jù)庫(kù)應(yīng)用及其特點(diǎn) 數(shù)據(jù)庫(kù)數(shù)據(jù)的基本特點(diǎn)
數(shù)據(jù)庫(kù)應(yīng)用及其特點(diǎn) 數(shù)據(jù)庫(kù)數(shù)據(jù)的基本特點(diǎn)? 數(shù)據(jù)庫(kù)應(yīng)用及其特點(diǎn) 隨著計(jì)算機(jī)技術(shù)的不斷發(fā)展和普及，數(shù)據(jù)
星火夜話，論道國(guó)產(chǎn)數(shù)據(jù)庫(kù)
”活動(dòng)，希望能夠傳承薩師煊先生研究中國(guó)數(shù)據(jù)庫(kù)之初心，共話國(guó)產(chǎn)數(shù)據(jù)庫(kù)技術(shù)創(chuàng)新，共釋填補(bǔ)福建省基礎(chǔ)軟件領(lǐng)域空白的技術(shù)路線，共謀福建省信創(chuàng)新質(zhì)生產(chǎn)力發(fā)展之道，照亮我國(guó)數(shù)據(jù)庫(kù)技術(shù)、產(chǎn)業(yè)傳承奮進(jìn)
云數(shù)據(jù)庫(kù)是哪種數(shù)據(jù)庫(kù)類型？
云數(shù)據(jù)庫(kù)是一種部署在虛擬計(jì)算環(huán)境中的數(shù)據(jù)庫(kù)，它融合了云計(jì)算的彈性和可擴(kuò)展性，為用戶提供高效、靈活的數(shù)據(jù)庫(kù)服務(wù)。云
工商網(wǎng)監(jiān)
評(píng)論