引言
閑魚是一個以C2C為主的平台，差別于B端的使用者，C端賣家在釋出商品時更傾向于圖+描述的輕釋出模式，對于補充商品的結構化資訊往往執行力和專業程度都不高，這為我們的商品了解帶來了很大的困難。為了能夠在釋出側獲得更多的商品結構化資訊，我們開始嘗試在原有圖+文的極簡釋出模式中加入商品關鍵屬性的補充選項，事實證明，适當的結構化屬性選項并不會影響使用者的釋出體驗，卻能極大地提升我們對商品了解的能力。然而存在以下問題：
在設定結構化屬性選項時，往往強依賴行業營運的經驗，缺少實時的、多元度的資料分析手段。雖然離線産出的資料報表能夠在一定程度上統計某些關鍵名額，但對于精細的、個性化的資料查詢需求，離線報表擴充性和性能都不足。
基于上述問題，我們搭建了龍宮資料分析平台。
龍宮資料分析平台的定位與總體架構
差別于資料報表，我們在設計龍宮資料分析平台時主要考慮了以下方面：
- 實時性要求，當營運上線新政策或因服務問題線上出現資料波動時，我們希望能夠實時地分析出結構化類目屬性在這段時間内的覆寫情況，以幫忙營運做進一步的決策。
- 多元度要求，閑魚目前擁有8000+的葉子類目，不同行業營運的側重點各不相同，資料分析平台要能夠滿足個性化的資料分析需求。
- 資料管理要求，閑魚的類目屬性、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設計。
- 增加使用者次元的資料分析能力，與算法對接，将資料分析的結果反哺算法，使得算法模型能預測出準确、個性化的類目屬性。