得物供应链复杂业务实时数仓建设之路

1 背景

得物供应链业务是纷繁复杂的，我们既有 JIT 的现货模式中间夹着这大量的仓库作业环节，又有到仓的寄售，品牌业务，有非常复杂的逆向链路。在这么复杂的业务背后，我们需要精细化关注人货场车的效率和成本，每一单的及时履约情况，要做到这一点我们需要各粒度和维度的数据来支撑我们的精细化管理。

1.1 业务早期

业务早期，业务反馈我们后台管理系统某些报表查询慢。查询代码可知，如下图：

这种现象一般表现为：

大表 JOIN,rdbms 不擅长做数据聚合,查询响应慢,调优困难；

多表关联,索引优化,子查询优化,加剧了复杂度,大量索引,读库磁盘空间膨胀过快；

数据量大,多维分析困难,跨域取数,自助拉到实时数据困难等。

一方面原因是系统设计之初,我们主要关注业务流程功能设计,事务型业务流程数据建模,对于未来核心指标的落地,特别是关键实时指标落地在业务快速增长的情况下如何做到非常好的支撑。mysql 在此方面越来越捉襟见肘。

另外一方面原因是 mysql 这种 oltp 数据库是无法满足实时数据分析需求的,我们需要探索一套实时数据架构,拉通我们的履约,仓储,运配等各域的数据,做有效串联,因此我们开始了我们的实时数据架构探索，下图是我们一些思考。

附:数据视角的架构设计也是系统架构设计的重要组成部分。

2 架构演变

2.1 原始阶段

2.1.1 通过 Adb(AnalyticDB for MySQL)完成实时 join

通过阿里云 DTS 同步直接将业务库单表实时同步到 Adb，通过 Adb 强大的 join 能力和完全兼容 mysql 语法,可以执行任意 sql，对于单表大数据量场景或者单表和一些简单维表的 join 场景表现还是不错的,但是在业务复杂,复杂的 sql rt 很难满足要求,即使 rt 满足要求,单个 sql 所消耗的内存,cpu 也不尽人意,能支撑的并发量很有限。

2.1.2 通过 Otter 完成大宽表的建设

基于 Canal 开源产品，获取数据库增量日志数据并下发，下游消费增量数据直接生成大宽表，但是宽表还是写入 mysql 数据库，实现单表查询，单表查询速度显著提升，无 olap 数据库的常见做法，通过宽表减少 join 带来的性能消耗。