導(dǎo)言

日前，國(guó)內(nèi)知名SaaS ERP服務(wù)商萬(wàn)里牛, 在其電商ERP系統(tǒng)中引入了阿里云PolarDB MySQL數(shù)據(jù)庫(kù)，借助PolarDB MySQL 一站式的事務(wù)處理和數(shù)據(jù)分析解決方案，同時(shí)利用In-Memory Column Index（IMCI）和并行執(zhí)行提供的HTAP實(shí)時(shí)數(shù)據(jù)分析能力以及高壓縮引擎X-Engine提供的低成本海量記錄讀寫能力，實(shí)現(xiàn)了SaaS ERP系統(tǒng)的“降本增效”，解決了ERP SaaS平臺(tái)客戶數(shù)據(jù)快速增長(zhǎng)后的復(fù)雜查詢分析效率難題以及歷史訂單記錄數(shù)增長(zhǎng)帶來的存儲(chǔ)成本飆升難題，通過一站式的解決方案快速滿足業(yè)務(wù)發(fā)展。

關(guān)于萬(wàn)里牛

萬(wàn)里牛是湖畔網(wǎng)絡(luò)旗下的產(chǎn)品品牌，萬(wàn)里牛以ERP為核心，形成包括WMS、跨境ERP、BI、門店零售、云訂貨等在內(nèi)的產(chǎn)品矩陣，服務(wù)于開展國(guó)內(nèi)電商、跨境電商和實(shí)體門店等零售業(yè)務(wù)場(chǎng)景的企業(yè)，經(jīng)過多年發(fā)展，萬(wàn)里牛已成為國(guó)內(nèi)電商ERP領(lǐng)域廣受消費(fèi)者信賴的SaaS服務(wù)提供商。

萬(wàn)里牛基于阿里云豐富的云產(chǎn)品體系構(gòu)建其電商SaaS平臺(tái)。在數(shù)據(jù)庫(kù)方面，大量使用了OLTP型產(chǎn)品PolarDB MySQL, RDS MySQL，NoSQL使用了Redis和Lindorm等產(chǎn)品，在 OLAP使用了在線數(shù)倉(cāng)和離線分析產(chǎn)品，通過產(chǎn)品和方案的組合來滿足電商SaaS的各個(gè)業(yè)務(wù)模塊對(duì)數(shù)據(jù)庫(kù)的各種需求。

萬(wàn)里牛電商SaaS ERP系統(tǒng)

在電商領(lǐng)域，ERP系統(tǒng)可以幫助商家降低履約成本，提升作業(yè)協(xié)同效率，同時(shí)幫助提高企業(yè)管理效率，其涉及到電商業(yè)務(wù)流程的各個(gè)方面，覆蓋訂單處理、倉(cāng)儲(chǔ)管理、采購(gòu)協(xié)同、分銷管理、庫(kù)存管理、售后工單、業(yè)財(cái)一體、數(shù)據(jù)分析等各個(gè)模塊。

訂單管理（OMS）

訂單處理是萬(wàn)里牛ERP的核心模塊，萬(wàn)里牛支持來自200多個(gè)國(guó)內(nèi)外電商平臺(tái)的訂單通過實(shí)時(shí)同步的方式下載到ERP中。一旦訂單被下載，系統(tǒng)會(huì)根據(jù)自動(dòng)化匹配策略，選擇最合適的倉(cāng)庫(kù)、快遞和是否需要拆單，以確保最快的履約和最低的成本。超過90%的訂單通常會(huì)自動(dòng)進(jìn)入下一步，通過智能策略進(jìn)行處理，而其他訂單則需要進(jìn)行人工審核，通過客服與消費(fèi)者的溝通來決定是否延遲發(fā)貨或進(jìn)入售后環(huán)節(jié)。如果消費(fèi)者通過線上平臺(tái)提交退款或退換貨申請(qǐng)，訂單會(huì)自動(dòng)處理，無(wú)需人工介入。

倉(cāng)儲(chǔ)管理

