摘要

本文深入探討了大數據治理域中的實時數據開發，重點介紹了流式數據處理的核心價值、特點、技術挑戰、典型能力和應用場景。同時，詳細闡述了流式技術架構，包括數據采集、處理、存儲和服務等環節，并針對大促場景提出了相應的技術措施，如實時任務優化、數據鏈路高可用和系統壓測等，旨在為實時業務提供高效、穩定的數據支持。

1. 實時數據開發簡介

實時數據開發的爆發是業務需求與技術能力共同作用的結果，未來隨著AIoT和元宇宙等場景深化，實時數據處理將逐步成為企業數據架構的默認選項，而非補充方案。開發者需掌握流式技術棧，同時關注實時與離線系統的協同設計。實時數據開發是近年來隨著大數據、物聯網、人工智能等技術快速發展而興起的重要領域，其背景和驅動力主要來自以下幾個方面：

1.1. 業務需求的實時化

• 即時決策需求：金融交易、電商促銷、交通調度等領域需要毫秒級響應，傳統批處理（TSP）無法滿足。
• 用戶體驗升級：如推薦系統（抖音、淘寶）、實時風險控制（反欺詐）等場景要求數據“新鮮度”。
• IoT與邊緣計算：傳感器、工業設備等產生的數據需實時處理（如預測性維護）。

1.2. 技術演進推動

• 流式計算框架成熟：Apache Kafka（消息隊列）、Flink（低延遲計算）、Spark Streaming等開源技術的普及。
• 云原生與Serverless：AWS Kinesis、Google Pub/Sub等托管服務降低了實時開發門檻。
• 硬件性能提升：SSD、高速網絡（5G）、GPU/TPU加速了數據處理效率。

1.3. 行業場景爆發

• 互聯網：實時用戶行為分析（點擊流）、A/B測試、廣告競價（RTB）。
• 工業4.0：生產線監控、設備異常檢測。
• 智慧城市：交通流量預測、應急事件響應。
• 金融科技：高頻交易、實時風控、反洗錢（AML）。

1.4. 數據架構變革

• Lambda/Kappa架構的爭議：從批流分離到流批一體（如Flink的統一計算模型）。
• 實時數倉興起：替代傳統T+1離線數倉，支持實時OLAP（如Apache Doris、ClickHouse）。
• 數據湖倉一體化：Delta Lake、Iceberg等支持實時數據更新。

1.5. 挑戰與趨勢

• 技術復雜度：需平衡一致性（Exactly-Once）、延遲和吞吐量。
• 成本問題：實時集群資源消耗遠高于離線處理。
• 新興方向：實時AI（在線模型推理）、時序數據庫（Prometheus、InfluxDB）、聯邦學習（邊緣實時協作）。

2. 流式數據處理特點

流式數據處理的核心價值在于用更低的延遲挖掘數據時效性，但需權衡準確性、一致性和系統復雜度。現代流式計算框架（如Flink）通過事件時間語義、精確一次（Exactly-Once）等機制逐步解決了早期流處理的缺陷，使其成為實時業務的核心支撐技術。流式數據處理（Stream Processing）是針對連續無界數據流的實時計算模式，與傳統的批處理（Batch Processing）有顯著差異。其核心特點如下：

2.1. 數據特征

• 無界性（Unbounded）：數據流理論上無限持續，沒有明確的終點（如傳感器數據、用戶點擊流）。
• 時序性（Time-Series）：數據嚴格依賴時間順序，亂序或延遲會影響結果準確性。
• 高吞吐（High Throughput）：數據可能以極高速率生成（如IoT設備每秒百萬條記錄）。

2.2. 處理模式

• 實時/近實時（Low Latency）：處理延遲從毫秒到秒級，遠快于批處理的分鐘/小時級。
• 增量計算（Incremental）：每條或每批數據到達時立即處理，無需等待全量數據。
• 持續運行（Continuous）：任務長期運行，7x24小時不間斷（需容錯機制保障）。

2.3. 技術挑戰

