簡介：相對于離線批處理技術，流式實時處理技術作為一個非常重要的技術補充，在阿里巴巴集團內被廣泛使用。

前言：
-更多關于數智化轉型、數據中臺內容請加入阿里云數據中臺交流群—數智俱樂部 和關注官方微信公總號（文末掃描二維碼或點此加入）

-阿里云數據中臺官網 https://dp.alibaba.com/index

來源：數智化轉型俱樂部

數據價值是具有時效性的，在一條數據產生的時候，如果不能及時處理并在業務系統中使用，就不能讓數據保持最高的“新鮮度”和價值最大化。

相對于離線批處理技術，流式實時處理技術作為一個非常重要的技術補充，在阿里巴巴集團內被廣泛使用。

在大數據業界中，流計算技術的研究是近年來非常熱門的課題。

業務訴求是希望能在第一時間拿到經過加工后的數據，以便實時監控當前業務狀態并做出運營決策，引導業務往好的方向發展。比如網站上一個訪問量很高的廣告位，需要實時監控廣告位的引流效果，如果轉化率非常低的話，運營人員就需要及時更換為其他廣告，以避免流量資源的浪費。在這個例子中，就需要實時統計廣告位的曝光和點擊等指標作為運營決策的參考。

按照數據的延遲情況，數據時效性一般分為三種（離線、準實時、實時）：

• 離線：在今天（T）處理N天前（T-N，N≥1）的數據，延遲時間粒度為天。
• 準實時：在當前小時（H）處理N小時前（H-N，N>0，如0.5小時、1小時等）的數據，延遲時間粒度為小時。
• 實時：在當前時刻處理當前的數據，延遲時間粒度為秒；

離線和準實時都可以在批處理系統中實現（比如Hadoop、MaxCompute、Spark等系統），只是調度周期不一樣而已，而實時數據則需要在流式處理系統中完成。簡單來說，流式數據處理技術是指業務系統每產生一條數據，就會立刻被采集并實時發送到流式任務中進行處理，不需要定時調度任務來處理數據。

整體來看，流式數據處理一般具有以下特征。

1．時效性高

數據實時采集、實時處理，延時粒度在秒級甚至毫秒級，業務方能夠在第一時間拿到經過加工處理后的數據。

2．常駐任務

區別于離線任務的周期調度，流式任務屬于常駐進程任務，一旦啟動后就會一直運行，直到人為地終止，因此計算成本會相對比較高。這一特點也預示著流式任務的數據源是無界的，而離線任務的數據源是有界的。這也是實時處理和離線處理最主要的差別，這個特性會導致實時任務在數據處理上有一定的局限性。

3．性能要求高

實時計算對數據處理的性能要求非常嚴格，如果處理吞吐量跟不上采集吞吐量，計算出來的數據就失去了實時的特性。比如實時任務1分鐘只能處理30秒采集的數據，那么產出的數據的延時會越來越長，不能代表當前時刻的業務狀態，有可能導致業務方做出錯誤的運營決策。在互聯網行業中，需要處理的數據是海量的，如何在數據量快速膨脹的情況下也能保持高吞吐量和低延時，是當前面臨的重要挑戰。因此，實時處理的性能優化占了任務開發的很大一部分工作。

4．應用局限性

實時數據處理不能替代離線處理，除了計算成本較大這個因素外，對于業務邏輯復雜的場景（比如雙流關聯或者需要數據回滾的情況），其局限性導致支持不足。另外，由于數據源是流式的，在數據具有上下文關系的情況下，數據到達時間的不確定性導致實時處理跟離線處理得出來的結果會有一定的差異。

流式技術架構

在流式計算技術中，需要各個子系統之間相互依賴形成一條數據處理鏈路，才能產出結果最終對外提供實時數據服務。在實際技術選型時，可選的開源技術方案非常多，但是各個方案的整體架構是類似的，只是各個子系統的實現原理不太一樣。另外，流式技術架構中的系統跟離線處理是有交叉的，兩套技術方案并不是完全獨立的，并且在業界中有合并的趨勢。

各個子系統按功能劃分的話，主要分為以下幾部分：

1．數據采集

數據的源頭，一般來自于各個業務的日志服務器（例如網站的瀏覽行為日志、訂單的修改日志等），這些數據被實時采集到數據中間件中，供下游實時訂閱使用。

2．數據處理

數據被采集到中間件中后，需要下游實時訂閱數據，并拉取到流式計算系統的任務中進行加工處理。這里需要提供流計算引擎以支持流式任務的執行。

**3．數據存儲
**
數據被實時加工處理（比如聚合、清洗等）后，會寫到某個在線服務的存儲系統中，供下游調用方使用。這里的寫操作是增量操作，并且是源源不斷的。

4．數據服務

在存儲系統上會架設一層統一的數據服務層（比如提供HSF接口、HTTP服務等），用于獲取實時計算結果。

