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

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

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

1.1 业务早期

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

这种现象一般表现为：

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

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

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

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

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有不错的封装,通过数据路由能做一些简单的数据拼接,但在调试上线复杂度上依然有不小的复杂度；

2.2 实时架构1.0

2.2.1 flink+kafka+ClickHouse

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

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

非常弱的update delete，不能保证原子性和实时性。

clickhouse只适合数据量大，业务模型简单,更新场景少的场景。

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

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

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

库内环节异常的多，从卖家发货到收货、分拣、质检、拍照、鉴别、防伪、复查、打包、出库、买家签收等十几个甚至更多的环节，一张以商品实物id为主键的大宽表，需要join几十张业务表；

clickhouse不支持标准的upsert模式，可以通过使用AggregatingMergeTree 引擎字段类型使用SimpleAggregateFunction(anyLast, Nullable(UInt64)) 合并规则取最后一条非null数据可以实现upsert相似的功能，但读时合并性能有影响。

2.3 实时架构2.0

2.3.1 flink+kafka+hologres

因此我们迫切的希望有支持upsert能力的olap数据库,同时能搞定供应链写多少的场景,也能搞定我们复杂查询的场景,我们希望的olap数据至少能做到如下几点：

有upsert能力，能对flink大任务做有效拆分；

存算分离，复杂业务计算，不影响业务写入，同时能平滑扩缩容；

有一定的join能力带来一些灵活度；

有完善的分区机制，热数据查询性能不受整体数据增长影响；

完善的数据备份机制。

这样一个行列混合的olap数据库,支持upsert,支持存算分离,还是比较符合我们的预期。但是，我们还是希望能够做到一个统一的标准，因为这样可以避免不同厂商之间的数据差异造成的数据不一致。

（编辑：驾考网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!