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 个月；
- 库内环节异样的多，从卖家发货到收货、分拣、质检、拍照、甄别、防伪、复查、打包、出库、买家签收等十几个甚至更多的环节，一张以商品实物 id 为主键的大宽表，须要 join 几十张业务表；
- 供应链零碎晚期设计没有每张表都会冗余惟一单号（入库单，作业单，履约单）这样的关键字段，导致没方法间接简略的 join 数据。
- 在这样一个架构下，们的 flink 在老本上，在稳定性保护上，调优上做的十分吃力。
附: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, 反对存算拆散, 还是比拟合乎咱们的预期。
目前这样一套架构反对了供应链每天数千人的报表取数需要, 以及每天 10 亿数据量的导出, 访问量在得物所有 to B 零碎中排名靠前。
2.3.2 咱们遇到的一些问题
多工夫问题 如何设置 segment_key, 抉择哪个业务字段作为 segment_key 供应链几十个环节都有操作工夫, 在不带 segment_key 的状况下性能如何保障，困扰了咱们一段时间。
设置正当的 segment_key 如有序的工夫字段, 能够做到齐全程序写。每个 segment 文件都有个 min,max 值, 所有的工夫字段过去只须要去比拟下在不在这个最小值最大值之间(这个动作开销很低), 不在范畴内间接跳过，在不带 segment_key 查问的条件下, 也能极大的升高所须要过滤的文件数量。
批流交融 背景：业务疾速倒退过程中，继续迭代实时工作成为常态。供应链业务简单，环节多，流程往往长达一个月周期之久，这就导致 state ttl 设置周期长。job 的 operator 变动（sql 批改），checkpoint 无奈主动复原，savepoint 复原机制无奈满足，比方减少 group by 和 join。从新生产历史数据依赖上游 kafka 存储时效，kafka 在公司平台个别默认都是存储 7 天，不能满足一个月数据回刷需要场景。
计划：通过批流交融在 source 端实现离线 + 实时数据进行数据读取、补齐。
（1）离线按 key 去重，每个 key 只保留一条，缩小音讯量下发。（2）离线和实时数据合并，应用 last_value 取雷同主键最新事件工夫戳的一条数据。（3）应用 union all + group by 形式是可作为代替 join 的一个抉择。（4）实时数据取当日数据，离线数据取历史数据，避免数据漂移，实时数据需前置一小时。
Join 算子乱序
- 问题剖析
因为 join 算子是对 join 键做 hash 后走不同的分片解决数据 ，开启了 2 个并发后，再因为 header_id 字段的值变动，detail 表 2 次数据流走到了 2 个不同的 taskmanage, 而不同的线程是无奈保障输入有序性的，所以数据有肯定的概率会乱序输入，导致冀望的后果不正确，景象是数据失落。
- 解决办法
通过 header inner join detail 表后，拿到 detail_id，这样再次通过 detail_id join 就不会呈现（join 键）的值会从 null 变成非 null 的状况产生了，也就不会乱序了。
insert into sinkSelect detail.id,detail.header_id,header.idfrom detailleft join (Select detail.id AS detail_id,detail.header_id,header.id from header inner join detail on detail.header_id = header.id) headerNewon detail.id = headerNew.detail_id2.3.3 Hologres or starrocks
这里也聊聊大家比拟关注的 hologres 和 starrocks,starrocks 从开源开始也和咱们放弃了密切联系, 也做了屡次的深刻交换, 咱们也大抵列了两者之间的一些各自劣势和对于咱们看来一些有余的中央。
3 其余做的一些事件
3.1 开发提效工具——flink 代码生成器
参考 MyBatis gennerator 一些思维，利用模板引擎技术，定制化模板来生成 flink sql。能够解决代码标准，和晋升开发效率。根本能够通过代码配置来生成 flink sql。
3.2 开发提效工具——可视化平台
间接通过配置的形式, 在线写 sql, 间接生成页面和接口, 一键公布, 同时引入缓存, 锁排队机制解决顶峰拜访性能问题。
动静配置接口，一键生成 rpc 服务:
动静配置报表:
4 将来布局
以后架构仍然存在某种程度的不可能三角，咱们须要摸索更多的架构可能性：
（1）利用写在 holo, 计算在 mc 防止 holo 这种内存数据库，在极其查问内存被打爆的问题，利用 mc 的计算能力能够搞定一些事实表 join 的问题晋升一些灵便度。
（2）借助 apache hudi 推动湖仓一体，hudi 做批流存储对立，flink 做批流计算对立，一套代码，提供 5-10 分钟级的准实时架构，缓解局部场景只须要准时升高实时计算成本。