共计 1827 个字符，预计需要花费 5 分钟才能阅读完成。
1 背景
公司存在多种物料品种、不同类型的库存和价值治理不一，存货零碎目前次要接入包装耗材、商品数据。目标是为了：
- 治理出入库价格、数量、库龄等业务数据，便于管理部门追溯及财务管控，帮助仓库晋升存货和物料的治理能力。
- 治理仓库物料及商品的费用价值，晋升核算及业务的效率，实现业务信息一体化及凭证自动化。
- 辅助打算或洽购部门查看库存，为采购计划提供数据撑持。
存货零碎先接入了包耗材数据，这类数据的个性是行数据不多，但每行数量很大。后接入了商品的库存，因为行数据量增长 N 倍以上 ，并且随着业务一直增长数据量越来越大，思考到原有底层设计不能很好的撑持这么大的数据量，故有了这次零碎的模型降级。
2 面对的问题
2.1 数据承接点问题
原业务流程在数据承接上逾越了外围 P0 链路后才把数据落地到库存利用（造成了肯定的技术危险，历史上也的确产生过一次技术故障，生产上游音讯代码有 bug，导致 P0 清结算链路数据下发呈现阻塞，影响了局部结算单据的解决时效）：
（1）数据落库在单据零碎
（2）关联订单数据
（3）查问出未税单价
（4）组装后下发库存
重构前的设计，老本表存储逻辑：不论每天成本价有没有变动，都会保护一条记录；台账表存储逻辑：每天如果有出入库数据依照业务类型汇总 + 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）团队价值：以赛代练，通过该我的项目造就了组内成员对于数仓平台和报表平台的实际和应用，拓宽了团队整体的技术栈，并积攒了数据开发的对应教训，也落地了数仓平台和报表平台的操作应用文档（节俭了后续团队成员的数据开发相熟接入的老本）。