整體技術架構如圖所示：

從圖可以看出，在數據采集和數據服務部分實時和離線是公用的，因為在這兩層中都不需要關心數據的時效性。這樣才能做到數據源的統一，避免流式處理和離線處理的不一致。

流式數據模型

在流式計算技術中，需要各個子系統之間相互依賴形成一條數據處理鏈路，才能產出結果最終對外提供實時數據服務。在實際技術選型時，可選的開源技術方案非常多，但是各個方案的整體架構是類似的，只是各個子系統的實現原理不太一樣。另外，流式技術架構中的系統跟離線處理是有交叉的，兩套技術方案并不是完全獨立的，并且在業界中有合并的趨勢。

各個子系統按功能劃分的話，主要分為以下幾部分：

數據模型設計是貫通數據處理過程的，流式數據處理也一樣，需要對數據流建模分層。實時建模跟離線建模非常類似，數據模型整體上分為五層（ODS、DWD、DWS、ADS、DIM）。

由于實時計算的局限性，每一層中并沒有像離線做得那么寬，維度和指標也沒有那么多，特別是涉及回溯狀態的指標，在實時數據模型中幾乎沒有。

整體來看，實時數據模型是離線數據模型的一個子集，在實時數據處理過程中，很多模型設計就是參考離線數據模型實現的。

1．數據分層

在流式數據模型中，數據模型整體上分為五層。

ODS層：跟離線系統的定義一樣，ODS層屬于操作數據層，是直接從業務系統采集過來的最原始數據，包含了所有業務的變更過程，數據粒度也是最細的。在這一層，實時和離線在源頭上是統一的，這樣的好處是用同一份數據加工出來的指標，口徑基本是統一的，可以更方便進行實時和離線間數據比對。例如：原始的訂單變更記錄數據、服務器引擎的訪問日志。

DWD層：DWD層是在ODS層基礎上，根據業務過程建模出來的實時事實明細層，對于訪問日志這種數據（沒有上下文關系，并且不需要等待過程的記錄），會回流到離線系統供下游使用，最大程度地保證實時和離線數據在ODS層和DWD層是一致的。例如：訂單的支付明細表、退款明細表、用戶的訪問日志明細表。

DWS層：訂閱明細層的數據后，會在實時任務中計算各個維度的匯總指標。如果維度是各個垂直業務線通用的，則會放在實時通用匯總層，作為通用的數據模型使用。比如電商網站的賣家粒度，只要涉及交易過程，就會跟這個維度相關，所以賣家維度是各個垂直業務的通用維度，其中的匯總指標也是各個業務線共用的。例如：電商數據的幾大維度的匯總表（賣家、商品、買家）。

ADS層：個性化維度匯總層，對于不是特別通用的統計維度數據會放在這一層中，這里計算只有自身業務才會關注的維度和指標，跟其他業務線一般沒有交集，常用于一些垂直創新業務中。例如：手機淘寶下面的某個愛逛街、微淘等垂直業務。

DIM層：實時維表層的數據基本上都是從離線維表層導出來的，抽取到在線系統中供實時應用調用。這一層對實時應用來說是靜態的，所有的ETL處理工作會在離線系統中完成。維表在實時應用的使用中跟離線稍有區別，后面章節中會詳細說明。例如：商品維表、賣家維表、買家維表、類目維表。

2．多流關聯

在流式計算中常常需要把兩個實時流進行主鍵關聯，以得到對應的實時明細表。在離線系統中兩個表關聯是非常簡單的，因為離線計算在任務啟動時已經可以獲得兩張表的全量數據，只要根據關聯鍵進行分桶關聯就可以了。但流式計算不一樣，數據的到達是一個增量的過程，并且數據到達的時間是不確定的和無序的，因此在數據處理過程中會涉及中間狀態的保存和恢復機制等細節問題。

比如A表和B表使用ID進行實時關聯，由于無法知道兩個表的到達順序，因此在兩個數據流的每條新數據到來時，都需要到另外一張表中進行查找。如A表的某條數據到達，到B表的全量數據中查找，如果能查找到，說明可以關聯上，拼接成一條記錄直接輸出到下游；但是如果關聯不上，則需要放在內存或外部存儲中等待，直到B表的記錄也到達。多流關聯的一個關鍵點就是需要相互等待，只有雙方都到達了，才能關聯成功。

下面通過例子（訂單信息表和支付信息表關聯）來說明，如圖示。

在上面的例子中，實時采集兩張表的數據，每到來一條新數據時都在內存中的對方表截至當前的全量數據中查找，如果能查找到，則說明關聯成功，直接輸出；如果沒查找到，則把數據放在內存中的自己表數據集合中等待。另外，不管是否關聯成功，內存中的數據都需要備份到外部存儲系統中，在任務重啟時，可以從外部存儲系統中恢復內存數據，這樣才能保證數據不丟失。因為在重啟時，任務是續跑的，不會重新跑之前的數據。

