Hadoop复习

Hadoop概述

Hadoop是一个开源框架，允许使用简单的编程模型在跨计算机集群的分布式环境中存储和处理大数据。它的设计是从单个服务器扩展到数千个机器，每个都提供本地计算和存储。

Hadoop发展历史

2002~2004 年，第一轮互联网泡沫刚刚破灭，很多互联网从业人员都失业了。我们们的“主角" Doug Cutting 也不例外，他只能写点技术文章赚点稿费来养家糊口。但是 Doug Cutting 不甘寂寞，怀着对梦想和未来的渴望，与他的好朋友 Mike Cafarella 一起开发出一个开源的搜索引擎 Nutch，并历时一年把这个系统做到能支持亿级网页的搜索。但是当时的网页数量远远不止这个规模，所以两人不断改进，想让支持的网页量再多一个数量级。
在 2003 年和 2004 年， Googles 分別公布了 GFS 和 Mapreduce 两篇论文。 Doug Cutting 和 Mike Cafarella 发现这与他们的想法不尽相同，且更加完美，完全脱离了人工运维的状态，实现了自动化。在经过一系列周密考虑和详细总结后，
2006 年， Dog Cutting 放奔创业，随后几经周折加入了 yahoo 公司(Nutch 的部分也被正式引入)，机绿巧合下，他以自己儿子的一个玩具大象的名字 Hadoop 命名了该项。当系统进入 Yahoo 以后，项目逐渐发展并成熟了起来。首先是集群规模，从最开始几十台机器的规模发展到能支持上千个节点的机器，中间做了很多工程性质的工作；然后是除搜索以外的业务开发， Yahoo 逐步将自己广告系统的数据挖掘相关工作也迁移到了 Hadoop 上，使 Hadoop 系统进一步成熟化了。
2007 年，纽约时报在 100 个亚马逊的虚拟机服务器上使用 Hadoop 转换了 4TB 的图片数据更加加深了人们对 Hadoope 的印象。
在 2008 年的时侯，一位 Google 的工程师发现要把当时的 Hadoop 放到任意一个集群中去运是一件很困难的事情，所以就与几个好朋友成立了ー个专门商业化 Hadoop 的公司 Cloudera。
同年， Facebook 团队发现他们很多人不会写 Hadoop 的程序，而对 SQL 的一套东西很熟，所以他们就在 Hadoop 上构建了一个叫作 Hive 的软件，专把 SQL 转换为 Hadoop 的 Mapreduce 程序。
2011年， Yahoo 将 Hadoop 团队独立出来，成立了ー个子公司 Hortonworks，专门提供 Hadoop 相关的服务。

Hadoop适用范围

• 适用
  • 大规模数据
  • 流式数据（写一次，读多次）
  • 商用硬件（一般硬件）
• 不适用
  • 低延时访问数据（是为高吞吐数据传输设计的，Hbase更适合低延时访问）
  • 大量的小文件（文件元数据存储于NameNode的内存中，太多小文件会消耗过多内存资源）
  • 频繁的修改文件（基本只写一次）

Hadoop优点

• 高可靠性：Hadoop提供了高可用HA服务，能够确保集群的运行正常
• 高扩展性：Hadoop是由中心节点（NameNode）存储的元数据管理集群，添加节点时，只需修改元数据即可，并且数据不与机器进行绑定，只需简单的增加物理机就可以扩大Hadoop的存储空间。扩展性上限取决于中心节点的性能。
• 高效性：Hadoop能够在节点之间动态的移动数据，并保证各个节点的动态平衡，以并行处理的方式加快处理速度，依托机架感知技术，可以减少一定的带宽资源占用。
• 高容错性：Hadoop能够保存数据的多个副本，并且能自动将失败的任务重新进行分配
• 低成本：开源项目，物理机可以是普通商用机。

Hadoop架构

1. Hadoop存储 - HDFS

1.1 HDFS概述

