簡介：通過兩個demo分享技術實時計算flink版的解決方案

本文整理自阿里云智能行業解決方案專家GIN的直播分享
直播鏈接：https://developer.aliyun.com/learning/course/839

本文主要分享兩個基于 Flink 制作的實時大數據的應用。為了更好的體現應用的價值以及它所代表的典型的場景，這次的分享定制了兩個接近現實生活中的應用案例。

第一個是如何去做實時的 API 應用服務日志的分析，第二個是采用模擬的 IoT 遙測數據去分析車輛的引擎，并且做實時的異常偵測，以達到做預測維護的一個目的。

實時應用日志分析

場景描述

第一個場景的需求是比較普遍的，這個場景搭建了車輛隱私保護的API。這個API本身是可以對用戶上傳的車輛的照片進行一個隱私保護的處理，是一個深度學習的模型。

這個模型被封裝成一個API，放在阿里云的公共云ECS上，供全世界各地的用戶去訪問。針對這個API首先需要做的就是去分析到底有多少人在訪問他的反饋的頻度，來自哪個國家或地區，以及他的訪問的一些特征，是否為攻擊或者正常的利用？

為了做這個實時的分析，首先需要有能力對各個API分散在各個服務器當中的本身的應用日志去進行海量且實時的一個收集的行為。不僅能收集我們，我們還要能夠對它進行一個比較及時的實時的一個處理。處理包括可能有維度表的查詢，有些窗口的聚合等等，這對流式計算來說比較常見的操作，最后把這些操作處理完的結果放在高吞吐低延遲的一個環境里邊，使得下游的分析系統能夠對數據進行一個實時的訪問。

整個這個鏈路并不復雜，但是它代表了一個非常重要的能力，也就是通過使用 Flink 為代表的實時計算和處理，能夠在秒級的單位內給業務決策人員提供一個數據驅動決策的功能。

Demo方案架構

具體來看一下這個demo是如何實現的，這里邊的這個架構里邊有幾個重要的關鍵。

首先右上方是搭建好的API的環境，用的是Flask、 Pytho結合比較主流的Nginx、Gunicorn把它制成了一個API 。需要把API變成一個容器鏡像，并且通過鏡像將它部署到阿里云的ECS上面，為了高并發低延遲，還裝了第七層的負載均衡，以及前面套了一個API Gateway網關去幫助用戶去調用API的能力。

同時作為這個demo，我們也提供了一個 WEB APP ，使得用戶不僅能通過代碼去調用 API ，也可以使用圖形化的界面去訪問API 。當前端的用戶去調用API 的時候，會使用SLS 簡單日志服務去從API 本身的服務器當中收集實時的收集API 的應用日志，并且將它做簡單的處理之后，投遞到實時計算Flink中。
Flink 有個很好的一個特征，就是它可以去訂閱來自簡單日志服務的日志的投遞，并且以流式計算的方式對這個日志進行窗口聚合維度表的查詢結合等等這些操作，還有一個好處是它可以用習慣的SQL去做比較復雜的業務邏輯的定制。

當這些數據都處理完了之后Flink 就會把流數據以結構化表的方式寫到Hologres，Hologres不僅作為數據的一個存儲，也同時作為一個給下游 BI 數據展現提供動力的類似OLAP的引擎的性質。這些東西串起來，形成了本次的大數據實時日志采集分析的一個架構。

方案解析

具體來看一下，每個部件是如何使用的。

使用車輛隱私 API 作為實時分析的數據源
通過WEB APP可以允許用戶非常簡單的去上傳自己的車輛的照片，API 會對他進行一個模糊化的處理。錄屏中可以看到這張照片交由API 處理之后背景被虛化了，并且車牌的部分還有隱私信息的部分也被遮擋了。

SLS 日志中心
當有用戶去訪問這個API 的時候后臺簡單日志服務就會對他進行一個實時的采集。

日志采集之后會使用Log tail 的轉換數據加工的能力，對原始的日志去進行一定程度的解析和轉換，其中就包括將IP地址解析為例如國家城市緯度精度等這樣的地理信息，方便后續做下游的分析的時候可以調度這些信息，除了簡單的一些服務還提供一個非常強大的圖形化的數據分析的能力。

實時計算Flink版
在這里可以做一個初級的數據分析的，或者是數據勘察的功能，可以看到原始日志的轉換是否滿足下游業務支撐的一個需求，當日志被采集轉換處理完之后，會通過Log Hub將這個日志投遞給流處理中心，也就是實時計算Flink 。

其實用投遞這個詞并不是特別的精確，實際上是Flink 主動去訂閱，在Log Hub 里邊存儲的Log Store 的這些處理過的日志的信息。Flink 有個非常好的地方，可以用常見的SQL去寫編業務邏輯，包括轉換處理一些邏輯條件。當SQL寫完后只要點擊上線，就可以包裝成一個Flink的job ，并托管在Flink 的cluste里邊，集群里邊，通過這個控制臺可以非常方便的訪問。

