邹建平：智能化大数据平台打造实践

12月15日，由腾讯云主办的首届“腾讯腾讯云开发者社区开发者大会”在北京举行。本届大会以“新趋势•新技术•新应用”为主题，汇聚了超40位技术专家，共同探索人工智能、大数据、物联网、小程序、运维开发等热门技术的最新发展成果，吸引超过1000名开发者的参与。以下是大数据AI分会场的演讲内容，稍作整理，分享给大家。

大数据平台具有集群规模大、数据量大、组件多、模块间交互复杂等特点，而腾讯云需要面对不同的应用场景和业务需求。因此，如何及时发现、快速解决现网问题，并针对客户应用场景给出优化建议，持续提供高质量服务成为重点话题。本演讲介绍了腾讯云大数据团队如何通过引入机器学习、实时计算等技术提升集群运维效率和质量，最终实现为客户打造智能化的大数据平台。

腾讯云大数据产品现状

相信大家或多或少都和大数据平台打过交道，也相信经常会在实际工作中遇到大数据平台因为它的一些部署，运维，或者是配置的一些问题，导致运行缓慢，甚至出现故障，对具体的数据任务造成影响，比如在这个时候需要给老板的报表而无法按时提供，或者是机器学习的训练异常终止，这通常会是一个悲伤的故事。那么，在云上除了传统的运维以外，如何用一些更先进的方法来给大家提供更稳定、更可靠的数据产品，也是我们一直在思考的一个问题。

我今天给大家分享的主题是，腾讯云大数据产品如何通过一些智能化的手段，给大家达成可靠和高效运维的一些思考和探索。

腾讯云大数据产品线

目前腾讯云在公有云、私有云都有着全方位的大数据产品矩阵。其中大数据TBDS是从腾讯大数据平台孵化出来的，经历了腾讯内部业务数百PB数据规模的锤炼，具有从平台、应用到服务的一站式的大数据处理能力；数据仓库产品线包括两款各具特色的产品，一个是Sparkling，它是一个全托管、高性能的，PB级的云端数据仓库套件；而Snova是面向传统应用、具备高兼容性的Mpp数据仓储服务。EMR则是提供了云上Hadoop托管服务的产品，只要你之前的应用是基于Hadoop架构，就可以通过EMR产品来轻松的上云；在实时计算领域，我们有基于先进实时框架flink的流计算服务SCS，它具有高性能、易用性、弹性等特点；在搜索服务方面，我们有Elasticsearch Service，它是基于目前非常活跃的ELK生态，通过它可以快速构建日志分析，全文检索等应用；同时我们也提供了商业智能分析和云搜等报表可视化，以及垂直搜索的一些应用。通过这些大数据基础服务以及腾讯云的其他一些服务，例如像数据库、消息队列、对象存储，用户可以非常灵活快捷的构建自己的大数据应用。

腾讯云大数据面临的挑战

在为云上客户提供大服务的过程中，我们意识到，除了满足客户基本的功能、性能诉求之外，如何把原本复杂的大数据平台更稳定可靠的提供给客户使用，然后尽力帮助客户节省运维成本，是数据产品的核心价值之一，但是当前云上大数据产品在运维上面临着的几大挑战。

首先，大数据产品是一套复杂的分布式集群，里面的模块多、节点多、拓扑和配置复杂；再次，云上使用大数据产品的客户来自不同的领域，有电商的、有金融的、有游戏的，业务形态不同，使用场景和方式也各不相同；最后，大数据产品的数据规模大，同时越来越多的业务有实时性或近实时诉求，对运维响应时效要求高。所以如何在这种复杂业务场景下，高效率发现问题和解决问题，具有相当的挑战性。

我们怎么样应对这些挑战呢？能否以数据为中心，然后融入智能化的一些算法，来运营大数据产品本身呢。顺着这个想法，我们找到了智能化运维的思路。

智能化运维的概念和价值

我们先看一下智能化运维到底是什么？这个图描述的就是运维从一开始的初级阶段到高级阶段的一个演变过程。从最初的纯手工的运维，到后面通过自动运维工具构建的运维平台，再到后面研发运维一体化的DevOps模式，都是为了让产品运维更加简单、高效和可靠。目前公有云大数据产品基本上解决了客户在自动运维方面的诉求，用户可以在控制台上一键部署、扩容，或者下发配置。但是，在复杂场景下的故障处理和性能调优仍然需要人来决策，随着云上业务的规模和复杂性的爆炸式增长，之前的传统化自动运维方式，也无法进一步来提升我们的运维效率和质量。

