3.1 HDFS简介
Hadoop平台解决两大核心问题：
- 分布式存储
- 分布式处理
HDFS就是解决海量数据分布式存储
背景：大数据时代，对于海量的数据，单个计算机无法处理，只能借助整个集群来处理海量数据。
文件系统结构（主从结构）：
主节点：承担起目录作用，比如元数据服务。
从节点：实现数据存取的任务。
概念：HDFS是分布式文件系统，即文件通过网络在多个主机共享的文件系统，让多个机器的多个用户分享文件和存储空间。
特点：通透性：DFS是通过网络完成访问文件的动作，由用户和程序来看就像访问本地磁盘一样。
HDFS架构：采用master/salve结构，是管理者-工作者模式。
实现目标：
- 兼容廉价的硬件设备
- 实现流数据读写（对于数据整个读写或者大部分读写，不会访问某一个子集，或一个块），满足海量数据批处理需求
- 支持大数据集
- 支持简单的文件模型，牺牲一些相关的性能，但是获取批量数据的特性，只允许追加不允许修改
- 强大的跨平台兼容性，基于java语言开发的，java具有良好的跨平台特性
自身局限性：
- 不适合低延迟数据访问，只能批量的读取数据，不能精确的定位到某一条数据，不能满足实时的处理需求（HBS可以）
- 无法高效存储大量小文件，如果小文件太多，索引节点太多，索引效率过低
- 不支持多用户写入和任意修改文件（设计的时候就是只允许追加不允许修改）
3.2 HDFS相关概念
块
（1）联系：为了分摊磁盘的读写开销
（2）区别：比普通的文件（64M）系统块大很多
（3）设计目的：
- 支持面向大规模数据存储
- 降低分布式节点的寻址开销：三级寻址（元数据目录，数据节点，块）
（4）缺点：如果块太大会导致Mapredecu就一两个任务在执行，完全牺牲了Mapreduce的并行度，发挥不了分布式并行处理的效果
使用块的好处：
（1）支持大规模文件存储：把大文件进行切割，分布式的存储到不同机器上
（2）简化系统设计：块大小是固定的，文件除以块的大小，可以算出块需要多少，元数据设计简单
（3）适合数据备份：一个块存储到多个荣誉的节点上
HDFS组件：
- 名称节点：
（1）名称节点是一个中心服务器，负责管理文件系统的命名空间
（2）协调客户端对文件的访问
（3）执行对命名空间的操作
（4）记录每个文件数据块在数据节点的位置和副本信息 - 数据节点：
（1）负责所在物理节点的管理，是真正数据存储的地方
（2）负责处理客户端的文件读写请求
（3）在名称节点的指挥下负责数据块的创建、删除、复制
（4）周期性的向名称节点汇报数据块信息 - 客户端节点：
（1）把文件切分成一个个数据包
（2）访问或命令行管理HDFS
（3）与名称节点交互，获取文件位置信息
（4）与数据节点交互，读取和写入数据
元数据信息：
- 文件是什么
- 文件被分成多少块
- 每个块和文件是怎么映射的
- 每个块 被存储在哪个服务器上
名称节点的数据结构：
- FsImage：保存系统文件树
- EditLog：记录对数据进行的诸如创建、删除、重命名等操作
FsImage负责：
- 块大小以及组成文件的块
- 文件的复制等级
- 修改和访问时间
- 访问权限
其中数据块存放在哪些节点不是通过FsImage，而是以下过程
过程：
当数据节点加入到一个集群中去，数据节点像名称节点汇报自己节点上保存了哪些数据块，名称节点就可以自己构建一个清单，这些信息保存在内存中。
名称节点运行机制
首先将FsImage从磁盘读入到内存，和EditLog各项操作进行合并，FsImage存储是历史数据，通过EditLog记录的操作得到最新的元数据，把新版的FsImage保留下来，把旧版的删除，同时创建一个空的EditLog文件。
优点：FsImage对于大数据来讲规模非常大，每次不断改FsImage，会导致系统运行很慢。把更新的部分单独存储起来，EditLog规模很小，操作效率很高。
存在的问题：EditLog会不断增大，大到一定程度又会影响系统性能
第二名称节点
任务：
（1）名称节点的冷备份
（2）对EditLog不断增大的处理
第二名称节点运行机制：
定期地与名称节点通信，在阶段会请求名称节点停止使用EditLog文件，此时名称节点生成一个edit.new文件，把新到达地更新全部写到edit.new文件中，第二名称节点通过HTTPget方式把原来旧的FsImage和EditLog下载到本地，在第二名称对FsImage更新（FsImage和EditLog合并操作）得到一个新的FsImage，再发送个名称节点，edit.new更改为edit
数据节点
运行机制：
Blockreport：当数据节点启动后，扫描本地文件系统，生成HDFS数据块系统列表，像名称节点发送一个报告
过程：
Datanode启动后向名称节点注册，注册成功后，以后每一个周期上报自己所有数据块信息，然后每4秒给名称节点发送心跳，心跳返回名称节点给数据节点的命令，如果一段时间没有心跳认为该数据节点不可用。
3.3 HDFS体系结构（主从架构）
客户端读数据：先访问名称节点，知道文件存储在哪些数据节点，从而客户端去各个数据节点的位置获取数据
客户端写数据：先访问名称节点，知道文件存储到哪些数据节点，从而客户端去各个数据节点的位置存储数据
HDFS命名空间：
包括目录文件块
/+目录名称
通信协议：
HDFS的通信协议都是构建在TCP/IP上，客户端到名称节点使用TCP客户端协议，名称节点到数据节点使用专门数据协议
客户端取数据使用远程的RPC协议
局限性：
- 命名空间限制：名称节点是保存在内存中的，因此名称节点能容纳的对象（文件、块）的个数会受到空间大小限制
- 性能的瓶颈：整个分布式文件的吞吐量，受限于单个节点的吞吐量
- 隔离问题：由于集群中只有一个名称节点，只有一个命名空间，因此无法对不同的应用程序进行隔离
- 集群的可用性：一旦这个唯一的名称节点发生故障，会导致整个集群变得不可用。
关于第二名称节点：由于他是冷备份所以不能解决集群单点故障问题
冷备份：不能保证发生故障就可以立马代替故障节点，必须停止一段时间，慢慢恢复，再提供对外恢复。
3.4 HDFS存储原理
数据冗余保存（默认是3）
好处：
- 加快数据传输速度：同样的任务可以并行访问冗余的节点
- 容易检查错误数据：通过和备份的数据对比
- 保证数据可靠性：一但系统探测到副本发生故障，会自动复制，把整个副本数恢复到原来数目。
数据块存放：
首先对块复制三份，第一份放在上传文件的数据节点，如果提交数据的请求不是来自集群内布，HDFS随机挑选一个磁盘不太满，CPU不太忙的数据节点放置，第二节点放在与第一节点不同的机架上。第三个副本放在第一个副本相同机架的其他节点上
数据读取
就近读取：HDFS提供一个API可以确定一个数据节点所属的机架ID，客户端也可以调用自己API获取自己所属的机架ID。
过程：客户端从名称节点获得数据块不同副本的存放位置列表，列表中包含了副本所在的数据节点，调用API确定客户端和数据节点的机架ID，优先从ID相同的机架读取，如果没有就随机读取。
数据的错误和恢复
名称节点出错：
通过第二名称节点备份恢复（1.0）
数据节点：
定期向名称节点发送心跳信息，告诉自己活着，一旦一段时间名称节点收不到信息，知道它发送故障，将其标记为宕机，把凡是存储在故障机上的数据重新分发到其他可以的机器上。
数据出现错误：
磁盘损坏等。
客户端读取数据使用校验码校验，如果出现错误，就会发现不对。对冗余数据进行复制。
3.5 HDFS读写过程
读过程：
（1）打开文件：
HDFS客户端发起，生成DistributedFileSystem类对象，创建一个FSDataInputStream
（2）获取数据块信息：
通过远程调用从名称节点获取数据块信息，名称节点会把文件开始的一部分文件信息返回
（3）读取请求：
客户端收到文件信息列表，执行read函数，从距离客户端最近的数据节点建立连接。读完以后关闭输入流和数据节点连接
（4）获取数据块信息：
再去输入流去获取文件的下一个数据块信息
（5）读取数据
…
（6）关闭文件
写过程：
（1）创建文件请求：
客户端节点创建文件请求，创建分布式文件系统和一个输出流
（2）创建文件元数据：
输出流调用名称节点，让名称节点在命名空间中新建一个文件，名称节点会检查文件是否存在，客户端是否有权限创建。如果都通过就会创建
（3）写数据：
把数据分成一个个分包，分别放入输出流的内部队列，输出流向名称节点申请保存这些数据块的数据节点，把分包发到第一个数据节点，第一个数据节点再发到第二个数据节点，第二个数据节点再发到第三个数据节点
（4）返回确认包：
由最后一个节点传给前一个节点，依次往前。
（5）关闭文件
3.6 HDFS的稳健性
1、故障类型
- 节点故障
- 通讯故障
- 数据损坏
（1）数据在网络中损坏
（2）数据存储在硬盘中损坏
2、故障检测
- 节点故障检测：
数据节点每三秒发送一个心跳信号，如果名称节点10分钟没有接受到，就认为数据节点挂掉了。 - 网络故障检测：
没测发送数据时，接收者会回复一个应答信号，如果没有收到应答信号（多次尝试），发送者就会认为主机已经挂掉，或者发送网络错误。 - 数据损坏故障检测：
HDFS客户端实现对文件内容的校验和，HDFS写入的时候计算校验和，然后每次读的时候再计算校验和，硬盘存储数据的同时也会存储校验和
3.7 HDFS的可访问性
（1）提供一个命令行接口让用户和HDFS数据交互
（2）通过原生的FileSystem Java API接口访问
（3）通过浏览器的方式访问HDFS中的实例文件
3.8 HA架构
1、解决的问题：
为了解决名称节点单点故障的问题，为名称节点保存一个热备，两个独立的机器作为名称节点：Active Namenode,Standby Namenode。任何时候只有一个节点处于Active状态，另一个处于Standby状态。前者用于接受客户端请求，后者作为salve保持群的状态数据以备快速failover。
2、HA结构
3、快速failover
数据节点需要同时配置两个名称节点地址，同时建立心跳链接，并把块位置发给他们。当Active失效后，Standby切换成Active
4、两种常见方案
（1）NFS
- 实现机制：
active和standby需要共享一个存储目录，active把数据变更日志保存在该目录，同时standby监视更新，保持数据同步，为了保证active挂了以后不再有新数据写入，Fencing逻辑切断所有与active连接。 - 局限性：
1）只支持一个数据变更共享目录，导致HA能力受限于该目录。
2）为防止共享目录的单点失效，对共享目录有额外的要求。
3）NFS方式部署更复杂。
（2）QJM
- 实现机制：
两个节点都与一组称为JNS的互相独立的进程保持通信，当active更新命名空间，把修改日志发送给JNS的多数派，standby从JNS读取edit，持续关注日志变更，把变更应用到自己的命名空间中。
5、两者比较
（1）共同点：
- 都是热备方案
- 都是一个active和一个standby
- 都使用ZK quorum和ZKFC实现自动恢复
- 在失效恢复时都需要配置fencing方法来断开active
（5）不同点
- 分享的数据方式不同
- 参与HA的不同角色
3.9 HDFS优缺点
（1）优点：
（2）缺点：
（3）主要问题：
