優酷視頻搜索是文娛分發場最核心的入口之一，數據源多、業務邏輯複雜，尤其實時系統的質量保障是一個巨大挑戰。如何保障數據質量，如何衡量數據變化對業務的影響？本文會做詳細解答。

一、現狀分析

搜索數據流程如下圖所示，從内容生産到生成索引經曆了複雜的數據處理流程，中間表多達千餘張，實時數據消費即消失，難以追蹤和複現。

從上圖可以看出，整個系統以實時流模式為數據流通主體，業務層面按實體類型打平，入口統一分層解耦，極大的增加了業務的實時性和穩定性。但是另一方面，這種龐大的流式計算和數據業務系統給質量保障帶來了巨大的挑戰。如何從 0 開始，建設實時數據的質量保障體系，同時保證數據對搜索引擎業務的平滑過渡？這是我們面臨的挑戰。

二、實時數據質量保障體系方案

質量保障需要透過現象看本質。通過對架構和業務的分析，可以發現整個流式計算的業務系統有幾個關鍵點：流式計算、數據服務、全鍊路、數據業務（包括搜索引擎的索引和摘要）。整體的質量訴求可以歸類為：

1. 基礎數據内容質量的保障
2. 流式鍊路的數據正确性和及時性保障
3. 數據變化對業務效果的非負向的保障

結合線上、線下、全鍊路閉環的理論體系去設計我們的整體質量保障方案，如下圖所示：

三、線下質量

1．實時 dump

數據測試包含鍊路節點比對、時效性、正确性、一緻性、可用性等方面，依托于阿裡技術資源設計實時 dump 的方案如圖：

2．數據一緻性

一緻性主要是指每個鍊路節點消費的一緻性，重點在于整體鍊路的各個節點的數據處理消費情況保持一緻，通過對數據消費的分時分頻率的比對完成一緻性驗證。方案如下圖：

我們采取不同的數據流頻率輸送給實時鍊路進行消費，利用各層的 dump 機制進行數據 dump，然後取不同的抽樣間隔對 dump 數據計算分析，分為三種不同的數據頻率模式：

• natural-flow：自然消費的數據流，是源于線上真實的數據消息通道，即自然頻率的數據消費，以該模式進行測試更貼合實際業務情景；
• high-frequency：高頻數據流，采用超出真實峰值或者其他設定值的數據頻次輸送給實時消費鍊路，在壓測或者檢測鍊路穩定性中是一個常用的測試策略；
• low-frequency：低頻數據流，采用明顯低于真實值或者特定的低頻次數據輸送給實時消費鍊路。如果數據鍊路中有基于數據量的批量處理策略會暴露的比較明顯，比如批量處理的阈值是 100，那麼在業務低峰時很有可能達不到策略阈值，這批數據就會遲遲不更新，這個批量處理策略可能不是合理。同時低頻次的消費對于實時鍊路處理的一些資源、鍊接的最低可用度這些層面的檢查也是有意義的。

3．數據正确性

數據正确性是對于數據内容的具體值的檢查，總體原則是：

• 首先，高優保障影響用戶體驗的數據；
• 其次，保障業務層直接使用的核心業務相關的數據内容；
• 再次，中間層的核心業務相關數據由于不對外露出，會轉換成業務引擎需要的最終層的業務數據。所以中間層我們采用通用的規則和業務規則來做基礎數據質量保障，同時對上下遊數據内容變化進行 diff 對比，保障整個流程處理的準确性。

4．數據可用性

數據可用性指的是數據鍊路生産的最終數據是能夠安全合理使用的，包括存儲、查詢的讀寫效率、數據安全讀寫、對不同的使用方提供的數據使用保持一緻性等。

可用性保障主要關注數據的存儲、查詢、數據協議（數據結構）三個大的維度，衡量的标準重點關注三個方面：

• 易讀寫：數據的結構化存儲和寫入必須是高效合理的；
• 服務一緻：數據在結構化存儲後，對外提供的服務有很多種，比如 PB 協議、API、SDK 等，需要根據業務去考量。比如 SDK、PB 等對外提供使用的方式會涉及協議版本，不同的版本可能數據結構不一緻導緻對外使用的數據不一緻性；
• 安全可靠：重點關注存儲穩定、可靠、高效，兼顧效率和穩定性，同時更要關注安全性，防範随意改寫數據、惡意 dump 等嚴重影響線上數據使用安全的風險。

5．時效性

由于實時鍊路的流式特性和多實體多次更新的特性，在測試時效性時核心問題有兩點：

• 如何去跟蹤确定一條唯一的消息在整個鍊路的消費情況；
• 如何低成本獲取每個節點過程的數據鍊路時間。

我們抽象出一個 trace wraper 的流式 trace 模型如下圖：

獲取鍊路過程的每個節點的時間，包括傳輸時間和處理時間。對于 track-wraper 需要約定統一的 track 規範和格式，并且保證這部分的信息對業務數據沒有影響，沒有增加大的性能開銷。如下圖，我們最終的信息中經過 trace&track-wraper 帶出來的 trak-info，采用 json 格式方便 track-info 的擴展性。

這樣就很容易獲取到任意信息，計算每個節點的時間：

我們也可以通過抽樣計算一些統計指标衡量時效：

對于時效性有明顯異常的數據可以篩選出來，進行持續優化。

6．性能測試

實時數據鍊路本質是一套全鍊路數據計算服務，所以我們也需要測試它的性能情況。

第一步，我們先具體化全鍊路的待測系統服務

包括兩部分的性能，Bigku 的反查服務，即 HSF 服務，再就是 blink 的計算鍊路節點。

