云原生大数据是大数据平台新一代架构和运行形态。随着字节跳动内部业务的快速增长，传统大数据运维平台的劣势开始逐渐暴露，如组件繁多，安装运维复杂，与底层环境过度耦合；对业务方来说缺少开箱即用的日志、监控、告警功能等。在此背景下，我们进行了一系列云原生大数据运维管理实践。通过云原生的方式进行运维管理，最终达到弱化业务方对状态的感知，屏蔽环境的差异，统一不同环境下的使用体验。

业务现状与背景介绍

字节跳动过去几年在支撑自身业务的过程中积累了很多大数据领域的引擎工具，目前也在探索将这些引擎工具的能力进行标准化、产品化的输出。在此过程中主要有以下几个难点：

• 组件繁多：大数据领域完成一项工作需要很多组件配合。比如分布式大数据存储及各种任务执行引擎：Flink、Spark 及各种 ETL 的 OLAP 工具和调度 ETL 的任务调度工具，还有支撑工具引擎的运行日志监控系统和项目用户权限的辅助系统等；

• 部署复杂：这些系统的组件繁多，相互配合也非常复杂，导致部署变得困难。比如部署一套完整的生产环境，可能会涉及到多个依赖和配置管理。有强依赖，比如各种任务引擎对底层大数据存储的依赖；也有弱依赖，比如任务引擎对日志监控系统的依赖；甚至还有循环依赖，比如消息中间件可能需要采集日志，但日志采集本身又依赖消息中间件，另外它们的配置还会形成相互嵌套；

• 环境耦合：比如任务执行引擎可能需要嵌套大数据存储配置，日志采集可能需要感知每个组件的目录以及它的格式等。部署复杂就会造成环境的耦合，因为日常需要维护这些复杂的配置及依赖等，日积月累下就会与这套环境形成了一个深度耦合造成移植困难。

随着近几年云原生概念的兴起，我们也尝试将这些工具进行云原生改造来解决以上问题。

云原生场景特性

• 无服务状态感知：用户可以使用功能而不需要关注背后的运行状态，也不需要关心背后的逻辑；

• 极致弹性伸缩：对用户隐藏运行状态后，在云原生场景下的伸缩更为极致，按需使用可以使成本降低显著；

• 快速故障转移：当故障发生时借助极致的弹性伸缩特性，可以快速下线故障节点，补充新的正常节点，从而实现快速故障转移，并且这个故障转移对用户来说也是无感无损的动作。

以上这三个特性会相互促进，形成一个良性的循环。

云原生演进方向

架构演进

云原生大数据简介

云原生大数据主要是构建在容器上的，这里的容器可以是公有云的容器服务，也可以是私有云的容器底座，私有云的容器底座可以是开源的 K8s/基于 K8s 改造的底座，整个云原生大数据可以分为三大平台和一大支撑体系，三大平台分别是调度层、引擎层和平台层。在容器之上是资源调度层，负责统一管理调度整个集群的计算、存储和网络等资源。调度层上面的核心引擎层主要是是字节自研的统一大数据存储系统，兼容 HDFS 语义的同时支持对接标准的 S3 对象存储。存储层的上一层是 Flink、Spark 等各类字节自研或优化的计算引擎、消息中间件、日志搜索及实时分析引擎等工具。最上面的平台服务层负责将这些引擎能力封装整合成一个对外输出的产品。

本次介绍的运维管理平台支撑了上述的三大平台，提供日常组件运维的管理功能，为了更好地适应整个大数据云原生的改造，我们对运维管理模块也做了云原生的改进。

云原生上的运维实践

• 资源占用率低：运维管理模块不是面向用户的产品核心功能，所以它的存在感要足够低，资源占比要足够小，甚至在一些小型场景下要可以被忽略不计；

• 伸缩性强：在日常的运维管理中，因为日志监控跟集群的规模是呈正相关的，那么所有运维管理相关的功能要有跟环境进行快速水平伸缩的能力；

• 稳定性高：运维管理对稳定性的要求很高，即使在发生故障的情况下，也要能够快速恢复，并且也需要对其他组件提供容灾管理的能力；

• 可移植性强：运维管理模块的一个大目标就是支持整个云原生大数据产品的快速移植，那么就要求它本身就不能有环境耦合的问题，并且所有的相关功能都需要支持插拔式设计，可以灵活的在不同环境提供一套完整的运维管理功能；

• 环境感知弱：向上层业务屏蔽由于环境差异带来的运维管理的差异性，保证上层业务可以用统一的方式使用不同环境上的运维管理功能。

