簡介：本文由阿里巴巴高級產品專家陳守元老師分享，詳細講解實時計算 Flink 的具體業務場景并分享實時計算 Flink 的相關應用案例。

作者：陳守元（巴真），阿里巴巴高級產品專家

摘要：本文由阿里巴巴高級產品專家陳守元老師分享，詳細講解實時計算 Flink 的具體業務場景并分享實時計算 Flink 的相關應用案例。

內容分為以下四部分：
● 技術原理
● 技術應用
● 應用場景
● 行業案例

1、技術原理

關于技術原理這部分的介紹，下文主要從通曉原理、容易混淆的四大概念、批處理和流處理的對比、事件觸發的流處理四個方面展開介紹。

通曉原理舉一反三

從上圖所示的關于實時計算 Flink 業務架構圖中可以發現，平時在做業務開發或是架構設計的時候，開發人員需要通曉產品背后的技術原理，只有這樣做開發的過程中才能避免非必要的失誤，從而提高數據開發的效率。對于很多架構師來講，只有通曉了技術背后的原理，才能養成全局的架構嗅覺。

容易混淆的四大概念

下圖所示的數據處理時效性的四大概念是從不同維度描述的，分別代表計算的不同特征，它們分別是：實時計算、離線計算、流計算（或稱流處理）和批處理。這四個概念其實是從兩個維度來描述的，橫坐標軸上面的計算和下面的處理，指代的是業務的特征。

實時計算它描述快速的計算過程和快速的請求響應。實時計算描述的是計算鏈路的表達，是實時業務實時計算的需求特征。離線計算強調的是它的離線特征，即非實時的，非實時的計算過程和非實時的請求響應。業務特征是，不求特快，只求結果。

所以橫向坐標軸上面描述的本質都是業務處理需求，而坐標軸下面描述的是技術需求。

流計算（流處理）強調的技術特征是流式處理。流式處理有有幾大特征，包括常駐、事件觸發和通常具備實時性。批處理（又稱批計算）強調了計算通過批示進行處理。它的特征是，非常駐、外界觸發和通常不具備實時性。

批處理和流處理的對比

對于批處理來說，處理分為三步。第一步是數據裝載；第二步是批量計算，系統會把這份數據加載到存儲里面然后構建相應元數據或者索引等操作；第三步是外界發起數據請求觸發計算，計算出結果返回給用戶。對于流計算來說，它的方式完全不一樣。通常來說用戶要把一個流式作業提前寫好，然后提交到集群或計算系統里面。（由上圖右側所示）數據寫入一條，流式計算就會觸發一次并運算一次，然后寫出一個結果，整個過程很短。

所以總結而言，對于批處理來說，數據裝載、數據計算本身是完全脫節的過程，數據是一批批加載，計算也是一批批請求，這就是批處理（批計算）；同時它也是一個高時延的計算；另外它還是一個主動發起的計算，所謂的主動發起就是用戶主動發起計算請求的。對于流式計算來說，它正好與之相反。流計算是持續的，只要有數據輸入就會持續的計算；另外它是低時延的；它也是一個事件觸發的計算。

事件觸發的流處理

關于流處理，從維基百科上可以提煉3個關鍵詞，Event，Stream和Process，本名為事件流處理，日常在工程實踐中會被簡化稱為流處理或流計算。三個關鍵詞準確地描述了流處理的三大特點：

● Event說明了流處理是由事件觸發，同時事件又具有極強的時間性，比如事件發生時間、事件處理時間、事件進入時間等等。

● Stream代表的是事件流，也就是上圖說明的“無界的事件集合”。意思是對于流計算來說，它的數據是持續的、源源不斷地進入流計算系統的。也就是說，只要不人為終止它，數據便會源源不斷地進入消息隊列，最終進入流式處理系統。所以它本質上是一個無窮無盡的事件流，我們稱之為無界的事件集合。

● Process是指流程，流處理作為一個處理系統也是一個計算系統，同樣也是一個Process流程系統。對于流計算來說，數據進入一條就會觸發一條，然后處理一條再輸出，整個過程需要非常快的速度，也就是我們說得實時在線處理。

流式處理的價值

流式處理的價值在于當數據進來產生后，能夠被迅速處理計算，然后迅速得到業務結果，這就是流計算的價值。需要流計算的地方，一般是數據價值隨著時間流逝而迅速降低的場景。

對于離線計算來說，數據放一小時、一天或一個月，都不會影響計算，但對于實時計算來說，一旦數據沒能做到及時流處理并即刻產生結果，那么數據的價值就會隨著時間的流逝而逐漸降低。

關于流式處理的業務價值，可以舉個例子，相信很多人對一年一度的雙11都很熟悉，每年雙11顯示總交易額的實時大屏就是實時計算的一個最佳應用。另外一個更倍顯價值的案例就是關于淘寶或是天貓的賣家通過實時的廣告流量數據來調動或指定廣告策略并執行，這樣對他們的實時業務做到最大的助力。

