HDFS

问题一：
假设有大小为一个 T 的文本文件，这个文件每行都是一个字符串且每行的字符串不会太大，这个文件中有且只有重复的两行，需求是如何用一台内存大小为 64M 的电脑找出这两个重复行的位置。

方案一：
利用冒泡排序的思想，从文件中先读出第一行然后然后逐一从文件中读出第二行、第三行 … 与第一行进行比较，如果找到相同行则停止，否则从文件中读取第二行，然后再跟第三行、第四行 … 进行比较，以此类推。

方案二：
利用归并排序的思想，先将该文件分为很多个小文件，然后对每个小文件按大小进行排序，在排序过程中如果发现有相同行则停止，否则对这些小文件进行归并排序，排序过程中如果发现有相同行则停止，否则继续归并。

方案三：
倒排索引的思想，可以在内存中建立一个结点数组，从文件中每读取一行，就与数组中已存储的值进行比较，如果有相同的，则在该数组所对应位置的结点中记录所在行和出现次数 +1，如果不同，则将该字符串加入到数组中并在该结点记录所在行和出现次数为 1。该方法适用于重复行出现次数较多的，对于本题要求来说，只有两行重复，显然内存中放不下该数组，因此可以写入到磁盘中。

方案四：
将文件逐行读取，每读出一行通过 hash 算法映射为一个数，然后做取模运算，就可以将这个大文件拆分为很多个小文件，此时重复的两行必然在某个小文件中，然后在对每个小文件检索查找是否有重复行。

问题二：
假设还是有 1T 的文件，文件中有很多行，每行存放一个数字，且每行的数字基本不会重复，但是该文件是乱序的，要求对该文件进行全排序。

方案一：
以行为单位进行读取，然后将 0-100 范围的数字放到一个小文件中，101-200 范围的数字放到另一个小文件中，以此类推，此时从宏观上看这些小文件内部无序，外部有序，然后对每个小文件进行排序。

方案二：
归并排序。。。

1. Hadoop 简介

Hadoop 创始人 Doug Cutting，在就职 Yahoo 期间开发了 Hadoop 项目，Hadoop 名字来源于 Doug Cutting 儿子的玩具大象。

Hadoop 是 Apache 基金会的一个顶级项目，主要包括以下四个模块：

• Hadoop Common：支持其它 Hadoop 模块的常用实用程序。
• HDFS （Hadoop Distributed File System）：分布式文件系统，提供了高可靠性、高扩展性和高吞吐率的数据存储服务。
• MapReduce：分布式计算框架。
• YARN（Yet Another Resource Manager）：分布式资源管理框架，负责集群资源的管理和调度。

项目起源以及发展历程：

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 (Nutch Distributed File System)来运行，在20个节点稳定运行。

2006年1月，Doug Cutting 加入雅虎，Yahoo! 提供一个专门的团队和资源将 Hadoop 发展成一个可在网络上运行的系统。

2006年2月，Apache Hadoop 项目正式启动以支持 MapReduce 和 HDFS 的独立发展。

2. HDFS

HDFS 设计思想

HDFS 被设计成用来使用低廉的服务器来进行海量数据的存储，那是怎么做到的呢？
1、 将大文件切割成小文件（Block），使用分而治之的思想让很多服务器对同一个文件进行联合管理
2、 每个小文件做冗余备份，并且分散存到不同的服务器，做到高可靠不丢失

这样做的好处就是：分而治之，并行计算。就是将大文件、大批量文件，分布式的存放于大量服务器上，以便于采取分而治之的方式对海量数据进行运算分析。

HDFS 存储模型

HDFS 是以字节为单位，将文件线性切割成块（Block），并将 Block 分散存储在集群结点中。

关于 Block 的说明：
Block 有 偏移量（offset） 和 位置信息
单一文件 Block 大小一致，不同文件的 Block 可以不一致
Block 可以设置副本数，副本分散在不同的节点中
文件上传时可以设置 Block 大小和副本数
已上传文件的 Block 副本数可以调整，大小不能改变
只支持一次写入多次读取，同一时刻只有一个写者
可以 append 在文件末尾追加数据，不可以插入数据

HDFS 架构模型

HDFS 的架构模型是一个主从模型

主节点：NameNode（数据是存在内存中）
1、保存文件的元数据信息 metadata（文件 ownership 和 permissions、文件大小和时间、Block 偏移量）
2、维护 HDFS 的虚拟目录树结构
3、管理 Block 的映射信息（由 DataNode 上报）
4、处理客户端读写请求

从节点：DataNode（数据在磁盘）
1、保存文件 Block 数据
2、执行数据的读写操作

