? ? ? ?本文是Hadoop組件之HDFS的學習總結(jié)性文章。因本人非技術(shù)出身，所學均來源于網(wǎng)絡(luò)，難免有不嚴謹甚至錯誤之處，懇請大家指正。

? ? ? ?我們接著上一篇文章來講，假設(shè)A公司最起初是用Excel來存放數(shù)據(jù)的，隨著業(yè)務(wù)發(fā)展發(fā)現(xiàn)業(yè)務(wù)數(shù)據(jù)使用Excel存不下了（百萬行），則過渡于使用數(shù)據(jù)庫進行存儲，而數(shù)據(jù)庫的數(shù)據(jù)其實是存儲在硬盤上的。
? ? ? ?就拿我們?nèi)粘Ｊ褂玫碾娔X來舉例，假設(shè)其有D（512G）、E（512G）、F（512G）三個硬盤。我們在上面裝了一個數(shù)據(jù)庫系統(tǒng)（比如：Mysql，關(guān)系型數(shù)據(jù)庫的一種），然后指定它存放數(shù)據(jù)的地方為D盤。A公司的所有業(yè)務(wù)數(shù)據(jù)都會存在D盤中，隨著數(shù)據(jù)不斷增加，D盤的512G空間快不能滿足需求時，一般有2種方案來解決，一是：增加D盤的存儲空間，比如升級到1T（這種叫垂直擴展）。 二是：把業(yè)務(wù)數(shù)據(jù)分成不同部分，分別存儲至D、E、F盤中（這種叫水平擴展）。在實際的情況中最后一般都是使用第二種方案，因為電腦硬件達到一定性能后，再升級成本會非常大，帶來的邊際效益會越來越小，最后可能為負。
? ? ? ?上面的說法只是為了方便技術(shù)功底不深的朋友理解，但其實是不嚴謹?shù)?。在我的認知水平中，實際的情況是企業(yè)會使用單獨的服務(wù)器（可以理解為企業(yè)使用的專業(yè)主機）作為數(shù)據(jù)庫，且使用的是linux系統(tǒng)，不分 C、D、E、F盤。所以當這個服務(wù)器的存儲空間使用完畢后，要么升級服務(wù)器的存儲空間，要么是增加一臺新的服務(wù)器同時作為數(shù)據(jù)庫。所以可以簡單的理解這種多個獨立的服務(wù)器共同存儲數(shù)據(jù)的機制叫做分布式存儲。

? ? ? ?以上并沒有直接講到HDFS，但是其中提到的擴容思想與HDFS思想類似，在此基礎(chǔ)上更有助于我們來理解HDFS。順便說一下上文提到的關(guān)系型數(shù)據(jù)庫與HDFS的區(qū)別，關(guān)系型數(shù)據(jù)庫存儲的是關(guān)系型數(shù)據(jù)（常見的有MySQL、Oracle、DB2、PostgreSQL等），可以快速的執(zhí)行增刪改查（所以上面的例子說的是業(yè)務(wù)數(shù)據(jù)——需要經(jīng)常的增刪改查）。而HDFS是分布式文件系統(tǒng)，是一種通用型的數(shù)據(jù)存儲系統(tǒng)，可以存儲各種類型的數(shù)據(jù)，比如用戶行為數(shù)據(jù)，圖片，視頻等等。

什么是HDFS？

? ? ? ?前面講到，隨著數(shù)據(jù)量越來越大，在一臺服務(wù)器上已經(jīng)無法存儲所有的數(shù)據(jù)了，那我們會將這些數(shù)據(jù)分配到不同的服務(wù)器進行存儲，但是這就帶來一個問題：不方便管理和維護，所以就出現(xiàn)了分布式文件系統(tǒng)來統(tǒng)一管理這些分布在不同服務(wù)器的數(shù)據(jù)。
? ? ? ?而HDFS（Hadoop Distributed File System）就是Hadoop框架下的一種分布式文件系統(tǒng)，為整個Hadoop分布式體系提供底層文件存儲。通過HDFS，我們不必去管文件到底被分片存儲在多少服務(wù)器上，就像是使用一臺服務(wù)器存儲數(shù)據(jù)文件一樣便捷，大大的減少了日常的工作量。能達到這種效果是因為那些大佬把整個邏輯做了底層封裝，就像我們的產(chǎn)品在調(diào)用微信/支付寶的支付接口一樣，我們不必去實現(xiàn)背后復(fù)雜的邏輯，只需要調(diào)用即可。

HDFS是如何工作的呢？

