偷偷摘套内射激情视频,久久精品99国产国产精,中文字幕无线乱码人妻,中文在线中文a,性爽19p

億級搜索系統(tǒng)的基石,如何保障實時數(shù)據(jù)質量?

數(shù)據(jù)庫
突然而至的疫情,讓線下娛樂幾乎停擺。全國人民對于線上娛樂需求激增,在家追劇、在家上課、在家互動,還要時刻關注疫情動態(tài)。每時每刻,都有海量用戶在優(yōu)酷搜索自己想看的內(nèi)容。千萬級別的視頻量,幾十億級別的信息量,如何能做到將信息及時有效的透出給用戶?怎樣保障數(shù)據(jù)準確無誤的呈現(xiàn)呢?

 [[319101]]

阿里妹導讀:突然而至的疫情,讓線下娛樂幾乎停擺。全國人民對于線上娛樂需求激增,在家追劇、在家上課、在家互動,還要時刻關注疫情動態(tài)。每時每刻,都有海量用戶在優(yōu)酷搜索自己想看的內(nèi)容。千萬級別的視頻量,幾十億級別的信息量,如何能做到將信息及時有效的透出給用戶?怎樣保障數(shù)據(jù)準確無誤的呈現(xiàn)呢?

阿里文娛有專門的搜索引擎算法團隊做相關的探索??赡阒绬?在算法業(yè)務背后,面對數(shù)億的視頻數(shù)據(jù),還有一支技藝高超的測試團隊,在保障龐大數(shù)據(jù)系統(tǒng)的數(shù)據(jù)質量。

阿里文娛測試開發(fā)專家熙閆將通過本文講述阿里文娛是如何構建實時數(shù)據(jù)質量保障體系,進而提升搜索引擎數(shù)據(jù)全面、快速、準確效果的,希望對大家有啟發(fā)。

一、背景

優(yōu)酷視頻搜索是文娛分發(fā)場的最核心入口之一,數(shù)據(jù)源多、業(yè)務邏輯復雜,尤其是實時系統(tǒng)的質量保障是一個巨大挑戰(zhàn)。如何保障數(shù)據(jù)質量,如何衡量數(shù)據(jù)變化對業(yè)務的影響?本文會做詳細解答。

二、現(xiàn)狀分析

搜索數(shù)據(jù)流程如下圖所示,從內(nèi)容生產(chǎn)到生成索引經(jīng)歷了復雜的數(shù)據(jù)處理流程,中間表多達千余張,實時數(shù)據(jù)消費即消失,難以追蹤和復現(xiàn)。 

 從上圖可以看出,整個系統(tǒng)以實時流模式為數(shù)據(jù)流通主體,業(yè)務層面按實體類型打平,入口統(tǒng)一分層解耦,極大的增加了業(yè)務的實時性和穩(wěn)定性。但是另一方面,這種龐大的流式計算和數(shù)據(jù)業(yè)務系統(tǒng)給質量保障帶來了巨大的挑戰(zhàn),從0到1建設實時數(shù)據(jù)的質量保障體系,同時保證數(shù)據(jù)對搜索引擎業(yè)務的平滑過渡是我們面臨的考驗。

三、實時數(shù)據(jù)質量保障體系方案

質量保障需要透過現(xiàn)象看本質。通過對架構和業(yè)務的分析,可以發(fā)現(xiàn)整個流式計算的業(yè)務系統(tǒng)有幾個關鍵點:流式計算、數(shù)據(jù)服務、全鏈路、數(shù)據(jù)業(yè)務(包括搜索引擎的索引和摘要)。整體的質量訴求可以歸類為:

  1. 基礎數(shù)據(jù)內(nèi)容質量的保障
  2. 流式鏈路的數(shù)據(jù)正確性和及時性保障
  3. 數(shù)據(jù)變化對業(yè)務效果的非負向的保障

結合線上、線下、全鏈路閉環(huán)的理論體系去設計我們的整體質量保障方案,如下圖所示: 

 四、線下質量

1.實時dump

數(shù)據(jù)測試包含鏈路節(jié)點比對、時效性、正確性、一致性、可用性等方面,依托于阿里技術資源設計實時dump的方案如圖:  

 2.數(shù)據(jù)一致性

