結(jié)構(gòu)化數(shù)據(jù)計(jì)算仍是重中之重

大數(shù)據(jù)平臺(tái)主要是為了應(yīng)對(duì)海量數(shù)據(jù)存儲(chǔ)和分析的需求，海量數(shù)據(jù)存儲(chǔ)的確不假，除了生產(chǎn)經(jīng)營(yíng)產(chǎn)生的結(jié)構(gòu)化數(shù)據(jù)，還有大量音視頻等非結(jié)構(gòu)化數(shù)據(jù)，這部分?jǐn)?shù)據(jù)很大，占用的空間也很多，有時(shí)大數(shù)據(jù)平臺(tái) 80% 以上都存儲(chǔ)著非結(jié)構(gòu)化數(shù)據(jù)。不過(guò)，數(shù)據(jù)光存儲(chǔ)還不行，只有利用起來(lái)才能產(chǎn)生價(jià)值，這就要進(jìn)行分析了。

大數(shù)據(jù)分析要分結(jié)構(gòu)化和非結(jié)構(gòu)化數(shù)據(jù)兩部分討論。

結(jié)構(gòu)化數(shù)據(jù)主要是企業(yè)生產(chǎn)經(jīng)營(yíng)過(guò)程中產(chǎn)生的業(yè)務(wù)數(shù)據(jù)，可以說(shuō)是企業(yè)的核心，以往在沒(méi)有大數(shù)據(jù)平臺(tái)的時(shí)候企業(yè)主要或全部在使用的就是這部分?jǐn)?shù)據(jù)。隨著業(yè)務(wù)的不斷積累，這部分?jǐn)?shù)據(jù)也越來(lái)越大，傳統(tǒng)數(shù)據(jù)庫(kù)方案面臨很大挑戰(zhàn)，建設(shè)大數(shù)據(jù)平臺(tái)自然要解決這部分核心數(shù)據(jù)分析問(wèn)題。

有了大數(shù)據(jù)平臺(tái)，給大家的想象空間也大了起來(lái)，以往無(wú)法利用的日志、圖片、音視頻等非結(jié)構(gòu)化數(shù)據(jù)也要產(chǎn)生價(jià)值，這就涉及到非結(jié)構(gòu)化數(shù)據(jù)分析了。相對(duì)核心業(yè)務(wù)數(shù)據(jù)分析，非結(jié)構(gòu)化數(shù)據(jù)分析看起來(lái)更像是錦上添花。即使如此，非結(jié)構(gòu)化數(shù)據(jù)分析并不是孤立存在，也還會(huì)伴隨大量結(jié)構(gòu)化數(shù)據(jù)處理。采集非結(jié)構(gòu)化數(shù)據(jù)的同時(shí)，常常會(huì)伴隨著采集許多相關(guān)的結(jié)構(gòu)化數(shù)據(jù)，比如音視頻的制作人、制作時(shí)間、所屬類(lèi)別、時(shí)長(zhǎng)、…；有些非結(jié)構(gòu)化數(shù)據(jù)經(jīng)過(guò)處理后也會(huì)轉(zhuǎn)變成結(jié)構(gòu)化數(shù)據(jù)，比如網(wǎng)頁(yè)日志中拆解出訪(fǎng)問(wèn)人 IP、訪(fǎng)問(wèn)時(shí)刻、關(guān)鍵搜索詞等。所謂的非結(jié)構(gòu)化數(shù)據(jù)分析，經(jīng)常實(shí)際上是針對(duì)這些伴生而出的結(jié)構(gòu)化數(shù)據(jù)。

結(jié)構(gòu)化數(shù)據(jù)分析仍然是大數(shù)據(jù)平臺(tái)的重中之重。而結(jié)構(gòu)化數(shù)據(jù)處理技術(shù)就比較成熟了，比如我們常用的基于關(guān)系數(shù)據(jù)模型的關(guān)系數(shù)據(jù)庫(kù)（SQL）。