所以AI方法的一个引入，可以使得机器能够代替人做这些决策，让真正意义上运维自动化成为了一个可能。Gartner也看到了这里的价值，在两年前提出了智能化运维AIOps的一个概念，这是它的一个概念图。总的来说，AIOps就是以大数据平台和人工智能算法为核心，对运维数据做一个采集、进行分析决策，最后执行解决问题的一个闭环流程。

近年来，业界对AIOps的研究日益高涨，腾讯内部也有很多运维团队有着非常丰富的实践经验，所以我们大数据产品引入AIOps，也有很多成功的经验来借鉴，更有把握。

AIOps有很多落地点，我们针对目前大数据产品的痛点，从探索问题、发现问题、优化问题等方面做了一些探索和落地。探索问题，是将大数据产品的日志和指标进行汇聚和呈现，让人能够更快速分析问题；发现问题，是采用基于统计和机器学习的算法代替人的经验，及时迅速对指标做出异常判断，能够实现无阈值监控告警；优化问题，我们是通过智能化的手段，来对大数据产品里的配置和参数进行智能调整，使系统运行在最优的状态下。

智能化大数据平台最佳实践 – 探索问题

首先来看一下探索问题。当系统出现一个故障的时候，最怕的是两眼一抹黑。对大数据产品来说，除了内存、CPU等基础监控的上报，还需要业务层面的日志来进行问题分析。我们采用多种方式来呈现数据产品的运行状态，让运维人员对系统了如指掌。例如ES就用来收集大数据集群里各种功能模块的日志，一方面，在追查问题的时候，可以在一个统一的平台下查看搜索流程日志，另一方面，数据收集好了，未来可以进一步挖掘日志，关联业务行为，便于将来主动发现问题。

分布式系统各种模块之间调用和交互复杂，我们采用了jaeger收集各模块之间的RPC调用上报，通过这个平台可以将不同模块之间的请求关系关联起来。在出现异常的时候，可以快速找到调用链上的异常模块，和查看调用详细信息，快速解决问题。

对于大数据集群里的作业维度的分析，我们采用了dr-elephant，它是一个hadoop、spark的作业性能监控和调优工具。它能自动采集作业级别的各种metric并分析后以简单明了的方式展现出来，例如可以方便查看数据倾斜情况。

通过使用这些可视化工具，能非常好的解决了大数据系统节点多，调用复杂，难以快速分析故障的问题。

智能化大数据平台最佳实践 – 发现问题

接着让我们来看下如何发现问题，这里我以流计算产品为例来介绍。很多用户就是用流计算来进行业务监控和告警、或者实现金融业务里的实时风控，所以流计算产品对数据处理的时延和吞吐都有比较高的要求。如果出现异常的话，例如，当flink任务处理中出现大状态，导致内存消耗过多，如果不及时介入，可能会引起OOM，对整体服务会造成影响。

例如以下几个异常曲线，一个是taskmanger的gc时间出现了突增，第二个是流计算的消息处理出现了突降，第三是ES服务的写入量的爆增。这些都是需要业务方关注的，但对于不同客户，不同业务场景，对业务的指标可能有不同的告警要求。如果仍然采用传统的阈值告警方式，例如固定值或波动率告警，一方面每个上报指标设置阈值比较费时费力，经常出现漏设置的情况；另一方面，即使设置了阈值，如果设置过低，会导致误报，而过多误报警会让用户对这些告警视而不见，而阈值设置过高，则可能业务出现问题而没有被及时发现。

那么我们的解决思路，就是采用基于统计、机器学习的算法来自动化判断异常，无需设置阈值。

我们再讲一下通常在工业界做日常检测的基本算法。我们先看一下基于统计和无监督算法的一个情况，这是它一个基本的流程，但实际数据流到系统里来的时候，我们先对数据做预处理，有差值补缺或者归一化操作等，再通过统计和无监督的算法再做判断。通常我们会针对一个检测点会取之前1小时或3小时的数据作为一个窗口，然后通过一些统计的方法来做一个判断，比如说3sigma和控制图算法。

3Sigma对正态分布的数据比较有效，对均值正负3个标准差之外的数据会判定为异常。统计的另外一类用的比较多的算法是控制图的算法，我们自己用的比较多的两种，一种是加权移动平均法，另一种是EWMA。加权移动平均法是对观察值给予不同权重，求得移动平均值来确定预测值，并以该值为基础设置上下界，如果待测试点超过上下界，则为异常。EWMA的权重随着时间呈指数级递减，更能反映近期变化的趋势。

我们再来看一下基于无监督的异常检测，跟前面的统计方法类似，也是对采样点之前的窗口样本做一些判断，我们这里常用的有单分类支持向量机和孤立森林，这里和统计方法的区别，需要提前对数据样本做一些训练，得到无监督的模型，再用模型来对待检测数据进行异常判定。

