數據時代, 大數據計算已經滲透到了各行各業, 業務沉澱數據, 數據計算產生新的業務價值, 大數據計算正不斷地用這種方式推動業務向前發展. 電商雙11, 商家與消費者狂歡的背後, 同樣離不開大數據計算帶來的價值貢獻, 特別是應用越來越廣泛的 '即時計算' . 現實世界中, 數據連續產生, 並被即時採集和計算 我們要做數據計算, 挖掘產品商業價值, 首要解決的問題是數據的問題. 現實世界裡, 數據往往是隨著時間的推進連續產生的, 比如用戶瀏覽商品, 一系列的滑鼠點擊操作, 會產生一連串的後台數據; 開車使用手機導航, GPS定位每隔一段時間更新一次, 也會不斷產生日誌數據; 用戶瀏覽新聞推送, 搜索歌曲, 監控攝像頭定時採集圖片上傳到雲端存儲, 視頻直播等等場景, 這背後生成的數據都是連續產生的. 連續產生的業務數據, 又被即時採集起來, 就形成了數據流. 流式數據一經採集, 就可以立即參與計算, 同時將計算結果投入到業務應用中, 這就是即時計算. 即時數據計算其實早已經進入到人們生活的方方面面了, 比如天氣預報, 以前人們的習慣是每天接收一次天氣預報資訊, 現在則可以即時查看天氣預測, 同一個時間點的天氣預測會隨著時間的接近越來越準確, 這就是監測數據採集更新及即時數據計算帶來的效果. 根據興趣量身定製, 即時計算讓產品越來越了解用戶 即時數據來源越來越多, 數量越來越大, 每年的數據量都在成倍地增長, 這對即時計算本身是利好的, 可以有更多的應用場景, 更好的應用效果, 還可能促成一些革命性的變化. 那麼, 大數據即時計算還能做什麼? 在網易, 考拉海購雙11, 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引擎的自動優化也是當前主要的一個技術突破方向, 相信未來即時流計算會隨著技術的進步, 應用得跟深入, 更廣泛.
數據時代, 大數據計算已經滲透到了各行各業, 業務沉澱數據, 數據計算產生新的業務價值, 大數據計算正不斷地用這種方式推動業務向前發展. 電商雙11, 商家與消費者狂歡的背後, 同樣離不開大數據計算帶來的價值貢獻, 特別是應用越來越廣泛的 '即時計算' . 現實世界中, 數據連續產生, 並被即時採集和計算 我們要做數據計算, 挖掘產品商業價值, 首要解決的問題是數據的問題. 現實世界裡, 數據往往是隨著時間的推進連續產生的, 比如用戶瀏覽商品, 一系列的滑鼠點擊操作, 會產生一連串的後台數據; 開車使用手機導航, GPS定位每隔一段時間更新一次, 也會不斷產生日誌數據; 用戶瀏覽新聞推送, 搜索歌曲, 監控攝像頭定時採集圖片上傳到雲端存儲, 視頻直播等等場景, 這背後生成的數據都是連續產生的. 連續產生的業務數據, 又被即時採集起來, 就形成了數據流. 流式數據一經採集, 就可以立即參與計算, 同時將計算結果投入到業務應用中, 這就是即時計算. 即時數據計算其實早已經進入到人們生活的方方面面了, 比如天氣預報, 以前人們的習慣是每天接收一次天氣預報資訊, 現在則可以即時查看天氣預測, 同一個時間點的天氣預測會隨著時間的接近越來越準確, 這就是監測數據採集更新及即時數據計算帶來的效果. 根據興趣量身定製, 即時計算讓產品越來越了解用戶 即時數據來源越來越多, 數量越來越大, 每年的數據量都在成倍地增長, 這對即時計算本身是利好的, 可以有更多的應用場景, 更好的應用效果, 還可能促成一些革命性的變化. 那麼, 大數據即時計算還能做什麼? 在網易, 考拉海購雙11, 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引擎的自動優化也是當前主要的一個技術突破方向, 相信未來即時流計算會隨著技術的進步, 應用得跟深入, 更廣泛.
|
