阿里雲大數據助力知衣科技打造AI服裝行業核心競爭力
公司簡介
杭州知衣科技有限公司是一家以人工智慧技術為驅動的國家高新技術企業，致力於將數據化趨勢發現、爆款挖掘和供應鏈組織能力標準化輸出，打造智慧化服裝設計的供應鏈平台。知衣成立於2018年2月，同年獲得千萬美金A輪融資；2021年完成由高瓴創投、萬物資本領投的2億人民幣B輪融資，同年入圍「杭州市准獨角獸企業榜單」。
知衣憑藉影像識別、數據挖掘、智慧推薦等核心技術能力，不斷升級服務體系，自主研發了知衣、知款、美念等一系列服裝行業數據智慧SaaS產品，為服裝企業和設計師提供流行趨勢預測、設計賦能、款式智慧推薦等核心功能，並通過SaaS入口向產業鏈下游拓展，提供一站式設計+柔性生產的供應鏈平台服務。目前已服務UR、唯品會、綾致、赫基、太平鳥、海瀾之家、森馬等數千家時尚品牌和平台。
方案架構
當前知衣在阿里雲上的整體方案架構如下，大致分為產品層、服務層、數據層以及大數據平台。
-
產品層：知衣目前有多款APP應用，如主打產品知衣、增強設計協作的美念等。除此之外，我們還提供訂製化API向第三方開放數據介面服務和以圖搜圖的功能。從數字選款到大貨成品交付的一站式服裝供應鏈平台也是核心的能力輸出。
-
服務層：相關產品的前後端系統都已經實現容器化，部署在阿里雲的ACK容器服務集群
-
數據層：主要保存原始圖片、業務系統產生的業務數據、以及OLAP數據分析服務
- 對象存儲OSS：保存原始圖片，構建服裝行業十億級別款式庫
- 資料庫MySQL：OLTP業務數據
- HBase：以KV格式訪問的數據，如商品詳細資訊、離線計算榜單等數據
- 特徵向量庫：由圖片識別抽取的向量再經過清洗後保存在阿里達摩院開發的Proxima向量檢索引擎庫
- ElasticSearch：用於點查及中小規模數據的指標統計計算。設計元素標籤超過1000個，標籤維度主要有品類、面料、紋理、製程、輔料、風格、廓形、領型、顏色等
-
大數據平台
-
日誌服務SLS：用於快取經過圖片識別後的海量向量數據。SLS還有一個基於SQL查詢的告警能力，就是若向量數據沒有進來會觸發告警，這對於業務及時發現問題非常有用。
-
離線數倉（DataWorks + MaxCompute）：通過DataWorks集成快取了圖片特徵向量的日誌服務作為數據源，然後創建數據開發任務對原始特徵向量進行清洗（比如去重等）保存在MaxCompute，再通過DataWorks將MaxCompute清洗後的向量數據直接寫入ElasticSearch的Proxima
-
數據挖掘 & 演算法推薦：部署在ACK里的一些Python任務，主要做推薦相關的內容，比如用戶特徵Embedding計算、基於用戶行為的款式圖片的推薦、相似性部落客的推薦等
-
圖片識別服務：目前圖片識別服務主要還是部署在IDC機房，5~6台GPU伺服器對圖片進行批量識別
大數據方案演進
知衣的大數據方案也是經過不同的階段不斷的演進，滿足我們在成本、效率和技術方面的追求，本質上還是服務於業務需求。
階段一：IDC自建CDH集群
我們的業務系統一開始就部署在阿里雲，同時在IDC機房部署了10台伺服器搭建CDH集群，構建Hive數倉。計算過程是先將雲上生產環境數據同步到CDH，在CDH集群進行計算後將計算結果再回傳到阿里雲上提供數據服務。
自建CDH集群雖然節省了計算費用，但是也帶來不少問題。最主要的就是運維比較複雜，需要專業的人員進行集群的運維管理。出現問題也是在網上到處搜索排查原因，效率比較低。
階段二：DataWorks + MaxCompute替換CDH集群
為了降低運維複雜度，我們將計算任務遷移到MaxCompute，直接基於DataWorks做任務編排調度。
階段三：ElasticSearch構建即席查詢
知款聚焦於快速發現時尚趨勢靈感，集成了社交平台、品牌秀場、零售及批發市場、淘系電商、時尚街拍五大圖源，海量的設計靈感參考，幫助服裝品牌及設計師快速準確地預判時尚風向，掌握市場動態。其中趨勢分析板塊就需要對某個季度下各種組合條件下的設計要素標籤進行統計分析，並輸出上升、下降以及餅圖等指標。這也是我們數據量最大的查詢場景，掃描分析的數據量量級會接近百萬。
阿里雲託管版ElasticSearch相比較開源版本最大優點就是開箱即用免運維，特別的就是支援達摩院的Proxima向量檢索引擎，非常適合我們業務的多維查詢和統計分析場景。後面會在圖片識別展開講述Proxima向量引擎。
圖片識別
我們的核心功能場景是以圖搜圖，前提是需要對海量的圖片庫數據進行識別。我們以離線的方式對圖片庫的所有圖片進行機器學習分析，將每一幅圖抽象成高維（256維）特徵向量，然後將所有特徵藉助Proxima構建成高效的向量索引。
模型訓練
圖片識別之前需要訓練模型。由專業的服務行業背景的人員對圖片庫進行標註，然後線下部署的GPU集群從阿里雲對象存儲OSS批量拉取已標註的圖片進行訓練。為了降低標註的成本，我們採用了主動學習（Active Learning）方法，即基於一部分已標註的圖片由機器學習訓練出一個模型，然後對未標註的圖片進行預測，讓人工對預測結果再次進行確認和審核，再將標註的數據使用監督學習模型繼續進行模型訓練，逐步提升模型效果。
批量圖片識別
模型生成以後打包到Docker鏡像，然後在GPU節點上運行容器服務就可以對海量的服裝圖片進行識別，提取出高維的特徵向量。因為提取的特徵向量數據量很大且需要進行清洗，我們選擇將特徵向量先快取在阿里雲日誌服務SLS，然後通過DataWorks編排的數據開發任務同步SLS的特徵向量並進行包含去重在內的清洗操作，最後寫入向量檢索引擎Proxima。
因為一次批量識別圖片的工作量很大，線下的GPU伺服器計算性能有瓶頸，所以我們就藉助雲上彈性的GPU資源做計算資源的補充。線下GPU和雲上GPU組成一個計算資源池，共同消費同一批需要進行圖片識別的計算任務，效率大大提升。雲上我們購買的是GPU搶佔式實例，一般是按量價格的2~3折，可以進一步降低成本。
單次圖片識別
我們以在線serving的模式在web前端提供單次單張圖片識別功能，比如用戶上傳一張圖片，通過模型的推理輸出如下結果。
以圖搜圖
構建好服裝圖片的特徵向量庫，我們就可以實現以圖搜圖的功能。當用戶上傳一張新圖片的時候，我們用之前的機器學習方法對其進行分析併產出一個表徵向量，然後用這個向量在之前構建的向量索引中查找出最相似的結果，這樣就完成了一次以圖片內容為基礎的影像檢索。選擇合適的向量檢索引擎非常重要。
Faiss
Faiss (Facebook AI Similarity Search) 是Facebook AI 團隊開源的向量檢索庫引擎。初期我們也是選擇Faiss部署分散式服務，在多台GPU伺服器上部署特徵向量搜索匹配服務，將搜索請求分發到每台GPU子服務進行處理，然後將TOP N的相似結果數據匯總返回給調用方。
在使用Faiss的過程中，我們也遇到了實際的困難。當然這並不是Faiss本身的問題，而是需要投入更多人力開發運維分散式系統才能匹配業務需求。
- 穩定性較差：分散式GPU集群有5~6台，當某一台機器掛了會拉長整個介面響應時間，業務的表現就是搜圖服務等很久才有結果返回。
- GPU資源不足：我們採用的是最基礎的暴力匹配演算法，2億個256維特徵向量需要全部載入到顯示記憶體，對線下GPU資源壓力很大。
- 運維成本高：特徵庫分片完全手動運維，管理比較繁瑣。數據分片分散式部署在多個GPU節點，增量分片數據超過GPU顯示記憶體，需要手動切片到新的GPU節點。
- 頻寬爭搶：圖片識別服務和以圖搜圖服務都部署在線下機房，共享300Mb機房到阿里雲的專線頻寬，批量圖片識別服務佔用大頻寬場景下會直接導致人機交互的圖搜響應時間延長。
- 特定場景下召回結果集不足：因為特徵庫比較大，我們人工將特徵庫拆成20個分片部署在多台GPU伺服器上，但由於Faiss限制每個分片只能返回1024召回結果集，不滿足某些場景的業務需求。
Proxima
Proxima是阿里達摩院自研的向量檢索引擎（//developer.aliyun.com/article/782391），實現了對大數據的高性能相似性搜索，也集成在我們之前在用的阿里雲託管版的ElasticSearch。功能和性能上與Faiss相比各有千秋，主要是針對Faiss使用上的困難，ElasticSearch + Proxima幫助我們解決了。
- 穩定性高：開箱即用的產品服務SLA由阿里雲保障，多節點部署的高可用架構。到目前為止，極少碰到介面超時問題
- 演算法優化：基於圖的HNSW演算法不需要GPU，且與Proxima集成做了工程優化，性能有很大的提升（1000萬條數據召回只需要5毫秒）。目前業務發展特徵向量已經增長到3億。
- 運維成本低：分片基於ES引擎，數據量大的情況下直接擴容ElasticSearch計算節點就可以
- 無頻寬爭搶：以圖搜圖的服務直接部署在雲上，不佔用專線頻寬，圖搜場景下沒有再出現超時查詢告警
- 召回結果集滿足業務需求：Proxima也是基於segment分片取Top N相似，聚合後再根據標籤進行過濾。因為segment較多，能搜索到的數據量就比原先多很多。
技術架構升級展望
OLAP分析場景優化迭代
隨著數據量的不斷增長以及業務需求的不斷變化，OLAP分析場景越來越複雜，對演算法和技術方案選型要求越來越高。舉個業務場景的例子
10萬部落客發布的圖片數量有1億多，用戶可以對部落客進行關注訂閱，關註上限是2000個部落客。用戶關注的2000個部落客對應的圖片量級會在200萬左右。需要對用戶關注的圖片進行實時多條件統計分析（每個用戶關注部落客不同）
以上例子在使用ElasticSearch實現查詢的時候需要9秒，顯然不滿足業務需要。那有沒有更好的方案呢？近期在調研完Clickhouse之後，對數據進行預處理產生大寬表再查詢，查詢時延已經降低到2秒以內，很好的滿足了業務需求。阿里雲託管版的Clickhouse開箱即用，降低業務試錯成本，幫助我們快速響應業務需求。
規範數據建模和數據治理
目前DataWorks主要是用來做數據集成和任務調度，也有些少量的基於規則判斷數據品質，團隊內部的約定更多的是文檔化的開發規範，缺乏一些有效工具的輔助。隨著業務場景越來越複雜，集成的數據源越來越豐富，數據開發人員也越來越多，制定全部門統一的開發規範非常必要。DataWorks的數據建模通過工具和流程建立數據標準，可以實現結構化有序的統一管理。數據治理模組可以通過配置檢查項檢測不符合數據規範的開發流程，基於多項治理項的健康分度量項目健康度以及治理成效。目前我們正在結合自己的業務試用數據建模和數據治理，期待能幫助我們更好的管理數據，實現數據價值的最大化。【建議替換數據建模和數據治理的圖】
圖搜方案進階合作
在服裝行業領域圖片識別和以圖搜圖是我們的核心競爭力。阿里雲機器學習PAI也提供了相似圖匹配的影像檢索解決方案（//help.aliyun.com/document_detail/313270.html）只需要配置原始影像數據，無需標註就可以在線構建模型，這點對我們來說比較有吸引力，後續可以考慮進行測試對比，展開在服裝圖片建模領域的合作。