• 亂序與遲到數據：需通過水位線（Watermark）、事件時間（Event Time）等機制處理。
• 狀態管理：需維護中間狀態（如窗口聚合結果），并支持故障恢復（如Checkpoint）。
• 資源動態調整：應對流量突增（如電商大促）需彈性擴縮容（如K8s+Flink）。

2.4. 典型能力

• 窗口計算（Window）：

• • 時間窗口（Tumbling/Sliding/Session）。
  • 計數窗口（每N條數據觸發）。

• 流式關聯（Stream Joins）：如雙流Join（支付+訂單流）、維表關聯（實時查詢Redis）。
• 復雜事件處理（CEP）：模式匹配（如檢測“連續登錄失敗”）。

2.5. 與批處理的對比

維度	流式處理	批處理
數據范圍	無界數據流	有界數據集
延遲	毫秒~秒級	分鐘~小時級
計算邏輯	增量處理	全量處理
資源占用	長期占用（需高可用）	短期占用（任務結束釋放）
典型框架	Flink、Kafka Streams	Spark（批模式）、MapReduce

2.6. 應用場景

• 實時監控：服務器指標異常檢測（如Prometheus）。
• 實時推薦：用戶行為即時分析（如抖音“劃一推一”）。
• 金融風控：信用卡欺詐交易實時攔截。
• 物流調度：網約車訂單動態派單。

3. 流式技術架構

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

1. 數據采集

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

1. 數據處理

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

1. 數據存儲

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

1. 數據服務

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

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

3.1. 數據采集

數據采集是整個數據處理鏈路的源頭，是所有數據處理鏈路的根節點，既然需要做到實時計算，那么自然就需要做到實時采集了。所采集的數據都來自于業務服務器，從所采集的數據種類來看，主要可以劃分為兩種：

• 數據庫變更日志，比如MySQL的binlog日志、HBase的hlog日志、OceanBase的變更日志、Oracle的變更日志等。
• 引擎訪問日志，比如用戶訪問網站產生的Apache引擎日志、搜索引擎的接口查詢日志等。

不管是數據庫變更日志還是引擎訪問日志，都會在業務服務器上落地成文件，所以只要監控文件的內容發生變化，采集工具就可以把最新的數據采集下來。一般情況下，出于吞吐量以及系統壓力上的考慮，并不是新增一條記錄就采集一次，而是基于下面的原則，按批次對數據進行采集。

• 數據大小限制：當達到限制條件時，把目前采集到的新數據作為一批（例如512KB寫一批）
• 時間閾值限制：當時間達到一定條件時，也會把目前采集到的新數據作為一批，避免在數據量少的情況下一直不采集（例如30秒寫一批)

只要上面的其中一個條件達到了，就會被作為一批新數據采集到數據中間件中。這兩個條件的參數需要根據業務的需求來設定，當批次采集頻繁時，可以降低延時，但必然會導致吞吐量下降。

對于采集到的數據需要一個數據交換平臺分發給下游，這個平臺就是數據中間件。數據中間件系統有很多實現方式，比如開源的系統有Kafka,而阿里巴巴集團內部用得比較多的是TimeTunnel(原理和Kafka類似)，還有MetaQ、Notify等消息系統。從圖5.3可以看出，消息系統是數據庫變更節點的上游，所以它的延時比數據中間件低很多，但是其支持的吞吐量有限。因此，消息系統一般會用作業務數據庫變更的消息中轉，比如訂單下單、支付等消息。對于其他較大的業務數據（每天幾十TB的容量），一般會通過數據中間件系統來中轉，雖然它的延時在秒級，但是其支持的吞吐量高。消息系統和數據中間件的性能對比如表5.1所示。

另外，在一些情況下，有些業務并沒有通過消息系統來對數據庫進行更新（比如有些子業務的訂單數據是通過同步方式導入MySQL的）。