SQL 仍是目前最廣泛的結(jié)構(gòu)化數(shù)據(jù)計(jì)算技術(shù)

回歸 SQL 卻是當(dāng)前大數(shù)據(jù)計(jì)算語(yǔ)法的一個(gè)發(fā)展傾向。在 Hadoop 體系中，早期的 PIG Latin 已經(jīng)被淘汰，而 Hive 卻一直堅(jiān)挺；Spark 上也在更多地使用 Spark SQL，而 Scala 反而少很多（Scala 易學(xué)難精，作為編譯型語(yǔ)言不支持熱部署也有很多不方便之處）。其它一些新的大數(shù)據(jù)計(jì)算體系一般也將 SQL 作為首選的計(jì)算語(yǔ)法，經(jīng)過(guò)幾年時(shí)間的混戰(zhàn)，現(xiàn)在 SQL 又逐步拿回了主動(dòng)權(quán)。

這個(gè)現(xiàn)象，大概有這么兩個(gè)原因：

1. 實(shí)在沒(méi)什么別的好用

關(guān)系數(shù)據(jù)庫(kù)過(guò)于普及，程序員對(duì) SQL 相當(dāng)熟悉，甚至思維習(xí)慣都是 SQL 式的。SQL 用來(lái)做一些常規(guī)查詢(xún)也比較簡(jiǎn)單，雖然用于處理復(fù)雜的過(guò)程計(jì)算或有序運(yùn)算并不方便，但其它那些替代技術(shù)也好不到哪里去，碰到 SQL 難寫(xiě)的運(yùn)算一樣要寫(xiě)和 UDF 相當(dāng)?shù)膹?fù)雜代碼，反正都是麻煩，還不如繼續(xù)用 SQL。

2. 大數(shù)據(jù)廠商的鼎力支持

大數(shù)據(jù)的技術(shù)本質(zhì)是高性能，而 SQL 是性能比拼的關(guān)鍵陣地。比性能要面對(duì)同樣的運(yùn)算才有意義，過(guò)于專(zhuān)門(mén)和復(fù)雜的運(yùn)算涉及的影響因素太多，不容易評(píng)估出大數(shù)據(jù)平臺(tái)本身的能力。而 SQL 有國(guó)際標(biāo)準(zhǔn)的 TPC 系列，所有用戶(hù)都看得懂，這樣就有明確的可比性，廠商也會(huì)把性能優(yōu)化的重點(diǎn)放在 SQL 上。

兼容 SQL 更利于移植

大數(shù)據(jù)平臺(tái)兼容 SQL 的好處是很明顯的，SQL 的應(yīng)用非常廣泛，會(huì) SQL 的程序員很多，如果繼續(xù)采用 SQL 則可以避免許多學(xué)習(xí)成本。支持 SQL 的前端軟件也很多，使用 SQL 的大數(shù)據(jù)平臺(tái)很容易融入這個(gè)現(xiàn)成的生態(tài)圈中。大數(shù)據(jù)平臺(tái)打算替代的傳統(tǒng)數(shù)據(jù)庫(kù)也是 SQL 語(yǔ)法的，這樣兼容性會(huì)很好，移植成本相對(duì)較低。

好了，我們說(shuō)完大數(shù)據(jù)平臺(tái)為什么會(huì)回歸關(guān)系數(shù)據(jù)模型了。那么繼續(xù)使用關(guān)系數(shù)據(jù)模型（SQL）會(huì)存在哪些問(wèn)題呢？

問(wèn)題

性能低

繼續(xù)使用 SQL 的最大問(wèn)題就是難以獲得大數(shù)據(jù)計(jì)算最需要的高性能。