所以为了满足以上要求总结了接下来需要关注的几个方向。在环境管理方面需要我们抽象出一套统一的环境模型去适应不同的部署；另外还要有一个灵活便捷的组件管理服务统一管理组件元数据的依赖、配置等信息；最后还需要拥有功能抽象的能力，比如对常见的日志、监控、告警等功能可以通过抽象统一对上层业务屏蔽环境差异性。

环境管理与组件服务

环境管理

可以将整个环境按照功能划分成三个逻辑区域，分别是控制面、系统面和数据面，需要注意的是这三块区域只是逻辑区域的划分，并不是物理环境上的隔离。比如在一些场景下控制面可以与系统面进行合并，甚至在一些小型场景下，三个面也可以合并在一个物理集群内。

• 控制面：用来提供弱业务承载，是全局唯一一个负责环境管控、成本核算及服务网关等支撑性的工作；

• 系统面：在每个逻辑单元内是唯一的，但是整个系统中可以有多个逻辑单元，比如在同城多活/异地多活的场景下，每一个逻辑单元都可能对应着一个机房/一个区域，多个逻辑单元间的关系依靠控制面协调；

• 数据面：用于提供引擎运行所需的计算、存储、网络等资源，并且在系统面的统一协调下多个数据面可以形成一个逻辑上的联邦集群。

组件服务

通过对环境区域的划分也对组件进行层级的划分，主要可以分成系统级、集群级、租户级和项目级。系统级负责大部分的业务管控逻辑；集群级则主要完成日志数据/监控数据 Agent 和内部自研的调度器及 Operator 等的采集工作；租户级主要用于支撑特定大用户独占的组件；最下层的项目级就是用户的作业实例、中间件实例及其他第三方工具等。通过这里的划分把整个部署分为了网格形式，使每个组件只需要关注自己所在的网格，很好的屏蔽了组件与环境信息的耦合。

K8s 对单个资源的支持十分友好，对特定领域的操作也十分丰富。但是简单的服务也需要多个资源的配合，比如 Deployment 承载业务逻辑就需要 ConfigMap 去保存它的配置，然后又为了方便地对外暴露服务需要通过 Service 统一访问入口，但是这里的资源协调在 K8s 中并没有提供很好的工具。在开源的解决方案中很多开源组件基本上都提供了迁移 K8s 的 Helm Chart，但为了更好地融入开源的生态体系，我们也基于 Helm 构建了自己的组件服务。

由于开源 Helm 命令行工具并不适用于云原生场景下组件间的 API 调用，所以我们对开源 Helm 进行了深度服务化定制，在常见的部署、卸载、升级、回滚等需求中通过 API 的方式进行对外暴露，并增加可视化界面，同时还支持了深度的仿真部署，让用户可以快速进行部署、验证、调试等工作，也对层级配置做了精细的划分使组件在部署时可以进行合并覆盖，另外也在组件部署时配置了对资源的动态修改，通过以上措施使上层的业务组件可以更加关注在自己的业务领域中。

磁盘管理

在磁盘管理中将其分成两大块区域，第一块区域是 K8s 维护的，比如常用的 EmptyDir，这个部分推荐用来存储配置数据或者少量的临时性数据。

剩下的区域就是上文提到的通过 CSI 进行统一管理，主要细化成了三块区域，分别对应的前面提到的三个存储卷，共享容量卷基于简单的本地路径的方式进行支持；对于共享磁盘卷会先会把所有的磁盘组装组合成一个 Volume Group，当业务组件申请共享磁盘卷时可以创建一个逻辑卷使用，从而达到隔离的效果。

下一篇将介绍：字节大数据平台运维管理的统一日志告警，敬请期待。

作者简介

本文根据演讲者在 GOPS 2023·深圳站演讲整理而成，如有图文不妥，请以视频为准。更多精彩，请关注高效运维公众号。

还不过瘾？10月下旬，GOPS 全球运维大会 2023 · 上海站，早鸟票火热预售中~

商务赞助及合作：

周静：130 7118 2180（微信同号）

任怡：132 6958 7068（微信同号） 

门票咨询：

李伟：130 2108 2989（微信同号） 

张娜：132 6188 5689（微信同号）

渠道合作：

刘欣：158 0111 5386（微信同号）

王子翰：185 4893 3915（微信同号）

议题申报：

刘杰：156 5212 7323（微信同号）

高婉莹：185 1087 3635（微信同号）

近期好文：

使用 Prometheus 进行应用监控，这些总结，你受用吗？

“高效运维”公众号诚邀广大技术人员投稿

投稿邮箱：jiachen@greatops.net，或添加联系人微信：greatops1118。

点个“在看”，一年不宕机