系列文章目錄

一、HDFS設計原理
二、HDFS系統架構
三、HDFS關鍵技術
四、HDFS應用實例
五、解決HDFS不能處理小文件詳解問題

---

---

前言

HDFS（Hadoop Distributed File System，Hadoop分布式文件系統）是專為大規模數據集設計的分布式文件存儲解決方案，它通過一系列的技術和設計理念，實現了高效、可靠、可擴展的大數據存儲。以下是對HDFS如何做到大規模數據存儲的詳細說明，包括其設計原理、架構、關鍵技術以及應用實例，

---

一、設計原理

HDFS的設計原理主要基于“分而治之”的策略，即將大文件分割成固定大小的數據塊（Block），并將這些數據塊分布存儲在多個計算節點（DataNode）上，以實現數據的并行處理和冗余存儲。這種設計使得HDFS能夠處理PB級別的數據存儲，并支持高吞吐量的數據訪問。

二、系統架構

HDFS采用主從架構（Master-Slave Architecture），主要由以下幾個組件組成：

• NameNode：HDFS的主節點，負責維護文件系統的命名空間，管理文件系統樹及整棵樹內所有的文件和目錄。NameNode還負責維護文件系統樹中各個文件和目錄的元數據信息，包括權限信息、文件屬性等。這些信息被保存在NameNode的內存中，以便快速查詢。
• DataNode：HDFS的從節點，負責處理文件系統客戶端的讀寫請求，在文件系統中實際存儲數據。DataNode會定期向NameNode發送心跳信號和塊報告，告知NameNode自己的狀態以及存儲的塊信息。
• Secondary NameNode：并非NameNode的熱備，其主要作用是定期合并NameNode的編輯日志（Edit Log）和文件系統鏡像（FSImage），以減少NameNode啟動時間。此外，Secondary NameNode還可以在NameNode發生故障時，用于恢復NameNode。
• Client：HDFS的客戶端，是用戶與HDFS交互的主要途徑。客戶端提供的API使得應用程序可以方便地讀取、寫入和管理分布式文件系統中的文件。

三、關鍵技術

• 數據塊（Block）：HDFS將大文件分割成固定大小的數據塊（默認大小為128MB，Hadoop 2.x版本以后可配置），每個數據塊會存儲在多個DataNode上，實現數據的分布式存儲。這種設計有利于數據的并行處理和負載均衡。
• 副本機制：為了保證數據的可靠性，HDFS采用副本機制，默認情況下，每個數據塊會有三個副本。這些副本會被分布在不同的DataNode上，甚至可能位于不同的機架上，以避免單點故障導致的數據丟失。
• 元數據管理：NameNode負責維護文件系統的元數據信息，包括文件名、路徑、副本數量、數據塊ID以及存儲的DataNode節點等信息。這些信息被保存在NameNode的內存中，并通過編輯日志和文件系統鏡像進行持久化存儲。
• 容錯性設計：HDFS通過多種機制來保障系統的高可用性，包括數據塊的冗余存儲、DataNode的心跳檢測、NameNode的故障恢復等。當DataNode出現故障時，HDFS會自動從其他DataNode上讀取副本數據，以保證數據的可用性。
• 擴展性：HDFS支持動態添加DataNode，以實現存儲容量的擴展。這種設計使得HDFS能夠輕松應對數據量的快速增長。

四、應用實例

以互聯網公司使用HDFS存儲用戶行為數據為例，HDFS作為大數據離線分析的基礎存儲平臺，可以支撐PB級別數據的存儲和分析。具體流程如下：

數據收集：通過日志收集系統（如Flume）將用戶行為數據實時收集并寫入HDFS。
數據存儲：HDFS將收集到的數據按照一定的規則進行分割和存儲，每個數據塊會被復制到多個DataNode上，以實現數據的冗余存儲。
數據分析：數據挖掘工程師可以使用MapReduce、Spark等計算框架對存儲在HDFS中的數據進行處理和分析，以發現有價值的信息。
結果展示：分析得到的結果可以通過數據可視化工具進行展示，為企業的決策提供有力支持。

五、解決HDFS不能處理小文件詳解問題

