腾讯大数据平台自治能力探索

标题图来源：pexels

自治理念

一、趋势

在科幻电影中未来的太空飞船上往往有着人工智能角色，协助人类掌控飞船各方面的状况，或是为飞船上的每个乘客提供贴心的服务。这样的科幻场景离我们现实也不算太远，汽车的自动驾驶能力实际上就是这样一种智能化探索方向。而在我们所关心的大数据平台中，其实也急迫需要这样一个类似大脑的角色，以腾讯大数据平台现阶段的情况为例，我们有着10万+机器的存算集群，上面每天运行千万级别的离在线任务，我们的用户、大数据组件研发者、运维专家们可能会消耗不少精力去处理一些非业务逻辑相关的问题。

但如果大数据平台本身能有一个智能大脑，就能帮助数据科学家们做任务运行问题的诊断，帮平台的运营运维专家们保障存算集群的稳定运行，甚至帮助大数据平台各类服务组件的研发者们，找出组件能力优化的方向。这样的数据平台实质上是一个自动驾驶、自我保护和自我修复的自治型大数据平台。自治这种概念实际上已经被业界很多头部公司所认可，这也是我们腾讯下一代大数据平台目前在探索的方向之一。今天的文章会聊一聊腾讯大数据平台在自治能力建设上的一些实践经验。

二、演进线路

腾讯大数据团队把前面构想的这种大数据平台自治能力的载体称之为平台大脑，大脑的演进路线设想是这样的：第一阶段：它发展出感知能力，能感受到自身的运行状况；第二阶段：它开始从感知到信息中学习、或者从外部的经验中学习，发展出判断能力，能辅助数据平台的使用者或者维护者开展日常工作，这时数据平台可以认为是半自治的；第三阶段：它依据判断，调动数据平台进行自我修复和优化，第四阶段，理想中的自治状态，这要求前几个阶段的能力全面主动干预到大数据平台各个组件的运行状况中。具体而言，在平台大脑建设过程中：

第一，为了感知大数据平台的运行状况，首先建立一个标准化的可观测性基础设施，承载对大数据平台上的物理机、进程、服务、任务等各种信息的实时观测、记录、存储、分析与展示能力，这些信息在形态上沉淀为指标库、拓扑图等。

第二，在这些基础设施上，平台大脑整合整个生态中大数据组件开发者、运维专家的经验能力，结合规则引擎、时序数据异常检测的机器学习算法、业务异常归因算法等，发展出用于异常发现、问题诊断、成本调优的平台级能力，体现为数据大盘、异常告警、巡检机器人、离线报表及诊断建议等形式。并在这个过程中反哺到原本的观测基础设施中，不断完善观测到的指标集和分析能力。

第三，这是平台大脑目前正在探索的阶段，即利用上述的决策信息，来做辅助人工或联动大数据平台的各个组件实现自恢复自优化的能力。例如：实时调度、自动扩容、集群恢复等能力。

可以感受到，整个过程是”数据+专家经验+算法“衍生出自治能力的过程。有意思的是，这样的一种演进过程，也同样可以类比自动驾驶的分级发展过程。

技术架构

从架构的角度来说，平台大脑的探索的三个阶段恰巧与SPI架构模型的三个组成部分有一定的对应关系，大体上是自底向上逐层搭建。这是目前平台大脑的整体架构图。

一、基础服务层

最先搭建的基础架构层，提供的是自治体系的基石--数据的统一数据采集能力，下图为腾讯大数据平台本身的组件体系，基于它的复杂性和现网业务的敏感性，对于平台大脑基础架构层的采集agent，基础服务层需要满足：秒级观测、隔离性（各个不同采集逻辑的隔离性）、可扩展、低功耗等要求。

这里面遇到的主要难点在于：

10万+集群本地部署、并发百万级采集进程对象的采集场景，采集端可能遇到的失败状况复杂多样，且在数据汇聚上报时对mq会产生上报通信压力；
直接在大数据现网部署，必须将对现网业务的影响降到最低；
保障数据采集的准确性和及时性；
适配各类的大数据平台采集对象做到开箱即用，灵活配置。

为此，采集agent上做了如下设计：

插件化各类agent，在主进程的管理下，各类插件间进程隔离，自动识别环境中的进程特征按需加载采集插件；
通过聚合发送、配合mq增加数据汇聚前置代理等手段，降低数据报送的并发连接和对mq的压力；
设计统一且符合工业标准的采集格式，利用配置化管理能力，实现动态更新采集范围（减少频繁上线变更的影响）；
对多样化的采集数据源支持，包括物理机系统日志、指定路径数据源、shell脚本结果、暴露jmx数据的web服务端口等，支持快速扩展开发；同时已经支持物理机指标、python/java进程、常见的大数据场景组件自定义指标等；
满足低功耗需求，在实际测试中15s采集场景，当上报数据异常时，CPU瞬间用量高峰最高值为5%，平均值为0.01%（注：CPU占比为单核占比，即如果200%则占用多核系统的2个核执行时间。）；内存用量约几十M，当上报数据异常时，内存用量无变化。

