作者 | 宋文欣
以 Hadoop 为中心的大数据生态系统从 2006 年开源以来,一直是大部分公司构建大数据平台的选择,但这种传统选择随着人们的深入使用,出现的问题也越来越多,比如:数据开发迭代速度不够快、集群资源利用效率过低、新的开发工具集成非常复杂等。这些问题已经成为困扰企业数字化转型加速迭代和升级的主要障碍。
而传统大数据平台通常是以 Hadoop 为中心的大数据生态技术。一个 Hadoop 集群包含 HDFS 分布式文件系统和以 Yarn 为调度系统的 MapReduce 计算框架。围绕 Hadoop,有一系列的软件来帮助人们进行大数据的存储和计算,比如数据仓库 Hive、计算框架 Spark、实时消息队列 Kafka 等。
在大数据发展的初期,这样的大数据生态技术框架是能基本满足人们建设大数据平台的需要的。随着时代的发展,大数据技术使用逐步地深入,大数据开发需求变得越来越旺盛,人们对多租户环境下大数据开发的效率、大数据集群资源利用率、新(计算和存储)技术的集成速度提出了越来越高的要求,而传统大数据平台在面对这些需求时则显得有点束手无策,出现了无法克服的困难。
从 2014 年开始,以 Docker 和 Kubernetes(K8s)为代表的云原生技术蓬勃发展,云原生的社区和机构迅速壮大。现在,Kubernetes 已经成为企业搭建容器云平台的标配。
那么,高速发展的云原生技术能不能解决传统大数据平台的问题呢?答案是肯定的。本文将从大数据平台产品云原生化的实践过程,阐述一下传统大数据平台迁移到 Kubernetes 上所要经过的技术改造过程。
1 传统大数据平台遭遇四大窘迫问题
我们先仔细分析看下传统大数据平台的弊端。传统大数据平台的技术架构决定了依靠它本身的发展是无法克服以下这些困难:
总而言之,传统大数据平台因为其结构性的缺陷导致了多租户环境下数据开发效率低、集群资源利用率不高、以及集成新技术很复杂等问题,依靠 Hadoop 生态技术框架本身的发展是不可能解决这些问题的。
2 大数据平台的云原生化趋势
既然不能够依靠 Hadoop 生态技术本身的发展来解决传统大数据平台带来的难题,那么我们就应该把注意力放到当前最新的技术发展趋势之上,也就是以容器和 Kubernetes 为代表的云原生技术。
云原生技术在 2013 年容器项目以及 2014 年 Kubernetes 项目正式发布以后,发展非常迅猛。现在,各大公有云厂商都支持 K8s,还有上百家技术公司在持续投入 K8s 的迭代和更新工作。成立于 2015 年的云原生计算基金会(CNCF),将 K8s 作为其托管的第一个项目,到目前该基金会已经托管了 123 个项目,近 200 个国家的 16 万开发者在为这些项目开发代码。更令人兴奋的是,CNCF 的生态全景图目前包含了 1000 多个云原生技术产品,覆盖了数据库、消息级流处理、调度和任务编排、存储系统等 10 多个技术领域。
对于大数据来说,2021 年应该是云原生大数据技术发展的里程碑。在这一年,有两个重大的技术进展被公布。一个是 2021 年 3 月,Apache 宣布 Spark 3.1 正式支持了 kubernetes,另外是在 2021 年 5 月,Apache Kafka 背后的商业公司 Confluent 也发布了 Confluent on Kuberneters,一个能私有发布的在 K8s 之上运行的 Kafka 生产集群系统。
这两个重要事件表明,大数据平台的云原生化已是大势所趋。按照这个趋势,Hadoop 也会逐渐迁移到 K8s 上。从技术角度来分析,常说的 Hadoop 三架马车中,计算框架 MapReduce 会被更高效的 Spark 所取代,资源调度组件 Yarn 正在被 K8s 取代,最坚挺的 HDFS 也有了云原生的对标方案。这意味着直接在 K8s 上运行所有现在的大数据工作负载已经成为了可能。
同时,从企业业务需求来看,传统大数据平台所缺乏的难以集成新组件、难以实现资源隔离、难以提供资源利用率,特别是缺乏云原生的弹性扩展能力大大阻碍了企业业务系统的发展,由于缺乏弹性扩展能力而导致的业务系统崩溃想象时有发生,而云原生大数据平台恰恰是解决这些问题的良药,简单的讲,就是云原生赋予了大数据平台原来没有的多种云化能力。
因此,无论从技术趋势还是从企业业务需求来看,大数据平台的云原生化都是一个必然的趋势。
3 传统平台云原生化需要解决的 8 项技术难题
虽然大数据平台的云原生化已经是大势所趋,但在落地实践的过程中还是有一些技术难题需求攻克。就拿 Spark 来说,虽然 Apache Spark 3.1 已经支持了 K8s,但是有几个问题还没有解决,比如 Hive SQL 作业如何以 Spark 的方式在 K8s 运行?JupyterLab 运行的 PySpark 和 Spark 程序怎么运行在 K8s 上?接下来,我们介绍下智领云是如何解决传统大数据平台云原生化的技术难题。
Hive SQL 程序在 K8s 上运行
在传统大数据平台中,Hive 被广泛用来进行数据仓库的建设。大数据平台的云原生化一个很重要的工作就是要保留对 Hive SQL 的支持,否则原有的大量的 Hive SQL 程序需要进行迁移,风险和成本都难以把控。从语法上看,Hive SQL 和 Spark SQL 还是有很大差异的,所以我们不能简单地用 Spark SQL 来取代 Hive SQL。另一个技术选择就是修改 Hive 的底层执行引擎,让 Hive SQL 程序以 Spark 作业的方式运行在 K8s 上。这个选择看上去不错,但也面临一些技术挑战。
首先,Spark 对 K8s 的支持是 2021 年达到 GA 状态,不同的 Hive 版本、Spark 版本、K8s 版本、以及很多相关大数据组件(比如说授权组件 Apache Ranger)之间的适配还没有成熟。因此,我们经过生产集群的验证,确定了基于以下大数据组件版本的 Hive 执行引擎切换到 Spark 的解决方案。
对于 Spark,我们推荐使用最新的版本,因为新版本的 Spark 能增强对 K8s 的支持。而 Hive 从 4.0.0 版本开始,重构了 spark-client 模块的代码结构,增加了 SparkClient 抽象类,通过对该抽象类的代码扩展,我们可以实现对 K8s 的支持。但是在 Hive 代码进行扩展的过程中,要注意避免 Hive 和 Spark 针对 Kryo 库的版本冲突。
我们对 Hive 代码的改造主要是增加了抽象类 SparkClient 的一个 K8s 实现,KubernetesSubmitSparkClient 类。这个类通过创建一个 SparkSubmit 实例向 K8s 提交 Spark 任务的各种参数。如下图所示,Hive SQL 代码的执行经过了下面一系列的流程。
Spark 程序在 K8s 上运行
对于 Spark 程序和 PySpark 代码的执行,我们采用的解决方案是基于 Google 开源的 Spark on K8s Operator 项目。这个开源项目更好地利用了 K8s 的一些特性,来增强在 K8s 上使用 Spark 计算引擎的易用性、灵活性、以及性能提升。
但该项目有一个缺陷,就是用户需要通过配置一个复杂的 Yaml 文件来运 Spark 作业,该 Yaml 文件需要声明 Spark 作业的所有信息,包括 Driver/Executor 的资源配置、Spark 的容器镜像版本、以及调度算法等。对于一般用户而言,这些配置信息显得过于繁琐和复杂。
为了简化 Spark 程序在 K8s 上运行的复杂配置流程,我们模仿 Apache Livy 的 API 开发了一个 Spark Job Manager Server。该服务负责管理 Spark On K8s Operator 的作业,提供作业的创建、更新、删除、查询状态、日志获取等接口。提交 Spark 程序的时候,用户不需要配置任何 Yaml 文件,只需要配置少量 Spark 作业参数,跟用 spark-submit 脚本提交方式没有区别。Spark Job Manager Server 服务会根据用户提交的参数完成 Spark 作业的 Yaml 文件渲染,将作业提交到 K8s 集群。这一操作方式极大地简化用户在 K8s 上运行 Spark 程序的复杂度。Spark 程序在 K8s 上运行的架构图可以参考下图:
需要注意的是,第 1、2、3 步都是发生在 Spark Job Manager Server,第 4 步是将 Spark 作业以 Yaml 文件的方式提交给 K8s API Server,之后的 Spark 作业执行就交给 Spark on K8s Operator 去执行了。在第 11 步,Spark Job Manager Server 会通过 API Server 获取 Spark Driver 的状态信息,从而与 Spark Driver 进行通讯以获取 Spark 作业的执行结果。
JupyterLab 代码在 K8s 上运行
在传统大数据平台,JupyterLab 一直是数据科学家首选的交互式编程工具,广泛应用在数据的探索分析以及人工智能机器学习算法的开发上。因此,在 K8s 平台上支持 JupyterLab 交互式的 Spark 程序运行是必须要解决的问题。
目前,JupyterLab 是利用开源项目 SparkMagic Kernel 通过 Apache Livy 服务来和 Spark 集群进行通讯,实现 Spark 程序的交互式运行。但是,Apache Livy 目前的版本并不支持 K8s。针对这个问题,我们采用了 Hive 模式类似的方式,对 Apache Livy 代码进行了扩展,在 Livy 服务端创建了一个 RPC Server,然后通过 SparkSubmit 提交 Spark 任务。运行在 K8s 集群的 Spark Driver Pod 会和 RPC Server 通信,来完成 SQL 任务的交互执行。下图展示了整个流程的架构图:
Kafka 集群在 K8s 上运行
Kafka on K8s 有不少开源的方案,我们选择了 Strimzi 开源的 Kafka Operator。这个项目通过 CRD 抽象描述各种 Kafka 组件的配置,以 Operator 控制协调的原理去管理 Kafka 集群组件,相对完整地实现了 Kafka 集群在 K8s 上的部署。
我们对 Strimzi Kafka Operator 的改造主要是支持安全认证和权限管理,将 Schema Registry 组件集成到 Kafka Operator,然后对开源的 Kafka 运维管理工具 AKHQ 进行改造,将其也集成到 Kafka Operator。下图展示了 Kafka 在 K8s 运行的架构图:
HDFS 在 K8s 上运行
目前开源社区有不少成熟的项目都支持 HDFS 集群在 K8s 上发布,但是对多租户和数据安全的支持却不是很完善。我们对 HDFS on K8s 项目进行了扩展,首先是将 Hadoop 的版本升级到最新版本,并与最新的 K8s 版本进行适配。同时,我们集成了对 Https 访问、Kerberos 安全认证和 Apache Ranger 权限授权等功能的支持。
利用 KubeVela 简化大数据组件在 K8s 上的发布
在 K8s 这样的平台上发布应用并不是一件容易的事情,应用开发者要了解 K8s 复杂的应用资源配置,比如 API 版本、资源类型、命名空间、标签、容器参数、存储参数、网络参数、重启配置等等一长串的配置。应用开发者为了掌握 K8s 基于 Yaml 文件的应用配置方式需要大量时间去学习和实践。在实践过程中,有不少开发者反映,他们 90% 的时间都在编写重复的应用配置,整个流程过于复杂。
为了解决这一问题,我们采用了 KubeVela 框架来简化 K8s 上应用发布和交付的复杂性。KubeVela 作为 K8s 的一个插件,它利用 Open Application Model 模型和 K8s 的可扩展性,通过构建应用发布的一个抽象层,来解决在 K8s 上发布应用存在的一些复杂问题,比如 Pod、端口暴露、权限、资源声明和管理、CRD 等概念,都被抽象成了以应用为视角的配置 SDK。我们通过 KubeVela 框架,将应用发布的通用定义、监控告警定义、监控面板定义、日志采集定义、以及对外端口定义等都抽象成了一个个组件,极大地简化了应用发布的复杂性,也统一了数据应用集成开发平台的应用发布规范。
大数据组件可观测性在 K8s 上的实现
大数据组件的运行需要有统一的监控、报警、日志系统来高效地进行运行状态及性能的监控、失效报警、和故障跟踪等大数据运维工作,以保证大数据生产系统的平稳运行。
在可观测性方面,我们采用了开源的 Prometheus 来进行监控指标的采集,集成了 Grafana 来配置各组件的监控面板,利用轻量级的云原生日志系统 Loki 来收集各组件的日志,并自主研发了 LogViewer 服务来快速地搜索和获取日志。下图展示了 Kafka 集群的监控面板及日志检索大屏:
数据安全和资源隔离在 K8s 上的实现
通常一个大数据平台要服务多个部门、业务人员、数据开发人员,是一个典型的多租户环境。在这样的多租户环境下,我们首先要实现所有大数据(可视化)组件的单点登录,这样既能避免维护多套用户登录系统的麻烦,也能保证我们能在大数据计算和存储层能实现统一的安全认证和权限授权机制,而安全认证和权限授权机制也必须是所有计算和存储引擎共用同一套机制。
传统大数据平台在多租户环境下的一个难点就是资源隔离,它很难避免一个或少数几个租户独占资源的情况。在云原生架构下,这一问题就迎刃而解。那么,我们具体看看是怎么实现上述功能点的。
数据应用开发平台的数据安全架构如下图所示。目前,每个用户在每台虚机上都创建了一个相同的账号,并且保存了一份该用户的 Kerberos keytab,这样每个运行中 K8s 上的容器和大数据组件都可以使用这个用户 ID 和 keytab 进行安全认证。
目前,我们已经将云原生大数据平台的基本版作为一个项目开放了出来,与开发者共享 HDFS、Hive、Spark operator、和 Kafka Operator 等大数据组件的部署方式。开发者可以基于这个项目部署一个实验的大数据集群,来体验云原生大数据平台。
Github 地址:
https://github.com/linktimecloud/big-data-on-k8s
Gitee 地址:
https://gitee.com/linktimecloud/big-data-on-k8s
需要注意的是,本项目只能作为一个实验系统来运行,因为它不支持高可用、Kerberos 安全认证、以及基于 Apache Ranger 的鉴权机制。
4 结束语
这两年以来,我们在大数据平台云原生化这个方向做了大量尝试,实现了大数据组件在 K8s 的稳定运行以及统一的数据安全机制,使数据应用开发平台实现了完整的云原生化。接下来,我们将在以下几个方向继续探索,推动大数据平台更高效更稳定地运行在 K8s 之上。
作者简介
宋文欣,智领云科技联合创始人兼 CTO,美国纽约州立石溪大学计算机博士,武汉大学计算机系本科及硕士。具有二十多年软件开发,大数据及云计算经验,前 Electronic Arts 高级工程经理,ask.com Analytics 技术带头人。
今日好文推荐
字节跳动现象级 App 十年成长史,移动端基础建设与组织演进之路 | 卓越技术团队访谈录
满心欢喜入职 Gitpod 一年后失望离开:垃圾邮件当 OKR、天天造势但就不兑现承诺
钉钉总裁称非常讨厌红点和 DING 消息;Mozilla 控诉苹果、谷歌和微软锁定浏览器;特斯拉上海工人薪酬曝光:到手七八千|Q 资讯
接手了一座年收入 2000 万美元的代码“屎山”,我到底是该重写还是该跳槽?