目录

大数据云原生化的机遇和挑战

1.大数据云原生化的现状

2.云原生大数据的挑战

腾讯云原生大数据架构

1.峰峦云原生大数据底座

2.峰峦云原生引擎层

3.峰峦云原生调度层

4.峰峦云原生混部

5.峰峦云原生运行时

总结与展望

---

大数据云原生化的机遇和挑战

1.大数据云原生化的现状

大数据的发展经历了四个阶段，首先最早是单机单引擎阶段，像SQL引擎这种，接下来过渡到分布式计算的第二阶段，这一阶段以商业化的引擎为主，第三阶段就是近十几年比较火的Hadoop开源生态体系，极大促进开开源大数据的发展，但是本身还存在很多痛点，因为Hadoop体系相对独立跟在线资源无法共享，并且运维过于复杂，因此随着云原生化的发展，大数据计算引擎Spark、Flink，包括机器学习引擎和OLAP引擎等都开始向云原生化进行靠拢，kubernetes成为资源调度的事实标准，也就是进入到第四阶段，这一阶段当前也存在问题，像是存算分离、Shuffle机制、数据集成等技术还在不断演进。

云原生为大数据带来了三个方面的优势：

• 最主要的优势就是在成本上的节约，大数据集群可以利用云原生弹性做到按需创建，实现Cluster Auto-Scale的弹性伸缩能力，减少了资源成本；另一点就是通过云原生统一资源的申请和运营模式，将离线资源和在线资源进行混部，更充分的利用资源。处理资源成本降低以外还有技术成本，比如统一技术栈还有自动化部署等都会节约一定的人力成本。

• 第二方面是效率上的提升，之前Hadoop体系更多的依赖独立的部署组件和人工操作，发布周期和标准化流程效率都比较低，在云原生体系下，基于kubernetes声明式API的思想，直接利用程序指导系统的发布和升级，包括监控、日志底层组件也可以和在线复用，达到开发效率和发布效率的双重提升。

• 最后是可用性的提升，大数据可以结合云原生技术做自动容灾，资源隔离能力增强，以及在线升级能力提升等。

2.云原生大数据的挑战

云原生大数据除了带来以上几点优势以外，当前还存在一些问题，由于云原生技术最早是服务在线系统的，跟大数据系统不同，在线系统通常运行周期会很长，对于调度要求比较低，资源弹性要求也不高，而大数据都是一些跑完就结束的短时任务，任务之间也会有依赖，对于资源弹性要求比较高。此外在线业务对延迟是非常敏感的，很多业务都需要按照高峰期要求配置一些冗余资源保证在任何情况下在线SLA 延迟不受影响，但是大数据应用不那么关注某一时刻的延迟情况。最后一点就是存算分离的特点，在线业务本身就是存算分离的，服务层是无状态的设计。而大数据因为数据计算量很大，会利用数据本地性加速任务的运行。总结以上现状，云原生大数据存在三方面的挑战：

• 第一点就是弹性和调度相关的要求，云原生调度默认是静态资源配额管理，大数据则以离线任务为主，动态资源管理以及吞吐是强需求。

• 第二点是规模挑战，在线业务以 API Server 为中心的这种消息同步机制，因为所有状态都要落盘的设计模式，限制了基础调度的吞吐上限。

• 第三点主要是对大数据的架构挑战，包括存算分离、在离线混部、以及运行时的改造等，为了适应云原生化在大数据侧都需要做相关的工作。

腾讯云原生大数据架构

1.峰峦云原生大数据底座

腾讯峰峦云原生大数架构如下图：

最上层是各种大数据以及AI 的应用，包括腾讯内部的天穹大数据体系中的流计算、批计算、OLAP、SuperSQL引擎等，然后就是以Tensorflow为主自研AI引擎太极机器学习平台，以及公有云大数据的实时数仓、EMR、Impala等大数据服务，在云原生化后都统一生长在峰峦底座上。

中间层是峰峦云原生大数据底座层，其内部又分为三层：

• 第一层对引擎做了云原生的改造，包括引擎本身、基于Alluxio缓存机制加速、对shuffle的支持、可观测性建设、本地资源的管理、以及结合业务和资源特点的autopolit实现；

• 第二层是核心的云原生调度层，峰峦是以及虚拟集群的管控机制，对于调度的功能和性能都做了针对性优化，包括拓扑调度、gang调度，并支持了资源池弹性，此外峰峦还同时支持内网和公有云的通用需求；

• 第三层包括对大数据业务混部的支持和大数据运行时两部分，大数据业务混部支持调度感知、资源隔离等，然后是在云原生后对Runtime进行容器化，在容器化的过程中做一些运行时的增强，包括容器的热迁移、内存压缩、用户态内核安全性的增强等。