訂單經(jīng)過人工或自動(dòng)化審核后，會(huì)進(jìn)入萬(wàn)里牛智能倉(cāng)儲(chǔ)系統(tǒng)的作業(yè)環(huán)節(jié)。這里，倉(cāng)庫(kù)工作人員會(huì)進(jìn)行打單、分揀、打包、驗(yàn)貨、稱重和出庫(kù)等全流程，以確保消費(fèi)者能盡早收到自己心儀的寶貝。當(dāng)然，系統(tǒng)也有多項(xiàng)智能策略來提高倉(cāng)內(nèi)作業(yè)效率。

每一個(gè)商品都按照標(biāo)準(zhǔn)的庫(kù)位號(hào)、貨架號(hào)、層數(shù)等整齊地存放在貨架上，揀貨員可以使用播種揀貨模式，自動(dòng)帶入任務(wù)，依序?qū)⒂唵畏湃雽?duì)應(yīng)的播種框中，按照PDA提示到達(dá)指定庫(kù)位，掃描條碼將商品放入指定的播種框中。使用PDA指導(dǎo)，倉(cāng)儲(chǔ)作業(yè)人員可以通過單次“S”型路徑，走更少的步數(shù)拿更多的貨，快速高效地完成該波次下所有訂單的揀貨任務(wù)，省時(shí)省力。

數(shù)據(jù)管理

基于萬(wàn)里牛ERP中龐大的商品、訂單數(shù)據(jù)，搭配萬(wàn)里牛ERP里的幾十張多維度報(bào)表和BI工具，輕松實(shí)現(xiàn)高效、全面的數(shù)據(jù)分析和決策支持。其中，多環(huán)節(jié)報(bào)表集合能夠?qū)崿F(xiàn)全場(chǎng)景數(shù)據(jù)的覆蓋，讓用戶一目了然地掌握企業(yè)各個(gè)環(huán)節(jié)的數(shù)據(jù)情況。預(yù)設(shè)數(shù)據(jù)分析模板則為用戶提供了量化業(yè)務(wù)環(huán)節(jié)的核心指標(biāo)，幫助他們更加全面地分析和把握企業(yè)的運(yùn)營(yíng)情況。

零代碼自定義搭建數(shù)據(jù)看板是另一個(gè)非常實(shí)用的功能，它能夠讓用戶輕松抓取核心業(yè)務(wù)信息，無(wú)需編寫代碼或者擁有專業(yè)的技能，通過拖拉拽的形式讓用戶能夠快速建立自己的數(shù)據(jù)看板，實(shí)現(xiàn)高效的數(shù)據(jù)分析和管理。此外，賬號(hào)自定義權(quán)限設(shè)置能夠保障用戶數(shù)據(jù)安全，讓企業(yè)內(nèi)部數(shù)據(jù)不被泄露或?yàn)E用。最后，銷量預(yù)測(cè)、庫(kù)存預(yù)警等智能分析能夠靈活配合市場(chǎng)決策，讓企業(yè)的決策更加準(zhǔn)確和高效。

萬(wàn)里牛ERP數(shù)據(jù)庫(kù)采用典型的SaaS多租戶架構(gòu)，某個(gè)商家的慢SQL可能影響同數(shù)據(jù)庫(kù)上其他商家系統(tǒng)卡和慢，同時(shí)訂單管理作為ERP的核心，也是數(shù)據(jù)密集型應(yīng)用，對(duì)數(shù)據(jù)寫入和分析實(shí)時(shí)要求高，在多租戶架構(gòu)下，慢SQL雪崩效應(yīng)可能進(jìn)一步放大，因此，解決慢SQL能夠有效提升客戶體驗(yàn)和降低系統(tǒng)運(yùn)行風(fēng)險(xiǎn)。

增效：PolarDB IMCI提升訪問體驗(yàn)

萬(wàn)里牛ERP最初使用MySQL作為核心數(shù)據(jù)庫(kù)，在早期數(shù)據(jù)體量較小，業(yè)務(wù)模式相對(duì)簡(jiǎn)單的情況下，MySQL支撐了業(yè)務(wù)發(fā)展，但隨著公司規(guī)模擴(kuò)大、客戶體量逐年增加，業(yè)務(wù)場(chǎng)景變得越來越復(fù)雜，日單超數(shù)十萬(wàn)的客戶數(shù)量也不斷持續(xù)增加。隨著直播等新的業(yè)態(tài)發(fā)展，原生MySQL已經(jīng)無(wú)法完全滿足各種復(fù)雜查詢和承受突發(fā)的爆單壓力。

