我們都知道現在大資料儲存用的基本都是 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 叢集相互連通？歡迎在評論中寫下你的思考。