雙11背後的黑科技：大數據實時計算如何爲你量身定製？

本文由  網易雲 發佈。

 

數據時代，大數據計算已經滲透到了各行各業，業務沉澱數據，數據計算產生新的業務價值，大數據計算正不斷地用這種方式推進業務向前發展。電商雙11，商家與消費者狂歡的背後，一樣離不開大數據計算帶來的價值貢獻，特別是應用愈來愈普遍的「實時計算」。

 

現實世界中，數據連續產生，並被實時採集和計算

 

咱們要作數據計算，挖掘產品商業價值，首要解決的問題是數據的問題。現實世界裏，數據每每是隨着時間的推動連續產生的，好比用戶瀏覽商品，一系列的鼠標點擊操做，會產生一連串的後臺數據；開車使用手機導航，GPS定位每隔一段時間更新一次，也會不斷產生日誌數據；用戶瀏覽新聞推送、搜索歌曲、監控攝像頭定時採集圖片上傳到雲端存儲、視頻直播等等場景，這背後生成的數據都是連續產生的。連續產生的業務數據，又被實時採集起來，就造成了數據流。

 

流式數據一經採集，就能夠當即參與計算，同時將計算結果投入到業務應用中，這就是實時計算。實時數據計算其實早已經進入到人們生活的方方面面了，好比天氣預報，之前人們的習慣是天天接收一次天氣預報信息，如今則能夠實時查看天氣預測，同一個時間點的天氣預測會隨着時間的接近愈來愈準確，這就是監測數據採集更新及實時數據計算帶來的效果。

 

根據興趣量身定製，實時計算讓產品愈來愈瞭解用戶

 

實時數據來源愈來愈多、數量愈來愈大，每一年的數據量都在成倍地增加，這對實時計算自己是利好的，能夠有更多的應用場景、更好的應用效果，還可能促成一些革命性的變化。那麼，大數據實時計算還能作什麼？

 

在網易，考拉海購雙十一、618海淘盛典等活動期間，都會有一塊網易有數大屏幕實時展現當前最新的銷售總額、每一個商品品類的銷售比例、訂單增加趨勢、活躍用戶地理位置等，各類維度的信息都在一塊屏幕上不斷跳動。每一個用戶每筆訂單所產生的影響都會實時更新到大屏上。這種可視化的實時應用效果，除了增添一份電商狂歡節的氛圍，更易於發現數據價值，指導市場運營、輔助商業決策。

 

金融風控是另外一種典型的實時計算應用場景。對金融業務這種風險敏感的業務來講，僅僅能把數據可視化是遠遠不夠的，它須要流計算系統可以利用一些風險模型的匹配規則，去實時分析海量的用戶行爲數據，發現異常事件、判斷風險等級，並做出相應的風險控制措施，自動化地去作報警通知、改變業務流程。經過實時計算作金融風控，帶來的好處是更快、更準、更廣。其餘許多相似風控這樣的事件驅動計算場景，實時計算都能解決好。

 

實時計算在推薦領域的應用也已經很深刻了。不管是新聞推薦、音樂推薦仍是讀書推薦，基本都已經作到了千人千面，每一個人接收到的推送內容都是根據我的興趣偏好量身定製的。而用戶的興趣偏好，每每是經過實時數據計算不斷在更新的。以新聞推送爲例，當用戶點擊一條條推送消息時，背後產品其實時刻在對用戶的行爲作實時分析，實時更新用戶的興趣偏好，不斷髮現用戶新的興趣點，對用戶愈來愈瞭解，最後給用戶推送他更感興趣的內容。再以音樂推薦爲例，若是一個用戶某段時間收藏了幾首悲傷的歌曲，經過實時數據分析，系統能夠識別出這一信息，同時有針對性的推送一些歌曲去撫慰用戶。這種場景是隻有實時計算才能解決的，也最能體現實時計算的價值。

 

愈來愈多的實時計算場景會被開發出來，將來人們對「一切都在變化之中」的感覺會愈來愈深入。

 

從「先存後算」到「邊算邊存」，實時計算再也不怕「大」數據

 

實時計算這麼好，在實現層面應該怎麼作，有哪些困難和挑戰是必須解決的？

 