SQL 中缺乏一些必要的數(shù)據(jù)類(lèi)型和運(yùn)算定義，這使得某些高性能算法無(wú)法描述，只能寄希望于計(jì)算引擎在工程上的優(yōu)化。傳統(tǒng)商業(yè)數(shù)據(jù)庫(kù)經(jīng)過(guò)幾十年的發(fā)展，優(yōu)化經(jīng)驗(yàn)已經(jīng)相當(dāng)豐富，但即使這樣仍有許多場(chǎng)景難以被優(yōu)化，理論層面的問(wèn)題確實(shí)很難在工程層面解決。而新興的大數(shù)據(jù)平臺(tái)在優(yōu)化方面的經(jīng)驗(yàn)還遠(yuǎn)遠(yuǎn)不如傳統(tǒng)數(shù)據(jù)庫(kù)，算法上不占優(yōu)，就只能靠集群更多的機(jī)器獲得性能提升。另外，SQL 描述過(guò)程的能力不太好，不擅長(zhǎng)指定執(zhí)行路徑，而想獲得高性能常常需要專(zhuān)門(mén)優(yōu)化的執(zhí)行路徑，這又需要增加許多特殊的修飾符來(lái)人為干預(yù)，那還不如直接用過(guò)程性語(yǔ)法更為直接，這也會(huì)妨礙用 SQL 寫(xiě)出高性能的代碼。

SQL 發(fā)明之初的計(jì)算機(jī)硬件能力還比較差，要保證實(shí)用性，SQL 的設(shè)計(jì)必須適應(yīng)當(dāng)時(shí)的硬件條件，這就導(dǎo)致了 SQL 很難充分利用當(dāng)代計(jì)算機(jī)的硬件能力，具體來(lái)說(shuō)就是大內(nèi)存、并行和集群。SQL 中的 JOIN 是按鍵值對(duì)應(yīng)的，而大內(nèi)存情況下其實(shí)可以直接用地址對(duì)應(yīng)，不需要計(jì)算 HASH 值和比對(duì)，性能可以提高很多；SQL 的數(shù)據(jù)表無(wú)序，單表計(jì)算時(shí)還容易做到分段并行，多表關(guān)聯(lián)運(yùn)算時(shí)一般就只能事先做好固定分段，很難做到同步動(dòng)態(tài)分段，這就難以根據(jù)機(jī)器的負(fù)載臨時(shí)決定并行數(shù)量；對(duì)于集群運(yùn)算也是這樣，SQL 在理論上不區(qū)分維表和事實(shí)表，JOIN 運(yùn)算簡(jiǎn)單地定義為笛卡爾積后過(guò)濾，要實(shí)現(xiàn)大表 JOIN 就會(huì)不可避免地產(chǎn)生占用大量網(wǎng)絡(luò)資源的 HASH Shuffle 動(dòng)作，在集群節(jié)點(diǎn)數(shù)太多時(shí)，網(wǎng)絡(luò)傳輸造成的延遲會(huì)超過(guò)節(jié)點(diǎn)多帶來(lái)的好處。

舉個(gè)具體的例子，我們想在 1 億條數(shù)據(jù)中取出前 10 名，用 SQL 寫(xiě)出來(lái)是這樣的：

select top 10 x,y from T order by x desc

這個(gè)語(yǔ)句中有個(gè) order by，嚴(yán)格按它執(zhí)行就會(huì)涉及大排序，而排序非常慢。其實(shí)我們可以想出一個(gè)不用大排序的算法，但用 SQL 卻無(wú)法描述，只能指望數(shù)據(jù)庫(kù)優(yōu)化器了。對(duì)于這句 SQL 描述的簡(jiǎn)單情況，很多商用數(shù)據(jù)庫(kù)確實(shí)都能優(yōu)化，使用不必大排序的算法，性能通常很好。但情況復(fù)雜一些，比如在每個(gè)分組中取前 10 名，要用窗口函數(shù)和子查詢(xún)把 SQL 寫(xiě)成這樣：

select * from (select y,*,row_number() over (partition by y order by x desc) rn from T)where rn<=10