2、技術場景

在Apache Flink官網有專門描述三大抽象技術場景，它們是：Stream Analytics，Stream Pipelines，Event-Driven Application。這三大抽象技術場景是我們下面展開的所有業務場景的基礎，了解了這三大抽象技術場景，對未來推導其他業務場景和應用案例有很大的幫助。

Stream Analytics

目前在中國，最多的使用場景是Stream Analytics，它對應的是流處理；如上圖左側Batch Analytics對應的是批處理。Batch Analytics大家應該很熟悉了，它是傳統批量分析，也就是批處理，基于有限的數據集構建應用來完成事件的批查詢或計算，這個過程和上文介紹的批處理流程是一樣的。

右邊的Stream Analytics正好相反。如圖所示，數據流是持續不斷的進入query或application計算系統， 并持續的計算結果，結果再寫入外部的存儲，然后再通過Live Report輸出給用戶。

以上是批處理和流處理在Analytics這個場景下的延伸介紹，它們的原理式完全一樣的。

Stream Analytics的核心優勢是它規避了批處理周期性數據導入和計算的高延遲過程。相對于批處理，流處理更快更有效率。

Flink 如何支持數據分析類應用

Flink 最大的特點是它內置了一個符合ANSI標準的SQL接口，可以將批量和流式的語義統一起來。無論是在記錄事件的靜態數據集上，還是實時事件流上，相同SQL查詢都會得到一致的結果。這套系統是阿里云貢獻給整個社區的，也是從2015年開始就承接了每年雙11實時大屏的工作。歷經考驗，它是一套非常成熟穩定的系統。

Flink內置的符合ANSI標準的SQL接口，成功地把流式處理的技術平民化，賦能給大量的BI工程師或開發人員。他們只需會寫SQLC口或稍微通曉一點 Flink 的流處理語言，就能夠做相應的開發。 Flink 所支持的數據分析類應用包括：實時數倉，實時數據中臺和實時BI。

Stream Pipelines

如上圖，左邊是批處理Periodic ETL，右邊是實時處理Data Pipeline。從整張圖的數據管道來看，流處理相對于批處理來講，更具有流動性，也就是數據的鏈路更可以實現實時化。

如上圖，對于實時的數據管道，最大的優勢是，能夠明顯降低將數據移動到目的端的延遲，也能夠持續消費和發送數據，因此用途更廣，支持用例更多。

Flink 如何更好的支持數據管道應用呢？ 很多常見的數據轉換和增強操作可以利用 Flink 的SQL接口（或Table API）及用戶自定義的函數解決。如果數據管道有更高級別的需求，可以選擇更通用的DataStream API來實現。

Flink 為多種數據存儲系統內置了連接器，如Kafka、Kinesis、Elasticsearch、JDBC數據庫等系統。它還提供了文件系統的連續型數據源(Source)及數據匯端(Sink)，可用來監控目錄變化和以時間分區的方式寫入文件。

Stream Pipeline的應用場景有，實時數據清洗、實時搜索構建和實時告警。

Event Driven Application

希望將 Flink打造成流處理界的翹楚，希望達到更加極致的實時化，也就是提供一些更加定制化或個性化的數據處理。達成這樣的效果需要圍繞Application做到快速的讀取和寫入等。從坐標來看，希望把 Flink推向另外一個對處理時間要求更極致化的Event-Driven的Application。所以Event-Driven Application滿足的是對更極致流的場景需求。

事件驅動型應用的優勢是，無需查詢遠程數據庫，本地數據訪問使得它具有更高的吞吐和更低的延遲。而由于定期向遠程持久化存儲的CheckPoint工作可以異步、增量式完成，因此對于正常事件處理的影響甚微。

事件驅動型應用的優勢不僅限于本地數據訪問，傳統分層架構下，通常多個應用會共享同一個數據庫，因而任何對數據庫自身的更改都需要謹慎協調。而事件驅動型應用，由于只需考慮自身數據，因此在更改數據表示或服務擴容時，所需的協調工作將大大減少。

事件型應用案例包括，反欺詐、異常檢測和復雜規則告警，或是其他比較復雜的非二維關系代數模型分析類的應用。

3、應用場景

基于第二部分的技術場景，在上面做疊加和組合，就是以下幾個應用場景的介紹。

實時數倉

實時數倉是在當下比較火、綜合了Stream Analytics和Pipeline最終形成了實時數倉。它與傳統數倉最大的區別是，它能夠把前方的業務數據實時進行清洗、匯聚、加工，最后寫入實時服務這一層。實時數倉最核心的是把業務的整個鏈路實時化了，這就極大的滿足了一些需要實時看數據等業務需求。

實時風控