最底层是基础设施层，计算资源包括离线的独占资源区、共享资源区和其他资源区，存储包括基于HDFS 的分布式文件系统和基于COS的对象存储。

2.峰峦云原生引擎层

传统Hadoop生态系统中，Yarn、Flink计算引擎基于Yarn进行资源调度，而Presto等OLAP引擎则基于CVM部署，计算资源之间是相对静态的，资源池不能复用。计算任务在读取HDFS数据以后，通过Map阶段做映射处理后溢写到本地盘，然后通过shuffle形式把数据分发到Reduce进行处理。

在云原生体系下采用Spark、Flink采用 native k8s模式，Presto采用Operator模式，使得他们能够同时跑在k8s的统一资源池上，通过scheduler和算力感知的优化提升资源使用效率。

云原生下由于存算资源分离的思想计算引擎shuffle阶段，部分计算节点无法提供较大的本地存储空间，因此必须对传统的shuffle框架进行改造。在腾讯内部则实现了一套Shuffle Service框架来解决本地落盘的问题，当前这套系统也已经开源。

在存储侧云原生大数据需要能够对接HDFS、对象存储等多种存储系统，腾讯内部也做了一套DOP的统一存储层进行数据编排，对上层提供统一的Meta信息和访问接口，并提供cache机制进行读写性能增强。

基于原生shuffle框架依赖本地磁盘，落盘过程中对数据排序频繁的磁盘IO，以及大任务数据倾斜时导致stage频繁失败等痛点，Remote Shuffle Service框架在map以后直接把数据推送到远端，可以直接落在内存、Shuffle Service的本地盘或者HDFS上，远端的Reducer任务通过Shuffle Service拉取对应数据，无需依赖计算节点本地盘存储。

对两种shuffle进行Benchmark基础数据测试结果显示，在1TB数据规模下RSS的性能相比ESS提升不明显，但随着数据量扩大，Shuffle开销占整个应用时间会越来越长，RSS相比ESS性能会有明显的提升。对于Shuffle密集型任务RSS的失败率下降了5%，大作业性能提升了20%。

峰峦云原生引擎层还实现了统一任务管理，Spark、Flink等计算引擎在Native实现时直接由Driver或Master启动Pod，对于计算资源的把控性和灵活性有一定的增强，但由于k8s调度层直接看到是 Pod 信息，缺少application的视角，因此我们做了App Master来watch API Server的任务状态来实现任务生命周期管理功能，并提供任务画像、依赖管理、网络转发等增强能力。另外在节点侧部署峰峦Agent进行本地磁盘管理，将之前Hadoop体系上的磁盘资源进行利旧。

下面是一个峰峦和引擎联动的例子，SuperSQL是腾讯内部的SQLsuper Gateway，用户提交的SQL会进行自动翻译，然后根据SQL本身的特点调度到Spark或者Presto集群上。在峰峦侧的Presto这一层我们做了HA相关的能力，因为olap查询一般白天会多一些，晚上下班以后用户会把大SQL跑在Spark 上，云原生底座提供的弹性能力机制会把这两种不同的计算资源打通做quota共享，然后进行自动扩缩容，空闲时间缩出来的资源就可以提供给Spark应用使用。另外我们在Presto Coordinate上还做了节点算力感知的功能，在公共集群使用SLA保障性较低的资源时，可以自动对Presto算力进行干预，使用此功能在达到相同性能的情况下成本节约了35%。

3.峰峦云原生调度层

峰峦的核心思想就是虚拟集群，虚拟集群的架构可以分为三层，其中最上层是Tenant logical Cluster租户集成，直接暴露给外部用户；中间层是Meta Cluster，负责整个管控的工作，包括Cluster Controller、proxy-apiserver、syncer、resource-balancer这些组件；最下层是物理集群Cluster，与上层Tenant Cluster是多对多的关系，用户从上层看到的一个Cluster可能底层对应多个物理cluster的节点，通过这种跨物理集群调度机制解决了在作业和资源总量一定的情况下多个小集群的碎片造成的资源浪费问题。

虚拟集群的调度方案某种程度实现了负载的上下层拆分，用户关心的负载主要在上层的租户集群管理，底层相关的资源负载都是通过物理集群管理，这样就做到了压力的分摊。

这里以一个spark任务的执行为例，用户在Tenant集群提交一个Spark任务，在k8s集群上会启动了一个 driver pod，然后调度器会根据与该Tenant相关的所有物理集群负载情况进行调度，接着Syncer会把这个pod同步到物理集群上，物理资源启动以后会Pod status反向同步到Tenent，同时driver连接的API Server也会修改到Tenent的API master上，最后新申请的Executor Pod。

