你公司到底需不需要引入實時計算引擎？| 推薦

大資料發展至今，資料呈指數倍的增長，對實效性的要求也越來越高，於是像上面這種需求也變得越來越多了。

那這些場景對應著什麼業務需求呢？我們來總結下，大概如下：

初看這些需求，是不是感覺很難？

那麼我們接下來來分析一下該怎麼去實現？

從這些需求來看，最根本的業務都是需要實時檢視資料資訊，那麼首先我們得想想如何去採集這些實時資料，然後將採集的實時資料進行實時的計算，最後將計算後的結果下發到第三方。

資料實時採集

就上面這些需求，我們需要採集些什麼資料呢？

買家搜尋記錄資訊
買家瀏覽的商品資訊
買家下單訂單資訊
網站的所有瀏覽記錄
機器 CPU/MEM/IO 資訊
應用日誌資訊

資料實時計算

採集後的資料實時上報後，需要做實時的計算，那我們怎麼實現計算呢？

計算所有商品的總銷售額
統計單個商品的銷量，最後求 Top5
關聯使用者資訊和瀏覽資訊、下單資訊
統計網站所有的請求 IP 並統計每個 IP 的請求數量
計算一分鐘內機器 CPU/MEM/IO 的平均值、75 分位數值
過濾出 Error 級別的日誌資訊

資料實時下發

實時計算後的資料，需要及時的下發到下游，這裡說的下游代表可能是：

1、告警方式（郵件、簡訊、釘釘、微信）

在計算層會將計算結果與閾值進行比較，超過閾值觸發告警，讓運維提前收到通知，及時做好應對措施，減少故障的損失大小。

2、儲存（訊息佇列、DB、檔案系統等）

資料儲存後，監控大盤（Dashboard）從儲存（ElasticSearch、HBase 等）裡面查詢對應指標的資料就可以檢視實時的監控資訊，做到對促銷活動的商品銷量、銷售額，機器 CPU、MEM 等有實時監控，運營、運維、開發、領導都可以實時檢視並作出對應的措施。

讓運營知道哪些商品是爆款，哪些店鋪成交額最多，哪些商品成交額最高，哪些商品瀏覽量最多；

讓運維可以時刻了解機器的執行狀況，出現當機或者其他不穩定情況可以及時處理；

讓開發知道自己專案執行的情況，從 Error 日誌知道出現了哪些 Bug；

讓領導知道這次促銷賺了多少 money。

從資料採集到資料計算再到資料下發，整個流程在上面的場景對實時性要求還是很高的，任何一個地方出現問題都將影響最後的效果！

實時計算場景

前面說了這麼多場景，這裡我們總結一下實時計算常用的場景有哪些呢？

交通訊號燈資料
道路上車流量統計（擁堵狀況）
公安影片監控
伺服器執行狀態監控
金融證券公司實時跟蹤股市波動，計算風險價值
資料實時 ETL
銀行或者支付公司涉及金融盜竊的預警

……

另外我自己在我的群裡也有做過調研（不完全統計），他們在公司 Flink（一個實時計算框架）使用場景有這些：

總結一下大概有下面這四類：

1、實時資料儲存

實時資料儲存的時候做一些微聚合、過濾某些欄位、資料脫敏，組建資料倉儲，實時 ETL。

2、實時資料分析

實時資料接入機器學習框架（TensorFlow）或者一些演算法進行資料建模、分析，然後動態的給出商品推薦、廣告推薦

3、實時監控告警

金融相關涉及交易、實時風控、車流量預警、伺服器監控告警、應用日誌告警

4、實時資料包表

活動營銷時銷售額/銷售量大屏，TopN 商品

說到實時計算，這裡不得不講一下和傳統的離線計算的區別！

實時計算 VS 離線計算

再講這兩個區別之前，我們先來看看流處理和批處理的區別：

流處理與批處理

看完流處理與批處理這兩者的區別之後，我們來抽象一下前面文章的場景需求（實時計算）：

實時計算需要不斷的從 MQ 中讀取採集的資料，然後處理計算後往 DB 裡儲存，在計算這層你無法感知到會有多少資料量過來、要做一些簡單的操作（過濾、聚合等）、及時將資料下發。

相比傳統的離線計算，它卻是這樣的：

在計算這層，它從 DB（不限 MySQL，還有其他的儲存介質）裡面讀取資料，該資料一般就是固定的（前一天、前一星期、前一個月），然後再做一些複雜的計算或者統計分析，最後生成可供直觀檢視的報表（dashboard）。

離線計算的特點

資料量大且時間週期長（一天、一星期、一個月、半年、一年）
在大量資料上進行復雜的批次運算
資料在計算之前已經固定，不再會發生變化
能夠方便的查詢批次計算的結果

實時計算的特點

在大資料中與離線計算對應的則是實時計算，那麼實時計算有什麼特點呢？由於應用場景的各不相同，所以這兩種計算引擎接收資料的方式也不太一樣：離線計算的資料是固定的（不再會發生變化），通常離線計算的任務都是定時的，如：每天晚上 0 點的時候定時計算前一天的資料，生成報表；然而實時計算的資料來源卻是流式的。

這裡我不得不講講什麼是流式資料呢？我的理解是比如你在淘寶上下單了某個商品或者點選瀏覽了某件商品，你就會發現你的頁面立馬就會給你推薦這種商品的廣告和類似商品的店鋪，這種就是屬於實時資料處理然後作出相關推薦，這類資料需要不斷的從你在網頁上的點選動作中獲取資料，之後進行實時分析然後給出推薦。

流式資料的特點

資料實時到達
資料到達次序獨立，不受應用系統所控制
資料規模大且無法預知容量
原始資料一經處理，除非特意儲存，否則不能被再次取出處理，或者再次提取資料代價昂貴

實時計算的優勢

實時計算一時爽，一直實時計算一直爽，對於持續生成最新資料的場景，採用流資料處理是非常有利的。例如，再監控伺服器的一些執行指標的時候，能根據採集上來的實時資料進行判斷，當超出一定閾值的時候發出警報，進行提醒作用。再如透過處理流資料生成簡單的報告，如五分鐘的視窗聚合資料平均值。複雜的事情還有在流資料中進行資料多維度關聯、聚合、塞選，從而找到複雜事件中的根因。更為複雜的是做一些複雜的資料分析操作，如應用機器學習演算法，然後根據演算法處理後的資料結果提取出有效的資訊，作出、給出不一樣的推薦內容，讓不同的人可以看見不同的網頁（千人千面）。

使用實時資料流面臨的挑戰

1、資料處理唯一性（如何保證資料只處理一次？至少一次？最多一次？）

2、資料處理的及時性（採集的實時資料量太大的話可能會導致短時間內處理不過來，如何保證資料能夠及時的處理，不出現資料堆積？）

3、資料處理層和儲存層的可擴充套件性（如何根據採集的實時資料量的大小提供動態擴縮容？）

4、資料處理層和儲存層的容錯性（如何保證資料處理層和儲存層高可用，出現故障時資料處理層和儲存層服務依舊可用？）

總結

本文從日常需求來分析該如何去實現這類需求，需要實時採集、實時計算、實時下發，並用圖片把需求完成後的效果圖展示了出來，接著我們分析了對實時性要求高的計算這塊，然後將離線計算與實時計算進行了對比、批處理與流處理進行對比、離線計算的特點與實時計算的特點進行了對比，再加上我自己的調研結果，歸納了實時計算的四種使用場景，提出了使用實時計算時要面臨的挑戰。因為各種需求，也就造就了現在不斷出現實時計算框架，而下文我們將重磅介紹我們推薦的實時計算框架 —— Flink。