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

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