摘要：本文整理自 Flink Forward Asia 2023 中閉門會的分享。主要分享實時計算在各行業(yè)的應用實踐，對回歸實時計算的重點場景進行介紹以及企業(yè)如何使用實時計算技術，并且提供一些在技術架構上的參考建議。內容分為以下四個部分：

1. 業(yè)務需求變化推動架構演進

2. 實時計算在各行業(yè)的應用與實踐

3. 從數(shù)據(jù)看實時計算在各行業(yè)的趨勢

4. 總結

一、業(yè)務需求變化推動架構演進

任何技術的發(fā)展都是隨著業(yè)務需求而推動。那么隨著業(yè)務技術的需求推動，是如何發(fā)展到當前的技術形態(tài)呢？

在早期，企業(yè)依靠數(shù)據(jù)分析和數(shù)據(jù)倉庫查看到最近的數(shù)據(jù)，如昨天、一個月前乃至三個月前的數(shù)據(jù)。許多企業(yè)的數(shù)據(jù)倉庫是基于像 MySQL、Oracle、DB2 這樣的傳統(tǒng)單機數(shù)據(jù)庫系統(tǒng)搭建的。隨著時間推移，企業(yè)對歷史數(shù)據(jù)的分析需求增加，需要分析的數(shù)據(jù)也越來越多，時間跨度也擴大到了三年、五年，甚至十年，導致單機架構在這種海量數(shù)據(jù)分析需求面前也顯得力不從心。因此，分布式數(shù)據(jù)庫如 Teradata、Greenplum (GP) 應運而生，幫助解決在海量數(shù)據(jù)情況下企業(yè)快速數(shù)據(jù)分析的需求，并且解決了第二個問題：“大”和“快”的問題。 從2006 年 Hadoop 成為開源社區(qū)的頂級項目開始，企業(yè)大規(guī)模使用 Hadoop 來做離線分析，標志著數(shù)據(jù)處理能力的一個重要進步。
隨著互聯(lián)網(wǎng)技術的發(fā)展，傳統(tǒng)的數(shù)據(jù)倉庫已經不僅限于關系數(shù)據(jù)，可能來自于互聯(lián)網(wǎng)的行為日志數(shù)據(jù)，也可能來自不同設備的終端時序數(shù)據(jù)，這些數(shù)據(jù)在傳統(tǒng)數(shù)據(jù)倉庫中沒有辦法基于 SQL、存儲過程來分析，而是需要基于 MapReduce、 Spark 以及 Python 方式對數(shù)據(jù)進行預處理和分析。在這種情況下就需要一種新的系統(tǒng) Hadoop，目前大多數(shù)企業(yè)已經在這個階段過渡。后來業(yè)務需求對實質性的要求越來越高，需要的不再是 T+1 的數(shù)據(jù)，而是需要根據(jù)前一個小時、前一分鐘、前一秒的業(yè)務動態(tài)來判斷下一個角色。所以對時效性要求越來越高，這促使著現(xiàn)在的流計算技術發(fā)展，使 Flink 成為企業(yè)的一個在實時計算的事實標準。

二、實時計算在各行業(yè)的應用與實踐

接下來分享四個實時計算使用比較多的行業(yè)，分別是金融、汽車，交通物流以及零售行業(yè)。分享一下在這些行業(yè)場景中是如何使用大數(shù)據(jù)實時計算相關的技術，以及近幾年實時計算使用的比例變化。

1. 金融行業(yè)

金融業(yè)在實時計算的應用里基本上處于百花齊放的狀態(tài)。不僅可以收到實時推薦的消息、股票交易的動態(tài)變化等，而且除了這些情況外，金融機構還會做 To B 端企業(yè)服務和私募基金的相關服務。對大客營銷需要針對性的監(jiān)管報送，實時將企業(yè)、金融機構的風險提供給監(jiān)管部門，這些都需要大量的實時計算技術。

接下來舉兩個行業(yè)場景的例子，金融行業(yè)是如何使用相關大數(shù)據(jù)實時計算技術的？下圖是一個案例證券交易行為。

