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

前言

先廣而告之，本文摘自本人《大數據重磅炸彈——實時計算框架 Flink》課程第二篇，內容首發自我的知識星球，後面持續在星球裏更新，這裏做個預告，今晚 12 點後漲價至 199。

自己之前發佈過一篇 Chat 《大數據“重磅炸彈”：實時計算框架 Flink》，裏面介紹了多種需求：

小田，你看能不能做個監控大屏實時查看促銷活動銷售額（GMV）？

小朱，搞促銷活動的時候能不能實時統計下網站的 PV/UV 啊？

小鵬，我們現在搞促銷活動能不能實時統計銷量 Top5 啊？

小李，怎麼回事啊？現在搞促銷活動結果服務器宕機了都沒告警，能不能加一個？

小劉，服務器這會好卡，是不是出了什麼問題啊，你看能不能做個監控大屏實時查看機器的運行情況？

小趙，我們線上的應用頻繁出現 Error 日誌，但是隻有靠人肉上機器查看才知道情況，能不能在出現錯誤的時候及時告警通知？

小夏，我們 1 元秒殺促銷活動中有件商品被某個用戶薅了 100 件，怎麼都沒有風控啊？

小宋，你看我們搞促銷活動能不能根據每個顧客的瀏覽記錄實時推薦不同的商品啊？

……

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

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

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

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

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

數據實時採集

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

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

數據實時計算

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

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

數據實時下發

實時計算後的數據，需要及時的下發到下游，這裏說的下游代表可能是：

告警方式（郵件、短信、釘釘、微信）

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

存儲（消息隊列、DB、文件系統等）

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

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

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

讓開發知道自己項目運行的情況，從 Error 日誌知道出現了哪些 Bug；

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

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

實時計算場景

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

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

……

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

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

實時數據存儲

實時數據存儲的時候做一些微聚合、過濾某些字段、數據脫敏，組建數據倉庫，實時 ETL。

實時數據分析

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

實時監控告警

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

實時數據報表

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

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

實時計算 VS 離線計算

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

流處理與批處理

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

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

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

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

離線計算的特點

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

實時計算的特點

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

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

流式數據的特點

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

實時計算的優勢

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

使用實時數據流面臨的挑戰

數據處理唯一性（如何保證數據只處理一次？至少一次？最多一次？）
數據處理的及時性（採集的實時數據量太大的話可能會導致短時間內處理不過來，如何保證數據能夠及時的處理，不出現數據堆積？）
數據處理層和存儲層的可擴展性（如何根據採集的實時數據量的大小提供動態擴縮容？）
數據處理層和存儲層的容錯性（如何保證數據處理層和存儲層高可用，出現故障時數據處理層和存儲層服務依舊可用？）

總結

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