300多局点，数据接入量超过2TB/S，华为用AI优化数据中台

【导读】12 月 5-7 日，由中国计算机学会主办，CCF 大数据专家委员会承办，CSDN、中科天玑协办的中国大数据技术大会（BDTC 2019）在北京长城饭店隆重举行。

100+ 顶尖技术专家、1000+ 大数据从业者齐聚于此，以“大数据驱动智能+”为主题，聚焦智能时代大数据技术的发展曲线，围绕大数据与社会各行业相结合的最新实践，进行了深度解读和讨论。

在主论坛上，华为技术有限公司运行商BG高级工程师王力发表了题为《AI在华为数据中台的应用》的演讲。

演讲核心观点：数据中台承载着华为的运营商大数据分析业务，在全球建有300多个局点，单局点最大1000+服务器，数据接入量超过2TB/S。数据中台应用spark支持批计算任务，使用yarn做spark的资源管理器。yarn虽然提供了配置参数接口，但是各局点的应用数据对容器的规格、数量有不同的需求，依赖专家配置费时、费力，且不一定最优。因此，提出应用强化学习算法，针对不同业务，学习、尝试，并最终选择spark运行时的最佳参数。该方法不仅可以用作spark运行时的最佳参数选择，对于其它需要配置运行时参数的系统仍然适用。

以下内容为演讲实录，由 AI 科技大本营（ID:rgznai100）整理：

提纲：

华为数据中台支撑的业务

华为数据中台面临的挑战

AI在华为数据中台中的应用

应对未来的挑战

华为使用AI技术对GTS数据中台的调度系统做了优化。和图像识别、推荐系统、NLP领域使用AI算法不同，在这些领域中AI即使出错也不会对系统本身运行造成影响。相对的，调度系统是整个计算集群的大脑，一旦AI出现问题，整个计算集群会出现性能不稳定，甚至瘫痪的风险，这是客户完全无法接受的。因此，在系统关键组件，尤其调度系统中应用AI本身就是个难题。此外，用于支撑AI做决策的数据本身可能也不准确，这就更增加了在调度系统中应用AI的难度。从现有工作来看，数据预处理占据了一半的工作量，从代码量来看，预处理的代码量几乎赶上核心代码算法量。

我们对调度系统进行优化的目标是提升资源利用率，尤其是CPU的利用率。提高资源利用率的一个直接收益就是节省成本，这对客户来说是真金白银，对我们产品来说就是核心竞争力。算法早一日落地，客户就会早一日享受到红利，所以我们采用小步快走的方式，先把算法部署到现网看到收益，再逐步进行优化。但每次迭代都涉及到后向兼容的问题，同时，我们是面向运营商的设备，需要保证5个9的可靠性，DFX设计本身的工作量就很大，从特性设计到最终版本落地，算法的设计和实现只占了四分之一的工作量。从这里也可以看出，AI算法从实验室到产品落地，有非常长的路要走。

华为数据中台支撑的业务

支撑面向运营商的数字化应用

我们GTS数据中台的主要客户是运营商，为运营商提供数据采集、处理、存储到最后呈现的功能，支撑运营商规、建、维、优、营这5项工作。“规”和“建”就是规划和建设，5G基站在哪里放站，建设密度等都需要大量数据支撑，每个地点的用户使用流量都要作为规划的输入，这些数据的采集和处理最终都要数据中台来支撑。“维”就是运维，运营商在提供服务时的设备网络要保证平稳。经过多年建设，运营商设备的存量巨大，网络复杂，每个网元的运行状态都要及时上报。比如判断需要新建基站，还是通过功率优化来解决信号质量差的问题，需要在数据中台采集大量数据作为判断依据。“营”这点很好理解，运营商如何制订套餐也要依靠大量数据分析，在满足绝大部分用户需求的同时，保证运营商的收益最高。

数据流特征

数据流程一般是：从探针接入话单和网元数据进入XDR流处理，处理之后进入Spark批处理生成SDR，然后入库，支撑用户查询和数据探索。

这是数据中台在全球的局点分布，目前有300多个局点，最大局点有1000+服务器，数据接入量超过2TB/S。根据业务部门的额测算，随着5G的建设，探针接入的数据量要增长为现在的7倍。如果为了支撑这么大的流量，简单地把服务器配置翻7倍是不现实的，因为运营商要考虑成本，甚至机房的空间限制，不可能水平扩7倍配置，只能压榨服务器计算能力，提高服务器计算效率，最终支撑更大流量，节省用户成本。

数据中台面临的挑战

大数据批处理引擎

