在 DTC（Direct to Customer） 趨勢(shì)下，零售企業(yè)紛紛建設(shè)面向最終消費(fèi)者的大前臺(tái)，例如自營(yíng)電商、微信小程序等，使得產(chǎn)品和服務(wù)加速迭代。業(yè)務(wù)需求對(duì) IT 基礎(chǔ)設(shè)施的要求就是“快”和“準(zhǔn)”，云盛海宏不斷夯實(shí)數(shù)據(jù)底座來(lái)應(yīng)對(duì)外部環(huán)境的變化。
云盛海宏是一家零售業(yè)科技公司，以科技的力量為門店和線上客戶打造 360 度的優(yōu)秀體驗(yàn)，目前服務(wù)中國(guó)近萬(wàn)家的線下門店和千萬(wàn)級(jí)別的線上會(huì)員。
業(yè)務(wù)挑戰(zhàn)
云海零售系統(tǒng)是支撐著全渠道、全品類運(yùn)動(dòng)鞋服零售服務(wù)平臺(tái)的關(guān)鍵系統(tǒng)。最初，云盛海宏采用微服務(wù)和 MySQL 分庫(kù)分表的方式支撐云海零售系統(tǒng)。隨著業(yè)務(wù)的快速發(fā)展，MySQL 集群在復(fù)雜報(bào)表分析方面的支持不足。為了解決實(shí)時(shí)報(bào)表的問(wèn)題，云盛海宏引入了 Oracle 作為報(bào)表需求的分擔(dān)，并通過(guò) Otter 進(jìn)行數(shù)據(jù)的實(shí)時(shí)同步。然而，隨著數(shù)據(jù)爆發(fā)式增長(zhǎng)和需求難度的增加，基于 MyCAT 的分庫(kù)分表架構(gòu)面臨新的挑戰(zhàn)，需要增加或者調(diào)整表結(jié)構(gòu)，從維護(hù)層面增加了大量人力成本。此外，Oracle 也遇到了單點(diǎn)性能無(wú)法擴(kuò)展、聚合庫(kù)分析時(shí)效差等問(wèn)題，云盛海宏開始積極尋求替代方案。
經(jīng)過(guò)詳細(xì)的對(duì)比測(cè)試，包括大數(shù)據(jù)量的查詢以及復(fù)雜 SQL 的查詢性能等方面的細(xì)致比較，TiDB 在解決 Oracle 存在的問(wèn)題方面表現(xiàn)得非常出色且高效。在小規(guī)模試用取得效果之后，云盛海宏最終決定正式引入 TiDB。
解決方案
云海零售系統(tǒng)使用 TiDB 支撐面向最終用戶的營(yíng)促銷業(yè)務(wù)，橫向擴(kuò)展能力支持海量數(shù)據(jù)高并發(fā)，通過(guò)實(shí)時(shí)的行為數(shù)據(jù)分析洞察用戶需求，實(shí)現(xiàn)對(duì)用戶生命周期的全程追蹤，在 360° 畫像的基礎(chǔ)上進(jìn)行產(chǎn)品和服務(wù)創(chuàng)新。利用 TiDB HTAP 能力，實(shí)時(shí)獲取跨業(yè)務(wù)的聚合數(shù)據(jù)，支撐企業(yè)運(yùn)營(yíng)管理對(duì)實(shí)時(shí)、復(fù)雜數(shù)據(jù)查詢的需求，幾千行的業(yè)務(wù)報(bào)表 SQL 也能高效執(zhí)行。目前，云盛海宏已部署兩個(gè) TiDB 集群分別承擔(dān)前端和后臺(tái)的業(yè)務(wù)負(fù)載，集群總規(guī)模已達(dá)百臺(tái)，數(shù)據(jù)量將近 15 TB，業(yè)務(wù)高峰期 QPS 達(dá)到兩萬(wàn)多，最大業(yè)務(wù)單表達(dá)到了 600 GB。
圖：云海零售系統(tǒng)架構(gòu)示意圖
業(yè)務(wù)價(jià)值
高度兼容 MySQL 的分布式數(shù)據(jù)庫(kù)
TiDB 原生分布式架構(gòu)提供靈活的在線擴(kuò)容和縮容能力，快速響應(yīng)業(yè)務(wù)需求的變化。TiDB 高度兼容 MySQL 協(xié)議，應(yīng)用程序可實(shí)現(xiàn)從 MySQL 到 TiDB 的無(wú)縫遷移，無(wú)需考慮分庫(kù)分表以及分布式事務(wù)的實(shí)現(xiàn)，降低了業(yè)務(wù)開發(fā)人員的開發(fā)與學(xué)習(xí)等隱性成本。
簡(jiǎn)化數(shù)據(jù)棧，節(jié)省硬件資源
TiDB HTAP 混合負(fù)載能力為企業(yè)多個(gè)業(yè)務(wù)提供一棧式數(shù)據(jù)服務(wù)，既能支撐前端業(yè)務(wù)的在線事務(wù)處理，又能支撐多源數(shù)據(jù)的實(shí)時(shí)分析。新架構(gòu)降低了 80% 的 otter 數(shù)據(jù)同步通道， 與 MyCAT 分庫(kù)分表架構(gòu)相比，部分庫(kù)表冗余度從 10 份降低到 2 份，再加上 TiDB 自帶的壓縮能力，硬件資源可節(jié)省約 50% 左右。
運(yùn)維工作大幅提效
與管理 MySQL 集群相比，TiDB 可以做到輕量級(jí)維護(hù)。原先 DBA 以月或者季度為周期需要一次性完成十幾個(gè)實(shí)例的數(shù)據(jù)遷移，維護(hù)工作量巨大且數(shù)據(jù)遷移風(fēng)險(xiǎn)極高。引入 TiDB 之后，DBA 不用再為 MySQL 日常巡檢、歸檔和備份這些動(dòng)作耗費(fèi)時(shí)間，大幅提升了運(yùn)維工作的效率。
“疫情對(duì)我們的業(yè)務(wù)帶來(lái)了很大沖擊，我們開始發(fā)力做線上業(yè)務(wù)，技術(shù)側(cè)最直接的壓力來(lái)自于庫(kù)存管理模塊的變化。原本，從接到需要對(duì)接淘寶、京東、唯品會(huì)、抖音等平臺(tái)的需求到最終落地需要三個(gè)月甚至半年的時(shí)間，但因?yàn)槲覀兦捌谝呀?jīng)切換到了 TiDB，技術(shù)棧層面做好了充足的準(zhǔn)備，最終只用了兩周時(shí)間就完成了單平臺(tái)庫(kù)存管理模塊的調(diào)整”，云盛海宏首席架構(gòu)師洪亮如是說(shuō)道。
