分享嘉宾：童光辉 腾讯
编辑整理：罗鹏 ecarx
出品平台：DataFunTalk

导读： PCG（平台与内容事业群）包含长短视频、信息流、社交通信、工具等多种ToC的互联网应用，因为从不同BG整合而来，在基础平台、数据标准都有所区别，要完成大数据技术体系的升级无异于对高速行驶的汽车换引擎且还要一边行驶一边修路。本文主要围绕实时数仓流批一体处理这个大数据领域来说明其整体架构的设计和相关的维护保障。

01 腾讯PCG的前世今生

1. 问题和挑战

腾讯PCG事业群由于是由多个其他事业群合并而来，之前的各个BG采用不同的架构，导致业务在使用上会有数据不通、口径不同、质量不一致、易用性差等问题，这里的整合无异于多家公司的IT系统合并。

我们当时做的第一件事情就是梳理出各BG的大数据场景与相关系统，通过专家们多轮讨论，一起落地了大数据顶层架构的设计，公司多个大数据团队通过开源协同共建的方式负责自己的擅长与感兴趣的部分，但在元数据管理、权限等基础的部分需要统一的建设保证授信源唯一操作幂等。上图示为大数据顶层架构设计。

痛点在于 ，从数据的采集分发、数据存储、数据计算、计算引擎、工具平台，到数据应用有非常多的组件，这些组件又是来自于不同的团队去支持，然后业务再基于这些组件去构建上层的应用平台，这就导致有非常多的界面，很难有超级英雄既能掌握全局又能掌握细节，在质量的管理与保障上是超过个人的认知上限的，如果缺乏体系化的设计不仅日常被淹没在各类问题的事务中，在出现重大故障时也很难协调，由于篇幅所限一篇文章难以把大数据整体的架构与保障讲清楚，本次分享主要还是围绕实时数仓流批一体处理这个大数据领域来说明其整体架构的设计和相关的维护保障。

在讲实时数仓流批一体处理前，需要先给大家讲下前置依赖的2个关键系统——MQ（CDMQ）和日志管道（ATTA）。

02 MQ架构的内核生态改造

1. 面临的问题

传统的Kafka集群面临着一些问题，一个是它有承载的上限，第二个在几十上百个实例的情况下，必然会有相应的故障。而MQ故障之后，上层会有明显的感知，比如传输和实时计算，都会受影响。

2. 解决方案

怎样保障Kafka在MQ这个环节，能有更好的一个质量和架构的可用性？

① 无感迁移容错

在Kafka层面，可以把controller管理节点抽象出来，让Kafka可以做到多个集群放到一个group内，然后每一个Kafka的集群又可以承载不同的topic。这样一来，当一个集群出现故障之后，就可以很方便的向其他正常集群做迁移。迁移之后，流量也能进一步的切换。对于上层来说，没有太大的感知，切换的动作的损耗大概只需要一个10到15秒的样子。

② 支持弹性扩缩容

这种基于broker节点部署，灵活延伸的架构，可以根据运行过程中的流量的情况，对机器资源做弹性扩缩容。

③ Topic数突破

一般Kafka的topic存在千级左右的上限。原因是Kafka在管理的时候，需要ZK开销资源以及内存开销资源。通过对kafka改造支持多Region，通过扩容Region就可以和Pulsar一样支持到百万或更多TP数，同时比Pulsar又多了Kafka对本地Disk的数据进行快速读取写入能力。

03 日志管道系统（ATTA）

一般来说，业务的在线服务会部署在2个以上地域，比如上海、深圳、天津等地域，主要是跨地域容灾以及就快接入考虑，给腾讯的用户提供更稳定、更快的服务。

为了让日志数据稳定生产且出现异常时不要影响在线服务的稳定性，日志管道系统ATTA提供多种接入的方式，其中最重要的一种就是提供各语言的日志SDK，通过与RPC框架合作把ATTA SDK作为默认插件，业务在使用的时候简单的导入就可以使用，支持同步、异步、TCP、UDP等的选择，使用方可以根据对性能/数据可靠性的权衡灵活设置。

