2021-01-29 大数据课程笔记 day9

@R星校长

hadoop 第一天

Hadoop一共六天课程：

分布式存储两天
MapReduce计算两天
案例两天

第一天内容安排

1T文件操作（训练）
hadoop起源（了解）
HDFS架构（重点）
数据块副本放置策略（重点）
HDFS的权限（了解）
hadoop的安全模式（理解）
HDFS写文件流程（重点）
HDFS读文件流程（重点）
伪分布式搭建（熟练）

热身1T文件操作的思考：

分治思想
单机处理大数据的问题
集群分布式处理大数据的辩证

分治思想引入案例

十万个元素（数字或单词）需要存储，如何存储？
如果想查找某一个元素，最简单的遍历方式的复杂度是多少？
如果我们期望复杂度是O(4)呢？

• 分而治之的思想非常重要，常见于以下技术：

     1.  Redis集群2.   Hadoop3.    Hbase4. ElasticSearch

单机处理大数据的问题

需求：
有一个非常大的文本文件，里面有非常多的行，只有两行内容一样，它们出现在未知的位置，需要查找到它们。硬件：单台机器，而且可用的内存很少，也就 500MB。
• 假如 IO 速度是 500MB/S
• 1T 文件读取一遍需要约 30 分钟
• 循环遍历需要 N 次 IO 时间
• 分治思想可以使时间降为 2 次 IO

• 思考：
• 如何让时间变为分钟、秒级别
• 假如 IO 速度是 500MB/S
• 1T 文件读取一遍需要约 30 分钟
• 如何对 1TB 文件进行排序

方式 1：外部有序，内部无序。
逐一读入内存排序
方式 2：逐一读取 500M 排序，内部有序，外部无序，然后进行归并排序

需求：
• 有一个非常大的文本文件，里面有几百亿行，只有两行内容一样，它们出现在未知的位置，需要查找到它们。
• 分钟、秒级别完成
• 硬件：*台机器，而且可用的内存 500MB。

由于涉及到计算机之间文件传输，千兆带宽，100MB/s
拉取网卡 100MB/S

之前忽略了上传时间：1TB/100MB = 10000S /3600S = 3H

集群分布式处理大数据的辩证

•    2000 台真的比一台快吗？
•   如果考虑分发上传文件的时间呢？
•   如果考虑每天都有 1TB 数据的产生呢？
•   如果增量了一年，最后一天计算数据呢？
•   1天  2*30=1H               3H1M2S
•   2天    2H                   3H1M4S
•   3天    3H                   3H1M6S
•   4天    4H                   3H1M8S

hadoop起源

发展历史

2002年10月，Doug Cutting 和 Mike Cafarella 创建了开源网页爬虫项目 Nutch。
2003年10月，Google 发表 Google File System 论文。
2004年7月，Doug Cutting 和 Mike Cafarella 在 Nutch 中实现了类似 GFS 的功能，即后来 HDFS 的前身。
2004年10月，Google 发表了 MapReduce 论文。
2005年2月，Mike Cafarella 在 Nutch 中实现了 MapReduce 的最初版本。
2005年12月，开源搜索项目 Nutch 移植到新框架，使用 MapReduce 和 NDFS 在 20 个节点稳定运行。
2006年1月，Doug Cutting 加入雅虎，Yahoo! 提供一个专门的团队和资源将 Hadoop 发展成一个可在网络上运行的系统。
2006年2月，Apache Hadoop 项目正式启动以支持 MapReduce 和 HDFS 的独立发展。
2006年3月，Yahoo! 建设了第一个 Hadoop 集群用于开发。
2006年4月，第一个 Apache Hadoop 发布。
2006年11月，Google 发表了 Bigtable 论文，激起了 Hbase 的创建。
2007年10月，第一个 Hadoop 用户组会议召开，社区贡献开始急剧上升。
2007年，百度开始使用 Hadoop 做离线处理。
2007年，中国移动开始在“大云”研究中使用 Hadoop 技术。
2008年，淘宝开始投入研究基于 Hadoop 的系统——云梯，并将其用于处理电子商务相关数据。
2008年1月，Hadoop 成为 Apache 顶级项目。
2008年2月，Yahoo! 运行了世界上最大的 Hadoop 应用，宣布其搜索引擎产品部署在一个拥有 1 万个内核的 Hadoop 集群上。
2008年4月，在 900 个节点上运行 1TB 排序测试集仅需 209 秒，成为世界最快。
2008年8月，第一个 Hadoop 商业化公司 Cloudera 成立。
2008年10月，研究集群每天装载 10TB 的数据。
2009 年3月，Cloudera 推出世界上首个 Hadoop 发行版—— CDH（Cloudera’s Distribution including Apache Hadoop）平台，完全由开放源码软件组成。
2009年6月，Cloudera 的工程师 Tom White 编写的《 Hadoop 权威指南》初版出版，后被誉为 Hadoop 圣经。
2009年7月，Hadoop Core 项目更名为 Hadoop Common ;
2009年7月，MapReduce 和 Hadoop Distributed File System (HDFS) 成为 Hadoop 项目的独立子项目。
2009年8月，Hadoop 创始人 Doug Cutting 加入 Cloudera 担任首席架构师。
2009年10月，首届 Hadoop World 大会在纽约召开。
2010年5月，IBM 提供了基于 Hadoop 的大数据分析软件 —— InfoSphere BigInsights，包括基础版和企业版。
2011年3月，Apache Hadoop 获得 Media Guardian Innovation Awards 媒体卫报创新奖
2012年3月，企业必须的重要功能 HDFS NameNode HA 被加入 Hadoop 主版本。
2012年8月，另外一个重要的企业适用功能 YARN 成为 Hadoop 子项目。
2014年2月，Spark 逐渐代替 MapReduce 成为 Hadoop 的缺省执行引擎，并成为 Apache 基金会顶级项目。
2017年12月，Release 3.0.0 generally available

