王玉君，腾讯云后台工程师，拥有多年大规模Kubernetes集群的开发运维经验。目前负责腾讯云TKE大规模Kubernetes集群的大数据应用托管服务。
谭春强，腾讯云后台工程师，拥有两年大数据EMR集群管控运维经验，目前负责腾讯云大数据EMR组件的容器化方向。
1.引言 随着云原生概念的兴起，越来越多的企业投身于云原生转型的浪潮，以解决传统应用面临的弹性能力不足、资源利用率较低、迭代周期较长等问题。通过云原生技术（如容器，不可变基础设施和声明式API等)，使得企业在公有云、私有云和混合云等云环境构建和运行应用变得更加容易，更能充分利用云环境的优势，加速了企业应用迭代、降低资源成本、提高系统容错性和资源弹性。 基于Hadoop生态的传统大数据系统，同样面临着弹性能力不足、资源利用率低，管理困难等问题，云原生技术天然适合解决这些问题。然而，将基于Hadoop生态的传统大数据系统改造成云原生架构，涉及到改造成本高、迁移风险大等诸多挑战。那有没有方案，既可以基于云原生技术解决大数据系统弹性能力不足，资源利用率低，管理困难等问题，又能保证改造成本、迁移风险比较低呢？腾讯云大数据团队和容器团队，基于大数据系统的现状，结合大数据技术和容器技术的特点，推出了渐进式的云原生演进方案。使用该方案，可以在较小改造成本和迁移风险的前提下，实现大数据系统的云原生化，充分利用云原生的优势。 本文依次分析了大数据系统当前面临的主要问题、云原生如何解决这些问题、大数据系统云原生改造面临的挑战，基于这些问题和调整，重点介绍了基于Hadoop Yarn on Kubernetes Pod（下文会详细介绍）的渐进式的云原生演进方案及其最佳实践。 2.大数据系统主要问题 传统的大数据系统围绕着Hadoop生态快速的发展，百花齐放，各个企业也逐步建立了自己的大数据平台，甚至是数据中台。然而，在激烈的市场竞争和不断增加的消费期望的双重驱动下，一方面业务需要快速迭代以满足迅速的增长，另一方面需要在资源需求不断增长的同时控制高昂的成本以保持企业的竞争力。这就要求大数据系统能够及时、快速的扩容以满足生产需求，又能尽可能的提高资源的使用效率，降低资源的使用成本。具体的问题体现在以下几点： 图1 大数据系统主要问题 以上提到的弹性扩缩容、应用发布效率和资源利用率，是当前大数据系统普遍存在的问题，如何解决和应对这些问题，越来越成为企业较为关心的话题。接下来，我们将从云原生的角度来分析如何解决这些问题。 3. 云原生技术如何解决大数据系统问题 云原生技术如何解决弹性扩容问题 : 在云原生架构中，应用程序及其依赖环境已经提前构建在镜像中，应用程序运行在基于该镜像启动的容器中。在业务高峰期，随着业务量的上升，向云原生环境申请容器资源，只需等待镜像下载完成即可启动容器（一般镜像下载时间也是秒级的），当容器启动后，业务应用将立即运行并提供算力，不存在虚拟机的创建、依赖软件安装和服务部署等耗时的环节。而在业务低峰期，删除闲置的容器，即可下线相应的应用程序，以节省资源使用的成本。借助云原生环境和容器技术，可以快速的获取容器资源，并基于应用镜像秒级启动应用程序，实现业务的快速启停，实时的扩缩容业务资源以满足生产需求。 云原生技术如何解决资源使用率低的问题 : 在传统架构中，大数据业务和在线业务往往部署在不同的资源集群中，这两部分业务相互独立。但大数据业务一般更多的是离线计算类业务，在夜间处于业务高峰，而在线业务恰恰相反夜间常常处于空载状态。云原生技术借助容器完整(CPU，内存，磁盘IO，网络IO等)的隔离能力，及Kubernetes强大的编排调度能力，实现在线和离线业务混合部署，从而使在离线业务充分利用在线业务空闲时段的资源，以提高资源利用率。 另外，使用无服务器(serverless)技术，通过容器化的部署方式，做到有计算任务需求时才申请资源，资源按需使用和付费，使用完之后及时退还资源，极大的增加了资源使用的灵活性，提升资源使用的效率，有效的降低了资源使用的成本。 云原生技术如何解决发布周期长的问题 : 传统大数据系统中，所有环境基本上使用同一个镜像，依赖环境比较复杂，部署、发布周期往往比较长。有时基础组件需要更新，因为需要重新构建镜像，并上传到各个地域，耗时可能长达数天。而云原生架构使用容器进行部署，应用的发布和基础组件的更新都只需要拉取新的镜像，重新启动容器，具有更新速度快的天然优势，并且不会有环境一致性的问题，可以加快应用发布的节奏，解决应用发布周期长的问题。 4. 大数据系统向云原生架构演进的挑战 云原生的技术虽然能解决当前大数据系统遇到的问题，然而，将大数据系统从传统的基于Hadoop生态的架构，迁移到云原生架构，将会面临一些挑战： 应用改造成本高 ：将运行在Hadoop平台的大数据应用迁移到云原生平台，一方面需要大数据团队将业务应用进行容器化改造，如系统任务的启动方式、基础设施的适配（环境变量、配置文件获取方式的变更等），这些都需要大数据团队来做适配，在资源管理的方式，则从适配Yarn修改为适配Kubernetes，总体改造成本比较高；另一方面，需要在大数据应用的资源申请层面进行改造，使其具备直接向Kubernetes集群申请资源的特性，也称为Native on Kubernetes。目前Apache Spark、Apache Flink已经从框架内核不同程度的支持了该特性，但整体的完整对依赖于社区的努力。迁移风险高 ：一次变更引入的改动越多，引发故障的几率也越多。在Hadoop领域，大数据应用的资源，由 Hadoop Yarn负责管理和调度，具体来说，大数据应用运行在Yarn提供的Container之中，这里的Container，是Yarn中资源的抽象，并非Linux Container，将其迁移至以容器为技术的云原生架构，跨越了底层基础架构，改动面比较大，风险相对也更高。 组织架构造成额外的成本 ：企业里负责开发和运维Hadoop系统的团队，和容器团队通常分属不同的部门，其技术栈也有明显区别，在迁移的过程中，存在过多的跨部门沟通，带来额外的迁移成本，如果改动比较大，跨部分沟通的成本会非常大。 由此可见，将大数据应用从传统Hadoop架构迁移至Kubernetes架构，并没有那么简单，尤其是依赖社区对大数据应用本身的改造，使其具备运行在云原生平台的能力，然而这些改造，非一朝一夕所能完成，仍需要大数据应用社区在云原生方向作出更多的努力。 5. 大数据系统云原生渐进式演进方案 5.1 渐进式演进方案简介 上文提到的大数据系统现存问题，云原生技术如何解决大数据系统的问题，以及大数据系统从传统架构迁移到云原生架构的挑战。那有没有一种方案既能解决大数据系统的问题，让大数据系统架构更加云原生。又可以降低迁移过程中的改造成本，规避迁移风险呢？ 接下来本文将介绍大数据系统渐进式向云原生演进的方案，通过渐进式迁移演进的方式，在架构较小改动的情况下，通过云原生技术解决大数据系统的问题。通过较小的投入，获得云原生技术的红利，并且避免迁移过程的的风险。同时后期还可以在这基础上进一步将大数据系统平滑演进到云原生架构。 渐进式演进方案主要有弹性扩缩容和离在线混合部署两种模式，两个模式的侧重点略有不同，弹性扩缩容主要聚焦于如何利用云原生资源，借助serverless技术，快速扩容资源以补充算力，满足业务实时需求。而离在线混部主要聚焦于利用在线业务空闲时段的闲置资源，通过将大数据离线计算任务调度到在线业务闲置资源的上，在保证业务稳定性的基础上，大幅提升资源的使用效率。这两种模式都使用了Yarn on Kubernetes Pod的形式，如下图，其基本思想是，将Yarn NodeManager运行在Kubernetes集群中新扩容的Pod容器内，当Yarn NodeManager Pod启动后，根据配置文件自动向已有的Hadoop集群的Yarn ResourceManager发起注册，最终以Kubernetes Pod的形式补充Yarn集群的算力。 图2 Yarn on Kubernetes Pod 5.2 渐进式演进之弹性扩缩容模式 在弹性扩缩容模式中，弹性扩缩容模块会根据大数据集群资源的使用情况，动态的向serverless Kubernetes集群申请(释放)资源。申请资源的具体形式为，在Kubernetes集群中创建(销毁)Yarn operator的自定义资源（CustomResourceDefinition,CRD)，集群中部署的Yarn-operator会根据crd资源来创建(删除) Yarn pod。在Yarn pod中会启动Yarn nodemanager进程，Yarn nodemanager进程启动后会自动向大数据集群中的Yarn resource-manager发起注册，扩充(减少)大数据集群的算力，满足任务的资源需求。 如图1所示，左侧是运行在腾讯云EMR（弹性MapReduce）系统上的大数据集群，右侧是腾讯云EKS（弹性容器服务）(Serverless Kubernetes)集群。 图3 弹性扩缩容方案（EMR大数据集群） 该方案的关键组件是Yarn-operator和Yarn-autoscaler。Yarn-autoscaler组件通过监听Yarn集群中资源使用的情况，作出扩容或者缩容的判断，然后向EKS集群创建Yarn-operaor crd资源。Yarn-operaor根据crd资源创建或删除对应的Yarn pod实例，这两个的组件的功能如下。 1）Yarn-operator Yarn-operator通过Kubernetes接口监听大数据集群管控平台中Yarn-autoscaler模块创建的crd资源。Yarn-opterator完成的主要功能包括： (1) 根据crd中的配置创建对应的Yarn pod; (2) 维护pod的生命周期，在pod出现异常时，自动重启pod;
(3) 指定pod进行缩容；
(4) 在pod启动失败时，标记启动失败。
其中pod异常恢复和固定pod name主要参考了kurbernetes statefulsets的设计思路，保证节点异常后能以同样的名称加入到Yarn集群。指定pod进行缩容，支持不受pod下标顺序的限制，删除任意的pod实例，对于关心集群拓扑结构的用户，操作空间更灵活。快速失败标记能够将将长时间未进入running状态的Pod主动删除，避免扩容流程长时间阻塞。 2）Yarn-autoscaler Yarn-autoscaler组件提供按负载和按时间弹性伸缩两种扩缩容方式。对于按负载伸缩，用户可以对不同指标设置阈值来触发扩缩容，比如设置Yarn root队列的availablevcore、pending vcore、available mem、pending mem等。当Yarn中的这些指标达到预设阈值时，Yarn-autoscaler将触发扩容过程，通过向EKS集群创建的Yarn-opterator的crd资源完成Yarn集群的扩容。 图4 扩缩容规则管理--负载伸缩
对于按时间弹性伸缩，用户可以设置不同的时间规则来触发扩缩容，比如设置一次性、按天、按周、按月重复的规则，当规则触发后，进行弹性扩缩容流程，通过创建(删除)EKS集中的Yarn-opterator的crd资源来完成Yarn集群算力的增减。 图5 扩缩容规则管理--时间伸缩 另外对于云上客户自建的大数据集群，也可以通过将集群导入到EMR的管系统形式来实现弹性扩缩容，提升资源使用的效率。具体的只需在每个节点安装EMR agent组件，然后EMR团队在后台增加对应的集群信息，即可以完成集群的导入。EMR agent本身对集群无任何侵入，消耗的资源也比较小(CPU 消耗小于0.1核，内存消耗小于150M)，主要做监控指标采集，日志采集，集群心跳上报等工作。安装完agent后，集群将完整的被EMR管控系统纳管，客户不仅可以使用弹性扩缩容的能力，还可以在既使用自身日志监控的能力的同时使用EMR提供的日志监控能力。后续也可以持续享受EMR提供的各种能力。 图6 弹性扩缩容方案（用户自建集群导入EMR管控系统）
5.3 渐进式演进之在离线混部模式 对于在离线混部模式，节点上的agent组件基于监控统计cpu和内存的真实使用情况，这些统计信息由一个server统一收集，大数据管控平台通过该server，获取当前在线集群中可以提供的闲置算力的规格及数量，调用Kubernetes api创建对应数量的资源，ex-scheduler扩展调度器确保Pod被创建在剩余资源更多的节点上，其中申请资源的具体形式与弹性扩缩容模式中相同，由Yarn operator根据crd资源创建(删除)Yarn pod。 图7 在离线混部方案 如上图所示，左侧是TKE(腾讯云容器服务)集群，右侧是EMR大数据集群。在线业务具有明显的波峰浪谷特征，而且规律比较明显，尤其是在夜间，资源利用率比较低，这时候大数据管控平台向Kubernetes集群下发创建资源的请求，可以提高大数据应用的算力。这里主要通过四个组件来实现，recomm-agent、recomm-server、ex-scheduler和Yarn-operator。 ceres-agent从prometheus(node-exporter、telegraf) 读取节点的cpu idle信息，作为可以超卖的cpu数量，并通过node节点的可分配内存-总体请求内存作为空闲memory数量，并将计算结果patch到Node节点的node.status.capacity字段； ceres-server汇总ceres-agent在各节点patch的可超卖cpu和memory信息，根据http client提供的pod规格，返回可以支持的pod的数量； ex-scheduler是基于Kubernetes scheduler extender实现的一个扩展调度器，相对于Yarn调度器，Kuberentes调度器具有更细的调度粒度，比如以milli-cores为单位进行CPU资源的调度，如500m，表示0.5个cpu、以bytes为单位进行内存资源的调度等，更细的粒度通常能带来更好的资源使用率。该调度器在score打分环节，根据待调度的pod中声明的squeezed-cpu以及ceres-agent在节点的node.status.capacity写入的squeezed-cpu，来决定Node的分值，空闲资源越多的节点，打分越高，从而筛选出实际资源空闲最多的节点。
Yarn-opterator的主要作用是根据crd资源，动态创建(删除)pod，功能和弹性扩容模式中的Yarn-opterator一样，这里就不再重复介绍。
5.4 渐进式演进方案如何解决大数据系统的问题 以上两种方案，解决了文章开始提到的一系列问题和挑战。借助渐进式演进的方案，既能解决大数据系统的问题和迁移的挑战，让大数据系统架构更加云原生，充分利用云原生的能力，又可以降低迁移过程中的改造成本，尽可能的规避迁移风险，其主要体现在以下几个方面： 6. 大数据系统云原生渐进式演进最佳实践 6.1 基于EKS的弹性扩缩容最佳实践 图8 用户最佳实践--弹性扩容缩容 该用户基于Hadoop Yarn自建了大数据集群，包含多种组件，如Spark、Flink、Hive等，当前遇到的主要问题是，面对临时的突发流量，如何快速的扩容以提高算力，并且在计算完成后，如何实时的释放资源以解决成本。借助腾讯云EKS的serverless能力，我们实现的快速自动扩缩容方案，正好可以满足该用户的诉求。 在控制台上，用户使用我们提供的自动扩缩容的配置策略，自由配置自动扩容、缩容的触发阈值。比如配置当剩余CPU或者内存小于指定的值时，Yarn弹性伸缩组件会调用EKS Kubernetes API创建Yarn NodeManager Pod，容器启动后自动注册到Yarn ResourceManager，从而提供算力；当触发了用户配置的缩容策略时，如剩余CPU或者内存大于指定的值时，Yarn弹性伸缩组件同样会调用EKS Kubernetes API缩容Yarn NodeManager Pod，整个过程中无需用户创建虚拟机，计费方式以Pod的CPU和内存为基础，真正的达到资源随用随建，按需付费。 6.2 混合云弹性基于TKE的在离线混部最佳实践 图9 用户最佳实践--离在线混部 该客户大数据应用和存储跑在Yarn管理的大数据集群，在生产环境中，面临诸多问题，主要体现在大数据的算力不足和在线业务波谷时资源的浪费。如离线计算在算力不足时，数据准时性无法得到保证，尤其是当遇到随机紧急大数据查询任务，没有可用的计算资源，只能停掉已有的计算任务，或者等已有任务完成，无论哪种方式，总体任务执行的效率都会大打折扣。 基于TKE的在离线混部方案，将离线任务自动扩容至云上集群，与在线业务混合部署，充分利用云上波谷时段的闲置资源，提高离线业务的算力，并利用云上资源快速的弹性扩容能力，及时补充离线计算的算力。简单来说，该方案提供了三种使用方式: 根据在线业务的波谷时段，配置定时扩容任务，在定时任务指定的时间到达时，调用TKE Kubernetes API，提交扩容请求，Yarn NodeManager则会以Pod的形式被Kubernetes创建出来，并且根据镜像里事先准备好的配置，自动向Yarn ResourceManager注册，从而提供算力资源。该方案帮助用户提高在线集群利用率的同时，提高了离线集群的算力； 大数据管控平台也可以直接向TKE Kubernetes API发送扩展指令，以应对临时的紧急大数据查询任务，避免算力不足带来的任务无法启动，从而提高系统SLA； 用户可以在控制台上配置自动扩缩容策略，结合Ceres Server\Client资源预测，将Yarn NodeManager创建在合适的节点上。 7. 总结 本文提出了大数据云原生渐进式演进的理念和最佳实践，在极大减少改造成本、降低迁移风险的基础上，解决了大数据应用当前面临的主要问题。在未来，我们将基于最小化迁移风险、最低改造成本等原则，设计并落地更多方案，使大数据应用更原生的跑在云原生架构上，为企业带来更多的便利和实际收益。 附录
如果提示本群已满
请扫描下方二维码添加小助手拉你进群
记得备注入群暗号“ 大数据云原生 ”哦