實效性與準確性的背後:多系統資料聚合展示

語言: CN / TW / HK

背景

大家在平時的業務開發中,會不會遇到這麼一種問題:一個新的需求展示的某種業務資料,資料來源橫跨多個不相關的業務系統,時間跨度長且需要及時反映實時的資料變化,資料查詢的QPS較高且要求rt較小。

遇到這類問題應該怎麼處理?下面以閒魚粉絲系統標籤的實現方案為例,跟大家交流一種實際落地的解決方案。

面臨的挑戰

粉絲系統標籤是閒魚提供給Pro使用者進行粉絲管理的基礎功能,在“我的粉絲”頁面有幾個粉絲系統標籤分組,包括新粉、老粉和已購粉。其中,已購粉的含義是有過交易成功記錄的粉絲,且在已購粉列表中透出歷史總購買次數,並按照最新購買時間排序。 

對於系統標籤,有如下要求:

• 須包含全部的歷史資料,如已購粉需要統計出歷史交易總數。

• 多場景透出,如IM聊天場景也需要進行標籤的透顯,QPS較高。

實現目標:

• 資料實時更新,反應最新的粉絲購買動態。

• 查詢效能良好,QPS比較大,rt要求高。

• 資料準確無遺漏。

系統標籤的面臨的問題和挑戰,和文章一開始 提到的基本一致,用一句話來說,就是在面對多系統業務資料聚合展示的需求時,如何在保障資料準確性的同時,還兼顧實時性以及查詢效能。

下面就這種型別問題的解決進行展開討論。

整體思路與方案選擇

為了解決上面的問題,有如下幾個比較通用的方案,其各自的優缺點已羅列如下:

以上的三種方案有各自的優缺點,我們可以考慮把上面的解決思路進行結合,以滿足文章一開始提到的要求。

首先採用方案二的方式每天凌晨將不同系統的業務資料進行匯出,進行離線關聯計算,然後對計算結果進行schema的轉化後作為業務資料的離線資料來源。這種方式可以滿足涵蓋多個業務系統全量歷史資料的要求,並且能保障資料的準確性。為了在此基礎上反應實時資料的變化,可以採用方案三的思 路對離線資料進行實時補償。

實時資料補償可以基於消費業務變更訊息來進行。如在系統標籤場景中,可以對關注/取關訊息、交易訊息進行消費,來生成實時補償資料。業務資料查詢時,再對離線和實時補償資料進行聚合,如下圖所示。

最後,需要保障查詢的高吞吐低延時。這裡可以分兩方面來考慮。首先在技術選型上,需要考慮選擇一種高效能的儲存系統,這裡可以使用kv儲存(如LevelDB),保障低延時。其次,可根據查詢的資料檢視來生成資料儲存的schema,儘可能降低資料查詢頻率與資料後處理的複雜度。

離線資料和實時資料應該怎樣聚合才能保障資料準確?離線和實時資料製備鏈路具體又是如何實現的?下來以已購粉系統標籤的為例,介紹一下具體的方案實現。

開發實踐

資料結構與聚合邏輯

系統標籤資料儲存使用的是kv儲存。kv儲存中的資料,從型別上主要分為一對一交易資料和一對多已購粉絲列表資料。從離線和實時上,兩種不同的型別有各自的離線和實時資料。

之所以有一對一交易資料,是為了用來進行交易次數的正反向查詢,並且在新增關注之後,也可實時查詢到兩個人的歷史購買資料。

在查詢交易次數時,第一步會先讀取一對一離線交易資料,獲取歷史交易數量。第二步再讀取一對一實時補償交易資料,查詢交易時間大於離線資料更新時間的交易訂單數,將二者求和即為當前交易次數總和。

查詢已購粉列表時,會將一對多實時交易資料和一對多離線資料進行merge,根據最新購買時間重新排序,然後再查詢已購資料服務獲取交易次數,展示給使用者。

系統標籤資料製備鏈路

離線資料的製備,是根據訂單資料和關注關係的業務系統儲存資料,離線生成離線資料表,再聚合匯入到離線的kv儲存中。

而實時資料的製備,主要是通過消費交易成功的訊息,對一對一交易實時資料進行更新。如果是關注關係變更訊息,則進行已購粉列表實時補償資料更新。

還有一種場景需要處理,如果有新增的粉絲,需要對該粉絲歷史購買的資料進行查詢,補充到已購粉列表資料中。在具體更新鏈路中會消費新增關注的訊息,然後通過查詢離線和實時一對一交易資料獲取最新的交易時間,更新到已購粉列表的實時補償資料中。

方案成果

以上方案實現了既能展示歷史全量已購粉絲資料,又能滿足及時反應資料實時變化的要求,在保障資料準確度的同時,承載了接近1w的QPS,查詢rt可以控制在幾毫秒內。

總結與展望

本文以閒魚系統標籤系統為例,介紹了一種通用的解決多業務系統資料實時聚合展示問題的思路。這種思路可以高效快速地滿足一些業務需求,但是也會存在一些侷限,如熱點資料會導致實時補償資料激增等問題,有待進一步優化。另外在資料儲存上的選型,也可以考慮使用分析資料庫,如AnalyticDB。

在類似問題的解決上,有其他思路也歡迎留言討論,謝謝。