為解決復(fù)雜查詢的效率和技術(shù)問題，萬(wàn)里牛技術(shù)團(tuán)隊(duì)采用了PolarDB MySQL提供的In-Memory Column Index功能。

PolarDB一站式HTAP數(shù)據(jù)庫(kù)產(chǎn)品解決方案

使用IMCI技術(shù)方案，萬(wàn)里牛ERP系統(tǒng)可以在無(wú)需額外技術(shù)研發(fā)投入和業(yè)務(wù)功能調(diào)整的前提下，快速解決眾多數(shù)據(jù)庫(kù)痛點(diǎn)。

以下舉例介紹萬(wàn)里牛ERP如何使用IMCI的。

靈活查詢的高效響應(yīng)

電商ERP面向各個(gè)商品類目客戶群體，每個(gè)類目的業(yè)務(wù)細(xì)節(jié)和業(yè)務(wù)需求多樣且差異較大，體現(xiàn)在ERP系統(tǒng)里，訂單查詢頁(yè)面就需要實(shí)現(xiàn)各種查詢項(xiàng)來滿足用戶使用，同時(shí)數(shù)據(jù)需要進(jìn)行實(shí)時(shí)匯總查詢，例如庫(kù)存、快遞成本。

以選擇訂單修改快遞為例，快遞公司會(huì)高頻的調(diào)整快遞費(fèi)用計(jì)算規(guī)則，計(jì)算規(guī)則由包裹重量，最大單邊長(zhǎng)度，收件地區(qū)等因素決定，商家需要基于此類條件，快速的查詢出對(duì)應(yīng)的訂單，調(diào)整快遞申請(qǐng)電子面單，否則就會(huì)影響發(fā)貨時(shí)效和成本。在使用PolarDB In-Memory Column Index之前，主要依賴于MySQL行存索引能力，但對(duì)于類似如下的復(fù)雜SQL，如果交易trade存量在1000萬(wàn)以上，查詢延時(shí)會(huì)急劇增加，不能有效保證客戶的頁(yè)面響應(yīng)時(shí)間。

SELECT?a.*FROM?TRADE?aWHERE?a.COMPANY?=?'~7A~'??AND?a.SHOP?IN?('~2F2~',?'~D41D4~',?'~DB60~')??AND?a.STORAGE?IN?('~6251FA7~',?'~72EBD3~',?'~47BA~',?'~B5C9~')??AND?(a.MESSAGE?LIKE?CONCAT('%',?'停發(fā)11.24',?'%')?OR?a.MEMO?LIKE?CONCAT('%',?'停發(fā)11.24',?'%')?OR?a.REMARK?LIKE?CONCAT('%',?'停發(fā)11.24',?'%'))??AND?a.STATE?=?0???AND?STATUS?=?0???AND?a.weight?>=?0?and?a.weight?<=0.18??AND?a.sum?>=?1?and?a.sum?<=?2??AND?NOT?EXISTS???(????SELECT?1?????FROM?ORDER?o?????WHERE?a.UID?=?o.SUID??????AND?(o.ITEM_ID?IN?('~35CA~',?'~0325~')?OR?o.SKU_ID?IN?('~0EC46~','~903~',?'~82AD~'))??)???AND?NOT?EXISTS???(????SELECT?1?????FROM?ORDER?o???????LEFT?JOIN?trade?t?ON?o.sys_trade?=?t.salercpt_uid???????LEFT?JOIN?INVENTORY?pi?ON?pi.COMPANY?=?o.COMPANY?AND?pi.SKU_ID?=?o.SKU_ID?AND?pi.storage_id?=?t.STORAGE??????WHERE?o.SUID?=?a.UID???????AND??IFNULL(pi.P_QUANTITY,?0)?<=?IFNULL(pi.P_LOCK,?0)??????AND?o.COMPANY?=?'~7A4F4~'???????AND?o.order_status?!=?x???);

