[大数据]Hadoop核心组件及组件介绍

一、核心组件

1、Hadoop通用组件 -? Hadoop Common

包含了其他hadoop模块要用到的库文件和工具

2、分布式文件系统 - Hadoop Distributed File System （HDFS）

运行于通用硬件上的分布式文件系统，高吞吐，高可靠

3、资源管理组件 - Hadoop YARN

于2012年引入的组件，用于管理集群中的计算资源并在这些资源上调度用户应用

4、分布式计算框架 - Hadoop MapReduce

用于处理超大数据集计算的MapReduce编程模型的实现

二、Hadoop关联项目

1、Apache Ambari 是一种基于Web的工具，支持Apache Hadoop集群的供应、管理和监控。Apache Ambari 支持HDFS、MapReduce、Hive、Pig、Hbase、Zookeepr、Sqoop和Hcatalog等的集中管理。也是5个顶级hadoop管理工具之一。

2、Avro：数据序列化系统

3、Cassandra是一套开源分布式NoSQL数据库系统。他最初由Facebook开发，用于储存收件箱等简单格式数据，集GoogleBigTable的数据模型与Amazon Dynamo的完全分布式的架构于一身，Facebook于2008将Caddandra开源。

4、chukwa是一个开源的用于监控大型分布式系统的数据收集系统。这是构建在hadoop的HDFS和MapReduce框架之上的，继承了hadoop的可伸缩性和健壮性。Chukwa还包含了一个强大的灵活的工具集，可用于展示、监控和分析已收集的数据。

5、hive 是基于Hadoop的一个数据仓库工具，可以将结构化的数据文件映射为一张数据库表，并提供简单的sql查询功能，可以将sql语句转换为MapReduce任务进行运行。

6、Mahout提供一些可扩展的机器学习领域经典算法的实现，旨在帮助开发人员更加方便快捷的创建智能应用程序。Mahout包含许多实现，包括聚类、分类、推荐过滤、频繁子项挖掘。此外，通过使用Apache Hadoop库，Mahout可以有效的扩展到云中。

7、Apache Pig 是一个高级过程语言，适合于使用Hadoop 和 MapReduce 平台来查询大型半结构化数据集。通过允许对分布式数据集进行类似SQL的查询，Pig可以简化Hadoop的使用。

8、Apache Spark是专为大规模数据处理而设计的快速通用的计算引擎。Spark是UCBerkeley AMP lab开源的类Hadoop MapReduce的通用并行框架，拥有MapReduce具有的优点。

9、Tez 是 Apache 最新的支持 DAG 作业的开源计算框架。它允许开发者为最终用户构建性能更快、扩展性更好的应用程序。Hadoop传统上是一个大量数据批处理平台。但是，有很多用例需要近乎实时的查询处理性能。还有一些工作则不太适合MapReduce，例如机器学习。Tez的目的就是帮助Hadoop处理这些用例场景。

10、ZooKeeper是一个分布式的，开放源码的分布式应用程序协调服务，是Google的Chubby一个开源的实现，是Hadoop和Hbase的重要组件。它是一个为分布式应用提供一致性服务的软件，提供的功能包括：配置维护、域名服务、分布式同步、组服务等。

11、HBase是一个分布式的、高可靠性、高性能、面向列、可伸缩的分布式存储系统，该技术来源于Fay Chang所撰写的Google论文“Bigtable：一个结构化数据的分布式存储系统”。就像Bigtable利用了Google文件系统（File System）所提供的分布式数据存储一样，HBase在Hadoop之上提供了类似于Bigtable的能力。

三、HDFS架构

1. 硬件错误
   1. 硬件错误是常态而不是异常。
   2. HDFS可能由成百上千的服务器所构成，单机故障概率的存在意味着总有一部分服务器不工作的。
   3. 错误检测和快速自动恢复是HDFS最核心架构目标。
2. 流式数据访问
   1. 运行在HDFS上的应用需要流式访问它们的数据集。
   2. HDFS的设计重点是批处理，而不是交互处理。是高吞吐量而不是低延迟。
   3. 为了提高数据的吞吐量，在关键方面修改POSIX的语义。
3. 大规模数据集
   1. HDFS上的一个典型文件大小一般都在G字节至T字节。
   2. HDFS支持大文件存储。
   3. 单一HDFS实例能支撑数以千万计的文件。
4. 简单的一致性模型
   1. HDFS应用遵循“一次写入多次读取”的文件访问模型。
   2. 简化了数据一致性问题，并且使高吞吐量的数据访问成为可能。
   3. Map/Reduce应用或者网络爬虫应用都非常适合这个模型。
5. 移动计算比移动数据更划算
   1. 降低网络阻塞的影响，提高系统数据的吞吐量。
   2. 将计算程序发送到数据所在的主机，比GB级别TB级别的数据移动更便捷。
6. 异构软硬件平台间的可移植性
   1. HDFS在设计的时候就考虑到平台的可移植性。
   2. 这种特性方便了HDFS作为大规模数据应用平台的推广。

四、NameNode

NameNode管理文件系统的命名空间

