實(shí)時(shí)計(jì)算在推薦領(lǐng)域的應(yīng)用也已經(jīng)很深入了。不論是新聞推薦、音樂推薦還是讀書推薦，基本都已經(jīng)做到了千人千面，每個(gè)人接收到的推送內(nèi)容都是根據(jù)個(gè)人興趣偏好量身定制的。而用戶的興趣偏好，往往是通過實(shí)時(shí)數(shù)據(jù)計(jì)算不斷在更新的。 以新聞推送為例，當(dāng)用戶點(diǎn)擊一條條推送消息時(shí)，背后產(chǎn)品其實(shí)時(shí)刻在對(duì)用戶的行為做實(shí)時(shí)分析，實(shí)時(shí)更新用戶的興趣偏好，不斷發(fā)現(xiàn)用戶新的興趣點(diǎn)，對(duì)用戶越來越了解，最后給用戶推送他更感興趣的內(nèi)容。再以音樂推薦為例，如果一個(gè)用戶某段時(shí)間收藏了幾首悲傷的歌曲，通過實(shí)時(shí)數(shù)據(jù)分析，系統(tǒng)可以識(shí)別出這一信息，同時(shí)有針對(duì)性的推送一些歌曲去撫慰用戶。這種場(chǎng)景是只有實(shí)時(shí)計(jì)算才能解決的，也最能體現(xiàn)實(shí)時(shí)計(jì)算的價(jià)值。

越來越多的實(shí)時(shí)計(jì)算場(chǎng)景會(huì)被開發(fā)出來，未來人們對(duì)“一切都在變化之中”的感受會(huì)越來越深刻。

　　從“先存后算”到“邊算邊存”，實(shí)時(shí)計(jì)算不再怕“大”數(shù)據(jù)

實(shí)時(shí)計(jì)算這么好，在實(shí)現(xiàn)層面應(yīng)該怎么做，有哪些困難和挑戰(zhàn)是必須解決的?

首先從整體架構(gòu)看，數(shù)據(jù)計(jì)算，無外乎三樣?xùn)|西：數(shù)據(jù)輸入→計(jì)算→數(shù)據(jù)輸出。傳統(tǒng)的計(jì)算模型，以數(shù)據(jù)庫為例，是先將數(shù)據(jù)存儲(chǔ)在一個(gè)數(shù)據(jù)表中，用戶通過執(zhí)行查詢語句觸發(fā)數(shù)據(jù)庫的計(jì)算操作，最后數(shù)據(jù)庫完成計(jì)算后輸出結(jié)果。這種“先存后算”的模型在大數(shù)據(jù)實(shí)時(shí)計(jì)算場(chǎng)景下是行不通的。我們所要計(jì)算的數(shù)據(jù)很“大”，一個(gè)計(jì)算結(jié)果所涉及的源數(shù)據(jù)可能是涵蓋過往一天的數(shù)據(jù)，可能是上千億條數(shù)據(jù)記錄。如果每增加一些新數(shù)據(jù)，都把所有數(shù)據(jù)都重新計(jì)算一遍，這樣的開銷是非常大的，最終的效果會(huì)是很“慢”，達(dá)不到實(shí)時(shí)的效果。比較合理的做法是“邊算邊存”，意思是數(shù)據(jù)進(jìn)入實(shí)時(shí)計(jì)算系統(tǒng)后，不一定需要先存儲(chǔ)起來，可以直接參與計(jì)算，而且這里的計(jì)算是把當(dāng)前新增的數(shù)據(jù)在之前歷史數(shù)據(jù)的計(jì)算結(jié)果上做“增量計(jì)算”，同一條數(shù)據(jù)不重復(fù)參與計(jì)算，計(jì)算完成之后，再把計(jì)算結(jié)果保存起來，供業(yè)務(wù)使用，這時(shí)數(shù)據(jù)存儲(chǔ)的壓力也小了很多。同時(shí)“大”意味著數(shù)據(jù)并發(fā)很高，每秒可能需要計(jì)算上千萬條新數(shù)據(jù)，這樣的計(jì)算量不是單機(jī)能承受的，所以大數(shù)據(jù)實(shí)時(shí)計(jì)算要解決好的是分布式系統(tǒng)架構(gòu)下的一系列技術(shù)問題。