在當前股市中，對交易監(jiān)控的實時性要求極高，主要是因為市場價格波動迅速，股民的交易行為需要得到即時的監(jiān)管。例如，在實施注冊制之前，如果股票的交易價格為 100 元，投資者可以掛出 110 元的買單。在極短的時間內，可能價格就會漲到 110 元，從而使投資者獲得 10% 的收益。但注冊制實行后，掛單價格的上限受到限制，不得超過當前賣出價格溢價的 2%，也就是說最高只能掛 102 元。這樣的變化意味著對交易行為實施實時監(jiān)控和告警，以及在必要時進行阻斷變得更加重要。如果阻斷措施延遲，可能會引發(fā)數(shù)據(jù)合規(guī)性問題。因此，為了確保合規(guī)并保護投資者的利益，對于交易行為的監(jiān)控系統(tǒng)必須做到快速反應。

舉個例子，在股市交易監(jiān)控方面，各種訂單數(shù)據(jù)，如股票的買入量、當前報價及股票代碼，以實時數(shù)據(jù)的形式流入系統(tǒng)并進入消息隊列。除了這些流式數(shù)據(jù)，還需要引入與所購股票相關的基本信息，比如客戶購買的財報數(shù)據(jù)、昨日的漲停價和開盤價等。這些基礎數(shù)據(jù)存儲于 Hologres 中，以維表的形式存在，用于與流式數(shù)據(jù)進行關聯(lián)。數(shù)據(jù)關聯(lián)之后，再利用 Flink 對這些信息進行加工和判斷分析。如果檢測到用戶在近幾分鐘內掛出的訂單價格超過了當下價格的 2%，系統(tǒng)會立即采取阻斷措施并發(fā)出告警?？紤]到場景架構圖中存在眾多的風險和交易規(guī)則，我們采用基于復雜事件處理（CEP）的方法來實現(xiàn)風控規(guī)則，而上述只描述了其中一條規(guī)則。同時，還可能需要引入離線數(shù)據(jù)來補充用戶信息。這些離線數(shù)據(jù)每天按照T+1模式更新，通過分析這些歷史數(shù)據(jù)并將它們與實時數(shù)據(jù)結合，可以對交易情況做出更加細致的判斷。

下面第二個案例是零售銀行面向 c 端的用戶推薦。

銀行和許多金融機構會定期發(fā)布各種促銷活動，包括針對股票和基金的活動。作為用戶，當通過 APP 或 H5 頁面點擊參與活動時，就會生成一條實時觸發(fā)的消息流。接下來，系統(tǒng)需要判斷這個用戶應該得到多少優(yōu)惠券，并且通過積分獎勵的方式鼓勵用戶完成購買，形成銷售的閉環(huán)。為了處理這個流程，整個鏈路會使用 Flink+Hologres 來協(xié)助客戶做處理。

2. 汽車行業(yè)

近年來，隨著新能源汽車產業(yè)的快速發(fā)展，汽車行業(yè)對數(shù)據(jù)的依賴日益增加，數(shù)據(jù)量的增長速度非常迅猛。可以看到一個現(xiàn)象，在云上的多數(shù)企業(yè) CPU 和內存的使用成本遠遠高于數(shù)據(jù)存儲成本，在云上的來說存儲相對廉價。然而，汽車行業(yè)的情況頗為獨特，由于數(shù)據(jù)涌現(xiàn)速度極快，特別是新能源汽車產生的數(shù)據(jù)已經在云平臺上造成存儲成本超過計算成本的現(xiàn)象。

汽車行業(yè)從初期的研發(fā)制造、供應鏈、銷售、再到對外的服務，整個鏈路都包含了眾多的實時場景與應用。包括在研發(fā)階段需要對研發(fā)過程的實時監(jiān)控、研發(fā)參數(shù)的實時告警。在供應鏈環(huán)節(jié)，對零部件進行實時預警同樣關鍵，每一個供應鏈環(huán)節(jié)都可能直接影響到一個企業(yè)的業(yè)務目標和銷售業(yè)績。在銷售環(huán)節(jié)，針對C端用戶的商品推薦和行為分析也極為重要。

