Hadoop年度回顾与2016发展趋势

Hadoop 2015 技术发展与 2016 发展趋势

Hadoop 部分分为 HDFS 和 YARN 两部分，首先介绍 HDFS 在 2015 年的进展。

HDFS

HDFS 在 2015 年有几个重大特性发布，我列出三个最为突出的：

1. 异构存储介质
2. Truncate 操作的支持，也就是 append 逆操作（HDFS-3107）
3. 异构数据块的支持，即同一文件数据块大小可以不一样，用户可在 append API 中设置 CreateFlag.APPEND 或 CreateFlag.NEW_BLOCK，以决定是继续往最后一个 block 中写数据，还是写到一个新的 block 中。

异构存储介质的支持，使得 HDFS 朝着异构混合存储方向发展。

我们都知道，HDFS 之前是一个以磁盘单存储介质为主的分布式文件系统。但随着近几年新存储介质的兴起，支持多存储介质早就提上了日程。目前，HDFS 已经对多存储介质有了良好的支持，包括 Disk、Memory 和 SSD 等。

HDFS 具体支持的介质如下：

• ARCHIVE：高存储密度但耗电较少的存储介质，通常用来存储冷数据。
• DISK：磁盘介质，这是HDFS最早支持的存储介质。
• SSD：固态硬盘，是一种新型存储介质，目前被不少互联网公司使用。
• RAM_DISK ：数据被写入内存中，同时会往该存储介质中再（异步）写一份。
</ul>



这是 HDFS 异构存储介质示意图，我们可以通过参数 dfs.datanode.data.dir 指定每块盘的类型，这样，当写文件时，可以指定文件存储到某种存储介质上。



这张表给出了 HDFS 支持的存储策略，不同的策略，存储方式是不同的。用户可以针对不同类型的文件，定制相应的存储策略。

说到异构存储，很多人可能会想到 Spark 社区提出的 Tachyon，它是 Distributed cache system on HDFS，最初是为了解决不同应用程序间共享 RDD 而产生的，现已发展成通用系统。

但很不幸，HDFS 社区的也正在做类似的事情，有两个重大 feature，大家可以关注下：

• Centralized CacheManagement (HDFS-4949)，允许用户指定将某些文件或目录缓存到内存中。
• DDM：Discardable Distributed Memory（HDFS-5851），使用 YARN 作为资源管理系统，管理内存资源。

在 HDFS 之上单独搞多存储介质支持是不太友好的，最好跟 Hadoop 中资源管理系统 YARN 做一个结合，所以，有人预测，HDFS 和 YARN 的关系会逐步朝下图展示的方式发展：



也就是说，YARN 统一管理异构存储介质和资源，包括磁盘，SSD，网络，CPU 和 memory，并将这些资源分配给 MapReduce，HBase，甚至 HDFS。

YARN

在2015年，YARN 取得了重大进展，本来准备了 5 个特性，由于时间关系，今天主要介绍三个：

1. 基于标签的调度
2. 对长服务的支持
3. 对 Docker 的支持

这个特性使得 YARN 能够更好地支持异构集群调度。它的基本思想是，管理员可为每个 NodeManager 赋予一个或多个标签（就是一字符串），之后在调度器中配置资源队列与 label 的对应关系（目前仅支持 Capacity Scheduler），这样，管理员就实现了：按照节点类型将 YARN 分成若干个逻辑上相互独立（可能交叉）的集群。这种集群跟物理上独立的集群很不一样，用户可以很容易地通过动态调整 label，实现不同类型节点数目的增减，这具有很好的灵活性。

给大家举两个例子，这都是在 Hulu 内部的实际应用：

1. 一个 Hadoop 集群，20 台服务器，一半高配置，一半低配置，如何将 Spark 作业仅运行在高配置的 NodeManager 上。
2. 一个 Hadoop 集群，1,000 台机器，只想让 Docker 运行在某 10 个 NodeManager 上（安装和维护 Docker engine 麻烦）。

这两种应用场景，都可以很好地使用标签调度解决



这是一个可能的部署图。YARN 在 2015 年新增的另外一个重大特性是：支持长服务。

YARN 的最终定位是通用资源管理和调度系统，包括支持像类似 MapReduce，Spark 的短作业和类似 Web Service，MySQL 的长服务。 支持长服务是非常难的一件事情，YARN 需要解决以下问题：服务注册、日志滚动、ResourceManager HA、NodeManager HA（NM 重启过程中，不影响 Container）和 ApplicationMaster 永不停止，重启后接管之前的 Container。