Hadoop的存储系统是HDFS(Hadoop Distributed File System)分布式存储系统。通常将一个大文件分为多个block存储在不同服务器的多个节点中。为防止文件丢失，会为每个文件复制多个副本（默认3个），1个副本放置在同机架不同节点上，另一个放置在不同机架的节点上。

1.2 HDFS的核心组件

• NameNode
  1. 存储namespace（NS）、所有文件及目录的元数据信息（metadata），这些信息是存储在内存中的。
  2. 元数据持久化分两种fsimage/edit log。fsimage：NameNode启动时对整个文件系统的快照。edit log：NameNode启动后对文件改动的序列。NameNode内存中存储=fsimage + edit log。
  3. NameNode启动过程：加载fsimage（旧）文件，应用edit log（旧）文件，更新到fsimage（新）文件，生成edit log（新）文件
  4. HDFS的副本保存数量由NameNode保存，并由NameNode统一调度与DataNode进交互。
  5. NameNode异常时，整个集群不可用。2.0.0版本后，集群增加HA，主备节点共享edit log , DataNode需要同时向主备节点发送消息，当主节点异常时，通过zk或者QJM选举主节点。
• DataNode
  1. 数据节点，保存具体的block。
  2. 负责数据的读写操作和复制操作。
  3. NN与DN的关系为master/worker关系，DataNode会定时向NameNode反馈状态和block信息。所有的通讯协议都是基于TCP/IP协议。在设计上，NameNode不会主动发起RPC，而是响应客户端或DataNode的RPC请求。
  4. DataNode之间会进行通信，复制数据块，保证数据的冗余性。
• Block
  1. 基本的存储单位，一般为64M或128M。增大block块可以减少数据搜寻时间，减轻NameNode压力，减少建立网络连接的压力。
  2. 一个大文件会拆分成多个块，可能存储在多台机器。如果文件小于block块大小，实际占用空间为其本身大小。
  3. 每个块都会复制多份当做副本，副本数量和存储位置由NameNode控制。
• Secondary NameNode
  1. 并非字面意义上的第二节点，主要是为NameNode提供一个CheckPoint，可以算是检查节点。
  2. NameNode在运行过久后，edit log会变得很大，在重启的时候，加载edit log会导致启动时间过长。Secondary NameNode会定时拉取NameNode的edit log并更新到自己的fsimage上，然后将新fsimage拷贝回NameNode并重置edit log。NameNode下次重启时会使用新的fsimage，从而减少重启时间。
  3. 在NameNode宕机时， Secondary NameNode只能恢复部分数据，要保障集群的运行，还是需要增加HA。
• HDFS Federation
  1. HDFS的文件上限受限于NameNode的内存，Federation提供了一种横向扩展NameNode的方式，使集群能够同时存在多个NameNode。
  2. 每个NameNode管理一个NameSpace Volume，包括命名空间的元数据和此命名空间下的所有Block的数据块池（Block pool）。
  3. 各个NameNode相互独立，不需要互相协调，各自分工管理自己的区域，即使某个NameNode失效也不会影响其他节点。
  4. 数据块池不再切分，因此所有DataNode都要注册到每个NameNode且周期性向所有NameNode发送心跳和块报告，并且存储所有数据块池，同时处理来自所有NameNode的指令。

2. Hadoop计算 - MapReduce

2.1 MapReduce概述

MapReduce是一种编程模型，用于大规模数据集的并行运算，主要思想为“Map（映射）”和“Reduce（归纳）”，可以把MapReduce理解为，把一堆杂乱无章的数据按照某种特征归纳起来，然后处理并得到最后的结果。Map面对的是杂乱无章的互不相关的数据，它解析每个数据，从中提取出key和value，也就是提取了数据的特征。经过MapReduce的Shuffle阶段之后，在Reduce阶段看到的都是已经归纳好的数据了，在此基础上我们可以做进一步的处理以便得到结果。

2.2 Hadoop MapReduce1.0架构（MRv1）

2.2.1 MRv1组件

• 客户端
  1. 用户编写的MapReduce程序通过client提交到JobTracker。
  2. 用户可以通过client的一些端口查看作业运行状态