另外，訂單記錄的變更有可能發生多次（比如訂單的多個字段多次更新），在這種情況下，需要根據訂單ID去重，避免A表和B表多次關聯成功；否則輸出到下游就會有多條記錄，這樣得到的數據是有重復的。

以上是整體的雙流關聯流程，在實際處理時，考慮到查找數據的性能，實時關聯這個步驟一般會把數據按照關聯主鍵進行分桶處理，并且在故障恢復時也根據分桶來進行，以降低查找數據量和提高吞吐量。

3．維表使用

在離線系統中，一般是根據業務分區來關聯事實表和維表的，因為在關聯之前維表的數據就已經就緒了。而在實時計算中，關聯維表一般會使用當前的實時數據（T）去關聯T-2的維表數據，相當于在T的數據到達之前需要把維表數據準備好，并且一般是一份靜態的數據。

為什么在實時計算中這么做呢？主要基于以下幾點的考慮。

數據無法及時準備好：當到達零點時，實時流數據必須去關聯維表（因為不能等待，如果等就失去了實時的特性），而這個時候T-1的維表數據一般不能在零點馬上準備就緒（因為T-1的數據需要在T這一天加工生成），因此去關聯T-2維表，相當于在T-1的一天時間里加工好T-2的維表數據。

無法準確獲取全量的最新數據：維表一般是全量的數據，如果需要實時獲取到當天的最新維表數據，則需要T-1的數據+當天變更才能獲取到完整的維表數據。也就是說，維表也作為一個實時流輸入，這就需要使用多流實時關聯來實現。但是由于實時數據是無序的并且到達時間不確定，因此在維表關聯上有歧義。

數據的無序性：如果維表作為實時流輸入的話，獲取維表數據將存在困難。比如10:00點的業務數據成功關聯維表，得到了相關的維表字段信息，這個時候是否就已經拿到最新的維表數據了呢？其實這只代表拿到截至10:00點的最新狀態數據（實時應用永遠也不知道什么時候才是最新狀態，因為不知道維表后面是否會發生變更）。

因此在實時計算中維表關聯一般都統一使用T-2的數據，這樣對于業務來說，起碼關聯到的維表數據是確定的（雖然維表數據有一定的延時，但是許多業務的維表在兩天之間變化是很少的）。

在有些業務場景下，可以關聯T-1的數據，但T-1的數據是不全的。比如在T-1的晚上22:00點開始對維表進行加工處理，在零點到達之前，有兩個小時可以把數據準備好，這樣就可以在T的時候關聯T-1的數據了，但是會缺失兩個小時的維表變更過程。

另外，由于實時任務是常駐進程的，因此維表的使用分為兩種形式。

全量加載：在維表數據較少的情況下，可以一次性加載到內存中，在內存中直接和實時流數據進行關聯，效率非常高。但缺點是內存一直占用著，并且需要定時更新。例如：類目維表，每天只有幾萬條記錄，在每天零點時全量加載到內存中。

增量加載：維表數據很多，沒辦法全部加載到內存中，可以使用增量查找和LRU過期的形式，讓最熱門的數據留在內存中。其優點是可以控制內存的使用量；缺點是需要查找外部存儲系統，運行效率會降低。例如：會員維表，有上億條記錄，每次實時數據到達時，去外部數據庫中查詢，并且把查詢結果放在內存中，然后每隔一段時間清理一次最近最少使用的數據，以避免內存溢出。

在實際應用中，這兩種形式根據維表數據量和實時性能要求綜合考慮來選擇使用。注：本書中出現的部分專有名詞、專業術語、產品名稱、軟件項目名稱、工具名稱等，是淘寶（中國）軟件有限公司內部項目的慣用詞語，如與第三方名稱雷同，實屬巧合。

連載：阿里巴巴大數據實踐—數據開發平臺>>
連載：阿里巴巴大數據實踐—實時技術>>

數據中臺是企業數智化的新基建，阿里巴巴認為數據中臺是集方法論、工具、組織于一體的，“快”、“準”、“全”、“統”、“通”的智能大數據體系。目前正通過阿里云數據中臺解決方案對外輸出，包括零售、金融、互聯網、政務等領域，其中核心產品有：

• Dataphin，一站式、智能化的數據構建及管理平臺；
• Quick BI，隨時隨地 智能決策；
• Quick Audience，全方位洞察、全域營銷、智能增長；
• Quick A+， 跨多端全域應用體驗分析及洞察的一站式數據化運營平臺；

官方站點：
數據中臺官網 https://dp.alibaba.com

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

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

總結

以上是生活随笔為你收集整理的连载：阿里巴巴大数据实践—实时技术的全部內容，希望文章能夠幫你解決所遇到的問題。

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