A. HDFS 架構
HDFS 涉及兩個重要進程：NameNode、DataNode。
他們一般都部署單獨部署在不同伺服器上，運行 NameNode 的伺服器是主伺服器，運行 DataNode 的伺服器是從伺服器。主伺服器只有一個，從伺服器有多個。
這種一主多從的架構基本適用於所有分布式系統或框架。可重復使用的架構方案叫作架構模式，一主多從可謂是大數據領域的最主要的架構模式。主伺服器只有一台，掌控全局。從伺服器有很多台，負責具體的事情。這樣很多台伺服器可以有效組織起來，對外表現出一個統一又強大的存儲計算能力。
DataNode 負責文件數據的存儲和讀寫操作，HDFS 將文件數據分割成若干數據塊（Block），每個 DataNode 存儲一部分數據塊，這樣文件就分布存儲在整個 HDFS 伺服器集群中。應用程序客戶端（Client）可以並行對這些數據塊進行訪問，從而使得 HDFS 可以在伺服器集群規模上實現數據並行訪問，極大地提高了訪問速度。
在實踐中，HDFS 集群的 DataNode 伺服器會有很多台，一般在幾百台到幾千台這樣的規模，每台伺服器配有數塊磁碟，整個集群的存儲容量大概在幾 PB 到數百 PB。
NameNode 負責整個分布式文件系統的元數據（MetaData）管理，也就是文件路徑名、數據塊的 ID 以及存儲位置等信息，相當於操作系統中文件分配表（FAT）的角色。HDFS 為了保證數據的高可用，會將一個數據塊復制為多份（默認3份），並將多份相同的數據塊存儲在不同的機架的伺服器上。這樣當有磁碟損壞，或者某個 DataNode 伺服器宕機，甚至某個交換機宕機時，系統能通過其備份的數據塊進行查找。
處理客戶端的請求。
客戶端向 HDFS 上傳文件。
客戶端向 HDFS 讀取文件。
像 NameNode 這樣主從伺服器管理同一份數據的場景，如果從伺服器錯誤地以為主伺服器宕機而接管集群管理，會出現主從伺服器一起對 DataNode 發送指令，進而導致集群混亂，也就是所謂的「腦裂」。這也是這類場景選舉主伺服器時，引入 ZooKeeper 的原因。
B. hdfs詳解之塊、小文件和副本數
1、block：block是物理切塊，在文件上傳到HDFS文件系統後，對大文件將以每128MB的大小切分若干，存放在不同的DataNode上。例如一個文件130M，那麼他會存被切分成2個塊，一個塊128M，另一個塊2M.
1、HDFS 適應場景: 大文件存儲，小文件是致命的
2、如果小文件很多的，則有可能將NN(4G=42億位元組)撐爆。例如:1個小文件(閾值<=30M),那麼NN節點維護的位元組大約250位元組。一億個小文件則是250b * 1億=250億.將會把NN節點撐爆。如果一億個小文件合並成100萬個大文件:250b * 1百萬=2億位元組。
3、在生產上一般會:
1）調整小文件閾值
2）合並小文件:
a.數據未落地到hdfs之前合並
b.數據已經落到hdfs，調用spark service服務 。每天調度去合並 （-15天 業務周期）
3）小文件的危害:
a.撐爆NN。
b.影響hive、spark的計算。佔用集群計算資源
1、如果是偽分布式，那麼副本數只能為一。
2、生成上副本數一般也是官方默認參數: 3份
如果一個文件130M，副本數為3。那麼第一個block128M，有三份。另外一個block2M，也有三份。
題目:
blockSize128M,副本數3份，那麼一個文件260M，請問多少塊，多少實際存儲？
260%128=2....4M 3個塊 3個副本=9塊
260M 3=780M
C. HDFS架構
HDFS中的文件是以數據塊（Block）的形式存儲的，默認最基本的存儲單位是128 MB（Hadoop 1.x為64 MB）的數據塊。也就是說，存儲在HDFS中的文件都會被分割成128 MB一塊的數據塊進行存儲，如果文件本身小於一個數據塊的大小，則按實際大小存儲，並不佔用整個數據塊空間。HDFS的數據塊之所以會設置這么大，其目的是減少定址開銷。數據塊數量越多，定址數據塊所耗的時間就越多。當然也不會設置過大，MapRece中的Map任務通常一次只處理一個塊中的數據，如果任務數太少，作業的運行速度就會比較慢。HDFS的每一個數據塊默認都有三個副本，分別存儲在不同的DataNode上，以實現容錯功能。因此，若數據塊的某個副本丟失並不會影響對數據塊的訪問。數據塊大小和副本數量可在配置文件中更改
NameNode是HDFS中存儲元數據（文件名稱、大小和位置等信息）的地方，它將所有文件和文件夾的元數據保存在一個文件系統目錄樹中，任何元數據信息的改變，NameNode都會記錄。HDFS中的每個文件都被拆分為多個數據塊存放，這種文件與數據塊的對應關系也存儲在文件系統目錄樹中，由NameNode維護。NameNode還存儲數據塊到DataNode的映射信息，這種映射信息包括：數據塊存放在哪些DataNode上、每個DataNode上保存了哪些數據塊。NameNode也會周期性地接收來自集群中DataNode的「心跳」和「塊報告」。通過「心跳」與DataNode保持通信，監控DataNode的狀態（活著還是宕機），若長時間接收不到「心跳」信息，NameNode會認為DataNode已經宕機，從而做出相應的調整策略。「塊報告」包含了DataNode上所有數據塊的列表信息。
DataNode是HDFS中真正存儲數據的地方。客戶端可以向DataNode請求寫入或讀取數據塊，DataNode還在來自NameNode的指令下執行塊的創建、刪除和復制，並且周期性地向NameNode匯報數據塊信息。
NodeSecondaryNameNode用於幫助NameNode管理元數據，從而使NameNode能夠快速、高效地工作。它並不是第二個NameNode，僅是NameNode的一個輔助工具。HDFS的元數據信息主要存儲於兩個文件中：fsimage和edits。fsimage是文件系統映射文件，主要存儲文件元數據信息，其中包含文件系統所有目錄、文件信息以及數據塊的索引；edits是HDFS操作日誌文件，HDFS對文件系統的修改日誌會存儲到該文件中。當NameNode啟動時，會從文件fsimage中讀取HDFS的狀態，也會對文件fsimage和edits進行合並，得到完整的元數據信息，隨後會將新HDFS狀態寫入fsimage。但是在繁忙的集群中，edits文件會隨著時間的推移變得非常大，這就導致NameNode下一次啟動的時間會非常長。為了解決這個問題，則產生了SecondaryNameNode，SecondaryNameNode會定期協助NameNode合並fsimage和edits文件，並使edits文件的大小保持在一定的限制內。SecondaryNameNode通常與NameNode在不同的計算機上運行，因為它的內存需求與NameNode相同，這樣可以減輕NameNode所在計算機的壓力。
D. HDFS 系統架構
HDFS Architecture
Hadoop Distributed File System (HDFS) 是設計可以運行於普通商業硬體上的分布式文件系統。它跟現有的分布式文件系統有很多相通的地方，但是區別也是顯著的。HDFS具有高度容錯性能，被設計運行於低成本硬體上。HDFS可以向應用提供高吞吐帶寬，適合於大數據應用。HDFS 放寬了一些 POSIX 的要求，以開啟對文件系統數據的流式訪問。HDFS 最初是作為Apache Nutch web 搜索引擎項目的基礎設施開發的。HDFS 現在是 Apache Hadoop 核心項目的一部分。
HDFS是主從架構。一個HDFS集群包含一個NameNode，一個管理文件系統命名空間和控制客戶端訪問文件的master server。以及，若乾的 DataNodes，通常集群的每個node一個，管理運行DataNode的節點上的存儲。HDFS 發布一個文件系統命名空間，並允許用戶數據已文件的形式存儲在上面。內部，一個文件被分成一個或多個塊，存儲在一組DataNodes上。NameNode 執行文件系統命名空間操作，比如：打開、關閉、重命名文件或目錄。它還確定塊到DataNodes的映射。DataNodes 負責向文件系統客戶端提供讀寫服務。DataNodes 根據 NameNode 的指令執行塊的創建、刪除以及復制。
NameNode 和 DataNode 是設計運行於普通商業機器的軟體。這些機器通常運行 GNU/Linux 操作系統。HDFS 是Java 語言編寫的；任何支持Java的機器都可以運行NameNode or DataNode 軟體。使用高移植性Java語言，意味著HDFS可以部署在很大范圍的機器上。一個典型的部署就是一台特定的機器只運行NameNode 軟體，而集群內的其他機器運行DataNode 軟體的一個實例。這種架構不排除一台機器上運行多個DataNodes ，但是在實際部署中很少見。
單 NameNode 節點的存在大大簡化了架構。NameNode 是所有HDFS 元數據的仲裁和倉庫。系統設計上，用戶數據永遠不經過NameNode。
HDFS 支持傳統的文件分級組織。用戶或應用可以創建目錄，並在目錄內存儲文件。 文件系統命名空間的層次結構跟其他文件系統類似；可以創建、刪除、移動、重命名文件。HDFS 支持 user quotas 和 access permissions 。 HDFS 不支持軟、硬鏈接。但是，HDFS 架構不排除實現這些功能。
雖然HDFS遵守 文件系統命名約定 ，一些路徑和名稱 (比如/.reserved 和.snapshot ) 保留了。比如功能 transparent encryption 和 snapshot 就使用的保留路徑。
NameNode 維護文件系統命名空間。任何文件系統命名空間或屬性的變化，都會被NameNode記錄。 應用可以指定HDFS應維護的文件副本數量。文件副本的數量被稱為該文件的復制因子 replication factor 。該信息存儲於NameNode。
HDFS 被設計用於在一個大規模集群上跨機器可靠地存儲巨大的文件。它以一序列的塊的方式存儲文件。每個文件都可以配置塊尺寸和復制因子。
一個文件除了最後一個塊外，其他的塊一樣大。在 append 和 hsync 添加了可變長度塊的支持後，用戶可以啟動一個新的塊，而不用填充最後一個塊到配置的塊大小。
應用可以指定一個文件的副本數量。復制因子可以在創建的時候指定，也可以以後更改。HDFS的文件只寫一次(除了 appends 和 truncates) ，並在任何時候只允許一個 writer 。
NameNode 指定塊復制的所有決策。它周期性的從集群的每個DataNodes 接受 Heartbeat 和 Blockreport。Heartbeat 的接受代表 DataNode 工作正常。Blockreport 包含了DataNode上所有塊的清單。
副本的位置對HDFS的可靠性和性能至關重要。副本位置的優化是HDFS和其他大多數分布式文件系統的區別。這是一個需要大量調優和經驗的特性。Rack-aware 復制策略的目的就是提高數據可靠性，可用性和網路帶寬利用率。當前副本位置策略的實現是這個方向的第一步。實施該策略的短期目標是在生產環境驗證它，了解其更多的行為，為測試和研究更復雜的策略打下基礎。
大型HDFS實例運行在跨多個Rack的集群伺服器上。不同rack的兩個node通信需要通過交換機。大多數情況下，同一rack內的帶寬大於rack之間的帶寬。
NameNode 通過在 Hadoop Rack Awareness 內的進程描述 判斷DataNode 屬於哪個rack id。一個簡單但是並非最佳的策略是將副本分布於不同的racks。這可以防止整個機架發生故障時丟失數據，並允許在讀取數據時使用多個機架的帶寬。該策略在群集中均勻地分布副本，使得組件故障時很容易平衡負載。 但是，該策略會增加寫入成本，因為寫入操作需要將塊傳輸到多個機架。
一般，復制因子設置為3， HDFS 的分布策略是：如果writer在datanode上則將一個副本放到本地機器， 如果writer不在datanode上則將一個副本放到writer所在機櫃的隨機datanode 上；另一個副本位於不同機架的node上；最後一個副本位於同一遠程機架的不同node上。 該策略減少了機架間的寫流量，提升了寫性能。機架故障的概率遠小於節點故障的概率；此策略不會影響數據可靠性和可用性承諾。但是，在讀取數據時，它確實減少了聚合帶寬，因為塊存儲於兩個機櫃而不是三個機櫃內。使用此策略，副本不會均勻的分布於機架上。1/3 副本 位於同一節點， 2/3 副本位於同一機架， 另1/3副本位於其他機架。該策略提升了寫性能而不影響數據可靠性和讀性能。
如果復制因子大於3，那麼第4個及以後的副本則隨機放置，只要滿足每個機架的副本在(replicas - 1) / racks + 2)之下。
因為 NameNode 不允許 DataNodes 擁有同一個塊的多個副本，所以副本的最大數就是DataNodes的數量。
在把對 存儲類型和存儲策略 的支持添加到 HDFS 後，除了上面介紹的rack awareness外， NameNode 會考慮其他副本排布的策略。NameNode 先基於rack awareness 選擇節點，然後檢查候選節點有文件關聯的策略需要的存儲空間。 如果候選節點沒有該存儲類型， NameNode 會查找其他節點。如果在第一條路徑中找不到足夠的節點來放置副本，NameNode會在第二條路徑中查找具有回滾存儲類型的節點。 、
當前，這里描述的默認副本排布策略正在使用中。
為了最小化全局帶寬消耗和讀取延遲， HDFS 會嘗試從最靠近reader的副本響應讀取請求。如果在reader節點的同一機架上上存在副本，則該副本有限響應讀請求。如果HDFS集群跨多個數據中心，則本地數據中心優先。
啟動時，NameNode 會進入一個稱為 Safemode 的特殊狀態。當NameNode處於Safemode狀態時，不會復制數據塊。NameNode從DataNodes接收Heartbeat和Blockreport消息。Blockreport包含DataNode託管的數據塊列表。每個塊都指定了最小副本數。當數據塊的最小副本數已與NameNode簽入時，該塊被認為是安全復制的。在NameNode簽入安全復制數據塊的已配置百分比（加上額外的30秒）後，NameNode退出Safemode狀態。然後，它判斷列表內的數據塊清單是否少於副本指定的數量。NameNode 然後復制這些塊給其他 DataNodes。
HDFS 命名空間由 NameNode 存儲。NameNode 使用事務日誌 EditLog 來持久化的保存系統元數據的每次變更。比如，在HDFS創建一個新文件，NameNode會在 EditLog 插入一條記錄來指示該變更。類似的，變更文件的復制因子也會在 EditLog 插入一條新記錄。NameNode 以文件的形式，將 EditLog 保存在本地OS文件系統上。整個文件系統命名空間，包括塊到文件的映射、文件系統屬性，都存儲於名字為 FsImage 的文件內。 FsImage 也以文件的形式，存儲在NameNode的本地文件系統上。
NameNode 將包含整個文件系統和塊映射的image保存在內存中。當NameNode啟動時，或檢查點被預先定義的閾值觸發時，它會從磁碟讀取 FsImage 和 EditLog ，把 EditLog 內的事物應用到內存中的FsImage，再將新版本刷新回磁碟的新 FsImage 。然後會截斷舊的 EditLog ，因為它的事物已經應用到了持久化的 FsImage 上。 這個過程稱為檢查點 checkpoint 。檢查點的目的是通過對文件系統元數據進行快照並保存到FsImage，來確保HDFS擁有文件系統元數據的一致性視圖。盡管讀取 FsImage 是高效的，但是對 FsImage 直接增量修改是不高效的。不是對每次編輯修改 FsImage ，而是將每次編輯保存到 Editlog 。在檢查點期間，將 Editlog 的變更應用到 FsImage 。一個檢查點可以在固定周期(dfs.namenode.checkpoint.period)(以秒為單位)觸發，也可以文件系統事物數量達到某個值(dfs.namenode.checkpoint.txns)的時候觸發。
DataNode 在本地文件系統上以文件的形式存儲 HDFS data 。DataNode 不知道 HDFS 文件。它將HDFS data 的每個塊以獨立的文件存儲於本地文件系統上。DataNode 不在同一目錄創建所有的文件。而是，使用heuristic來確定每個目錄的最佳文件數量，並適當的創建子目錄。在一個目錄創建所有的本地文件是不好的，因為本地文件系統可能不支持單目錄的海量文件數量。當DataNode啟動的時候，它掃描本地文件系統，生成與本地文件系統一一對應的HDFS數據塊列表，然後報告給NameNode。這個報告稱為 Blockreport。
所有的HDFS通信協議都在TCP/IP協議棧上。客戶端與NameNode指定的埠建立連接。與NameNode以ClientProtocol 通信。DataNodes與NameNode以DataNode Protocol進行通信。遠程過程調用(RPC)封裝了Client Protocol 和 DataNode Protocol。設計上，NameNode從不啟動任何RPCs。相反，它只應答DataNodes or clients發出的RPC請求。
HDFS的主要目標是可靠的存儲數據，即使是在故障的情況下。常見故障類型有三種： NameNode failures , DataNode failures 和 network partitions 。
每個DataNode都周期性的向NameNode發送心跳信息。 一個 network partition 可能導致DataNodes子集丟失與NameNode的連接。NameNode會基於心跳信息的缺失來偵測這種情況。NameNode將沒有心跳信息的DataNodes標記為 dead ，並不再轉發任何IO請求給它們。任何注冊到dead DataNode的數據對HDFS將不再可用。DataNode death會導致某些塊的復制因子低於它們指定的值。NameNode不斷跟蹤需要復制的塊，並在必要時啟動復制。很多因素會導致重新復制：DataNode不可用，副本損壞，DataNode上硬碟故障，復制因子增加。
標記 DataNodes dead 的超時時間保守地設置了較長時間 (默認超過10分鍾) 以避免DataNodes狀態抖動引起的復制風暴。對於性能敏感的應用，用戶可以設置較短的周期來標記DataNodes為過期，讀寫時避免過期節點。
HDFS 架構支持數據再平衡schemes。如果一個DataNode的空餘磁碟空間低於閾值，sheme就會將數據從一個DataNode 移動到另外一個。在某些文件需求突然增長的情況下，sheme可能會在集群內動態的創建額外的副本，並再平衡其他數據。這些類型的數據再平衡schemes還沒有實現。
有可能從DataNode獲取的數據塊，到達的時候損壞了。這種損壞可能是由於存儲設備故障、網路故障、軟體bug。HDFS客戶端軟體會HDFS的內容進行校驗。當客戶端創建HDFS文件的時候，它計算文件每個塊的校驗值，並以獨立的隱藏文件存儲在同一HDFS命名空間內。當客戶端檢索文件時候，它會校驗從每個DataNode獲取的數據，是否與關聯校驗文件內的校驗值匹配。 如果不匹配，客戶端可以從另外擁有副本塊的DataNode檢索。
FsImage 和 EditLog 是HDFS的核心數據結構。這些文件的損壞將導致HDFS實例異常。 因此，NameNode可以配置為支持多 FsImage 和 EditLog 副本模式。任何對 FsImage or EditLog 的更新都會導致每個 FsImages 和 EditLogs 的同步更新。 FsImage 和 EditLog 的同步更新會導致降低命名空間每秒的事物效率。但是，這種降級是可以接受的，因為HDFS應用是數據密集型，而不是元數據密集型。當NameNode重啟的時候，它會選擇最新的一致的 FsImage 和 EditLog 。
另外一種提供故障恢復能力的辦法是多NameNodes 開啟HA，以 shared storage on NFS or distributed edit log (called Journal)的方式。推薦後者。
Snapshots - 快照，支持在特定時刻存儲數據的副本。快照功能的一個用法，可以回滾一個故障的HDFS實例到已知工作良好的時候。
HDFS被設計與支持超大的文件。與HDFS適配的軟體都是處理大數據的。這些應用都只寫一次，但是它們會讀取一或多次，並且需要滿足流式讀速度。HDFS支持文件的 一次寫入-多次讀取 語義。 HDFS典型的塊大小是128 MB.。因此，HDFS文件被分割為128 MB的塊，可能的話每個塊都位於不同的DataNode上。
當客戶端以復制因子3寫入HDFS文件時，NameNode以 復制目標選擇演算法 replication target choosing algorithm 檢索DataNodes 列表。該列表包含了承載該數據塊副本的DataNodes清單。然後客戶端寫入到第一個DataNode。第一DataNode逐步接受數據的一部分，將每一部分內容寫入到本地倉庫，並將該部分數據傳輸給清單上的第二DataNode。第二DataNode，按順序接受數據塊的每個部分，寫入到倉庫，然後將該部分數據刷新到第三DataNode。最終，第三DataNode將數據寫入到其本地倉庫。
因此，DataNode從管道的前一個DataNode獲取數據，同時轉發到管道的後一個DataNode。因此，數據是以管道的方式從一個DataNode傳輸到下一個的。
應用訪問HDFS有很多方式。原生的，HDFS 提供了 FileSystem Java API 來給應用調用。還提供了 C language wrapper for this Java API 和 REST API 。另外，還支持HTTP瀏覽器查看HDFS實例的文件。 通過使用 NFS gateway ，HDFS還可以掛載到客戶端作為本地文件系統的一部分。
HDFS的用戶數據是以文件和目錄的形式組織的。它提供了一個命令行介面 FS shell 來提供用戶交互。命令的語法類似於其他shell (比如：bash, csh)。如下是一些範例：
FS shell 的目標是向依賴於腳本語言的應用提供與存儲數據的交互。
DFSAdmin 命令用於管理HDFS集群。這些命令僅給HDFS管理員使用。如下範例：
如果啟用了回收站配置，那麼文件被 FS Shell 移除時並不會立即從HDFS刪除。HDFS會將其移動到回收站目錄(每個用戶都有回收站，位於 /user/<username>/.Trash )。只要文件還在回收站內，就可以快速恢復。
最近刪除的文件大多數被移動到 current 回收站目錄 ( /user/<username>/.Trash/Current )，在配置周期內，HDFS給 current目錄內的文件創建檢查點 checkpoints (位於 /user/<username>/.Trash/<date> ) ，並刪除舊的檢查點。參考 expunge command of FS shell 獲取更多關於回收站檢查點的信息。
在回收站過期後，NameNode從HDFS命名空間刪除文件。刪除文件會將文件關聯的塊釋放。注意，在用戶刪除文件和HDFS增加free空間之間，會有一個明顯的延遲。
如下範例展示了FS Shell如何刪除文件。我們在delete目錄下創建兩個文件(test1 & test2)
我們刪除文件 test1。如下命令顯示文件被移動到回收站。
現在我們嘗試以skipTrash參數刪除文件，該參數將不將文件發送到回收站。文件將會從HDFS完全刪除。
我們檢查回收站，只有文件test1。
如上，文件test1進了回收站，文件test2被永久刪除了。
當縮減文件的復制因子時，NameNode選擇可以被刪除的多餘副本。下一個Heartbeat會通報此信息給DataNode。DataNode然後會刪除響應的塊，相應的剩餘空間會顯示在集群內。同樣，在setReplication API調用完成和剩餘空間在集群顯示之間會有一個時間延遲。
Hadoop JavaDoc API .
HDFS source code: http://hadoop.apache.org/version_control.html
E. hdfs適合存儲多大的單個文件
首先hdfs是建立在多個機器文件系統上的一個邏輯上的文件系統。它的底層數據以數據塊方式存儲，塊大小可進行調整。
假如你設置一個數據塊大小為256M，上傳一個1G的文件，它底層會將這個文件分成4塊存儲，每個塊256M。你在hdfs上看到的是一個完整的文件，隨時可對這個文件進行操作，無需關注它的存儲。就像你在操作系統上操作文件一樣，無需關注它存在那個磁碟哪個扇區
F. hdfs為什麼不適合處理大量的小文件
在HDFS中，namenode將文件系統中的元數據存儲在內存中，因此，HDFS所能存儲的文件數量會受到namenode內存的專限制。一般屬來說，每個文件、目錄、數據塊的存儲信息大約佔150個位元組，根據當前namenode的內存空間的配置，就可以計算出大約能容納多少個文件了。
有一種誤解就是，之所以HDFS不適合大量小文件，是因為即使很小的文件也會佔用一個塊的存儲空間。這是錯誤的，HDFS與其它文件系統不同，小於一個塊大小的文件，不會佔用一個塊的空間。
G. HDFS 上每個數據節點最多能存多少，多大的數據
HDFS 上每個數據節點最多能存儲多少數據取決於節點的硬碟大小。
對於單個節點來說，其存儲的容量為磁碟容量減去hdfs-site.xml配置文件中dfs.datanode..reserved參數值。
對於集群來說，取決於集群中所有DataNode節點的硬碟大小之和。但是需要注意考慮集群的備份數量，假設備份數量為3，集群總容量為3TB,則實際可以存儲1TB的文件。
H. parquet和orc
Parquet文件是自解析的，文件中包括該文件的數據和元數據。在HDFS文件系統和Parquet文件中存在如下幾個概念：
1）HDFS塊(Block)：它是HDFS上的最小的副本單位，HDFS會把一個Block存儲在本地的一個文件並且維護分散在不同的機器上的多個副本，通常情況下一個Block的大小為256M、512M等。
2）HDFS文件(File)：一個HDFS的文件，包括數據和元數據，數據分散存儲在多個Block中。
3）行組(Row Group)：按照行將數據物理上劃分為多個單元，每一個行組包含一定的行數，在一個HDFS文件中至少存儲一個行組，Parquet讀寫的時候會將整個行組緩存在內存中，所以如果每一個行組的大小是由內存大的小決定的。
4）列塊(Column Chunk)：在一個行組中每一列保存在一個列塊中，行組中的所有列連續的存儲在這個行組文件中。不同的列塊可能使用不同的演算法進行壓縮。
5）頁(Page)：每一個列塊劃分為多個頁，一個頁是最小的編碼的單位，在同一個列塊的不同頁可能使用不同的編碼方式。
Parquet文件的格式如下圖所示：
可以看出，存儲格式中元數據索引信息是被存儲在最後的，所以當讀取某一行的數據的時候，就需要去定位最後的索引信息，最後才能去讀取對應的行數據。元數據包括 Parquet 原始類型定義、Page類型、編碼類型、壓縮類型等等。
Parquet 支持嵌套結構的數據模型，而非扁平式的數據模型，這是 Parquet 相對其他列存比如 ORC 的一大特點或優勢。支持嵌套式結構，意味著 Parquet 能夠很好的將諸如 Protobuf，thrift，json 等對象模型進行列式存儲。
Parquet 的數據模型也是 schema 表達方式，用關鍵字 message 表示。每個欄位包含三個屬性，repetition屬性（required/repeated/optional）、數據類型（primitive基本類型/group復雜類型）及欄位名。如：
和Parquet類似，ORC文件也是以二進制方式存儲的，所以是不可以直接讀取，ORC文件也是自解析的，它包含許多的元數據，這些元數據都是同構ProtoBuffer進行序列化的。ORC的文件結構如下圖，其中涉及到如下的概念：
ORC文件：保存在文件系統上的普通二進制文件，一個ORC文件中可以包含多個stripe，每一個stripe包含多條記錄，這些記錄按照列進行獨立存儲，對應到Parquet中的row
group的概念。
文件級元數據：包括文件的描述信息PostScript、文件meta信息（包括整個文件的統計信息）、所有stripe的信息和文件schema信息。
stripe：一組行形成一個stripe，每次讀取文件是以行組為單位的，一般為HDFS的塊大小，保存了每一列的索引和數據。
stripe元數據：保存stripe的位置、每一個列的在該stripe的統計信息以及所有的stream類型和位置。
row group：索引的最小單位，一個stripe中包含多個row group，默認為10000個值組成。
stream：一個stream表示文件中一段有效的數據，包括索引和數據兩類。索引stream保存每一個row group的位置和統計信息，數據stream包括多種類型的數據，具體需要哪幾種是由該列類型和編碼方式決定。
在ORC文件中保存了三個層級的統計信息，分別為文件級別、stripe級別和row group級別的，他們都可以用來根據Search ARGuments（謂詞下推條件）判斷是否可以跳過某些數據，在統計信息中都包含成員數和是否有null值，並且對於不同類型的數據設置一些特定的統計信息。
讀取ORC文件是從尾部開始的，第一次讀取16KB的大小，盡可能的將Postscript和Footer數據都讀入內存。文件的最後一個位元組保存著PostScript的長度，它的長度不會超過256位元組，PostScript中保存著整個文件的元數據信息，它包括文件的壓縮格式、文件內部每一個壓縮塊的最大長度(每次分配內存的大小)、Footer長度，以及一些版本信息。在Postscript和Footer之間存儲著整個文件的統計信息(上圖中未畫出)，這部分的統計信息包括每一個stripe中每一列的信息，主要統計成員數、最大值、最小值、是否有空值等。
接下來讀取文件的Footer信息，它包含了每一個stripe的長度和偏移量，該文件的schema信息(將schema樹按照schema中的編號保存在數組中)、整個文件的統計信息以及每一個row group的行數。
處理stripe時首先從Footer中獲取每一個stripe的其實位置和長度、每一個stripe的Footer數據(元數據，記錄了index和data的的長度)，整個striper被分為index和data兩部分，stripe內部是按照row group進行分塊的(每一個row group中多少條記錄在文件的Footer中存儲)，row group內部按列存儲。每一個row group由多個stream保存數據和索引信息。每一個stream的數據會根據該列的類型使用特定的壓縮演算法保存。在ORC中存在如下幾種stream類型：
PRESENT：每一個成員值在這個stream中保持一位(bit)用於標示該值是否為NULL，通過它可以只記錄部位NULL的值
DATA：該列的中屬於當前stripe的成員值。
LENGTH：每一個成員的長度，這個是針對string類型的列才有的。
DICTIONARY_DATA：對string類型數據編碼之後字典的內容。
SECONDARY：存儲Decimal、timestamp類型的小數或者納秒數等。
ROW_INDEX：保存stripe中每一個row group的統計信息和每一個row group起始位置信息。
在初始化階段獲取全部的元數據之後，可以通過includes數組指定需要讀取的列編號，它是一個boolean數組，如果不指定則讀取全部的列，還可以通過傳遞SearchArgument參數指定過濾條件，根據元數據首先讀取每一個stripe中的index信息，然後根據index中統計信息以及SearchArgument參數確定需要讀取的row group編號，再根據includes數據決定需要從這些row group中讀取的列，通過這兩層的過濾需要讀取的數據只是整個stripe多個小段的區間，然後ORC會盡可能合並多個離散的區間盡可能的減少I/O次數。然後再根據index中保存的下一個row group的位置信息調至該stripe中第一個需要讀取的row group中。
ORC文件格式只支持讀取指定欄位，還不支持只讀取特殊欄位類型中的指定部分。
使用ORC文件格式時，用戶可以使用HDFS的每一個block存儲ORC文件的一個stripe。對於一個ORC文件來說，stripe的大小一般需要設置得比HDFS的block小，如果不這樣的話，一個stripe就會分別在HDFS的多個block上，當讀取這種數據時就會發生遠程讀數據的行為。如果設置stripe的只保存在一個block上的話，如果當前block上的剩餘空間不足以存儲下一個strpie，ORC的writer接下來會將數據打散保存在block剩餘的空間上，直到這個block存滿為止。這樣，下一個stripe又會從下一個block開始存儲。
由於ORC中使用了更加精確的索引信息，使得在讀取數據時可以指定從任意一行開始讀取，更細粒度的統計信息使得讀取ORC文件跳過整個row group，ORC默認會對任何一塊數據和索引信息使用ZLIB壓縮，因此ORC文件佔用的存儲空間也更小，這點在後面的測試對比中也有所印證。
I. hdfs的特點有哪些
hdfs的特點
一、hdfs的優點
1.支持海量數據的存儲：一般來說，HDFS存儲的文件可以支持TB和PB級別的數據。
2.檢測和快速應對硬體故障：在集群環境中，硬體故障是常見性問題。因為有上千台伺服器連在一起，故障率很高，因此故障檢測和自動恢復hdfs文件系統的一個設計目標。假設某一個datanode掛掉之後，因為數據是有備份的，還可以從其他節點里找到。namenode通過心跳機制來檢測datanode是否還存活。
3.流式數據訪問：（HDFS不能做到低延遲的數據訪問，但是HDFS的吞吐量大）=》Hadoop適用於處理離線數據，不適合處理實時數據。HDFS的數據處理規模比較大，應用一次需要大量的數據，同時這些應用一般都是批量處理，而不是用戶互動式處理。應用程序能以流的形式訪問資料庫。主要的是數據的吞吐量，而不是訪問速度。訪問速度最終是要受制於網路和磁碟的速度，機器節點再多，也不能突破物理的局限。
4.簡化的一致性模型：對於外部使用用戶，不需要了解hadoop底層細節，比如文件的切塊，文件的存儲，節點的管理。一個文件存儲在HDFS上後，適合一次寫入，多次讀取的場景。因為存儲在HDFS上的文件都是超大文件，當上傳完這個文件到hadoop集群後，會進行文件切塊，分發，復制等操作。如果文件被修改，會導致重新觸發這個過程，而這個過程耗時是最長的。所以在hadoop里，2.0版本允許數據的追加，單不允許數據的修改。
5.高容錯性：數據自動保存多個副本，副本丟失後自動恢復。可構建在廉價的機器上，實現線性擴展。當集群增加新節點之後，namenode也可以感知，將數據分發和備份到相應的節點上。
6.商用硬體：Hadoop並不需要運行在昂貴且高可靠的硬體上。它是設計運行在商用硬體（在各種零售店都能買到的普通硬體）的集群上的，因此至少對於龐大的集群來說，節點故障的幾率還是非常高的。HDFS遇到上述故障時，被設計成能夠繼續運行且不讓用戶察覺到明顯的中斷。
二、HDFS缺點（局限性）
1、不能做到低延遲數據訪問：由於hadoop針對高數據吞吐量做了優化，犧牲了獲取數據的延遲，所以對於低延遲數據訪問，不適合hadoop。對於低延遲的訪問需求，HBase是更好的選擇。
2、不適合大量的小文件存儲 ：由於namenode將文件系統的元數據存儲在內存中，因此該文件系統所能存儲的文件總數受限於namenode的內存容量。根據經驗，每個文件、目錄和數據塊的存儲信息大約佔150位元組。因此，如果有一百萬個小文件，每個小文件都會佔一個數據塊，那至少需要300MB內存。如果是上億級別的，就會超出當前硬體的能力。
3、修改文件：對於上傳到HDFS上的文件，不支持修改文件。Hadoop2.0雖然支持了文件的追加功能，但是還是不建議對HDFS上的文件進行修改。因為效率低下。HDFS適合一次寫入，然後多次讀取的場景。
4、不支持用戶的並行寫：同一時間內，只能有一個用戶執行寫操作。
J. 大數據之HDFS
在現代的企業環境中，單機容量往往無法存儲大量數據，需要跨機器存儲。統一管理分布在集群上的文件系統稱為 分布式文件系統 。
HDFS （Hadoop Distributed File System）是 Hadoop 的核心組件之一， 非常適於存儲大型數據 (比如 TB 和 PB)， HDFS 使用多台計算機存儲文件，並且提供統一的訪問介面，像是訪問一個普通文件系統一樣使用分布式文件系統。
HDFS是分布式計算中數據存儲管理的基礎，是基於流數據模式訪問和處理超大文件的需求而開發的，可以運行於廉價的商用伺服器上。它所具有的 高容錯、高可靠性、高可擴展性、高獲得性、高吞吐率 等特徵為海量數據提供了不怕故障的存儲，為超大數據集的應用處理帶來了很多便利。
HDFS 具有以下 優點 ：
當然 HDFS 也有它的 劣勢 ，並不適合以下場合：
HDFS 採用Master/Slave的架構來存儲數據，這種架構主要由四個部分組成，分別為HDFS Client、NameNode、DataNode和Secondary NameNode。
Namenode是整個文件系統的管理節點，負責接收用戶的操作請求。它維護著整個文件系統的目錄樹，文件的元數據信息以及文件到塊的對應關系和塊到節點的對應關系。
Namenode保存了兩個核心的數據結構：
在NameNode啟動的時候，先將fsimage中的文件系統元數據信息載入到內存，然後根據edits中的記錄將內存中的元數據同步到最新狀態；所以，這兩個文件一旦損壞或丟失，將導致整個HDFS文件系統不可用。
為了避免edits文件過大， SecondaryNameNode會按照時間閾值或者大小閾值，周期性的將fsimage和edits合並 ，然後將最新的fsimage推送給NameNode。
並非 NameNode 的熱備。當NameNode 掛掉的時候，它並不能馬上替換 NameNode 並提供服務。其主要任務是輔助 NameNode，定期合並 fsimage和fsedits。
Datanode是實際存儲數據塊的地方，負責執行數據塊的讀/寫操作。
一個數據塊在DataNode以文件存儲在磁碟上，包括兩個文件，一個是數據本身，一個是元數據，包括數據塊的長度，塊數據的校驗和，以及時間戳。
文件劃分成塊，默認大小128M，以快為單位，每個塊有多個副本（默認3個）存儲不同的機器上。
Hadoop2.X默認128M， 小於一個塊的文件，並不會占據整個塊的空間 。Block數據塊大小設置較大的原因：
文件上傳 HDFS 的時候，Client 將文件切分成 一個一個的Block，然後進行存儲。
Client 還提供一些命令來管理 HDFS，比如啟動或者關閉HDFS。
Namenode始終在內存中保存metedata，用於處理「讀請求」，到有「寫請求」到來時，namenode會首 先寫editlog到磁碟，即向edits文件中寫日誌，成功返回後，才會修改內存 ，並且向客戶端返回，Hadoop會維護一個fsimage文件，也就是namenode中metedata的鏡像，但是fsimage不會隨時與namenode內存中的metedata保持一致，而是每隔一段時間通過合並edits文件來更新內容。
HDFS HA（High Availability）是為了解決單點故障問題。
HA集群設置兩個名稱節點，「活躍（ Active ）」和「待命（ Standby ）」，兩種名稱節點的狀態同步，可以藉助於一個共享存儲系統來實現，一旦活躍名稱節點出現故障，就可以立即切換到待命名稱節點。
為了保證讀寫數據一致性，HDFS集群設計為只能有一個狀態為Active的NameNode，但這種設計存在單點故障問題，官方提供了兩種解決方案：
通過增加一個Secondary NameNode節點，處於Standby的狀態，與Active的NameNode同時運行。當Active的節點出現故障時，切換到Secondary節點。
為了保證Secondary節點能夠隨時頂替上去，Standby節點需要定時同步Active節點的事務日誌來更新本地的文件系統目錄樹信息，同時DataNode需要配置所有NameNode的位置，並向所有狀態的NameNode發送塊列表信息和心跳。
同步事務日誌來更新目錄樹由JournalNode的守護進程來完成，簡稱為QJM，一個NameNode對應一個QJM進程，當Active節點執行任何命名空間文件目錄樹修改時，它會將修改記錄持久化到大多數QJM中，Standby節點從QJM中監聽並讀取編輯事務日誌內容，並將編輯日誌應用到自己的命名空間。發生故障轉移時，Standby節點將確保在將自身提升為Active狀態之前，從QJM讀取所有編輯內容。
注意，QJM只是實現了數據的備份，當Active節點發送故障時，需要手工提升Standby節點為Active節點。如果要實現NameNode故障自動轉移，則需要配套ZKFC組件來實現，ZKFC也是獨立運行的一個守護進程，基於zookeeper來實現選舉和自動故障轉移。
雖然HDFS HA解決了「單點故障」問題，但是在系統擴展性、整體性能和隔離性方面仍然存在問題：
HDFS HA本質上還是單名稱節點。HDFS聯邦可以解決以上三個方面問題。
在HDFS聯邦中，設計了多個相互獨立的NN，使得HDFS的命名服務能夠水平擴展，這些NN分別進行各自命名空間和塊的管理，不需要彼此協調。每個DN要向集群中所有的NN注冊，並周期性的發送心跳信息和塊信息，報告自己的狀態。
HDFS聯邦擁有多個獨立的命名空間，其中，每一個命名空間管理屬於自己的一組塊，這些屬於同一個命名空間的塊組成一個「塊池」。每個DN會為多個塊池提供塊的存儲，塊池中的各個塊實際上是存儲在不同DN中的。