为了解决这个问题，一般都是派专家去一线出差，现场调优spark批计算的参数，以提升服务器的资源利用率。但是数据中台在全球有300多个节点，每个节点调整约1周，1个工程师把这300多个节点全部调一遍，需要6年左右。而且调完之后的运行参数可能会随着局点数据量、数据特征的变化，变得不再适用，再重新调一遍完全不现实，而且成本巨大。所以，华为就想到了用人工智能解决这个问题。

专家在一线调优spark参数时，先挑选一些关键的参数，再根据经验调整这些参数，调整后观察系统在新参数下的性能，如果性能有优化，则朝着这个方向继续调整参数，如果性能不变甚至下降，则朝着相反方向调整这些参数。专家调整spark参数时的原理与强化学习类似。因此，我们想到用强化学习来解决spark参数调优问题。

使用强化学习调优spark资源参数

强化学习的几个基本要素包括：1） agent，即算法选择调整哪些参数，并从系统收集 性能数据计算reward，判断下一步需要采取的动作；2）environment，就是spark计算集群；3）State，即状态空间，表示选择的spark运行参数；4）action，即资源参数调整的动作；5）reward，当前状态下调整spark资源参数后获得的奖励。每个参数只执行三个动作，调大、调小、不动，但每个参数调整的步长不同。我们的目标是提升计算效率、提升资源利用率，但是资源利用率不太好统计，所以就转化为执行时间，在给定任务条件下执行时间更短，就说明执行效率更高，那么资源利用率就更高。

强化学习还涉及在某个状态下如何选择下一个动作。因为强化学习是一个尝试的过程，要兼顾开发和探索两个方面：开发指已经选择了一套比较好的参数 ，最大程度地利用和保留该参数 ；探索指概率性选择某些没有使用过的参数 。从使用强化学习算法来看，我们没有改动强化学习算法本身，只是根据强化学习对所有解决的问题建模。

我们知道，强化学习样本利用率很低，那么应如何提升样本利用率，加快强化学习的训练速度？我们用了一个取巧的方法，不是通过优化强化学习算法本身来提高训练效率，而是在解空间上使用了小技巧，通过缩小强化学习探索的解空间来提升强化学习的收敛速度。如这张图所示，最外层的大圆是优化问题的解空间，强化学习就是在解空间里找到最优解。在为Spark寻找最优资源参数时，由于spark参数有亲和性和反亲和性，选定一个参数后另外一个参数也会随之改变，就造成了解空间上有一些不可选的参数范围，表现在图上就是很多空洞，而实际训练过程中这些黑洞非常多，很大程度上缩小了解空间的范围，提升了强化学习的训练速度。

插一句题外话，我们知道现在强化学习和深度强化学习最知名的例子是AlphaGo击败人类棋手。对照这张图，人类棋手训练时有棋谱和定式，也就是在小圈的解空间里做训练，永远出不了这个圈，即使在圈里得到了最优解，也不一定是全局最优解。但是AlphaGo一开始是根据人类棋谱训练，之后再拓展到整个棋局对弈的解空间。在图中大圈所示的解空间里拿到全局最优解的概率远远大于在小圈里获得全局最优解的概率。所以即使当时AlphaGo没有击败人类，但只要计算力一直提升，AlphaGo迟早会击败人类。典型的现象就是AlphaGo经常走出一些人类棋手认为匪夷所思的着数，其原因就是这些着数是AlphaGo在图中所示的小圈外获得的最优解。

强化学习落地有两个关键点，其中一个是仿真器。在资源调度领域里，发布出来的成功的案例是谷歌做的数据中心节能，成功的原因是为数据中心节能问题开发了一个仿真器，这个仿真器是一个有19个参数的神经网络，预测不同参数下的PUE并进行优化，仿真器的精度是百分之几。如果仿真器精度达到这种水平，状态空间又不是很多，完全可以不用强化学习，把所有的状态遍历一遍就可以得到最优解。

为什么要做仿真器？第一，保证生产环境稳定是工程师的头等大事，工程师不敢轻易调整参数；第二，强化学习的样本利用率非常低，一次训练需要很久才能获得reward，经过几千轮迭代需要耗费十年、几十年时间，造成强化学习可能还没有收敛，局点就可能下线了，所以不可能在现实场景逐步尝试，只能用仿真器。这也是谷歌数据中心案例成功的关键点。