首先從總體架構看，數據計算，無外乎三樣東西：數據輸入→計算→數據輸出。傳統的計算模型，以數據庫爲例，是先將數據存儲在一個數據表中，用戶經過執行查詢語句觸發數據庫的計算操做，最後數據庫完成計算後輸出結果。這種「先存後算」的模型在大數據實時計算場景下是行不通的。咱們所要計算的數據很「大」，一個計算結果所涉及的源數據多是涵蓋過往一天的數據，多是上千億條數據記錄。若是每增長一些新數據，都把全部數據都從新計算一遍，這樣的開銷是很是大的，最終的效果會是很「慢」，達不到實時的效果。比較合理的作法是「邊算邊存」，意思是數據進入實時計算系統後，不必定須要先存儲起來，能夠直接參與計算，並且這裏的計算是把當前新增的數據在以前歷史數據的計算結果上作「增量計算」，同一條數據不重複參與計算，計算完成以後，再把計算結果保存起來，供業務使用，這時數據存儲的壓力也小了不少。同時「大」意味着數據併發很高，每秒可能須要計算上千萬條新數據，這樣的計算量不是單機能承受的，因此大數據實時計算要解決好的是分佈式系統架構下的一系列技術問題。

 

分佈式實時計算面臨的挑戰包括不少方面。數據從採集、到計算、到輸出整個過程必須作到低延遲，除了計算節點自己採用「增量計算」的模型，還要求上游數據傳輸模塊具備很高的吞吐能力，而且具有數據緩存的能力，在大流量場景下能夠起到緩衝的做用，下游輸出模塊也須要作數據壓縮、批量輸出等優化，以保證輸出結果的實時性。低延遲這個大前提對實時計算系統的其餘特性提出了更高的要求。好比雙11凌晨0點的時候，大量消費者在同一時刻下單支付，這是涌進實時計算系統的瞬時數據量是巨大的，系統須要有強大的並行處理數據的能力，將大量瞬時流量合理分配到成百上千個計算節點，並將這些節點的計算結果匯聚到一塊兒計算出一個整體的結果，在高吞吐的狀況下仍保證低延遲。

 

從「批量計算」到「增量計算」，最具挑戰的是準確性和易用性

 

和低延遲一樣關鍵的挑戰是準確性。「增量計算」模型和傳統「批量計算」模型是有區別的，因此不能照搬過往的技術經驗，不然就會有準確性方面的問題。須要考慮清楚新進入的數據如何疊加到老的計算結果上，有些場景下甚至要支持從老的計算結果中撤除部分計算值，以保證最終結果的準確性。

 

分佈式系統中的某個節點出現故障是很常見的，實時流計算系統的故障恢復能力也至關重要，由於當故障發生時，系統必須快速恢復，不然系統的輸出更新可能就停滯了，實時性也就無從談起。同時故障發生也不能破壞「增量計算」這個模型，不然退化到「批量計算」的模型就又得不到實時的計算結果了，並且結果準確性也難以保證。

 

事實上網易大數據在實現自研流計算平臺Sloth的過程當中，遇到並克服了上述技術難點。網易流計算平臺Sloth做爲一個平臺化的產品，在產品易用性、多租戶隔離方面作了大量的工做。就實時計算而言，易用性是一個比較值得討論的方面。

 

對於開發人員而言，寫一個分佈式程序比寫單機程序會困難一些，而寫一個分佈式實時計算程序，會更難。好在業界有一些開源的流計算引擎幫助完成了很多工做，開發人員可使用這些流計算引擎完成流計算任務的開發，他們可能再也不須要關心計算任務如何分發到多個計算節點上、數據在計算節點間如何傳輸等問題，只須要專一於計算邏輯的開發、控制好不一樣計算階段的計算並行度。

 

以計算一篇文章的單詞數爲例，一個分佈式計算程序的內容可能包括三個部分，首先是用幾個計算節點共同把每一行文本拆分紅一個一個的單詞；第二步是用另一些計算節點去統計單詞的個數（考慮到數據量巨大的狀況，這裏有必要用多個節點去作計算）；第三步是由一個計算節點把上游各各節點算出的部分計數匯聚成一個總的計數。這樣一個最簡單的場景，須要開發的代碼量大約是200行。實際業務場景下，數據流經的計算節點遠遠不止3個，計算類型也比基礎的求和複雜不少，因此即便有了流計算引擎，分佈式實時計算程序的開發仍然是比較困難的。再進一步看，即便開發完成了，還須要把大量的時間投入到調試、計算框架維護等方面，一旦計算需求發生變化，全部的工做都須要從新迭代一遍，這是個比較痛苦的過程。如何讓流式計算程序更易編寫，是實時計算平臺須要去完成的挑戰。

 