在引入PolarDB IMCI之前， 對(duì)應(yīng)的訂單管理系統(tǒng)SQL監(jiān)控如下，會(huì)存在大量訂單查詢慢SQL：

使用MySQL慢查詢監(jiān)控

在引入使用PolarDB MySQL之后，我們?cè)谠蠵olarDB集群上配置一個(gè)帶列索引的節(jié)點(diǎn)，然后在復(fù)雜查詢的表上創(chuàng)建了列存索引。之后將前述復(fù)雜的訂單查詢請(qǐng)求通過hint注解，直接打到IMCI節(jié)點(diǎn)。在trade單量超過1000萬(wàn)數(shù)記錄條目的場(chǎng)景下，PolarDB IMCI能夠大幅度提升查詢速度，同時(shí)也極大的降低了普通業(yè)務(wù)讀寫節(jié)點(diǎn)的壓力。

如下圖所示，在使用PolarDB IMCI之后，平均執(zhí)行時(shí)間和最大執(zhí)行時(shí)間都有了大幅降低。在一個(gè)8C的計(jì)算節(jié)點(diǎn)上最大執(zhí)行時(shí)間也都能控制在10S以下，在大促時(shí)間通過Serverless彈升計(jì)算節(jié)點(diǎn)規(guī)格，查詢時(shí)間還能進(jìn)一步降低。

使用IMCI之后的SQL響應(yīng)延時(shí)監(jiān)控

一站式事務(wù)處理和實(shí)時(shí)數(shù)據(jù)分析

在使用PolarDB IMCI之前， 受限于MySQL的復(fù)雜查詢效率限制，如果需要在處理日常OLTP業(yè)務(wù)的同時(shí)運(yùn)行復(fù)雜查詢和實(shí)時(shí)報(bào)表，通常無(wú)法滿足報(bào)表查詢的時(shí)延要求。此時(shí)則需要引入其他專門的數(shù)倉(cāng)或者檢索系統(tǒng)并將數(shù)據(jù)同步過去，然后使用兩套系統(tǒng)的組合方案，會(huì)遇到兩個(gè)挑戰(zhàn)：

數(shù)據(jù)一致性問題：通常OLTP系統(tǒng)和下游的數(shù)倉(cāng)或者檢索系統(tǒng)會(huì)通過Binlog進(jìn)行數(shù)據(jù)復(fù)制， 這個(gè)數(shù)據(jù)同步延遲只能控制在秒級(jí)別，且偶爾會(huì)出現(xiàn)延遲抖動(dòng)，導(dǎo)致用戶在下游數(shù)倉(cāng)系統(tǒng)查詢的數(shù)據(jù)與ERP系統(tǒng)的OLTP數(shù)據(jù)中數(shù)據(jù)不一致性，極大地影響用戶體驗(yàn)。 一個(gè)典型場(chǎng)景，當(dāng)上下游數(shù)據(jù)延遲時(shí)， 商家在ERP系統(tǒng)中對(duì)某一批訂單做發(fā)貨處理之后，去刷新監(jiān)控大屏頁(yè)面查看當(dāng)前訂單的發(fā)貨統(tǒng)計(jì)信息，會(huì)發(fā)現(xiàn)剛已經(jīng)發(fā)貨的那批訂單還處于未發(fā)貨狀態(tài)。

數(shù)據(jù)冗余及維護(hù)：ERP系統(tǒng)本身非常復(fù)雜，涉及到非常多的系統(tǒng)組合，因此存在很多庫(kù)和表。對(duì)于萬(wàn)里牛還有個(gè)數(shù)據(jù)量大的難題，引入多套存儲(chǔ)系統(tǒng)就會(huì)產(chǎn)生重復(fù)數(shù)據(jù)和多套代碼實(shí)現(xiàn)，不僅浪費(fèi)開發(fā)資源，還會(huì)導(dǎo)致高昂的存儲(chǔ)成本。

傳統(tǒng)多套系統(tǒng)組合的HTAP方案

