hdfs存儲模型

❶ Hadoop系列之HDFS架構

    本篇文章翻譯了Hadoop系列下的 HDFS Architecture ，原文最初經過筆者翻譯後大概有6000字，之後筆者對內容進行了精簡化壓縮，從而使筆者自己和其他讀者們閱讀本文時能夠更加高效快速的完成對Hadoop的學習或復習。本文主要介紹了Hadoop的整體架構，包括但不限於節點概念、命名空間、數據容錯機制、數據管理方式、簡單的腳本命令和垃圾回收概念。

    PS：筆者新手一枚，如果看出哪裡存在問題，歡迎下方留言！

    Hadoop Distributed File System（HDFS）是高容錯、高吞吐量、用於處理海量數據的分布式文件系統。

    HDFS一般由成百上千的機器組成，每個機器存儲整個數據集的一部分數據，機器故障的快速發現與恢復是HDFS的核心目標。

    HDFS對介面的核心目標是高吞吐量而非低延遲。

    HDFS支持海量數據集合，一個集群一般能夠支持千萬以上數量級的文件。

    HDFS應用需要對文件寫一次讀多次的介面模型，文件變更只支持尾部添加和截斷。

    HDFS的海量數據與一致性介面特點，使得遷移計算以適應文件內容要比遷移數據從而支持計算更加高效。

    HDFS支持跨平台使用。

    HDFS使用主從架構。一個HDFS集群由一個NameNode、一個主伺服器（用於管理系統命名空間和控制客戶端文件介面）、大量的DataNode（一般一個節點一個，用於管理該節點數據存儲）。HDFS對外暴露了文件系統命名空間並允許在文件中存儲用戶數據。一個文件被分成一個或多個塊，這些塊存儲在一組DataNode中。NameNode執行文件系統命名空間的打開關閉重命名等命令並記錄著塊和DataNode之間的映射。DataNode用於處理客戶端的讀寫請求和塊的相關操作。NameNode和DataNode一般運行在GNU/Linux操作系統上，HDFS使用Java語言開發的，因此NameNode和DataNode可以運行在任何支持Java的機器上，再加上Java語言的高度可移植性，使得HDFS可以發布在各種各樣的機器上。一個HDFS集群中運行一個NameNode，其他機器每個運行一個（也可以多個，非常少見）DataNode。NameNode簡化了系統的架構，只用於存儲所有HDFS元數據，用戶數據不會進入該節點。下圖為HDFS架構圖：

    HDFS支持傳統的分層文件管理，用戶或者應用能夠在目錄下創建目錄或者文件。文件系統命名空間和其他文件系統是相似的，支持創建、刪除、移動和重命名文件。HDFS支持用戶數量限制和訪問許可權控制，不支持軟硬鏈接，用戶可以自己實現軟硬鏈接。NameNode控制該命名空間，命名空間任何變動幾乎都要記錄到NameNode中。應用可以在HDFS中對文件聲明復制次數，這個次數叫做復制系數，會被記錄到NameNode中。

    HDFS將每個文件存儲為一個或多個塊，並為文件設置了塊的大小和復制系數從而支持文件容錯。一個文件所有的塊（除了最後一個塊）大小相同，後來支持了可變長度的塊。復制系數在創建文件時賦值，後續可以更改。文件在任何時候只能有一個writer。NameNode負責塊復制，它周期性收到每個數據節點的心跳和塊報告，心跳錶示數據節點的正常運作，塊報告包含了這個DataNode的所有塊。

    副本存儲方案對於HDFS的穩定性和性能至關重要。為了提升數據可靠性、靈活性和充分利用網路帶寬，HDFS引入了機架感知的副本存儲策略，該策略只是副本存儲策略的第一步，為後續優化打下基礎。大型HDFS集群一般運行於橫跨許多支架的計算機集群中，一般情況下同一支架中兩個節點數據傳輸快於不同支架。一種簡單的方法是將副本存放在單獨的機架上，從而防止丟失數據並提高帶寬，但是增加了數據寫入的負擔。一般情況下，復制系數是3，HDFS存儲策略是將第一份副本存儲到本地機器或者同一機架下一個隨機DataNode，另外兩份副本存儲到同一個遠程機架的不同DataNode。NameNode不允許同一DataNode存儲相同副本多次。在機架感知的策略基礎上，後續支持了 存儲類型和機架感知相結合的策略 ，簡單來說就是在機架感知基礎上判斷DataNode是否支持該類型的文件，不支持則尋找下一個。

    HDFS讀取數據使用就近原則，首先尋找相同機架上是否存在副本，其次本地數據中心，最後遠程數據中心。

    啟動時，NameNode進入安全模式，該模式下不會發生數據塊復制，NameNode接收來自DataNode的心跳和塊報告，每個塊都有一個最小副本數量n，數據塊在NameNode接受到該塊n次後，認為這個數據塊完成安全復制。當完成安全復制的數據塊比例達到一個可配的百分比值並再過30s後，NameNode退出安全模式，最後判斷是否仍然存在未達到最小復制次數的數據塊，並對這些塊進行復制操作。

    NameNode使用名為EditLog的事務日誌持續記錄文件系統元數據的每一次改動（如創建文件、改變復制系數），使用名為FsImage的文件存儲全部的文件系統命名空間（包括塊到文件的映射關系和文件系統的相關屬性），EditLog和FsImage都存儲在NameNode本地文件系統中。NameNode在內存中保存著元數據和塊映射的快照，當NameNode啟動後或者某個配置項達到閾值時，會從磁碟中讀取EditLog和FsImage，通過EditLog新的記錄更新內存中的FsImage，再講新版本的FsImage刷新到磁碟中，然後截斷EditLog中已經處理的記錄，這個過程就是一個檢查點。檢查點的目的是確保文件系統通過在內存中使用元數據的快照從而持續的觀察元數據的變更並將快照信息存儲到磁碟FsImage中。檢查點通過下面兩個配置參數出發，時間周期（dfs.namenode.checkpoint.period）和文件系統事務數量（dfs.namenode.checkpoint.txns），二者同時配置時，滿足任意一個條件就會觸發檢查點。

    所有的HDFS網路協議都是基於TCP/IP的，客戶端建立一個到NameNode機器的可配置的TCP埠，用於二者之間的交互。DataNode使用DataNode協議和NameNode交互，RPC包裝了客戶端協議和DataNode協議，通過設計，NameNode不會發起RPC，只負責響應來自客戶端或者DataNode的RPC請求。

    HDFS的核心目標是即使在失敗或者錯誤情況下依然能夠保證數據可靠性，三種常見失敗情況包括NameNode故障、DataNode故障和network partitions。

    網路分區可能會導致部分DataNode市區和NameNode的連接，NameNode通過心跳包判斷並將失去連接的DataNode標記為掛掉狀態，於是所有注冊到掛掉DataNode的數據都不可用了，可能會導致部分數據塊的復制數量低於了原本配置的復制系數。NameNode不斷地追蹤哪些需要復制的塊並在必要時候進行復制，觸發條件包含多種情況：DataNode不可用、復制亂碼、硬體磁碟故障或者認為增大負值系數。為了避免DataNode的狀態不穩定導致的復制風暴，標記DataNode掛掉的超時時間設置比較長（默認10min），用戶可以設置更短的時間間隔來標記DataNode為陳舊狀態從而避免在對讀寫性能要求高的請求上使用這些陳舊節點。

    HDFS架構兼容數據各種重新平衡方案，一種方案可以在某個DataNode的空閑空間小於某個閾值時將數據移動到另一個DataNode上；在某個特殊文件突然有高的讀取需求時，一種方式是積極創建額外副本並且平衡集群中的其他數據。這些類型的平衡方案暫時還未實現（不太清楚現有方案是什麼...）。

    存儲設備、網路或者軟體的問題都可能導致從DataNode獲取的數據發生亂碼，HDFS客戶端實現了對文件內容的校驗，客戶端在創建文件時，會計算文件中每個塊的校驗值並存儲到命名空間，當客戶端取回數據後會使用校驗值對每個塊進行校驗，如果存在問題，客戶端就會去另一個DataNode獲取這個塊的副本。

    FsImage和EditLog是HDFS的核心數據結構，他們的錯誤會導致整個HDFS掛掉，因此，NameNode應該支持時刻維持FsImage和EditLog的多分復制文件，它們的任何改變所有文件應該同步更新。另一個選擇是使用 shared storage on NFS 或者 distributed edit log 支持多個NameNode，官方推薦 distributed edit log 。

    快照能夠存儲某一特殊時刻的數據副本，從而支持HDFS在發生錯誤時會滾到上一個穩定版本。

    HDFS的應用場景是大的數據集下，且數據只需要寫一次但是要讀取一到多次並且支持流速讀取數據。一般情況下一個塊大小為128MB，因此一個文件被切割成128MB的大塊，且每個快可能分布在不同的DataNode。

    當客戶端在復制系數是3的條件下寫數據時，NameNode通過目標選擇演算法收到副本要寫入的DataNode的集合，第1個DataNode開始一部分一部分的獲取數據，把每個部分存儲到本地並轉發給第2個DataNode，第2個DataNode同樣的把每個部分存儲到本地並轉發給第3個DataNode，第3個DataNode將數據存儲到本地，這就是管道復制。

    HDFS提供了多種訪問方式，比如 FileSystem Java API 、 C language wrapper for this Java API 和 REST API ，而且還支持瀏覽器直接瀏覽。通過使用 NFS gateway ，客戶端可以在本地文件系統上安裝HDFS。

    HDFS使用目錄和文件的方式管理數據，並提供了叫做 FS shell 的命令行介面，下面有一些簡單的命令：

    DFSAdmin命令集合用於管理HDFS集群，這些命令只有集群管理員可以使用，下面有一些簡單的命令：

