云计算（一）

:D 自从要好好的来学习云计算以来，就一直尽量在空余大量内阅读相关各种书籍与技术博客，看了久了，也该自己来写写一些了。云计算这种新事物总是很神奇，感觉上就觉得很高大上。现在是到自己来学习了，总是克服了一些思想上的困难总算是入了一点点门了吧。


HDFS框架
一、前提和设计目标

1、硬件错误是常态，而非异常情况，这种设计和我们之前写代码一直假设程序环境都是完美无缺的情况下的是完全不一样的。HDFS 可能是有成百上千的 server 组成，任何
一个组件都有可能一直失效，因此错误检测和快速、自动的恢复是 HDFS 的核心架构目标。
2、跑在 HDFS 上的应用与一般的应用不同，它们主要是以流式读为主，做批量处理；
比之关注数据访问的低延迟问题，更关键的在于数据访问的高吞吐量。
3、HDFS 以支持大数据集合为目标，一个存储在上面的典型文件大小一般都在千兆至T 字节，一个单一 HDFS 实例应该能支撑数以千万计的文件。
4、  HDFS 应用对文件要求的是 write-one-read-many 访问模型。一个文件经过创建、写，关闭之后就不需要改变。这一假设简化了数据一致性问题，使高吞吐量的数据访问
成为可能。典型的如 MapReduce 框架，或者一个 web crawler 应用都很适合这个模型。
5、移动计算的代价比之移动数据的代价低。一个应用请求的计算，离它操作的数据越近就越高效，这在数据达到海量级别的时候更是如此。将计算移动到数据附近，比之将数据移动到应用所在显然更好，HDFS 提供给应用这样的接口。

二、Namenode 和 Datanode

HDFS 采用 master/slave 架构。一个 HDFS 集群是有一个 Namenode 和一定数目的
Datanode 组成。 Namenode 是一个中心服务器，负责管理文件系统的 namespace 和客
户端对文件的访问。Datanode 在集群中一般是一个节点一个，负责管理节点上它们附带
的存储。一般情况下是一个物理机器部署一个Datanode。一个文件其实分成一个或多个 block，这些 block 存储在 Datanode 集合里。Namenode 执行文件系统的 namespace 操作，例如打开、关闭、重命名文件和目录，同时决定 block 到具体 Datanode 节点的映射。Datanode 在 Namenode 的指挥下进行 block 的创建、删除和复制。Namenode 和 Datanode 都是设计成可以跑在普通的廉价的运行 linux 的机器上。
HDFS 采用 java 语言开发，因此可以部署在很大范围的机器上，虽然这里我没太懂为啥。

三、文件系统的 namespace

HDFS 支持传统的层次型文件组织，与大多数其他文件系统类似，用户可以创建目录，
并在其间创建、删除、移动和重命名文件。HDFS 不支持 user quotas 和访问权限，也不
支持链接（link)，不过当前的架构并不排除实现这些特性。Namenode 维护文件系统的
namespace，任何对文件系统 namespace 和文件属性的修改都将被 Namenode 记录下
来。应用可以设置 HDFS 保存的文件的副本数目，文件副本的数目称为文件的 replication因子，这个信息也是由 Namenode 保存。

四、数据复制

HDFS 被设计成在一个大集群中可以跨机器地可靠地存储海量的文件。它将每个文件存
储成 block 序列，除了最后一个 block，所有的 block 都是同样的大小。文件的所有 block为了容错都会被复制。每个文件的 block 大小和 replication 因子都是可配置的。Replication 因子可以在文件创建的时候配置，以后也可以改变。HDFS 中的文件是
write-one，并且严格要求在任何时候只有一个 writer。Namenode 全权管理 block 的复制，它周期性地从集群中的每个 Datanode 接收心跳包和一个 Blockreport。心跳包的接收表示该 Datanode 节点正常工作，而 Blockreport 包括了该 Datanode 上所有的 block
组成的列表。
1、副本的存放，副本的存放是 HDFS 可靠性和性能的关键。HDFS 采用一种称为
rack-aware 的策略来改进数据的可靠性、有效性和网络带宽的利用。这个策略实现的短期
目标是验证在生产环境下的表现，观察它的行为，构建测试和研究的基础，以便实现更先进
的策略。庞大的 HDFS 实例一般运行在多个机架的计算机形成的集群上，不同机架间的两
台机器的通讯需要通过交换机，显然通常情况下，同一个机架内的两个节点间的带宽会比不
同机架间的两台机器的带宽大。在大多数情况下，replication 因子是 3，HDFS 的存放策略是将一个副本存放在本地机架上的节点，一个副本放在同一机架上的另一个节点，最后一个副本放在不同机架上的一个节点。机架的错误远远比节点的错误少，这个策略不会影响到数据的可靠性和有效性。三分之一的副本在一个节点上，三分之二在一个机架上，其他保存在剩下的机架中，这一策略改进了写的性能。
2、副本的选择，为了降低整体的带宽消耗和读延时，HDFS 会尽量让 reader 读最近
的副本。如果在 reader 的同一个机架上有一个副本，那么就读该副本。如果一个 HDFS
集群跨越多个数据中心，那么 reader 也将首先尝试读本地数据中心的副本。