另一個場景是在服務階段，如何提供良好的汽車服務以促進二次銷售也是企業(yè)需要關注的場景。下文將介紹一個重要的行業(yè)應用：新能源汽車的車聯(lián)網(wǎng)場景。隨著車輛上裝配的攝像頭、傳感器和雷達數(shù)量的增多，這背后采集到的數(shù)據(jù)量也在相應增加。

我們有一個客戶，每天要采集大約 42 億條數(shù)據(jù)，采集頻率是每秒一次。相比之下，在一年前他們可能是每天只采集一次數(shù)據(jù)。隨后這個頻率提高到了每10分鐘一次，繼而因為業(yè)務需求，他們需要將采集頻率從原先的每 10 秒逐步過渡到每秒采集。此外，我們還有汽車行業(yè)的客戶，現(xiàn)在已經需要達到每 500 毫秒采集一次數(shù)據(jù)。以 30 萬輛運行中的車為例，如果每秒采集數(shù)據(jù)一次，就意味著每秒需要采集 30 萬條數(shù)據(jù)。然而，這些數(shù)據(jù)與其他行業(yè)的數(shù)據(jù)有所不同，一條數(shù)據(jù)就可能包含多達 3,000 到 4,000 個字段的信號數(shù)據(jù)

在車聯(lián)網(wǎng)場景中，前端設備可能是 TBOX 或 TSB 這樣的車載平臺，它們通常采集的是二進制數(shù)據(jù)。許多企業(yè)首要的工作是利用 Flink 將這些車載二進制信號數(shù)據(jù)轉換成后續(xù)可進行分析的結構化數(shù)據(jù)，這是處理流程的第一步。接下來，他們可能會使用 Hologres 進行實時的在線分析服務。針對汽車行業(yè)高昂的存儲成本問題，Hologres也推出了價格更低廉的存儲產品，包括低頻訪問的存儲解決方案，幫助客戶在處理海量數(shù)據(jù)時實現(xiàn)存儲分層，從而幫助降低整體成本。

下面是介紹新能源汽車行業(yè)，結合剛才的實時數(shù)據(jù)可以做的哪些場景。

在這一場景中，我們可以采集到多種車輛數(shù)據(jù)，包括車輛所處的車道、駕駛員是否雙手握方向盤、車速以及車輛是左轉還是右轉等信息。通過分析這些數(shù)據(jù)，系統(tǒng)能夠判斷駕駛員是否存在危險駕駛行為。例如，如果一個駕駛員在五分鐘內持續(xù)雙手脫離方向盤，或者在高速公路上連續(xù)五分鐘的速度超過 150 公里/小時，那么系統(tǒng)就會將其歸類為危險駕駛，并可能采取相應措施向客戶發(fā)出預警。

同時，還可以根據(jù)這些數(shù)據(jù)對用戶進行畫像。如果數(shù)據(jù)顯示用戶偏好激烈的駕駛行為，那么在下一次購車時，系統(tǒng)可能會向該用戶推薦性能更強的車型。如今，無論是傳統(tǒng)主機廠還是排名前十的新能源汽車制造商，超過 70% 的車聯(lián)網(wǎng)平臺都在運行于阿里云上。結合這些企業(yè)的實踐經驗，阿里云推出了一套面向車聯(lián)網(wǎng)行業(yè)的推薦參考架構。許多領先的汽車廠家都按照這套架構實施其車聯(lián)網(wǎng)平臺。

下圖左側是實時架構，右側是離線架構。