正常的HDFS安裝都會配置一個web服務，通過可配的TCP埠對外暴露命名空間，從而使得用戶可以通過web瀏覽器查看文件內容。

如果垃圾回收配置打開，通過FS shell移除的文件不會立刻刪除，而是會移動到一個垃圾文件專用的目錄（/user/<username>/.Trash），類似回收站，只要文件還存在於那個目錄下，則隨時可以被回復。絕大多數最近刪除的文件都被移動到了垃圾目錄（/user/<username>/.Trash/Current），並且HDFS每個一段時間在這個目錄下創建一個檢查點用於刪除已經過期的舊的檢查點，詳情見 expunge command of FS shell 。在垃圾目錄中的文件過期後，NameNode會刪除這個文件，文件刪除會引起這個文件的所有塊的空間空閑，需要注意的是在文件被刪除之後和HDFS的可用空間變多之間會有一些時間延遲（個人認為是垃圾回收機制佔用的時間）。下面是一些簡單的理解刪除文件的例子：

    當文件復制系數減小時，NameNode會選擇多餘的需要刪除的副本，在收到心跳包時將刪除信息發送給DataNode。和上面一樣，這個刪除操作也是需要一些時間後，才能在集群上展現空閑空間的增加。

HDFS Architecture

❷ Hadoop分布式存儲