核心组件

hadoop 通用组件 - Hadoop Common
包含了其他 hadoop 模块要用到的库文件和工具
分布式文件系统 - Hadoop Distributed File System (HDFS)
运行于通用硬件上的分布式文件系统，高吞吐，高可靠
资源管理组件 - Hadoop YARN
于 2012 年引入的组件，用于管理集群中的计算资源并在这些资源上调度用户应用。
分布式计算框架 - Hadoop MapReduce
用于处理超大数据集计算的 MapReduce 编程模型的实现。
Hadoop Ozone: An object store for Hadoop.
Hadoop Submarine: A machine learning engine for Hadoop

hadoop 关联项目

Apache Ambari 是一种基于 Web 的工具，支持 Apache Hadoop 集群的供应、管理和监控。 Apache Ambari 支持 HDFS、MapReduce、Hive、Pig、Hbase、Zookeepr、Sqoop 和 Hcatalog 等的集中管理。也是 5 个顶级 hadoop 管理工具之一。
Avro™: 数据序列化系统
Cassandra 是一套开源分布式 NoSQL 数据库系统。它最初由 Facebook 开发，用于储存收件箱等简单格式数据，集 GoogleBigTable 的数据模型与 Amazon Dynamo 的完全分布式的架构于一身， Facebook 于 2008 将 Cassandra 开源。
chukwa 是一个开源的用于监控大型分布式系统的数据收集系统。这是构建在 hadoop 的 HDFS 和 MapReduce 框架之上的，继承了 hadoop 的可伸缩性和健壮性。Chukwa 还包含了一个强大和灵活的工具集，可用于展示、监控和分析已收集的数据。
hive 是基于 Hadoop 的一个数据仓库工具，可以将结构化的数据文件映射为一张数据库表，并提供简单的 sql 查询功能，可以将 sql 语句转换为 MapReduce 任务进行运行。
Mahout 提供一些可扩展的机器学习领域经典算法的实现，旨在帮助开发人员更加方便快捷地创建智能应用程序。Mahout 包含许多实现，包括聚类、分类、推荐过滤、频繁子项挖掘。此外，通过使用 Apache Hadoop 库，Mahout 可以有效地扩展到云中。
Apache Pig 是一个高级过程语言，适合于使用 Hadoop 和 MapReduce 平台来查询大型半结构化数据集。通过允许对分布式数据集进行类似 SQL 的查询，Pig 可以简化 Hadoop 的使用。
Apache Spark 是专为大规模数据处理而设计的快速通用的计算引擎。Spark 是 UC Berkeley AMP lab 开源的类 Hadoop MapReduce 的通用并行框架，拥有 MapReduce 所具有的优点；但是 Job 中间输出结果可以保存在内存中，从而不再需要读写 HDFS ，因此 Spark 能更好地适用于数据挖掘与机器学习等需要迭代的 MapReduce 的算法。
Tez 是 Apache 最新的支持 DAG 作业的开源计算框架。它允许开发者为最终用户构建性能更快、扩展性更好的应用程序。Hadoop 传统上是一个大量数据批处理平台。但是，有很多用例需要近乎实时的查询处理性能。还有一些工作则不太适合 MapReduce ，例如机器学习。Tez 的目的就是帮助 Hadoop 处理这些用例场景。
ZooKeeper 是一个分布式的，开放源码的分布式应用程序协调服务，是 Google 的 Chubby 一个开源的实现，是 Hadoop 和 Hbase 的重要组件。它是一个为分布式应用提供一致性服务的软件，提供的功能包括：配置维护、域名服务、分布式同步、组服务等。
HBase 是一个分布式的、高可靠性、高性能、面向列、可伸缩的分布式存储系统，该技术来源于 Fay Chang 所撰写的 Google 论文 “ Bigtable：一个结构化数据的分布式存储系统”。就像 Bigtable 利用了 Google 文件系统（File System）所提供的分布式数据存储一样，HBase 在 Hadoop 之上提供了类似于 Bigtable 的能力。