1. 文件和目录的元数据：(运行时，元数据放内存)

??? 文件的block副本个数

??? 修改和访问的时间

??? 访问权限

??? block大小以及组成文件的block列表信息

1. 以两种方式在NameNode本地进行持久化：

??? 命名空间镜像文件（fsimage）和编辑日志（edits log）。

1. fsimage文件不记录每个block所在的DataNode信息，这些信息在每次系统启动的时候从DataNode重建。之后DataNode会周期性地通过心跳包向NameNode报告block信息。DataNode向NameNode注册的时候NameNode请求DataNode发送block列表信息。

存储结构

一个运行的NameNode如下的目录结构，该目录结构在第一次格式化的时候创建

?

如果属性dfs.namenode.name.dir指定了多个路径，则每个路径中的内容是一样的，尤其是当其中一个是挂载的NFS的时候，这种机制为管理提供了一些弹性。备份数据

in_use.lock文件用于NameNode锁定存储目录。这样就防止其他同时运行的NameNode实例使用相同的存储目录。

edits表示edits log日志文件

fsimage表示文件系统元数据镜像文件

NameNode在checkpoint之前首先要切换新的edits log文件，在切换时更新seen_txid的值。上次合并fsimage和editslog之后的第一个操作编号

VERSION文件是一个Java的属性文件

?

layoutVersion是一个负数，定义了HDFS持久化数据结构的版本。这个版本数字跟hadoop发行的版本无关。当layout改变的时候，该数字减1（比如从-57到-58）。当对HDFDS进行了升级，就会发生layoutVersion的改变。

namespaceID是该文件系统的唯一标志符，当NameNode第一次格式化的时候生成。

clusterID是HDFS集群使用的一个唯一标志符，在HDFS联邦的情况下，就看出它的作用了，因为联邦情况下，集群有多个命名空间，不同的命名空间由不同的NameNode管理。

blockpoolID是block池的唯一标志符，一个NameNode管理一个命名空间，该命名空间中的所有文件存储的block都在block池中。

cTime标记着当前NameNode创建的时间。对于刚格式化的存储，该值永远是0，但是当文件系统更新的时候，这个值就会更新为一个时间戳。

storageType表示当前目录存储NameNode内容的数据结构。

?

当文件系统客户端进行了写操作（例如创建或移动了文件），这个事务首先在edits log中记录下来。NameNode在内存中有文件系统的元数据，当edits log记录结束后，就更新内存中的元数据。内存中的元数据用于响应客户端的读请求。

edits log在磁盘上表现为一定数量的文件。每个文件称为片段（Segment），前缀“edits”，后缀是其中包含的事务ID（transaction IDs）。每个写操作事务都仅仅打开一个文件（比如：edits_inprogress_00000000000010），写完后冲刷缓冲区并同步到磁盘，然后返回客户端success状态码。如果NameNode的元数据需要写到多个目录中，则对于每个写事务需要所有的写操作都完成，并冲刷缓冲区同步到磁盘才返回success状态码。这样就可以保证在发生宕机的时候没有事务数据丢失。

用户的操作是一个事务，每个操作NN都要先将操作记录到edits log中，如果给NN指定了多个目录，则在多个目录中都存在edits log文件，用户的操作要在多个目录中都写完成，才让NN同步数据到内存中。当NN在内存中也同步了数据，就返回客户端success。

每个fsimage文件都是系统元数据的一个完整的持久化检查点（checkpoint）（后缀表示镜像中的最后一个事务）。写操作不更新这个数据，因为镜像文件通常为GB数量级，写到磁盘很慢。如果NameNode宕机，可以将最新fsimage加载到内存，同时执行edits log对应于该faimage之后的操作，就可以重建元数据的状态。而这正是每次启动NameNode的时候NameNode要做的工作。

tb_user

update tb_user set username='张三' where id=7000;

my.log : update tb_user set username='张三' where id=7000;

SecondaryNameNode

存在的意义

edits log会随着对文件系统的操作而无限制地增长，这对正在运行的NameNode而言没有任何影响，如果NameNode重启，则需要很长的时间执行edits log的记录以更新fsimage（元数据镜像文件）。在此期间，整个系统不可用。

在系统启动期间，NameNode合并fsimage+edits log

fsimage=0

edist log=很大

内存

fsimage=GB

edits log=很大 TB

内存->执行edits log条目

解决方案就是运行SecondaryNameNode，它的作用就是为NameNode内存中的文件系统元数据生成检查点（checkpoint）。fsimage

工作流程

edits_inprogress_00000000018_0000000028? seen_txid=29

1、secondarynamenode请求namenode生成新的edits log文件并向其中写日志。NameNode会在所有的存储目录中更新seen_txid文件

2、SecondaryNameNode通过HTTP GET的方式从NameNode下载fsimage和edits文件到本地。

3、SecondaryNameNode将fsimage加载到自己的内存，并根据edits log更新内存中的fsimage信息，然后将更新完毕之后的fsimage写到磁盘上。