為了降低整體的帶寬消耗和讀取延時，HDFS會盡量讓讀取程序讀取離它最近的副本。如果在讀取程序的同一個機架上有一個副本，那麼就讀取該副本。如果一個HDFS集群跨越多個數據中心，那麼客戶端也將首先讀本地數據中心的副本

Namenode啟動後會進入一個稱為安全模式的特殊狀態。處於安全模式的Namenode是不會進行數據塊的復制的。Namenode從所有的 Datanode接收心跳信號和塊狀態報告。塊狀態報告包括了某個Datanode所有的數據塊列表。每個數據塊都有一個指定的最小副本數。當Namenode檢測確認某個數據塊的副本數目達到這個最小值，那麼該數據塊就會被認為是副本安全(safely replicated)的；在一定百分比（這個參數可配置）的數據塊被Namenode檢測確認是安全之後（加上一個額外的30秒等待時間），Namenode將退出安全模式狀態。接下來它會確定還有哪些數據塊的副本沒有達到指定數目，並將這些數據塊復制到其他Datanode上

所有的HDFS通訊協議都是建立在TCP/IP協議之上。客戶端通過一個可配置的TCP埠連接到Namenode，通過ClientProtocol協議與Namenode交互。而Datanode使用DatanodeProtocol協議與Namenode交互。一個遠程過程調用(RPC)模型被抽象出來封裝ClientProtocol和Datanodeprotocol協議。在設計上，Namenode不會主動發起RPC，而是響應來自客戶端或 Datanode 的RPC請求

❸ hadoop文件格式和壓縮

Hadoop中的文件格式大致上分為面向行和面向列兩類：

面向行：TextFile、SequenceFile、MapFile、Avro Datafile

二進制格式文件大小比文本文件大。

生產環境常用，作為原始表的存儲格式，會佔用更多磁碟資源，對它的 解析開銷一般會比二進制格式高 幾十倍以上。