HDFS架构

前提和设计目标

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

HDFS 架构

问题：100 台服务器，存储空间单个 100GB 10T5T 文件如何存储？
128MB一块      128MB*8=1GB    128*8*1024=1TB
5T数据分成的128MB的块数8192 *5。

清单：5TB文件分的块：元数据：文件名称：web.log大小：5TB创建时间：权限：文件所有者：文件所属的用户组：文件类型：文件块列表信息：0~128*1024*1024 -1：128MB：node1：path,node3:path,node8:path128*1024*1024~2*128*1024*1024 -1：128MB：node2：path,...2*128*1024*1024~3*128*1024*1024 -1：128MB：node3：path0~128*1024*1024 -1：128MB：node1：0~128*1024*1024 -1：128MB：node1：0~128*1024*1024 -1：128MB：node1：0~128*1024*1024 -1：128MB：node1：0~128*1024*1024 -1：128MB：node1：

NameNode

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

文件和目录的元数据：(运行时，元数据放内存)
文件的 block 副本个数
修改和访问的时间
访问权限
block 大小以及组成文件的 block 列表信息
以两种方式在 NameNode 本地进行持久化：
命名空间镜像文件（fsimage）和编辑日志（edits log）。
fsimage 文件不记录每个 block 所在的 DataNode 信息，这些信息在每次系统启动的时候从 DataNode 重建。之后 DataNode 会周期性地通过心跳包向 NameNode 报告 block 信息。DataNode 向 NameNode 注册的时候 NameNode 请求 DataNode 发送 block 列表信息。

1、文件名称和路径
2、文件的大小
3、文件的所属关系
4、文件的block块大小  128MB
5、文件的副本个数  3   MR  10个副本
6、文件的修改时间
7、文件的访问时间
8、文件的权限
9、文件的block列表blk1:0,134217728‬,node1,node13,node26：blockIDblk2:134217728,134217728‬,node7,node89,node1002blk2:134217728*2,134217728‬,node7,node89,node1002blk2:134217728*3,134217728‬,node7,node89,node1002blk2:134217728*4,134217728‬,node7,node89,node1002blk2:134217728*5,134217728‬,node7,node89,node1002blk2:134217728,134217728‬,node7,node89,node1002blk2:134217728,134217728‬,node7,node89,node1002...

存储结构
一个运行的 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对应于该fsimage之后的操作，就可以重建元数据的状态。而这正是每次启动NameNode的时候NameNode要做的工作。

SecondaryNameNode

存在的意义

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

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

fsimage=0
edist 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 logfsimage很大，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

存储结构

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）（按字节切割）
…
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 追加数据

优势（了解）

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

数据块副本放置策略

Block 的副本放置策略

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

源代码：

HDFS的权限（了解）

1、每个文件和目录都和一个拥有者和组相关联。
2、文件或者目录对与拥有者、同组用户和其他用户拥有独立的权限。
3、对于一个文件，r 表示读取的权限，w 表示写或者追加的权限。对于目录而言，r 表示列出目录内容的权限，w 表示创建或者删除文件和目录的权限，x 表示访问该目录子项目的权限。
4、默认情况下 hadoop 运行时安全措施处于停用模式。一个客户端可以在远程系统上通过创建和任意一个合法用户同名的账号来进行访问。 hadoop root
5、安全措施可以防止用户或自动工具及程序意外修改或删除文件系统的重要部分。（dfs.permissions.enabled 属性）。防止好人做错事。
6、超级用户是 namenode 进程的标识。对于超级用户，系统不会执行任何权限检查。

