分布式文件係統HDFS設計
《Hadoop 權威指南》上用這麼一句話來描述HDFS:
HDFS is a filesystem designed for storing very large files with streaming data access patterns, running on clusters of commodity hardware.
有幾個關鍵性的詞組:Very large files,Streaming data access,以及Commodity hardware。解下來一個一個解釋。
① Very large files
在Hadoop中,“very large”是多大?運行在HDFS上的應用具有很大的數據集。HDFS上的一個典型文件大小一般都在G字節至T字節。現如今,已經有不少的企業,存儲在HDFS上的數據,已經超過了PB的級別,例如淘寶。
② Streaming data access
HDFS的設計的理想用法是一次寫入,多次讀取。這種方式的使用是最高效的。運行在HDFS上的應用和普通的應用不同,需要流式訪問它們的數據集。HDFS的設計中更多的考慮到了數據批處理,而不是用戶交互處理。比之數據訪問的低延遲問題,更關鍵的在於數據訪問的高吞吐量,所以,從這方麵來說,讀取整個數據的時間延遲要比讀取到第一條記錄的數據延遲更重要(這一點很重要,這一思想,將在《HDFS學習(二) – HDFS Block介紹》中說明)。
③ Commodity hardware
Hadoop適合部署在廉價的機器上,即普通的機器上,不需要時昂貴且高可靠的機器。這樣的話,機器節點的故障幾率就會非常高。所以,Hadoop是一個高度容錯的係統,錯誤檢測和快速、自動的恢複是HDFS最核心的架構目標。Hadoop出現故障時,被設計成能夠繼續進行且不讓用戶察覺。
綜上,HDFS是一個不錯的分布式文件係統,但是,HDFS也有其不適合的場合,也有其缺點:
① 低延時數據訪問
HDFS不太適合於要求低延時(數十毫秒)訪問的應用程序,因為HDFS是設計用於高吞吐量數據訪問的,這就需要以一定的延時為代價。而對於那些有低延時要求的應用程序,HBase是一個更好的選擇。HBase的口號就是“Use Apache HBase when you need random, realtime read/write access to your Big Data”。
② 大量的小文件
因為Namenode把文件係統的元數據放置在內存中,所以文件係統所能容納的文件數目是由Namenode的內存大小來決定。一般來說,每一個文件、文件夾和Block需要占據150字節左右的空間,所以,如果你有1000萬個文件,每一個占據一個Block,你就至少需要2G內存。當前來說,數百萬的文件還是可行的,當擴展到數十億時,我們就需要幾十G的內存。這樣算來,Namenode內存,就嚴重製約了集群的擴展。
還有一個問題就是,因為Map task的數量是由splits來決定的,所以用MR處理大量的小文件時,就會產生過多的Map task,線程管理開銷將會增加作業時間。處理大量小文件的速度遠遠小於處理同等大小的大文件的速度。舉個例子,處理10000M的文件,若每個split為1M,那就會有10000個Map tasks,會有很大的線程開銷;若每個split為100M,則隻有100個Map tasks,每個Map task將會有更多的事情做,而線程的管理開銷也將減小很多。
對於第一問題,最新版本的Hadoop已經有了解決方案:HDFS Federation,將在《HDFS學習(四) – HDFS Federation》做詳細介紹。
對於第二個問題,Hadoop本身也提供了一定的解決方案,將在《Hadoop學習(五) – 小文件處理》做詳細介紹。
③ 多用戶寫,任意文件修改
目前Hadoop隻支持單用戶寫,不支持並發多用戶寫。可以使用Append操作在文件的末尾添加數據,但不支持在文件的任意位置進行修改。《Hadoop 權威指南》第三版上說,現在尚無對這方麵的支持。
Files in HDFS may be written to by a single writer. Writes are always made at the end of the file. There is no support for multiple writers or for modifications at arbitrary offsets in the file. (These might be supported in the future, but they are likely to be relatively inefficient.)
最後更新:2017-04-03 22:30:57