二、平台服务层

平台服务层包括：数据可视化平台、实时分析平台、离线巡检平台、算法决策平台及公共服务平台，这些能力很显然是依赖生长在腾讯大数据自身基础组件上的，其中：

1.数据可视化平台

提供时序类指标、组件业务流水以及拓扑图表的自助配置、秒级查询的可视化能力。这里面依赖了腾讯的OLAP数据库Hermes、图数据库，以及开源的时序数据库druid，形成融合查询能力，展示上使用的是grafana来做快速上线，未来预计还会引入时序内存数据库等缓存手段，来做查询加速，并基于grafana二次开发来实现数据大盘与异常告警、诊断建议等能力的实时联动。

2.实时分析平台（基于腾讯Oceanus、Hermes及太极）

数据的预处理（实现数据过滤、按维度,周期聚合等）；规则引擎（支持支持判定、自定义复杂表达式、简单的波形判定、以及对OLAP、模型服务的实时调用）；异常收敛（实现防抖动、聚合异常、消除告警风暴）；以及告警推送等能力；这个实时分析平台的核心模块实现如下：

3.离线巡检平台（基于腾讯统一调度及TDW数仓）

通过离线分析任务、各个组件内化的检测脚本来实现：定期巡检（物理机巡检，关注内核错误、硬件报错、oomkiller动作等做巡检；各类组件业务巡检，如hdfs巡检、hbase巡检等）；趋势预测（进行业务集群容量性能趋势预测、机器硬件寿命预测）；评估推荐（高风险任务报告、异常告警报告、资源及参数推荐报告）等，简化后的离线巡检报表系统架构图如下：

4.算法决策平台（基于腾讯太极平台及图数据库）

为异常分析、趋势预测提供算法模型服务、并尝试利用知识图谱做问题洞察与业务归因，结合专家知识库形成决策建议。例如在时序数据异常检测方面，新业务的指标监控无法复用现有的监控规则，人工规则设置的阈值在一些场景下也比较难以准确设置。目前在做的NM的异常检测尝试，基于规则的话，对于failed数到底应该取多少作为异常阈值，是比较难判断的。不同机器不同时间段的任务负载不一样，不同的机器在相同的时间段，可能出现较大的container失败数差值，很难给集群的所有nodemanager机器设定一个统一的检测阈值，也无法避免人工阈值带来的误报问题。期望能通过统计+无监督学习来进行一个初步的判断（例如指数加权移动平均等）。

平台服务层目前仍然有部分能力正在建设中。

三、应用服务层

应用服务层是由各种平台级能力组合形成产品，面向运维、研发、普通数据分析用户提供的各种场景化应用能力。包括：统一数据大盘（SLO通晒、黄金KPI及报表、秒级监控）、业务洞察（全链路异常诊断）、健康分（任务健康度评估、集群健康度评估）、自治管控（OpenAPI、自助恢复工具等）。

这里讲到的平台大脑的搭建，并没在提数据质量管理、或者是常规的devops领域的配置管理能力，这是因为这部分能力已经有一定建设基础了，所以就没有进行赘述。目前在上面提到的应用服务中，落地已经比较成熟的主要是数据大盘、业务洞察及健康分的部分能力，自治管控能力仍然在探索建设中。下面会对一些具体的落地场景进行介绍。

落地场景

一、任务健康分与全链路异常分析

对于大数据平台而言，每天千万级的作业任务由不同的开发同学进行提交，作业失败问题的排查、作业运行状况的调优，往往涉及到任务上下游多个环节的信息联动，卷入到运维、甚至是各个组件的开发者参与，占用了大量的时间精力，一直是个痛点，而且随着大数据平台上业务规模的增长，这种消耗已经变得几乎不可接受。无论从经验上的观察统计情况来看、还是从二八法则触发，作业问题的诊断调优思路很大一部分是通用的。

平台大脑上利用对任务、集群的全链路监控和异常检测体系，可以比较及时的发现异常；但是将这些异常下游关联起来，传统的关系型数据分析能力在关联方不断增长的情况下，变得不可用，我们借助图数据库来存储任务及其所属服务的拓扑结构，并将异常分析结果标注在图上，能很快定位到任务异常的根因；基于任务各个观察角度数据化，构建出健康分的打分体系，类似电脑管家查毒的checklist，多维度去评估任务运行的可调优点。

目前平台大脑以spark任务作为健康分首先落地的场景，利用知识图谱，从spark任务启动前的统一调度系统，到任务提交Yarn平台、任务运行时计算框架spark本身、以及任务依赖的hdfs存储集群，都被串联起来，在这些环境中中预置了异常发现规则，异常实时发现后会被标注到拓扑图上的对应点中，当以任务ID触发查询时，沿着拓扑图能很快将上下游的问题点标注出来；而非以前从上到下逐层排查的顺序链路，问题排查时间极大缩短。