hadoop 的安全模式

工作流程(理解)

启动 NameNode ，NameNode 加载 fsimage 到内存，对内存数据执行 edits log 日志中的事务操作。
文件系统元数据内存镜像加载完毕，进行 fsimage 和 edits log 日志的合并，并创建新的 fsimage 文件和一个空的 edits log 日志文件。
NameNode 等待 DataNode 上传 block 列表信息，直到副本数满足最小副本条件。
当满足了最小副本条件，再过 30 秒，NameNode 就会退出安全模式。最小副本条件指整个文件系统中有 99.9% 的 block 达到了最小副本数（默认值是 1 ，可设置）

在 NameNode 安全模式（safemode）

对文件系统元数据进行只读操作
当文件的所有block信息具备的情况下，对文件进行只读操作
不允许进行文件修改（写，删除或重命名文件）

注意事项

NameNode 不会持久化 block 位置信息；DataNode 保有各自存储的 block 列表信息。正常操作时，NameNode 在内存中有一个 block 位置的映射信息。
NameNode 在安全模式，NameNode 需要给 DataNode 时间来上传 block 列表信息到 NameNode 。如果 NameNode 不等待 DataNode 上传这些信息的话，则会在 DataNode 之间进行 block 的复制，而这在大多数情况下都是非必须的（因为只需要等待 DataNode 上传就行了），还会造成资源浪费。
在安全模式 NameNode 不会要求 DataNode 复制或删除 block 。
新格式化的 HDFS 不进入安全模式，因为 DataNode 压根就没有 block 。

命令操作(了解)

通过命令查看 namenode 是否处于安全模式：

$ hdfs dfsadmin -safemode get
Safe mode is ON

HDFS 的前端 webUI 页面也可以查看 NameNode 是否处于安全模式。
有时候我们希望等待安全模式退出，之后进行文件的读写操作，尤其是在脚本中，此时：

$ hdfs dfsadmin -safemode wait
# your read or write command goes here

管理员有权在任何时间让 namenode 进入或退出安全模式。进入安全模式：

$ hdfs dfsadmin -safemode enter
Safe mode is ON

这样做可以让 namenode 一直处于安全模式，也可以设置 dfs.namenode.safemode.threshold-pct 为1做到这一点。
离开安全模式：

$ hdfs dfsadmin -safemode leave
Safe mode is OFF

HDFS 写文件流程（重点）

流程

调用客户端的对象 DistributedFileSystem 的 create 方法；
DistributedFileSystem 会发起对 namenode 的一个 RPC 连接，请求创建一个文件，不包含关于 block 块的请求。namenode 会执行各种各样的检查，确保要创建的文件不存在，并且客户端有创建文件的权限。如果检查通过，namenode 会创建一个文件（在 edits 中，同时更新内存状态），否则创建失败，客户端抛异常 IOException 。
DistributedFileSystem 返回一个 FSDataOutputStream 对象给客户端用于写数据。FSDataOutputStream 封装了一个 DFSOutputStream 对象负责客户端跟 datanode 以及 namenode 的通信。
FSDataOutputStream 对象将数据切分为小的数据包（64kb ，core-default.xml：file.client-write-packet-size 默认值 65536），并写入到一个内部队列（“ 数据队列 ”）。DataStreamer 会读取其中内容，并请求 namenode 返回一个 datanode 列表来存储当前 block 副本。列表中的 datanode 会形成管线，DataStreamer 将数据包发送给管线中的第一个 datanode ，第一个 datanode 将接收到的数据发送给第二个 datanode ，第二个发送给第三个。。。
DFSOoutputStream 维护着一个数据包的队列，这的数据包是需要写入到 datanode 中的，该队列称为确认队列。当一个数据包在管线中所有 datanode 中写入完成，就从 ack 队列中移除该数据包。如果在数据写入期间 datanode 发生故障，则执行以下操作
a) 关闭管线，把确认队列中的所有包都添加回数据队列的最前端，以保证故障节点下游的 datanode 不会漏掉任何一个数据包。
b) 为存储在另一正常 datanode 的当前数据块指定一个新的标志，并将该标志传送给 namenode ，以便故障 datanode 在恢复后可以删除存储的部分数据块。
c) 从管线中删除故障数据节点并且把余下的数据块写入管线中另外两个正常的 datanode 。namenode 在检测到副本数量不足时，会在另一个节点上创建新的副本。
d) 后续的数据块继续正常接受处理。
e) 在一个块被写入期间可能会有多个 datanode 同时发生故障，但非常少见。只要设置了 dfs.replication.min 的副本数（默认为 1），写操作就会成功，并且这个块可以在集群中异步复制，直到达到其目标副本数（dfs.replication 默认值为 3）。
如果有多个 block ，则会反复从步骤 4 开始执行。
当客户端完成了数据的传输，调用数据流的 close 方法。该方法将数据队列中的剩余数据包写到 datanode 的管线并等待管线的确认
客户端收到管线中所有正常 datanode 的确认消息后，通知 namenode 文件写完了。
namenode 已经知道文件由哪些块组成，所以它在返回成功前只需要等待数据块进行最小量的复制。

