前言
- 在大数据场景中，大量数据是以文件形式储存的，典型的是行为日志数据（用户搜索日志，购买日志，点击日志，以及机器操作数据等）
- 这些数据都很重要，则就必须满足可扩展，容错，易用等特点
背景
HDFS的出现主要解决一下问题：
- 容错性
数据越来越大，所以储存的服务器就会原来越多，这就要求当中一台服务器异常不影响数据 - 统一格式储存
数据的大小各不相同，这就要求数据的保存要从新定义，（block 块是一个很好的解决问题） - 一次写入多次读取
有些数据（日志）只会写一次，多次读取
分布式系统的存储种类
- 文件级别的分布式系统
存储单位是文件 - 块级别的分布式系统
存储单位是将文件分为的等大小的块
HDFS的基本架构
hdfs 采用主从架构（master-slave）
NameNode(主节点)
hdfs的集群管理者，负责管理集群的元信息(维护整个文件的目录结构树和数据块信息)和管理datanode（通过心跳周期性的检测DataNode的存活状态
NameNode的相关问题
1、单点故障：
一个集群只有一个NameNode为之服务，称为“active NameNode”,为了避免单点故障，可备用一台备用机“standby NameNode”;
2、主备切换：
手动模式：通过命令
自动模式：借助zookeeper
3、状态同步：
借助第三方日志储存系统，activeNameNode将操作日志写入共享系统，standby NameNode从共享系统中读取出来拓展
当数据越来越大时，单个nameNode会成为数据传输的瓶颈，这是就需要对NameNode进行分片，也就是可以允许多个NameNode 对集群进行服务（当然，也得考虑单点故障）
SecondNameNode(检查点节点)
- 首先，它定时到NameNode去获取edit logs，并更新到fsimage上。
- 一旦它有了新的fsimage文件，它将其拷贝回NameNode中。
- NameNode在下次重启时会使用这个新的fsimage文件，从而减少重启的时间。
DataNode(从节点)
- 储存实际的数据块，通过心跳即时汇报自己的状态信息
Client(客户端)
- 用户借助client来与nameNode 和 dataNode 进行交互，完成各种操作
- client 完成数据的分块
- client 向dataNode传输数据是流水线操作
Hdfs的容错
- NameNode 异常
前面已经提到了nameNode 可设置主从配置 - DataNode 服务器异常
Hdfs的数据默认是3副本，当发现有数据异常，nameNode 可从新分配 - 数据块损坏
NataNode在存储数据的时候，会相应的生成一段随机数，当读取的时候发现随机数不一致，就认为数据失效了
HDFS的副本放置策略
- 客户端与Datanode 同节点（第一个副本写在同节点的datanode上，另外两个副本写在另一个相同机架的不同dataNode上）
- 客户端与NameNode 与dataNode 不同节点，（第一个副本会随机写在一个nataNode上，另外两个写在另一个相同机架的不同节点上）
HDFS的异构存储介质
- hdfs 可支持多种储存介质（固态硬盘，内存等）
集中式缓存管理
HDFS可通过命令或者api来管理集中式缓存系统中的文件和目录，来提高效率
访问方式
- shell
- api
