文章目录
- 分布式文件系统Hadoop（一）了解原理
- Hadoop
- HDFS
- HDFS HA(High Availability高可用性)
- YARN
- MapReduce文件系统
分布式文件系统Hadoop（一）了解原理
Hadoop
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这个名字不是一个缩写，而是一个虚构的名字。该项目的创建者，Doug Cutting解释Hadoop的得名 ：“这个名字是我孩子给一个棕黄色的大象玩具命名的。我的命名标准就是简短，容易发音和拼写，没有太多的意义，并且不会被用于别处。小孩子恰恰是这方面的高手
Hadoop是一个模仿Google大数据技术的开源实现。是一个开源的分布式存储和分布式计算框架。
Hadoop是一个开源 + 分布式存储（HDFS）＋分布式计算平台（MapReduce）。
优点
1.高可靠性。Hadoop按位存储和处理数据的能力值得人们信赖 。
2.高扩展性。Hadoop是在可用的计算机集簇间分配数据并完成计算任务的，这些集簇可以方便地扩展到数以千计的节点中 。
3.高效性。Hadoop能够在节点之间动态地移动数据，并保证各个节点的动态平衡，因此处理速度非常快 。
4.高容错性。Hadoop能够自动保存数据的多个副本，并且能够自动将失败的任务重新分配 。
5.低成本。与一体机、商用数据仓库以及QlikView、Yonghong Z-Suite等数据集市相比，hadoop是开源的，项目的软件成本因此会大大降低。
应用场景
1.日志分析，将数据分片并行计算处理。
2.基于海量数据的在线应用。
3.推荐系统，精准营销。
4.搜索引擎。
名词解释
- Hive：利用Hive可以不需要编写复杂的Hadoop程序，只需要写一个SQL语句，Hive就会把SQL语句转换成Hadoop的任务去执行，降低使用Hadoop离线计算的门槛。
- HBase：海量数据存储的非关系型数据库，单个表中的数据能够容纳百亿行x百万列。
- ZooKeeper：监控Hadoop集群中每个节点的状态，管理整个集群的配置，维护节点间数据的一致性。
- Flume：海量日志采集系统。
Hadoop 部署模式有：本地模式、伪分布模式、完全分布式模式、HA完全分布式模式。
区分的依据是 NameNode、DataNode、ResourceManager、NodeManager等模块运行在几个JVM进程、几个机器。
模式名称 | 各个模块占用的JVM进程数 | 各个模块运行在几个机器数上 |
本地模式 | 1 | 1 |
伪分布式模式 | N | 1 |
完全分布式模式 | N | N |
HA完全分布式 | N | N |
HDFS
HDFS是分布式文件系统，存储海量的文件，其中HDFS中包含NameNode、DataNode、SecondaryNameNode组件等。
Block数据块
1.HDFS中基本的存储单元，1.X版本中每个Block默认是64M，2.X版本中每个Block默认是128M。
2.一个大文件会被拆分成多个Block进行存储，如果一个文件少于Block的大小，那么其实际占用的空间为文件自身大小。
3.每个Block都会在不同的DataNode节点中存在备份(默认备份数是3)
DataNode
1.保存具体的Blocks数据。
2.负责数据的读写操作和复制操作。
3.DataNode启动时会向NameNode汇报当前存储的数据块信息。
NameNode
1.存储文件的元信息和文件与Block、DataNode的关系，NameNode运行时所有数据都保存在内存中，因此整个HDFS可存储的文件数受限于NameNode的内存大小。
2.每个Block在NameNode中都对应一条记录，如果是大量的小文件将会消耗大量内存，因此HDFS适合存储大文件。
3.NameNode中的数据会定时保存到本地磁盘中(只有元数据)，但不保存文件与Block、DataNode的位置信息，这部分数据由DataNode启动时上报和运行时维护。
Secondary NameNode
它的职责是合并NameNode的edit logs到fsimage文件中。
上面的图片展示了Secondary NameNode是怎么工作的。
首先，它定时到NameNode去获取edit logs，并更新到fsimage上。[笔者注：Secondary NameNode自己的fsimage]
一旦它有了新的fsimage文件，它将其拷贝回NameNode中。
NameNode在下次重启时会使用这个新的fsimage文件，从而减少重启的时间。Secondary NameNode的整个目的是在HDFS中提供一个检查点。它只是NameNode的一个助手节点。这也是它在社区内被认为是检查点节点的原因。
现在，我们明白了Secondary NameNode所做的不过是在文件系统中设置一个检查点来帮助NameNode更好的工作。它不是要取代掉NameNode也不是NameNode的备份。所以从现在起，让我们养成一个习惯，称呼它为检查点节点吧。
HDFS HA(High Availability高可用性)
在HDFS集群中，NameNode依然是单点故障（SPOF: Single Point Of Failure）。元数据同时写到多个文件系统以及Second NameNode定期checkpoint有利于保护数据丢失，但是并不能提高可用性。
这是因为NameNode是唯一一个对文件元数据和file-block映射负责的地方， 当它挂了之后，包括MapReduce在内的作业都无法进行读写。当NameNode故障时，常规的做法是使用元数据备份重新启动一个NameNode。元数据备份可能来源于：
多文件系统写入中的备份
Second NameNode的检查点文件启动新的Namenode之后，需要重新配置客户端和DataNode的NameNode信息。另外重启耗时一般比较久，稍具规模的集群重启经常需要几十分钟甚至数小时，造成重启耗时的原因大致有：
1） 元数据镜像文件载入到内存耗时较长。
2） 需要重放edit log
3） 需要收到来自DataNode的状态报告并且满足条件后才能离开安全模式提供写服务。
Hadoop的HA方案
采用HA的HDFS集群配置两个NameNode，分别处于Active和Standby状态。当Active NameNode故障之后，Standby接过责任继续提供服务，用户没有明显的中断感觉。一般耗时在几十秒到数分钟。
HA涉及到的主要实现逻辑有
1） 主备需共享edit log存储。
主NameNode和待命的NameNode共享一份edit log，当主备切换时，Standby通过回放edit log同步数据。
共享存储通常有2种选择
NFS：传统的网络文件系统
QJM：quorum journal managerQJM是专门为HDFS的HA实现而设计的，用来提供高可用的edit log。QJM运行一组journal node，edit log必须写到大部分的journal nodes。通常使用3个节点，因此允许一个节点失败，类似ZooKeeper。注意QJM没有使用ZK，虽然HDFS HA的确使用了ZK来选举主Namenode。一般推荐使用QJM。
2）DataNode需要同时往主备发送Block Report
因为Block映射数据存储在内存中（不是在磁盘上），为了在Active NameNode挂掉之后，新的NameNode能够快速启动，不需要等待来自Datanode的Block Report，DataNode需要同时向主备两个NameNode发送Block Report。3）客户端需要配置failover模式（失效备援模式，对用户透明）
Namenode的切换对客户端来说是无感知的，通过客户端库来实现。客户端在配置文件中使用的HDFS URI是逻辑路径，映射到一对Namenode地址。客户端会不断尝试每一个Namenode地址直到成功。4）Standby替代Secondary NameNode
如果没有启用HA，HDFS独立运行一个守护进程作为Secondary Namenode。定期checkpoint，合并镜像文件和edit日志。如果当主Namenode失败时，备份Namenode正在关机（停止 Standby），运维人员依然可以从头启动备份Namenode，这样比没有HA的时候更省事，算是一种改进，因为重启整个过程已经标准化到Hadoop内部，无需运维进行复杂的切换操作。
NameNode的切换通过代failover controller来实现。failover controller有多种实现，默认实现使用ZooKeeper来保证只有一个Namenode处于active状态。
每个Namenode运行一个轻量级的failover controller进程，该进程使用简单的心跳机制来监控Namenode的存活状态并在Namenode失败时触发failover。Failover可以由运维手动触发，例如在日常维护中需要切换主Namenode，这种情况graceful(优雅的) failover，非手动触发的failover称为ungraceful failover。在ungraceful failover的情况下，没有办法确定失败（被判定为失败）的节点是否停止运行，也就是说触发failover后，之前的主Namenode可能还在运行。QJM一次只允许一个Namenode写edit log，但是之前的主Namenode仍然可以接受读请求。Hadoop使用fencing来杀掉之前的Namenode。Fencing通过收回之前Namenode对共享的edit log的访问权限、关闭其网络端口使得原有的Namenode不能再继续接受服务请求。使用STONITH技术也可以将之前的主Namenode关机。
YARN
在古老的 Hadoop1.0 中，MapReduce 的 JobTracker 负责了太多的工作，包括资源调度，管理众多的 TaskTracker 等工作。这自然是不合理的，于是 Hadoop 在 1.0 到 2.0 的升级过程中，便将 JobTracker 的资源调度工作独立了出来，而这一改动，直接让 Hadoop 成为大数据中最稳固的那一块基石。，而这个独立出来的资源管理框架，就是 Yarn 。
在详细介绍 Yarn 之前，我们先简单聊聊 Yarn ，Yarn 的全称是 ** Yet Another Resource Negotiator**，意思是“另一种资源调度器”，这种命名和“有间客栈”这种可谓是异曲同工之妙。这里多说一句，以前 Java 有一个项目编译工具，叫做 Ant，他的命名也是类似的，叫做 “Another Neat Tool”的缩写，翻译过来是”另一种整理工具“。
Yarn是Hadoop集群的资源管理系统。Hadoop2.0对MapReduce框架做了彻底的设计重构，我们称Hadoop2.0中的MapReduce为MRv2或者Yarn
Hadoop1.x对MapReduce job的调度管理方式，它主要包括两部分功能：
1.ResourceManagement 资源管理
2. JobScheduling/JobMonitoring 任务调度监控
到了Hadoop2.x也就是Yarn，它的目标是将这两部分功能分开，也就是分别用两个进程来管理这两个任务：
1. ResourceManger
2. ApplicationMaster(job)
Yarn主要由以下几个组件组成：
1. ResourceManager：Global（全局）的进程
2. NodeManager：运行在每个节点上的进程
3. ApplicationMaster：Application-specific（应用级别）的进程
- *Scheduler：是ResourceManager的一个组件*
- *Container：节点上一组CPU和内存资源*Container是Yarn框架的计算单元，是具体执行应用task（如map task、reduce task）的基本单位。Container和集群节点的关系是：一个节点会运行多个Container，但一个Container不会跨节点。
一个Container就是一组分配的系统资源，现阶段只包含两种系统资源（之后可能会增加磁盘、网络等资源）：
1. CPU core
2. Memory in MB任何一个job或application必须运行在一个或多个Container中，在Yarn框架中，ResourceManager只负责告诉ApplicationMaster哪些Containers可以用，ApplicationMaster还需要去找NodeManager请求分配具体的Container。
NodeManager进程运行在集群中的节点上，每个节点都会有自己的NodeManager。NodeManager是一个slave服务：它负责接收ResourceManager的资源分配请求，分配具体的Container给应用。同时，它还负责监控并报告Container使用信息给ResourceManager。通过和ResourceManager配合，NodeManager负责整个Hadoop集群中的资源分配工作。ResourceManager是一个全局的进程，而NodeManager只是每个节点上的进程，管理这个节点上的资源分配和监控运行节点的健康状态。下面是NodeManager的具体任务列表：
- 接收ResourceManager的请求，分配Container给应用的某个任务
- 和ResourceManager交换信息以确保整个集群平稳运行。ResourceManager就是通过收集每个NodeManager的报告信息来追踪整个集群健康状态的，而NodeManager负责监控自身的健康状态。
- 管理每个Container的生命周期
- 管理每个节点上的日志
- 执行Yarn上面应用的一些额外的服务，比如MapReduce的shuffle过程ResourceManager主要有两个组件：Scheduler和ApplicationManager。
Scheduler是一个资源调度器，它主要负责协调集群中各个应用的资源分配，保障整个集群的运行效率。Scheduler的角色是一个纯调度器，它只负责调度Containers，不会关心应用程序监控及其运行状态等信息。同样，它也不能重启因应用失败或者硬件错误而运行失败的任务
Scheduler是一个可插拔的插件，它可以调度集群中的各种队列、应用等。在Hadoop的MapReduce框架中主要有两种Scheduler：Capacity Scheduler和Fair Scheduler，关于这两个调度器后面会详细介绍。
另一个组件ApplicationManager主要负责接收job的提交请求，为应用分配第一个Container来运行ApplicationMaster，还有就是负责监控ApplicationMaster，在遇到失败时重启ApplicationMaster运行的Container。
ApplicationMaster的主要作用是向ResourceManager申请资源并和NodeManager协同工作来运行应用的各个任务然后跟踪它们状态及监控各个任务的执行，遇到失败的任务还负责重启它。
在MR1中，JobTracker即负责job的监控，又负责系统资源的分配。而在MR2中，资源的调度分配由ResourceManager专门进行管理，而每个job或应用的管理、监控交由相应的分布在集群中的ApplicationMaster，如果某个ApplicationMaster失败，ResourceManager还可以重启它，这大大提高了集群的拓展性。
在MR1中，Hadoop架构只支持MapReduce类型的job，所以它不是一个通用的框架，因为Hadoop的JobTracker和TaskTracker组件都是专门针对MapReduce开发的，它们之间是深度耦合的。Yarn的出现解决了这个问题，关于Job或应用的管理都是由ApplicationMaster进程负责的，Yarn允许我们自己开发ApplicationMaster，我们可以为自己的应用开发自己的ApplicationMaster。这样每一个类型的应用都会对应一个ApplicationMaster，一个ApplicationMaster其实就是一个类库。这里要区分ApplicationMaster类库和ApplicationMaster实例，一个ApplicationMaster类库何以对应多个实例，就行java语言中的类和类的实例关系一样。总结来说就是，每种类型的应用都会对应着一个ApplicationMaster，每个类型的应用都可以启动多个ApplicationMaster实例。所以，在yarn中，是每个job都会对应一个ApplicationMaster而不是每类。
注意
- NameNode不允许DataNode具有同一个Block的多个副本，所以创建的最大副本数量是当时DataNode的总数。
- DataNode会定期向NameNode发送心跳信息，一旦在一定时间内NameNode没有接收到DataNode发送的心跳则认为其已经宕机，因此不会再给它任何IO请求。
- 如果DataNode失效造成副本数量下降并且低于预先设置的阈值或者动态增加副本数量，则NameNode会在合适的时机重新调度DataNode进行复制。
MapReduce文件系统
MapReduce是一种编程模型，用于大规模数据集（大于1TB）的并行运算。MapReduce将分成两个部分"Map（映射）“和"Reduce（归约）”。
当你向MapReduce框架提交一个计算作业时，它会首先把计算作业拆分成若干个Map任务，然后分配到不同的节点上去执行，每一个Map任务处理输入数据中的一部分，当Map任务完成后，它会生成一些中间文件，这些中间文件将会作为Reduce任务的输入数据。Reduce任务的主要目标就是把前面若干个Map的输出汇总到一起并输出。