也就是說，從消息系統中獲取的數據并不是最全的，而通過數據庫變更日志拿到的業務變更過程數據肯定是全的。因此，為了和離線數據源保持一致，一般都是通過數據中間件來采集數據庫變更數據這種形式來獲取實時數據的（這需要在數據處理層對業務主鍵進行merge處理，比如一筆訂單可能會被變更多次，會有多條變更記錄，這時就需要進行merge拿到最新的數據)。

時效性和吞吐量是數據處理中的兩個矛盾體，很多時候需要從業務的角度來權衡使用什么樣的系統來做數據中轉

3.2. 數據處理

實時計算任務部署在流式計算系統上，通過數據中間件獲取到實時源數據后進行實時加工處理。在各大互聯網公司中，有各種開源的和非開源的流計算引擎系統在使用。在業界使用比較廣泛的是Twitter開源的Storm系統、雅虎開源的S4系統、Apache的Spark Streaming,以及最近幾年興起的Flik。這些系統的整體架構大同小異，但是很多細節上的實現方式不太一樣，適用于不同的應用場景。

在阿里巴巴集團內使用比較多的是阿里云提供的StreamCompute系統，作為業界首創的全鏈路流計算開發平臺，涵蓋了從數據采集到數據生產各個環節，力保流計算開發嚴謹、可靠。其提供的SQL語義的流式數據分析能力(StreamSQL),讓流數據分析門檻不再存在。它在Storm的基礎上包裝了一層SQL語義，方便開發人員通過寫SQL就可以實現實時計算，不需要關心其中的計算狀態細節，大大提高了開發效率，降低了流計算的門檻。當然，它也支持傳統模式的開發，就像Hadoop中的Hive和MapReduce的關系一樣，根據不同的應用場景選擇不同的方式。另外，StreamCompute還提供了流計算開發平臺，在這個平臺上就可以完成應用的相關運維工作，不需要登錄服務器操作，極大地提高了運維效率。

下面以Storm為例，簡單講一下流數據處理的原理。實時應用的整個拓撲結構是一個有向無環圖（詳情可參考Apache Storm的官網：

• spout:拓撲的輸入，從數據中間件中讀取數據，并且根據自定義的分發規則發送給下游的bolt,可以有多個輸入源。
• bot:業務處理單元，可以根據處理邏輯分為多個步驟，其相互之間的數據分發規則也是自定義的。

實時數據處理應用出于性能考慮，計算任務往往是多線程的。一般會根據業務主鍵進行分桶處理，并且大部分計算過程需要的數據都會放在內存中，這樣會大大提高應用的吞吐量。當然，為了避免內存溢出，內存中過期的數據需要定時清理，可以按照LRU（最近最少使用)算法或者業務時間集合歸類清理（比如業務時間屬于T1的，會在今天凌晨進行清理)。下面就實時任務遇到的幾個典型問題進行講解。

3.2.1. 去重指標

在BI(商業智能)統計類實時任務中，對于資源的消耗有一類指標是非常高的，那就是去重指標。由于實時任務為了追求處理性能，計算邏輯一般都是在內存中完成的，中間結果數據也會緩存在內存中，這就帶來了內存消耗過多的問題。在計算去重時，勢必要把去重的明細數據保存下來，當去重的明細數據達到上億甚至幾十億時，內存中放不下了，怎么辦？這時需要分兩種情況去看：

• 精確去重。在這種情況下，明細數據是必須要保存下來的，當遇到內存問題時，可以通過數據傾斜來進行處理，把一個節點的內存壓力分到多個節點上。
• 模糊去重。在去重的明細數據量非常大，而業務的精度要求不高的情況下，可以使用相關的去重算法，把內存的使用量降到千分之一甚至萬分之一，以提高內存的利用率。

1. 布隆過濾器

該算法是位數組算法的應用，不保存真實的明細數據，只保存明細數據對應哈希值的標記位。當然，會出現哈希值碰撞的情況，但是誤差率可以控制，計算出來的去重值比真實值小。采用這個算法存儲1億條數據只需要100多MB的空間。

適用場景：統計精度要求不高，統計維度值非常多的情況。比如統計全網各個商家的UV數據，結果記錄數達到上千萬條。因為在各個維度之間，布隆過濾器是可以共用的。