因此傳統(tǒng)方案無(wú)法有效的滿足萬(wàn)里牛的需求，PolarDB HTAP是一站式的事務(wù)處理和數(shù)據(jù)分析解決方案，首先在現(xiàn)有PolarDB集群中通過添加列索引即可以讓復(fù)雜查詢提速百倍，免去了維護(hù)多套系統(tǒng)的麻煩，其次PolarDB的列存分析節(jié)點(diǎn)通過Redo物理日志與寫入節(jié)點(diǎn)進(jìn)行實(shí)時(shí)數(shù)據(jù)同步，平時(shí)同步延時(shí)在亞毫秒且高峰期不超過5ms，再結(jié)合PolarDB Proxy的事務(wù)一致性讀配置可以實(shí)現(xiàn)強(qiáng)一致讀寫分離。萬(wàn)里牛ERP系統(tǒng)在切換到PolarDB后，借助PolarDB 一體化的IMCI ，以很低的開發(fā)成本解決了對(duì)實(shí)時(shí)數(shù)據(jù)做復(fù)雜查詢的效率問題，不再需要額外的數(shù)倉(cāng)系統(tǒng)。在減少成本的同時(shí)，避免了開發(fā)資源的浪費(fèi)，并且提高了用戶體驗(yàn)。

萬(wàn)里牛ERP訂單系統(tǒng)數(shù)據(jù)庫(kù)實(shí)例拓?fù)?/p>

萬(wàn)里牛ERP從22年開始將訂單和交易數(shù)據(jù)存儲(chǔ)在PolarDB MySQL上，充分利用了其強(qiáng)大的HTAP能力，針對(duì)相關(guān)業(yè)務(wù)代碼的調(diào)整，只需要在SQL中增加Hint注解即可實(shí)現(xiàn)，無(wú)額外新增開發(fā)成本投入。

在整體使用PolarDB IMCI之后，在單集群8C16G數(shù)據(jù)庫(kù)配置，以O(shè)MS典型業(yè)務(wù)場(chǎng)景為例，每小時(shí)壓測(cè)指標(biāo)如下：

整體而言，大幅加快了ERP業(yè)務(wù)系統(tǒng)的處理速度，從商家側(cè)來看，萬(wàn)里牛頭部某服飾商家反饋說：“萬(wàn)里牛的ERP系統(tǒng)經(jīng)過近期升級(jí)后，給我們感覺更快了，比如說，審單、發(fā)貨、物流推送等相關(guān)業(yè)務(wù)流程提速明顯，對(duì)我們商家來說，可以大幅提升經(jīng)營(yíng)效率！”

降本：高壓縮引擎X-Engine實(shí)現(xiàn)海量交易訂單歷史存儲(chǔ)

作為國(guó)內(nèi)領(lǐng)先的電商ERP SaaS系統(tǒng)開發(fā)商，萬(wàn)里牛所管理的數(shù)據(jù)具有兩個(gè)特點(diǎn)：

數(shù)據(jù)體量大：考慮到交易訂單按時(shí)間積累的特征，交易訂單庫(kù)單個(gè)表的行數(shù)往往達(dá)到千萬(wàn)甚至億級(jí)別， 耗費(fèi)大量的存儲(chǔ)成本。

周期性明顯：交易數(shù)據(jù)通常在7天、30天和90天后出現(xiàn)明顯的使用熱度下降，但考慮到售后等因素，這些數(shù)據(jù)又不能完全冷歸檔，對(duì)于很多類目產(chǎn)品，如大家電類等售后有效期長(zhǎng)的產(chǎn)品需要對(duì)歷史數(shù)據(jù)進(jìn)行修改。

萬(wàn)里牛在使用PolarDB期間，PolarDB研發(fā)團(tuán)隊(duì)針對(duì)歷史交易記錄/聊天記錄等數(shù)據(jù)量大且訪問周期性特征明顯的數(shù)據(jù)存儲(chǔ)問題，提出了在線/歸檔一體化的混合引擎架構(gòu)， 即在PolarDB 標(biāo)準(zhǔn)版本集群中，除了InnoDB這一事務(wù)引擎之外，同時(shí)支持實(shí)現(xiàn)了X-Engine高壓縮引擎。

