乐趣区

关于腾讯云:大数据云原生系列大数据系统云原生渐进式演进最佳实践

jiezi

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. 总结

本文提出了大数据云原生渐进式演进的理念和最佳实际，在极大缩小革新老本、升高迁徙危险的根底上，解决了大数据利用以后面临的次要问题。在将来，咱们将基于最小化迁徙危险、最低革新老本等准则，设计并落地更多计划，使大数据利用更原生的跑在云原生架构上，为企业带来更多的便当和理论收益。

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

退出移动版