那么現在的plus的集群的使用程度頻度如何？CPU 如何，有沒有異常，有沒有報錯，包括查看整個交付的情況等等，可直接通過Flink 托管，這是一個非常大的優勢，幾乎不用去為運維操心。

Hologres (HSAP)

Flink 處理完成，這個流數據通過 Flink 提供的接口，可以使得處理完的流數據，以一種類似于表格結構化的方式直接寫入到我們的存儲系統Hologress里 ，Hologress有一個特別大的特征就是它既是OLTP，也是OLAP。

具體來說既可以把它拿做OUTP去快速的寫入，同時也可以對被寫入的數據同時進行一個高并發的低延遲的查詢分析。也就是常常說的OLAP引擎的能力，他把兩者合并為一塊，所以Hologress 也被稱為HSAP。

DataV Dashboard
在本次的架構當中，它主要用來把處理完的數據展現給下游，也就是終端用戶，終端的業務決策人員可以看到消費的實時的大屏。

這個實時的大屏會隨著API 被訪問，以秒級的延遲，把最新的信息處理完的信息給反映。在這個datav的實時大屏上，這樣的話可以很大程度上減少決策人員看到數據時產生的延遲。

如果采用的是傳統的那種批處理的方式的，那么每次處理可能要上TB級的數據，而且處理時間長達數小時。如果采用以flink 為核心的端到端的實時計算的方案的話，這個延遲就能從幾個小時被壓縮在幾秒甚至是一秒以內。

車輛引擎實時預測維護

場景描述

第二個業務場景是結合IoT通過模擬的遙測數據，分析判斷馬路上行走的車的引擎是否展現一些異常的證照，可以提前判斷是否可能存在問題，如果放任不管的話3個月之后可能某個部件就要壞了，這也是一個在實際應用場景當中經常會被提到的一個需求，我們稱之為預測性的維護。預測性維護在實際的應用場景當中，可以幫客戶方省下大量的金錢，因為當東西已經出現問題在進行修復，肯定不如在損壞之前提前給替換來的有效。

Demo方案架構

為了實現這么一個比較接近真實世界的場景，調研了解了在車載設備當中有個叫OBD II的這個診斷系統，它里邊經常包含的經典數據，把這些數據采集了一部分過來對它進行加工、模擬。寫了一個程序，模擬一個比較真實的在現實環境當中運行的車的引擎的一個數據。

當然本次因為不太可能真的讓一輛車在馬路上開，所以有了這個模擬程序，利用各種各樣的統計分析的手法去模擬生成這樣的行車數據，盡可能達到真實的效果。

這個程序會把模擬的行車引擎遙測數據把它給投遞到Kafka ，然后通過實時計算Flink 消費訂閱Kafka的Topic ，然后根據每個Topic進行不同的流式計算。結果的一部分將它歸檔在 OSS ，把它存儲下來就有了歷史數據，另一部分作為熱流數據源直接投遞給開發的異常偵測的模型，把它部署在PAI EAS上面，通過 Flink 可以直接去調用。

然后做了這個機器學習的判斷后，再去看現在當下的這個引擎的數據有沒有異常的征兆，再把這個結果寫入到數據庫里邊，供AB進行一個進行一個進行一個消費。數據通過實時計算Flink做了實時的處理之后，一部分的數據把它歸檔到了OSS里。

這部分數據實際用來作為歷史數據去建模，甚至是重新模型。因為每隔一段時間可能行車的這個特征萬一發生了一些變化，俗稱Data Drifting ，那么又可以用新產生的歷史數據去對模型進行重新的訓練，重新訓練完的模型又可以把它作為 Web Service ，把它部署到PAI ES上供Flink 去調用，這樣的話就完成了一個Lambda 架構的大數據解決方案。

方案解析

生成模擬行車數據

首先需要做模擬數據生成的工作，去把引擎的遙測數據OBD的數據把它給模擬出來，投遞到這個云上去做分析。這邊采用的是函數計算，函數計算非常的方便。它首先是一個托管服務，它是一個service 的服務。

其次可以把Python的腳本從本地開發好的腳本直接照搬copy配置到這個函數計算里邊，利用這個托管的計算去執行這個模擬數據生成的這么一個程序腳本，非常的方便。

在本次demo當中采用了每一分鐘執行一次函數計算，也就是生成一個批次的遙測數據，然后每次生成間隔3秒投遞一個數據到Kafka里邊去盡可能去模擬一個真實環境當中的這個數據產生的一個頻度。

收集/發布行車數據