一致性主要是指每個鏈路節(jié)點消費的一致性,重點在于整體鏈路的各個節(jié)點的數(shù)據(jù)處理消費情況保持一致,通過對數(shù)據(jù)消費的分時分頻率的比對完成一致性驗證。方案如下圖: 

 

我們采取不同的數(shù)據(jù)流頻率輸送給實時鏈路進行消費,利用各層的dump機制進行數(shù)據(jù)dump,然后取不同的抽樣間隔對dump數(shù)據(jù)計算分析,分為三種不同的數(shù)據(jù)頻率模式:

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

3.數(shù)據(jù)正確性 

數(shù)據(jù)正確性是對于數(shù)據(jù)內(nèi)容的具體值的檢查,總體原則是:

首先,高優(yōu)保障影響用戶體驗的數(shù)據(jù);

其次,保障業(yè)務層直接使用的核心業(yè)務相關的數(shù)據(jù)內(nèi)容;

再次,中間層的核心業(yè)務相關數(shù)據(jù)由于不對外露出,會轉換成業(yè)務引擎需要的最終層的業(yè)務數(shù)據(jù)。所以中間層我們采用通用的規(guī)則和業(yè)務規(guī)則來做基礎數(shù)據(jù)質量保障,同時對上下游數(shù)據(jù)內(nèi)容變化進行diff對比,保障整個流程處理的準確性。

4.數(shù)據(jù)可用性

數(shù)據(jù)可用性指的是數(shù)據(jù)鏈路生產(chǎn)的最終數(shù)據(jù)是能夠安全合理使用的,包括存儲、查詢的讀寫效率、數(shù)據(jù)安全讀寫、對不同的使用方提供的數(shù)據(jù)使用保持一致性等。 

可用性保障主要關注數(shù)據(jù)的存儲、查詢、數(shù)據(jù)協(xié)議(數(shù)據(jù)結構)三個大的維度,衡量的標準重點關注三個方面:

  • 易讀寫:數(shù)據(jù)的結構化存儲和寫入必須是高效合理的;
  • 服務一致:數(shù)據(jù)在結構化存儲后,對外提供的服務有很多種,比如PB協(xié)議、API、SDK等,需要根據(jù)業(yè)務去考量。比如SDK、PB等對外提供使用的方式會涉及協(xié)議版本,不同的版本可能數(shù)據(jù)結構不一致導致對外使用的數(shù)據(jù)不一致性;
  • 安全可靠:重點關注存儲穩(wěn)定、可靠、高效,兼顧效率和穩(wěn)定性,同時更要關注安全性,防范隨意改寫數(shù)據(jù)、惡意dump等嚴重影響線上數(shù)據(jù)使用安全的風險。

5.時效性

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

  • 如何去跟蹤確定一條唯一的消息在整個鏈路的消費情況;
  • 如何低成本獲取每個節(jié)點過程的數(shù)據(jù)鏈路時間。

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

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

這樣就很容易去獲取到任意信息,計算每個節(jié)點的時間。 

我們也可以通過抽樣計算一些統(tǒng)計指標衡量時效: 

對于時效性有明顯異常的數(shù)據(jù)可以篩選出來,進行持續(xù)優(yōu)化。

6.性能測試

實時數(shù)據(jù)鏈路本質是一套全鏈路數(shù)據(jù)計算服務,所以我們也需要測試它的性能情況。

第一步,我們先具體化全鏈路的待測系統(tǒng)服務。 

包括兩部分的性能,Bigku的反查服務,即HSF服務,再就是blink的計算鏈路節(jié)點。

第二步,準備數(shù)據(jù)和工具。

壓測需要的業(yè)務數(shù)據(jù)就是消息。數(shù)據(jù)準備有兩種方式,一種是盡可能模擬真實的消息數(shù)據(jù),我們只要獲取消息內(nèi)容進行程序自動模擬即可;另外一種會采用更真實的業(yè)務數(shù)據(jù)dump引流,進行流量回放。

