閒魚商品理解資料分析平臺——龍宮

語言: CN / TW / HK

簡介: 資料分析平臺助力運營,中流砥柱

作者:閒魚技術——故淵

引言

閒魚是一個以C2C為主的平臺,區別於B端的使用者,C端賣家在釋出商品時更傾向於圖+描述的輕釋出模式,對於補充商品的結構化資訊往往執行力和專業程度都不高,這為我們的商品理解帶來了很大的困難。為了能夠在釋出側獲得更多的商品結構化資訊,我們開始嘗試在原有圖+文的極簡釋出模式中加入商品關鍵屬性的補充選項,事實證明,適當的結構化屬性選項並不會影響使用者的釋出體驗,卻能極大地提升我們對商品理解的能力。然而存在以下問題:
在設定結構化屬性選項時,往往強依賴行業運營的經驗,缺少實時的、多維度的資料分析手段。雖然離線產出的資料報表能夠在一定程度上統計某些關鍵指標,但對於精細的、個性化的資料查詢需求,離線報表擴充套件性和效能都不足。
基於上述問題,我們搭建了龍宮資料分析平臺。

龍宮資料分析平臺的定位與總體框架

區別於資料報表,我們在設計龍宮資料分析平臺時主要考慮了以下方面:

  1. 實時性要求,當運營上線新策略或因服務問題線上出現數據波動時,我們希望能夠實時地分析出結構化類目屬性在這段時間內的覆蓋情況,以幫忙運營做進一步的決策。
  2. 多維度要求,閒魚目前擁有8000+的葉子類目,不同行業運營的側重點各不相同,資料分析平臺要能夠滿足個性化的資料分析需求。
  3. 資料管理要求,閒魚的類目屬性、SPU資料、運營策略需要一個統一管理的地方。

我們希望以此實現結構化資料對運營的反哺,構成商品結構化資料生產與應用的閉環。


總體分層框架如下:

 

資料鏈路建設

構建資料分析平臺的關鍵是資料鏈路的建設,在閒魚,結構化資料主要分為線上資料(通過釋出、編輯入口使用者直接填寫的資料)和離線資料(通過後置演算法模型分析商品的圖文獲取的資料)。資料鏈路的建設存在以下關鍵難點:

  • 儲存資料量大(全量20億+),訪問QPS高(1.5萬+),服務穩定性要求高。
  • 資料來源多(10餘種),各來源資料異構,存在重複、衝突的資料,資料實時性要求高(秒級延遲)。
  • 資料分析場景複雜(QPS小,但sql複雜度高),普通資料庫查詢難以支撐。

針對資料量大和QPS高的問題,我們選用tableStore作為儲存商品結構化資訊的資料庫,它一種典型的列儲存資料庫,具有擴充套件性好、可用性高、單機可支撐QPS上萬的特性,非常適合作為大資料的儲存終端。其可用性可達99.99%,同時具有主備雙庫能力。
同時我們線上資料儲存在mysql的商品表中,通過在java應用中監聽表的變更將資料寫入資料來源表;離線資料通過ODPS+MQ的方式將資料傳入演算法模組,並通過blink將演算法結果寫入資料來源表。由於線上離線的多來源資料可能存在重複、衝突的問題(同一商品演算法A識別為iphone 12而演算法B識別為iphone 11),所以在系統設計時我們使用源表來儲存所有的原資料,使用終表來儲存加工融合之後的資料,加工融合的策略是產品、運營可決策的。
分析資料我們使用的是分析型資料庫ADB,ADB在儲存容量、單機查詢QPS方面都遠不及tableStore,但它在複雜sql的執行、實時索引建立、冷熱資料隔離等方面擁有其他資料庫不及的效能,是資料分析庫的較好選擇。

 

離線異構資料來源的接入

在閒魚,結構化資料不僅僅來自於釋出時的賣家填寫,正如前面所說,閒魚的C端賣家在填寫結構化屬性的專業程度和執行力都遠遠不及淘寶天貓的賣家,所以我們通過圖文多模態的演算法,在釋出的後置鏈路中為商品補充很多結構化的屬性(這部分cpv目前佔大盤覆蓋率的一半左右,不同類目情況不同)。接入這些離線資料具有以下難點:

  • 各個資料具有結構不同、產出時間不同、資料量級大的特徵,難以複用相同模式,接入新資料來源的成本高。
  • 資料同步任務分散,難以做統一監控。