数据接收之后，会以最快的速度存入本地Data store，当消费的时候，会跨地域对多个地区的数据读取出，然后把数据分发到MQ、日志的查询、离线数仓等场景进行后续的处理，这样既满足了业务的快速的数据写入，同时对服务端来说，整个的处理耗时也比较短。

04 实时数仓流批一体架构

业务为了更快的看到数据，实时计算在快速增加，DE团队需要同时维护离线与实时2套数仓架构，不仅运营成本更高，维护也建设成本也很高，所以我们团队又基于已有的日志管道、MQ、HADOOP等能力加上Flink构建了流批一体的数据加工平台，实现一套代码支持实时与离线2种方式的加工，业务可以根据自己的需要在流/批上进行转换，当实时计算出现数据异常或者业务统计口径调整时也可以通过批的方式重放数据。加工好的数据会根据业务需要放入到我们的实时/离线数仓中，业务就可以灵活方便的进行数据探索、数据应用、报表配置等。

便随着业务需求与架构的演进， 大数据运维也发生了相应的变化 ，主要为：

• 复杂性越来越高，整个流程中有非常多的模块，非常多的系统。
• 对时效的要求越来越快，传统的比如做离线，是基于天/小时出结果。而到实时计算领域，整个链条（app产生数据到产品看到数据）要求在30秒内。这个要求基本上不太可能依赖人工去处理故障，因为从收到报警、打开电脑到登录系统至少也得几分钟的时间，所以对于整个运维保障压力非常大。

那如何能够保障数据中台快速落地，同时能够做到质量与建设速度的均衡？

05 定义系统可运维性目标

1. 定义中台内各平台的可运维性

在项目团队内定义系统可运维性的目标或它的可运维性的阶段。

我们定义了五个level，对不同level也有明确的要求。 比如如果要把系统发布上线，需要做什么样的一些事情，接入量&保障能力需要有一个科学的权衡，否则是无法应对保障的压力的，1、2级基本上是开发与内测阶段可以做有针对性的业务试点接入，到了3级就可以放开业务自由接入，4、5级就属于比较程成熟的阶段，具备非常有竞争力的平台、质量、效率、安全的综合优势。这基本上和产品的生命周期较为吻合，通过明确的定义可以让平台的建设在多个维度上更为科学的权衡。

2. 定义错误预算

在质量保障方面另外一个比较重要的是定义清楚支撑边界和能力，通过错误预算来做质量和其它维度的tradeoff。 其实就是可用到完美可靠性之间的差值，系统当前阶段质量问题最大的可容忍度。要求三个九的服务和要求四个九服务容错性是不一样的，根据容错性的不同对系统的架构、系统的支撑能力、自动化水平，都会提出不同等级的要求，对建设方来说就可以根据错误预算来开展变更、质量保障动作，错误预算消耗过大时可以对质量管控更为严格甚至进入code yellow状态停止非bug fix的发布，团队人力重点转入质量问题解决。

有了错误预算时，其实服务的SLA、SLO、SLI就已经明确了，使用平台能力的业务在选型的时候除了是否满足需求外也可以进行质量维度的评估，以免在使用过程中出现平台质量达标而业务遭受重大的质量失败。平台（建设）团队每半年和业务（使用）团队签订一次SLA协议以约束双方的责、权，在签订时也会review上周期的情况，一般是持平或者调高SLA承诺。

06 全生命周期管理

质量保障和治病是一个道理，发病后在去治疗需要付出更大的代价，有一定症状就去治疗的代价更小，最好的状态是注意保护身体提高抵抗力不生病或少生病。

回到质量保障上就是问题应该要尽早的暴露、尽早的管控、尽早的解决而不是等到事后再去处理。所以要在整个软件开发生命周期里面去做，SRE团队会和研发团队一起设计方案评审方案并参与代码实现、code review，建设并优化CI到CO周期的流程工具，实现风险有的有效控制，在问题出现时有事前的SOP预案并通过演习保证团队应对预案的熟练程度。

