基于騰訊云數(shù)據(jù)庫構(gòu)建商品加工引擎，管理近10億商品數(shù)據(jù)

商品加工引擎是騰訊基于云原生打造的高可用、可擴展、靈活配置的商品處理引擎，融合商品接入、商品加工、商品存儲、商品分發(fā)、鏈路監(jiān)控、商品對賬等核心能力，支持近十億的商品管理和加工，以及騰訊多個核心應(yīng)用場景。

商品加工引擎提供不同類型的商品錄入、商品統(tǒng)一加工、商品信息分發(fā)等能力。存儲商品數(shù)據(jù)接近十億，支持商品加工能力包括：淫穢、色情、迷信、暴力、涉政等內(nèi)容機器或人工審核，圖片轉(zhuǎn)鏈、視頻轉(zhuǎn)鏈、統(tǒng)一商品理解類目品牌詞生成、統(tǒng)一商品標簽生成、商品賣點信息生成等等。

系統(tǒng)架構(gòu)

支持商品統(tǒng)一接入、商品基于自建的組件市場進行商品加工、基于流程編排模塊可以定制化配置加工組件、統(tǒng)一存儲的商品數(shù)據(jù)通過商品分發(fā)模塊進行統(tǒng)一分發(fā)。

技術(shù)挑戰(zhàn)

1.商品存儲的挑戰(zhàn)

單sku 300+字段，近十億的商品，支持查詢QPS 4萬+，商品更新TPS 1萬+，日4億+次商品數(shù)據(jù)實時分發(fā)，有較明顯的高峰低峰期。如何既滿足高性能，又滿足可擴展性？這里面涉及到：

a.表結(jié)構(gòu)設(shè)計，需要平衡各行業(yè)的字段擴展需求以及商品數(shù)據(jù)分發(fā)組裝帶來的耗時及性能問題。

b.存儲設(shè)計，如此高并發(fā)和大數(shù)據(jù)量的需求背景下，持久化數(shù)據(jù)庫選型顯得尤為重要。

所選數(shù)據(jù)庫要同時滿足：可擴展性、穩(wěn)定性、事務(wù)性、支持頻繁增加字段的運維場景、數(shù)據(jù)訂閱組件支持（保證分發(fā)和存儲完全解耦）、盡量低的存儲成本。

2.業(yè)務(wù)支持的挑戰(zhàn)

不同類型、不同應(yīng)用渠道的商品加工特性各異，如何做到跟上業(yè)務(wù)訴求快速迭代，且做到懂業(yè)務(wù)的人可以自己去管控整個加工流程，而不是技術(shù)人員自己寫在代碼黑盒里。例如：新聞資訊類行業(yè)審核需要涉及到包含淫穢、色情、迷信、暴力、政治審核等審核條目，但其他行業(yè)不需要政審等等。

3.高優(yōu)加工通路支持的挑戰(zhàn)

全數(shù)據(jù)通路，商品加工因受限于底層的圖片識別等能力限制，存在擴展的邊際成本。所以怎樣能夠確保高優(yōu)通路商品得到優(yōu)先處理，任務(wù)優(yōu)先級管理是在架構(gòu)層面臨的另一挑戰(zhàn)。

技術(shù)架構(gòu)

技術(shù)架構(gòu)上將整體數(shù)據(jù)處理管道抽象成數(shù)據(jù)接入層、存儲&數(shù)據(jù)加工層、流水解析層、數(shù)據(jù)分發(fā)層，各層之間通過消息中間件進行解耦，并起到各層間流量反壓緩沖的作用。技術(shù)選型上選擇騰訊云原生數(shù)據(jù)庫TDSQL-C和中間件，且保證全鏈路數(shù)據(jù)的順序性和at Least Once的消息處理語義。

商品表結(jié)構(gòu)設(shè)計

商品表目前拆分為：商品信息表、銷售信息表、優(yōu)惠券信息表，以最寬粒度拆表是因為商品中臺在進行數(shù)據(jù)分發(fā)時，需要各表信息join組裝分發(fā)，當表的粒度過細，會嚴重影響數(shù)據(jù)組裝效率，直接導致分發(fā)吞吐量的降低以及數(shù)據(jù)庫壓力的倍增，不符合可擴展性設(shè)計。

主鍵及分片策略：分片策略采用商品HashId分片，HashId生成算法如下：

public static Long genHashId(Long catalogId, String... outerIds) {

        Preconditions.checkNotNull(catalogId);

        Preconditions.checkNotNull(outerIds);

        Hasher hasher = Hashing.murmur3_128().newHasher();

        hasher.putLong(catalogId);

        for (String outerId : outerIds) {

            hasher.putString(outerId, Charsets.UTF_8);

        }

        return ~(1l << 63) & hasher.hash().asLong();

    }

現(xiàn)最大商品庫7千萬+商品無Hash沖突，且最大限度保證數(shù)據(jù)均勻?，F(xiàn)在四個分片數(shù)據(jù)分布如下：

