存货库存模型升级始末 | 得物技术
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) 团队价值:以赛代练,通过该项目培养了组内成员对于数仓平台和报表平台的实践和使用,拓宽了团队整体的技术栈,并积累了数据开发的对应经验,也落地了数仓平台和报表平台的操作使用文档(节省了后续团队成员的数据开发熟悉接入的成本)。
作者:得物技术
链接:https://juejin.cn/post/7208817904559833149
来源:稀土掘金
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
GPU推理服务性能优化之路 | 得物技术
1背景 随着CV算法在业务场景中使用越来越多,给我们带来了新的挑战,需要提升Python推理服务的性能以降低生产环境成本。为此我们深入去研究Python GPU推理服务的工作原理,推理模型优化的方法。最终通过两项关键的技术: 1.Python的GPU与CPU进程分离,2.使用TensorRT对模型进行加速,使得线上大部分模型服务QPS提升5-10倍左右,大量节约了线上GPU推理服务的成本。 针对上面的两项关键技术,我们还自研了相关框架与工具进行沉淀。包括基于Python的CPU与GPU进程自动隔离的推理服务框架,以及对推理模型进行转TensorRT优化的调试工具。 此外针对不同的推理服务性能瓶颈,我们还梳理了各种实战优化技巧,比如CPU与GPU分离,TensorRT开启半精度优化,同模型混合部署,GPU数据传输与推理并行等。 下面从理论,框架与工具,实战优化技巧三个方面介绍下推理服务性能优化的方法。 2理论篇 2.1 CUDA架构 CUDA 是 NVIDIA 发明的一种并行计算平台和编程模型。它通过利用图形处理器 (GPU) 的处理能力,可大幅提升计算性能。 CUDA的架构中引入了主机...
- 下一篇
时效准确率提升之承运商路由网络挖掘 | 得物技术
1引子 履约时长是电商的生命线,直接关系到用户的消费体验。新华网[5]2022年双十一的报告显示,37.4%的受访者希望次日达,29.91%希望当日达。相较于其他物品,受访者对手机、电脑、数码产品的物流时效要求更高,更希望当日或1-2天内能收到货。 得物履约场景中,主要的阶段包括仓库内生产和第三方承运商配送。在用户支付时,得物会根据仓库的生产情况和运配资源,给用户一个承诺时效。 1.1 为什么要预测承运商的线路时效 在履约过程中,得物需要监控订单的流转,及时的发现可能超时的订单(与和用户承诺时效相比),这里包含仓库生产的监控和三方配送的监控。在实际过程中我们发现:配送节点发生变更时,承运商给的预测偏保守的。下面例子中,到了营业部承运商才给到比较精准的预计送达时间,故在分拣中心使用承运商的预计送达时间容易出现误报。 下图是承运商接口返回的预计送达时效的宽松指数,可以看到在接近目的地时,承诺时效才比较准确。 2承运商网络是如何运作的 在构建承运商网络之前,需要先了解承运商网络是如何工作的。下面是从A网点到E网点的配送示意图,分为以下内容: (1)节点,包含的揽收和派送网点以及分拣中心。 (...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- CentOS8安装MyCat,轻松搞定数据库的读写分离、垂直分库、水平分库
- CentOS8编译安装MySQL8.0.19
- CentOS6,CentOS7官方镜像安装Oracle11G
- CentOS7,8上快速安装Gitea,搭建Git服务器
- SpringBoot2整合Thymeleaf,官方推荐html解决方案
- MySQL8.0.19开启GTID主从同步CentOS8
- SpringBoot2更换Tomcat为Jetty,小型站点的福音
- Red5直播服务器,属于Java语言的直播服务器
- CentOS6,7,8上安装Nginx,支持https2.0的开启
- CentOS8,CentOS7,CentOS6编译安装Redis5.0.7