1. 方案的阶段

方案设计阶段应该由专门团队介入到方案的设计和制定。提前考虑到比如监控、OPSAPI和常见故障的处理方式等。

2. 开发阶段

开发阶段要做相应的代码质量管控，比如对代码验收增加单测质量红线。

3. 发布阶段

发布阶段，可以复制脱敏真实流量来构建相应镜像的预发布环境，同时在这个环境里构建混沌工程，通过故障注入做准入准出的一些要求以及流量压测等。然后在生产环境中要先灰度发布确定没有问题再进行全量发布。

在上线的阶段，整个风险的识别和管理，应该秉持着早发现，早管控早处理的理念。对系统里的一些风险，以及对于风险的主要应对措施，都应该在架构上线之前，跟所有的开发者甚至是开发的leader或者项目团队做相应的明确SOP预案。

4. 持续运营保障阶段

在持续运营保障阶段， 持续评估整体的自动化工具能力，然后结合SRE保障要求将故障处理放入统一的标准化体系中执行，通过MTTR（recovery）、MTBF等指标牵引团队的质量保障，在标准有序处理下实现故障更快的解决并控制不同等级故障的发生频次，以免过于频繁的故障让大家疲于奔命或者太久不发生故障导致对SOP流程的生疏甚至自满。

07 全面监控

在大数据运维尤其是实时计算运维，面临着一个比较难的问题CAP定理在经典计算机下是无法被打破的，大数据领域为了更廉价的传输数据一般会采取大量异步，可能在部分环节能实现Exactly-once，但端（数据上报）到端（ODS Application Data Service）要实现Exactly once机器成本过于高昂，对于每天传输数十万亿的场景基本上不可以接受的，所以在链路上数据是可能发生丢失或者重复的，当数据质量发生问题时如何能快速发现问题并快速定位问题就非常关键了。

除了架构本身的数据质量保障例如重试、去重外，在数据质量监控上采用数据审计、数据染色来解决主要问题，在数据上报时每份数据有一个全局唯一的id，数据在流转过程中我们会对数据的接收条数、处理条数、发送/分发条数进行上报，审计数据在入实时数仓前通过Exactly once来保障数据准确，在数据写到实时数仓后我们对数据端到端以及每个环节就具备了分钟级的审计能力，这种方式可以解决数据分发的场景的对账。在数据分发中有也会有较为复杂的ETL情况，比如数据过滤、一拆多、多合一、多流join等场景，这种情况用对账就只能看出一个大体的趋势变化无法准确的判断问题，我们通过无侵入的染色实现了部分中台场景的数据质量端到端以及过程判断，对每条物理链路我们还会创建1~2条拨测的链路已保障物理链路的可用性，对实时计算、数据传输数据质量监控的补齐，即使是面对海量、复杂的数据传输计算领域我们依然能够全面快速的发现问题、诊断问题。

08 数字化运维能力建设

我们打磨了一整套的事前、事中、事后的质量保障能力，通过对运维数据的积累和平台能力的打磨具备较好的自助/自动运维能力 。

作为大数据团队中的SRE团队对AIOPS的解读是全面的数字化能力加上特定场景下的自动处理能力以及全面的故障诊断能力，在系统设计阶段和研发团队一起定义了各系统/模块的统一接口、可观测指标、监控告警、OPSAPI，通过把metric数据、日志数据实时上报处理后写入到数仓中，这里的数据一方面提供给BI系统配置运营看板给人进行决策，比如成本分析、质量趋势分析、系统/模块性能追踪等，另一方面也会进行故障预警结合报警事件或者用户咨询做故障诊断，对诊断出的问题部分进行自动化的处理，无法处理给oncall进行处理建议。

这套系统本身也是有做数字化的运营的，我们会持续挖掘根因提高问题预测、故障诊断速度、诊断效果以及自动化处理场景覆盖。

09 故障处理由繁入简