了解

64KB 数据包包含的头部信息

packet 接收者：

64KB 数据包格式：

HDFS 读文件流程（重点）

流程

客户端通过 FileSystem 对象的 open 方法打开希望读取的文件，DistributedFileSystem 对象通过 RPC 调用 namenode ，以确保文件起始位置。对于每个 block ，namenode 返回存有该副本的 datanode 地址。这些 datanode 根据它们与客户端的距离来排序。如果客户端本身就是一个 datanode ，并保存有相应 block 一个副本，会从本地读取这个 block 数据。
DistributedFileSystem 返回一个 FSDataInputStream 对象给客户端读取数据。该类封装了 DFSInputStream 对象，该对象管理着 datanode 和 namenode 的 I/O ，用于给客户端使用。客户端对这个输入调用 read 方法，存储着文件起始几个 block 的 datanode 地址的 DFSInputStream 连接距离最近的 datanode 。通过对数据流反复调用 read 方法，可以将数据从 datnaode 传输到客户端。到达 block 的末端时，DFSInputSream 关闭与该 datanode 的连接，然后寻找下一个 block 的最佳 datanode 。客户端只需要读取连续的流，并且对于客户端都是透明的。
客户端从流中读取数据时，block 是按照打开 DFSInputStream 与 datanode 新建连接的顺序读取的。它也会根据需要询问 namenode 来检索下一批数据块的 datanode 的位置。一旦客户端完成读取，就 close 掉 FSDataInputStream 的输入流。
在读取数据的时候如果 DFSInputStream 在与 datanode 通信时遇到错误，会尝试从这个块的一个最近邻 datanode 读取数据。它也记住那个故障 datanode ，保证以后不会反复读取该节点上后续的 block 。DFSInputStream 也会通过校验和确认从 datanode 发来的数据是否完整。如果发现有损坏的块，就在 DFSInputStream 试图从其他 datanode 读取其副本之前通知 namenode 。
Client 下载完 block 后会验证 DN 中的 MD5 ，保证块数据的完整性。

注意

namenode告知客户端每个block中最佳的datanode，并让客户端直接连到datanode检索数据。由于数据流分散在集群中的所有datanode，这样可以使HDFS可扩展到大量的并发客户端。同时，namenode只需要响应block位置的请求，无需响应数据请求，否则namenode会成为瓶颈。

伪分布式搭建

hadoop 官网地址：

http://hadoop.apache.org

中文文档：
http://hadoop.apache.org/docs/r1.0.4/cn

apache老版本软件下载地址：
https://hadoop.apache.org/old/releases.html#Download

安装&部署:
node1: NN DN SNN

1)基础设施GUN/Linuxjdk  1.7+环境:JAVA_HOME ->  /etc/profile   ~/.bash_profilessh免密:远程执行<-不需要用户交互,而是用户直接给出一个命令,直接在远程执行不会加载 /etc/profile远程登陆<-返回一个交互接口返回接口/bash  会加载/etc/profileip时间同步hosts/hostname2)应用的安装a)绿色:开箱即用(配置/部署)环境变量应用自己的环境变量JAVA_HOME ->  hadoop-env.shb)操作:formatstart使用

上传 hadoop 的 tar 包和 jdk 的 rpm 包

