【大数据云原生系列】大数据系统云原生渐进式演进最佳实践

1.引言

随着云原生概念的兴起，愈来愈多的企业投身于云原生转型的浪潮，以解决传统应用面临的弹性能力不足、资源利用率较低、迭代周期较长等问题。经过云原生技术（如容器，不可变基础设施和声明式API等)，使得企业在公有云、私有云和混合云等云环境构建和运行应用变得更加容易，更能充分利用云环境的优点，加速了企业应用迭代、下降资源成本、提升系统容错性和资源弹性。

基于Hadoop生态的传统大数据系统，一样面临着弹性能力不足、资源利用率低，管理困难等问题，云原生技术自然适合解决这些问题。然而，将基于Hadoop生态的传统大数据系统改形成云原生架构，涉及到改形成本高、迁移风险大等诸多挑战。那有没有方案，既能够基于云原生技术解决大数据系统弹性能力不足，资源利用率低，管理困难等问题，又能保证改形成本、迁移风险比较低呢？腾讯云大数据团队和容器团队，基于大数据系统的现状，结合大数据技术和容器技术的特色，推出了渐进式的云原生演进方案。使用该方案，能够在较小改形成本和迁移风险的前提下，实现大数据系统的云原生化，充分利用云原生的优点。

本文依次分析了大数据系统当前面临的主要问题、云原生如何解决这些问题、大数据系统云原生改造面临的挑战，基于这些问题和调整，重点介绍了基于Hadoop Yarn on Kubernetes Pod（下文会详细介绍）的渐进式的云原生演进方案及其最佳实践。

2.大数据系统主要问题

传统的大数据系统围绕着Hadoop生态快速的发展，百花齐放，各个企业也逐步创建了本身的大数据平台，甚至是数据中台。然而，在激烈的市场竞争和不断增长的消费指望的双重驱动下，一方面业务须要快速迭代以知足迅速的增加，另外一方面须要在资源需求不断增加的同时控制高昂的成本以保持企业的竞争力。这就要求大数据系统可以及时、快速的扩容以知足生产需求，又能尽量的提升资源的使用效率，下降资源的使用成本。具体的问题体如今如下几点：

• 弹性扩缩容能力没法知足快速增加的业务需求：随着业务的发展，流量和数据量突增，尤为对于实时计算，须要资源可以及时的扩容，以知足业务需求。尽管一些大数据管控平台尝试实现自动的扩缩容（如经过集群负载状况，进行扩容），然而，在传统大数据平台架构下，一般须要资源申请、依赖软件安装、服务部署等一系列步骤，该过程一般比较慢，对于集群负载的缓解，不够及时。
• 在离线分离部署及粗粒度调度没法提升资源的利用率：在传统Hadoop架构下，离线做业和在线做业每每分属不一样的集群，然而在线业务、流式做业具备明显的波峰波谷特性，在波谷时段，会有大量的资源处于闲置状态，形成资源的浪费和成本的提高。在离线混部集群，经过动态调度削峰填谷，当在线集群的使用率处于波谷时段，将离线任务调度到在线集群，能够显著的提升资源的利用率。然而，Hadoop Yarn目前只能经过NodeManager上报的静态资源状况进行分配，没法基于动态资源调度，没法很好的支持在线、离线业务混部的场景。
• 操做系统镜像及部署复杂性拖慢应用发布：虚拟机或裸金属设备所依赖的镜像，包含了诸多软件包，如HDFS、Spark、Flink、Hadoop等，系统的镜像远远大于10GB，一般存在镜像过大、制做繁琐、镜像跨地域分发周期长等问题。基于这些问题，有些大数据开发团队不得不将需求划分为镜像类和非镜像类需求，当须要修改镜像的需求积累到必定程度，才统一进行发布，迭代速度受限，当遇到用户紧急且须要修改镜像的需求时，势必面临很大的业务压力。同时，购买资源后，应用的部署涉及到依赖部署、服务部署等环节，进一步拖慢应用的发布。