五、文件系统元数据的持久化

Namenode 存储 HDFS 的元数据。对于任何对文件元数据产生修改的操作，Namenode 都使用一个称为 Editlog 的事务日志记录下来。Namenode 在内存中保存着整个文件系统 namespace 和文件 Blockmap 的映像。 这个关键的元数据设计得很紧凑，因而一个带有 4G 内存的  Namenode 足够支撑海量的文件和目录。当 Namenode 启动时，它从硬盘中读取 Editlog 和 FsImage，将所有 Editlog中的事务作用（apply)在内存中FsImage  ，并将这个新版本的 FsImage 从内存中 flush到硬盘上,然后再 truncate 这个旧的Editlog，因为这个旧的 Editlog 的事务都已经作用在FsImage 上了。这个过程称为 checkpoint.


六、通讯协议

所有的 HDFS 通讯协议都是构建在 TCP/IP 协议上。客户端通过一个可配置的端口连接
到 Namenode，通过 ClientProtocol 与  Namenode 交互。而 Datanode 是使用
DatanodeProtocol 与 Namenode 交互。从 ClientProtocol 和  Datanodeprotocol 抽象出一个远程调用(RPC），在设计上，Namenode 不会主动发起 RPC，而是是响应来自客
户端和  Datanode  的 RPC 请求。

七、健壮性

HDFS 的主要目标就是实现在失败情况下的数据存储可靠性。常见的三种失败：
Namenode failures, Datanode failures 和网络分割（network partitions)

1、硬盘数据错误、心跳检测和重新复制
每个 Datanode 节点都向 Namenode 周期性地发送心跳包。网络切割可能导致一部分
Datanode 跟 Namenode 失去联系。  Namenode 通过心跳包的缺失检测到这一情况，
并将这些 Datanode 标记为 dead，不会将新的 IO 请求发给它们。寄存在 dead Datanode上的任何数据将不再有效。 Datanode 的死亡可能引起一些 block 的副本数目低于指定值，Namenode 不断地跟踪需要复制的  block，在任何需要的情况下启动复制。在下列情况可能需要重新复制：某个 Datanode 节点失效，某个副本遭到损坏，Datanode 上的硬盘错误，或者文件的 replication 因子增大。

2、集群均衡
HDFS 支持数据的均衡计划，如果某个 Datanode 节点上的空闲空间低于特定的临界
点，那么就会启动一个计划自动地将数据从一个 Datanode 搬移到空闲的 Datanode。当
对某个文件的请求突然增加，那么也可能启动一个计划创建该文件新的副本，并分布到集群
中以满足应用的要求。这些均衡计划目前还没有实现。

3、数据完整性
从某个 Datanode 获取的数据块有可能是损坏的，这个损坏可能是由于 Datanode 的
存储设备错误、网络错误或者软件 bug 造成的。HDFS 客户端软件实现了 HDFS 文件内容的校验和。当某个客户端创建一个新的 HDFS 文件，会计算这个文件每个 block 的校验和，并作为一个单独的隐藏文件保存这些校验和在同一个 HDFS namespace 下。当客户端检索文件内容，它会确认从 Datanode 获取的数据跟相应的校验和文件中的校验和是否匹配，如果不匹配，客户端可以选择从其他 Datanode 获取该 block 的副本