Hadoop API 提供的一種二進制文件，它將數據以<key,value>的形式序列化到文件中。這種二進制文件內部使用Hadoop 的標準的Writable 介面實現序列化和反序列化。它與Hadoop API中的MapFile 是互相兼容的。

MapFile即為排序後的SequeneceFile，它會額外生成一個索引文件提供按鍵的查找。文件不支持復寫操作，不能向已存在的SequenceFile(MapFile)追加存儲記錄，在執行文件寫操作的時候，該文件是不可讀取的。

Avro是一種用於支持數據密集型的二進制文件格式。它的文件格式更為緊湊，若要讀取大量數據時，Avro能夠提供更好的序列化和反序列化性能。並且Avro數據文件天生是帶Schema定義的，所以它不需要開發者在API 級別實現自己的Writable對象。最近多個Hadoop 子項目都支持Avro 數據格式，如Pig 、Hive、Flume、Sqoop和Hcatalog。

面向列：Parquet 、RCFile、ORCFile

RCFile是Hive推出的一種專門面向列的數據格式。 它遵循「先按列劃分，再垂直劃分」的設計理念。當查詢過程中，針對它並不關心的列時，它會在IO上跳過這些列。

ORCFile （Optimized Record Columnar File)提供了一種比RCFile更加高效的文件格式。其內部將數據劃分為默認大小為250M的Stripe。每個Stripe包括索引、數據和Footer。索引存儲每一列的最大最小值，以及列中每一行的位置。

Parquet 是一種支持嵌套結構的列式存儲格式。Parquet 的存儲模型主要由行組（Row Group）、列塊（Column Chuck）、頁（Page）組成。

1、行組，Row Group：Parquet 在水平方向上將數據劃分為行組，默認行組大小與 HDFS Block 塊大小對齊，Parquet 保證一個行組會被一個 Mapper 處理。

2、列塊，Column Chunk：行組中每一列保存在一個列塊中，一個列塊具有相同的數據類型，不同的列塊可以使用不同的壓縮。

3、頁，Page：Parquet 是頁存儲方式，每一個列塊包含多個頁，一個頁是最小的編碼的單位，同一列塊的不同頁可以使用不同的編碼方式。

一般原始表數據使用文本格式存儲，其他的都是列式存儲。

目前在Hadoop中常用的幾種壓縮格式：lzo，gzip，snappy，bzip2,主要特性對比如下：

其性能對比如下：

2.1 lzo

hadoop中最流行的壓縮格式，壓縮/解壓速度也比較快，合理的壓縮率，支持split。適用於較大文本的處理。

對於lzo壓縮，常用的有LzoCodec和lzopCodec，可以對sequenceFile和TextFile進行壓縮。對TextFile壓縮後，mapred對壓縮後的文件默認是不能夠進行split操作，需要對該lzo壓縮文件進行index操作，生成lzo.index文件，map操作才可以進行split。如果設置LzoCodec，那麼就生成.lzo後綴的文件，可以用LzoIndexer 進行支持split的index計算，如果設置LzopCodec，那麼生成.lzo_deflate後綴的文件，不支持建立index。

❹ HDFS的數據存儲之block

HDFS被設計成支持非常大的文件，與HDFS兼容的應用是那些處理大數據集的應用。這些應用程序處理非常大的文件在具有隻被創建和寫入一次，被讀取一次或多次的特性，即HDFS中存儲的大文件是一次寫入多次讀取不支持修改的，同時要求HDFS滿足應用程序以流讀取速度的要求。

正是因為大數據系統對所需的文件系統有這些要求，就決定了HDFS在存儲模型上具有以下特點:

❺ HDFS由什麼組成

大數據平台包含了採集層、存儲層、計算層和應用層，是一個復雜的IT系統，需要學會Hadoop等分布式系統的開發技能。
1.1採集層：Sqoop可用來採集導入傳統關系型資料庫的數據、Flume對於日誌型數據採集，另外使用Python一類的語言開發網路爬蟲獲取網路數據；
1.2儲存層：分布式文件系統HDFS最為常用；採用了主從（Master/Slave）結構模型，一個HDFS集群是由一個NameNode和若干個DataNode組成的。其中NameNode作為主伺服器，管理文件系統的命名空間和客戶端對文件的訪問操作；集群中的DataNode管理存儲的數據。
1.3計算層：有不同的計算框架可以選擇，常見的如MapRece、Spark等，一般來講，如果能使用計算框架的「原生語言」，運算效率會最高（MapRece的原生支持Java，而Spark原生支持Scala）；
1.4應用層：包括結果數據的可視化、交互界面開發以及應用管理工具的開發等，更多的用到Java、Python等通用IT開發前端、後端的能力；