通過X-Engine這一LSM-tree引擎冷熱分層，壓縮率高(一般業(yè)務(wù)在5倍左右) 的特性來滿足海量數(shù)據(jù)存儲(chǔ)的降本訴求。 而X-Engine的事務(wù)支持，SQL兼容性與InnoDB基本一致， 對(duì)業(yè)務(wù)開發(fā)沒有適配成本。用戶可以在同一個(gè)PolarDB集群中，根據(jù)不同表的數(shù)據(jù)量和訪問特點(diǎn)，靈活地選擇InnoDB引擎或者X-Engine引擎。并且可以使用DDL語(yǔ)句在這兩種引擎之間自由轉(zhuǎn)換。

通過將已發(fā)貨完結(jié)訂單存儲(chǔ)到同一個(gè)Polardb實(shí)例的X-Engine高壓縮引擎中，實(shí)現(xiàn)了數(shù)倍的存儲(chǔ)成本壓縮, 而未發(fā)貨訂單繼續(xù)使用InnoDB引擎。萬(wàn)里牛基于ERP系統(tǒng)不同請(qǐng)求的訪問特點(diǎn)，使用了兩種訪問模式：一種是在頁(yè)面交互開始時(shí)直接區(qū)分在線和歷史訂單查詢，另一種是在代碼中實(shí)現(xiàn)冷熱訂單的混合查詢。最終在用戶體驗(yàn)基本不變的情況下，如下圖所示，我們調(diào)整后的存儲(chǔ)總量減少了十幾T，每個(gè)表的平均壓縮比可達(dá)1/4，甚至有部分表可以壓縮到1/10的大小，總體來看存儲(chǔ)成本下降80%。

萬(wàn)里牛ERP部分表使用X-Engine壓縮效果

為了進(jìn)一步降低存儲(chǔ)成本，PolarDB可以使用PSL4（PolarStore Level 4）的磁盤，PSL4采用采用阿里巴巴自研的硬件壓縮盤（Smart-SSD）技術(shù)，在物理SSD磁盤層面壓縮、解壓縮存儲(chǔ)的數(shù)據(jù)，在保持性能影響可控的情況下，使單位容量數(shù)據(jù)的存儲(chǔ)價(jià)格更低。

后記

萬(wàn)里牛ERP在訂單管理場(chǎng)景下使用PolarDB一站式的事務(wù)處理和數(shù)據(jù)分析解決方案，不僅提升了產(chǎn)品用戶體驗(yàn)而且降低了數(shù)據(jù)層面的研發(fā)和維護(hù)成本，后續(xù)，將進(jìn)一步推廣到其他多數(shù)據(jù)密集型的ERP系統(tǒng)中，擴(kuò)大PolarDB for SaaS中的使用范圍。

近年來，國(guó)家政策的鼓勵(lì)和扶持推動(dòng)了中小企業(yè)、跨境電商、數(shù)字政府等領(lǐng)域的數(shù)字化轉(zhuǎn)型需求. 而企業(yè)管理和業(yè)務(wù)流程的標(biāo)準(zhǔn)化和復(fù)雜化，為SaaS企業(yè)提供了豐富的應(yīng)用場(chǎng)景和市場(chǎng)。而中國(guó)的SaaS服務(wù)開發(fā)商受益于云計(jì)算技術(shù)的成熟和普及，從誕生之日起即充分利用云計(jì)算平臺(tái)提供的底層基礎(chǔ)設(shè)施，以降低開發(fā)和運(yùn)維成本。

PolarDB MySQL的HTAP能力和高壓縮引擎能力即是兩個(gè)典型適用于頭部SaaS客戶的功能，高壓縮致力于讓客戶以更低的成本存儲(chǔ)更多的數(shù)據(jù)并從數(shù)據(jù)中發(fā)現(xiàn)商機(jī)，而HTAP能力讓SaaS企業(yè)無(wú)需使用復(fù)雜架構(gòu)即可提升對(duì)海量數(shù)據(jù)局的查詢分析效率，為客戶提升更好的體驗(yàn)，助力提升SaaS企業(yè)商業(yè)化能力，進(jìn)而幫助客戶帶來自身業(yè)績(jī)的增長(zhǎng)。