大数据存储核心痛点

数据存储容量的问题。

大数据要解决的是数以PB计的数据计算问题，而在03年一般的服务器磁盘容量通常1～2TB，要如何存储这么大规模的数据，并能把它们使用起来，是很困难的。

数据读写速度的问题。

哪怕解决了前一个存储问题，但在03年一般磁盘的连续读写速度为几十MB，以这样的速度，几十PB的数据恐怕要读写到天荒地老。

数据可靠性的问题。

就算前面两个问题都解决了，但我们都知道，在计算机设备中磁盘应该就是最易损坏的硬件了，在03年，通常情况下，服务器里一块磁盘使用寿命大概是一年，如果磁盘损坏了，数据怎么办？

HDFS设计

本文的主角HDFS，它的核心设计目标，就是要解决前面提到的海量数据的存储、读写和可靠性的痛点。

那它到底是如何做到的呢？

下面我会从设计参考（落地思路、论文），HDFS实现论文，以及企业HDFS解决方案解析三个模块来了解。

设计参考

参考技术方案：RAID（独立磁盘冗余阵列）

RAID将数据分片后在多块磁盘上并发进行读写访问，从而提高了存储容量、加快了访问速度，并通过数据的冗余校验提高了数据的可靠性，即使某块磁盘损坏也不会丢失数据。

而分布式文件系统的核心原理，其实就可以看成将RAID的设计思路扩大到整个分布式服务器集群。对于RAID，可以翻看专栏后续的文章。

参考论文：Google File System（简称GFS）

Google在2003年发布的这篇论文被称为大数据的三驾马车之一！

Google File System（简称GFS）是Google公司开发的分布式文件系统，它是HDFS的前身。

对于该论文的深入解读可以翻看专栏后续的文章。

HDFS实现论文

Hadoop Distributed File System（简称HDFS）是Apache Hadoop项目的核心组成部分，是Google File System（简称GFS）的开源实现。

Hadoop分布式文件系统（HDFS）旨在可靠地存储大型数据集，并将这些数据集以高带宽流式传输到用户应用程序。在一个大型集群中，成千上万的服务器既直接托管存储，又执行用户应用程序任务。通过在多台服务器上分布存储和计算，资源可以随需求而增长，同时保持经济性。（The Hadoop Distributed File System (HDFS) is designed to store very largedata sets reliably, and to stream those data sets at high bandwidth to user applications.In a large cluster, thousands of servers both host directly attached storage and executeuser application tasks. By distributing storage and computation across many servers,the resource can grow with demand while remaining economical at every size.）

因为后续会详细讲解HDFS内容，这里就不过多深入HDFS实现论文，感兴趣可以阅读对应论文原文。

企业HDFS解决方案设计解析

下面会提到HDFS的组件名，先简单解释一下：

• Namenode：存储数据元数据信息的组件
• DataNode：存储真实数据的组件

专栏后面文章会详细讲解HDFS的核心设计，会包括组件的详细解析，本文就不过多赘述。

存储与读写设计

和前面提到的，与RAID在多个磁盘上进行文件存储及并行读写的思路一样，HDFS是在一个大规模分布式服务器集群上，对数据分片后进行并行读写及冗余存储。

1.数据分片与并行读写

HDFS主要通过将文件拆分存储的方式来支持大文件存储。

数据分片以后也能提高数据的并行处理效率。

2.流式数据写入

HDFS参考了GFS的思路，考虑了集群硬件中最大的瓶颈是网络，所以通过分离控制流和数据流，并用流水式的网络数据传输方式写入数据，可以最大程度利用不同机器的网络带宽，提高数据存储效率。

高可用设计

数据存储层面：通过心跳检测定位问题节点，并快速应对机器故障带来的问题

元数据管理层面：通过Zookeeper，JournalNode等外部集群去保障集群的高可用

1.数据存储故障容错

磁盘介质在存储过程中受环境或者老化影响，其存储的数据可能会出现错乱。

HDFS的应对措施是，对于存储在DataNode上的数据块，计算并存储校验和（CheckSum）。

在读取数据的时候，重新计算读取出来的数据的校验和，如果校验不正确就抛出异常，应用程序捕获异常后就到其他DataNode上读取备份数据。

2.磁盘故障容错

如果DataNode监测到本机的某块磁盘损坏，就将该块磁盘上存储的所有BlockID报告给NameNode，NameNode检查这些数据块还在哪些DataNode上有备份，通知相应的DataNode服务器将对应的数据块复制到其他服务器上，以保证数据块的备份数满足要求。

3.DataNode故障容错

DataNode的状态管理

在原始设计中DataNode会通过心跳和NameNode保持通信，如果DataNode超时未发送心跳，NameNode就会认为这个DataNode已经宕机失效。

但是心跳会有一定的延迟，可能会导致NameNode认为DataNode已经失效，但是DataNode还没有宕机，只是网络通信出现问题；也可能会导致NameNode认为DataNode还没有失效，但是DataNode已经宕机。

所以通常企业生产会引入Zookeeper来协助管理DataNode的状态。

确认失效后处理

如果确认DataNode已经宕机失效，NameNode立即查找这个DataNode上存储的数据块有哪些，以及这些数据块还存储在哪些服务器上，随后通知这些服务器再复制一份数据块到其他服务器上，保证HDFS存储的数据块备份数符合用户设置的数目，即使再出现服务器宕机，也不会丢失数据。

4.NameNode故障容错

NameNode是整个HDFS的核心，记录着HDFS文件分配表信息，所有的文件路径和数据块存储信息都保存在NameNode，如果NameNode故障，整个HDFS系统集群都无法使用；如果NameNode上记录的数据丢失，整个集群所有DataNode存储的数据也就没用了。

所以，NameNode高可用容错能力非常重要。

NameNode通过采用主从热备的方式提供高可用服务，集群部署两台NameNode服务器，一台作为主服务器提供服务，一台作为从服务器进行热备，两台服务器通过ZooKeeper管理，由ZooKeeper决定谁是主服务器。而DataNode则会向两个NameNode同时发送心跳数据，但是只有主NameNode才能向DataNode返回控制信息。

正常运行期间，主从NameNode之间通过一个共享存储系统shared edits来同步文件系统的元数据信息。当主NameNode服务器宕机，从NameNode会通过ZooKeeper升级成为主服务器，并保证HDFS集群的元数据信息，也就是文件分配表信息完整一致。

注意：关于shared edits，通常采用JournalNode，通过它来存储 NameNode 的编辑日志（edit logs）。当 Active NameNode 进行元数据修改时，会将这些修改记录到多个 JournalNode 中。Standby NameNode 也会从 JournalNode 中读取这些修改，以保持与 Active NameNode 的元数据一致。