❻ Hadoop生態系統-新手快速入門（含HDFS、HBase系統架構）

Hadoop是一個由Apache基金會所開發的分布式系統基礎架構。

用戶可以在不了解分布式底層細節的情況下，開發分布式程序。充分利用集群的威力進行高速運算和存儲。

Hadoop實現了一個分布式文件系統（Hadoop Distributed File System），簡稱HDFS。HDFS有高容錯性的特點，並且設計用來部署在低廉的（low-cost）硬體上；而且它提供高吞吐量（high throughput）來訪問應用程序的數據，適合那些有著超大數據集（large data set）的應用程序。

Hadoop的框架最核心的設計就是：HDFS和MapRece。HDFS為海量的數據提供了存儲，而MapRece則為海量的數據提供了計算。

廣義的Hadoop，一般稱為Hadoop生態系統，如下所示。

Hadoop生態系統中這些軟體的作用：

HDFS 採用了主從（Master/Slave）結構模型，一個HDFS集群包括一個名稱節點（NameNode）和若干個數據節點（DataNode）。

HDFS採用Java語言開發，因此任何支持JVM的機器都可以部署名稱節點和數據節點。

在配置好Hadoop 集群之後，可以通過瀏覽器訪問 http://[NameNodeIP]:9870，查詢HDFS文件系統。通過該Web界面，可以查看當前文件系統中各個節點的分布信息。

HBase系統架構如下所示，包括客戶端、Zookeeper伺服器、Master主伺服器、Region伺服器。一般而言，HBase會採用HDFS作為底層數據存儲。

在HBase伺服器集群中，包含了一個Master和多個Region伺服器，Master是HBase集群的「總管」，它必須知道Region伺服器的狀態。

HBase中可以啟動多個Master，但是Zookeeper 可以幫助選舉出一個Master 作為集群的總管，並保證在任何時刻總有唯一一個Master在運行，這樣可以避免Master單點失效的問題。

Region伺服器是HBase中最核心的模塊，負責維護分配給自己的Region，並響應用戶的讀寫請求。

Store是Region伺服器的核心。每個Store對應了表中的一個列族的存儲。每一個Store包含了一個MemStore緩存和若干個StoreFile文件。

HBase採用HLog來保證系統發生故障時，能夠恢復到正確的狀態。HLog是磁碟上面的記錄文件，它記錄著所有的更新操作。

HBase系統為每個Region伺服器配置了一個HLog文件，它是一種預寫式日誌（Write Ahead Log），也就是說，用戶更新數據必須首先被記入日誌後，才能寫入MemStore緩存。

此外，Pig和Hive還為HBase提供了高層語言支持，使得在HBase上進行數據統計處理變的非常簡單。 Sqoop則為HBase提供了方便的RDBMS數據導入功能，使得傳統資料庫數據向HBase中遷移變的非常方便。

注意：Hadoop 安裝完成之後，只包含HDFS和MapRece，並不含HBase，因此需要在Hadoop 之上繼續安裝HBase。

❼ hadoop項目孵化時主要包括哪兩個項目