4、SecondaryNameNode通过HTTP PUT将新的fsimage文件发送到NameNode，NameNode将该文件保存为.ckpt的临时文件备用。

5、NameNode重命名该临时文件并准备使用。此时NameNode拥有一个新的fsimage文件和一个新的很小的edits log文件（可能不是空的，因为在SecondaryNameNode合并期间可能对元数据进行了读写操作）。管理员也可以将NameNode置于safemode，通过hdfs dfsadmin -saveNamespace命令来进行edits log和fsimage的合并。

SecondaryNameNode要和NameNode拥有相同的内存。对大的集群，SecondaryNameNode运行于一台专用的物理主机。

?

检查点创建时机

对于创建检查点（checkpoint）的过程，有三个参数进行配置：

1、默认情况下，SecondaryNameNode每个小时进行一次checkpoint合并

??? 由dfs.namenode.checkpoint.period设置，单位秒

2、在不足一小时的情况下，如果edits log存储的事务达到了1000000个也进行一次checkpoint合并

??? 由dfs.namenode.checkpoint.txns设置事务数量

3、事务数量检查默认每分钟进行一次

??? 由dfs.namenode.checkpoint.check.period设置，单位秒。

总结：

存储结构

?

1、SecondaryNameNode中checkpoint目录布局（dfs.namenode.checkpoint.dir）和NameNode中的一样。

2、如果NameNode完全坏掉（没有备用机，也没有NFS），可以快速地从SecondaryNameNode恢复。有可能丢数据

3、如果SecondaryNameNode直接接手NameNode的工作，需要在启动NameNode进程的时候添加-importCheckpoint选项。该选项会让NameNode从由dfs.namenode.checkpoint.dir属性定义的路径中加载最新的checkpoint数据，但是为了防止元数据的覆盖，要求dfs.namenode.name.dir定义的目录中没有内容。

DataNode

存储结构

DataNode不需要显式地格式化;关键文件和目录结构如下：

?

1、HDFS块数据存储于blk_前缀的文件中，包含了被存储文件原始字节数据的一部分。

2、每个block文件都有一个.meta后缀的元数据文件关联。该文件包含了一个版本和类型信息的头部，后接该block中每个部分的校验和。

3、每个block属于一个block池，每个block池有自己的存储目录，该目录名称就是该池子的ID（跟NameNode的VERSION文件中记录的block池ID一样）。

当一个目录中的block达到64个（通过dfs.datanode.numblocks配置）的时候，DataNode会创建一个新的子目录来存放新的block和它们的元数据。这样即使当系统中有大量的block的时候，目录树也不会太深。同时也保证了在每个目录中文件的数量是可管理的，避免了多数操作系统都会碰到的单个目录中的文件个数限制（几十几百上千个）。

如果dfs.datanode.data.dir指定了位于在不同的硬盘驱动器上的多个不同的目录，则会通过轮询的方式向目录中写block数据。需要注意的是block的副本不会在同一个DataNode上复制，而是在不同的DataNode节点之间复制。

存储数据模型(重点)

1、文件线性切割成块（Block）（按字节切割）

2、Block分散存储在集群节点中

3、单一文件Block大小一致，文件与文件可以不一致

??? hdfs? dfs? -D? dfs.blocksize=1048576? -D dfs.replication=3? -put hello.txt? /

4、Block可以设置副本数，副本分散在不同节点中

??? a) 副本数不要超过节点数量

??? b) 承担计算

??? c) 容错

5、文件上传可以设置Block大小和副本数

6、已上传的文件Block副本数可以调整，大小不变

7、只支持一次写入多次读取，同一时刻只有一个写入者

??? 对同一个文件，一个时刻只有一个写入者

8、可以append追加数据

优势（了解）

1. 一个文件的大小可以大于网络中任意一个磁盘的容量
2. 使用抽象块而非整个文件作为存储单元，大大简化存储子系统的设计
3. 块非常适合用于数据备份进而提供数据容错能力和提高可用性

?

?

数据块副本放置策略

Block的副本放置策略

第一个副本：放置在上传文件的DN；如果是集群外提交，则随机挑选一台磁盘不太满，CPU不太忙的节点。

第二个副本：放置在于第一个副本不同的 机架的节点上。

第三个副本：与第二个副本相同机架的节点。

更多副本：随机节点

源代码：

?

HDFS的权限（了解）

1、每个文件和目录都和一个拥有者和组相关联。

2、文件或者目录对与拥有者、同组用户和其他用户拥有独立的权限。

3、对于一个文件，r表示读取的权限，w表示写或者追加的权限。对于目录而言，r表示列出目录内容的权限，w表示创建或者删除文件和目录的权限，x表示访问该目录子项目的权限。

4、默认情况下hadoop运行时安全措施处于停用模式。一个客户端可以在远程系统上通过创建和任意一个合法用户同名的账号来进行访问。 hadoop? root

5、安全措施可以防止用户或自动工具及程序意外修改或删除文件系统的重要部分。（dfs.permissions.enabled属性）。防止好人做错事。

6、超级用户是namenode进程的标识。对于超级用户，系统不会执行任何权限检查。