第二个关键点，每个局点的数据分布、计算特征、资源都不同，仿真器和强化学习模型如何推广？我们的客户是运营商，数据不可能出网，需要在局点本地训练，而且每个局点的强化学习模型和仿真器都不同。怎么办？我们先尽可能把收集到的数据拿到实验室，实验室中有一个几百台服务器的大集群环境，在大集群环境经过训练得到初始模型，把初始模型发布到各个局点做增量训练，一方面增强仿真器的精度，另一方面得到适应各个据点特征的、更精确的强化学习模型。

前面讲的是使用强化学习调整Spark参数，还有一点是做潮汐调度。在GTS数据中台，我们使用carbon在数据的加载，carbon同样是使用yarn作为资源管理器，也就是说yarn上有两个队列，一个是carbon加载，一个是spark计算。在晚上休息时，运营商的流量会下降，需要加载的数据量减少，此时carbon加载队列处于低估，而计算任务需要计算一天内的所有分析数据，所以这时spark计算队列处于高峰。白天正好相反，话务量增加后carbon加载队列处于高峰，spark不需要计算天任务，白天处于低谷，这就出现了spark计算和carbon加载之间的错峰现象。那么，是否可以在白天把Spark计算的资源释放给carbon加载呢？这是没问题的，工程师也是这么做的，但是有一个问题是把多少资源从Spark释放出来，如果只释放少量，carbon加载见效非常慢，而释放过多，有可能Spark资源不够，白天执行的任务出现超时、失败。由于调整spark资源单纯是一个调整资源量多少的问题，我们想到用PID反馈控制来解决这个问题。

由于spark是批计算，可以容忍一定的计算时延，不要求立即得到计算结果，可以在最大时延内把结果计算出来即可，这样就留出了调整的空间。工程师告诉我们，如果spark批任务的执行时间远远小于最大执行时延，可以调得狠一点；执行时间比最大执行时延只小一点，就调得慢一点；而如果执行时间一旦大于最大执行时延，说明调整过度，就得马上快速降下来。这个过程用语言描述非常模糊，但是调整又需要非常精确的控制语音。因此，我们用模糊 PID算法，将模糊控制逻辑去模糊，得到精确的控制量来调整为spark分配的资源。

测试效果如上图所示，左上角是模糊 PID调整效果，经过有限次迭代后，实际的执行时间与目标比较接近，而且非常平滑。PID虽然也能达到最终目标，但是波动较大，这对运营商来说是不可接受的。

然而，模糊 PID算法也面临着各个局点特征不一样，如何在各个局点推广的问题？与前面的做法一样，我们收集尽可能多的局点实际数据在大集群环境中回放，人工做PID参数整定，并调整模糊控制逻辑，再把这些得到的参数随版本发到各局点，在各局点上使用强化学习调整模糊逻辑和整定参数。

测试结果如上图所示，从执行时间来看，使用强化学习算法那之后，相同的任务执行时间缩短82%。

CPU资源利用率方面，此环境下分给Spark35%的资源，不使用强化学习，当前资源利用率等价为57%，使用强化学习以后提升到86%。这其中有一个问题，我们在这个环境里给Spark分了35%的资源，如果YARN上集群只有一个Spark时间对垒，百分之百的资源都给到Spark，会出现什么问题？物理服务器的CPU利用率会一直保持在80%以上，长时间运行在80%以上会大大降低服务器的寿命，所以业务方提出把利用率降下来的要求。我们在设计算法时的初衷是尽可能压榨 CPU的资源利用率，这已经达到算法的设计初衷了，但算法不能一根筋地压榨下去。从AI算法到工程化，在实际应用中算法还是有缺陷 ，需要提前终止，不能达到这么高。从数据中台从这个实践中可以看到，AI在解决复杂问题上确实有优势，但就当前AI的发展水平来说，AI算法不能“狂奔”，必须有专家去驾驭它。

华为数据中台应对未来的挑战

在数据中台的数据处理流程中还有流计算引擎，也需要提升效率、节省成本。流处理和批处理不太一样，流处理每个窗口接入的数据特征差别非常大，涉及资源预测、预留等问题。此外，5G的到来引入了边缘计算的概念，有些计算任务必须在边缘做，有些任务必须在中心做，还有很多任务可在边缘做也可在中心做，对于这些任务系统该如何根据当前状态动态判断把它们放在边缘还是放在中心，这就要AI算法来回答，所以下一阶段，我们的目标会在这两个方面。

以上是我分享的内容，谢谢大家！

嘉宾介绍：

王力，华为技术有限公司运营商BG高级工程师，西安交通大学博士。主要研究分布式计算平台、大数据处理引擎的资源调度技术，获得教育部科技进步二等奖（第3完成人）

◆