1. 基數估計

該算法也是利用哈希的原理，按照數據的分散程度來估算現有數集的邊界，從而得出大概的去重值總和。這里估算的去重值可能比真實值大，也可能比真實值小。采用這個算法存儲1億條數據只需要幾KB的內存。

適用場景：統計精度要求不高，統計維度非常粗的情況。比如整個大盤的UV數據，每天的結果只有一條記錄。基數估計在各個維度值之間不能共用，比如統計全天小時的UV數據，就需要有24個基數估計對象，因此不適合細粒度統計的場景。

3.2.2. 數據傾斜

數據傾斜是ETL中經常遇到的問題，比如計算一天中全網訪客數或者成交額時，最終的結果只有一個，通常應該是在一個節點上完成相關的計算任務。在數據量非常大的時候，單個節點的處理能力是有限的，必然會遇到性能瓶頸。這時就需要對數據進行分桶處理，分桶處理和離線處理的思路是一樣的。

1. 去重指標分桶

通過對去重值進行分桶Hash,相同的值一定會被放在同一個桶中去重，最后再把每個桶里面的值進行加和就得到總值，這里利用了每個桶的CPU和內存資源。

1. 非去重指標分桶

數據隨機分發到每個桶中，最后再把每個桶的值匯總，主要利用的是各個桶的CPU能力。

1. 事務處理

由于實時計算是分布式處理的，系統的不穩定性必然會導致數據的處理有可能出現失敗的情況。比如網絡的抖動導致數據發送不成功、機器重啟導致數據丟失等。在這些情況下，怎么做到數據的精確處理呢？

上面提到的幾個流計算系統幾乎都提供了數據自動ACK、失敗重發以及事務信息等機制。

1. 超時時間：由于數據處理是按照批次來進行的，當一批數據處理超時時，會從拓撲的spout端重發數據。另外，批次處理的數據量不宜過大，應該增加一個限流的功能（限定一批數據的記錄數或者容量等)，避免數據處理超時。
2. 事務信息：每批數據都會附帶一個事務D的信息，在重發的情況下，讓開發者自己根據事務信息去判斷數據第一次到達和重發時不同的處理邏輯。
3. 備份機制：開發人員需要保證內存數據可以通過外部存儲恢復，因此在計算中用到的中間結果數據需要備份到外部存儲中。

上面的這些機制都是為了保證數據的冪等性。

3.3. 數據存儲

實時任務在運行過程中，會計算很多維度和指標，這些數據需要放在一個存儲系統中作為恢復或者關聯使用。其中會涉及三種類型的數據：

中間計算結果一在實時應用處理過程中，會有一些狀態的保存(比如去重指標的明細數據)，用于在發生故障時，使用數據庫中的數據恢復內存現場。

最終結果數據一指的是通過ETL處理后的實時結果數據，這些數據是實時更新的，寫的頻率非常高，可以被下游直接使用。

維表數據一在離線計算系統中，通過同步工具導入到在線存儲系統中，供實時任務來關聯實時流數據。后面章節中會講到維表的使用方式。

數據庫分為很多種類型，比如關系型數據庫、列式數據庫、文檔數據庫等，那么在選擇實時任務所使用的數據庫時應該注意哪些特征呢？

前面提到實時任務是多線程處理的，這就意味著數據存儲系統必須能夠比較好地支持多并發讀寫，并且延時需要在毫秒級才能滿足實時的性能要求。在實踐中，一般使用HBase、Tair、MongoDB等列式存儲系統。由于這些系統在寫數據時是先寫內存再落磁盤，因此寫延時在毫秒級，讀請求也有緩存機制，重要的是多并發讀時也可以達到毫秒級延時。

