神刀安全网

Hadoop年度回顾与2016发展趋势

董西成,Hulu 网,专注于分布式计算和资源管理系统等相关技术。《Hadoop 技术内幕:深入解析 MapReduce 架构设计与实现原理》和《Hadoop 技术内幕:深入解 析 YARN 架构设计与实现原理》作者,dongxicheng.org 博主。

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 :数据被写入内存中,同时会往该存储介质中再(异步)写一份。

Hadoop年度回顾与2016发展趋势

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

Hadoop年度回顾与2016发展趋势

这张表给出了 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 的关系会逐步朝下图展示的方式发展:

Hadoop年度回顾与2016发展趋势

也就是说,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 麻烦)。

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

Hadoop年度回顾与2016发展趋势

这是一个可能的部署图。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 的方式如下,大家感受下:

Hadoop年度回顾与2016发展趋势

当然,目前 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!等。

原文  http://h2ex.com/569

转载本站任何文章请注明:转载至神刀安全网,谢谢神刀安全网 » Hadoop年度回顾与2016发展趋势

分享到:更多 ()

评论 抢沙发

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址
分享按钮