大数据存储的进化史 --从 RAID 到 Hdfs
我们都知道现在大数据存储用的基本都是 Hdfs ，但在 Hadoop 诞生之前，我们都是如何存储大量数据的呢？这次我们不聊技术架构什么的，而是从技术演化的角度来看看 Hadoop Hdfs。
我们先来思考两个问题。
- 在 Hdfs 出现以前，计算机是通过什么手段来存储“大数据” 的呢？
- 为什么会有 Hadoop Hdfs 出现呢？
在 Hdfs 出现以前，计算机是通过什么手段来存储“大数据”
要知道，存储大量数据有三个最重要的指标，那就是速度，容量，容错性。速度和容量的重要性毋庸置疑，如果容量不够大，或者读取的速度不够快，那么海量数据存储也就无从谈起了。而磁盘又是计算机中很容易损坏的零件，当磁盘损坏的时候怎么办？放任数据的丢失吗，那可不行，这就有了容错性的需求。
在没有分布式存储的时代，单个磁盘容量不够怎么办？加磁盘呗。磁盘容易坏怎么办，同时用其他磁盘备份呗。就这样，独立磁盘冗余阵列（ Redundant Array of Independent Disks ），简称 RAID，诞生了。
image
在 2000 年以前，磁盘还是很珍贵的资源，不像现在，磁盘是 PC 机中最廉价的部件。一开始 RAID 技术是为了将多个廉价的容量较小的磁盘组合起来充当一个大磁盘以节约成本，但后来人们发现这项技术也可以用在单台机器磁盘扩容上了，于是 RAID 技术开始被广泛使用。
RAID 技术将多个磁盘组合成一个逻辑扇区，对计算机而言，它会将 RAID 当作一个磁盘来处理。使用 RAID 的好处有：增强数据集成度，增强容错功能，增加处理量或容量。
另外 RAID 也有分为多个档次，标准的分法，分别是 RAID0 ， RAID1 ， RAID2 ，RAID3 ，RAID4 ，RAID5 ， RAID6 ，每个档次都有对应的优缺点。这里就不详细介绍，这些 RAID 等级的不同主要是对 上述说到的三个数据存储要素（速度，容量，容错性）的不同取舍，各有各的应用场景。我们从上述的三个指标来看 RAID 技术。
- 速度： RAID通过在多个磁盘上同时存储和读取数据来大幅提高存储系统的数据吞吐量。在RAID中，可以让很多磁盘驱动器同时传输数据，而这些磁盘驱动器在逻辑上又是一个磁盘驱动器，所以使用RAID可以达到单个磁盘驱动器几倍、几十倍甚至上百倍的速率。
- 容量： 可以将多个磁盘连接起来，对比以前的单个磁盘存储，RAID 将存储的量级拔高了一个台阶。但依旧有其局限性，因为 RAID 始终是放在单台机器上，机器的磁盘卡槽不可能无限增加，磁盘也不可能一直增大。
- 容错性： 不同等级的 RAID 使用不同的数据冗余策略，保证数据的容错性。比如最简单的 RAID1 就是数据在写入磁盘时，将一份数据同时写入两块磁盘，这样任何一块磁盘损坏都不会导致数据丢失，而插入一块新磁盘就可以通过复制数据的方式自动修复，具有极高的可靠性。
为什么会有 Hadoop Hdfs 出现
image
最直接是原因是 Google 三篇大数据论文的发表，这直接导致了 Hadoop 的问世。
但更深层的原因其实还是因为传统的但节点磁盘容量达到了极限，即便是用上述的 RAID 技术，但单个台服务器的容量始终有一个边界值。而且随着互联网的普及，在 2000 年后，数据的积累呈指数式增长，这时候单台服务器显然已经放不下这海量的数据了。但是就像 RAID 的改革思想一样，既然单台服务器不够，那我们就加服务器呗。
最早是 Google ，他们在自己的系统上实现了 Google File System（GFS） 这么一个分布式存储系统，并在 03 年的时候将它的实现论文发表了出来。
但要将多台服务器联合在一起进行分布式存储，显然不是那么容易。Hadoop1.0 的时候，Hdfs 还是有一些隐患的。举个例子，用分布式进行数据存储，那就需要一个来记录元数据的服务器，也就是记录数据存储位置的服务器。Hadoop1.0 时候的 Hdfs 是用一个 namenode 管理元数据的，但显然，只有一个 namenode 来存储元数据有极大的风险，那就是 namenode 的可靠性无法保证，一旦这个 namenode 挂掉，整个集群就完蛋了。
好在这些问题及时得到修复，Hadoop2.0 横空出世，架构升级，解决了大部分的问题，Hdfs 这才算是坐稳了大数据存储王者的宝座。
在这里我们就先不说 Hdfs 的架构如何，依旧是从上面说到的大数据存储的三个指标速度，容量，容错性这几个方面来看 Hdfs。
- 速度： 速度方面的优势源于 Hdfs 合理的设计理念。它默认用到 Hdfs 处理的是大的数据(TB,PB 级的数据)，并且摒弃了传统文件系统中的 Update 操作，只有 Append 操作。在这个基础上，Hdfs 将一个文件分割成若干个块（Block），每个块分布在不同的机器中。。和 RAID 利用多个磁盘并发 IO 提高速度一样，每次操作一个文件的时候，实际上是多个机器在并发读取，这样无疑是进一步提高读取速度。
- 容量： 容量这个问题自不必说，理论上是可以无限制得扩容。但实际上由于它的元数据存储在一台 namenode 中，所以它的大小还是会收到元数据存储的这个限制。不过在 Hadoop2.0 后，在机器条件允许的情况下，一个 Hdfs 支撑起 PB 级别的存储还是绰绰有余的。
- 容错性： 在容错性这个方面，从以前到现在基本都是通过数据冗余来实现的。只不过数据冗余的一些策略会根据不同的应用场景而做出一些改变。由于 Hadoop 本身就是假设部署在多台廉价机器上，所以它会倾向于将存储数据的节点当作不可靠的节点。出于这个因素，Hdfs 的默认冗余备份数是 3份 ，就是说当你向 Hdfs 写入一份数据的时候，同时会在其他三台机器上也写入相同的内容。
我们可以发现，其实 Hdfs 和 RAID 在思想上是有一些相似之处的。都是通过水平拓展，比如 RAID 水平拓展磁盘，Hdfs 则是水平拓展机器。
铁打的营盘流水的兵。数据就是那些兵，大数据计算框架，比如 Spark，Hive 是将军。而营盘就是 Hdfs 了。兵进进出出，将军换了一个又一个，唯独营盘不会变， Hdfs 无疑是大数据体系中最基础也是最重要的那一环。
这里给出一个有意思的问题： 当下一次互联网革命到来，数据又呈指数增长的时候，数据存储的模式会怎样演化呢？会是简单的增加集群吗，比方说让多个 hdfs 集群相互连通？欢迎在评论中写下你的思考。
欢迎关注公众号，有数据，代码和深度的思考。
PS：关注后回复“数据挖掘一”可获得数据挖掘思维导图
哈尔的数据城堡
