初探大数据处理 on Kubernetes

自2003年Google的三大核心技术GFS(03)、MapReduce(04)、和BigTable(06)的论文陆续发表至今，以Hadoop为代表的大数据处理框架，开始登上历史的舞台，迎来了一个黄金时代。Apache Hadoop是其中最为成功的开源项目，让企业级的大数据处理能力变得唾手可得。围绕Hadoop的学术研究和工业界的探索在过去的十多年里一直保持着火热。

而在另一条时间线上，容器技术在Docker问世后，终于等来了快速发展的6年。与此同时，Kubernetes作为容器编排的开源系统，在过去几年经过一番混战，并借助CNCF社区的推动以及云原生的兴起，也很快成为了业界容器编排的事实标准。如今，几乎所有的云厂商都有一套围绕Kubernetes的容器生态，例如我们阿里云就有ACK、ASK（Serverless Kubernetes）、EDAS、以及ECI(阿里云弹性容器实例)。

 

Data from Google Trends

ASF (Apache Software Foundation) 和CNCF（Cloud Native Computing Foundation），两大相对独立的阵营悄然步入到了一个历史的拐点，我们都期待他们之间会碰撞出怎样的火花。显然，Spark2.3.0 开始尝试原生支持on Kubernetes就是一个重要的时间节点。本文就是主要分享最近调研Spark on Kubernetes的一些总结。

 

从Hadoop说起

Hadoop主要包含以下两个部分：Hadoop Distributed File System (HDFS) 和一个分布式计算引擎，该引擎就是Google的 MapReduce思想的一个实现 。Hadoop一度成为了大规模分布式数据存储和处理的标椎。

Hadoop to Spark

Hadoop在被业界广泛使用的同时，也一直存在很多的问题：

1、只支持Map和Reduce算子，复杂的算法、业务逻辑很难表达，最终只能将逻辑写入算子里面，除了代码不宜维护，还导致调度上没有任何优化空间，只能根据任务数单一纬度来调度。

2、计算的中间结果也要存入HDFS，不必要的IO开销。

3、 TaskTracker 将资源划分为map slot和reduce slot，不够灵活，当缺少某个stage的时候会严重降低资源利用率。

4、…

关于Hadoop的研究也基本是围绕资源调度、MapReduce计算模式、HDFS存储、以及通用性等方面的优化，Spark便是众多衍生系统中最成功的一个。甚至可以说是里程碑级别的，从此关于Hadoop的研究沉寂了很多。2009年由加州大学伯克利分校的AMPLab开发的Spark问世，便很快成为Apache的顶级开源项目。Apache Spark是一个基于内存计算、支持远比MapReduce复杂算子、涵盖批流等多种场景的大数据处理框架。

 

Spark 模块关系图

梳理下Spark中一些主要的概念：

• Application：Spark Application的概念和Hadoop中的 MapReduce类似，指的是用户编写的 Spark 应用程序，相比于Hadoop支持更丰富的算子，而且利用内建的各种库可以很方便开发机器学习、图计算等领域的应用。
• Job：由大量的Task组成的并行计算作业，一个作业通常包含一批RDD及作用于相应RDD上的各种算子。
• Stage：每个作业都会被拆分成很多组Task，每组Task即为一个TaskSet，也被称为Stage，一个作业分为多个Stage。
• Task： 被指定到某个Executor上的执行的任务，Task可以理解为一段逻辑，如果你对大数据开发感兴趣，想系统学习大数据的话，可以加入大数据技术学习交流扣群：458数字345数字782获取学习资源，等待被调度到Excutor的某个线程中执行。
• Operations：即算子，分为1）Action，比如：reduce、collect、count等；2）Transformation，比如：map、join、reduceByKey等。Action会将整个作业切割成多个Stage。
• Executor：Application运行在Worker节点上的一个进程，该进程负责运行Task，每个Application都有各自的一批Executor。Executor的数量可以静态设定好，也可以采用动态资源分配。
• Driver：Spark中的Driver根据提交的Application创建SparkContext，即准备程序的运行环境。SparkContext负责和ClusterManager通信，进行资源的申请、任务的分配等；当所有Executor全部执行完毕后，Driver负责将SparkContext关闭。
• Worker：集群中任何可以运行Application任务的节点。
• Cluster Manager：集群中调度资源的服务。Standalone模式下为Master；Yarn模式下为Yarn中的ResourceManager。

Hadoop to YARN

早期的Hadoop大规模集群也可以达到几千个节点，当数据处理需求不断增长的时候，粗暴的增加节点已经让原生调度系统非常吃力。Application管理和Resource管理的逻辑全部放在Hadoop的 JobTracker中，而 JobTracker又不具备横向扩展的能力，这让JobTracker不负重堪。需要一套方案能将Application管理和Resource管理职责分开，能将计算模式和 JobTracker解耦，YARN就是在这样的背景下诞生的。如今我们常听到的Hadoop其实已经是指Yarn了。

 

 

Yarn 在集群的角色

 

Yarn 模块关系图

Spark调度在最初设计的时候，就是开放式的，而且调度模块之间的关系跟YARN的概念非常吻合。

Spark Master和ResourceManager对应，Spark Worker和NodeManager对应，Spark Driver和Application Master对应，Spark Executor和Container对应。每个Executor能并行运行Task的数量就取决于分配给它的Container的CPU核数。

Client提交一个应用给 Yarn ResourceManager后， Application Manager接受请求并找到一个Container创建该应用对应的Application Master，Application Master会向ResourceManager注册自己，以便client访问。Application Master上运行的就是Spark Driver。Application Master申请 Container并启动，Spark Driver然后在Container里启动 Spark Executor，并调度Spark Task到Spark Executor上的线程执行。等到所有的Task执行完毕后，Application Master取消注册并释放资源。

带来的好处

1、YARN作为集群统一的资源调度和应用管理层，降低了资源管理的复杂性的同时，对所有应用类型都是开放的，即支持混部MapReduce、Spark等，能提高整个集群的资源利用率。

2、两级调度方式，大大降低了ResourceManager的压力，增加了集群的扩展能力。

3、计算模式和资源调度解耦。在调度层，屏蔽了MapReduce、Spark、Flink等框架的计算模式的差异，让这些框架都只用专注于计算性能的优化。

4、可以使用YARN的高级功能，比如：1）原生FIFO之外的调度策略: CapacityScheduler & F