這時(shí)候，數(shù)據(jù)庫(kù)優(yōu)化器就會(huì)犯暈了，猜不出這句 SQL 的目的，只能老老實(shí)實(shí)地執(zhí)行排序的邏輯（這個(gè)語(yǔ)句中還是有 order by 的字樣），結(jié)果性能陡降。

開(kāi)發(fā)效率低

不僅跑的慢，開(kāi)發(fā)效率也不高，尤其在復(fù)雜計(jì)算方面，SQL 實(shí)現(xiàn)很繁瑣。比如根據(jù)股票記錄查詢(xún)某只股票最長(zhǎng)連續(xù)上漲天數(shù)，SQL（oracle）的寫(xiě)法如下：

SELECT MAX(ContinuousDays)-1 FROM ( SELECT code, NoRisingDays, COUNT(*) ContinuousDays FROM ( SELECT code, SUM(RisingFlag) OVER (PARTITION BY code ORDER BY day) NoRisingDays FROM ( SELECT code, day, CASE WHEN price> LAG(price) OVER (PARTITION BY code ORDER BY day) THEN 0 ELSE 1 END RisingFlag FROM stock ) ) GROUP BY NoRisingDays )

用了很繞的方式實(shí)現(xiàn)，別說(shuō)寫(xiě)出來(lái)，看懂都要半天。

此外，SQL 也很難實(shí)現(xiàn)過(guò)程計(jì)算。什么是過(guò)程性計(jì)算呢？就是一步寫(xiě)不出來(lái)，需要多次分步運(yùn)算，特別是與數(shù)據(jù)次序相關(guān)的運(yùn)算。

我們舉幾個(gè)例子來(lái)看：

一周內(nèi)累計(jì)登錄時(shí)長(zhǎng)超過(guò)一小時(shí)的用戶(hù)占比，但要除去登錄時(shí)長(zhǎng)小于 10 秒的誤操作情況

信用卡在最近三個(gè)月內(nèi)最長(zhǎng)連續(xù)消費(fèi)的天數(shù)分布情況，考慮實(shí)施連續(xù)消費(fèi) 10 天后積分三倍的促銷(xiāo)活動(dòng)

一個(gè)月中有多少用戶(hù)在 24 小時(shí)連續(xù)操作了查看商品后加入購(gòu)物車(chē)并購(gòu)買(mǎi)的的動(dòng)作，有多少用戶(hù)在中間步驟中放棄？

……

（為了便于理解，這些例子已經(jīng)做了簡(jiǎn)化，實(shí)際情況的運(yùn)算還要復(fù)雜很多）

這類(lèi)過(guò)程性運(yùn)算，用 SQL 寫(xiě)出來(lái)的難度就很大，經(jīng)常還要寫(xiě) UDF 才能完成。如果 SQL 寫(xiě)都寫(xiě)不出來(lái)，那么 SQL 的使用效果將大打折扣。

開(kāi)發(fā)效率低導(dǎo)致性能低

復(fù)雜 SQL 的執(zhí)行效率往往也很低，這就又回到性能的問(wèn)題了，實(shí)際上開(kāi)發(fā)效率和計(jì)算性能是密切相關(guān)的，很多性能問(wèn)題本質(zhì)上是開(kāi)發(fā)效率造成。

復(fù)雜 SQL 的優(yōu)化效果很差，在嵌套幾層之后，數(shù)據(jù)庫(kù)引擎也會(huì)暈掉，不知道如何優(yōu)化。提高這類(lèi)復(fù)雜運(yùn)算的性能，指望計(jì)算平臺(tái)的自動(dòng)優(yōu)化就靠不住了，根本手段還要靠寫(xiě)出高性能的算法。象過(guò)程式運(yùn)算中還常常需要保存中間結(jié)果以復(fù)用，SQL 需要用臨時(shí)表，多了 IO 操作就會(huì)影響性能，這都不是引擎優(yōu)化能解決的事情，必須要去改寫(xiě)計(jì)算過(guò)程。