​ 图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，获取当前在线集群中能够提供的闲置算力的规格及数量，调用Knetes 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 渐进式演进方案如何解决大数据系统的问题

以上两种方案，解决了文章开始提到的一系列问题和挑战。借助渐进式演进的方案，既能解决大数据系统的问题和迁移的挑战，让大数据系统架构更加云原生，充分利用云原生的能力，又能够下降迁移过程当中的改形成本，尽量的规避迁移风险，其主要体如今如下几个方面：

• 在弹性扩缩容和资源申请方面，借助基于Kubernetes的serveless服务，作到资源按需建立、按需使用和付费；而资源的调度方式，则依然保证不变。具体来讲，Kubernetes只是资源的提供方，只提供建立和销毁资源的API，业务方负责调用该API来建立和销毁资源，资源在Kubernetes上建立完成以后，该资源的Yarn NodeManager组件自动向Yarn ResourceManager注册，以Kubernetes Pod的形式提供算力，后续执行做业时涉及到的资源调度，依然由Yarn负责。
• 在镜像和发布周期方面，容器镜像技术精简了应用的运行环境，镜像只需提供应用必须的依赖环境，使其存储空间获得了极大的减小，上传和下载镜像的时间变的更短，快速启动和销毁变的很容易，整体极大的缩短了应用的发布周期。
• 在资源利用率方面，借助云原生架构的技术能力，多方位提高系统的资源利用率，如细粒度调度（将CPU和内存这两个核心资源划分的更细，从而更充分的分配系统资源）、动态调度（基于节点真实负载状况，而非静态划分的资源，将任务调度到已分配了资源可是未实际使用的节点上，从而更充分的提升系统算力），在离线混部（根据离线任务和在线任务的周期性，削峰填谷，从而充分利用系统闲置资源）。
• 在应用改形成本、迁移风险和组织架构方面：经过渐进式的迁移，大数据应用团队无需改造既有架构，只需制做当前所用的Hadoop版本的镜像，便可完成在Kubernetes上建立容器资源补充算力，这种方式，能够最低程度的减小变动，从而尽量的下降迁移风险，与此同时，大数据团队保证Yarn资源调度和使用，容器团队保证Yarn pod的稳定运行，分工明确，能最大限度的保证系统的稳定性。

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的在、离线混部方案，将离线任务自动扩容至云上集群，与在线业务混合部署，充分利用云上波谷时段的闲置资源，提升离线业务的算力，并利用云上资源快速的弹性扩容能力，及时补充离线计算的算力。简单来讲，该方案提供了三种使用方式:

1. 根据在线业务的波谷时段，配置定时扩容任务，在定时任务指定的时间到达时，调用TKE Kubernetes API，提交扩容请求，Yarn NodeManager则会以Pod的形式被Kubernetes建立出来，而且根据镜像里事先准备好的配置，自动向Yarn ResourceManager注册，从而提供算力资源。 该方案帮助用户提升在线集群利用率的同时，提升了离线集群的算力；
2. 大数据管控平台也能够直接向TKE Kubernetes API发送扩展指令，以应对临时的紧急大数据查询任务，避免算力不足带来的任务没法启动，从而提升系统SLA；
3. 用户能够在控制台上配置自动扩缩容策略，结合Ceres ServerClient资源预测，将Yarn NodeManager建立在合适的节点上。

7. 总结

本文提出了大数据云原生渐进式演进的理念和最佳实践，在极大减小改形成本、下降迁移风险的基础上，解决了大数据应用当前面临的主要问题。在将来，咱们将基于最小化迁移风险、最低改形成本等原则，设计并落地更多方案，使大数据应用更原生的跑在云原生架构上，为企业带来更多的便利和实际收益。

【腾讯云原生】云说新品、云研新术、云游新活、云赏资讯，扫码关注同名公众号，及时获取更多干货！！