? ? ? ?現(xiàn)在A公司使用到了Hadoop框架來處理大數(shù)據(jù)相關(guān)的需求。假設(shè)A公司每天產(chǎn)生2個G的用戶行為數(shù)據(jù)需要存儲至HDFS中，那么整個流程如下圖：

數(shù)據(jù)文件存儲至HDFS

額外補充一個Block塊大小設(shè)置規(guī)則
在實際應(yīng)用中，hdfs block塊的大小設(shè)置為多少合適呢？為什么有的是64M，有的是128M、256M、512呢？
首先我們先來了解幾個概念：
1）尋址時間：HDFS中找到目標文件block塊所花費的時間。
2）原理：文件塊越大，尋址時間越短，但磁盤傳輸時間越長；文件塊越小，尋址時間越長，但磁盤傳輸時間越短。
Block不能設(shè)置過大，也不要能設(shè)置過小
1）如果塊設(shè)置過大，一方面從磁盤傳輸數(shù)據(jù)的時間會明顯大于尋址時間，導(dǎo)致程序在處理這塊數(shù)據(jù)時，變得非常慢；另一方面，MapReduce中的map任務(wù)通常一次只處理一個塊中的數(shù)據(jù)，如果塊過大運行速度也會很慢。
2）如果設(shè)置過小，一方面存放大量小文件會占用NameNode中大量內(nèi)存來存儲元數(shù)據(jù)，而NameNode的內(nèi)存是有限的，不可??；另一方面塊過小，尋址時間增長，導(dǎo)致程序一直在找block的開始位置。因此，塊適當設(shè)置大一些，減少尋址時間，那么傳輸一個有多個塊組成的文件的時間主要取決于磁盤的傳輸速度。
多大合適呢？
1）HDFS中平均尋址時間大概為10ms；
2）經(jīng)過前任的大量測試發(fā)現(xiàn)，尋址時間為傳輸時間的1%時，為最佳狀態(tài)，所以最佳傳輸時間為：10ms/0.01=1000ms=1s
3）目前磁盤的傳輸速度普遍為100MB/s，最佳block大小計算：100MB/s*1s=100MB。所以我們設(shè)置block大小為128MB。
4）實際中，磁盤傳輸速率為200MB/s時，一般設(shè)定block大小為256MB;磁盤傳輸速率為400MB/s時，一般設(shè)定block大小為512MB。

? ? ? ?到這里我們其實已經(jīng)大致了解了HDFS的工作原理，但是呢他作為文件存儲系統(tǒng)，并且能被各公司使用，在數(shù)據(jù)安全這方面肯定是需要得到保障的。我們來想一下，一個數(shù)據(jù)文件被分成了很多片存儲在多臺服務(wù)器上，如果其中的一臺服務(wù)器突然壞了，數(shù)據(jù)不就丟失了嘛，所以HDFS和數(shù)據(jù)庫一樣都需要有容災(zāi)手段（凡是涉及到數(shù)據(jù)的東西，大家都可以簡單粗暴的認為他們都會有備份的機制，比如消息中間件Kafka會有數(shù)據(jù)備份的機制、數(shù)據(jù)庫會有主從備份等）。因此為了容錯，Block都會有副本(可以簡單理解一模一樣的文件)，每個文件的Block大副本數(shù)與其大小一樣都是可配置的。
下面使用一個圖片來示意下HDFS的備份機制：（假設(shè)設(shè)置副本數(shù)為3）

HDFS備份機制

假設(shè)第一個備份先傳到DataNode A，那么第二個備份是從DataNode A上以流的形式傳輸?shù)紻ataNode B，第三個備份是從DataNode B以流的形式傳輸?shù)紻ataNode C上面的。即這里的備份并不需要HDFS客戶端去寫，只要DataNode之間互相傳遞數(shù)據(jù)就好了。

? ? ? ?好了！關(guān)于HDFS的就大致講這么多，很多細節(jié)性的東西，比如HDFS客戶端讀寫數(shù)據(jù)的具體流程和步驟我覺得作為產(chǎn)品無需過多了解，當然，如果有興趣的朋友歡迎來一起探討學習。下一篇文章我打算寫點關(guān)于MapReduce的內(nèi)容。

傳送門
Hadoop系列文章（一）數(shù)據(jù)產(chǎn)品經(jīng)理有必要了解的Hadoop
Hadoop系列文章（三）數(shù)據(jù)產(chǎn)品經(jīng)理有必要了解的MapReduce
Hadoop系列文章（四）數(shù)據(jù)產(chǎn)品經(jīng)理有必要了解的YARN