我們都知道現在大數據存儲用的基本都是 Hadoop Hdfs ，但在 Hadoop 誕生之前，我們都是如何存儲大量數據的呢？這次我們不聊技術架構什么的，而是從技術演化的角度來看看 Hadoop Hdfs。
我們先來思考兩個問題。
- 在 Hdfs 出現以前，計算機是通過什么手段來存儲“大數據” 的呢？
- 為什么會有 Hadoop Hdfs 出現呢？
在 Hadoop Hdfs 出現以前，計算機是通過什么手段來存儲“大數據”
要知道，存儲大量數據有三個最重要的指標，那就是速度，容量，容錯性。速度和容量的重要性毋庸置疑，如果容量不夠大，或者讀取的速度不夠快，那么海量數據存儲也就無從談起了。而磁盤又是計算機中很容易損壞的零件，當磁盤損壞的時候怎么辦？放任數據的丟失嗎，那可不行，這就有了容錯性的需求。
在沒有分布式存儲的時代，單個磁盤容量不夠怎么辦？加磁盤唄。磁盤容易壞怎么辦，同時用其他磁盤備份唄。就這樣，獨立磁盤冗余陣列（ Redundant Array of Independent Disks ），簡稱 RAID，誕生了。
在 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 出現
最直接是原因是 Google 三篇大數據論文的發表，這直接導致了 Hadoop 的問世。
但更深層的原因其實還是因為傳統的但節點磁盤容量達到了極限，即便是用上述的 RAID 技術，但單個台服務器的容量始終有一個邊界值。而且隨着互聯網的普及，在 2000 年后，數據的積累呈指數式增長，這時候單台服務器顯然已經放不下這海量的數據了。但是就像 RAID 的改革思想一樣，既然單台服務器不夠，那我們就加服務器唄。
最早是 Google ，他們在自己的系統上實現了 Google File System（GFS） 這么一個分布式存儲系統，並在 03 年的時候將它的實現論文發表了出來。而后 Doug Cutting 和 Mike Cafarella 在這三篇論文的基礎上開發出了 Hadoop。
但要將多台服務器聯合在一起進行分布式存儲，顯然不是那么容易。Hadoop1.0 的時候，Hdfs 還是有一些隱患的。舉個例子，用分布式進行數據存儲，那就需要一個來記錄元數據的服務器，也就是記錄數據存儲位置的服務器。Hadoop1.0 時候的 Hdfs 是用一個 namenode 管理元數據的，但顯然，只有一個 namenode 來存儲元數據有極大的風險，那就是 namenode 的可靠性無法保證，一旦這個 namenode 掛掉，整個集群就完蛋了。
好在這些問題及時得到修復，Hadoop2.0 橫空出世，解決了大部分的問，比如上面說到的 NameNode 單點故障問題，解決方式就是多引入一台 NameNode 做同步備份，一個 NameNode 出問題時另一個跳出來扛。升級過后，Hadoop Hdfs 這才算是坐穩了大數據存儲王者的寶座。
在這里我們就先不說 Hadoop Hdfs 的架構如何，依舊是從上面說到的大數據存儲的三個指標速度，容量，容錯性這幾個方面來看 Hadoop Hdfs。
- 速度： 速度方面的優勢源於 Hdfs 合理的設計理念。它默認用到 Hdfs 處理的是大的數據(TB,PB 級的數據)，並且摒棄了傳統文件系統中的 Update 操作，只有 Append 操作。在這個基礎上，Hdfs 將一個文件分割成若干個塊（Block），每個塊分布在不同的機器中。。和 RAID 利用多個磁盤並發 IO 提高速度一樣，每次操作一個文件的時候，實際上是多個機器在並發讀取，這樣無疑是進一步提高讀取速度。
- 容量： 容量這個問題自不必說，理論上是可以無限制得擴容。但實際上由於它的元數據存儲在一台 namenode 中，所以它的大小還是會收到元數據存儲的這個限制。不過在 Hadoop2.0 后，在機器條件允許的情況下，一個 Hdfs 支撐起 PB 級別的存儲還是綽綽有余的。
- 容錯性： 在容錯性這個方面，從以前到現在基本都是通過數據冗余來實現的。只不過數據冗余的一些策略會根據不同的應用場景而做出一些改變。由於 Hadoop 本身就是假設部署在多台廉價機器上，所以它會傾向於將存儲數據的節點當作不可靠的節點。出於這個因素，Hdfs 的默認冗余備份數是 3份 ，就是說當你向 Hdfs 寫入一份數據的時候，同時會在其他三台機器上也寫入相同的內容。
我們可以發現，其實 Hadoop Hdfs 和 RAID 在思想上是有一些相似之處的。都是通過水平拓展，比如 RAID 水平拓展磁盤，Hadoop Hdfs 則是水平拓展機器。
鐵打的營盤流水的兵。數據就是那些兵，大數據計算框架，比如 Spark，Hive 是將軍。而營盤就是 Hadoop Hdfs 了。兵進進出出，將軍換了一個又一個，唯獨營盤不會變，Hadoop Hdfs 無疑是大數據體系中最基礎也是最重要的那一環。
這里給出一個有意思的問題： 當下一次互聯網革命到來，數據又呈指數增長的時候，數據存儲的模式會怎樣演化呢？會是簡單的增加集群嗎，比方說讓多個 hdfs 集群相互連通？歡迎在評論中寫下你的思考。