大数据平台是否更应该容器化

大数据的发展历史

大数据技术起源于 Google 在 2004 年前后发表的三篇论文，分布式文件系统 GFS、分布式计算框架 MapReduce 和 NoSQL 数据库系统 BigTable，熟称 ” 三驾马车 ”。在论文发表后，Lucene 开源项目的创始人 Doug Cutting 根据论文原理初步实现了类似 GFS 和 MapReduce 的功能。并在 2006 年，将该部分功能设置成独立的项目即大名鼎鼎的 Hadoop 项目。Hadoop 项目中主要包括分布式文件系统 HDFS 和大数据计算引擎 MapReduce 两个组件。

图片来源于网络

在早期，MapReduce 既是一个执行引擎，又是一个资源调度框架，集群的资源调度管理由 MapReduce 自己完成。但是这样不利于资源复用，也使得 MapReduce 非常臃肿。于是一个新项目启动了，将 MapReduce 执行引擎和资源调度分离开来，这就是 Yarn。2012 年，Yarn 成为一个独立的项目开始运营，随后被各种大数据产品支持，成为大数据平台上最主流的资源调度系统。伴随着时代的发展，大数据场景下的计算引擎层出不穷，主要的有内存式计算引擎 Spark, 分布式实时计算 Storm, 流计算框架 Flink 等。这些计算引擎都使用 Yarn 进行资源管理和调度。

大数据平台目前存在的问题

目前绝大多数大数据平台都是基于 Hadoop 生态，使用 Yarn 作为核心组件来进行资源管理和调度。但这样的平台普遍存在如下问题：

(1) 资源弹性不足，无法按需自动扩容。大数据系统资源的高峰往往具有明显的周期性。例如实时计算资源消耗主要在白天。离线分析中，日报型的计算任务资源的高峰一般在 22:00 以后。周报和月报型的计算任务业务高峰往往也是在一个固定的时间点。并且离线计算有时还有突发的计算任务，例如需要对历史数据做一个统计。目前的大数据系统普遍缺乏资源的弹性，无法按需进行快速扩容，为了应对业务高峰和突发的计算任务只能预留出足够多的资源来保证任务能够正常响应。

(2) 资源利用率低。日志留存和流量清单等存储密集型的业务 CPU 使用率长期小于 30%。而计算类的业务虽然 CPU 消耗很高，但是存储的资源使用率小于 20%。大量资源闲置。并且考虑在线业务往往在低峰期会有大量的资源闲置。这些资源其实离线计算业务是完全可以利用的，但目前大数据的系统架构这部分资源完全没有被利用。导致资源利用率进一步降低。

(3) 资源隔离性差。从 Hadoop2.2.0 版本开始，Yarn 开始使用 cgroup 实现了 CPU 资源隔离，通过 JVM 提供的内存隔离机制来实现内存资源隔离。对于磁盘 IO 和网络 IO 的隔离目前社区还在讨论中 YARN-2139，YARN-2140。对于文件系统环境的隔离，社区在 Hadoop 3.0 版本中支持通过 Classpath isolation HADOOP-11656 来避免不同版本的 jar 包冲突，但无法做到完整的文件系统隔离。整体上看 Yarn 的资源隔离做的并不完善，这就造成了，多个任务运行到同一个工作节点上时，不同任务之间会存在资源抢占的问题，不同任务之间相互影响。

(4) 系统管理困难。在大数据系统中缺少统一的管理接口，也缺少路由管理，网络管理，磁盘管理等能力。这就造成大数据平台的开发往往需要对管理系统进行深度定制。开发工作量大，系统管理困难，并且平台迁移困难。例如大数据平台中需要提供对大数据组件 UI 页面的访问能力。在大数据平台构建中，为了能够访问组件的 UI 页面往往需要单独进行网络的打通，进行额外的路由的配置。并且很多时候这些配置都缺少标准的接口，无法做到自动化，管理起来十分困难。

(5) 管理方式不统一。在线业务和大数据业务虽然属于不同的业务类型，但就管理平台来说提供的功能是类似的。主要提供资源管理，业务 (任务) 管理，权限管理，可视化展示与操作等方面的功能。但因为管理方式不统一，底层框架与运行方式不同，造成了在线业务和大数据业务往往需要开发不同的平台，由不同的团队运维来管理，这极大的增加了额外的人力投入，造成不必要的人力损失。

Kubernetes 编排系统现状介绍

Kubernetes 是谷歌开源的生产级的容器编排系统，在谷歌内部长达 15 年的使用积累，依赖其对功能场景的清晰定义，声明式 API 的简洁易用，充分的扩展性，逐步在容器编排领域的竞争中胜出，成为这一领域的领导者。伴随着微服务，DevOps，持续交付等概念的兴起和持续发酵，并依托于云原生计算基金会 CNCF，Kubernetes 保持着高速发展，正在成为 ” 云计算时代的操作系统 ”。