基于标准化的CI、CD、CO构建，明确的运营标准，充足准确的运维数据这些基石中的基石，故障的处理就可以变得清晰明了。发现故障之后，做相应的根因识别，然后到根因库做故障定位，然后基于构建任务的编排做自动处理，最后还是搞不定的事情，再开始进入对相应的一线二线的开发负责人的on call。并且，对于不同的错误预算消耗，会定义到不同的故障等级。对于重大故障，会直接发起对应的预案，做相应的故障修复。这就会形成一个比较立体的质量支撑保障。最后就能形成一个比较好的正循环的机制。

我们还会评估oncall的工作时间、非工作时间的负载情况，一定的平衡大家的压力，取了一段时间数据可以看到我们的自动定位、自动处理率还是较高的，部分系统达到了平台优化级（L4）的能力，数十万亿级的日志传输、实时计算系统每周电话oncall差不多在0~5次，全部的工单小于15次。

10 提供全栈、易使用、高质量的数据服务

最后，我简单也给大家介绍下PCG数据中台部分AIOPS、DataOps的技术规划。

在IaaS方面 ，我们会继续并加大对公司级开源协同的投入更好满足PCG内数据中台对基础组件的能力需求，在PaaS层面我们会把数据开发的全生命周期逐步进行覆盖并加强各阶段的能力，这样SaaS层面的数据应用组件能够更为简单基于合规、安全的使用高质量数据。

在运维领域 ，SRE团队会把数字化、智能运维能力赋予到数据中台的产品中，服务于数据中台的使用者们。服务的用户数量就是成千甚至上万的级别，将其作为数据中台核心服务核心竞争力之一，提高用户使用数据效率并降低使用数据的成本。

11 Q&A

Q1：监控用的是自研的系统还是开源的？

A1：PCG是自研的的监控系统，Prometheus的性能无法满足需求。大数据所有的metric的可关键性指标是我们来定义，但整个监控的生态还是用监控的整个系统，基于这个生态里面，去把这个数据重新还要做数仓的清洗处理入仓，再做一些相应的一些处理。

如果只是一个监控，其实是不够的，必须是监控和监控数据以及日志数据合并起来，就形成由监控触发问题，然后触发问题之后，去定位问题的原因，然后找到原因之后，去调取相应的处理的自动化流程，然后把问题进行修复，形成这么一个闭环的能力。

Q2：关于多节点共享算法模型的问题，像如果是异常检测算法代码和模型如果是部署在多个节点里面，为了保证这种检测效率的实时性，那模型会存在内存里面，当那个模型发生更新的时候，如何同步更新所有节点上的模型，或者说模型如何共享？

A2：这问题在推荐中台那边是一个比较关键的基础的模型发布问题，在推荐中台里面，模型发布分两种，第一种是离线模型，第二种是实时模型。

离线模型统一是在云上机器挂有云盘，我们采用了P2P的一些技术解决中心化推送的带宽和时效性瓶颈问题，把模型按需推到云盘里面，然后再加载。

实时处理模型一般是放到分布式内存相关系统，比如说Redis这样的系统里，离线与实时配合，形成比较好的一个模型更新能力，保障模型的发布速度。

但是即使这样也做不到在一个模型上线的时候，一定在五秒十秒内模型全部发布到线上成千上万个节点。推荐场景这也不是不可忍受的关键问题，有新模型并不一定要求说不能用老模型，只是老模型的效果差一点，那只要保证分钟级把所有模型给收敛掉就可以了。

Q3：ATTA是自研的，还是开源的，支持几种语言的客户端?

A3：ATTA是自研的。sdk有很多，常见的c++、 java、 go、python这些都有，腾讯现在有一个技术体系叫开源协同，所有的团队/个人都可以参与任何oteam，贡献者能够享受在ot里面给予的一些激励的机制，取得好的效果会有奖金、晋升等优势。参与者们还是比较享受这么一个过程，即使你不在这个团队，你也能为这个团队去做贡献，并且能够享受到收益。

分享嘉宾