HDFS设计基础与目标
- 硬件错误是常态。因此需要冗余
- 流式数据访问。即数据批量读取而非随机读写，Hadoop擅长做的是数据分析而不是事务处理(随机性的读写数据等)。
- 大规模数据集
- 简单一致性模型。为了降低系统复杂度，对文件采用一次性写多次读的逻辑设计，即是文件一经写入，关闭，就再也不能修改
- 程序采用“数据就近“原则分配节点执行
HDFS体系结构
Namenode:
- 管理文件系统的命名空间
- 记录每个文件数据块在各个Datanode上的位置和副本信息
- 协调客户端对文件的访问
- 记录命名空间内的改动或空间本身属性的改动
- Namenode使用事务日志记录HDFS元数据的变化。使用映像文件存储文件系统的命名空间，包括文件映射(fsimage)，文件属性等
Datanode:
- 负责所在物理节点的存储管理
- 一次写入，多次读取（不修改），因此不需要考虑一致性问题
- 文件由数据块组成，典型的块大小是64MB
- 数据块尽量散布道各个节点
Hadoop读取HDFS数据的流程：
- 客户端要访问HDFS中的一个文件
- 首先从namenode获得组成这个文件的数据块位置列表
- 根据列表知道存储数据块的datanode
- 访问datanode获取数据
- Namenode并不参与数据实际传输
HDFS可靠性：
- 冗余副本策略
hdfs-site.xml中指定，副本越大越安全，但是资源利用率越低。
- 机架策略
3份副本策略：本地，本机架，其他机架。
- 心跳机制
Namenode周期性从datanode接收心跳信号和块报告，根据块报告验证元数据，没有按时发送心跳的datanode会被标记为宕机，不会再给它任何I/O请求，如果datanode失效造成副本数量下降，并且低于预先设置的阈值，namenode会检测出这些数据块，并在合适的时机进行重新复制，引发重新复制的原因还包括数据副本本身损坏、磁盘错误，复制因子被增大等。
- 安全模式
Namenode启动时会先经过一个“安全模式”阶段，安全模式阶段不会产生数据写，在此阶段Namenode收集各个datanode的报告，当数据块达到最小副本数以上时，会被认为是“安全”的。在一定比例（可设置）的数据块被确定为“安全”后，再过若干时间，安全模式结束。当检测到副本数不足的数据块时，该块会被复制直到达到最小副本数。
- 校验和
- 回收站
删除一个文件时，其实放入回收站/trash中，回收站中的文件可以快速恢复，通过设定时间阈值，当超过这个阈值，就被彻底删除并释放占用的数据块。
- 元数据保护
- 快照机制
HDFS中Namenode的持久化机制：
HDFS 在解决namenode元数据持久性问题时，采用了一种事物日志（transaction log,called EditLog) + 文件系统镜像文件（FsImage)的办法。日志文件和镜像文件都存储在主机本地文件系统中。 当HDFS运行时，在内存中有一份整个文件系统元数据的镜像。当对HDFS进行修改性操作时，系统只修改内存中的文件系统元数据镜像，并在事物日志中添加操作记录，并不及时修改硬盘中的FsImage文件。只有当namenode下次启动时，系统会从磁盘上同时读取EditLog 和 FsImage两个文件，并根据EditLog中记录的操作来修改（或者叫更新）FsImage，然后将新版本的FsImage写回磁盘并清空EditLog。这时候，磁盘和内存中的FsImage文件都是最新的。
HDFS文件操作
命令行方式
hadoop fs –put <local path> <hdfs path> //将本地文件放入HDFS中 hadoop fs –ls <hdfs path> //显示文件目录 hadoop fs –get <hdfs path> <local path> //将Hdfs中的数据拷贝到本地 hadoop fs –rmr <file> //删除文件,如果开启回收站了会到回收站里面 hadoop fs –cat <file path> //查看文件内容 hadoop dfsadmin –report //查看hdfs目前状态
注：有些地方命令是hadoop dfs …..这个跟hadoop fs一样的，没什么区别。
JAVA API方式
这个就不多说了。。。