Kubernetes 究竟有多热门，根据 CNCF 年初 (2020) 的统计数据，在 2019 年 84% 的企业在生产环境中使用了 Kubernetes。随着在生产环境的广泛使用，Kubernetes 的成熟度已经得到了大范围的检验。很多公司已经提出了所有组件容器化的目标，借助云原生的技术，来提升组件运维管理和研发流程的效率。

图片来源于网络

Kubernetes 如何解决大数据的问题

对于在线业务，使用容器技术能够很好的提高资源使用率，基于容器构建 CI/CD 流程可以大幅提升研发效能和系统管理能力，使用集群的自动伸缩功能可以根据需要动态申请和释放资源，提高资源使用的弹性。那么在大数据场景下，使用容器能否解决大数据平台目前遇到的问题呢？

首先对于资源弹性不足的问题，Kubernetes 可以通过弹性扩缩容来实现业务高峰时的快速扩容，避免为了应对业务高峰预留过多的资源。更进一步可以直接使用无服务计算 (Serverless) 技术，直接将大数据业务跑在无服务计算的容器上，做到按需使用和付费，使资源的使用完全弹性。

​ Kubernetes 集群自动扩缩容原理

对于资源使用率低的问题。一方面 Kubernetes 支持更加细粒度的资源划分，这样可以尽量做到资源能用尽用，最大限度的按需使用。另外一方面支持更加灵活的调度，并根据业务 SLA 的不同，业务高峰的不同，通过资源的超卖和混合部署来进一步提升资源使用率。由于在线业务和离线业务两者之间 SLA 要求明显不同，业务高峰期也明显不同，容器化后使用离线在线混合部署，一般对资源使用率的提升在 30% 以上。

对于资源隔离性差的问题。容器技术从一开始就支持不同资源的隔离。CPU，内存，磁盘 IO，网络 IO，设备等这些都有比较完整的支持。在线业务使用容器技术，通过 Kubernetes 编排系统能够很好的将不同业务实例混合部署到相同的节点上，实例之间使用隔离技术，完整的隔离，相互之间完全不受影响。

​ Kubernetes 隔离能力示意图

对于系统管理困难的问题，Kubernetes 不仅提供资源管理的能力，还提供路由管理，网络管理，监控日志等多方面的能力。同时对外通过统一的声明式 API 进行访问。基于 Kubernetes 构建大数据平台，可以极大的简化系统开发的难度，减少系统管理的复杂度。例如在大数据平台中，使用 Kubernetes 提供的路由管理能力 Service 和 Ingress 可以十分方便实现对大数据组件 UI 的访问，并且 Kubernetes 还提供标准的声明式 API 来管理，极大的简化了自动化的复杂度。

​ Kubernetes ingress 提供访问大数据各个组件 UI 示意图

如果在线业务和大数据业务都统一使用容器化的方式来部署，使用 Kubernetes 编排框架来管理。这样就能将大数据业务和在线业务在同一个平台中实现管理和运维。避免平台管理团队的人员分散，大大提高平台管理团队工作效率。

​ 统一的业务管理平台示意图

大数据容器化技术现状

大数据组件众多，按照类别大致可以分为文件存储系统，NoSQL 数据库，计算框架，消息中间件，查询分析等。常用的大数据组件具体的分类如下表所示：

这些组件现在一般都有对应的开源项目来支持部署到 Kubernetes 上，本文将对一些常用的组件在 Kubernetes 的部署进行分析。

文件存储系统

HDFS on Kubernetes

HDFS 主要包括 Datanode，Namenode 和 Journalnode 三个组件。在 Kubernetes 中进行部署时，由于 Datanode 需要存储 HDFS 中的数据，对磁盘要求非常高，所以在 Kubernetes 中部署时 Datanode 采用 DaemonSet 的方式进行部署，每个存储节点部署一个 Datanode 实例。而 Namenode 和 Journalnode 由于需要保持名称不变，在 Kubernetes 中采用 StatefulSet 的方式进行部署。

NoSQL 数据库

Hbase on Kubernetes

Hbase 主要包括两种类型的节点，HMaster 节点和 HRegionServer 节点。其中 HMaster 节点作为主节点，负责管理多个 HRegionServer 节点。HRegionServer 节点作为 worker 节点，负责管理各个 region。由于 Hbase 的实际数据存储在 HDFS 中，Hbase 本身并不存储数据，所以 HMaster 和 HRegionServer 并不需要挂载磁盘。只是为了保持实例名称不变，HMaster 和 HRegionServer 都采用 StatefulSet 的方式进行部署。

数据查询分析

Hive on Kubernetes

Hive 主要包括 hive-Server 和 metastore 两个组件。其中 hive-Server 作为访问入口，可以按照在线服务一样使用 Deployment 进行部署。metastore 因为需要保持名称不变，所以使用了 StatefulSet 的方式进行部署。