分布式實(shí)時(shí)計(jì)算面臨的挑戰(zhàn)包括很多方面。數(shù)據(jù)從采集、到計(jì)算、到輸出整個(gè)過程必須做到低延遲，除了計(jì)算節(jié)點(diǎn)本身采用“增量計(jì)算”的模型，還要求上游數(shù)據(jù)傳輸模塊具有很高的吞吐能力，并且具備數(shù)據(jù)緩存的能力，在大流量場(chǎng)景下可以起到緩沖的作用，下游輸出模塊也需要做數(shù)據(jù)壓縮、批量輸出等優(yōu)化，以保證輸出結(jié)果的實(shí)時(shí)性。低延遲這個(gè)大前提對(duì)實(shí)時(shí)計(jì)算系統(tǒng)的其他特性提出了更高的要求。比如雙11凌晨0點(diǎn)的時(shí)候，大量消費(fèi)者在同一時(shí)刻下單支付，這是涌進(jìn)實(shí)時(shí)計(jì)算系統(tǒng)的瞬時(shí)數(shù)據(jù)量是巨大的，系統(tǒng)需要有強(qiáng)大的并行處理數(shù)據(jù)的能力，將大量瞬時(shí)流量合理分配到成百上千個(gè)計(jì)算節(jié)點(diǎn)，并將這些節(jié)點(diǎn)的計(jì)算結(jié)果匯聚到一起計(jì)算出一個(gè)總體的結(jié)果，在高吞吐的情況下仍保證低延遲。

和低延遲同樣關(guān)鍵的挑戰(zhàn)是準(zhǔn)確性?！霸隽坑?jì)算”模型和傳統(tǒng)“批量計(jì)算”模型是有區(qū)別的，所以不能照搬過往的技術(shù)經(jīng)驗(yàn)，否則就會(huì)有準(zhǔn)確性方面的問題。需要考慮清楚新進(jìn)入的數(shù)據(jù)如何疊加到老的計(jì)算結(jié)果上，有些場(chǎng)景下甚至要支持從老的計(jì)算結(jié)果中撤除部分計(jì)算值，以保證最終結(jié)果的準(zhǔn)確性。

分布式系統(tǒng)中的某個(gè)節(jié)點(diǎn)出現(xiàn)故障是很常見的，實(shí)時(shí)流計(jì)算系統(tǒng)的故障恢復(fù)能力也相當(dāng)重要，因?yàn)楫?dāng)故障發(fā)生時(shí)，系統(tǒng)必須快速恢復(fù)，否則系統(tǒng)的輸出更新可能就停滯了，實(shí)時(shí)性也就無從談起。同時(shí)故障發(fā)生也不能破壞“增量計(jì)算”這個(gè)模型，否則退化到“批量計(jì)算”的模型就又得不到實(shí)時(shí)的計(jì)算結(jié)果了，而且結(jié)果準(zhǔn)確性也難以保證。

事實(shí)上網(wǎng)易大數(shù)據(jù)在實(shí)現(xiàn)自研流計(jì)算平臺(tái)Sloth的過程中，遇到并克服了上述技術(shù)難點(diǎn)。網(wǎng)易流計(jì)算平臺(tái)Sloth作為一個(gè)平臺(tái)化的產(chǎn)品，在產(chǎn)品易用性、多租戶隔離方面做了大量的工作。就實(shí)時(shí)計(jì)算而言，易用性是一個(gè)比較值得討論的方面。