我简单介绍一下，单分类支持向量机，对于前面的正常样本做一个训练，得到一个决策超平面，后面对待检测点跟决策超平面做一个关系判定，如果落到里面是正常点，落到外面就是异常点。另外一种无监督的异常检测方法是孤立森林，可以理解为无监督的随机森林算法，基本的思路是用一个树模型对样本数据做一个分割，一直分割到只有一个独立点为止，我们发现，越快分割成叶子节点的数据点，就越有可能是异常数据。该算法对内存要求比较低，而且具有线性时间复杂度，是一个较高效的算法。

我们来小结一下刚刚基于统计和无监督算法的优缺点。优点是性能不错，不需要标注，用的比较广泛。缺点是统计方式比较固定，没有对前面数据做标注学习的过程，所以说它的适用面比较窄。

我们再来看一下如何用有监督算法来做异常检测，跟其他机器学习的方式差不多，一个是离线训练阶段，我们收集好系统的时序数据，先进行数据预处理，然后需要对这些数据进行打标，标注时序数据中哪些点是异常点，在对标注好的数据进行特征工程后，采用各种有监督算法进行训练，最后输出分类模型；另一个是线上预测阶段，数据经过预处理后，采用同样的特征工程，通过分类模型进行预测判定。

这里是我们的算法框架。我们先会对数据做一个特征提取，生成一个特定集合之后到我们的模型层，会通过对逻辑回归，LightGBM，深度神经网络等多种算法集成的方式来输出一个加权的异常概率。

特征工程在机器学习里是一个非常重要的步骤，我们从统计、拟合、分类以及组合等多个维度进行了特征提取。最终我们将时序数据生成了数百个特征。

有监督算法的优缺点，跟统计无监督差不多相反。优点是有标注学习的过程，所以适应面比较广，对于异常能够分辨的更好。缺点是因为有标注过程，所以标注的人力成本比较高。同时在预测阶段需要做特征工程和算法预测，所以说计算开销也比较大。在我们的实时异常检测的场景，计算开销也是一个较致命的缺点。

所以最终我们采用了混合的模式。通过统计和无监督算法，筛掉多数正常样本，同时尽量把异常的样本召回。在离线训练阶段，提前使用筛选可以让后面人工标记少了很多工作量，也可以提升异常样本在总样本中的比例；而在线预测阶段，采用筛选可以把大部分正常样本筛掉，后面的有监督算法则会少了很多计算量。当然也可能在前期漏掉一些异常样本，我们也会对前期的筛选样本集进行抽查，如果有明显的问题，会调整统计或者无监督算法的参数，优化这块的表现。

简单介绍一下如何用腾讯云的数据产品来实现这样的一个实时异常监控系统。大概分为几块，一个是离线系统，一个是在线系统，还有跟外围互动的平台。

在离线系统部分，我们使用EMR里的HDFS来存储样本库，通过生产系统采集的上报从kafka按照一定格式存储到HDFS；EMR里集成了spark来对样本进行统计分析、特征提取和模型训练，最终将模型存储到了对象存储COS。

在在线系统部分，大数据生产系统里的日志和上报也通过kafka消息队列发送到流计算服务，在流计算服务里包括两个主要处理流程，一个是实时数据处理，这里面包括数据预处理，统计过滤，特征工程，以及采用分类模型进行预测，在这之后产生的异常事件会在规则引擎进行二次处理，这里的规则引擎我们是采用CEP模块来实现的，可以对一些事件进行更复杂的处理逻辑：例如通常异常事件会触发告警模块，这时我们会调用外部云函数接口，经过对事件的关联，发送微信、短信或邮件等给到对应的关注人；也有一些异常事件需要满足一定的规则，例如某事件重复触发，或者多个事件按照一定的顺序触发，我们会采取一些反馈动作，例如对系统进行自动扩缩容的动作；同时，这些事件也会发送到搜索服务ES里，进行后续的复盘。

这个是Flink线上实时流处理逻辑里的实现，当数据从Kafka流到流计算服务的时候，我们会先对数据进行统一的数据预处理，接着会复制两路流进行后续处理，一路流，也就是下面的路径，采用固定规则直接进行检查，例如越过了预定义的阈值，就会发出告警事件；另一个流进入智能告警模块，在这里会先过滤掉部分不需要智能告警的数据，然后通过keyby算子做多路分流，在每个流里，会先进行window划分滑动窗口，然后对每个滑动窗口，来做异常预测，最终输出的异常事件继续流入规则CEP模块，输出对应的动作。

最终我们的验证效果还可以，我们的准确率大于88%，召回率接近于80%。未来的优化方面是一方面通过对时序曲线进行聚类算法的分类，匹配相应的预测模型，来提升准确率；另一方面是我们也会对长期活动的曲线做周期性分析，再用更长的周期采样数据来进行训练，提升效果。