HDFS通過其獨特的設計原理和架構，實現了大規模數據的高效、可靠、可擴展存儲。它采用數據塊分割、副本機制、元數據管理等多種技術，保障了數據的可靠性和可用性。同時，HDFS還支持動態擴展，能夠輕松應對數據量的快速增長。在實際應用中，HDFS已經成為大數據處理和分析的重要工具之一，為企業提供了強有力的數據支持。
然而，需要注意的是，HDFS并非完美無缺。由于其針對大規模數據集進行優化，因此在處理小文件時可能會存在性能瓶頸。此外，HDFS的寫入操作相對較慢，且不支持并發寫入和隨機讀寫操作。因此，在選擇存儲解決方案時，需要根據具體的應用場景和需求進行綜合考慮。在數據倉庫中，小文件問題是一個常見的挑戰，特別是在使用Hadoop HDFS（Hadoop Distributed File System）等分布式存儲系統時。小文件會導致大量的元數據開銷、NameNode性能下降以及HDFS讀寫效率的降低。為了有效地處理小文件問題，可以采取以下幾種策略：

1. 合并小文件

• 手動合并：通過編寫腳本或程序，將多個小文件合并成一個大文件。這種方法適用于周期性或批處理場景。
• Hadoop MapReduce作業：利用MapReduce框架編寫作業來合并小文件。MapReduce作業可以并行處理大量數據，提高合并效率。
• Hadoop Archive (HAR)：HAR是一種用于存儲和管理小文件的技術，它將多個小文件打包成一個單獨的歸檔文件，類似于zip格式。這樣可以減少存儲空間的占用和元數據的開銷。
• Spark動態分區合并：Spark SQL支持通過動態分區寫入和AQE（Adaptive Query Execution，自適應查詢執行）特性來自動合并較小的分區，從而減少小文件的數量。

2. 優化Hive配置

• 設置輸入輸出合并：在Hive中，可以通過設置hive.merge.mapredfiles、hive.merge.mapfiles等參數來在Map或Reduce任務結束時合并小文件。
  控制Map和Reduce的數量：減少Map和Reduce的數量可以減少小文件的生成。例如，通過set mapred.reduce.tasks來設置Reduce的數量，或者通過distribute by rand()來盡量使每個Reduce處理的數據量均衡。
• 使用CombineHiveInputFormat：將hive.input.format設置為org.apache.hadoop.hive.ql.io.CombineHiveInputFormat，可以在執行Map前進行小文件合并。

3. 使用壓縮和存儲格式優化

• 文件壓縮：使用gzip、bzip2、snappy等壓縮算法對小文件進行壓縮，可以減少磁盤空間和網絡帶寬的使用，并減少小文件損壞的可能性。
• 存儲格式優化：Hive支持多種存儲格式，如ORC、Parquet等。這些格式允許將多個小文件壓縮并序列化成一個大文件，從而提高存儲效率和查詢性能。

4. 定時合并任務

• 定時調度：設置定時任務（如每天或每周）來合并小文件。這可以通過編寫腳本或利用大數據平臺的調度工具（如Airflow、Apache Oozie等）來實現。
• 數據清洗任務：在數據傳輸或處理任務后，增加一個清洗任務來合并小文件。這可以確保從數據源開始，小文件就不會向下游流去。

5. 重建表

• 無分區表重建：對于無分區的表，可以考慮直接將表刪掉然后重建，使用新的配置或處理邏輯來避免小文件的產生。
• 分區表優化：對于分區表，可以優化分區策略以減少小文件的產生。同時，也可以利用Hive的ALTER TABLE CONCATENATE等命令來合并分區中的小文件。

6. 垃圾回收

• 定期刪除過期數據：使用HDFS的TTL（Time-To-Live）機制或定期執行刪除命令來刪除過期或不再需要的數據，以減少HDFS的存儲壓力和元數據開銷。
  綜上所述，處理數據倉庫中的小文件問題需要從多個方面入手，包括合并小文件、優化Hive配置、使用壓縮和存儲格式優化、設置定時合并任務、重建表以及垃圾回收等。在實際應用中，可以根據具體情況選擇最合適的策略或組合多種策略來解決問題。

補充面試題

1. hdfs寫入數據原理[面試]

1.客戶端發起寫入數據的請求給namenode
2.namenode接收到客戶端請求,開始校驗(是否有權限,路徑是否存在,文件是否存在等),如果校驗沒問題,就告知客戶端可以寫入
3.客戶端收到消息,開始把文件數據分割成默認的128m大小的的block塊,并且把block塊數據拆分成64kb的packet數據包,放入傳輸序列