實時數(shù)倉與實時計算的主要區(qū)別在于數(shù)據(jù)的處理和管理方式。在傳統(tǒng)的數(shù)倉中，數(shù)據(jù)通常會進行層次化處理，涉及到離線數(shù)據(jù)的不同層級，比如 DWD、DWS 和 ADS。然而，在實時計算中，進行層次化分隔較為困難，因為它缺乏統(tǒng)一的存儲層次。例如，ODS 層的數(shù)據(jù)可能存放在 Kafka 中，加工后的 DWD 層數(shù)據(jù)可能放在 RDS 中，這些數(shù)據(jù)難以統(tǒng)一管理。目前，阿里云通過整合 Flink 和 Hologres 技術，使接入的數(shù)據(jù)在消息隊列中存儲，并經過 Flink 的處理轉化成寬表格式，之后統(tǒng)一存放在 Hologres 中，實現(xiàn)了數(shù)據(jù)流的實時處理與分析。

很多業(yè)務部門早期將數(shù)據(jù)存放在消息隊列中，但這樣做無法執(zhí)行查詢，也無法使用 SQL 語句進行數(shù)據(jù)操作?，F(xiàn)在，可以將寬表格式的數(shù)據(jù)直接存儲在 Hologres 中，并且借助 Flink 按照離線數(shù)倉的層次化架構，加工形成指標數(shù)據(jù)后統(tǒng)一存放入 Hologres 引擎。將 Hologres 定義為面向業(yè)務的唯一數(shù)據(jù)出口，避免了對其他關系數(shù)據(jù)庫和 Key-Value 數(shù)據(jù)庫的依賴。將所有數(shù)據(jù)集中存儲在 Hologres 中后，前端應用、報表和各種數(shù)據(jù)產品都能基于 Hologres 實現(xiàn)數(shù)據(jù)的統(tǒng)一訪問與輸出，這樣不僅簡化了數(shù)據(jù)架構還提升了數(shù)據(jù)處理的效率。

3. 物流行業(yè)

預計今年，許多物流企業(yè)采用實時計算的比例將超過50%。

物流行業(yè)在數(shù)據(jù)流轉方面與零售行業(yè)相似，都是圍繞著人、貨和場所進行。一個顯著特點是物流行業(yè)對位置信息的要求日益增高。用戶在下單之后會時刻關注快遞的位置，因此，物流企業(yè)開始圍繞位置信息展開實時計算的數(shù)據(jù)加工與處理。數(shù)據(jù)的生成起始于用戶通過手機APP下單或電話聯(lián)系快遞員上門這樣的環(huán)節(jié)，從而形成一套訂單信息。這些訂單在物流企業(yè)內部經過分發(fā)處理后，轉換為具體的運單信息。運單形成后，進一步貫穿于派送和簽收等環(huán)節(jié)。在整個流程中，對鏈路時效性的要求越來越高，用戶對數(shù)據(jù)更新的容忍度逐漸降低，希望能夠實時、每秒鐘都能看到最新的快遞信息。

下面舉幾個簡單的場景，第一個場景是大件物流。與小件快遞不同，大件物流主要是做快運。

快運服務的一個特點是車輛類型的多樣性，包括大、中、小型車輛，此外還有許多特定的標簽，比如載重能力。例如，如果一個客戶需要運輸兩噸重的物品，但是分配了一個能承載十噸重的車輛，這顯然會有些浪費。背后的匹配邏輯相當復雜，因為有時兩噸重的貨物實際上可能因體積較大而需要更大的車輛。那么，該如何有效地進行車輛與貨物間的匹配呢？這就需要通過數(shù)據(jù)對車輛和貨物進行精確的標記，隨后實時計算技術便可以根據(jù)用戶貨物的變化和位置變化進行合適的匹配與推薦。

接下來看第二個場景：

疫情期間所帶來的挑戰(zhàn)可能讓人感受更為明顯，比如一個企業(yè)負責從杭州到北京的大件物流運輸。在這種情況下，可能會遇到運至某城市時發(fā)現(xiàn)該城市正處于疫情管控，無法通過。這樣原本確定的物流單可能被迫取消，導致貨主雙方都面臨一系列問題。為了解決這類問題，借助實時計算技術，司機可以實時上報自己的位置和其他相關信息，這通常需要硬件的支持；同時，貨主端也能實時監(jiān)控貨物的狀態(tài)變化。通過這種方式，能夠有效提高整個物流過程的效率和響應時效。

