結(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ù)。不過，數(shù)據(jù)光存儲(chǔ)還不行，只有利用起來才能產(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)過程中產(chǎn)生的業(yè)務(wù)數(shù)據(jù)，可以說是企業(yè)的核心，以往在沒有大數(shù)據(jù)平臺(tái)的時(shí)候企業(yè)主要或全部在使用的就是這部分?jǐn)?shù)據(jù)。隨著業(yè)務(wù)的不斷積累，這部分?jǐn)?shù)據(jù)也越來越大，傳統(tǒng)數(shù)據(jù)庫方案面臨很大挑戰(zhàn)，建設(shè)大數(shù)據(jù)平臺(tái)自然要解決這部分核心數(shù)據(jù)分析問題。
有了大數(shù)據(jù)平臺(tái)，給大家的想象空間也大了起來，以往無法利用的日志、圖片、音視頻等非結(jié)構(gòu)化數(shù)據(jù)也要產(chǎn)生價(jià)值，這就涉及到非結(jié)構(gòu)化數(shù)據(jù)分析了。相對(duì)核心業(yè)務(wù)數(shù)據(jù)分析，非結(jié)構(gòu)化數(shù)據(jù)分析看起來更像是錦上添花。即使如此，非結(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í)間、所屬類別、時(shí)長(zhǎng)、…；有些非結(jié)構(gòu)化數(shù)據(jù)經(jīng)過處理后也會(huì)轉(zhuǎn)變成結(jié)構(gòu)化數(shù)據(jù)，比如網(wǎng)頁日志中拆解出訪問人 IP、訪問時(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ù)庫（SQL）。
SQL 仍是目前最廣泛的結(jié)構(gòu)化數(shù)據(jù)計(jì)算技術(shù)
回歸 SQL 卻是當(dāng)前大數(shù)據(jù)計(jì)算語法的一個(gè)發(fā)展傾向。在 Hadoop 體系中，早期的 PIG Latin 已經(jīng)被淘汰，而 Hive 卻一直堅(jiān)挺；Spark 上也在更多地使用 Spark SQL，而 Scala 反而少很多（Scala 易學(xué)難精，作為編譯型語言不支持熱部署也有很多不方便之處）。其它一些新的大數(shù)據(jù)計(jì)算體系一般也將 SQL 作為首選的計(jì)算語法，經(jīng)過幾年時(shí)間的混戰(zhàn)，現(xiàn)在 SQL 又逐步拿回了主動(dòng)權(quán)。
這個(gè)現(xiàn)象，大概有這么兩個(gè)原因：
1. 實(shí)在沒什么別的好用
關(guān)系數(shù)據(jù)庫過于普及，程序員對(duì) SQL 相當(dāng)熟悉，甚至思維習(xí)慣都是 SQL 式的。SQL 用來做一些常規(guī)查詢也比較簡(jiǎn)單，雖然用于處理復(fù)雜的過程計(jì)算或有序運(yùn)算并不方便，但其它那些替代技術(shù)也好不到哪里去，碰到 SQL 難寫的運(yùn)算一樣要寫和 UDF 相當(dāng)?shù)膹?fù)雜代碼，反正都是麻煩，還不如繼續(xù)用 SQL。
2. 大數(shù)據(jù)廠商的鼎力支持
大數(shù)據(jù)的技術(shù)本質(zhì)是高性能，而 SQL 是性能比拼的關(guān)鍵陣地。比性能要面對(duì)同樣的運(yùn)算才有意義，過于專門和復(fù)雜的運(yùn)算涉及的影響因素太多，不容易評(píng)估出大數(shù)據(jù)平臺(tái)本身的能力。而 SQL 有國(guó)際標(biāo)準(zhǔn)的 TPC 系列，所有用戶都看得懂，這樣就有明確的可比性，廠商也會(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ù)庫也是 SQL 語法的，這樣兼容性會(huì)很好，移植成本相對(duì)較低。
好了，我們說完大數(shù)據(jù)平臺(tái)為什么會(huì)回歸關(guān)系數(shù)據(jù)模型了。那么繼續(xù)使用關(guān)系數(shù)據(jù)模型（SQL）會(huì)存在哪些問題呢？
問題
性能低
繼續(xù)使用 SQL 的最大問題就是難以獲得大數(shù)據(jù)計(jì)算最需要的高性能。
SQL 中缺乏一些必要的數(shù)據(jù)類型和運(yùn)算定義，這使得某些高性能算法無法描述，只能寄希望于計(jì)算引擎在工程上的優(yōu)化。傳統(tǒng)商業(yè)數(shù)據(jù)庫經(jīng)過幾十年的發(fā)展，優(yōu)化經(jīng)驗(yàn)已經(jīng)相當(dāng)豐富，但即使這樣仍有許多場(chǎng)景難以被優(yōu)化，理論層面的問題確實(shí)很難在工程層面解決。而新興的大數(shù)據(jù)平臺(tái)在優(yōu)化方面的經(jīng)驗(yàn)還遠(yuǎn)遠(yuǎn)不如傳統(tǒng)數(shù)據(jù)庫，算法上不占優(yōu)，就只能靠集群更多的機(jī)器獲得性能提升。另外，SQL 描述過程的能力不太好，不擅長(zhǎng)指定執(zhí)行路徑，而想獲得高性能常常需要專門優(yōu)化的執(zhí)行路徑，這又需要增加許多特殊的修飾符來人為干預(yù)，那還不如直接用過程性語法更為直接，這也會(huì)妨礙用 SQL 寫出高性能的代碼。
SQL 發(fā)明之初的計(jì)算機(jī)硬件能力還比較差，要保證實(shí)用性，SQL 的設(shè)計(jì)必須適應(yīng)當(dāng)時(shí)的硬件條件，這就導(dǎo)致了 SQL 很難充分利用當(dāng)代計(jì)算機(jī)的硬件能力，具體來說就是大內(nèi)存、并行和集群。SQL 中的 JOIN 是按鍵值對(duì)應(yīng)的，而大內(nèi)存情況下其實(shí)可以直接用地址對(duì)應(yīng)，不需要計(jì)算 HASH 值和比對(duì)，性能可以提高很多；SQL 的數(shù)據(jù)表無序，單表計(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)單地定義為笛卡爾積后過濾，要實(shí)現(xiàn)大表 JOIN 就會(huì)不可避免地產(chǎn)生占用大量網(wǎng)絡(luò)資源的 HASH Shuffle 動(dòng)作，在集群節(jié)點(diǎn)數(shù)太多時(shí)，網(wǎng)絡(luò)傳輸造成的延遲會(huì)超過節(jié)點(diǎn)多帶來的好處。
舉個(gè)具體的例子，我們想在 1 億條數(shù)據(jù)中取出前 10 名，用 SQL 寫出來是這樣的：
select top 10 x,y from T order by x desc
這個(gè)語句中有個(gè) order by，嚴(yán)格按它執(zhí)行就會(huì)涉及大排序，而排序非常慢。其實(shí)我們可以想出一個(gè)不用大排序的算法，但用 SQL 卻無法描述，只能指望數(shù)據(jù)庫優(yōu)化器了。對(duì)于這句 SQL 描述的簡(jiǎn)單情況，很多商用數(shù)據(jù)庫確實(shí)都能優(yōu)化，使用不必大排序的算法，性能通常很好。但情況復(fù)雜一些，比如在每個(gè)分組中取前 10 名，要用窗口函數(shù)和子查詢把 SQL 寫成這樣：
select * from (select y,*,row_number() over (partition by y order by x desc) rn from T)where rn<=10
這時(shí)候，數(shù)據(jù)庫優(yōu)化器就會(huì)犯暈了，猜不出這句 SQL 的目的，只能老老實(shí)實(shí)地執(zhí)行排序的邏輯（這個(gè)語句中還是有 order by 的字樣），結(jié)果性能陡降。
開發(fā)效率低
不僅跑的慢，開發(fā)效率也不高，尤其在復(fù)雜計(jì)算方面，SQL 實(shí)現(xiàn)很繁瑣。比如根據(jù)股票記錄查詢某只股票最長(zhǎng)連續(xù)上漲天數(shù)，SQL（oracle）的寫法如下：
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)，別說寫出來，看懂都要半天。
此外，SQL 也很難實(shí)現(xiàn)過程計(jì)算。什么是過程性計(jì)算呢？就是一步寫不出來，需要多次分步運(yùn)算，特別是與數(shù)據(jù)次序相關(guān)的運(yùn)算。
我們舉幾個(gè)例子來看：
一周內(nèi)累計(jì)登錄時(shí)長(zhǎng)超過一小時(shí)的用戶占比，但要除去登錄時(shí)長(zhǎng)小于 10 秒的誤操作情況
信用卡在最近三個(gè)月內(nèi)最長(zhǎng)連續(xù)消費(fèi)的天數(shù)分布情況，考慮實(shí)施連續(xù)消費(fèi) 10 天后積分三倍的促銷活動(dòng)
一個(gè)月中有多少用戶在 24 小時(shí)連續(xù)操作了查看商品后加入購物車并購買的的動(dòng)作，有多少用戶在中間步驟中放棄？
……
（為了便于理解，這些例子已經(jīng)做了簡(jiǎn)化，實(shí)際情況的運(yùn)算還要復(fù)雜很多）
這類過程性運(yùn)算，用 SQL 寫出來的難度就很大，經(jīng)常還要寫 UDF 才能完成。如果 SQL 寫都寫不出來，那么 SQL 的使用效果將大打折扣。
開發(fā)效率低導(dǎo)致性能低
復(fù)雜 SQL 的執(zhí)行效率往往也很低，這就又回到性能的問題了，實(shí)際上開發(fā)效率和計(jì)算性能是密切相關(guān)的，很多性能問題本質(zhì)上是開發(fā)效率造成。
復(fù)雜 SQL 的優(yōu)化效果很差，在嵌套幾層之后，數(shù)據(jù)庫引擎也會(huì)暈掉，不知道如何優(yōu)化。提高這類復(fù)雜運(yùn)算的性能，指望計(jì)算平臺(tái)的自動(dòng)優(yōu)化就靠不住了，根本手段還要靠寫出高性能的算法。象過程式運(yùn)算中還常常需要保存中間結(jié)果以復(fù)用，SQL 需要用臨時(shí)表，多了 IO 操作就會(huì)影響性能，這都不是引擎優(yōu)化能解決的事情，必須要去改寫計(jì)算過程。
所以，本質(zhì)上，提高性能還是降低開發(fā)難度。軟件無法提高硬件的性能，只能想辦法設(shè)計(jì)復(fù)雜度更低的算法，而如果能夠快速低成本地實(shí)現(xiàn)這些算法，那就可以達(dá)到提高性能的目標(biāo)。如果語法體系難以甚至沒辦法描述高性能算法，必須迫使程序員采用復(fù)雜度較高的算法，那也就很難再提高性能了。優(yōu)化 SQL 運(yùn)算無助于降低它的開發(fā)難度，SQL 語法體系就是那樣，無論怎樣優(yōu)化它的性能，開發(fā)難度并不會(huì)改變，很多高性能算法仍然實(shí)現(xiàn)不了，也就難以實(shí)質(zhì)性地提高運(yùn)算性能。
編寫 UDF 在許多場(chǎng)景時(shí)確實(shí)能提高性能，但一方面開發(fā)難度很大，另一方面這是程序員硬寫的，也不能利用到 SQL 引擎的優(yōu)化能力。而且經(jīng)常并不能將完整運(yùn)算都寫成 UDF，只能使用計(jì)算平臺(tái)提供的接口，仍然要在 SQL 框架使用它的數(shù)據(jù)類型，這樣還是會(huì)限制高性能算法的實(shí)現(xiàn)。
根本的解決方法，還是要讓大數(shù)據(jù)平臺(tái)真地有一些更好用的語法。
解法
使用開源集算器 SPL 就可以作為 SQL 很好的替代和延伸，作為大數(shù)據(jù)平臺(tái)專用的計(jì)算語言，延續(xù) SQL 優(yōu)點(diǎn)的同時(shí)改善其缺點(diǎn)。
SPL 是一款專業(yè)的開源數(shù)據(jù)計(jì)算引擎，提供了獨(dú)立的計(jì)算語法，整個(gè)體系不依賴關(guān)系數(shù)據(jù)模型，因此在很多方面都有長(zhǎng)足突破，尤其在開發(fā)效率和計(jì)算性能方面。下面來盤點(diǎn)一下 SPL 都有哪些特性適用于當(dāng)代大數(shù)據(jù)平臺(tái)。
強(qiáng)集成性
首先是集成性，不管 SPL 多優(yōu)秀，如果與大數(shù)據(jù)平臺(tái)無法結(jié)合使用也是白費(fèi)。要在大數(shù)據(jù)平臺(tái)中使用 SPL 其實(shí)很方便，引入 jar 包就可以使用（本身也是開源的，想怎么用就怎么用）。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();…
高效開發(fā)
敏捷語法
在結(jié)構(gòu)化數(shù)據(jù)計(jì)算方面，SPL 提供了獨(dú)立的計(jì)算語法和豐富的計(jì)算類庫，同時(shí)支持過程計(jì)算使得復(fù)雜計(jì)算實(shí)現(xiàn)也很簡(jiǎn)單。前面舉的計(jì)算股票最長(zhǎng)連漲天數(shù)的例子，用 SPL 實(shí)現(xiàn)是這樣的：
A | |
1 | =db.query(“select * from stock order by day”) |
2 | =A1.group@i(price<price[-1]).max(~.len())-1 |
按交易日排好序，將連漲的記錄分到一組，然后求最大值 -1 就是最長(zhǎng)連續(xù)上漲天數(shù)了，完全按照自然思維實(shí)現(xiàn)，不用繞來繞去，比 SQL 簡(jiǎn)單不少。
再比如根據(jù)用戶登錄記錄列出每個(gè)用戶最近一次登錄間隔：
A | ||
1 | =ulogin.groups(uid;top(2,-logtime)) | 最后2個(gè)登錄記錄 |
2 | =A1.new(uid,#2(1).logtime-#2(2).logtime:interval) | 計(jì)算間隔 |
支持分步的 SPL 語法完成過程計(jì)算很方便。
SPL 提供了豐富的計(jì)算類庫，可以更進(jìn)一步簡(jiǎn)化運(yùn)算。
直觀易用開發(fā)環(huán)境
同時(shí)，SPL 還提供了簡(jiǎn)潔易用的開發(fā)環(huán)境，單步執(zhí)行、設(shè)置斷點(diǎn)，所見即所得的結(jié)果預(yù)覽窗口…，開發(fā)效率也更高。
多數(shù)據(jù)源支持
SPL 還提供了多樣性數(shù)據(jù)源支持，多種數(shù)據(jù)源可以直接使用，相比大數(shù)據(jù)平臺(tái)需要數(shù)據(jù)先“入庫”才能計(jì)算，SPL 的體系更加開放。
SPL 支持的部分?jǐn)?shù)據(jù)源（仍在擴(kuò)展中…）
不僅如此，SPL 還支持多種數(shù)據(jù)源混合計(jì)算，充分發(fā)揮各類數(shù)據(jù)源自身的優(yōu)勢(shì)，擴(kuò)展大數(shù)據(jù)平臺(tái)的開放性。同時(shí)，直接使用多種數(shù)據(jù)源開發(fā)實(shí)現(xiàn)上也更簡(jiǎn)單，進(jìn)一步提升開發(fā)效率。
熱切換
SPL 是解釋執(zhí)行的，天然支持熱切換，這對(duì) Java 體系下的大數(shù)據(jù)平臺(tái)是重大利好。基于 SPL 的大數(shù)據(jù)計(jì)算邏輯編寫、修改和運(yùn)維都不需要重啟，實(shí)時(shí)生效，開發(fā)運(yùn)維更加便捷。
高計(jì)算性能
前面我們說過，高性能與高開發(fā)效率本質(zhì)上是一回事，基于 SPL 的簡(jiǎn)潔語法更容易寫出高性能算法。同時(shí)，SPL 還提供了眾多高性能數(shù)據(jù)存儲(chǔ)和高性能算法機(jī)制，SQL 中很難實(shí)現(xiàn)的高性能算法及存儲(chǔ)方案用 SPL 卻可以輕松實(shí)現(xiàn)，而軟件提高性能關(guān)鍵就在于算法和存儲(chǔ)。
例如前面說過的 TopN 運(yùn)算，在 SPL 中 TopN 被理解為聚合運(yùn)算，這樣可以將高復(fù)雜度的排序轉(zhuǎn)換成低復(fù)雜度的聚合運(yùn)算，而且很還能擴(kuò)展應(yīng)用范圍。
A | ||
1 | =file(“data.ctx”).create().cursor() | |
2 | =A1.groups(;top(10,amount)) | 金額在前 10 名的訂單 |
3 | =A1.groups(area;top(10,amount)) | 每個(gè)地區(qū)金額在前 10 名的訂單 |
這里的語句中沒有排序字樣，也不會(huì)產(chǎn)生大排序的動(dòng)作，在全集還是分組中計(jì)算 TopN 的語法基本一致，而且都會(huì)有較高的性能。