但是這些系統的缺點也是比較明顯的，以HBase為例，一張表必須要有rowkey,而rowkey是按照ASCII碼來排序的，這就像關系型數據庫的索引一樣，rowkey的規則限制了讀取數據的方式。如果業務方需要使用另一種讀取數據的方式，就必須重新輸出rowkey。從這個角度來看，HBase沒有關系型數據庫方便。但是HBase的一張表能夠存儲幾TB甚至幾十TB的數據，而關系型數據庫必須要分庫分表才能實現這個量級的數據存儲。因此，對于海量數據的實時計算，一般會采用非關系型數據庫，以應對大量的多并發讀寫。

1. 表名設計

設計規則：匯總層標識+數據域+主維度+時間維度例如：dws trd slr dtr,表示匯總層交易數據，根據賣家(slr)主維度+0點截至當日(dtr)進行統計匯總。這樣做的好處是，所有主維度相同的數據都放在一張物理表中，避免表數量過多，難以維護。另外，可以從表名上直觀地看到存儲的是什么數據內容，方便排查問題。

1. rowkey設計

設計規則：MD5+主維度+維度標識+子維度1+時間維度子維度2，

例如：賣家ID的MD5前四位+賣家ID+app+一級類目ID+ddd+二級類目ID。以MD5的前四位作為rowkey的第一部分，可以把數據散列，讓服務器整體負載是均衡的，避免熱點問題。在上面的例子中，賣家D屬于主維度，在查數據時是必傳的。每個統計維度都會生成一個維度標識，以便在rowkey上做區分。

3.4. 數據服務

實時數據落地到存儲系統中后，使用方就可以通過統一的數據服務獲取到實時數據。比如下一章將要講到的OneService,其好處是：

• 不需要直連數據庫，數據源等信息在數據服務層維護，這樣當存儲系統遷移時，對下游是透明的。
• 調用方只需要使用服務層暴露的接口，不需要關心底層取數邏輯的實現。
• 屏蔽存儲系統間的差異，統一的調用日志輸出，便于分析和監控下游使用情況。

4. 流式數據模型

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

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

整體來看，實時數據模型是離線數據模型的一個子集，在實時數據處理過程中，很多模型設計就是參考離線數據模型實現的。下面從數據分層、多流關聯、維表使用這三個方面來詳細說明。

4.1. 數據分層

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

1. ODS層

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

1. DWD層

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

1. DWS層

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

1. ADS層

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

1. DIM層

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

下面通過簡單的例子來說明每一層存儲的數據。

1. ODS層：訂單粒度的變更過程，一筆訂單有多條記錄。
2. DWD層：訂單粒度的支付記錄，一筆訂單只有一條記錄。
3. DWS層：賣家的實時成交金額，一個賣家只有一條記錄，并且指標在實時刷新。
4. ADS層：外賣地區的實時成交金額，只有外賣業務使用。
5. DM層：訂單商品類目和行業的對應關系維表。

其中，ODS層到DM層的ETL處理是在離線系統中進行的，處理完成后會同步到實時計算所使用的存儲系統。ODS層和DWD層會放在數據中間件中，供下游訂閱使用。而DWS層和ADS層會落地到在線存儲系統中，下游通過接口調用的形式使用。

在每一層中，按照重要性劃分為P0、P1、P2、P3等級，P0屬于最高優先級保障。根據不同的優先級給實時任務分配不同的計算和存儲資源，力求重要的任務可以得到最好的保障。

4.2. 多流關聯

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

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

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

另外，訂單記錄的變更有可能發生多次（比如訂單的多個字段多次更新)，在這種情況下，需要根據訂單D去重，避免A表和B表多次關聯成功；否則輸出到下游就會有多條記錄，這樣得到的數據是有重復的。以上是整體的雙流關聯流程，在實際處理時，考慮到查找數據的性能，實時關聯這個步驟一般會把數據按照關聯主鍵進行分桶處理，并且在故障恢復時也根據分桶來進行，以降低查找數據量和提高吞吐量。

4.3. 維表使用

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

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

1. 數據無法及時準備好

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

1. 無法準確獲取全量的最新數據

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

1. 數據的無序性