以計(jì)算一篇文章的單詞數(shù)為例，一個(gè)分布式計(jì)算程序的內(nèi)容可能包括三個(gè)部分，首先是用幾個(gè)計(jì)算節(jié)點(diǎn)共同把每一行文本拆分成一個(gè)一個(gè)的單詞;第二步是用另外一些計(jì)算節(jié)點(diǎn)去統(tǒng)計(jì)單詞的個(gè)數(shù)(考慮到數(shù)據(jù)量巨大的情況，這里有必要用多個(gè)節(jié)點(diǎn)去做計(jì)算);第三步是由一個(gè)計(jì)算節(jié)點(diǎn)把上游各各節(jié)點(diǎn)算出的部分計(jì)數(shù)匯聚成一個(gè)總的計(jì)數(shù)。這樣一個(gè)最簡(jiǎn)單的場(chǎng)景，需要開發(fā)的代碼量大約是200行。實(shí)際業(yè)務(wù)場(chǎng)景下，數(shù)據(jù)流經(jīng)的計(jì)算節(jié)點(diǎn)遠(yuǎn)遠(yuǎn)不止3個(gè)，計(jì)算類型也比基礎(chǔ)的求和復(fù)雜很多，所以即使有了流計(jì)算引擎，分布式實(shí)時(shí)計(jì)算程序的開發(fā)仍然是比較困難的。再進(jìn)一步看，即使開發(fā)完成了，還需要把大量的時(shí)間投入到調(diào)試、計(jì)算框架維護(hù)等方面，一旦計(jì)算需求發(fā)生變化，所有的工作都需要重新迭代一遍，這是個(gè)比較痛苦的過程。如何讓流式計(jì)算程序更易編寫，是實(shí)時(shí)計(jì)算平臺(tái)需要去完成的挑戰(zhàn)。

且不考慮實(shí)時(shí)流計(jì)算系統(tǒng)如何解決易用性這個(gè)問題，看下計(jì)算機(jī)科學(xué)發(fā)展過程中，類似問題是怎么解決的。人們希望編程可以容易一些，所以越來越多的高級(jí)編程語言被發(fā)明出來了;人們希望數(shù)據(jù)計(jì)算可以容易一些，然后就有了數(shù)據(jù)庫，以及SQL語言——結(jié)構(gòu)化查詢語言;到了大數(shù)據(jù)時(shí)代，人們還在折騰離線批量計(jì)算的時(shí)候，就遇到的依靠計(jì)算引擎編程復(fù)雜的問題，最終通過把SQL語言應(yīng)用到分布式離線計(jì)算系統(tǒng)上，解決了這個(gè)問題。而現(xiàn)在實(shí)時(shí)計(jì)算的迅速發(fā)展的現(xiàn)在，是否同樣可以用SQL語言去解決這個(gè)問題?答案是肯定的。不過有許多細(xì)節(jié)的問題需要去推敲求證。

　　實(shí)時(shí)流計(jì)算中的數(shù)據(jù)流，可以理解為一張動(dòng)態(tài)的數(shù)據(jù)表

上文提及了離線批量計(jì)算模型和實(shí)時(shí)增量計(jì)算模型是有差異的，當(dāng)SQL語言分別作用與批量計(jì)算和流式計(jì)算時(shí)，其語義也是需要發(fā)生變化的。批量計(jì)算和流式計(jì)算最主要的區(qū)別是前者計(jì)算的數(shù)據(jù)是有限的、后者計(jì)算的數(shù)據(jù)是無限的是不斷采集進(jìn)入系統(tǒng)的。當(dāng)一個(gè)SQL查詢作用在一批離線數(shù)據(jù)上面時(shí)，計(jì)算完成、輸出結(jié)果，這條SQL查詢也就完成了。映射到流式計(jì)算，當(dāng)SQL查詢觸發(fā)計(jì)算，它是不會(huì)結(jié)束的，因?yàn)閿?shù)據(jù)在持續(xù)不斷地流入，按照離線SQL的語義，SQL結(jié)束之前，計(jì)算不會(huì)輸出結(jié)果，這顯然不是流計(jì)算期望的效果，所以流式SQL其本質(zhì)應(yīng)當(dāng)是定義一系列流計(jì)算任務(wù)，同時(shí)這些任務(wù)是邊執(zhí)行邊輸出計(jì)算結(jié)果的。