由于數(shù)據(jù)鏈路的特性,對壓測鏈路施壓就是轉成發(fā)送消息數(shù)據(jù),那么如何控制數(shù)據(jù)發(fā)送呢?有兩種方式:

  • 第一種我們開發(fā)一個發(fā)送消息的服務接口,轉變成常規(guī)的接口服務壓測,然后可以采用阿里的任何壓測工具,整個測試就變成常規(guī)的性能測試;
  • 第二種我們可以利用blink消息回追的機制,重復消費歷史消息進行壓測,不過這種方法有弊端,無法控制消息的頻率。

7.壓測和指標收集

根據(jù)業(yè)務情況來收集指標,指標包括服務本身的指標和資源指標,可以參考我們的部分性能測試報告示例(數(shù)據(jù)有截斷): 

  

五、線上質量

1.服務穩(wěn)定性保障

穩(wěn)定性包括兩個層面,一是實時計算任務鏈路的每個節(jié)點的穩(wěn)定性,二是內(nèi)置服務的穩(wěn)定性。

2.實時計算

由于實時計算采用全blink的計算方式,我們可以利用blink系統(tǒng)本身的特性來做任務的監(jiān)控。每個節(jié)點的任務都需要配置穩(wěn)定性指標的監(jiān)控,包括rps、delay、failover等。效果示例如下: 

3.實體服務

實體服務是HSF服務,采用阿里統(tǒng)一的監(jiān)控平臺來完成整體服務能力的監(jiān)控,示例如圖: 

 整體指標包含以下內(nèi)容: 

4.數(shù)據(jù)消費保障

在數(shù)據(jù)消費層面,重點關注每個鏈路層級的消費能力和異常情況?;诜e累的track-report能力進行數(shù)據(jù)統(tǒng)計,結合平臺完備的基礎能力來完成消費保障。分為兩層:

核心層:消息出口的實體消息統(tǒng)計監(jiān)控,包括整體數(shù)量和消息內(nèi)容分類統(tǒng)計監(jiān)控。如圖示例: 

  

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

5.數(shù)據(jù)內(nèi)容保障

數(shù)據(jù)內(nèi)容層,建設綜合數(shù)據(jù)更新、數(shù)據(jù)內(nèi)容檢查、業(yè)務效果三位一體的精準數(shù)據(jù)檢查,達到數(shù)據(jù)生產(chǎn)、消費、可用性的閉環(huán)檢測,如圖所示: 

從圖中可以看出,我們數(shù)據(jù)內(nèi)容保障分為三部分:

  1. sampler:抽樣器,通過blink實時消費消息在鏈路中抽取待測數(shù)據(jù),通常是只抽取數(shù)據(jù)ID;抽樣策略分間隔和隨機兩種。間隔策略就是取固定時間間隔的特定數(shù)據(jù)進行檢查;隨機則根據(jù)一定的隨機算法策略來抽樣數(shù)據(jù)進行檢查。
  2. data-monitor:是做數(shù)據(jù)內(nèi)容檢查,包括更新時效性和數(shù)據(jù)特征屬性檢查。
  3. effect-monitor:數(shù)據(jù)正常更新之后,對在線業(yè)務實時產(chǎn)生的效果影響進行檢查,檢查的核心點包括搜索的兩大基本效果——召回和排序,以及用戶體驗相關的數(shù)據(jù)屬性的檢查。

部分數(shù)據(jù)實時效果示例圖:  

6.實時干預與自動修復

實時干預通道,如下圖:  

 實時干預系統(tǒng)會根據(jù)不同的干預需求,對消息內(nèi)容和干預機制進行消息組裝和通道分發(fā)。

  1. 當主通道業(yè)務鏈路正常時,若需要強制更新一個ID維度的數(shù)據(jù),只需要輸入ID走正常主鏈路更新即可。
  2. 當需要強制干預某些具體的數(shù)據(jù)內(nèi)容到指定的消息通道時,則可進行數(shù)據(jù)內(nèi)容級別的更詳細的精準干預。
  3. 緊急強制干預,是指當主鏈路中間層處理有較大延遲或者完全阻塞時,會造成下游業(yè)務層數(shù)據(jù)無法正常獲取輸入。通過主邏輯全copy的機制建立了一個VIP的消息通道,通過VIP通道去直接干預出口消息,保證業(yè)務數(shù)據(jù)正常能進行優(yōu)先更新。

六、質量效能

