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

基于云原生的作业帮大数据采集体系建设与迁移实践 伍思磊 作业帮大数据中台架构师 一.背景 二.作业帮数据采集体系的架构升级三.作业帮数据采集体系的迁移实践 1.数据库采集：从Canal到Flink-CDC 2.日志采集：从虚拟机到容器化 四.未来规划 一.背景 背景/关于作业帮 作业帮是一家什么样的公司？ 背景/作业帮大数据中台全景 二.作业帮数据采集体系的架构升级 架构升级/大数据采集架构演进的三个阶段 架构升级/采集2.0时代面临的问题 痛点1:新数据源难以扩展 痛点2: 采集组件虚机部署人肉运维 稳定性差 痛点3: 入仓需求定制化：表级/点位级kafka分发、实时流done标记、离线数据漂移、特殊任务调优... 痛点4: MR任务缺乏物理隔离各BU争抢资源 数据时效性差 架构升级/诊断思路与架构升级目标 大数据采集的 企业诉求业务场景需求本质架构目标 工作台 实时/小时级数据 在线系统，需求稳健迭代 面向核心经营活动实时OLAP,小时增量切块 数据系统高可用、准确 ① 支撑经营分析决策 业务分析挖掘T+1数据 深度洞察、查数广泛、需求灵活 业务试错、需求挖掘T+1快照,天/小时增量切块数据源多样性、SQL易编写 ② 管理者驾驶舱T+N数据、大盘趋势 历史数据、可视化、需求固化 经营决策 T+1快照、数据产出稳定历史快照保留、反复分析 ③ 低成本 企业成本管理 数据复用、避免烟囱 ④ 降低资源颗粒度、弹性扩缩 ⑤ 数据安全 审计活动/法律合规 用户个人信息数据脱敏 ⑥ 架构升级/作业帮采集场景的需求本质抽象 架构升级/采集架构3.0升级思路:采集链路视角 架构升级/采集架构3.0升级思路:SAAS化产品视角 三.作业帮数据采集体系的迁移实践 数据库采集：从Canal到Flink-CDC 迁移实践/关于Canal 作业帮在采集2.0阶段的解决方案 Canal+Canal-Admin 增量采集HA+平台化 数据库入仓规模 •实例数(mysql集群):300+ •接入表数量: •含分表:十万级分表合并:万级 •峰值QPS:200,000+均值QPS:50,000+ •日增量binlog大小:10T+ Canal是优秀的解决方案,但仍存在痛点 1.仅支持mysql，无法扩展其他数据源 2.不支持全量CDC,入仓链路割裂 3.基于云下的VM部署: •机器粒度HA,人工运维成本高 •资源利用率低，预算成本居高不下 迁移实践/CDC方案调研选型 CDC机制 日志+查询(部分无锁) 日志+查询 日志+查询(有锁) 日志 数据源支持(仅对比作业帮需求) MySQL MongoDBPostgreSQL(Polardb-O) TiDB MySQLMongoDBPostgreSQL MySQL,MongoDB,PostgreSQL国外产品,部分数据源用不到 MySQL 底层机制 Flink+Debezium Debezium+Kafka Debezium 自研内核 同步方式 增量/全量/增量+全量 增量/全量/增量+全量 增量/全量/增量+全量 增量 部署架构 EMR 基于作业帮Zlink平台部署 SAAS 单机 VM+分布式 产品化 自建 厂商平台 自建 CanalAdmin 定制化 基于Flink自定制 较困难 基于Java自定制 基于Client二开 监控告警 自建 厂商提供 自建 自建 SLA保证 自建 99.999% 自建 自建 SQL支持 支持 支持 否 否 迁移实践/Flink-CDC对各类数据源的特性支持 Flink-CDC版本:2.3.0 增量快照(无锁/并发/续传) 支持 支持 不支持 不支持 启动模式 initital/latest/earliest/gtids/binlogfile+offset/timestamp initital/latest initital/latest initital/latest 多库多表捕获 支持 支持 支持 支持 动态加表 仅支持Initial模式且会阻塞 不支持 不支持 不支持 获取binlog时间戳 支持 支持 支持 支持 获取主键 支持 支持 支持 支持 捕获DDL 支持 支持 支持 支持 数据类型支持 全部支持但个别字段不完善(如enum) 部分不支持 部分不支持 部分不支持 迁移实践/CDC架构设计思路 迁移实践/CDC迁移场景与挑战 技术挑战： 1.如何确保Canal和Flink-CDC的输出在量级和数据上完全相同? 2.如何尽量无缝、不丢数据地将任务平滑切换到CDC? 迁移实践/Canal→CDC迁移方案设计思路 迁移实践/CDC轻量化、整库同步的落地现状与挑战 基于CDC的数据异构 MySQL Table Table Table 1.轻量化 全量同步后自动切换增量 2.动态加表 整库CDC任务 动态新增表并从CK恢复 3.DDL同步 目标数仓 Table Table Table 源表Schema变化自动同步到下游数仓 轻量化的问题： 整库任务从Canal基于gtids迁移到CDC后，无法切换到initial模式 现状: 社区暂未支持 目前作业帮正在自研解决 动态加表的问题： 整库任务只能基于initial模式做动态加表,且加表时会阻塞其他增量表 现状: 社区在master解决,预计2.4发布目前作业帮正在试用验证 DDL同步的问题： 1.需要上游数据源来约束schema变化 2.下游用户接受度不高，更期望能用工单手动控制数仓schema 现状: 在作业帮内部不算刚需 沿用入仓工单维护schema变更 迁移实践/性能摸底:CanalVSCDC增量消费 CanalFlink-CDC 峰值QPS:13000峰值QPS:19000(+32%) •Canal版本:•启动方式： 1.1.3 binlog-ealriest •Flink-CDC版本:•启动方式： 2.3.0 binlog-ealriest •虚拟机规格： 96C/384G •TM内存： 6144MB •工作线程： 64 •并发/Slot： 6 •Kafka分区数： 6 •Kafka分区数： 6 由于Canal在后续版本中做了性能优化，因此该测试只能供参考：仅说明在作业帮场景下,Flink-CDC(2.3.0)性能优于Canal(1.1.3) 迁移实践/作业帮CDC迁移收益总结 成本性能功能 Canal Z-CDC Canal Z-CDC 资源核数消耗减少67% 消费性能增加32% 三.作业帮数据采集体系的迁移实践 日志采集：从虚拟机到容器化 迁移实践/作业帮日志采集规模 接入日志源 日志量级 峰值 CPS 峰值带宽 1000+ 百亿条 每天 百万+ 每秒 数百+ Gbps 迁移实践/基于虚拟机的日志采集：架构概览 迁移实践/基于虚拟机的日志采集：痛点分析 虚拟机架构下的痛点： 1.流量网关使用虚拟机部署，运维成本繁重 2.后端服务陆续容器化上云，现有Flume采集接入体系难以满足done标记需求 3.建设多个外围服务来进行flume管理、done标记管理，维护成本大，稳定性差 技术挑战： Tips:以采集时间为准,当某个区间(如13-14点)的数据都处理完毕后，再让数据向下游可见 流量网关如何上云？ 在k8s下,done标记需求如何支持? 迁移实践/流量网关上云思路 迁移实践/基于k8s日志采集的done标记实现思路 迁移实践/流量网关上云迁移方案 迁移实践/作业帮日志采集迁移收益 成本 虚拟机 容器化 根据流量潮汐按时间段动态扩缩POD 资源核数消耗减少54% 运维 虚拟机 容器化 K8S化,不再专人维护VM集群和Agent公司OP团队提供统一运维 3人力→0.5人力 四.未来规划 未来规划 1 CDC轻量化、整库同步等特性的优雅落地 2 接入能力进一步抽象，低成本接入更多新数据源 3 可观测性进一步增强，入仓全链路感知管控