離線SQL處理的是靜態(tài)數(shù)據(jù)表，而流式SQL處理的是數(shù)據(jù)流，SQL的計(jì)算語義(如求和、平均值、數(shù)據(jù)表連接等)作用在數(shù)據(jù)流上是否合理。理解這個(gè)問題需要做一個(gè)概念上的轉(zhuǎn)換：離線SQL是把靜態(tài)的數(shù)據(jù)表轉(zhuǎn)換成另一張靜態(tài)數(shù)據(jù)表;而實(shí)時(shí)流計(jì)算中的數(shù)據(jù)流，可以理解為一張動(dòng)態(tài)的數(shù)據(jù)表(數(shù)據(jù)會(huì)不斷增長(zhǎng)的動(dòng)態(tài)數(shù)據(jù)表)。不同的時(shí)刻這個(gè)數(shù)據(jù)表又不同的樣子，執(zhí)行SQL會(huì)得到不同的計(jì)算結(jié)果，把這些不同的計(jì)算結(jié)果像電影幻燈片放映一樣串聯(lián)起來，我們就得到了一張動(dòng)態(tài)的結(jié)果表——流式SQL做的工作就是把一張動(dòng)態(tài)數(shù)據(jù)表轉(zhuǎn)換成另一張動(dòng)態(tài)數(shù)據(jù)表，這樣流SQL的計(jì)算語義就比較容易理解了。實(shí)時(shí)流計(jì)算系統(tǒng)要解決的問題就縮小到了“如何實(shí)現(xiàn)動(dòng)態(tài)數(shù)據(jù)表的計(jì)算”上來。

　　流SQL引擎的自動(dòng)優(yōu)化是當(dāng)前主要的技術(shù)突破方向

實(shí)時(shí)流計(jì)算系統(tǒng)的易用性，是可以用SQL語言來解決的，網(wǎng)易流計(jì)算平臺(tái)Sloth的生產(chǎn)實(shí)踐也證實(shí)了這一理論。用戶不再需要學(xué)習(xí)各種計(jì)算引擎的編程接口，不再需要調(diào)試分布式計(jì)算程序，不再需要自己維護(hù)流計(jì)算系統(tǒng)，只需要把原來跑在離線平臺(tái)上的SQL遷移到實(shí)時(shí)流計(jì)算平臺(tái)上，就可以完成復(fù)雜的實(shí)時(shí)計(jì)算邏輯。

用戶端的工作大大減少了，實(shí)時(shí)流計(jì)算平臺(tái)的工作勢(shì)必是要增加的，其中比較困難的部分是如何把SQL查詢轉(zhuǎn)化成實(shí)際的計(jì)算邏輯，實(shí)現(xiàn)一個(gè)支持流式SQL的計(jì)算引擎，類似數(shù)據(jù)庫引擎的角色，而且就像之前討論的，這個(gè)引擎的計(jì)算邏輯必須符合“增量計(jì)算”模型。同時(shí)為了能讓實(shí)時(shí)計(jì)算結(jié)果應(yīng)用到各種各樣的業(yè)務(wù)場(chǎng)景中，計(jì)算引擎需要能夠?qū)痈鞣N存儲(chǔ)角色，比如數(shù)據(jù)、消息隊(duì)列、離線存儲(chǔ)等。

雙11大屏只是大數(shù)據(jù)實(shí)時(shí)流計(jì)算的一種應(yīng)用場(chǎng)景，未來會(huì)有越來越多的實(shí)時(shí)計(jì)算場(chǎng)景，比如除了文本計(jì)算實(shí)時(shí)化，圖像、語音計(jì)算也可以實(shí)時(shí)化，在線機(jī)器學(xué)習(xí)，物聯(lián)網(wǎng)實(shí)時(shí)計(jì)算等。實(shí)時(shí)數(shù)據(jù)以及實(shí)時(shí)流計(jì)算場(chǎng)景的類型都是指數(shù)增長(zhǎng)的，實(shí)時(shí)計(jì)算引擎會(huì)面臨不小的挑戰(zhàn)。基于SQL的流式計(jì)算描述也正在向前演化，會(huì)越來越多的納入流計(jì)算特有的屬性，比如輸出觸發(fā)、過期數(shù)據(jù)處理、多種規(guī)則的數(shù)據(jù)窗口劃分等。流SQL引擎的自動(dòng)優(yōu)化也是當(dāng)前主要的一個(gè)技術(shù)突破方向，相信未來實(shí)時(shí)流計(jì)算會(huì)隨著技術(shù)的進(jìn)步，應(yīng)用得跟深入、更廣泛。

songjy