为了让粉丝老爷们直接获取干货，我把每日札记放到额外的文章中啦！
HDFS 的地位为何如此稳固
在整个大数据体系里面，最宝贵、最难以替代的资源就是数据。
大量数据是以文件形式保存的，典型代表是行为日志数据（用户搜索日志、购买日志、点击日志以及机器操作日志等）。
这些文件形式的数据具有价值高、数据大、流式产生的特点，需要一个分布式文件系统存储它们，该文件系统应具有良好的容错性、扩展性和易用的 API。
而HDFS 就是一个理想的解决方案。
如果我们把大数据计算比作烹饪，那么数据就是食材，而分布式文件系统 HDFS 就是那口烧菜的大锅。
HDFS 作为最早的大数据存储系统，存储着宝贵的数据资产，各种新的算法、框架要想得到人们的广泛使用，必须支持 HDFS 才能获取已经存储在里面的数据。
所以大数据技术越发展，新技术越多，HDFS 得到的支持越多，我们越离不开 HDFS。
HDFS 也许不是最好的大数据存储技术，但依然最重要的大数据存储技术。
存储大数据的挑战在哪里
首先就是每天新增的数据量特别多，可多达 GB 级别，甚至是 TB 级别，新增的文件数量可能多达 10 万 级别。
为了应对数据扩容的问题，存在两种解决方案：纵向扩展（scala-up）和横向扩展（scale-out）。
纵向扩展利用现有的存储系统，通过不断增加存储容量来满足数据日益增长的需求；但是价格昂贵、升级困难、存在物理瓶颈
横向扩展则是增加节点来扩大存储容量，一般分布式文件系统都会选择横向扩展。
横向扩展的挑战在哪里
因故障丢失数据
横向扩展集群中采用的节点通常是普通的商用服务器，可能出故障地方又非常多，内存、CPU、主板、磁盘会损坏，服务器会宕机，网络会中断，机房会停电，所有这些都可能会引起软件系统的不可用，甚至数据永久丢失。
文件通常较大
在大数据场景中，GB 级别的文件是很常见的，且这样的文件数量极多，这与传统文件系统的使用场景是很不同的，这就要求分布式文件系统在 IO 操作以及块大小方面进行重新设计。
一次写入多次读取
一部分文件是通过追加方式产生的，且一旦产生之后不会再随机修改，实际有很多场景会是这样的，包括应用程序流式产生的数据、历史归档数据等。
HDFS 的主要架构
上面是 HDFS 文件系统的架构图。
HDFS 使用主从架构，主节点是 NameNode，从节点被称为 DataNode。
NameNode 是 HDFS 集群的管理者，负责管理文件系统元数据和所有的 DataNode。
DataNode 是存储实际的数据块，并周期性通过心跳向 NameNode 汇报自己的状态信息。
Client 是客户端，用户通过客户端和 NameNode 以及 DataNode 交互，完成 HDFS 管理（比如服务的启动和停止）和数据读写的操作。
为了解决单个文件过大的问题，HDFS 对文件分块之后存储。而分块操作也是在客户端完成的。
HDFS 高可用设计思路
文件分块存储
数据被分块存储在集群任意的 DataNode 上，所以 HDFS 存储的文件可以非常大，实现了大容量的存储。
DataNode上存储的数据块会复制多个副本，保证了数据的高可靠性，并通过一系列手段保证 HDFS 系统的主要组件高可用，进而保证数据和整个系统的高可用。
数据存储故障容错
磁盘介质在存储过程中受环境或者老化影响，其存储的数据可能会出现错乱。
HDFS 的应对措施是，对于存储在 DataNode 上的数据块，计算并存储校验和（CheckSum）。
在读取数据的时候，重新计算读取出来的数据的校验和，如果校验不正确就抛出异常，应用程序捕获异常后就到其他 DataNode 上读取备份数据。
磁盘故障容错
如果 DataNode 监测到本机的某块磁盘损坏，就将该块磁盘上存储的所有 BlockID 报告给 NameNode。
NameNode 检查这些数据块还在哪些 DataNode 上有备份，通知相应的 DataNode 服务器将对应的数据块复制到其他服务器上，以保证数据块的备份数满足要求。
DataNode 故障容错
DataNode 会通过心跳和 NameNode 保持通信，如果 DataNode 超时未发送心跳，NameNode 就会认为这个 DataNode 已经宕机失效。
NameNode立即查找这个 DataNode 上存储的数据块有哪些，以及这些数据块还存储在哪些服务器上。
随后通知这些服务器再复制一份数据块到其他服务器上，保证 HDFS 存储的数据块备份数符合用户设置的数目，即使再出现服务器宕机，也不会丢失数据。
NameNode 故障容错
一个 HDFS 集群只存在一个对外服务的 NameNode，称为 Active NameNode，为了防止单个 NameNode 出现故障后导致整个集群不可用，用户可启动一个备用 NameNode，称为 Standby NameNode，为了实现 NameNode HA，需解决好两者的切换和状态同步问题。
HDFS 提供了手动方式和自动方式完成主备 NameNode 切换，手动方式是通过命令显式修改 NameNode 角色完成的，通常用于 NameNode 滚动升级；
自动模式是通过 zk 实现的，可在主 NameNode 不可用时，自动将备用 NameNode 提升为主 NameNode，以保障 HDFS 不间断对外提供服务。
主备的状态同步也很重要，主/备 NameNode 并不是通过强一致协议保证状态一致的，而是通过第三方的共享存储系统。
主 NameNode 将 EditLog （修改日志，比如创建和修改文件）写入共享存储系统，备用 NameNode 则从共享存储系统中读取这些修改日志，并重新执行这些操作，以保证与 主 NameNode 的内存信息一致。
HDFS 的实现原理今天就讲到这，下次再见！
大数据组件的应用实战，会放到高级系列中
天道酬勤，加油！
KK架构
这是大数据快速入门系列，力求以最简单的文字，说清楚大数据各个组件，帮助你更好的入门大数据。长按，关注，不迷路！