• JobTracker
  1. 负责资源监控和作业调度。
  2. 监听所有TaskTracker和job的状态，一但发现失败，就将相应的任务转移到其他节点。
  3. 会跟踪任务的执行状态和资源使用量信息，并将这些信息告诉任务调度器（TaskScheduler），调度器会在资源出现空闲时，选择合适的任务去使用这些资源。
• TaskTracker
  1. 会周期性通过心跳机制将节点上的各种信息汇报给JobTracker
  2. 执行JobTracker下达的各种命令，包括：启动任务、提交任务、杀死任务和重新初始化任务。
• HDFS
  1. 保存数据的输出结果

2.2.2 MRv1的局限性

• JobTracker是MapReduce的集中处理点，存在单点故障隐患。
• JobTracker负责太多的功能，会占用更大的资源，当job非常多的时候，会造成更大的内存开销，潜在的增加了失败的风险。MRv1能够支撑的节点上限大概在4000个节点。
• 在TaskTracker端，对于map/reduce task的资源划分过于简单，如果几个极耗内存的task分配在同一台机器，容易造成OOM。
• 在TaskTracker端，将资源划分为map slot和reduce slot，而两者之间不允许共享，当机器上只执行其中一个task时，会造成资源浪费。
• 多框架计算互相抢占资源，storm,spark,mr计算框架很难共存。

2.2 Hadoop MapReduce2.0架构（MRv2）

2.2.1 MRv2架构

• client
  客户端，主要用来提交作业。
• ResourceManager
  Yarn的资源管理器，全局管理所有应用程序计算资源的分配。
• NodeManager
  Yarn节点管理器，负责启动和监听集群机器上的计算容器。
• MRAppMaster
  负责MapReduce任务的调度和监控。
• HDFS
  保存数据的输出结果。

2.2.2 MRv2的优势

MRv2重构的主要思想是将JobTracker的资源管理和任务调度/监控功能拆分成单独的组件，拆分后，新的yarn资源管理器将接管集群所有资源分配，而MRAppMaster将接管任务调度和监控功能，避免了旧架构的单点问题和资源利用率问题。

2.3 MapReduce运行机制

1. 输入分片（input split）
在进行map计算之前，mapreduce会根据输入文件计算输入分片（input split），每个输入分片对应一个map任务，输入分片存储的并非数据本身，而是一个分片长度和一个记录数据位置的数组。input split 和hdfs的block关系密切，假如hdfs的block大小为64M，如果我们输入两个文件大小分别为10M和70M，那么mapreduce会将10M的文件作为一个input split，70M的会分为2个input split（64M+6M），最终将会有3个map任务将执行，而且每个map处理的数据大小不均匀，这会导致任务运行时间过长，后续可针对此问题优化。
2. 解析阶段
根据输入片中的记录按照一定规则解析成键值对。
3. map阶段
将解析出来的键值对由用户自己编写的map函数处理，并产生一系列新的key/value。这一过程任务会分配到存放着所需数据的节点上进行计算。
4. shuffle阶段
shuffle就是将Map的输出进行整合，然后作为reduce的输入发送给reduce，简单理解就是把所有map的输出，按照key进行排序，并且把相对应的键值对整合到同一个组中。
5. reduce阶段
与map阶段类似，根据用户编写的逻辑，对分组后的键值进行处理。
6. output阶段
将最终结果输出到HDFS中。

3. Hadoop资源管理 - YARN

3.1 YARN概述

YARN，全称Yet Another Resource Manager，是Hadoop 2.x版本增加的新的资源管理框架。YARN就是将JobTracker的职责进行拆分，将资源管理和任务调度监控分成独立的进程：一个全局的资源管理和一个每个作业的管理。ResourceManager和NodeManager提供了计算资源的分配和管理，ApplicationMaster则完成了任务的运行。在YARN架构下，形成了一个通用的资源管理平台和一个通用应用计算平台，避免了旧架构的单点问题和资源利用率问题，并且也让其运行的程序不再局限于MR形式。