计算框架

Spark on Kubernetes

Spark 是大数据领域比较早做容器化的一个组件。Spark 从 2.3 版本支持原生的方式将任务跑在 Kubernetes 上。具体的实现原理如上图所示，通过 spark-submit 脚本向 kube-apiserver 提交创建请求，先创建 spark 的 driver 实例。然后 driver 实例按照任务执行需要的资源大小，向 kube-apiserver 发起请求，创建对应的 executor 实例，由 executor 实例来执行任务。Driver 实例通过监听 kube-apiserver 中 pod 的信息，对 executor 实例的生命周期进行管理。

Flink on Kubernetes

Flink 与 Spark 类似，在其内核中直接对接了 Kubernetes 的 kube-apiserver，以提高资源的使用效率。在 Flink Client 提交后，会先创建 Flink Job Manager 实例，然后再由 Job Manager 会调用 Kubernetes 的接口，根据任务的并行度来动态的创建对应的 TaskManager 实例。

通过对上面组件在 Kubernetes 的部署情况的分析，可以看到目前大部分的大数据组件都已经有项目来支持在 Kubernetess 上部署，并且借用 Kubernetes 不同类型的资源管理能力，就能实现对大数据组件的部署。大数据组件的容器化正在从尝试走向成熟。

腾讯大数据容器化实践

近两年腾讯内部多个部门展开了大数据容器化的实践，并取得了非常不错的效果。充分证明了大数据容器化的可行性和大数据容器化在简化运维管理成本，提升资源利用率上的效果。

云原生流计算平台 Oceanus 容器化实践

Oceanus 是腾讯云推出的流计算产品，其基于 Apache Flink 构建，提供全托管的云上服务，最大规模可达万亿级。使用流计算平台 Oceanus 可以方便的进行云端流式数据汇聚、计算，轻松的构建网站点击流分析、电商精准推荐、物联网 IoT 等应用。

近期腾讯云容器团队和大数据团队联合推出了 Oceanus on TKE(Tencent Kubernetes Engine)版本，通过将流计算任务运行在 Kubernetes 上，高效的解决了资源管理和隔离的问题。同时使用容器统一的日志采集方案，实现更好的日志采集和查看。另外使用 Kubernetes 提供的 Ingress 能力，灵活的支持查看各个大数据组件的运维页面。

腾讯云容器团队和大数据团队正打算将大数据组件逐步都运行到 Kubernetes 上，以实现更好的资源隔离和资源管控。为客户提供在离线统一的管理平台，达到资源运维管理的极简化，资源运行效率的极大化。

QAPM 数据分析平台全面容器化实践

QAPM（Quick Application Performance Monitor) 数据分析平台是腾讯云推出的客户端性能分析平台，其依托于腾讯云的全方位定位检测 APP 性能的专项解决方案，实现对 APP 性能的高效性能分析。2018 年，在开始设计和开发 QAPM 平台时，为了在云上充分利用资源的弹性，在云下支持私有化交付，并且尽可能降低管理成本，平台在设计之初就采用全容器化的方式进行部署。

具体的业务流程包括离线计算和流计算两个主要部分。在离线计算中，数据从客户端上报后，使用 kafka 进行转发，然后将数据通过 Hive 写入 HDFS。Spark 计算引擎把数据读出，经过处理后将处理的结果存入 ES，Postgres，Druid 等后端存储，用于前台的展示与查询。

在实时计算中，数据从客户端上报后，使用 kafka 进行转发，然后直接经过 Flink 进行流式处理。处理完后数据写入入 ES，Postgres，Druid 等后端存储，用于前台的展示与查询。

因为所有组件都使用容器化部署，每个组件都设计成了单独的 Charts 包，这样部署新的环境变得非常简单。之前按照传统的方式部署一套完整的环境，花费的时间在两天甚至更多。但因为使用了容器化部署，一般半小时以内就可以完成部署和相关配置的修改。极大的提升了效率。

为了进一步提高资源资源利用率，QAPM 平台在容器化的基础上通过将流计算业务和离线计算业务混合部署到了同一个集群。使用一个固定的资源池作为基础资源，在业务高峰期使用弹性扩容的方式来补充资源，使整体资源使用效率提升了 30%~50%。

总结

大数据与容器编排技术，一个是在数据处理领域历史相对比较长久的互联网的基石技术，一个是在业务编排领域近年来才兴起的新兴技术。两者本来都在各自的生态中处于不断发展壮大的阶段，相互直接融合比较少。但近年来随着 Kubernete 技术的成熟，使大数据容器化从设想变成了可能。通过容器化技术可以像在线业务场景一样在大数据场景进一步提升运维管理和资源使用的效率，进一步释放大数据的活力。

参考链接：

BIG DATA MANAGEMENT PLATFORM ABOUT INFORMATICA BIG DATA MANAGEMENT