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

原文：得物供应链复杂业务实时数仓建设之路_数据_join_mysql

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 带来的性能消耗。

但是存在以下几个问题：

虽然 otter 有不错的封装,通过数据路由能做一些简单的数据拼接,但在调试上线复杂度上依然有不小的复杂度；

otter 伪装 mysql 从库同时要去做 etl 逻辑,把 cdc 干的活和实时 ETL 的活同时干了,耦合度较高。

2.2 实时架构 1.0

2.2.1 flink+kafka+ClickHouse

在上述调研尝试后都没有解决根本的问题，我们开始把目标建立标准的实时数仓的思路上来，在 20 年 olap 没有太多的可选项,我们把目标放在 clickhouse 上。

为了保证顺序 append 每次写入都会生成一个 part 文件，满足一定条件后台定时合并。

非常弱的 update delete，不能保证原子性和实时性。* clickhouse 只适合数据量大，业务模型简单,更新场景少的场景。

存算不分离，复杂查询影响 clickhouse 写入。

因为 clickhouse 的这些特性,尤其是不支持 upsert 的情况下,我们通常需要提前把大宽表的数据提前在 flink 聚合好,并且供应链数据生命周期长,作业流程也长如：

货物的生命周期较短时长为一周，长周期时长超过 1 个月；

库内环节异常的多，从卖家发货到收货、分拣、质检、拍照、鉴别、防伪、复查、打包、出库、买家签收等十几个甚至