以下就是圍繞剛才講的兩個場景，物流行業(yè)場景的整個技術架構圖。

總體來看，涉及的數(shù)據(jù)包括訂單數(shù)據(jù)、貨源數(shù)據(jù)、司機數(shù)據(jù)以及用戶會員數(shù)據(jù)等。這些數(shù)據(jù)如何進行有效匹配呢？在這樣的數(shù)據(jù)架構背后，不僅包括了實時的流消息，還涉及到離線的用戶標簽數(shù)據(jù)、車輛的靜態(tài)維度表數(shù)據(jù)等多種數(shù)據(jù)類型。利用 Flink 技術，可以綜合處理這些不同來源的流數(shù)據(jù)和靜態(tài)維表數(shù)據(jù)進行必要的加工處理。加工后的數(shù)據(jù)可以應用于多種業(yè)務場景，例如智能匹配車輛與貨物、實時監(jiān)控路線以及提供最優(yōu)路線推薦等，有效地優(yōu)化物流配送的效率和服務質量。

針對這個場景，我們提出了一個參考架構。前端的埋點數(shù)據(jù)、用戶端數(shù)據(jù)以及 APP 上報的數(shù)據(jù)將會統(tǒng)一推送到消息隊列 Data Hub 中。數(shù)據(jù)一旦推送到 Data Hub，就會通過 Flink 進行實時的接入和加工處理。處理完成的數(shù)據(jù)隨后會統(tǒng)一存儲到 Hologres 中。前端應用可能直接從 Hologres 中執(zhí)行 OLAP 分析，或者在這基礎上進行實時決策支持。 Hologres 可以提供實時的運力匹配關系、供需動態(tài)以及實時軌跡分析等關鍵業(yè)務信息，這些功能在需要快速響應市場變化和用戶需求的業(yè)務場景應用中特別重要。在架構的右側，主要針對的是離線場景，同樣會將實時處理的數(shù)據(jù)寫入離線的對象存儲中，以便用于離線數(shù)據(jù)的進一步補充和處理。

4. 零售行業(yè)

零售行業(yè)是最早開始采用實時計算的行業(yè)之一。阿里巴巴在最初開展雙11大促活動時，就已經能夠通過大屏實時展示當前的銷售動態(tài)數(shù)據(jù)。企業(yè)的決策者們需要了解當前的銷售情況，并依據(jù)這些實時數(shù)據(jù)進行相關的決策。接下來，我會舉兩個具體的例子來說明。

第一個例子是，在特別是像雙十一、雙十二這樣的大型促銷中，許多零售企業(yè)會準備大量促銷活動。假設企業(yè)需要準備 1,000 萬優(yōu)惠券，它們需要對這 1,000 萬的優(yōu)惠券的動向進行實時監(jiān)控。接著，根據(jù)優(yōu)惠券的發(fā)放情況，需要進行動態(tài)的調整。如果在最開始的五分鐘內 1,000 萬優(yōu)惠券就被搶光了，企業(yè)需要立刻決策是否再追加 1,000 萬以增加用戶轉化率？這些都是在營銷的全過程中，包括營銷前、營銷中、營銷后，業(yè)務流程中需要考慮的因素。

在技術實現(xiàn)方面，離線場景涉及到大量的歷史數(shù)據(jù)，包括用戶的行為、他們偏好的服裝類型、年齡和性別等信息，這些都會被儲存在歷史數(shù)據(jù)平臺上。當出現(xiàn)購買信息或潛在的點擊行為時，基于 Flink 引擎可以幫助實時作出判斷。它能預測用戶是否可能在接下來的兩分鐘內下單，并且識別出哪種優(yōu)惠券對用戶來說更有吸引力。整個過程需要 Flink 利用技術手段來進行評估和決策。下圖是實施營銷的一個決策方案架構：

下面是第二個場景：