針對這些難點我們設計了一套離線異構資料來源統一接入的方案:


各個演算法的離線資料儲存在ODPS中,各個演算法的資料格式不一樣,資料的分割槽也不同,所以先通過一個ODPS的同步任務將各資料來源資料統一到一張結構化標準標籤表idle_kgraph_std_source中。表結構如下:

key

json格式的資料,key為主鍵列名,value為主鍵值

data

json格式的資料,每個key對應tableStore源表中的一列,value為需要寫入該列中的值

scene

分割槽欄位,該資料來源於何種場景

source

分割槽欄位,該種場景下的資料來源

表中key為主鍵資訊,因為不同場景的資料主鍵不一樣,所以這裡設計為開放式的主鍵,資料為json格式,key為主鍵列名,value為主鍵值。結構化標準表idle_kgraph_std_source通過一個Blink任務實時同步到tableStore的各個場景的資料表中。在Blink任務中,根據scene和source欄位將資料進行分發,根據data中的key將資料路由到tableStore表中的不同列。同時為了提升效率,減少在Blink任務中寫資料庫的次數,拿到資料後,先對資料進行合併操作,將同種場景(例如結構化屬性資料)的多來源資料合併成一條,再進行寫操作。
通過這套方案,我們成功解決了多資料來源接入中資料難以收口,難以統一監控的問題,同時,資料標準表中開放式資料格式的設計使得新資料來源能夠快速接入,極大地降低了重複開發的成本。

資料加工融合

在獲取到多來源資料之後,我們需要對資料進行加工融合,融合的策略是由產品和運營共同決定的,在變更策略時,存量的商品資料也需要重新進行加工融合,所以資料加工融合鏈路必須具備增量處理穩定,全量處理快速的特點。


在進行全量處理資料時,利用分散式任務排程系統,主任務節點通過資料庫的分片將全量資料劃分成多份,並將資料索引下發給各個子任務節點,由子任務進行資料拉取,使資料拉取與處理不受資料庫的物理分割槽與通道限制,大大提升效能,目前6億全量資料處理僅需40min。任務的分發策略如下:


總的來說,主要解決以下問題:

  • 分散式任務分發,分散式完成全量任務。
  • 操作冪等,操作可以重複,但不影響最終結果。
  • 全量增量彼此隔離,不影響線上服務

資料分析模組設計

在資料分析的場景中,大量涉及到正逆排序、按某指標過濾的頻繁查詢,如果對每一次資料分析請求都做一次完整的資料查詢,對資料庫會造成較大壓力。
所以設計資料分析模組時,我們將請求的分析條件分為兩類:

  • 維度分析條件:根據不同的維度,需要執行不同的查詢邏輯。會通過一個Distributor將分析請求路由到不同的processor中執行。
  • 篩選排序條件:這些條件不影響查詢的邏輯,只會在查詢的結果中進行排序或過濾,針對這種情況我們會優先從快取獲取結果,並在記憶體中進行排序過濾,以提升分析效能。


基於上述的方案,可有效降低資料分析查詢的成本,使查詢平均效率提升50%以上。

效果

目前龍宮平臺已推廣至行業運營、閒魚搜尋、閒魚首頁推薦等場景,取得了階段性效果:

  • 為行業運營提供8000+葉子類目屬性維度的資料分析,助力運營決策結構化選項在閒魚主發中的透出,幫忙其為閒魚結構化大盤貢獻8成類目覆蓋,一半核心cpv覆蓋。
  • 為搜尋、推薦等場景提供快捷的查詢手段,幫助開發、演算法同學實時定位線上問題,實現秒級延遲。大大提升了badcase歸因定位效率。

展望

我們致力於將龍宮打造成一個全面、靈活、準確的商品理解資料平臺,接下來我們將主要針對以下方面繼續優化:

  • 與商品釋出、成交大盤對接,接入商品診斷能力,提供更多維度的資料分析能力,推廣場景覆蓋,助力更多的產品、運營快速決策。
  • 增加更多、更直觀的資料表現形式,優化介面與UI設計。
  • 增加使用者維度的資料分析能力,與演算法對接,將資料分析的結果反哺演算法,使得演算法模型能預測出準確、個性化的類目屬性。

本文為阿里雲原創內容,未經允許不得轉載。