1、背景

公司存在多種物料種類、不同類型的庫存和價值管理不一，存貨系統目前主要接入包裝耗材、商品數據。目的是為了：

• 管理出入庫價格、數量、庫齡等業務數據，便于管理部門追溯及財務管控，協助倉庫提升存貨和物料的管理能力。
• 管理倉庫物料及商品的費用價值，提升核算及業務的效率，實現業務信息一體化及憑證自動化。
• 輔助計劃或采購部門查看庫存，為采購計劃提供數據支撐。

存貨系統先接入了包耗材數據，這類數據的特性是行數據不多，但每行數量很大。后接入了商品的庫存，由于行數據量增長N倍以上，并且隨著業務不斷增長數據量越來越大，考慮到原有底層設計不能很好的支撐這么大的數據量，故有了這次系統的模型升級。

2、面對的問題

2.1 數據承接點問題

原業務流程在數據承接上跨越了核心P0鏈路后才把數據落地到庫存應用（造成了一定的技術風險，歷史上也確實發生過一次技術故障 ，消費上游消息代碼有bug，導致P0清結算鏈路數據下發出現阻塞，影響了部分結算單據的處理時效）：

（1）數據落庫在單據系統

（2）關聯訂單數據

（3）查詢出未稅單價

（4）組裝后下發庫存

2.1 數據存儲設計問題（數據每日倍化膨脹）

重構前的設計，成本表存儲邏輯：不管每天成本價有沒有變化，都會維護一條記錄；臺賬表存儲邏輯：每天如果有出入庫數據按照業務類型匯總+2條期初期末數據，如果沒有出入庫數據，只保存2條期初期末數據。從存儲邏輯不難看出存儲了很多冗余數據，且臺賬表期初期末數據以行的形式存儲也是不合理的。

如下是例子數據

2.2.1 明細表（record）

每天出入庫、調價單的數據

2.2.2 成本表（cost_price）

所有物料每天都需要計算一個成本價

2.2.3 臺賬表（ledger）

日臺賬：匯總當天明細數據、以及期初、期末價格和數量 月臺賬：匯總當月明細數據、以及期初、期末價格和數量

2.3 頁面數據查詢性能瓶頸

2.3.1 大盤&臺賬表分析:

通過大盤和臺賬表分析，在接入倉庫商品數據后，頁面查詢接口耗時很高，接口性能存在問題

2.3.2 日/月進銷存也面臨同樣的問題

3、解決方案

3.1 數據承接優化

3.1.1 庫存應用直接承接單據池落地信息表

3.1.2 具體實現過程

3.2 數據存儲設計問題優化

3.2.1 簡單示例

比如一個物料，3月1日的成本價為100元，后在3月30日又進一件成本價200元的相同物料，則我們庫里的記錄信息如下， 2條數據即可 ， 【無須每日更新數據，只有當前物料當日有出入庫、調價數據時，才需要插入當日最新數據】，

實際場景，當業務代碼查詢3月10日的成本價時，往前查詢到03.01的數據即可

3.2.2 期望的數據存儲樣式

而不是30條數據 （ 03.02 至 03.29，這28條數據都是冗余的數據）

3.2.3 頁面數據查詢性能瓶頸解決方案

由于數據存儲邏輯變更，只會存儲有變動的數據，而進銷存報表是每天都需要產出的不管數據有沒有變化。結合當前業務邏輯以及數據量最后決定把數據同步到數倉，在數倉進行數據補全后，通過報表平臺拉取報表信息。

棄用當前后管平臺查詢報表   轉為使用報表平臺拉取庫存報表信息

數據同步流程如下：

報表平臺具備生成類似于Excel的數據展示，以及任意維度查詢信息的能力，同時也具備Excel導出的功能

4、重構后的價值

4.1 量化業務價值：

每月節省核算以及審核時間約30小時，占核算組總月結時間比例為30%。

4.2 不可量化業務價值

• 將倉庫業務納入存貨系統，龐大數據量通過系統自動核算，輸出表格，節約手工核算的時間，以及提升核算數據的準確性，解決無法通過表格實現的困境；
• 提升核算質量的同時，可以完成更多庫存、銷售數據分析，如周轉率分析，出入庫渠道分析，減值計提等等。分析結果提升公司退貨商品的管理以及庫存管理。
• 功能重構從基礎數據、入庫模型、調價單、成本計算、出庫模型、重算、報表都做了升級，在數據接收、成本計算等過程中增加了校驗邏輯和修復數據的功能。

4.3 技術價值

（1）技術價值：首次嘗試了在線TIDB切換流程（包括數據復制、數據同步、數據比對、數據切流），積累了TIDB切換經驗，給后續的TIDB遷移專項提供了經驗沉淀。

（2）技術價值：把P0級的清結算應用里的部分功能遷移到庫存應用中，解決了大流量的倉庫數據下傳至清結算應用的風險，實現了交易和非交易在應用級別的解耦和隔離。

（3） 團隊價值：以賽代練，通過該項目培養了組內成員對于數倉平臺和報表平臺的實踐和使用，拓寬了團隊整體的技術棧，并積累了數據開發的對應經驗，也落地了數倉平臺和報表平臺的操作使用文檔（節省了后續團隊成員的數據開發熟悉接入的成本）。