效能層面主要指:研發(fā)能快速自測上線,線上問題能高效排查定位這兩個維度,以期達到保證快速迭代、節(jié)省人力投入的目標。所以我們提供了實時debug和實時全鏈路trace透視兩大提效體系。

1.實時debug

實時debug是基于實時消息通道能力和debug機制建立的一套服務,在研發(fā)自測、問題復現(xiàn)等場景有很大用途,可以通過debug模式詳細了解鏈路的業(yè)務層處理細節(jié),業(yè)務層只需要按數(shù)據(jù)需求自主定制debug內(nèi)容,無需其他接入成本,具備很強的通用性和擴展性。  

 平臺效果圖: 

 填入節(jié)目ID,發(fā)送消息就會自動進入實時debug模式。

同時還配備了指定消息內(nèi)容的專家模式,方便研發(fā)進行單獨的消息內(nèi)容制定化測試和干預。 

2.全鏈路trace

我們提煉了一個全鏈路實時trace的通用模型,同時做更精細定制化的trace機制。結合實時業(yè)務鏈路邏輯視圖,來看下trace的系統(tǒng)實現(xiàn):  

鏈路層視角,目前整體分為4個業(yè)務塊,數(shù)據(jù)流按順序進行展示: 

 1)bigku_service 展示了當時消息的鏡像數(shù)據(jù)。 

 2)mid_show_f 為算法層面的基礎特征,即一級特征,包含了業(yè)務信息和系統(tǒng)信息(工程關注的指標數(shù)據(jù),主要用來指導優(yōu)化)。

 3)sum_video_f 和 ogc屬于搜索鏈路上的數(shù)據(jù),一般在節(jié)目里面會有一些較為復雜的截斷邏輯,通過字典表的形式提供數(shù)據(jù)層的透視視角,可以看到鏈路的全部信息。

七、產(chǎn)品體驗實時自動化保障

我們在實時數(shù)據(jù)內(nèi)容質量方面做了融合效果監(jiān)控的質量方案,建立了實時發(fā)現(xiàn)問題、實時定位、實時修復的閉環(huán)鏈路效果保障體系,起到了很好的效果。體系方案如下圖:  

后記

數(shù)據(jù)是算法的生命之源,保障好數(shù)據(jù)質量,提高優(yōu)質內(nèi)容的分發(fā)效率,既能留住用戶,也能讓用戶在疫情這段特殊的日子里看到高質量的視頻內(nèi)容。數(shù)據(jù)質量道阻且長,未來會深入每個節(jié)點和邏輯,探索海量數(shù)據(jù)和用戶體感的關系,能對算法業(yè)務發(fā)展有幫助作用,也能為廣大用戶感受到文娛帶來的精神滋養(yǎng)。

責任編輯:武曉燕 來源: 阿里技術
相關推薦

2024-02-19 00:06:06

數(shù)據(jù)分析系統(tǒng)Doris

2020-03-18 07:11:24

實時同步搜索

2019-08-21 09:48:37

數(shù)據(jù)處理

2019-04-01 08:19:38

搜索系統(tǒng)美團

2020-09-01 17:19:36

數(shù)據(jù)監(jiān)控建模

2022-06-27 09:09:34

快手Flink數(shù)倉建設

2013-11-07 16:41:38

XToolsSaaS

2011-06-07 17:01:44

2021-01-05 10:32:12

系統(tǒng)代碼測試

2011-04-14 10:36:36

2022-03-07 07:18:18

Netflix機器學習架構

2022-03-16 10:20:57

數(shù)據(jù)智慧城市傳感器

2020-04-28 11:04:51

數(shù)據(jù)架構互聯(lián)網(wǎng)Flink

2019-08-19 14:24:39

數(shù)據(jù)分析Spark操作

2022-08-01 15:58:48

數(shù)據(jù)倉庫架構數(shù)據(jù)

2024-10-18 08:17:09

Doris數(shù)據(jù)倉庫

2022-07-07 17:49:32

阿里數(shù)倉Hologres

2020-09-01 07:49:14

JVM流量系統(tǒng)

2022-09-22 10:53:38

實時數(shù)據(jù)ML 模型

2020-07-08 10:11:18

數(shù)據(jù)中心實時數(shù)據(jù)
點贊
收藏

51CTO技術棧公眾號