客户端：HDFSClient
1、文件切分，文件上传 HDFS 的时候，HDFSClient 将文件切分成一个一个的 Block，然后进行存储。
2、与 NameNode 交互，获取文件的位置信息。
3、与 DataNode 交互，读取或者写入数据。
4、Client 提供一些命令来管理 HDFS，比如启动或者关闭 HDFS。
5、Client 可以通过一些命令来访问 HDFS。

DataNode 与 NameNode 之间保持心跳，向 NameNode 提交 Block 映射信息（也就是位置信息）。

HDFSClient 先与 NameNode 交互元数据信息，然后 HdfsClient 再与 DataNode 交互文件 Block 数据。

SecondaryNameNode：并非 NameNode 的热备，只是辅助 NameNode，分担其工作量，合并 fsimage 和 edits，并推送给 NameNode。

HDFS 优缺点

HDFS 优点

1、高容错性

• 数据自动保存多个副本
• 副本丢失后，自动恢复

2、适合批处理

• 移动计算而非移动数据（计算向数据移动）
• 数据位置暴露给计算框架（Block 偏移量）

3、适合大数据处理

• 能够处理 GB、TB、甚至 PB 级数据
• 能处理百万规模以上的文件数量
• 能够处理10K以上的节点

4、可构建在廉价机器上

• 通过多副本提高可靠性
• 提供了容错和恢复机制

HDFS 缺点

1、不适合低延迟数据访问

• 比如毫秒级
• 低延迟与高吞吐率

2、不适合小文件存取

• 由于 NameNode 是基于内存存储的，过多的小文件会占用 NameNode 大量内存来存储文件的元数据信息
• 小文件的寻道时间超过读取时间

3、不能并发写入、文件随机修改

• 一个文件只能有一个写者
• 仅支持 append

安全模式

1、NameNode 启动的时候，首先将映像文件 (fsimage) 载入内存，并执行编辑日志 (edits) 中的各项操作。
2、一旦在内存中成功建立文件系统元数据的映射，则创建一个新的 fsimage 文件 (这个操作不需要SecondaryNameNode) 和一个空的 edits。
3、此刻 NameNode 运行在安全模式。即 NameNode 的文件系统对于客服端来说是只读的。(显示 目录，显示文件内容等。写、删除、重命名都会失败)。
4、在此阶段 NameNode 收集各个 DataNode 的报告，当数据块达到最小副本数以上时，会被认为是“安全”的，在一定比例（可设置）的数据块被确定为“安全”后，再过若干时间，安全模式结束。
5、当检测到副本数不足的数据块时，该块会被复制直到达到最小副本数，系统中数据块的位置并不是由 NameNode 维护的，而是以块列表形式存储在 DataNode 中。

NameNode 持久化

由于 NameNode 是基于内存存储的，故需要对 NameNode 持久化。

有两种情况可以触发持久化
1、默认是每隔一定时间触发一次（默认是 3600 秒）
2、默认 edits 日志达到一定大小触发一次（默认是 64 MB）

简单来说就是 SNN 从 Namenode 中拉取 fsimage 和 edits 合并后，产生一个新的 fsimage 文件并将其推回给 NameNode。

例如达到 3600s 后，SNN 从 NameNode 中拉取 fsimage 和 edits 合并成 fsimage.ckpt 并推回给 NameNode，在此期间 NameNode 会将日志信息写到一个新的 edits 中，如果这个新的 edits 达到 64 MB，SNN 就将其从 NameNode 中拉取过来，与新的 fsimage 合并再推回给 NameNode，以此类推。

总的来说，只要达到 3600s SNN 就会从 NN 中拉取 fsimage 和 edits，没有达到 3600s 但 edits 达到64 MB，SNN 就只拉取 edits。

Block 副本放置策略

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

HDFS 写流程

Client 先将文件切分成多个 Block
按 Block 线性和 NN 获取 DN 列表（DN 数量和副本数相同）
验证 DN 列表后，将 Block 以更小的单位 流式传输 数据（pipeline 时间线重叠：Client 和 1stDN 建立 socket，1stDN 和 2edDN 建立 socket … 小片传输：4K，Client 给 1stDN，1stDN 同时本机缓存，瞬间放入下游 socket 中）
Block 传输结束后：
DN 向 NN 汇报 Block 信息
DN 向 Client 汇报完成
Client 向 NN 汇报 BlockX 传输完成，然后给我下一个 Block 节点信息
…
全部传输完成，NN 更新元数据状态可用

HDFS 读流程

Client 先和 NN 获取 Block 副本位置列表，同一 Block 按照重复数会返回多个 locations，这些 locations 按照 Hadoop 拓扑结构排序，距离客户端近的排在前面。
Client 线性和 DN 获取 Block，最终合并为一个文件