我們都知道現在大數據存儲用的基本都是 Hdfs ，但在 Hadoop 誕生之前，我們都是如何存儲大量數據的呢？這次我們不聊技術架構什麼的，而是從技術演化的角度來看看 Hadoop Hdfs。
我們先來思考兩個問題。
- 在 Hdfs 出現以前，計算機是通過什麼手段來存儲“大數據” 的呢？
- 爲什麼會有 Hadoop Hdfs 出現呢？
在 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 年的時候將它的實現論文發表了出來。
但要將多臺服務器聯合在一起進行分佈式存儲，顯然不是那麼容易。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：關注後回覆“數據挖掘一”可獲得數據挖掘思維導圖