3.2 YARN核心组件

• ResourceManager
  • 全局资源管理器，负责整个系统的资源管理和分配，主要有2个组件构成：调度器（scheduler）和应用程序管理器（ApplicationManager）
  • 调度器负责分配最少满足任务运行的资源给任务。调度器只基于ApplicationMaster申请的资源进行调度。
  • ApplicationManager负责处理客户端提交的job，并协调第一个Container供ApplicationMaster运行，并且在AppMaster失败时，重新启动。
  • 管理NodeManager，接收来自NodeManager的资源汇报情况，并下达管理命令。
• NodeManager
  • 单个节点的资源监控和管理
  • 主要负责启动ResourceManager分配给AppMaster的Container（任务运行的容器）。
• ApplicationMaster
  • ApplicationMaster是特定计算框架的一个实例，每种计算框架都有自己的AppMaster.
  • 负责向ResourceManager报告状态，与调度器协商资源，与NodeManager协同合作启动Container，对失败节点进行处理。
• Container
  • 运行在NodeManager上。
  • 是Yarn对计算资源的一个抽象，它其实是一组CPU和内存资源，所有的应用都会运行在Container中。
  • Container是由ApplicationMaster向ResourceManger申请的，然后经由sheduler分配给AppMaster
  • Container的运行是由AppMaster向NodeManager发起的。启动时，会加载所需要的环境变量和资源（例如jar包、配置文件）。

3.3 YARN的优势

1. 可扩展性
相较于MRv1，得益于Yarn的资源管理器和ApplicationMaster分离架构，Yarn可以在更大规模的集群上运行。
2. 可用性
YARN先为资源管理器提供高可用性，再为应用提供高可用，应用之间互不干扰，并且会对失败的任务进行重试。
3. 利用率
在YARN中，一个节点管理器管理一个资源池，不再有特定的资源划分，应用能够按照自己的需求申请特定大小的资源，对于集群的整体利用率提高了。
4. 多租户
能够支撑更多的应用和计算框架，不再局限于MR。

3.4 YARN的调度FIFO.CS,FS

3.4.1 FIFO调度器（FIFO Scheduler）

FIFO调度器将应用放置在一个资源队列里，然后根据提交的顺序（先进先出）运行程序，首先为队列的第一个应用请求分配资源，第一个应用被满足后才会分配资源给下一个任务。优点是简单易懂，无需配置，但是不适合共享集群，大的应用会占用整个集群的资源，每个应用需要排队直到轮到自己运行。

3.4.2 容量调度器（Capacity Scheduler）

容量调度器允许多个组织共享一个Hadoop集群，每个组织会配置一个专门的队列，每个队列会分配到一部分资源。队列可以继续详细划分，这样组织内不同用户可以共享分配的资源，在同一队列里，使用FIFO调度策略对应用进行调度。
使用容量调度器，一个独立的资源队列，可以保障小任务一提交就可以运行，由于队列容量是为队列所保留的，因此这个策略是以牺牲集群整体利用率为代价。对于一个大任务来说，永远无法占用全部的集群资源，而且如果某个资源队列长期没有任务运行的话，会造成集群的资源浪费。
当某个队列中有多个任务运行，而且队列资源不够时，但集群仍有空闲资源，那么容器调度器可能会将空余的资源分配给队列中的任务，这部分资源叫做弹性队列。为防止弹性队列占用集群的全部资源，为队列设置一个最大资源数限制。

3.4.3 公平调度器（Fair Scheduler）