實時風控在很多有資損、監察、安全監控等需求的行業應用場景很多。在互聯網時代，對于大量的用戶訪問、數據請求和業務的需求，造就了實時風控系統架構的極致化應用。在互聯網初期，大家對時效性沒有那么高的要求，很多離線風控系統就可以滿足需求，但是現在實時化需求越來越大了。

借助實時風控，當用戶在做一些操作的時候，規則引擎在獲取數據后會做規則判斷，然后反饋結果用戶的操作是否合法。

實時機器學習

實時機器學習是一個更寬泛的概念，傳統靜態的機器學習主要側重于靜態的模型和歷史數據進行訓練并提供預測。很多時候用戶的短期行為，對模型有修正作用，或者說是對業務判斷有預測作用。對系統來說，需要采集用戶最近的行為并進行特征工程，然后給到實時機器學習系統進行機器學習。如果動態地實施新規則，或是推出新廣告，就會有很大的參考價值。

4、行業案例

以上的業務應用案例是不帶行業屬性的，那么這一部分將結合一些業務場景來看各個行業的案例。主要圍繞每個案例產生的背景、需要使用實時計算的痛點、使用實時計算后解決的問題或產生的價值來展開。

金融行業應用

實時計算在金融行業應用比較多是因為金融行業正在面臨數據化的轉型。轉型和變化表現在，從傳統到線上，由傳統向云上發展，由人決策向機器決策轉換等等。這樣會帶來幾個比較大的變化：

第一是它的業務會越來越復雜，以前只有線下業務，現在有了更多不同類型的業務，比如線上業務，終端業務等等；而且服務鏈條也越來越長，業務的變化也越來越快。第二是數據需要實行一些決策。以前線下業務在柜臺，是點對點的業務溝通和服務，對時效性要求不高。但是新增的線上業務或終端業務，就完全需要一個實時數據監控和實時化的決策，對系統實時化需求更高了。這種實時決策的需求同時對數據質量也會越來越高，這樣才能避免決策的失誤。

第三是傳統風控向實時風控的轉型。在金融體系中，像信用違約、賬戶安全、貸款記賬等等，以前的線下業務是靠很多人的參與完成決策的，現在全部數字化后，系統的實時風控就能解決。所以實時計算可以實現對系統整個鏈路數據的實時采集、實時計算和實時實施，最終實時反饋到業務線上。

在線教育行業應用

由于今年疫情的關系，在線教育行業非常火爆，推動了傳統教育向在線教育的轉型。在線教育行業面臨著很大的實時自動化的需求，因為第一是數據量大，用戶量暴增造成數據的暴增；第二是延遲，很多推薦場景或是運營場景，對實時化有強烈的訴求。傳統教育的報表是以離線時效性給給到老板查閱分析，但隨著行業的數據化轉型，數據開始產生價值，實時數據能夠為一線運營人員提供決策的依據。

第三是復雜，在線教育行業因疫情而爆發增長，屬于比較新的行業，那么他們的業務在快速發展的同時，一些BI場景也是處于快速變化中的，而且也比較復雜，因此急需一套完整的實時解決方案，幫助他們完成業務的數據的實時化和AI化的轉型。這就需要用到阿里實時計算 Flink 來解決了，它能幫助客戶快速使用 Flink SQL
解決業務問題。

內容資訊行業應用

內容資訊行業本身是數據密集型行業，而且已經實現個性化推薦，例如今日頭條、抖音等平臺。這種個性化的推薦需要大量的數據做實時決策。所以當一個公司，數據量突然猛增，業務發展迅猛，那么就需要實時計算解決方案。

另外，如果業務形態比較復雜也需要實時計算的幫助。有一些資訊平臺，不僅有新聞內容，還有UGC、短視頻、直播等內容，各種形態千差萬別。這就對實時化計算的訴求很強了。第三就是個性化推薦的實現，更是需要實時化計算來助力。它能夠實時的把在線業務系統、用戶行為等，實現實時抓取并計算，最終服務用戶產生個性化推薦。

電商行業應用

實時計算 Flink在阿里首先落地到了電商上，所以應用到電商行業的實時計算應用場景也很多。首先就是上文提到的每年雙11的實時巨屏；雙11期間淘寶天貓賣家對渠道出貨情況的實時了解，廣告投放的實時動態等等，以保證能在雙11僅僅24小時的窗口期，及時調整銷售策略和廣告策略，創造最大價值。

廣告行業應用

廣告行業從誕生之初，都是一個時效性要求非常高的行業。對廣告來說大部分的場景或核心場景都對實時化的要求就比較高。廣告數據的真實性對企業來講是非常重要的，那么能夠實時地將因廣告產生的用戶行為數據、索引數據、廣告鏈接點擊和檢測等等反饋到系統，借助在線反作弊來反饋真實的流量數據，對企業來講是有價值的。

實時計算 Flink 可以極大減少業務開發人員和架構人員在面臨實時計算的各種各樣不確定性情況時，做到非常穩定地實現廣告業務并保證企業的廣告收益。

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

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

總結

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

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