目前 Apache 有个二级项目叫 Apache Slider，可以帮助用户把已有应用或服务运行在 YARN 上，比如 HBase，Presto 等都已经通过 Slider 部署到 YARN 上。

YARN 第三个重大特性是实现了一个简易版 Docker On YARN。

实现思路是：YARN 的 ContainerExecutor 是可插拔的，目前提供了两种实现：DefaultContainerExecutor 和 LinuxContainerExecutor，而 Docker On YARN 正是通过引入第三种 ContainerExecutor 实现的，叫 DockerContainerExecutor

在 YARN 上运行一个 Docker Container 的方式如下，大家感受下：



当然，目前 YARN 自带的 Docker On YARN 是有很多局限性的，包括：

• ContainerExecutor 是系统级别配置，只能配置一个，这意味着用户如果在 YARN 中运行 Docker Container，就不能再运行 MapReduce，Spark 等其他类型的应用程序。
• 难以同时运行多个 Docker Container 。
• 需自己编写 Application On YARN 解决容错等问题。

为此，Hulu 内部自己开发了 Voidbox，一个较好的 Docker On YARN 方案。Hulu 的 Docker On YARN 方案叫 Voidbox，它提供了丰富的编程 API，支持 DAG Batch job 和 Long running Service 两种应用，具备良好的容错性。

由于篇幅关系，感兴趣的同学可参考我的技术博客：http://dongxicheng.org/mapreduce-nextgen/voidbox-docker-on-hadoop-hulu/

2016 年发展趋势

对于 HDFS，会朝着异构存储介质方向发展，尤其是对新兴存储介质的支持。对于 YARN，会朝着通用资源管理和调度方向发展，而不仅仅限于大数据处理领域，包括对 MapReduce、Spark 短作业的支持，以及对 Web Service 等长服务的支持。

Q & A

1、Yarn 支持长服务？什么是长服务？长连接服务吗？

长服务是指永不停止的应用应用程序（除非异常退出或用户主动关闭），比如 Web Server，MySQL 等，长服务是相对短作业而言的，短作业是指分钟，小时级别就会退出的应用程序。

2、我们用 0.x 版本的 Hadoop 的时候，集群从 100 台升级到 200 台调度器遇到瓶颈。Yarn 的调度算法有这方面的优化吗？一般能达到多大的集群？

Yarn 有优化的，规模上千台都不会有瓶颈，应该没有问题。0.x 版本调度器实现非常差，遇到瓶颈不足为奇。

3、讲的例子中一部分高配机器，一部分低配机器，运行某任务只用高配的，是为什么，多一些不更好吗？还是说为了防止出现低配节点过长时间等待的问题？

一般而言，公司的集群都是异构的，比如刚开始（N年前）买的是 24GB 机器，后来又买了 48GB 机器，最近买的是 128GB 内存，对于一些特殊的应用，对资源要求比较高，比如 Spark，机器越好，跑的越快，这时候将 Spark 运行在高配置机器上是很好地选择（如果同时运行在高配置和低配置机器中，可能让慢任务拖后腿，非常不利于 Spark 的运行），低配置的可以用来跑 MapReduce 等离线应用。你说的防止出现低配节点过长时间等待的问题，也是一个原因。

4、上文提到了 YARN 新特性支持 Docker，Docker 也有一个资源管理项目 Mesos，如果 YARN 从 Mesos 来获取资源的话是否也是可行？ 因为在晚上的时候业务对资源使用是一个峰谷，而离线任务恰恰在晚上需要大量计算资源。

YARN 从 Mesos 来获取资源是可行的，好像也有开源项目（需要对 YARN 进行适当修改）在做。但是我怀疑这种方案的维护成本，YARN 和 Mesos 都是一个分布式资源管理系统，是复杂度较高的系统，将两个系统叠加起来用，稳定性是不容易保证的。

5、Storm、MR，Spark 这些 CPU 密集型的任务是否应该放到不同 YARN 中？

Storm、MR，Spark 这些任务（他们全是 CPU 密集型的，Spark 是内存密集型，MR 是 IO 密集型）可以混合运行在 YARN 集群中，让 YARN 统一管理和调度，很多公司都是这么做的，包括 Hulu，Yahoo！等。

</div>