公平调度器旨在为所有运行在集群上的任务提供一个公平的资源分配。假设目前有A,B两个队列，资源配比50:50，当A启动任务Job1时，会占用集群的全部资源，此时B启动Job2时，调度器会从Job1中抢占一半资源分配给Job2，此时两个任务各占一半资源。当B启动Job3时，调度器会从Job2中抢占一半资源分配给Job3，最终任务占用资源比为Job1 : Job2 : Job3 = 50 : 25 : 25。最终公平调度器实现了：用户之间的公平分配（A : B = 50 ： 50），用户中任务的公平分配（Job2 : Job3 = 25 : 25 ）。
公平调度器支持“抢占”功能，就是允许调度器中止占用超过其公平份额的资源，这些资源释放后用于资源数低于应得份额的队列。这样的后果会降低整个集群的效率，因为被中止的资源中的任务需要重新执行。
公平调度器并不一定50：50就是公平，在配置文件中可以配置，例如A和B的资源配置为60:40，那么当资源比是60:40时，就认为是公平的。

4. 其他生态系统

4.1 Hive（数据仓库）

Hive是建立在Hadoop上的数据仓库的基础框架。Hive定义了一种类似于SQL的查询语言HQL，通常用于离线分析。
HQL可以让不熟悉MR的编程人员也能编写数据查询语句，这些语句会被翻译为Hadoop上运行的MR任务。

4.2 Hbase（分布式列存储数据库）

Hbase是一个建立在HDFS上，针对结构化数据的可伸缩、高可靠、高性能、分布式和面向列的动态模式数据库。Hbase采用BigTable数据模型：增强的稀疏排序映射表（key/value），其中键由行关键字、列关键字和时间戳构成。Hbase提供了对大规模数据的随机、实时读写访问。
Hbase特点：
1. 大：一个表可以有数十亿行，上百万列。
2. 无模式：每行有一个可排序的主键和任意多的列，列可以根据需求动态增加，一张表中不同行可以有不同的列。
3. 面向列：面向列的存储和权限控制，列独立索引。
4. 稀疏：Null列不会占用存储空间。
5. 数据多版本：可以同时存在多个版本的数据，默认情况下以插入时间戳为版本号。

4.3 Spark（内存计算引擎）

Spark是专门为大数据处理而设计的快速通用计算引擎。Spark是类Hadoop MapReduce的通用并行计算框架。与Hadoop MapReduce不同的是，Spark的Job中间输出结果可以写在内存中，因此Spark在内存中运行速度相较于Hadoop MapReduce可以提高100倍。

4.4 Flume（日志收集工具）

Cloudera开源的一个日志收集系统，具有分布式、高可靠、高容错、易于定制和扩展的特点。
它将数据从产生、传输、处理到最终写入目标路径的过程抽象为数据流。Flume支持定制数据发送方，从而支持收集各种不同协议数据。同时Flume提供对日志的简单处理。此外，Flume还能将数据写入各种数据目标的能力。

4.5 Sqoop（数据ETL/同步工具）

Sqoop是SQL-to-Hadoop的简写。主要用于传统数据库和Hadoop之间传输数据。数据的导入和导出，本质上是MR程序，因此充分利用了MR的并行性和容错性。

4.6 Zookeeper（分布式协作服务）

Zookeeper是一个开源的分布式应用程序协作服务，是Hadoop的重要组件。它为一个分布式应用提供了：配置维护、域名服务、分布式同步、组服务等功能。

4.7 Tez（DAG计算模型）

Tez是开源的支持DAG作业的计算框架，它源于MapReduce框架，但是核心思想是将MapReduce两个操作进一步拆分。
目前hive支持MR和Tez计算模型，Tez能够显著的提升计算效率。

4.8 Storm（实时处理系统）

Storm是一个分布式实时大数据处理系统。它是一个流处理框架，可用于连续计算，对数据流进行连续的查询。Storm保证每个消息都会得到处理。

4.9 Kafka（分布式消息队列）

Kafka是一个高吞吐量的分布式发布订阅消息系统。具有高性能，持久化，多副本备份，横向扩展能力。生产者往队列写入消息，消费者能够从队列里取出消息进行业务逻辑。

参考文献

1. Hadoop权威指南-大数据的存储与分析（第四版）
2. https://www.w3cschool.cn/hadoop
3. https://www.cnblogs.com/binarylei/p/8903601.html
4. https://blog.csdn.net/wdr2003/article/details/79692886
5. https://www.cnblogs.com/gridmix/p/5102694.html