Driver的负载情况通过上层Tenent管理，底层的Pod状态等通过物理集群管理，这样就把业务关心的负载信息和真正底层平台运行的负载进行了拆分，在上层也会隐藏vnode 和vpod的状态，压缩上层apiserver 的内存资源占用量。

通过隐藏不必要的状态和下沉职责到物理集群的手段，有效地减轻所有组件对API Server 访问的压力，以及 API Server 本身的需要处理的数据量，做到对大规模集群的支持。

峰峦调度层针对多集群支持也做了一些优化，主要涉及Proxy ApiServer和Syncer两个核心组件：

• 当一个pod在虚拟集群提交后，Syncer组件会把 Pod 以及跟 Pod 相关的这些资源，比如configmap、Secret等同步到其中一个物理集群，Pod进程启动以后status信息也会往上同步回虚拟集群，而像configmap、Secret信息没有发生变化则不需要同步。另外因为node的状态和信息是由底层物理集群管理，因此NODE信息会以vnode形式同步到上层，方便用户系统管理相关的操作。

• 虚拟集群在调度时需要知道Pod调用到哪个集群，那么调度器层需要能看到所有集群的信息，这时就要通过Proxy ApiServer来监听所有物理集群的node和Pod 的状态，在在线和离线任务同时执行场景下，Proxy ApiServer自动扣除agent及在线pod自身占用的资源，就可以看到所纳管集群所有物理节点的信息了。

在隔离层面公有云场景需求会更强烈，虚拟集群之间会独占管控面，比如公有云上两个用户，用户A安装自己的operator，完全不会影响到用户B，因为workload层的信息都是在虚拟集群做统一管理，因此说虚拟集群架构对于租户是强隔离的。

峰峦自研调度器突破原生Quota限制，实现类似队列领域弹性概念的业务弹性，还具备集群弹性能力在不同虚拟集群之间自动balance资源调配，利用Fair Share算法公平分配、按需借用、总量控制，打破集群资源边界。

4.峰峦云原生混部

腾讯内部基于Caelus组件实现全场景在离线混部，最上层master做全局的混部管理，中间是组件模块，可以分为资源画像、干扰检测、指标收集几个部分，底层是一些内核的技术支持。

在Runtime 层我们设计的核心是不侵入kubelet进行改造，因此更多的使用Hook方式，Hook的方式选择在这个OCI层。对离线提交的业务相关信息做统一的管理，统一横向的整体使用资源。

在干扰检测的处理上涉及混部整合流程的处理，在线和离线任务运行的时候会，混部框架会进行指标收集和干扰检测，然后进行行为处理，比如识别到干扰后禁止调度、调度感知、驱逐等相关操作。

指标检测主要基于容器和节点的指标，最近我们还做了基于eBPF的指标检测，首先收集节点本身eBPF的内核信息，然后在混部实现阶段把内核信息和业务真正的指标进行对比，分析出哪些内核指标和业务指标有相关性。最后在真正上线阶段，直接依赖内核指标的异常状况，判断业务可能有干扰，然后做一些压制。而且在整个流程的灰度过程中，我们的峰峦平台会进行同步处理，不需要用户一些额外的认知识别复杂操作。

5.峰峦云原生运行时

在峰峦运行时侧有两个比较有特点的功能，分别是热迁移和内存压缩。

在混部集群上运行任务的时候，可能某个时间在线流量比较多，那么就要对离线任务进行压制甚至驱逐，但是驱逐对离线用户是有一定伤害的，因此我们在峰峦运行时提供热迁移的能力。基于全局视角，当发现在线的节点性能有下降，或者有些异常情况需要压制离线的时候，会启动热迁移的能力，寻找全局最有目标节点，并保持IP不变、网络不中断，无感知迁移离线任务。

大数据的作业有30%内存是冷内存，虽然业务已经申请，但是这部分在一分钟之内是没有访问的。基于这个统计数据，我们对内存的使用情况进行检测，然后对于冷内存进行压缩，通过空闲CPU换内存提升大数据资源利用率，最后把压缩内存数据上报到峰峦做合理超发。

在腾讯现网的内存压缩，主要是有温和压缩和激进压缩两种策略，在温和压缩策略下，节约12%左右内存消耗，而CPU额外消耗基本是可以忽略不计的。在激进的压缩策略下，内存节约了19.29%，但是会消耗一些CPU，这种策略适合内存瓶颈但CPU富余的业务场景。

总结与展望

在基于峰峦的腾讯大数据云原生实践中，技术方面我们主要是推动以下几个方向：

• 自研remote shuffle service，实现存算分离；

• 虚拟集群架构，实现强隔离下的统一调度，以及超大规模集群能力；

• 自研大数据调度器，调度吞吐提升10倍以上；

• 在大数据运行时上首次落地运行时热迁移；

• 最后基于整个架构提出全场景在离线混部的能力，有效降低成本。