Hadoop核心组件
1.Hadoop通用组件 — Hadoop Common
包含了其他hadoop模块要用到的库文件和工具
2.分布式文件系统 — Hadoop Distributed File System(HDFS)
运行于通用硬件上的分布式文件系统，高吞吐，高可靠
3.资源管理组件 — Hadoop YARN
于2012年引入的组件，用于管理集群中的计算资源并在这些资源上调度用户应用
4.分布式计算框架 — Hadoop MapReduce
用于处理超大数据集计算的MapReduce编程模型的实现
5.Hadoop Ozone: An object store for Hadoop.
6.Hadoop Submarine: A machine learning engine for Hadoop
HDFS架构
NameNode 管理文件系统的命名空间
1. 文件和目录的元数据：(运行时，元数据放内存)
文件的block副本个数
修改和访问的时间
访问权限
block大小以及组成文件的block列表信息
2. 以两种方式在NameNode本地进行持久化
命名空间镜像文件(fsimage)和编辑日志(edits log)。
3. fsimage不记录每个block文件所在的DataNode信息，这些信息在每次重启系统的时候从DataNode重建。
之后DataNode会周期性的通过心跳包想NameNode报告block块信息。
DataNode向NameNode注册的时候NameNode请求DataNode发送block列表信息。
SecondaryNameNode
存在的意义：
edits log会随着对文件系统的操作而无限制的增长，这对正在运行的NameNode而言没有任何影响，
如果重启NameNode，则需要很长的时间执行 edits log 的记录以更新 fsimage(元数据镜像文件)。
在此期间，整个系统不可用。在系统启动期间，NameNode合并 fsimage + edits log
fsimage =0
edits log = 很大
内存
fsimage =GB
edits log
内存->执行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设置，单位秒。
总结
namenode
管理文件元数据
文件名称、大小、所属关系、权限、副本大小、副本个数
文件块的列表信息：(块的ID，偏移量，块的大小，块所在的主机名称列表)
持久化文件
fsimage(内存快照)，edits log
fsimage很大，GB级别；edits log只追加的文件
用户操作首先记录到edits log中，然后更新内存
fsimage不保存数据块位置信息
在系统启动的时候，datanode向namenode发送文件块列表信息（bid）
datanode通过心跳向namenode汇报列表信息。
namenode元数据正常工作时，元数据放内存，高并发。
secondarynamenode
在系统启动的时候，namenode首先加载fsimage，然后逐条执行edits log中的日志操作，如果edits log很大，
则需要很长时间才能加载完毕，向磁盘写新的fsimage，之后才可以对外提供服务。
周期性地从namenode拷贝fsimage+edits log，在SNN中合并为新的fsimage，推送给namenode。
条件：1、每小时一次，2、不足一小时，则只要edits log中记录的事务数达到了1000000，则合并。
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）（按字节切割）
.....
Hello world
2、Block分散存储在集群节点中
3、单一文件Block大小一致，文件与文件可以不一致
hdfs dfs -D dfs.blocksize=1048576 -D dfs.replication=2 -put hello.txt /
4、Block可以设置副本数，副本分散在不同节点中
a) 副本数不要超过节点数量
b) 承担计算
c) 容错
5、文件上传可以设置Block大小和副本数
6、已上传的文件Block副本数可以调整，大小不变
7、只支持一次写入多次读取，同一时刻只有一个写入者
对同一个文件，一个时刻只有一个写入者
8、可以append追加数据
优势：
1.一个文件的大小可以大于网络中任意一个磁盘的容量
2.使用抽象块而非整个文件作为存储单元，大大简化存储子系统的设计
3.块非常适合用于数据备份进而提供数据容错能力和提高可用性
HDFS的权限
1、每个文件和目录都和一个拥有者和组相关联。
2、文件或者目录对与拥有者、同组用户和其他用户拥有独立的权限。
3、对于一个文件，r表示读取的权限，w表示写或者追加的权限。
对于目录而言，r表示列出目录内容的权限，w表示创建或者删除文件和目录的权限，x表示访问该目录子项目的权限。
4、默认情况下hadoop运行时安全措施处于停用模式。一个客户端可以在远程系统上通过创建和任意一个合法用户同名的账号来进行访问。
hadoop root
5、安全措施可以防止用户或自动工具及程序意外修改或删除文件系统的重要部分。
（dfs.permissions.enabled属性）。防止好人做错事。
6、超级用户是namenode进程的标识。对于超级用户，系统不会执行任何权限检查。
108
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