主鍵采用業(yè)務(wù)主鍵catalogId+hashId，沒有用系統(tǒng)主鍵主要考慮每次落庫動作前均會先查詢做數(shù)據(jù)對比，然后落庫，采用業(yè)務(wù)主鍵可以避免回表查詢，大大提高緩存命中率及查詢效率。目前TDSQL-C緩存命中率99.91%，大部分查詢耗時小于5ms。

商品信息表字段按照信息領(lǐng)域拆分，每個信息領(lǐng)域以blob存儲protobuf壓縮后的對象信息?？梢赃_到領(lǐng)域內(nèi)信息字段的快速變更，并節(jié)省磁盤空間。在數(shù)據(jù)讀取以及網(wǎng)絡(luò)傳輸過程中，最大限度節(jié)省帶寬。關(guān)于protobuf優(yōu)缺點這里不做贅述，大家可以查詢相關(guān)資料詳細了解。

持久化存儲設(shè)計

持久化存儲設(shè)計主要采用TDSQL（InnoDB引擎）存儲熱數(shù)據(jù)，Hbase存儲冷數(shù)據(jù)的架構(gòu)設(shè)計，冷熱數(shù)據(jù)的區(qū)分是商品是否進行邏輯刪除。這里冷數(shù)據(jù)單獨存儲原因是要減少存儲成本。TDSQL為了提高數(shù)據(jù)訪問效率，高性能版本默認均為SSD硬盤，比普通的機械硬盤存儲要高很多。HBase存儲我們默認開啟了SNAPPY壓縮算法，所以從磁盤空間占用量和存儲成本上均有大幅降低。

那為什么不直接用Hbase存儲？

1.入庫數(shù)據(jù)后，經(jīng)常會判斷數(shù)據(jù)數(shù)量是否準確，我們對商品庫級別的count查詢是強需求，這點Hbase支持不了。

2.TDSQL作為騰訊云產(chǎn)品，產(chǎn)品易用性及監(jiān)控配置上更完善。

3.商品變更的數(shù)據(jù)流訂閱，Hbase暫未發(fā)現(xiàn)較優(yōu)雅的方案。

商品加工編排設(shè)計

商品加工的編排，主要針對加工組件市場里面的組件進行加工編排。抽象出商品加工組件市場的概念，主要目的是避免功能的重復建設(shè)，提高代碼復用性，并有效提高新系統(tǒng)的交付速度。商品加工事件編排架構(gòu)設(shè)計如下：

·優(yōu)先級隊列層：此層抽象出三個優(yōu)先級不同的topic用于分發(fā)商品加工事件,提升不同渠道數(shù)據(jù)處理效率，避免資源搶占。

·事件處理層：此層消費商品加工事件，對事件解析去重，通過不同優(yōu)先級隊列事件感知控制消費吞吐量，處理不同客戶任務(wù)優(yōu)先級。此層會基于不同應(yīng)用場景和商品所屬行業(yè)，去選擇對應(yīng)的DAG進行觸發(fā)商品加工流程。由于下游編排管理層在過高請求壓力下會存在服務(wù)過載情況，所以此處設(shè)置異常熔斷控制，以及異?；謴筒呗浴?/p>

·編排管理層：編排管理層，依賴騰訊云ASW調(diào)度平臺進行流程配置和管理。ASW在編排配置方面支持較全，循環(huán)、并行、選擇等條目支持很友好。（目前ASW支持騰訊云API 3.0上超過99%的接口，能做到像膠水一樣粘合各種服務(wù)，支持高并發(fā)場景。）

·請求轉(zhuǎn)發(fā)層：編排管理是對請求轉(zhuǎn)發(fā)層的編排，此層使用Serverless云函數(shù)進行部署。各請求轉(zhuǎn)發(fā)節(jié)點可以實現(xiàn)同步請求轉(zhuǎn)發(fā)或異步請求轉(zhuǎn)發(fā)。實現(xiàn)對不同商品處理場景的有效支撐。

·服務(wù)提供層：服務(wù)提供層提供對請求轉(zhuǎn)發(fā)層的請求處理，此層會對來自上層的請求進行多線程處理，提高數(shù)據(jù)處理速度。并負責對下游的請求流量管控，避免流量過大壓垮下游的服務(wù)。

·通用能力層：公司各個服務(wù)平臺提供的通用能力，例如：文本審核、圖片識別審核、商品理解統(tǒng)一類目、商品打標等。

總結(jié)

本篇文章主要針對現(xiàn)商品中臺整體架構(gòu)的梳理和總結(jié)，里面涉及到很多技術(shù)點，受篇幅限制沒有贅述，其中包括但不限于：全鏈路監(jiān)控、數(shù)據(jù)一致性比對、線程管理模型等等，后面會繼續(xù)完善相關(guān)內(nèi)容。