很多企業(yè)依賴實時數(shù)據(jù)分析來強化其商業(yè)決策，這需要能夠迅速向企業(yè)決策者和各個業(yè)務部門提供關鍵信息。例如，精確追蹤某個用戶在特定頁面的停留時間及其帶來了多少轉化率?；谝豢钐峁┫嚓P查詢和分析的平臺，簡而言之，用戶需要進行查詢，盡管這背后可能涉及海量的數(shù)據(jù)，可能是幾億甚至幾十億條記錄。那么如何解決這一挑戰(zhàn)呢？解決方案是通過 Hologres。我們可以看到，底層的數(shù)據(jù)被存儲在 Hologres 中，并且可能存在各種檢索條件?；谶@些檢索條件系統(tǒng)需要快速地給業(yè)務提供決策支持和響應能力。比如，可能需要查詢特定品類、用戶當前行為、某個商品占位信息或廣告投放的效率等?；诙鄻拥臋z索條件，Hologres 提供的 OLAP 查詢能力可以滿足這些需求，從而實現(xiàn)客戶對于數(shù)據(jù)的快速查詢。

下面是在線做電商的一個客戶，基本上幾十 TB 級的數(shù)據(jù)。自助分析的響應速度控制在 3 秒以內，基本上 99% 的查詢都是在 3 秒以內響應，業(yè)務方認為這樣的速度能夠非?？旖莸貛椭麄兲岣邲Q策效率。

零售行業(yè)也提出了一個參考架構。

在零售行業(yè)中，數(shù)據(jù)倉庫通常包含了如商品、會員、銷售、售后和運營等多個標準化領域，這些分域和層次結構一般來說都非常規(guī)范和通用。基于這樣的架構，可以借助阿里云的 MaxCompute 來執(zhí)行離線數(shù)據(jù)倉庫的分層處理。對于實時計算需求，則可以通過結合 Flink 和 Hologres 來實現(xiàn)實時數(shù)據(jù)倉庫的操作，以及構建統(tǒng)一的架構。至于調度管理層，可以使用 DataWorks 來提供統(tǒng)一的工作流程調度和數(shù)據(jù)加工服務。這是一個在零售行業(yè)常見的推薦架構。上述四個方面是對實時計算依賴性較高且使用效果良好的行業(yè)中的典型應用場景。

三、從數(shù)據(jù)看實時計算在各行業(yè)的趨勢

根據(jù)阿里云發(fā)布的公有云數(shù)據(jù)報告，中國大約有 50% 的大數(shù)據(jù)用戶選擇使用阿里云服務，擁有數(shù)萬名大數(shù)據(jù)客戶。從這些客戶數(shù)據(jù)中做出的簡單分析顯示，在四年前的 2020 年，實時計算的普及率還相對較低，基本都在 10% 以內。大部分企業(yè)當時仍然主要依賴于 T+1 的小時級離線分析。然而，預計下一年，金融行業(yè)實時計算的使用比例將超過 25%，物流行業(yè)的比例可能會超過 50%。因此，實時計算成為未來發(fā)展的一個關鍵考慮點。整個行業(yè)實時計算的用例預計都會超過 30%，這表明實時計算的普及率正處于一個迅速上升的階段。

四、總結

作為阿里云計算平臺的成員之一，除了今天討論的實時計算技術之外，還基于服務數(shù)萬+客戶的經驗，沉淀出了面向未來的一套云上數(shù)據(jù)倉庫參考架構。這一架構的設計旨在為客戶提供一套高效、可靠、可擴展的數(shù)據(jù)處理與分析平臺，以支撐大數(shù)據(jù)、人工智能和數(shù)據(jù)倉庫等多種復雜應用場景。

在未來的交流和分享中，我們將基于這一推薦的參考架構，深入探討如何有效地利用大數(shù)據(jù)技術、人工智能能力以及數(shù)據(jù)倉庫功能，來幫助客戶解鎖數(shù)據(jù)價值，推動業(yè)務成長和創(chuàng)新。通過這些互動，我們希望與客戶共同探索和實踐最佳的云計算解決方案，以滿足客戶不斷變化的業(yè)務需求。