4、元数据磁盘错误
FsImage 和 Editlog 是 HDFS 的核心数据结构。这些文件如果损坏了，整个 HDFS 实
例都将失效。因而，Namenode 可以配置成支持维护多个 FsImage 和 Editlog 的拷贝。
任何对 FsImage 或者 Editlog 的修改，都将同步到它们的副本上。这个同步操作可能会降低  Namenode 每秒能支持处理的 namespace 事务。这个代价是可以接受的，因为 HDFS是数据密集的，而非元数据密集。当 Namenode 重启的时候，它总是选取最近的一致的
FsImage 和 Editlog 使用。

5、快照
快照支持某个时间的数据拷贝，当 HDFS 数据损坏的时候，可以恢复到过去一个已知正确的时间点。HDFS 目前还不支持快照功能。


八、数据组织

1、数据块
兼容 HDFS 的应用都是处理大数据集合的。这些应用都是写数据一次，读却是一次到
多次，并且读的速度要满足流式读。HDFS 支持文件的 write- once-read-many 语义。
一个典型的 block 大小是 64MB，因而，文件总是按照 64M 切分成 chunk，每个 chunk
存储于不同的  Datanode
2、步骤
某个客户端创建文件的请求其实并没有立即发给 Namenode，事实上，HDFS 客户端
会将文件数据缓存到本地的一个临时文件。应用的写被透明地重定向到这个临时文件。当这
个临时文件累积的数据超过一个 block 的大小（默认 64M)，客户端才会联系 Namenode。
Namenode 将文件名插入文件系统的层次结构中，并且分配一个数据块给它，然后返回
Datanode 的标识符和目标数据块给客户端。客户端将本地临时文件 flush 到指定的 Datanode 上。当文件关闭时，在临时文件中剩余的没有 flush 的数据也会传输到指定的
Datanode，然后客户端告诉 Namenode 文件已经关闭。此时 Namenode 才将文件创建
操作提交到持久存储。如果 Namenode 在文件关闭前挂了，该文件将丢失。
上述方法是对通过对 HDFS 上运行的目标应用认真考虑的结果。如果不采用客户端缓
存，由于网络速度和网络堵塞会对吞估量造成比较大的影响。

3、流水线复制
当某个客户端向 HDFS 文件写数据的时候，一开始是写入本地临时文件，假设该文件
的 replication 因子设置为 3，那么客户端会从 Namenode  获取一张 Datanode 列表来存放副本。然后客户端开始向第一个 Datanode 传输数据，第一个 Datanode 一小部分一小部分（4kb)地接收数据，将每个部分写入本地仓库，并且同时传输该部分到第二个
Datanode 节点。第二个 Datanode 也是这样，边收边传，一小部分一小部分地收，存储
在本地仓库，同时传给第三个 Datanode，第三个 Datanode 就仅仅是接收并存储了。这
就是流水线式的复制。


九、可访问性

HDFS 给应用提供了多种访问方式，可以通过 DFSShell 通过命令行与 HDFS 数据进
行交互，可以通过 java API 调用，也可以通过 C 语言的封装 API 访问，并且提供了浏览器访问的方式。正在开发通过 WebDav 协议访问的方式。具体使用参考文档

十、空间的回收

1、文件的删除和恢复
用户或者应用删除某个文件，这个文件并没有立刻从 HDFS 中删除。相反，HDFS 将
这个文件重命名，并转移到/trash 目录。当文件还在/trash 目录时，该文件可以被迅速地恢复。文件在/trash 中保存的时间是可配置的，当超过这个时间， Namenode 就会将该文件从 namespace 中删除。文件的删除，也将释放关联该文件的数据块。注意到，在文件
被用户删除和 HDFS 空闲空间的增加之间会有一个等待时间延迟。当被删除的文件还保留在/trash 目录中的时候，如果用户想恢复这个文件，可以检索浏览/trash 目录并检索该文件。/trash 目录仅仅保存被删除文件的最近一次拷贝。/trash目录与其他文件目录没有什么不同，除了一点： HDFS 在该目录上应用了一个特殊的策略来自动删除文件，目前的默认策略是删除保留超过 6 小时的文件，这个策略以后会定义成可配置的接口。