Hadoop的兩個核心組成：
HDFS:分布式文件系統，存儲海量的數據。
MapRece:並行處理框架，實現任務分解和調度。
Hadoop由以下幾個項目構成
1、HadoopCommon：Hadoop體系最底層的一個模塊，為Hadoop各子項目提供各種工具，如：配置文件和日誌操作等。
2、HDFS：分布式文件系統，提供高吞吐量的應用程序數據訪問，對外部客戶機而言，HDFS就像一個傳統的分級文件系統。可以創建、刪除、移動或重命名文件，等等。但是HDFS的架構是基於一組特定的節點構建的，這是由它自身的特點決定的。這些節點包括NameNode（僅一個），它在HDFS內部提供元數據服務；DataNode，它為HDFS提供存儲塊。
由於僅存在一個NameNode，因此這是HDFS的一個缺點（單點失敗）。存儲在HDFS中的文件被分成塊，然後將這些塊復制到多個計算機中（DataNode）。這與傳統的RAID架構大不相同。塊的大小（通常為64MB）和復制的塊數量在創建文件時由客戶機決定。NameNode可以控制所有文件操作。HDFS內部的所有通信都基於標準的TCP/IP協議。
3、MapRece：一個分布式海量數據處理的軟體框架集計算集群。
4、Avro：dougcutting主持的RPC項目，主要負責數據的序列化。有點類似Google的protobuf和Facebook的thrift。avro用來做以後hadoop的RPC，使hadoop的RPC模塊通信速度更快、數據結構更緊湊。
5、Hive：類似CloudBase，也是基於hadoop分布式計算平台上的提供datawarehouse的sql功能的一套軟體。使得存儲在hadoop裡面的海量數據的匯總，即席查詢簡單化。hive提供了一套QL的查詢語言，以sql為基礎，使用起來很方便。
6、HBase：基於HadoopDistributedFileSystem，是一個開源的，基於列存儲模型的可擴展的分布式資料庫，支持大型表的存儲結構化數據。
7、Pig：是一個並行計算的高級的數據流語言和執行框架，SQL-like語言，是在MapRece上構建的一種高級查詢語言，把一些運算編譯進MapRece模型的Map和Rece中，並且用戶可以定義自己的功能。
8、ZooKeeper：Google的Chubby一個開源的實現。它是一個針對大型分布式系統的可靠協調系統，提供的功能包括：配置維護、名字服務、分布式同步、組服務等。ZooKeeper的目標就是封裝好復雜易出錯的關鍵服務，將簡單易用的介面和性能高效、功能穩定的系統提供給用戶。
9、Chukwa：一個管理大型分布式系統的數據採集系統由yahoo貢獻。
10、Cassandra：無單點故障的可擴展的多主資料庫。
11、Mahout：一個可擴展的機器學習和數據挖掘庫。

❽ Hadoop分布式文件系統（HDFS）會不會被淘汰

首先我們應該更具體的理解這樣一個現象，為什麼流行的技術閉閉敏框架會被淘汰。談到淘汰，常見兩種情況：

第一：應用模式被淘汰了，例如：BB機，功能機，最終被智能機淘汰，膠卷被數碼相機淘汰，即便諾基亞的功能機做得再完美，也會被淘汰。軟體方面例如：終端的字處理，郵件收發等應用軟體被視窗應用軟體淘汰。

第二：技術升級，新技術彌補了老技術的缺陷，並且引入了更多有優勢的功能。例如：Springframework的橫空出世，配合Hibernate，在具有同樣功效的情況下，解決了EJB的部署復雜，體態臃腫，計算效率低，用靈活性，面向程序員的友好性，淘汰了曾經企業級經典的EJB。

那麼對於Hadoop分布式文件系統（HDFS），我們要討論它的淘汰可能性，淘汰時間，首先我們就要看它為什麼要被淘汰的因素。從模式上，分布式文件系統是大數據存儲技術極為重要的一個領域，我們還看不到分布式文件系統有被淘汰的任何理由，那麼我就再看技術升級是否有淘汰它的可能性。

談技術升級，首先要看HDFS的缺點，然後再看這種缺點的解決辦法，是否會帶來新的技術框架，然後讓HDFS埋進歷史的垃圾堆。

HDFS為集中式態橋協調架構，namenode若是單節點，部署並不復雜，但是namenode作為單節點無法可靠的運行在生產環境，必須對namenode實現雙機HA，那麼部署復雜度就變得極高，這時候需要在namenode，datanode的基礎上再引入namenode active，namenode standby的概念，需要引入QJM的元數據共享存儲並基於Paxos做一致性協調，另外需要引入ZKFC和ZooKeeper，解決主備選舉，健康探測，主備切換等操作。

因此HDFS的部署復雜度完全是因為namenode HA導致的。這是集中式管理的分布式架構一個原生問題，如果在這個地方進行優化的話，那麼就是簡化QJM，ZKFC，ZooKeeper的多組服務，用一組服務來代替，但是namenode和datanode的分布式數據塊的讀寫，復制，恢復機制，目前看非常成熟，高效，這是核心問題，並不是缺點，不需要更具顛覆性的優化。