第二步，準備數據和工具

壓測需要的業務數據就是消息。數據準備有兩種方式，一種是盡可能模拟真實的消息數據，我們隻要獲取消息内容進行程序自動模拟即可；另外一種會采用更真實的業務數據 dump 引流，進行流量回放。

由于數據鍊路的特性，對壓測鍊路施壓就是轉成發送消息數據，那麼如何控制數據發送呢？有兩種方式：第一種我們開發一個發送消息的服務接口，轉變成常規的接口服務壓測，然後可以采用阿裡的任何壓測工具，整個測試就變成常規的性能測試；第二種我們可以利用 blink 消息回追的機制，重複消費曆史消息進行壓測，不過這種方法有弊端，無法控制消息的頻率。

7．壓測和指标收集

根據業務情況來收集指标，指标包括服務本身的指标和資源指标，可以參考我們的部分性能測試報告示例（數據有截斷）：

四、線上質量

1．服務穩定性保障

穩定性包括兩個層面，一是實時計算任務鍊路的每個節點的穩定性，二是内置服務的穩定性。

2．實時計算

由于實時計算采用全 blink 的計算方式，我們可以利用 blink 系統本身的特性來做任務的監控。每個節點的任務都需要配置穩定性指标的監控，包括 rps、delay、failover 等。效果示例如下：

3．實體服務

實體服務是 HSF 服務，采用阿裡統一的監控平台來完成整體服務能力的監控，示例如圖：

整體指标包含以下内容：

4．數據消費保障

在數據消費層面，重點關注每個鍊路層級的消費能力和異常情況。基于積累的 track-report 能力進行數據統計，結合平台完備的基礎能力來完成消費保障。分為兩層：

核心層：消息出口的實體消息統計監控，包括整體數量和消息内容分類統計監控。如圖示例：

中間層：包括每個實體消息處理的 accept，處理邏輯層的 success、fail、skip 指标，便于我們實時知曉每個鍊路層收到的消息、成功處理、錯誤和合理異常等消費能力情況。如圖示例：

5．數據内容保障

數據内容層，建設綜合數據更新、數據内容檢查、業務效果三位一體的精準數據檢查，達到數據生産、消費、可用性的閉環檢測，如圖所示：

從圖中可以看出，我們數據内容保障分為三部分：

1）sampler：抽樣器，通過 blink 實時消費消息在鍊路中抽取待測數據，通常是隻抽取數據 ID；抽樣策略分間隔和随機兩種。間隔策略就是取固定時間間隔的特定數據進行檢查；随機則根據一定的随機算法策略來抽樣數據進行檢查。

2）data-monitor：是做數據内容檢查，包括更新時效性和數據特征屬性檢查。

3）effect-monitor：數據正常更新之後，對在線業務實時産生的效果影響進行檢查，檢查的核心點包括搜索的兩大基本效果——召回和排序，以及用戶體驗相關的數據屬性的檢查。

部分數據實時效果示例圖：

6．實時幹預與自動修複

實時幹預通道，如下圖：

實時幹預系統會根據不同的幹預需求，對消息内容和幹預機制進行消息組裝和通道分發。

1）當主通道業務鍊路正常時，若需要強制更新一個 ID 維度的數據，隻需要輸入 ID 走正常主鍊路更新即可。

2）當需要強制幹預某些具體的數據内容到指定的消息通道時，則可進行數據内容級别的更詳細的精準幹預。

3）緊急強制幹預，是指當主鍊路中間層處理有較大延遲或者完全阻塞時，會造成下遊業務層數據無法正常獲取輸入。通過主邏輯全 copy 的機制建立了一個 VIP 的消息通道，通過 VIP 通道去直接幹預出口消息，保證業務數據正常能進行優先更新。

五、質量效能

效能層面主要指：研發能快速自測上線，線上問題能高效排查定位這兩個維度，以期達到保證快速疊代、節省人力投入的目标。所以我們提供了實時 debug 和實時全鍊路 trace 透視兩大提效體系。

1．實時 debug

實時 debug 是基于實時消息通道能力和 debug 機制建立的一套服務，在研發自測、問題複現等場景有很大用途，可以通過 debug 模式詳細了解鍊路的業務層處理細節，業務層隻需要按數據需求自主定制 debug 内容，無需其他接入成本，具備很強的通用性和擴展性。

平台效果圖：

填入節目 ID，發送消息就會自動進入實時 debug 模式。

同時還配備了指定消息内容的專家模式，方便研發進行單獨的消息内容制定化測試和幹預。

2．全鍊路 trace

我們提煉了一個全鍊路實時 trace 的通用模型，同時做更精細定制化的 trace 機制。結合實時業務鍊路邏輯視圖，來看下 trace 的系統實現：

鍊路層視角，目前整體分為 4 個業務塊，數據流按順序進行展示：

1）bigku_service 展示了當時消息的鏡像數據

2） mid_show_f 為算法層面的基礎特征，即一級特征，包含了業務信息和系統信息（工程關注的指标數據，主要用來指導優化）。

3）sum_video_f 和 ogc 屬于搜索鍊路上的數據，一般在節目裡面會有一些較為複雜的截斷邏輯，通過字典表的形式提供數據層的透視視角，可以看到鍊路的全部信息。

六、産品體驗實時自動化保障

我們在實時數據内容質量方面做了融合效果監控的質量方案，建立了實時發現問題、實時定位、實時修複的閉環鍊路效果保障體系，起到了很好的效果。體系方案如下圖：

作者介紹： 阿裡文娛測試開發專家 熙闫

,

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!

查看全部