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

時間 2019-11-29

標籤公司到底須要引入實時計算引擎简体版

原文原文鏈接

前言

本身以前發佈過一篇 Chat 《大數據「重磅炸彈」：實時計算框架 Flink》，裏面介紹了多種需求：github

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

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

小鵬，咱們如今搞促銷活動能不能實時統計銷量 Top5 啊？

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

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

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

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

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

……

大數據發展至今，數據呈指數倍的增加，對實效性的要求也愈來愈高，因而像上面這種需求也變得愈來愈多了。算法

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

初看這些需求，是否是感受很難？服務器

那麼咱們接下來來分析一下該怎麼去實現？微信

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

數據實時採集

就上面這些需求，咱們須要採集些什麼數據呢？架構

買家搜索記錄信息框架
買家瀏覽的商品信息運維
買家下單訂單信息
網站的全部瀏覽記錄
機器 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。