由於namenode在內存中記錄了所有數據塊（block 默認128M）的信息，索引了數據塊與datanode的關系，並且構建了文件系統樹，因此可想而知namenode的元數據內存區是大量佔用內存，這是沒有上限的。對於較大型數據存儲項目，例如上百個datanode節點和上千萬個數據塊的容量來說，元數據在namenode的內存大概能控制在32G以內，這是還沒問題的，但是對於構建海量數據中心的超大型項目，這個問題就好像達摩克斯之劍，首先堆內存超過臨界范圍導致的內存定址性能問題不說，一旦namenode內存超限到單機內存可承載的物理上最大承受范圍，整個hdfs數據平台將面臨停止服務。

這個問題的本質還是Google設計GFS時候採用粗放的實用主義，先把元數據都交給主節點在內存中節制，超大問題以後再解決。目前Google的GFS2設計上，已經將元數據在內存中遷移至了BigTable上，那麼問題就來了：「BigTable基於GFS，而GFS2的元數據基於BigTable」？有點雞生蛋還是蛋生雞的自相矛盾。是的，看似矛盾實質轎枝上是架構的嵌套復用，可以這么去解讀：GFS2是基於<基於GFS的BigTable的元數據存儲>的下一代GFS架構。用BigTable的k-v存儲模型放GFS2的元數據，雖然沒有內存高效，但是夠用，而且可以無限存儲，用BigTable專門存儲元數據形成的k-v記錄最終保存成GFS數據塊，因此在GFS的元數據內存中只需少量的內存佔用，就能支撐天量的真正應用於數據塊存儲的GFS2元數據。

基於GFS2的設計思想，我相信下一代HDFS應該也是這樣的方案去解決元數據的內存瓶頸問題，也就是基於<基於HDFS的HBase的元數據存儲>的下一代HDFS架構。那麼HDFS的元數據瓶頸問題將被徹底解決，很難看到比這更具優勢的替代性技術框架了。

如下圖所示：

副本數默認為3最大的問題就是占空間，這幾乎是所有傳統分布式文件系統（DFS）的通病。因此HDFS集群的默認空間利用率只有33.3%，這么低的利用率顯然不符合一些場景，例如長期的冷數據備份，那麼有沒有更好的方式呢？是有的，目前比較成熟的方案就是糾刪碼技術，類似raid5，raid6，HDFS 3.0版本以後支持這種模式，叫做Erasure Coding(EC)方案。

HDFS是怎麼通過EC方案解決磁碟利用率的問題呢？我們先聊點比較硬的原理，說說EC方案之一的條形布局：

首先數據文件寫的時候會向N個節點的塊(Block)依次寫入，N個Block會被切成多組條(stripe 1... stripe n)，如果分布式環境有五個存儲節點(DataNode)，那麼就把stripe切成3個單元(cell)，然後再根據這3個cell計算出2個校驗cell，然後這5個cell（3個data+2個parity）分別寫入5個Block中。數據條就這么依次輪巡的方式，將校驗塊的位置輪換存儲在不同Block上，直至寫滿，這樣校驗塊的分布可以更均勻。

其次再說取數據，取數據每次只從3個DataNode中各取出1個cell，如果這3個cell都是數據cell，那麼就成功拿到一組數據條stripe，如果有一個cell是校驗cell，那麼就能通過校驗cell和另外2個數據cell計算出第3個數據cell，完成數據條stripe的組合。這種情況下，即便是5個datanode節點有2個datanode宕機了，另外3個datanode也能通過校驗碼計算完成剩餘2個節點的數據，這就是利用糾刪碼技術實現數據冗餘的原理。

通過這種方式，我們就比傳統2副本50%，3副本33.3%的多副本模式要省空間，EC中2+1可以達到66.7%的磁碟利用率，例子是3+2可以達到60%的磁碟利用率

但是其問題是特別消耗CPU計算，上面那種讀取情況，五分之三的讀取數據條時間都要進行校驗碼計算。因此可以利用Intel CPU推出的ISA-L底層函數庫專門用於提升校糾刪碼演算法的編解碼性能。通常情況下，糾刪碼用於冷數據的冗餘，也就是不經常訪問，但又必須聯機存儲以備查詢的數據。除了磁碟利用率，多副本方式用空間換效率的方式肯定是最好，沒什麼問題。

❾ 關於hbase存儲模型的描述正確的是

關於hbase存儲模型的描述正確的有四個。
1、應用在FusionInsightHD的上層備裂應用。
2、HFS封裝了Hbase與HDFS的介面。
3、為上層應用仿棗閉提供文件存儲、岩彎讀取、刪除等功能。
4、HFS是：Hbase的獨立模塊。