Kafka也是一個常用的大數據的Pub/Sub的一個系統，它非常的靈活，擴容性非常的棒，在阿里云上的Kafka，可以在EMR 里邊自建一個Kafka集群，也可以使用叫Kafka on MQ的一個托管服務，來搭建一個完全service 。

這是個kafka系統，本次demo 為了方便就采用了kafka去搭建了一個托管式的 Pop Subject System ，這System 其實只是用來囤積前方生成的，也就是車輛投遞過來的這個引擎的數據，那么在實際的生產環境當中車不可能是一輛，甚至肯定是幾萬輛，幾十萬輛都有可能，采用kafka的話就可以非常方便的去擴容。不管前端的車有10輛還是10萬輛，整體架構都不需要做太大的改變，可以從容的應對這些擴容的彈性的需求。

實時計算和異常分析模型調用

實時計算的部分，仍然采 Flink 的這個實時計算系統，只不過在本次demo當中使用用的是 Blink 的獨享集群，也就是所謂的半托管式的這個實時計算的平臺。其實跟剛才在上一個場景當中的全托管使用方法幾乎是一模一樣的。

只不過在制作這個demo 的時候，一部分的區域還未上線Flink 全托管版本，所以選擇了一個叫Blink 獨享集群的服務，同樣也是掛在實時計算的這個家族當中，用起來的方法幾乎跟全托管是一模一樣的，開發人員也只需要focus 在寫這個腳本去做業務邏輯的處理，點擊上線，剩下的基本上就是完全由Flink 代為管理，只需要去監控看有沒有異常的出現，包括做一些調優等等的工作，非常的方便。

那么在這邊值得一提的是把PAI-EAS的這個模型調用的接口嵌入到了Flink 里邊，使得Flink 在實時處理流數據的時候，同時也可以把一部分的數據扔給PAI去做模型的這個推論，得出的結果再和實時流數據合并起來，最后一并寫入到下游的存儲系統里邊，體現了Flink計算平臺的一個延展性和擴容性。

異常檢測模型的開發

這部分展現如何用一個圖形化的學習平臺去設計開發一個非常簡單的二元分類模型。

這個二元分類模型主要就是從過去引擎的歷史數據當中，學習哪些特征會被用來判斷為引擎有問題，哪些是是比較屬于正常的這個數值。通過這個模型，就有依據可以用來對未來新產生的引擎數據進行一個判斷，這樣有助于業務人員提早去預知目前引擎的數據問題。

模型部署和調用服務

因為模型從過去已經學習到了相關的特征以及這個Data的pattern。這個模型的開發整個過程用的studio ，完全是拖拽搭建，幾乎沒寫過一條代碼，非常的方便快捷，完全可以通過紐扣來實現一個模型的開發。更好的一點在于當模型開發完了之后，通過PAI可以一鍵部署把它包裝成一個rest API 和Web Service 放在PAI的平臺上去供用戶去調用。一鍵部署之后，對這個部署完的模型的服務進行一個測試調用，非常的方便。

高吞吐結構化數據存儲 (RDS)

當模型部署完成，可以通過Flink 讓他判斷有沒有異常這個流數據進行實時的處理之后，最后把它寫到了一個MySQL 的數據庫里邊。

這個數據庫就會作為數據源去給下游的實時大屏提供一個數據的支撐。這樣的話業務人員就可以實現實時也就是隔幾秒的這個狀態就能看到目前在路上跑的這個車到底有沒有問題？

Near Realtime Dashboard

通過這個鏈接： https://datav.aliyuncs.com/share/9fff231ff81f409829180ee933e7bcee 可以打開這個實時的大屏。

data v 的大屏是預設每5秒更新一次，也就是說每5秒就會從數據庫當中把最新的預遙測數據，包括這個判斷有沒有異常的數據，把數據展示在大屏上。

紅色代表的是這個時間點采集上來的數據，代表是有問題的，那么藍色就代表normal，也就是比較正常的數據。這個數據的正常標準，完全是由之前產生的模擬數據function computer 去在控制。因為在function computer 邏輯里邊人為加了一些會讓引擎看起來出錯的這種數據，使得這個demo 的不正常的部分體現的更多一點。

以上就是本次分享的2個demo，感興趣的同學可以使用實時計算Flink版搭建自己的應用。

原文鏈接：https://developer.aliyun.com/article/789208?

版權聲明：本文內容由阿里云實名注冊用戶自發貢獻，版權歸原作者所有，阿里云開發者社區不擁有其著作權，亦不承擔相應法律責任。具體規則請查看《阿里云開發者社區用戶服務協議》和《阿里云開發者社區知識產權保護指引》。如果您發現本社區中有涉嫌抄襲的內容，填寫侵權投訴表單進行舉報，一經查實，本社區將立刻刪除涉嫌侵權內容。

總結

以上是生活随笔為你收集整理的基于实时计算Flink版的场景解决方案demo的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。