Hadoop是一个由Apache基金会所开发的分布式系统基础架构。用户可以在不了解分布式底层细节的情况下，开发分布式程序。充分利用集群的威力进行高速运算和存储。Hadoop实现了一个分布式文件系统（Hadoop Distributed File System），其中一个组件是HDFS。HDFS有高容错性的特点，并且设计用来部署在低廉的（low-cost）硬件上；而且它提供高吞吐量（high throughput）来访问应用程序的数据，适合那些有着超大数据集（large data set）的应用程序。HDFS放宽了（relax）POSIX的要求，可以以流的形式访问（streaming access）文件系统中的数据。Hadoop的框架最核心的设计就是：HDFS和MapReduce。
HDFS为海量的数据提供了存储，
而MapReduce则为海量的数据提供了计算。
文章目录
（一）前言
Hadoop是Apache软件基金会发起的一个项目，在大数据分析以及非结构化数据蔓延的背景下，Hadoop受到了前所未有的关注 。
Hadoop是一种分布式数据和计算的框架。它很擅长存储大量的半结构化的数据集。数据可以随机存放，所以一个磁盘的失败并不会带来数据丢失。Hadoop也非常擅长分布式计算——快速地跨多台机器处理大型数据集合。
Hadoop特性
Hadoop是一个能够对大量数据进行分布式处理的软件框架，并且
是以一种可靠、高效、可伸缩的方式进行处理的，它具有以下几个方
面的特性：
• 高可靠性
• 高效性
• 高可扩展性
• 高容错性
• 成本低
• 运行在Linux平台上
• 支持多种编程语言
Hadoop大数据处理的意义
Hadoop得以在大数据处理应用中广泛应用得益于其自身在数据提取、转换和加载(ETL)方面上的天然优势。Hadoop的分布式架构，将大数据处理引擎尽可能的靠近存储，对例如像ETL这样的批处理操作相对合适，因为类似这样操作的批处理结果可以直接走向存储。Hadoop的MapReduce功能实现了将单个任务打碎，并将碎片任务(Map)发送到多个节点上，之后再以单个数据集的形式加载(Reduce)到数据仓库里。
Hadoop1.0的局限与不足
Hadoop1.0的核心组件（仅指MapReduce和HDFS，不包括Hadoop生态系统内的Pig、Hive、HBase等其他组件），
主要存在以下不足：
- 抽象层次低，需人工编码
- 表达能力有限
- 开发者自己管理作业（Job）之间的依赖关系
- 难以看到程序整体逻辑
- 执行迭代操作效率低
- 资源浪费（Map和Reduce分两阶段执行）
- 实时性差（适合批处理，不支持实时交互式）
（二）针对Hadoop1.0的改进与提升
Hadoop的优化与发展主要体现在两个方面：
-
一方面是Hadoop自身两大核心组件MapReduce和HDFS的架构设计改进
-
- 1、HDFS存在问题
NameNode单点故障，难以应用于在线场景
NameNode压力过大，且内存受限，影响系统可扩展性
- 1、HDFS存在问题
-
- 2、MapReduce存在的问题
JobTracker访问压力大，影响系统可扩展性
难以支持除MapReduce计算框架之外的计算框架、比如spark、storm
- 2、MapReduce存在的问题
-
另一方面是Hadoop生态系统其它组件的不断丰富，加入了Pig、Tez、Spark和Kafka等新组件
-
- Hadoop1.0只支持离线计算，不支持spark内存计算框架(专为大规模数据处理而设计的快速通用的计算引擎)，storm是流式计算框架（计算实时数据）
Hadoop框架自身的改进：从1.0到2.0
| 组件 | hadoop1.0的问题 | Hadoop2.0的改进 |
|---|---|---|
| HDFS | 单一名称节点，存在单点失效问题 | 设计了HDFS HA，提供名称节点热备机制 |
| HDFS | 单一命名空间，无法实现资源隔离 | 设计了HDFS Federation，管理多个命名空间 |
| MapReduce | 资源管理效率低 | 设计了新的资源管理框架YARN |
不断完善的Hadoop生态系统
| 组件 | 功能 | 解决Hadoop1.0存在的问题 |
|---|---|---|
| Pig | 处理大规模数据的脚本语言，用户只需要编写几条简单的语句，系统会自动转换为MapReduce作业 | 抽象层次低，需要手工编写大量代码 |
| Spark | 基于内存的分布式并行编程框架，具有较高的实时性，并且较好支持迭代计算 | 延迟高，而且不适合执行迭代计算 |
| Oozie | 工作流和协作服务引擎，协调Hadoop上运行的不同任务 | 没有提供作业（Job）之间依赖关系管理机制，需要用户自己处理作业之间依赖关系 |
| Tez | 支持DAG作业的计算框架，对作业的操作进行重新分解和组合，形成一个大的DAG作业，减少不必要操作 | 不同的MapReduce任务之间存在重复操作，降低了效率 |
| Kafka | 分布式发布订阅消息系统，一般作为企业大数据分析平台的数据交换枢纽，不同类型的分布式系统可以统一接入到Kafka，实现和Hadoop各个组件之间的不同类型数据的实时高效交换 | Hadoop生态系统中各个组件和其他产品之间缺乏统一的、高效的数据交换中介 |
新一代资源管理调度框架YARN
MapReduce1.0的缺陷
（1）存在单点故障
（2）JobTracker“大包大揽”导致任务过重（任务多时内存开销大，上限4000节点）
（3）容易出现内存溢出（分配资源只考虑MapReduce任务数，不考虑CPU、内存）
（4）资源划分不合理（强制划分为slot ，包括Map slot和Reduce slot）
YARN架构思路：将原JobTacker三大功能拆分
到了Hadoop2.0以后，MapReduce1.0中的资源管理调度功能，被单独分离出来形成了YARN，它是一个纯粹的资源管理调度框架，而不是一个计算框架。
YARN体系结构
ResourceManager
- 处理客户端请求
- 启动/监控ApplicationMaster
- 监控NodeManager
- 资源分配与调度
ApplicationMaster
- 为应用程序申请资源，并分配给内部任务
- 任务调度、监控与容错
NodeManager
- 单个节点上的资源管理
- 处理来自ResourceManger的命令
- 处理来自ApplicationMaster的命令
（三）Hadoop3.0简介
Hadoop 2.0是基于JDK 1.7开发的，而JDK 1.7在2015年4月已停止更新，这直接迫使Hadoop社区基于JDK 1.8重新发布一个新的Hadoop版本，而这正是hadoop 3.0。
Hadoop 3.0要求JDK版本不低于1.8，对之前的Java版本不再提供支持。
Hadoop 3.0中引入了一些重要的功能和优化，包括HDFS 可擦除编码、多Namenode支持、MR Native Task优化、YARN基于cgroup的内存和磁盘IO隔离、YARN container resizing等。
Hadoop3端口号
在Hadoop3.x中，部分服务默认端口修改，不再绑定到Linux临时端口 (HDFS-9427,HADOOP-12811)
| 分类 | 应用 | Haddop 2.x | Haddop 3 |
|---|---|---|---|
| NNPorts | Namenode | 8020 | 9820 |
| NNPorts | NN HTTP UI | 50070 | 9870 |
| NNPorts | NN HTTPS UI | 50470 | 9871 |
| SNN ports | SNN HTTP | 50091 | 9869 |
| SNN ports | SNN HTTP UI | 50090 | 9868 |
| DN ports | DN IPC | 50020 | 9867 |
| DN ports | DN | 50010 | 9866 |
| DN ports | DN HTTP UI | 50075 | 9864 |
| DN ports | Namenode | 50475 | 9865 |
| YARN ports | YARN UI | 8088 | 8088 |
HDFS新功能与特性
(1)支持HDFS中的擦除编码Erasure Encoding
Erasure coding纠删码技术简称EC,是一种数据保护技术.最早用于通信行业中数据传输中的数据恢复,是一种编码容错技术.他通过在原始数据中加入新的校验数据,使得各个部分的数据产生关联性.在一定范围的数据出错情况下,通过纠删码技术都可以进行恢复.EC技术可以防止数据丢失，又可以解决HDFS存储空间翻倍的问题。
创建文件时，将从最近的祖先目录继承EC策略，以确定其块如何存储。与3路复制相比，默认的EC策略可以节省50％的存储空间，同时还可以承受更多的存储故障。
建议EC存储用于冷数据，由于冷数据确实数量大，可以减少副本从而降低存储空间，另外冷数据稳定，一旦需要恢复数据，对业务不会有太大影响。
(2) 基于HDFS路由器的联合
HDFS基于路由器的联合会添加一个RPC路由层，提供多个HDFS命名空间的联合视图。这与现有ViewFs和HDFS联合功能类似），不同之处在于安装表由服务器端由路由层而不是客户端进行管理。这简化了对现有HDFS客户端的联合集群的访问。与现有ViewFs和HDFS联合功能类似），不同之处在于安装表由服务器端由路由层而不是客户端进行管理。这简化了对现有HDFS客户端的联合集群的访问。
(3)支持多个NameNode
允许用户运行多个备用NameNode。例如，通过配置三个NameNode和五个JournalNode，群集能够容忍两个节点的故障，而不是一个故障。
但是Active的NameNode始终只有1个，余下的都是Standby。 Standby NN会不断与JN同步，保证自己获取最新的editlog，并将edits同步到自己维护的image中去，这样便可以实现热备，在发生failover的时候，立马切换成active状态，对外提供服务。同时，JN只允许一个active状态的NN写入
(4)DataNode内部添加了负载均衡 Disk Balancer
支持单个Datanode上，不同硬盘间的数据balancer。老版本的hadoop只支持在Datanode之间进行balancer，每个节点内部不同硬盘之间若发生了数据不平衡，则没有一个好的办法进行处理。现在可以通过hdfs diskbalancer命令，进行节点内部硬盘间的数据平衡。该功能默认是关闭的，需要手动设置参数dfs.disk.balancer.enabled为true来开启。
MapReduce新功能与特性
（1）MapReduce任务级本地优化（引入Native Task加速计算）
为MapReduce增加了C/C++的map output collector实现（包括Spill，Sort和IFile等），通过作业级别参数调整就可切换到该实现上。
本地库将使用-Pnative自动生成。用户可以通过设置mapreduce.job.map.output.collector.class = org.apache.hadoop.mapred来选择新的收集器。
nativetask.NativeMapOutputCollectorDelegator的作业配置。对于shuffle密集型工作，这可能会提高30％以上的速度。
（2）MapReduce内存参数自动推断
在Hadoop 2.0中，为MapReduce作业设置内存参数非常繁琐，涉及到两个参数：mapreduce.{map,reduce}.memory.mb和mapreduce.{map,reduce}.java.opts，一旦设置不合理，则会使得内存资源浪费严重，比如将前者设置为4096MB，但后者却是“-Xmx2g”，则剩余2g实际上无法让java heap使用到。
有了这个JIRA，我们建议根据可以调整的经验比例自动设置Xmx。如果用户提供，Xmx不会自动更改。
YARN新功能与特性
（1）YARN资源类型
YARN资源模型已被推广为支持用户定义的可数资源类型，超越CPU和内存。例如，集群管理员可以定义诸如GPU，软件许可证或本地附加存储器之类的资源。YARN任务可以根据这些资源的可用性进行调度。
（2）YARN Timeline Service v.2
提供YARN时间轴服务v.2 alpha 2，以便用户和开发人员可以对其进行测试，并提供反馈意见和建议，使其成为Timeline Service v.1.x的替代品。它只能用于测试能力。
Yarn Timeline Service V2提供一个通用的应用程序共享信息和共享存储模块。可以将metrics等信息保存。可以实现分布式writer实例和一个可伸缩的存储模块。同时，v2版本在稳定性和性能上面也做出了提升，原先版本不适用于大集群，v2版本使用hbase取代了原先的leveldb作为后台的存储工具。
参考
- 徐继业，朱洁华，王海彬编,气象大数据,上海科学技术出版社,2018.09
- 饶文碧主编,Hadoop核心技术与实验,武汉大学出版社,2017.04
- https://hadoop.apache.org/docs/stable/
- hadoop3.0新特性总结: https://www.cnblogs.com/yujianming/p/8309045.html