且不考慮實時流計算系統如何解決易用性這個問題，看下計算機科學發展過程當中，相似問題是怎麼解決的。人們但願編程能夠容易一些，因此愈來愈多的高級編程語言被髮明出來了；人們但願數據計算能夠容易一些，而後就有了數據庫，以及SQL語言——結構化查詢語言；到了大數據時代，人們還在折騰離線批量計算的時候，就遇到的依靠計算引擎編程複雜的問題，最終經過把SQL語言應用到分佈式離線計算系統上，解決了這個問題。而如今實時計算的迅速發展的如今，是否一樣能夠用SQL語言去解決這個問題？答案是確定的。不過有許多細節的問題須要去推敲求證。

 

實時流計算中的數據流，能夠理解爲一張動態的數據表

 

上文說起了離線批量計算模型和實時增量計算模型是有差別的，當SQL語言分別做用與批量計算和流式計算時，其語義也是須要發生變化的。批量計算和流式計算最主要的區別是前者計算的數據是有限的、後者計算的數據是無限的是不斷採集進入系統的。當一個SQL查詢做用在一批離線數據上面時，計算完成、輸出結果，這條SQL查詢也就完成了。映射到流式計算，當SQL查詢觸發計算，它是不會結束的，由於數據在持續不斷地流入，按照離線SQL的語義，SQL結束以前，計算不會輸出結果，這顯然不是流計算指望的效果，因此流式SQL其本質應當是定義一系列流計算任務，同時這些任務是邊執行邊輸出計算結果的。 

 

離線SQL處理的是靜態數據表，而流式SQL處理的是數據流，SQL的計算語義（如求和、平均值、數據錶鏈接等）做用在數據流上是否合理。理解這個問題須要作一個概念上的轉換：離線SQL是把靜態的數據錶轉換成另外一張靜態數據表；而實時流計算中的數據流，能夠理解爲一張動態的數據表（數據會不斷增加的動態數據表）。不一樣的時刻這個數據表又不一樣的樣子，執行SQL會獲得不一樣的計算結果，把這些不一樣的計算結果像電影幻燈片放映同樣串聯起來，咱們就獲得了一張動態的結果表——流式SQL作的工做就是把一張動態數據錶轉換成另外一張動態數據表，這樣流SQL的計算語義就比較容易理解了。實時流計算系統要解決的問題就縮小到了「如何實現動態數據表的計算」上來。

 

流SQL引擎的自動優化是當前主要的技術突破方向

 

實時流計算系統的易用性，是能夠用SQL語言來解決的，網易流計算平臺Sloth的生產實踐也證明了這一理論。用戶再也不須要學習各類計算引擎的編程接口，再也不須要調試分佈式計算程序，再也不須要本身維護流計算系統，只須要把原來跑在離線平臺上的SQL遷移到實時流計算平臺上，就能夠完成複雜的實時計算邏輯。

 

用戶端的工做大大減小了，實時流計算平臺的工做勢必是要增長的，其中比較困難的部分是如何把SQL查詢轉化成實際的計算邏輯，實現一個支持流式SQL的計算引擎，相似數據庫引擎的角色，並且就像以前討論的，這個引擎的計算邏輯必須符合「增量計算」模型。同時爲了能讓實時計算結果應用到各類各樣的業務場景中，計算引擎須要可以對接各類存儲角色，好比數據、消息隊列、離線存儲等。

 

雙11大屏只是大數據實時流計算的一種應用場景，將來會有愈來愈多的實時計算場景，好比除了文本計算實時化，圖像、語音計算也能夠實時化，在線機器學習，物聯網實時計算等。實時數據以及實時流計算場景的類型都是指數增加的，實時計算引擎會面臨不小的挑戰。基於SQL的流式計算描述也正在向前演化，會愈來愈多的歸入流計算特有的屬性，好比輸出觸發、過時數據處理、多種規則的數據窗口劃分等。流SQL引擎的自動優化也是當前主要的一個技術突破方向，相信將來實時流計算會隨着技術的進步，應用得跟深刻、更普遍。

 

網易有數

企業級大數據可視化分析平臺。面向業務人員的自助式敏捷分析平臺，採用PPT模式的報告製做，更加易學易用，具有強大的探索分析功能，真正幫助用戶洞察數據發現價值。

點擊這裏---免費試用。

 

瞭解 網易雲 ：
網易雲官網：https://www.163yun.com/
新用戶大禮包：https://www.163yun.com/gift
網易雲社區：https://sq.163yun.com/