所以，本質(zhì)上，提高性能還是降低開(kāi)發(fā)難度。軟件無(wú)法提高硬件的性能，只能想辦法設(shè)計(jì)復(fù)雜度更低的算法，而如果能夠快速低成本地實(shí)現(xiàn)這些算法，那就可以達(dá)到提高性能的目標(biāo)。如果語(yǔ)法體系難以甚至沒(méi)辦法描述高性能算法，必須迫使程序員采用復(fù)雜度較高的算法，那也就很難再提高性能了。優(yōu)化 SQL 運(yùn)算無(wú)助于降低它的開(kāi)發(fā)難度，SQL 語(yǔ)法體系就是那樣，無(wú)論怎樣優(yōu)化它的性能，開(kāi)發(fā)難度并不會(huì)改變，很多高性能算法仍然實(shí)現(xiàn)不了，也就難以實(shí)質(zhì)性地提高運(yùn)算性能。

編寫(xiě) UDF 在許多場(chǎng)景時(shí)確實(shí)能提高性能，但一方面開(kāi)發(fā)難度很大，另一方面這是程序員硬寫(xiě)的，也不能利用到 SQL 引擎的優(yōu)化能力。而且經(jīng)常并不能將完整運(yùn)算都寫(xiě)成 UDF，只能使用計(jì)算平臺(tái)提供的接口，仍然要在 SQL 框架使用它的數(shù)據(jù)類(lèi)型，這樣還是會(huì)限制高性能算法的實(shí)現(xiàn)。

根本的解決方法，還是要讓大數(shù)據(jù)平臺(tái)真地有一些更好用的語(yǔ)法。

解法

使用開(kāi)源集算器 SPL 就可以作為 SQL 很好的替代和延伸，作為大數(shù)據(jù)平臺(tái)專(zhuān)用的計(jì)算語(yǔ)言，延續(xù) SQL 優(yōu)點(diǎn)的同時(shí)改善其缺點(diǎn)。

SPL 是一款專(zhuān)業(yè)的開(kāi)源數(shù)據(jù)計(jì)算引擎，提供了獨(dú)立的計(jì)算語(yǔ)法，整個(gè)體系不依賴(lài)關(guān)系數(shù)據(jù)模型，因此在很多方面都有長(zhǎng)足突破，尤其在開(kāi)發(fā)效率和計(jì)算性能方面。下面來(lái)盤(pán)點(diǎn)一下 SPL 都有哪些特性適用于當(dāng)代大數(shù)據(jù)平臺(tái)。

強(qiáng)集成性

首先是集成性，不管 SPL 多優(yōu)秀，如果與大數(shù)據(jù)平臺(tái)無(wú)法結(jié)合使用也是白費(fèi)。要在大數(shù)據(jù)平臺(tái)中使用 SPL 其實(shí)很方便，引入 jar 包就可以使用（本身也是開(kāi)源的，想怎么用就怎么用）。SPL 提供了標(biāo)準(zhǔn) JDBC 驅(qū)動(dòng)，可以直接執(zhí)行 SPL 腳本，也可以調(diào)用 SPL 腳本文件。