如果維表作為實時流輸入的話，獲取維表數據將存在困難。比如10:00點的業務數據成功關聯維表，得到了相關的維表字段信息，這個時候是否就已經拿到最新的維表數據了呢？其實這只代表拿到截至10:00點的最新狀態數據（實時應用永遠也不知道什么時候才是最新狀態，因為不知道維表后面是否會發生變更)。因此在實時計算中維表關聯一般都統一使用T-2的數據，這樣對于業務來說，起碼關聯到的維表數據是確定的（雖然維表數據有一定的延時，但是許多業務的維表在兩天之間變化是很少的)。在有些業務場景下，可以關聯T1的數據，但T-1的數據是不全的。比如在T1的晚上22：00點開始對維表進行加工處理，在零點到達之前，有兩個小時可以把數據準備好，這樣就可以在T的時候關聯T1的數據了，但是會缺失兩個小時的維表變更過程。另外，由于實時任務是常駐進程的，因此維表的使用分為兩種形式。

• 全量加載：在維表數據較少的情況下，可以一次性加載到內存中，在內存中直接和實時流數據進行關聯，效率非常高。但缺點是內存一直占用著，并且需要定時更新。例如：類目維表，每天只有幾萬條記錄，在每天零點時全量加載到內存中。
• 增量加載：維表數據很多，沒辦法全部加載到內存中，可以使用增量查找和LRU過期的形式，讓最熱門的數據留在內存中。其優點是可以控制內存的使用量；缺點是需要查找外部存儲系統，運行效率會降低。例如：會員維表，有上億條記錄，每次實時數據到達時，去外部數據庫中查詢，并且把查詢結果放在內存中，然后每隔一段時間清理一次最近最少使用的數據，以避免內存溢出。

在實際應用中，這兩種形式根據維表數據量和實時性能要求綜合考慮來選擇使用。

5. 大促挑戰與保障

5.1. 大促特征

大促和日常比較，在數據量以及要求上有非常大的區別，日常不怎么關注的點，在大促的時候會被放大，并且一天中的峰值特別明顯，數據量是其他時間點的幾倍甚至數十倍，這對系統的抗壓能力要求非常高，不能因為洪流的到來而把系統壓垮。

1. 毫秒級延時

大促期間，業務方和用戶都會對實時數據非常關注，特別是在跨過零點的時候，第一個實時數字的跳動對業務方來說意義重大，預示著大促狂歡節真正開始。其他的產品，例如全球媒體直播大屏，更是要求延時達到毫秒級。這種要求吞吐量和延時兼得的情況，必須要做一些有針對性的優化工作才能滿足要求。

1. 洪峰明顯

大促就是全國乃至全世界的狂歡節，零點開售時的峰值陡峰是非常明顯的，一般是日常峰值的幾十倍，這對數據處理鏈路的每個系統都是巨大的挑戰。因此，在大促前會進行多次全鏈路壓測和預案梳理，確保系統能夠承載住洪峰的沖擊。

1. 高保障性

由于關注的人非常多，只要出現數據延遲或者數據質量的問題，業務方的反彈就比較大，并且會第一時間感知到數據異常。因此，在大促期間一般都要求高保障性，一些特殊的情況甚至需要做到強保障。對于強保障的數據，需要做多鏈路冗余（從采集、處理到數據服務整個數據鏈路都需要做物理隔離)（見圖5.7）。當任何一條鏈路出現問題時，都能夠一鍵切換到備鏈路，并且需要對業務方透明，讓下游感知不到有鏈路上的切換（由于各個鏈路計算的速度有一定的差異，會導致數據在切換時出現短時間下跌的情況，使用方需要做指標大小的判斷，避免指標下跌對用戶造成困擾)。

1. 公關特性

大促期間，數據及時對公眾披露是一項重要的工作，這時候要求實時計算的數據質量非常高。這里面涉及主鍵的過濾、去重的精準和口徑的統一等一系列問題，只有把每一個環節都做好才能保障和離線的數據一致。大促是一場對數據計算的高吞吐量、低延時、高保障性、高準確性的挑戰。