4.客戶端攜帶block塊信息再次向namenode發送請求,獲取能夠存儲block塊數據的datanode列表
5.namenode查看當前距離上傳位置較近且不忙的datanode,放入列表中返回給客戶端
6.客戶端連接datanode,開始發送packet數據包,第一個datanode接收完后就給客戶端ack應答(客戶端就可以傳入下一個packet數據包),同時第一個datanode開始復制剛才接收到的數據包給node2,node2接收到數據包也復制給node3(復制成功也需要返回ack應答),最終建立了pipeline傳輸通道以及ack應答通道
7.其他packet數據根據第一個packet數據包經過的傳輸通道和應答通道,循環傳入packet,直到當前block塊數據傳輸完成(存儲了block信息的datanode需要把已經存儲的塊信息定期的同步給namenode)

8.其他block塊數據存儲,循環執行上述4-7步,直到所有block塊傳輸完成,意味著文件數據被寫入成功(namenode把該文件的元數據保存上)
9.最后客戶端和namenode互相確認文件數據已經保存完成(也會匯報不能使用的datanode)

2. 讀取數據原理[面試]

1.客戶端發送讀取文件請求給namenode

2.namdnode接收到請求,然后進行一系列校驗(路徑是否存在,文件是否存在,是否有權限等),如果沒有問題,就告知可以讀取
3.客戶端需要再次和namenode確認當前文件在哪些datanode中存儲
4.namenode查看當前距離下載位置較近且不忙的datanode,放入列表中返回給客戶端

5.客戶端找到最近的datanode開始讀取文件對應的block塊信息(每次傳輸是以64kb的packet數據包),放到內存緩沖區中
6.接著讀取其他block塊信息,循環上述3-5步,直到所有block塊讀取完畢(根據塊編號拼接成完整數據)
7.最后從內存緩沖區把數據通過流寫入到目標文件中

8.最后客戶端和namenode互相確認文件數據已經讀取完成(也會匯報不能使用的datanode)

3. 元數據存儲的原理[面試]

1.namenode第一次啟動的時候先把最新的fsimage文件中內容加載到內存中,同時把edits文件中內容也加載到內存中
2.客戶端發起指令(增刪改查等操作),namenode接收到客戶端指令把每次產生的新的指令操作先放到內存中
3.然后把剛才內存中新的指令操作寫入到edits_inprogress文件中
4.edits_inprogress文件中數據到了一定閾值的時候,把文件中歷史操作記錄寫入到序列化的edits備份文件中
5.namenode就在上述2-4步中循環操作…

6.當secondarynamenode檢測到自己距離上一次檢查點(checkpoint)已經1小時或者事務數達到100w,就觸發secondarynamenode詢問namenode是否對edits文件和fsimage文件進行合并操作
7.namenode告知可以進行合并
8.secondarynamenode將namenode上積累的所有edits和一個最新的fsimage下載到本地，并加載到內存進行合并(這個過程稱checkpoint）
9.secondarynamenode把剛才合并后的fsimage.checkpoint文件拷貝給namenode

10.namenode把拷貝過來的最新的fsimage.checkpoint文件,重命名為fsimage,覆蓋原來的文件

注意: 不要死記硬背,要結合自己的理解,轉換為自己的話術,用于面試

4. hdfs如何保證數據安全：三大機制

4.1 副本機制:

為了保證數據安全和效率,block塊信息存儲多個副本,第一副本保存在客戶端所在服務器,第二副本保存在和第一副本不同機架服務器上,第三副本保存在和第二副本相同機架不同服務器

4.2 負載均衡機制:

namenode為了保證不同的datanode中block塊信息大體一樣,分配存儲任務的時候會優先保存在距離近且余量比較大的datanaode上

4.3 心跳機制:

datanode每隔3秒鐘向namenode匯報自己的狀態信息,如果某個時刻,datanode連續10次不匯報了,namenode會認為datanode有可能宕機了,namenode就會每5分鐘(300000毫秒)發送一次確認消息,連續2次沒有收到回復,就認定datanode此時一定宕機了(確認datanode宕機總時間310+52*60=630秒)。觀察地址http://node3:9864/datanode.html