王华，2014年加入阿里巴巴，一直在做大数据运维相关的事情，同时也在做运维平台的开发。第一年做线下运维，2015年开始做流计算运维，之前负责阿里云的流计算。2017年开始负责Flink运维，以及Flink运维管控建设。一、阿里Flink集群运维挑战首先说说流计算。批量计算是指数据集是有限的，每次计算可以得到相同的结果。在batch计算之上，如果batch多了，数据就会一直不断的来，就变成了一个flow。流计算是批计算之上的一个概念。许多流计算被使用。比如前端的所有日志每天都导入到流中，持续一天。再来说说阿里的流计算引擎。2015年，银河自研流计算。阿里2014年就有流计算，那时候有JStorm和Flink，分布在搜索和中间件部门。之后经常在内网PK，这几个引擎哪个最好。2017年前后，Flink以低延迟、高吞吐、一致性等优势从众多流计算引擎中脱颖而出。后来，整个集团统一了技术，其他引擎都被抛弃了。使用了Flink。Flink是阿里的统一流计算引擎。有了这样的基础，业务继续发展，所有的流计算引擎都迁移到了Flink。另一方面，我们对数据处理的要求越来越高，现在是尽可能的实时。现在越来越多的Flink本身已经有了很多批计算逻辑和机器学习。结合这三点，阿里的Flink集群变得非常庞大。据我了解，Google、Facebook之类的东西毫无用处。只要是用Flink，阿里的Flink集群都是全球最大的。现在我们的集群有几万个计算节点，大部分是传统的物理机，也有ECS和容器居多；集群有几百个，Flink的一些用户是阿里内部的，最大的集群规模可能是56000台，但是在阿里云上卖的，一个用户可以开一个集群。所以有几百个集群，一个集群可以有几百台或者几千台机器。整个系统非常复杂，因为Flink是一个计算系统，不负责数据的源存储和目标存储。因此，数据必须从上游读取，然后写入下游。在数据库或者其他系统中，上下游大概有几十个，整个Flink有很多base。最早有基于Hadoop的基地和阿里飞天的基地，现在有基于Kubernetes的云原生基地。另外出口也很多，基本上全世界都能看到Flink的应用。目前阿里内部只有Flink每秒处理数十亿条数据。数据量非常大。一条数据是1K。想想这个数据有多大。这么大的规模，在运维上遇到了很多问题。挑战分为以下几个部分：第一部分是故障，尤其是实时计算系统，运行在Flink上，所以我们对故障的要求比较严格；第二部分是如何保证大促的稳定性，如何保持大量日常运维操作的一致性；然后是成本，包括如何管理硬件成本，如何合理分配和平衡用户资源，如何降低运维人工成本。我们不仅做Flink运维，这么大的工作量，整个运维只有几个人负责，业务规模基本每年翻一番。它是一头奔跑的大象。首先，靠人运维是绝对不行的。这也是大数据运维和其他操作的区别。靠人是绝对不可能取胜的。一切运维都要以技术为出发点。基于技术，我们做了一个Flink运维管控。最上面是承载了很多Flink技术方案的Flink运维管控。我把这两个“技术”标红了，我们任何时候都不要忘记，我们需要用技术来解决这些问题。2、阿里Flink运维管控2015年的时候不叫Flink运维管控，叫流计算运维平台，2017年这个东西做大了，左图，我们运维一个集群，就是整合了一堆IDC资源：网络、机器、内核。软件部署在集群上，分布式系统软件和Flink软件，业务运行在软件上。运维主要针对集群业务和软件。用户分为几个部分。初期用户是我们自己平台的SRE，运维和运维研发（Flink开发），平台的业务端，很多现场外包也用到。整个权限的设计围绕着四类用户展开。它提供了很多功能，整个Flink以机器-集群-服务-业务的形式运行。因此，它带来了多种维度的产品化运维，如从管控平台一键发布、停止服务、提供实时秒级监控报表，其中包括监控系统。整个Flink管控做了资源生命周期管理，不仅仅是硬件，还有一些基于数据的运维和越位增值公司，现在还有智能诊断和故障自愈。下面说一下整体架构。最底层是数据层。我们在做一件事，就是Flink实时运维仓库的建设。一部分是业务数据，Flink自身的数据，一部分是实时数据，一部分是周边表数据。有一些公开的数据，这一层的主要解决方案是保证实时性和准确性。数据层之上是服务层，基础运维服务，数据分析服务，比如最左边的房产检测，日志集群，还有业务服务，诊断服务，资源服务。最上面是功能层，也很清晰。以业务为先，用户拥有自己的业务中心。它围绕稳定性、成本和效率三个主要领域构建。首先，我们需要谈谈稳定性。我们该怎么做呢？我们围绕着软件的发布，从整个生命周期来讲，每个环节怎么解决，第二个是成本，资源的生命周期怎么解决，日常运维的效率怎么解决。这是Flink运维管控功能的一个布局。其实这里的功能很多，菜单布局也有很多版本。后来我们找到了一个清晰的思路，就是业务有users，jobs，monitoring等等。其次是运维，就是稳定。面向运维的实体包括集群、机器、业务和服务，以及运营和KPI衡量；分析是为了提高效率，面向用户的业务包括所有实时操作。队列、预算等。这就是运维，是面向管控的。有多个运维，每个点可以管理一个集群或数百个集群。这是诊断分析。我们将在下面讨论它。我们的目标是说一个站点必须能够运维所有的集群。这其实是非常具有挑战性的，因为它涉及到很多异构的部署架构和网络域，阿里的网络领域比较复杂，未来的挑战也很大。3、Flink运维方案先说release的变化。在过去的几年里，GOPS中的每个人都在谈论自动发布更改。这两天听了，没有人说要发起变革，说明他们做的很好。你发现阿里前两个同学都讲了发布的变化。其实在阿里要发布变化还是挺难的。为什么？首先，阿里的场景非常复杂。同学提到我们几万台机器的内核怎么从3升级，如果业务上部署了十个软件，哪个软件提供接口，告诉他十个软件都下载了还不行。几万台机器，一天一台机器，半小时升级内核，升级到猴年，需要半年时间。这个时候可能会有业务需要分批升级。这更复杂。如果说纯计算Node，没有state，很简单。你不能说三台机器同时分布在不同的机架上，数据就会丢失。这是大数据分发系统的复杂点。另外一个就是流程很复杂，复杂在哪里？从一个软件包，有很多模块，再到测试环境，再到发布前的复现环境。这个过程有层层审批机制，可能会有熔断、回滚、验证。这个过程非常复杂。最下面是发布一个技术服务，下面会调用一些其他的能力比如天基。范围是发布流程，最后是发布场景，用户端和平台端发布。我们将很多场景做成工单，预先定义了所有的发布流程，你只需要做一个清单，所有的发布计划都会安排好。本周这两个集群的发布，所有的发布计划都安排好了，发布之后再执行，可以做到分钟级别的提单，不过最后也是给中台的，而且它可以利用天基的能力，实现全业务集群的自动化，一致。我刚刚谈到了软件发布。这里我先说一下Flink。软件包发送到集群后，如何让用户使用。用户的工作是一个长期的任务，一直在线运行，除非需要停下来使用新版本。只有上传所有资源才能升级到新资源。这就是流计算本身的原理。数据是时间轴。如果在10点停止，怎么能保证11点醒来呢？如何保证自恢复recovery，有一个状态，所有的计算中心结果都写在本地存储上。不同的版本有不同的兼容情况，整个升级非常复杂，升级几万个作业难度很大。的。在业务发布上，天机解决不了我们的问题。我们有自己的一套解决方案。每个人对此都有很多技术细节。如果你不了解Flink，我暂时不说。最终用户可以根据自己的业务属性自动批量升级。我们会打通升级的所有闭环，升级失败自动回滚，升级成功自动通知。这里面有更多的技术细节。软件上线，用户开始使用后，如何保证用户流畅运行，其实是失败的。我觉得在GOPS里面大家都是看故障和异常的，通过异常，即使平时有报警也算是异常，但是我们最关心的是如果按照报警去做，有警报太多。我们关心的是故障，传统的故障。众所周知，失败的感觉就像是突如其来，无可避免。每当这种失败来临时，你每次来都显得很被动，就像个孩子一样。你不知道什么时候哭。各种问题来了，老板会问你，怎么了，各种业务反馈，你会手忙脚乱。结束后，我很累。可能觉得告警没覆盖，加点告警，或者流程有问题，改进流程。故障就是这样，这很难。但实际上，去年我们做了一些事情。事实上，故障本身就有一个完整的生命周期。首先，服务是正常的。目标是减少故障。每个系统都有自己的故障定义，一开始有一些不正常的隐患，比如集群有5000台机器，有几个操作很糟糕，网站慢慢漏水。很多机器慢慢增加了，但是没有问题。当达到一定值时，比如有10万个核心线程的机器，负载可能开始很高，大量的CPU消耗在内核线程切换上。如果不处理了，因为是分布式系统，其他的job，会不会所有运行的job都有心跳？如果心跳超时，则失败。开始检查故障，故障后恢复，恢复正常，开始连续循环。这是一个完整的生命周期。其实这些断层都是借来的，分为两部分。一方面是故障隐患。我们没有缺点。但是，系统已经出现了异常。此时无需承担任何责任。这时，我们要积极发现和治疗。第二点是怎么回事？没有什么问题。我们只能快点发现，快点恢复。故障其实是有生命周期的。正确认识生命周期后，可以采用一些技术手段，系统地解决故障，低成本维护。我们如何发现和治愈潜在故障分为两个部分，包括潜伏期和暴露期。就是不知道潜伏期。曝光就是一个电话，它会分析各种数据。数据拿过来之后，第二部分就是分析。可以使用监控，也可以使用传统的阈值监控。对于异常事件，这是一个潜伏期。事件、异常事件主动发现。我们通过一个实时的环节，因为如果一个异常事件进入一个系统，如果处理慢了，就会导致失败，然后进入下面的治愈系统，这个系统是大家一起开发的，感知并执行决策。我感知这个事件，然后做出决定，最后执行和运维系统不断积累我们的经验。比如潜伏期有哪些自愈场景？有的作业盘写得很辛苦，有的作业挂了。一个工作挂掉是没有问题的。自愈系统暴露、告警、异常事件。几百台机器，然后工作，解决问题后，通知用户已经恢复。我们使用这个系统和理论，这是一个真实的场景。以前，每周大约有28到29个电话，但现在我们已经达到个位数，每周只有两三个电话。在潜在失败阶段，我们可能会尽力而为，但真正失败了，我们就到了第二阶段。有真正的故障，如何发现故障并从故障中恢复，GOPS在很多领域都说过，有异常，异常检测，根因分析，然后反馈。首先我们有一个故障定义，因为系统很大，我们需要找出一两个指标，并且能够明确的说，这个指标有问题，我的就有问题服务。像淘宝天猫，下单是一个KPI，支付是一个KPI，重定向是另一个KPI。如果前端访问不上，那是没有作用的，往下的指标也没有意义。如果整个集群的水位突然下降，可能是因为软件升级，也可能是部分用户停止了一些操作，手动操作，不算故障。越低的指标越没有意义，但是如果流量下降，很可能是失败，但也不一定，但至少位置越高的指标肯定越有意义，并且噪音越来越小。Flink把每一个运行状态，做成很多条曲线来反映服务的情况。最后这个指标的黄金指标，衡量一个服务好不好的最后一个黄金指标，一定要非常简单，不可能有很多很多曲线。曲线，肯定是不可能的，如果有，那一定是金指标，提取不正确，检测就是根据这个金指标。二是多指标关联。我们需要关联异常曲线，一种是断崖式的，一种是突然增加的。下一步是故障定位。必须明确指出故障位置。现在怎么了？我会把我的过错量化，我哪里错了，错在哪里，现在受了多少苦。一定要弄清楚是哪个服务，哪个集群出了问题，大概有多少个job受到影响。这些事情必须明确说明。然后是根本原因定位，其实是很难的。我们没有使用很多乱七八糟的代码。我们只是根据自己的经验，将经验代码一一记下。我知道失败的根本原因，我开始自愈。没那么简单。一些简单的场景可以自动恢复。比如有问题，可以从第三个服务上诊断出来。这里你可能不是很清楚。是失败了，我们钉Pin有一个push，出问题了。现在Flink服务正常了吗？这是一个比较难的问题，因为整个系统非常复杂和庞大。它不是链接，甚至不是链接。可能是异步的，没有ID。不同运维周期的对象都不相同，如果故障排除率低，可能会导致故障。我们如何诊断这个事情，一个系统，一个集群有很多存储调度、管理和控制的模块，每个模块也尝试按照刚才的规则抽取一两个黄金指标，来衡量这个模块好不好，根据这个黄金指标做模块诊断，然后再说集群好不好，集群诊断完成后，就可以做服务诊断了。这是夸大其词。如果在几分钟内发现故障，我们无法提供根本原因和恢复建议。这还不够。下面说说Flink相关的东西。大促的压力测试怎么做。用户有很多作业在线运行。我们要做一件事，用户的job，因为每个job的计算逻辑代码不一样，我们需要测试一份用户的计算逻辑到备份链接，看是否能满足要求。如果能够实现，就相当于双十一可以解决问题。克隆一个shadowjob，替换上下游，开始增加压力，做各种实时监控性能报表。只需在平台上点击一个职位，它就会自动完成这些事情。我说一个大家直观感受的事情。我刚才说了，整个服务本身已经是每秒处理数十亿表的数据了。按照正常的双十一，肯定是平时的几倍。你要创造的数量也应该是几十亿的几倍，否则逻辑说不通。这是一个非常困难的任务，一百个机器人都解决不了，更别说一个小脚本了，这根本不可能。这是我们大数据运维同学比较强烈的感受。我们非常擅长利用自己的大数据系统来解决我们在大数据运维中遇到的各种问题。我们想出了一个非常巧妙的解决方案。我们使用Flink自己的能力。这些Flinks可以巧妙地解决两个问题。充分利用Flink强大的分布式计算能力，可以解决压测过程中的高压问题。压力瓶颈。集群不能一上来压力就关掉，必须一步一步来。如何精确控制，我们通过使用不同数量的Flink作业巧妙地解决了这个问题。这是Flink最重要的业务。GMV大屏成交额，你可能每天在公关公关上看一分钟卖多少亿，十分钟卖多少亿。该任务在Flink集群上。逻辑是将整个淘宝和支付宝的交易数据库同步到数据通道，并启动一个Flink作业。该作业不断地消耗所有事务日志并将它们写入另一个存储系统。前端巡视存储系统。数据量大到可以持续一整天，Flink的作业延迟在秒级。再说说用户资源。用户资源只有我们阿里巴巴人才能懂。说白了，你有5万台机器，可能有500万个CPU。如何为现场用户合理分配资源？一些用户说我的生意很重要。这是一个非常复杂的场景。如何合理高效的为用户分配集群资源？我们希望最好的状态是用户不需要关心资源。如果资源池无限大，那到处都是资源，根本不用管。这件事。其实用户资源也是有生命周期的，从最开始的预算提高，到线上资源的扩张，再到上线后，一些用户滥用和使用了很多资源，我们怎么优化，怎么平衡，资源回收后如何平衡，如何计量计费，整个生命周期通过预算服务和资源服务进行管控。如何管理第二个硬件资源？如果每天10000台机器只安装一台，我们每天都要挂好几台机器。停机率为1/10,000。一天要维护多少台机器？一周几十台机器，如何做自动化维护，如果过程中效率很低，会导致下面的故障机器越来越多，一年几千台机器，如何高效上线下线。我们管理机器的生命周期，包括机器启动、容量扩展、硬件维护、收缩和保修到期。这或许与天机有关。我们会用到天机的很多能力，但是里面有很多业务逻辑。我们从业务上从机器生命周期的角度出发，希望我们平台上选出来的一堆机器能够自动下线，从而降低成本。下面说说Flink作业是否正常。我们做了一整套的作业诊断，比较复杂。整体思路下有很多事件、日志、接口、指标。下面有个诊断服务，主要做几个东西，运行状态，哪个状态是什么？Stages、logs和runningindicators，下面有很多条目。第一部分是工作状态。只要知道Flink的状态，每个状态是什么原因，第二部分就是日志集群。该算法将写入库中。该库中的日志属于该实体。是什么原因？我不知道原因。我们需要专家来标记它。标记之后，下次有新的错误进来，我们就可以找到这个日志，告诉他原因。如何处理这个工作是一个诊断思路，是我们落地的结果。基本上，资源跑不起来，我可以告诉你，因为资源跑不起来，应该怎么办，怎么扩容，哪里扩容，一站式，昨晚一台机器下线了，而且是可能告诉你哪个节点需要调整哪个内存。除了工作诊断外，思路都是一样的，就是通过一些技术扎实，通过经验原理和数据来实施诊断，最终定位到问题的根源，恢复意见。我们不仅做工作诊断，还做机器诊断，一个机器输入告诉你机器好不好。最后说一下智能运维机器人，解决问题非常容易。我们回答的问题很多，用户会有各种各样的问题，以前都是靠人。通过钉钉，我们的运维只需要构建文档、操作、流程的知识图谱，结合钉钉进行整体协同。用户完成端到端的问答非常简单。里面的功能很多，就不一一细说了。大数据运维的难点在哪里？阿里的大数据形态和别人有很大的不同。我们很早就意识到了，比如技术上的统一很早。Flink流计算是一个面向所有人的统一引擎。离线计算可能是MaxCompute，用空间做集群管理。近年来，没有重复。这方面推动了整个阿里巴巴底层大数据平台业务的快速发展，机器规模也随之增加。更多的复杂性导致运维方面的挑战越来越多。以上是阿里大数据运维技术专家王华在GOPS2019上海站的分享。