智能化大数据平台最佳实践 – 优化问题

我们再来看一下优化问题的场景，我们以EMR产品做例子。上面的图，是spark里面因为用户内存参数设置不合理，导致了任务有严重的GC情况；下面的图，是在我们的某个MR任务中，用户由于设置参数不合理，一方面，reduce任务个数设置偏少，另一方面，内存设置不够，结果导致了很多的溢写，性能没有达到要求，最后经过和客户一起分析日志，调整参数，任务执行时间从26min缩短到了21min。

在EMR产品里面涉及的Hadoop组件非常多，大大小小有十来个组件，对于任何一个大数据运维团队来说，对于Hadoop这种复杂性的产品，面临的问题是业务配置复杂，人工配置繁琐也容易出错，对云上的大数据产品，因为不同用户使用的情况也不同，这个问题就更加突出了。所以我们的解决方案，是希望能够通过一个机器学习的算法，来对参数的情况预测后面系统执行的效率，最终就是回归的问题。

用传统的机器学习来对这里的参数进行回归，最终能够优化参数。但存在一些问题，例如算法对训练数据的数量和质量，依赖都比较重，而在大数据平台调参这个场景，我们很难产生足够多的样本数据来进行训练。

于是我们想，强化学习只需要较少的样本数，是否可以解决这个问题？强化学习是一种模拟人类和环境交互学习的方式，普遍应用在游戏、机器人等领域，例如大名鼎鼎的alphago就是用的强化学习。它与传统机器学习不同，机器学习需要大量的数据来对模型进行训练，最终得到一个预测模型；而强化学习每次做出动作，不会得到对或者不对的结果，只会收到一些反馈，通过这些积累的反馈来调整优化自己的行为，最终迭代生成最优的策略。

Q_learning是一种常见的强化学习方法，它迭代学习每一个状态下，选择不同动作执行后获得的回报，学习到的Q值存放到Q表里，其中每一项Q值代表在某个状态下某个动作的最大期望的回报。等Q表成功收敛后，如果我们在Q表里执行每个状态下最大Q值的动作，就可以得到一个最优的决策路径了。但是，Qlearning是有缺陷的，它无法解决状态空间维度爆炸的问题，例如我们的大数据平台有上百个参数，假设每个参数有20个值选择，那么这个状态空间组合就有20的100次方的可能性。

所以后来人们提出DQN，一方面，使用了神经网络来逼近Q价值函数，也就是前面的Q表，这样就解决了状态空间爆炸的问题；同时也通过使用经验池回放的方法，以及两个同结构的神经网络来进行训练，能够快速收敛学习到Q值函数。

我们看一下DQN在EMR场景的落地。它有State、Action、Reward等几个关键元素。其中State表示EMR的hadoop集群里的一些关键参数，每个参数都有一些变动范围；Action相当于是我们对这个参数调整的一个动作，Reward则表示每次在emr执行基准任务后，性能变化情况；这里我们的性能指标一般是任务执行时间，或者资源利用效率，这个是根据我们的优化目标来定。在动作策略方面，贪婪策略容易陷入局部最优解，所以我们采用了e-greedy方式。我们最后也尝试了Double DQN，这个新的算法对原DQN进行了优化，能够收敛得更快。

这里是一些测试结果，DQN方法在更短时间内达到了比传统机器学习方法更优的效果。而double DQN方法则比DQN收敛的速度更快。

未来的改进方向，一方面是继续提升现有算法的性能，用更少样本来达成优化目标；另一方面，是如何将一个业务模型学习到的经验，快速复制到其他业务模型，而无需重新积累新的测试样本来学习。

未来展望

前面介绍了我们在数据平台智能化方面的一些探索和落地，我们目前的探索才刚起步，下面来看一下未来的展望。总的来说，我们会从四个方向进一步加强和优化：首先是场景化，我们需要挖掘更多提升大数据平台能力的点，例如异常告警后如何继续进行根因分析，进而能够正确地自动触发故障恢复流程；接着是产品化，目前已经在内部使用的一些告警和调优，等到充分验证后，会开放给到前端，用户可以直接使用；然后是平台化，通过平台化能力来提升接入算法的效率，能够快速引入更多新算法，变成生产力；最后是知识化，目前很多探索的场景还是属于一个case by case的情况，如何将现有业务学习到的模型复制到其他的新业务，需要我们进一步研究。

我今天给大家介绍了腾讯云大数据现有产品线的情况，以及在服务云客户的时候运维方面面临的挑战，并且我从探索问题、发现问题、优化问题几个场景来进一步阐述我们在大数据平台智能化方面的思考和探索。最终希望能够把我们大数据产品的运维做的更好，给大家提供更稳定可靠的产品。