基于Hadoop生态的传统大数据系统，同样面临着弹性能力不足、资源利用率低，管理困难等问题，云原生技术天然适合解决这些问题。然而，将基于Hadoop生态的传统大数据系统改造成云原生架构，涉及到改造成本高、迁移风险大等诸多挑战。那有没有方案，既可以基于云原生技术解决大数据系统弹性能力不足，资源利用率低，管理困难等问题，又能保证改造成本、迁移风险比较低呢？腾讯云大数据团队和容器团队，基于大数据系统的现状，结合大数据技术和容器技术的特点，推出了渐进式的云原生演进方案。使用该方案，可以在较小改造成本和迁移风险的前提下，实现大数据系统的云原生化，充分利用云原生的优势。
本文依次分析了大数据系统当前面临的主要问题、云原生如何解决这些问题、大数据系统云原生改造面临的挑战，基于这些问题和调整，重点介绍了基于HadoopYarnonKubernetesPod（下文会详细介绍）的渐进式的云原生演进方案及其最佳实践。
传统的大数据系统围绕着Hadoop生态快速的发展，百花齐放，各个企业也逐步建立了自己的大数据平台，甚至是数据中台。然而，在激烈的市场竞争和不断增加的消费期望的双重驱动下，一方面业务需要快速迭代以满足迅速的增长，另一方面需要在资源需求不断增长的同时控制高昂的成本以保持企业的竞争力。这就要求大数据系统能够及时、快速的扩容以满足生产需求，又能尽可能的提高资源的使用效率，降低资源的使用成本。具体的问题体现在以下几点：
图1大数据系统主要问题
以上提到的弹性扩缩容、应用发布效率和资源利用率，是当前大数据系统普遍存在的问题，如何解决和应对这些问题，越来越成为企业较为关心的话题。接下来，我们将从云原生的角度来分析如何解决这些问题。
云原生技术如何解决资源使用率低的问题:在传统架构中，大数据业务和在线业务往往部署在不同的资源集群中，这两部分业务相互独立。但大数据业务一般更多的是离线计算类业务，在夜间处于业务高峰，而在线业务恰恰相反夜间常常处于空载状态。云原生技术借助容器完整(CPU，内存，磁盘IO，网络IO等)的隔离能力，及kubernetes强大的编排调度能力，实现在线和离线业务混合部署，从而使在离线业务充分利用在线业务空闲时段的资源，以提高资源利用率。
另外，使用无服务器(serverless)技术，通过容器化的部署方式，做到有计算任务需求时才申请资源，资源按需使用和付费，使用完之后及时退还资源，极大的增加了资源使用的灵活性，提升资源使用的效率，有效的降低了资源使用的成本。
云原生技术如何解决发布周期长的问题:传统大数据系统中，所有环境基本上使用同一个镜像，依赖环境比较复杂，部署、发布周期往往比较长。有时基础组件需要更新，因为需要重新构建镜像，并上传到各个地域，耗时可能长达数天。而云原生架构使用容器进行部署，应用的发布和基础组件的更新都只需要拉取新的镜像，重新启动容器，具有更新速度快的天然优势，并且不会有环境一致性的问题，可以加快应用发布的节奏，解决应用发布周期长的问题。
云原生的技术虽然能解决当前大数据系统遇到的问题，然而，将大数据系统从传统的基于Hadoop生态的架构，迁移到云原生架构，将会面临一些挑战：
由此可见，将大数据应用从传统Hadoop架构迁移至Kubernetes架构，并没有那么简单，尤其是依赖社区对大数据应用本身的改造，使其具备运行在云原生平台的能力，然而这些改造，非一朝一夕所能完成，仍需要大数据应用社区在云原生方向作出更多的努力。
上文提到的大数据系统现存问题，云原生技术如何解决大数据系统的问题，以及大数据系统从传统架构迁移到云原生架构的挑战。那有没有一种方案既能解决大数据系统的问题，让大数据系统架构更加云原生。又可以降低迁移过程中的改造成本，规避迁移风险呢？
接下来本文将介绍大数据系统渐进式向云原生演进的方案，通过渐进式迁移演进的方式，在架构较小改动的情况下，通过云原生技术解决大数据系统的问题。通过较小的投入，获得云原生技术的红利，并且避免迁移过程的的风险。同时后期还可以在这基础上进一步将大数据系统平滑演进到云原生架构。
渐进式演进方案主要有弹性扩缩容和离在线混合部署两种模式，两个模式的侧重点略有不同，弹性扩缩容主要聚焦于如何利用云原生资源，借助serverless技术，快速扩容资源以补充算力，满足业务实时需求。而离在线混部主要聚焦于利用在线业务空闲时段的闲置资源，通过将大数据离线计算任务调度到在线业务闲置资源的上，在保证业务稳定性的基础上，大幅提升资源的使用效率。这两种模式都使用了YarnonKubernetesPod的形式，如下图，其基本思想是，将YarnNodeManager运行在Kubernetes集群中新扩容的Pod容器内，当YarnNodeManagerPod启动后，根据配置文件自动向已有的Hadoop集群的YarnResourceManager发起注册，最终以KubernetesPod的形式补充Yarn集群的算力。
图2YarnonKubernetesPod
在弹性扩缩容模式中，弹性扩缩容模块会根据大数据集群资源的使用情况，动态的向serverlessKubernetes集群申请(释放)资源。申请资源的具体形式为，在Kubernetes集群中创建(销毁)Yarnoperator的自定义资源（CustomResourceDefinition,CRD)，集群中部署的Yarn-operator会根据crd资源来创建(删除)Yarnpod。在Yarnpod中会启动Yarnnodemanager进程，Yarnnodemanager进程启动后会自动向大数据集群中的Yarnresource-manager发起注册，扩充(减少)大数据集群的算力，满足任务的资源需求。
图3弹性扩缩容方案（EMR大数据集群）
该方案的关键组件是Yarn-operator和Yarn-autoscaler。Yarn-autoscaler组件通过监听Yarn集群中资源使用的情况，作出扩容或者缩容的判断，然后向EKS集群创建Yarn-operaorcrd资源。Yarn-operaor根据crd资源创建或删除对应的Yarnpod实例，这两个的组件的功能如下。
Yarn-operator通过kubernetes接口监听大数据集群管控平台中Yarn-autoscaler模块创建的crd资源。Yarn-opterator完成的主要功能包括：
(1)根据crd中的配置创建对应的Yarnpod;(2)维护pod的生命周期，在pod出现异常时，自动重启pod;(3)指定pod进行缩容(4)在pod启动失败时，标记启动失败。
图4扩缩容规则管理--负载伸缩
另外对于云上客户自建的大数据集群，也可以通过将集群导入到EMR的管系统形式来实现弹性扩缩容，提升资源使用的效率。具体的只需在每个节点安装EMRagent组件，然后EMR团队在后台增加对应的集群信息，即可以完成集群的导入。EMRagent本身对集群无任何侵入，消耗的资源也比较小(CPU消耗小于0.1核，内存消耗小于150M)，主要做监控指标采集，日志采集，集群心跳上报等工作。安装完agent后，集群将完整的被EMR管控系统纳管，客户不仅可以使用弹性扩缩容的能力，还可以在既使用自身日志监控的能力的同时使用EMR提供的日志监控能力。后续也可以持续享受EMR提供的各种能力。
图6弹性扩缩容方案（用户自建集群导入EMR管控系统）
对于在离线混部模式，节点上的agent组件基于监控统计cpu和内存的真实使用情况，这些统计信息由一个server统一收集，大数据管控平台通过该server，获取当前在线集群中可以提供的闲置算力的规格及数量，调用Knetesapi创建对应数量的资源，ex-scheduler扩展调度器确保Pod被创建在剩余资源更多的节点上，其中申请资源的具体形式与弹性扩缩容模式中相同，由Yarnoperator根据crd资源创建(删除)Yarnpod。
图7在离线混部方案
图8用户最佳实践--弹性扩容缩容
该用户基于HadoopYarn自建了大数据集群，包含多种组件，如Spark、Flink、Hive等，当前遇到的主要问题是，面对临时的突发流量，如何快速的扩容以提高算力，并且在计算完成后，如何实时的释放资源以解决成本。借助腾讯云EKS的serverless能力，我们实现的快速自动扩缩容方案，正好可以满足该用户的诉求。
在控制台上，用户使用我们提供的自动扩缩容的配置策略，自由配置自动扩容、缩容的触发阈值。比如配置当剩余CPU或者内存小于指定的值时，Yarn弹性伸缩组件会调用EKSKubernetesAPI创建YarnNodeManagerPod，容器启动后自动注册到YarnResourceManager，从而提供算力；当触发了用户配置的缩容策略时，如剩余CPU或者内存大于指定的值时，Yarn弹性伸缩组件同样会调用EKSKubernetesAPI缩容YarnNodeManagerPod，整个过程中无需用户创建虚拟机，计费方式以Pod的CPU和内存为基础，真正的达到资源随用随建，按需付费。
图9用户最佳实践--离在线混部
某客户大数据应用和存储跑在Yarn管理的大数据集群，在生产环境中，面临诸多问题，主要体现在大数据的算力不足和在线业务波谷时资源的浪费。如离线计算在算力不足时，数据准时性无法得到保证，尤其是当遇到随机紧急大数据查询任务，没有可用的计算资源，只能停掉已有的计算任务，或者等已有任务完成，无论哪种方式，总体任务执行的效率都会大打折扣。
基于TKE的在、离线混部方案，将离线任务自动扩容至云上集群，与在线业务混合部署，充分利用云上波谷时段的闲置资源，提高离线业务的算力，并利用云上资源快速的弹性扩容能力，及时补充离线计算的算力。简单来说，该方案提供了三种使用方式:
本文提出了大数据云原生渐进式演进的理念和最佳实践，在极大减少改造成本、降低迁移风险的基础上，解决了大数据应用当前面临的主要问题。在未来，我们将基于最小化迁移风险、最低改造成本等原则，设计并落地更多方案，使大数据应用更原生的跑在云原生架构上，为企业带来更多的便利和实际收益。