Spark任务的健康分模型，则是从资源配置参数，Shuffle数据量、Task Input数据倾斜、Task Input数据量、任务调度健康度、慢任务（Task长尾任务）、GC处理健康度等方面对任务数据进行分析，给出任务打分和改进建议。

根据在微信支付场景上的实践情况来看，预计可以协助微信支付至少发现10%的成本节约和任务性能提升空间。

二、全集群GC参数推荐

大数据任务视角

在大数据平台上每天运行海量的Java进程，主要包括Spark、MR、Presto、Flink等类型。绝大多数任务在启动时选用默认JVM GC配置参数，主要包括Java Heap Size、GC类型、并发GC线程数量的配置。这个参数由运维专家的长期经验总结而来，能保证绝大多数任务能顺利地跑完。

但随着任务数量、规模的持续增长单一默认配置会造成一定的资源浪费，例如某个业务默认配置4core/8G的配置，实际评估Heap在4G以下也能相同性能完成计算。业务向集群申请的内存资源是8G，即使实际使用的内存只有4G，多申请的4G内存也不能被其它业务分配使用（受Quota限制）。还有一类，业务早期上线过程中因为数据量大或者其它原因，设置了比较保守的Java Heap配置（例如使用32G的内存），但业务后续数据量有了变化，或者业务处理逻辑调整，继续使用保守的配置，导致内存资源浪费。

针对内存资源浪费的问题，平台大脑的目标是为每个业务找到一个合适的GC配置参数，保证业务正常运行的同时，尽量节省资源使用。从2020年中起，平台大脑构建了GC参数推荐的1.0版本，简化架构如下。

由于Java应用差异性、复杂性，并没有通用的Heap Size选择的公式可供参考实现，在实际调优经验中，基于如下启发式的条件，实现了一个简单但有效的大数据任务Heap参数推荐流程：

足够的Java Heap保证任务能执行完成，不出现OOM等情况。
GC停顿时间占总执行时间的比例小于阈值，通常选择小于2%或者5%，离线、在线（时延要求高）的业务要求不一样。
对于CMS、G1等有并发处理的算法，并发处理的时间占比小于阈值，例如小于5%。

从系统部署的2020年6月到2020年10月，累计推荐优化任务换成成计算单元共计5k+（一个计算单元配置为20核50G）。

大数据组件视角

大数据平台现网的核心服务，比如hdfs的nn/dn，zookeeper等进程，由于服务节点多，业务量大，运维和研发没有精力持续跟踪每个进程的GC健康情况，有不少故障都是因为集群数据或者小文件逐渐变多，导致元数据变多，从而引起GC问题，最终导致影响用户的Job的稳定性，这种故障过往多半是业务首先发现，然后大数据平台侧介入解决，虽然会及时的解决问题，但是会影响整体的可用性。

目前正在开发的GC参数推荐2.0版本，会实时采集的现网各个服务的GC metric数据，对关系服务质量的黄金指标（比如进程的GC时间，GC频率，结合rpc请求的平均/99分位响应时间，集群文件数，block数等）的长周期变化趋势，每天定时从tdw离线数仓摄取数据，经过数据预处理后，通过rpc与机器学习算法模型服务做交互，使用趋势预测类算法进行检测，对发现的GC问题有较大风险的核心进程，按照集群，机器等躲个维度生成相应的检测结果，并作为离线报表的一个组成部分，体现在集群健康分的内容里面。

经验思考与展望

最后，在大数据平台自治体系，也就是平台大脑的建设过程中，笔者所在的团队也踩了不少坑，这里面有哪些共通的经验？

从架构方向来说是老生常谈，为对应业务发展，应当具备有业务快速接入、快速开发和实践的能力。体现为一些共同的特性设计方向，包括：标准化（意味着极易扩展、快速开发）、可配置化（意味着多源支持、零开发接入）、模块化（服务能力解耦，可通过组装来满足新的需求场景）；从数据驱动的角度来看，平台大脑是”以数据治理数据平台“的思路，它仍然遵循一个大数据应用的设计和优化方向，例如可以尝试去做：优化源数据质量、计算下推（思考移动数据还是移动计算？缩短数据处理链路）、必要的预处理（防止数据暴增、降低计算代价）等；从自治本身来思考，自治首先是要把基础（也就是数据采集存储模块）夯实，完备的指标集是实现自治的大前提，这是一个长期不断完善的过程；在此之上，自治的核心是专家经验的沉淀，无论是规则、数据标注、还是用于有监督学习的数据准备，均是这个核心的外化。做好了这些，才能实现“自治”目的：成倍数地延展大数据平台的组件研发者和运维专家的能力范围，也让腾讯大数据平台的用户的精力重新聚焦在业务价值挖掘上。

以上就是腾讯大数据平台大脑建设过程的回顾与总结，前文中也提到了，目前仍然有不少正在探索的能力，非常期望能有更多这方面的伙伴们来加入我们。