基于云原生的作业帮大数据采集体系建设与迁移实践

1. 基于云原生的作业帮大数据采集体系建设与迁移实践伍思磊作业帮大数据中台架构师

2.

3. 一.背景二.作业帮数据采集体系的架构升级三.作业帮数据采集体系的迁移实践 1.数据库采集：从 Canal 到 Flink-CDC 2.日志采集：从虚拟机到容器化四.未来规划

4. 一.背景

5. 背景 / 关于作业帮作业帮是一家什么样的公司？

6. 背景 / 作业帮大数据中台全景

7. 二.作业帮数据采集体系的架构升级

8. 架构升级 / 大数据采集架构演进的三个阶段

9. 架构升级 / 采集2.0时代面临的问题痛点1: 新数据源难以扩展痛点2: 采集组件虚机部署人肉运维稳定性差痛点3: 入仓需求定制化：表级/点位级 kafka分发、实时流done标记、离线数据漂移、特殊任务调优... 痛点4: MR任务缺乏物理隔离各BU争抢资源数据时效性差

10. 架构升级 / 诊断思路与架构升级目标企业诉求支撑经营分析决策低成本数据安全大数据采集的业务场景需求本质工作台实时/小时级数据在线系统，需求稳健迭代面向核心经营活动实时OLAP, 小时增量切块数据系统高可用、准确 ① 业务分析挖掘 T+1数据深度洞察、查数广泛、需求灵活业务试错、需求挖掘 T+1快照, 天/小时增量切块数据源多样性、SQL易编写 ② 管理者驾驶舱 T+N数据、大盘趋势历史数据、可视化、需求固化经营决策 T+1快照、数据产出稳定历史快照保留、反复分析 ③ 数据复用、避免烟囱 ④ 降低资源颗粒度、弹性扩缩 ⑤ 用户个人信息数据脱敏 ⑥ 企业成本管理审计活动 / 法律合规架构目标

11. 架构升级 / 作业帮采集场景的需求本质抽象

12. 架构升级 / 采集架构3.0升级思路: 采集链路视角

13. 架构升级 / 采集架构3.0升级思路: SAAS化产品视角

14. 三.作业帮数据采集体系的迁移实践数据库采集：从 Canal 到 Flink-CDC

15. 迁移实践 / 关于Canal 作业帮在采集2.0阶段的解决方案 Canal + Canal-Admin 增量采集 HA+平台化数据库入仓规模 Canal是优秀的解决方案, 但仍存在痛点 • 实例数(mysql集群): 300+ 1. 仅支持mysql，无法扩展其他数据源 • 接入表数量: 2. 不支持全量CDC, 入仓链路割裂 • 含分表: 十万级分表合并: 万级 • 峰值QPS: 200,000+ 均值QPS: 50,000+ • 日增量binlog大小: 10T+ 3. 基于云下的VM部署: • 机器粒度HA, 人工运维成本高 • 资源利用率低，预算成本居高不下

16. 迁移实践 / CDC方案调研选型 CDC机制日志 + 查询(部分无锁) 日志 + 查询日志 + 查询(有锁) 日志 MySQL MongoDB PostgreSQL (Polardb-O) TiDB MySQL MongoDB PostgreSQL MySQL, MongoDB, PostgreSQL 国外产品, 部分数据源用不到 MySQL 底层机制 Flink + Debezium Debezium + Kafka Debezium 自研内核同步方式增量/全量/增量+全量增量/全量/增量+全量增量/全量/增量+全量增量 EMR SAAS 单机 VM+分布式产品化自建厂商平台自建 Canal Admin 定制化基于Flink自定制较困难基于Java自定制基于Client二开监控告警自建厂商提供自建自建 SLA保证自建 99.999% 自建自建 SQL支持支持支持否否数据源支持 (仅对比作业帮需求) 部署架构基于作业帮Zlink平台部署

