vivo数据集成稳定性与数据质量保障及可观测实践_易龙

vivo数据集成稳定性与 数据质量保障及可观测实践 vivo互联网大数据架构师/易龙 目录 •vivo数据集成平台架构及功能 •vivo数据集成稳定性保障实践 •vivo数据集成链路数据质量保障实践 •vivo数据集成可观测实践 vivo数据集成平台架构及功能 数据量大小 PB级/日 数据完整性 99.999999% 可用性 99.99% 数据时效性 500ms 产品平台层 产品能力层 构建实时离线一体化数据仓库推荐、风控、分析等实时业务实时客户分析及精准推荐实时营销活构建客群标签画像 业务日志离线、实时接入业务多维数据分析数据接入离线异构数据源同步实时异构数据源同步 Bees，是vivo的一站式数据集成平台，它支持将多场景下多样化、分散的数据源，统一汇聚到大数据存 多场景解决方案支撑 数据传输集成 多种同步方式 批量（离线）全量/增量，实时同步，全增量一体 多种同异构数据源数据同步 源：Kafka/Mysql/MongoDB/Pulsar/… 目的:Kafka/Pulsar/Hive/CK/Hudi/HBase/… 数据接入 DB接入 Agent日志接入 SDK接入 运维维度 SLA管理 监控可观测 一键诊断 数据质量 集群管理 任务治理 用户维度 SLA管理 监控告警管理 任务管理 工单管理 业务 …… 业务4 业务2 业务1 业务3 数据量条数 万亿级/日 业务层 储，是数据流入大数据体系的一座桥梁。 Bees监控模块 监控、指标展示与告警 Bees-Manager 工单接入管理 任务管理 采集配置管理中心 用户平台服务【极重要】 Bees-SDK 数据接入SDK工具包 Bees-Agent 源端日志接入组件 部署在业务机器 影响CPU、内存、文件句柄、IO Bees-Bus 数据传输管道服务【极重要】 Bees-X：实时数据同步服务 支持binlog日志采集 mongdboplog实时采集 支持其他异构数据源数据同步 实时日志接入离线日志接入 Nginx/Tomcat/埋点日志支持容器服务日志 传输到Kafka（500ms内）支持过滤 支持同时写多Kafka业务隔离 Nginx/Tomcat/埋点日志支持容器服务日志 按小时粒度批传输 按10分钟粒度批传输支持限速 DB全增量日志实时接入SDK数据接入 支持接入到Kafka、Pulsar支持接入到Hive、CK等对主库无性能影响 保障秒级别时延 支持指定点位进行数据续传 bees-x 业务数据无需落地日志更低的时延（毫秒级）支持Avro、Thrift协议支持Java、C++语言 链路稳定性 链路数据质量 链路可观测性 核心问题维度 被动接收告警，问题定位恢复慢 散点式救火，运维成本高 数据产出时效性波动大 告警多而杂，处理成本高 如何从根本上长效的保障稳定性 如何从全路视角保障数据时效性 如何有效准确的告警并快速恢复 数据上报 网络/服务端 接入传输 ETL （Spark/Flink） 数仓 痛点问题 核心挑战 vivo数据集成稳定性保障实践 MTBF:（MeanTimeBetweenFailures)，平均故障间隔时间MTTF：(MeanTimeToFailure)，平均无故障时间MTTR：(MeanTimeToRepair)，平均修复时间 bees-monitor bees-sdk bees-bus bees-agent 核心服务多活高可用 服务拆分多节点部署 跨机房容灾 存储多活高可用 跨机房容灾 Proxy，无中心集群，支持高可用 Agent，基于Raft选主，支持高可用 节点均支持动态扩缩容 Proxy配置基于Zookeeper进行同步，保障一致性 MySQL IDC1 proxy0 bees-manager masterslave0 ag z nginx proxy1 bees-manager bees-manager slave1 agz 同服务 同数据agent zookeeper LVS+Keepalived IDC2 proxy2 bees-manager slave2ag z nginx bees-manager bees-manager proxy3 Slave3 agz 核心管控服务集群 portal API服务集群Portal服务集群 采集配置流 域名可用性检查 管控服务 采集数据流 bees-agent 心跳上报 心跳上报 bees-bus 消息队列 其他 bees-sdk 心跳上报 链路核心组件心跳上报 异常及时发现，追数补数 bees-manager 业务A任务a标签业务B任务b标签业务C任务c标签 源端采集 bees-bus Kafka集群 bees-sdk 业务A任务a bees-agent *.log 业务B任务b bees-agent …… bus节点n *.log 业务C任务c bees-agent bus节点0 bus节点1 *.log bus节点0 bus节点1 bus节点0 标签统一通过bees-manger管理 不同业务任务分配不同标签 按标签和bees-bus建立连接 bees-bus使用大内存物理机器 同一台bus机器负责一个业务 bees-bus备机池，及时扩容 2.1 1.2 SDK接入任务配置Agent接入任务配置 业务-sdk1业务*-log 业务-sdk2sdk2-log 扩容、sdk落盘任务创建 2.2 1.1 相同标签 平台化配置管控 配置动态感知 支持落多目录多文件 2.3 机器 b 3.13.2 3.3 落盘开关开启配置流 采集管控服务机器扩容落盘开关关闭数据流任务创建 CMDB 业务 业务服务ees-bus机器Kafka bees-busbees-bus agent *.l bees-sdk 4 bees- og 5 9 6 8 7 bees-manager 数据接入 bees-bus taskmanager Kafka集群 bees-sdk channel bees-agent source sink *.log FqueueSink Pulsar集群 Fqueue FqueuePollMnager selector 上下游联动，及时感知异常 全链路流量波动监控 及时数据反压告警 引入Fqueue落盘 支持顺序写落盘 支持落单盘和多盘 独立FqueueSink隔离发送 离线HDFS集群容灾能力 上下游联动 分钟级切换耗时 核心SLA业务 容灾触发切换 分钟级切换耗时 专项优化根治隐患 路 思 定期故障预案演练 事件故障记录分析 主动巡检识别隐患 历史故障 主动隐患识别 重大迭代 制定故障处理预案 故确定演练对象 障 演制定恢复预案确定验收指标评估影响范围 练 步 骤触发恢复预案 平台 实施故障演练 生成待办项 记录过程事件 事前 有预案 有测试有审核有通告 低峰期变更 事后 事中 点检checklist 要值守有通告 要验收 平台操作 要灰度要观察 有事要通告 明确版本功能 明确灰度指标 稳定性验证 （种子用户） 低频用户推广 核心用户推广 高频用户推广 全网用户推广 确定灰度管控策略 风险应对措施 回滚方案 协作流程 梯度灰度关键步骤 变更发布原则 变更类型梳理 常规配置 大版本升级 常规DB变更紧急 变更步骤梳理 通知范围 基础准备 监控告警 值班规范 点检checklist vivo数据集成 链路数据质量保障实践 支持双链路数据对账、链路关键卡点校验、发现异常并追数补数，保障SLA业务数据完整性要求 支持核心SLA业务离线实时双接入 支持多种数据对账方式 离线全链路对账 实时全链路对账 核心业务双链路对账 SLA动态保障 全链路数据完整性卡点校验 备份重接、追数补数 从全链路视角，结合SLA，制定整体措施，保障数据及时产出 优先级：P0>P1>P2SLA时间：T0<T1<T2 报 核 数据上报 网络/服务端 接入传输 ETL 数仓 措施 资源预测 北极星指标 血缘依赖 根因分析 动态调度 异常监控 容灾切换 延时告警 任务重跑 断点续传 Inotify感知 轮询发现 重采、补采 延迟告警 断点续传 动态扩容 流量监控 波动告警 CDN可用性 Nginx监控 网络设备监控 实时上报 退避重发 断点续传 SLA申 SLA签 订 SLA审 SLA数 据 分类分级 P0 P1P2 核心 高优 T0 T1T2 核心保障 普通 计算资源队列匹配 指标基线 全链路打标 全链路协作 专项保障 SLA保障 Agent采用定时轮巡+inotify组合，时效性达毫秒级 引入inotify时，若直接用jdk的watchservice会有两个问题： 问题1：日志量TPS很高时，inotify通知频率 快，每次agent处理事件，感知的增量日志少，batchSize低，浪费cpu； 问题2：JDK提供的WatchService只支持监听目录，不支持监听到具体的文本文件，直接用会 �现多任务重复监听单目录，重复越多，cpu浪费越多； 解决方案： 问题1方案：读到日志文件末尾，等待5ms， 当batchSize满或超过5ms时进行发送；使用 该方案，CPU使用率从单核10~20%下降至单核3~6%，下降幅度10%左右； 问题2方案：在WatchService基础上，封装一 层支持监听到文件级别的 BeesWatchService，实现文件级别监听，每个任务只订阅自己需要的文件，屏蔽了不相干文件的变更事件； 毫秒级内容变化事件的感知 毫秒级扩容 秒级日志接入 用户 任务配置 任务配置信息 任务打分 触发 资源匹配 资源信息 资源配置分配 任务资源配置下发 任务调度 任务综合打分信息 任务资源信息 任务延迟信息 监控模块 任务延迟 DB 任务运行信息 结果信息 任务状态信息 正常任务 延迟任务 0层 业务场景 1层 13 2层 4 5 3层 3 4 4层 P0 P0 P1 P1 P0 P1 P1 P1 P0 P1 P1 分析任务视图依赖，识别关键基础任务，触发资源分配调度，及时疏通链路 id task（任务） task_dependence_score(任务依赖数得分) scene_importance_score(场景重要性) total_score（综合得分） resource(资源) 0 Task1 13 (2*PO+P1)+ (PO+3*P1)=3*P0+4*P1 A a 1 Task5 4 2*PO+P1 B b 2 Task6 5 PO+3*P1 C c 3 Task11 3 2*PO+P1 D d 4 Task12 4 PO+3*P1 E e vivo数据集成可观测实践 ”监控是可观测的一种实现手段，但可观测远不止于监控。“ 监控 可观测 通过收集、分析和使用信息来观察一段时间内的运行进度，并且进行相应的决策管理的过程，监控侧重于观察特定指标。 通过分析系统生成的数据理解推演出系统内部的状态。 通过将指标、日志、追踪三大支柱信息，按场景进行关联、转化、组合，实现可观测能力 统一可观测平台 一元场景 指 标 可聚合 请求 范围内可聚合的事件 追 踪 请求范围 请求 范围内 的事件 日 志 事件记录 指标 日志 可聚合的 逻辑计量单元 转化场景 对离散的不连续的事件的一种记录 单次请求范围内的所有信息、即调用链信息 日志 指标 日志 追踪 请求范围内 的指标 可聚合/分解 的事件 通过日志获得指标数据通过对日志的聚合和转化得到追踪 追踪 指标 日志 指