…Class.forName(“com.esproc.jdbc.InternalDriver”);Connection conn =DriverManager.getConnection(“jdbc:esproc:local://”);Statement st = connection.();//直接執(zhí)行SPL腳本//ResultSet rs = st.executeQuery(“=100.new(~:baseNum,~*~:square2)”);//調(diào)用SPL腳本文件CallableStatement st = conn.prepareCall(“{call SplScript(?, ?)}”);st.setObject(1, 3000);st.setObject(2, 5000);ResultSet result=st.execute();…

高效開(kāi)發(fā)

敏捷語(yǔ)法

在結(jié)構(gòu)化數(shù)據(jù)計(jì)算方面，SPL 提供了獨(dú)立的計(jì)算語(yǔ)法和豐富的計(jì)算類(lèi)庫(kù)，同時(shí)支持過(guò)程計(jì)算使得復(fù)雜計(jì)算實(shí)現(xiàn)也很簡(jiǎn)單。前面舉的計(jì)算股票最長(zhǎng)連漲天數(shù)的例子，用 SPL 實(shí)現(xiàn)是這樣的：

按交易日排好序，將連漲的記錄分到一組，然后求最大值 -1 就是最長(zhǎng)連續(xù)上漲天數(shù)了，完全按照自然思維實(shí)現(xiàn)，不用繞來(lái)繞去，比 SQL 簡(jiǎn)單不少。

再比如根據(jù)用戶(hù)登錄記錄列出每個(gè)用戶(hù)最近一次登錄間隔：

支持分步的 SPL 語(yǔ)法完成過(guò)程計(jì)算很方便。

SPL 提供了豐富的計(jì)算類(lèi)庫(kù)，可以更進(jìn)一步簡(jiǎn)化運(yùn)算。

直觀易用開(kāi)發(fā)環(huán)境

同時(shí)，SPL 還提供了簡(jiǎn)潔易用的開(kāi)發(fā)環(huán)境，單步執(zhí)行、設(shè)置斷點(diǎn)，所見(jiàn)即所得的結(jié)果預(yù)覽窗口…，開(kāi)發(fā)效率也更高。

多數(shù)據(jù)源支持

SPL 還提供了多樣性數(shù)據(jù)源支持，多種數(shù)據(jù)源可以直接使用，相比大數(shù)據(jù)平臺(tái)需要數(shù)據(jù)先“入庫(kù)”才能計(jì)算，SPL 的體系更加開(kāi)放。

SPL 支持的部分?jǐn)?shù)據(jù)源（仍在擴(kuò)展中…）

不僅如此，SPL 還支持多種數(shù)據(jù)源混合計(jì)算，充分發(fā)揮各類(lèi)數(shù)據(jù)源自身的優(yōu)勢(shì)，擴(kuò)展大數(shù)據(jù)平臺(tái)的開(kāi)放性。同時(shí)，直接使用多種數(shù)據(jù)源開(kāi)發(fā)實(shí)現(xiàn)上也更簡(jiǎn)單，進(jìn)一步提升開(kāi)發(fā)效率。

熱切換

SPL 是解釋執(zhí)行的，天然支持熱切換，這對(duì) Java 體系下的大數(shù)據(jù)平臺(tái)是重大利好?；?SPL 的大數(shù)據(jù)計(jì)算邏輯編寫(xiě)、修改和運(yùn)維都不需要重啟，實(shí)時(shí)生效，開(kāi)發(fā)運(yùn)維更加便捷。

高計(jì)算性能

前面我們說(shuō)過(guò)，高性能與高開(kāi)發(fā)效率本質(zhì)上是一回事，基于 SPL 的簡(jiǎn)潔語(yǔ)法更容易寫(xiě)出高性能算法。同時(shí)，SPL 還提供了眾多高性能數(shù)據(jù)存儲(chǔ)和高性能算法機(jī)制，SQL 中很難實(shí)現(xiàn)的高性能算法及存儲(chǔ)方案用 SPL 卻可以輕松實(shí)現(xiàn)，而軟件提高性能關(guān)鍵就在于算法和存儲(chǔ)。

例如前面說(shuō)過(guò)的 TopN 運(yùn)算，在 SPL 中 TopN 被理解為聚合運(yùn)算，這樣可以將高復(fù)雜度的排序轉(zhuǎn)換成低復(fù)雜度的聚合運(yùn)算，而且很還能擴(kuò)展應(yīng)用范圍。

這里的語(yǔ)句中沒(méi)有排序字樣，也不會(huì)產(chǎn)生大排序的動(dòng)作，在全集還是分組中計(jì)算 TopN 的語(yǔ)法基本一致，而且都會(huì)有較高的性能。