5.2. 大促技術措施

5.2.1. 實時任務優化

大促前的優化工作在實時計算中顯得尤為重要，如果吞吐量跟不上的話，也就失去了實時的特性。吞吐量不佳原因非常多，有些跟系統資源有關，有些跟實現方式有關，以下幾點是實時任務優化中經常需要考慮的要素。

1. 獨占資源和共享資源的策略

在一臺機器中，共享資源池可以被多個實時任務搶占，如果一個任務在運行時80%以上的時間都需要去搶資源，這時候就需要考慮給它分配更多的獨占資源，避免搶不到CPU資源導致吞吐量急劇下降。

1. 合理選擇緩存機制，盡量降低讀寫庫次數

內存讀寫性能是最好的，根據業務的特性選擇不同的緩存機制，讓最熱和最可能使用的數據留在內存中，讀寫庫次數降低后，吞吐量自然就上升了。

1. 計算單元合并，降低拓撲層級

拓撲結構層級越深，性能越差，因為數據在每個節點間傳輸時，大部分是需要經過序列化和反序列化的，而這個過程非常消耗CPU和時間。

1. 內存對象共享，避免字符拷貝

在海量數據處理中，大部分對象都是以字符串形式存在的，在不同線程間合理共享對象，可以大幅降低字符拷貝帶來的性能消耗，不過要注意不合理使用帶來的內存溢出問題。

1. 在高吞吐量和低延時間取平衡

高吞吐量和低延時這兩個特性是一對矛盾體，當把多個讀寫庫操作或者ACK操作合并成一個時，可以大幅降低因為網絡請求帶來的消耗，不過也會導致延時高一些，在業務上衡量進行取舍。

5.2.2. 數據鏈路高可用

實時數據的處理鏈路非常長（數據同步一→數據計算一數據存儲一數據服務)，每一個環節出現問題，都會導致實時數據停止更新。實時計算屬于分布式計算的一種，而單個節點故障是常態的，這種情況在直播大屏中表現特別明顯，因為數據不再更新，所有的用戶都會發現數據出現了問題。因此，為了保障實時數據的可用性，需要對整條計算鏈路都進行多鏈路搭建，做到多機房容災，甚至異地容災（見圖5.8）。

由于造成鏈路問題的情況比較多，并且一般不能在秒級定位到原因，因此會通過工具比對多條鏈路計算的結果數據，當某條鏈路出現問題時，它一定會比其他鏈路計算的值小，并且差異會越來越大。這時候會一鍵切換到備鏈路，并且通過推送配置的形式讓其秒級生效，所有的接口調用會立刻切換到備鏈路，對直播大屏完全透明，并且用戶也感知不到故障的發生。

5.2.3. 系統進行壓測

在大促備戰中，會對實時鏈路進行多次壓測，主要是模擬“雙11的峰值情況，驗證系統是否能夠正常運行。壓測都是在線上環境中進行的，分為數據壓測和產品壓測。

數據壓測主要是蓄洪壓測，就是把幾個小時甚至幾天的數據積累下來，并在某個時刻全部放開，模擬“雙11”洪峰流量的情況，這里面的數據是真實的。比如通過把實時作業的訂閱數據點位調到幾個小時或者幾天前，這時候每一批讀到的數據都是最多的，對實時計算的壓力也最大。

產品壓測還細分為產品本身壓測和前端頁面穩定性測試。

1. 產品本身壓測

收集大屏服務端的所有讀操作的URL,通過壓測平臺進行壓測流量回放，按照QPS:500次/秒的目標進行壓測。在壓測過程中不斷地迭代優化服務端的性能，提升大屏應用處理數據的性能。

1. 前端頁面穩定性測試

將大屏頁面在瀏覽器中打開，并進行8~24小時的前端頁面穩定性測試。監控大屏前端JS對客戶端瀏覽器的內存、CPU等的消耗，檢測出前端JS內存泄漏等問題并修復，提升前端頁面的穩定性。

6. 博文參考

• 《阿里巴巴大數據實戰》