Big Data on Kubernetes : 云原生大数据平台将如何演变

去年，在大数据领域发生了两个比较有代表性的事件：Apaceh Spark 和 Kafka 先后开始正式支持 Kubernetes，两者间隔也就两个月。与此同时，Spark、Kubernetes（K8s） 和云原生存储也在逐渐取代 Hadoop 的“三架马车”：MapReduce 、YARN 和 HDFS。

“以前所有大数据组件的公分母是 Hadoop，现在已经变成 K8s 了。”智领云联合创始人兼 CEO 彭锋说道，“大数据平台的云原生化，是一个确定的趋势。”

在这一背景下，智领云发布了国内首个基于纯 K8s 平台运行的在线数据工程开发平台 BDOS Online，该平台提供了数据应用开发和运营所必需的组件，同时支持公有云及私有云发布。

改造思路

根据彭锋介绍，该平台的出发点是要让用户从之前数月周期、百万投入的大数据平台建设中抽离出来，可以直接使用大数据平台。

“以前使用大数据平台，需要采购至少十几台服务器，还要招人安装组件、建立开发和运维平台，购买各种各样的 BI 工具等。整个大数据平台的建设和使用成本，入门门槛和角色风险都比较高。我们希望通过云原生数据应用开发方式，用户开个账号就可以在数日内看到效果。”

实际上，业内都开始对大数据平台进行云原生改造，但各家思路并不相同。总体来看，国内用户更希望能够从现有架构平稳地迁移，厂商也更谨慎些。因此，目前厂商对大数据平台的云原生改造基本还在内部尝试阶段，没有成型的产品出来。

比如，某些厂商是基于自己的调度系统和分布式计算体系开发的大数据平台，虽然现在也在做 K8s 改造，把一部分调度工作移到了 K8s，但是绝大部分组件还是基于原来的大数据平台体系运行，并不是真正的实现了云原生架构下的数据平台。

相对来说，国外企业的改造会更加激进些。像 Snowflake 和 Databricks 基本已经放弃 Hadoop，以 K8s 为调度和运营平台，实现存算分离，直接使用云原生的存储来建设大数据体系，用户在线上可以直接运行应用，是更彻底、更纯粹的云原生。

智领云的思路与国外企业接近，即将全部组件做 K8s 改造，也将服务搬到了线上。为了兼顾对公有云和私有云的支持，智领云的底层云平台是松耦合的，同时将需要的通用功能抽象出来，而非直接对应 K8s 的 API。这样的架构允许系统灵活对接类似于阿里云的 ACK 服务，或者是自主发布的 K8s 集群。另外，虽然主要对标国内主流云服务商的 K8s 版本，但也将不断适配最新的 K8s 社区版。

智领云的底层之前使用的是 Mesos。由于 Mesos 和 K8s 皆来自 Google 的 Borg，在迁移到了 K8s 后，发布和管理流程并没有很大的变化。

迁移到 K8s 带来的最大好处就是有了更简单的 NameSpace 管理，简化了资源隔离或者用户隔离方面等很多工作。“原来 Mesos 的 NameSpace 管理没有那么完善，因为是二级调度，所以它的资源分配相对复杂，不如 K8s 的简单。”

存储方面，在私有发布中智领云目前采用的是 MinIO 和 HDFS。整体看，无论是开源还是闭源的云原生存储方案，现在对于大数据系统的支持都还不太成熟。即使是 Snowflake、Databricks 的很多解决方案也是使用了云厂商的存储。智领云在阿里云上使用的也是阿里云提供的 NFS 和 OSS。

“云原生的存储和大数据的存储之间最大的区别在于，云原生的存储主要是为了有状态容器的迁移和发布设计。比如当某个容器卸载后，其他地方仍可以启动原本的存储，无需再将数据复制。这比较适合无状态或简单的有状态服务，同时存算分离比较容易实现。将云原生的存储体系应用到大数据系统中，还是要解决一些 data locality 之类的优化问题。”彭锋介绍道。

运维方面，智领云正在致力于将整个运维“Operator 化”。所谓 Operator ，即允许大家将日常的安装、发布、运维，到扩容、降容、升级等所有操作代码化。“一旦完成，整个大数据运维将更加自动化。”

难在哪里？

不过，彭锋坦言，目前大数据平台的云原生改造并非易事，改造挑战主要体现在以下三个方面。

 第一，K8s 体系和原来大数据体系之间存在架构上的冲突。原来的大数据体系拥有自己的一套分布式管理和内部通讯机制，这与现在的 K8s 原生技术栈有很多冲突。例如，YARN 对于任务作业的调度和 K8s 本身的调度并不匹配，将 Hadoop 的 Kerberos 管理和 K8s 的 Secret 管理结合也需要做很多集成工作。

另外，两个体系所倡导的理念也不一样。比如 K8s 提倡的是存算分离，但是大数据讲究的是数据存在哪里计算就在哪里。这些矛盾都增加了融合难度。

因此可以看到，现在 Hive、Spark 只能支持某一版本的 K8s，而 Kafka 对 K8s 的支持现在并没有开源，这些都说明大数据组件对 K8s 的支持还处于跑通的早期阶段。为解决版本差异问题，智领云需要更改 Hive、Spark、Kafka 等源代码来完成改造。

第二，安装运维等流程改造上的冲突。现在 K8s 所有系统的安装、容错、运维、扩缩容以及更新等，全部以类似于 Operator 的方式自动运行，但大数据组件的安装运维方式是比较原始的手动管理方式。因此，要把大数据组件的安装运维方式全部换成 K8s 理念的，需要做很多工作。

第三，如何无缝迁移并对现有业务不造成影响。现有大数据组件运行了很多以前的业务应用，比如 ETL 数据分析、数据仓建设等，很多是用基于 HiveSQL 的程序开发的，为了使用 K8s 而把以前的业务应用全部重新写一遍是不现实的，所以我们需要考虑到现有 workload 的无缝迁移。

彭锋表示，大数据平台的云原生改造才刚刚开始。K8s 还有不少可以提升的地方，其在生态系统、业务系统上的采用正在逐渐提高，但要形成行业共识还需要一些时间。

“但可以肯定的是，K8s 是趋势。这种改造，不管是对以 SaaS 方式服务、云上提供服务，还是企业内部提供云原生数据开发能力来说，都非常重要。”彭锋说道。