17. 迁移实践 / Flink-CDC对各类数据源的特性支持 Flink-CDC版本: 2.3.0 增量快照支持支持不支持不支持启动模式 initital / latest / earliest / gtids/ binlog file+offset / timestamp initital / latest initital / latest initital / latest 多库多表捕获支持支持支持支持动态加表仅支持Initial模式且会阻塞不支持不支持不支持获取binlog时间戳支持支持支持支持获取主键支持支持支持支持捕获DDL 支持支持支持支持数据类型支持全部支持但个别字段不完善(如enum) 部分不支持部分不支持部分不支持 (无锁/并发/续传)

18. 迁移实践 / CDC架构设计思路

19. 迁移实践 / CDC迁移场景与挑战技术挑战： 1.如何确保Canal和Flink-CDC的输出在量级和数据上完全相同? 2.如何尽量无缝、不丢数据地将任务平滑切换到CDC?

20. 迁移实践 / Canal→CDC 迁移方案设计思路

21. 迁移实践 / CDC轻量化、整库同步的落地现状与挑战基于CDC的数据异构 MySQL Table Table Table 目标数仓 1.轻量化 2.动态加表 3.DDL同步全量同步后自动切换增量整库CDC任务动态新增表并从CK恢复源表Schema变化自动同步到下游数仓轻量化的问题：动态加表的问题：整库任务从Canal基于gtids迁移到 CDC后，无法切换到initial模式整库任务只能基于initial模式做动态加表, 且加表时会阻塞其他增量表现状: 现状: 社区暂未支持目前作业帮正在自研解决社区在master解决, 预计2.4发布目前作业帮正在试用验证 Table Table Table DDL同步的问题： 1. 需要上游数据源来约束schema变化 2. 下游用户接受度不高，更期望能用工单手动控制数仓schema 现状: 在作业帮内部不算刚需沿用入仓工单维护schema变更

22. 迁移实践 / 性能摸底: Canal VS CDC 增量消费 • • • • • Canal Flink-CDC 峰值QPS: 13000 峰值QPS: 19000 (+32%) Canal版本: 1.1.3 启动方式： binlog-ealriest 虚拟机规格： 96C / 384G 工作线程： 64 Kafka分区数： 6 • • • • • Flink-CDC版本: 启动方式： TM内存：并发/Slot： Kafka分区数： 2.3.0 binlog-ealriest 6144 MB 6 6 由于Canal在后续版本中做了性能优化，因此该测试只能供参考：仅说明在作业帮场景下, Flink-CDC(2.3.0)性能优于Canal(1.1.3)

23. 迁移实践 / 作业帮CDC迁移收益总结成本 Canal Z-CDC 资源核数消耗减少67% 性能 Canal Z-CDC 消费性能增加32% 功能

24. 三.作业帮数据采集体系的迁移实践日志采集：从虚拟机到容器化

25. 迁移实践 / 作业帮日志采集规模接入日志源日志量级峰值峰值 CPS 带宽 1000+ 百亿条百万+ 数百+ 每天每秒 Gbps

26. 迁移实践 / 基于虚拟机的日志采集：架构概览

27. 迁移实践 / 基于虚拟机的日志采集：痛点分析虚拟机架构下的痛点： 1.流量网关使用虚拟机部署，运维成本繁重 2.后端服务陆续容器化上云，现有Flume采集接入体系难以满足done标记需求 3.建设多个外围服务来进行flume管理、done标记管理，维护成本大，稳定性差技术挑战：流量网关如何上云？ Tips: 以采集时间为准, 当某个区间(如13-14点) 的数据都处理完毕后，再让数据向下游可见在k8s下, done标记需求如何支持?

28. 迁移实践 / 流量网关上云思路

29. 迁移实践 / 基于k8s日志采集的done标记实现思路

30. 迁移实践 / 流量网关上云迁移方案

31. 迁移实践 / 作业帮日志采集迁移收益运维成本虚拟机容器化根据流量潮汐按时间段动态扩缩POD 资源核数消耗减少54% 虚拟机容器化 K8S化, 不再专人维护VM集群和Agent 公司OP团队提供统一运维 3人力→0.5人力

32. 四.未来规划

33. 未来规划 1 CDC轻量化、整库同步等特性的优雅落地 2 接入能力进一步抽象，低成本接入更多新数据源 3 可观测性进一步增强，入仓全链路感知管控

34.