hadoop-2.6.5.tar.gz
jdkxxx.rpm

将文件上传到 /opt/apps 目录下

[root@node1 apps]# tar -zxvf hadoop-2.6.5.tar.gz -C /opt

安装 jdk 并配置环境变量

[root@node1 apps]# rpm -ivh jdk-8u221-linux-x64.rpm
[root@node1 apps]# vim  /etc/profile
export  JAVA_HOME=/usr/java/default
export  PATH=$PATH:$JAVA_HOME/bin
[root@node1 apps]# source  /etc/profile  或者  .  /etc/profile

配置免密钥

ssh-keygen  -t  dsa  -P  ''  -f  ~/.ssh/id_dsa
cat  ~/.ssh/id_dsa.pub  >  ~/.ssh/authorized_keys

解压 hadoop-2.6.5.tar.gz 到 /opt 目录

tar  -zxf  hadoop-2.6.5.tar.gz  -C  /opt

添加环境变量

将 HADOOP_HOME 以及 HADOOP_HOME/bin 和 HADOOP_HOME/sbin 添加到环境变量

export HADOOP_HOME=/opt/hadoop-2.6.5
export PATH=$PATH:$HADOOP_HOME/bin:$HADOOP_HOME/sbin

hadoop-env.sh 配置

$HADOOP_HOME/etc/hadoop

由于通过 SSH 远程启动进程的时候默认不会加载 /etc/profile 设置，JAVA_HOME 变量就加载不到，需要手动指定。

export  JAVA_HOME=/usr/java/jdk1.8.0_221-amd64

core-site.xml

<configuration><!-- 指定访问HDFS的时候路径的默认前缀  /  hdfs://node1:9000/ --><property><name>fs.defaultFS</name><value>hdfs://node1:9000</value></property><!-- 指定hadoop的临时目录位置，它会给namenode、secondarynamenode以及datanode的存储目录指定前缀 --><property><name>hadoop.tmp.dir</name><value>/var/bjsxt/hadoop/pseudo</value></property>
</configuration>

配置文件拷贝后格式不美观，可以通过以下方式格式化：

拷贝到对应的文件
Esc->Ctrl+V (下箭头选择要格式化的代码）
:!xmllint -format -
dd:再删除多没有<?xml …>
拷贝格式化后的代码，然后回车
dG 删除非格式的代码
i->Shift+Ins 将格式后的内容拷贝到文件中
保存并退出

hdfs-site.xml

<configuration><!-- 指定block副本数 --><property>
<name>dfs.replication</name>
<value>1</value></property><!-- 指定secondarynamenode所在的位置 --><property>
<name>dfs.namenode.secondary.http-address</name>
<value>node1:50090</value></property>
</configuration>

slaves

DataNode 所在的节点

[root@bk1 hadoop]# vim slaves
node1

格式化

hdfs  namenode  -format

启动

start-dfs.sh

查看进程

[root@node1 current]# jps
1943 SecondaryNameNode
1800 DataNode
1693 NameNode
2045 Jps

说明进程都正常启动了，然后网页访问：

http://node1:50070

查看文件系统

神马都没有：

上传文件

生成本地文件：

for i in `seq 100000`; do echo "hello bjsxt $i" >> hh.txt; done
ll -hhdfs dfs -D dfs.blocksize=1048576 -D dfs.replication=1 -put hh.txt /

cd /var/bjsxt/hadoop/pseudo/dfs/data/current/
cd current/BP-2057742434-192.168.20.91-1575827659318/current/finalized/subdir0/subdir0
ll -h
total 1.8M
-rw-r--r-- 1 root root 1.0M Dec 27 16:28 blk_1073741825
-rw-r--r-- 1 root root 8.1K Dec 27 16:28 blk_1073741825_1001.meta
-rw-r--r-- 1 root root 723K Dec 27 16:28 blk_1073741826
-rw-r--r-- 1 root root 5.7K Dec 27 16:28 blk_1073741826_1002.meta

关闭

[root@node1 ~]# stop-dfs.sh

总结-1

大文件如何存储？
单台服务器放不下，切块，将块打散放在各个datanode中文件要放进去，还要取出来文件分了多少块，每个块偏移量是多少，大小是多少
在哪些datanode上。元数据：一个文件的元数据放在NameNode的内存中放内存中应付高并发元数据很小，可以放内存方便用户浏览方便客户端操作