hdfs文件存儲

1. hadoop 中文件是怎麼存儲的

1、存儲文件的時候需要指定存儲的路徑，這個路徑是HDFS的路徑。而不是哪個節點的某個目錄。比如./hadoop fs -put localfile hdfspat
一般操作的當前路徑是/user/hadoop比如執行./hadoop fs -ls .實際上就相當於./hadoop fs -ls /user/hadoop
2、HDFS本身就是一個文件系統，在使用的時候其實不用關心具體的文件是存儲在哪個節點上的。如果需要查詢可以通過頁面來查看，也可以通過API來實現查詢。

2. HDFS 上每個數據節點最多能存多少，多大的數據

HDFS 上每個數據節點最多能存多少，多大的數據

HDFS 每數據節點能存儲少數據取決於節點硬碟校 於單節點說其存儲容量磁碟容量減hdfs-site.xml配置文件dfs.datanode..reserved參數值 於集群說取決於集群所DataNode節點硬碟
-

hadoop的datanode上存儲多少數據就是由該datanode的磁碟空間決定的，配置文件中dfs.data.dir參數指定了hdfs數據存放目錄（多個目錄由逗號分隔）伏余緩缺模，設置好該參數後，這個datanode節點的最大存儲空間就由設定目錄的空間決定。hadoop各個datanode節點的數據量基本是一致的，可以通過balancer.sh來平衡各個節點的空間利用率。

HDFS 上每個數據節點最多能存儲多少數據取決於節點的硬碟大小。
對於單個節點來說，其存儲的容量為磁碟容量減去hdfs-site.xml配置文件中dfs.datanode..reserved參數值。
對於集群來說，取決於集群中所有DataNode節點的硬碟大小之和。但是需要注意考慮集群的備份數量，假設備份數量為3，集群總容量為3TB,則實際可以存儲1TB的文件。

1.相同Hadoop版本同步數據
hadoop distcp -skipcrheck -update -m 20 hdfs:dchadoop002.dx:8020/user/dc/warehouse/test /user/dc/warehouse/test
2.不同hadoop版本同步數據
hadoop distcp -skipcrheck -update -m 20 hftp:ns1/user/test /user/dc/test
參數:
-m 表示並發數
-skipcrheck 跳過hdfs校驗
-update 更新文件
-

solr每個數據節點最多能存多少，多大的數據

單個數據節點並無數據量的限制，整個集群能存多少數毀局據取決於名稱節點的內存有多大，所存儲的單個文件的大小取決於整個集群所有數據節點的存儲容量之和有多大

sqlite最多能存多大的數據量

您好，我來為您解答：
sqlite本身最大支持2TB的數據量。
希望我的回答對你有幫助。

3. HDFS文件

Hadoop支持的文件系統由很多（見下圖），HDFS只是其中一種實現。java抽象類 org.apache.hadoop.fs.FileSystem 定義了Hadoop中一個文件系統的客戶端介面，並且該抽象類有幾個具體實現。Hadoop一般使用URI（下圖）方案來選取合適的文件系統實例進行交互。

特別的，HDFS文件系統的操作可以使用 FsSystem shell 、客戶端（http rest api、Java api、C api等）。

FsSystem shell 的用法基本同本地shell類似，命令可參考 FsSystem shell

Hadoop是用Java寫的，通過Java Api（ FileSystem 類）可以調用大部分Hadoop文件系統的交互操作。更詳細的介紹可參考 hadoop Filesystem 。

非Java開發的應用可以使用由WebHDFS協議提供的HTTP REST API，但是HTTP比原生的Java客戶端要慢，所以不到萬不得已盡量不要使用HTTP傳輸特大數據。通過HTTP來訪問HDFS有兩種方法：

兩種如圖

在第一種情況中，namenode和datanode內嵌的web服務作為WebHDFS的端節點運行（是否啟用WebHDFS可通過dfs.webhdfs.enabled設置，默認為true）。文件元數據在namenode上，文件讀寫操作首先被發往namenode，有namenode發送一個HTTP重定向至某個客戶端，指示以流的方式傳輸文件數據的目的或源datanode。

第二種方法依靠一個或多個獨立代理伺服器通過HTTP訪問HDFS。所有集群的網路通信都需要通過代理，因此客戶端從來不直接訪問namenode或datanode。使用代理後可以使用更嚴格的防火牆策略和帶寬策略。

HttpFs代理提供和WebHDFS相同的HTTP介面，這樣客戶端能夠通過webhdfs URI訪問介面。HttpFS代理啟動獨立於namenode和datanode的守護進程，使用httpfs.sh 腳本，默認在一個不同的埠上監聽（14000）。

下圖描述了

讀文件時客戶端與 HDFS 中的 namenode， datanode 之間的數據流動。

對上圖的解釋如下：

在讀取過程中， 如果 FSDataInputStream 在和一個 datanode 進行交流時出現了一個錯誤，他就去試一試下一個最接近的塊，他當然也會記住剛才發生錯誤的 datanode 以至於之後不會再在這個 datanode 上進行沒必要的嘗試。 DFSInputStream 也會在 datanode 上傳輸出的數據上核查檢查數(checknums).如果損壞的塊被發現了， DFSInputStream 就試圖從另一個擁有備份的 datanode 中去讀取備份塊中的數據。

在這個設計中一個重要的方面就是客戶端直接從 datanode 上檢索數據，並通過 namenode 指導來得到每一個塊的最佳 datanode。這種設計允許 HDFS 擴展大量的並發客戶端，因為數據傳輸只是集群上的所有 datanode 展開的。期間，namenode 僅僅只需要服務於獲取塊位置的請求（塊位置信息是存放在內存中，所以效率很高）。如果不這樣設計，隨著客戶端數據量的增長，數據服務就會很快成為一個瓶頸。

我們知道，相對於客戶端(之後就是 maprece task 了)，塊的位置有以下可能性：

我們認為他們對於客戶端的帶寬遞減，距離遞增（括弧中表示距離）。示意圖如下：

如果集群中的機器都在同一個機架上，我們無需其他配置，若集群比較復雜，由於hadoop無法自動發現網路拓撲，所以需要額外配置網路拓撲。

基本讀取程序，將文件內容輸出到console

FileSystemCat

隨機讀取

展開原碼

下圖描述了寫文件時客戶端與 HDFS 中的 namenode， datanode 之間的數據流動。

對上圖的解釋如下：

如果在任何一個 datanode 在寫入數據的時候失敗了，接下來所做的一切對客戶端都是透明的：首先， pipeline 被關閉，在確認隊列中的剩下的包會被添加進數據隊列的起始位置上，以至於在失敗的節點下游的任 何節點都不會丟失任何的包。然後與 namenode 聯系後，當前在一個好的 datanode 會聯系 namenode， 給失敗節點上還未寫完的塊生成一個新的標識ID， 以至於如果這個失敗的 datanode 不久後恢復了，這個不完整的塊將會被刪除。失敗節點會從 pipeline 中移除，然後剩下兩個好的 datanode 會組成一個的新的 pipeline ，剩下的 這些塊的包(也就是剛才放在數據隊列隊首的包)會繼續寫進 pipeline 中好的 datanode 中。最後，namenode 注意到塊備份數小於規定的備份數，他就安排在另一個節點上創建完成備份，直接從已有的塊中復制就可以。然後一直到滿足了備份數( dfs.replication )。如果有多個節點的寫入失敗了，如果滿足了最小備份數的設置( dfs.namenode.repliction.min ),寫入也將會成功，然後剩下的備份會被集群非同步的執行備份，直到滿足了備份數( dfs.replication )。

創建目錄

文件壓縮有兩大好處：

Hadoop 對於壓縮格式的是自動識別。如果我們壓縮的文件有相應壓縮格式的擴展名（比如 lzo，gz，bzip2 等）。Hadoop 會根據壓縮格式的擴展名自動選擇相對應的解碼器來解壓數據，此過程完全是 Hadoop 自動處理，我們只需要確保輸入的壓縮文件有擴展名。

Hadoop中有多種壓縮格式、演算法和工具，下圖列出了常用的壓縮方法。

表中的「是否可切分」表示對應的壓縮演算法是否支持切分，也就是說是否可以搜索數據流的任意位置並進一步往下讀取數據，可切分的壓縮格式尤其適合MapRece。

所有的壓縮演算法都需要權衡空間/時間：壓縮和解壓縮速度更快，其代價通常是只能節省少量的空間。不同的壓縮工具有不同的特性：

更詳細的比較如下

1.壓縮性能比較

2.優缺點

另外使用hadoop原生（native）類庫比其他java實現有更快的壓縮和解壓縮速度。特徵比較如下：

使用容器文件格式結合壓縮演算法也能更好的提高效率。順序文件、Arvo文件、ORCFiles、Parqurt文件同時支持壓縮和切分。

壓縮舉例（Java）

壓縮

解壓縮

六、文件序列化

序列化是指將結構化數據轉換為位元組流以便在網路上傳輸或寫到磁碟進行永久存儲。反序列化獅子將位元組流轉換回結構化對象的逆過程。

序列化用於分布式數據處理的兩大領域：進程間通信和永久存儲。

對序列化的要求時是格式緊湊（高效使用存儲空間）、快速（讀寫效率高）、可擴展（可以透明地讀取老格式數據）且可以互操作（可以使用不同的語言讀寫數據）。

Hadoop使用的是自己的序列化格式 Writable ，它絕對緊湊、速度快，但不太容易用java以外的語言進行擴展或使用。

當然，用戶也可以使用其他序列化框架或者自定義序列化方式，如 Avro 框架。

Hadoop內部還使用了 Apache Thrift 和 Protocal Buffers 來實現RPC和數據交換。

4. 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

5. hadoop怎麼保存配置文件

從安裝Hadoop 單機版的配置說起

在這里配置了Hadoop的文件目錄

1. 啟動Hadoop 並上傳文件

上傳文件命令：hadoop fs -put hadoop-2.9.2.tar.gz hdfs://hdgroup01:9000/

可以看到已經上傳了文件了

2. 刪除本地文件

如果刪除後你在瀏覽器刷新頁面 然後還能下載 說明 肯定存在其則哪寬他地方

使用命令下載也可以：hadoop fs -get hdfs://hdgroup01:9000/hadoop-2.9.2.tar.gz

3. hdfs 文件存放的位置

通過查看緩液 安裝時配置的hadoop文件目錄 上傳文件後的結果

這個dfs 應該見過的 就是在格式化namenode的時候 在我們配置的文件中創建了dfs 文件夾

4. 上傳一個349.5M 的文件

5. 進到hadoop 本地存儲文件中查看 存儲格式

上傳的文件為349.47M 被切分成了 三塊 因為是單機版 所以都存放到了 這台主機的文件系統中

可以看到 hadoop 塊大小為128M（默認） 超過128M的文件會被切成不同的塊存放

總結

1. hdfs是是通過分布式集群來存儲文件，為客戶端提供了一個便捷的訪問方式 虛擬的目錄結構

2. 文件存儲到hdfs集群中的時候是被切分成block的 默認為128M

3. 文件的block 存放在若乾颱datanode節點中

4. hdfs文件系統中的文件與真實的block之間有映射關系，由namenode管理

5. 每個block 在集孫亮群中會存儲多個副本，好處是可以提高數據的可靠性，還可以提高訪問的吞吐量。

6. 3.4 HDFS存儲原理

一、涉及的問題

1. 冗餘數據保存

2. 數據保存策略

3. 數據恢復

二、冗餘數據保存問題

1. 冗餘因子

出於成本考慮（也是HDFS優勢），HDFS常架構在廉價機器上——經常出故障。所以必須有冗餘機制。一般每個塊都保存3份，即冗餘因子默認是3

注意：偽分布式配置，即名稱節點和數據節點都放在同一個機器上，則冗餘因子顯然只能是1，因為只有一個機器

2. 冗餘機制的好處

(1) 加快數據傳輸速度——當多個客戶端同時想訪問相同數據塊時，可以同時並行而不需要排隊

(2) 很容易檢查數據錯誤——互相對照發現錯誤

(3) 保證數據可靠性——HDFS有這樣的機制：一旦探測到一個副本故障，會自動復制正確副本，使冗餘因子恢復默認值

三、數據保存與讀取

1. 第一副本存放策略：

(1) 如果保存請求來自集群內部，第一個副本放在發起者（應用）所在節點。比如一個在DataNode1上的應用發起存數據請求，那就把它第一份副本也存在DataNode1

(2) 如果保存請求來自集群外部，HDFS會隨機挑選一台磁碟不太忙且CPU不太忙的節點來放置第一個副本

2. 第二個副本存放策略：

放在和第一副本不同的機架的節點上 。如下圖中DataNode4，它和DataNode1在不同機架上

3. 第三副本放置策略：

放在和第一副本相同的機架的其他節點。如圖中的DataNode2或DataNode3

4. 更多副本存放策略：

全部隨機放置（依靠隨機演算法）

5、數據讀取

原則：就近讀取

——HDFS提供一個API可以告訴數據節點的機架ID，客戶端也可以用API診斷自己所在機架ID。ID相同說明在同一機架。而相同機架數據間通信很快，它們就是「相近」的數據。

——而前面也說了，每個數據塊都有多個不同的副本，如果找到某個副本和客戶端在同一個機架上，就優先選此副本。如果沒有就隨機找一個副本讀取

四、數據的錯誤與恢復

1. 名稱節點出錯

只有一個名稱節點，而且它保存了核心數據結構FsImage和EditLog。恢復方法：

(1) 在HDFS1.0里只能暫停服務，從第二名稱節點（冷備份）恢復

(2) 在HDFS2.0里可以直接用熱備份恢復而不用暫停服務

2. 數據節點出錯

(1) 如何發現數據節點出問題：

在整個運行期間，DataNode都會定期通過遠程調用向NameNode發送心跳信息。一旦隔了一個周期收不到心跳信息，則NameNode就知道這個DataNode發生了故障

(2) 如何恢復數據節點：

NameNode會在狀態列表裡把出錯的DataNode標記為不可用（宕機），然後把它裡面的數據塊對應的備份（在其他DataNode上）復制到另一個DataNode上去

——HDFS和其他分布式文件系統最大的區別就是 可以調整冗餘數據位置 。這種調整不僅發生在故障時，也可以在在機器負載不均衡時把一個DataNode的數據遷移到另一個上面以平衡負載

3. 數據出錯

(1) 如何發現數據出錯：

「校驗碼機制」——客戶端每寫入一個數據塊，都會為其生成一個校驗碼並保存在同一文件目錄下。讀取數據塊同時會核對其校驗碼，如果不對說明數據出問題了。

(2) 如何恢復數據：

從備份復制過來

Reference:

https://www.icourse163.org/learn/XMU-1002335004#/learn/content?type=detail&id=1214310117&cid=1217922275&replay=true

7. 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所在計算機的壓力。

8. hadoop面試題之HDFS

1、簡單介紹下hadoop吧？

    廣義上hadoop是指與hadoop相關的大數據生態圈。包含hive、spark、hbase等。

    狹義上hadoop指的是apache的開源框架。有三個核心組件：

----hdfs：分布式文件存儲系統

----yarn：分布式資源管理調度平台

----mr：分布式計算引擎

2、介紹下hdfs?

全稱為Hadoop Distributed File System。有三個核心組件：

namenode：有三個作用，第一是負責保存集群的元數據信息，第二是負責維護整個集群節點的正常運行。

第三是負責處理客戶端的請求。

datanode：負責實際保存數據。實際執行數據塊的讀寫操作。

secondarynamenode：輔助namenode進行元數據的管理。不是namenode的備份。

3、namenode的工作機制？

    namenode在內存中保存著整個內存系統的名稱空間和文件數據塊的地址映射。整個hdfs可存儲的文件數受限於namenode的內存大小。所以hdfs不適合大量小文件的存儲。

---namenode有三種元數據存儲方式來管理元數據：

    》內存元數據：內存中保存了完整的元數據

    》保存在磁碟上的元數據鏡像文件（fsimage）：該文件時hdfs存在磁碟中的元數據檢查點，裡面保存的是最後一次檢查點之前的hdfs文件系統中所有目錄和文件的序列化信息。

    》數據操作日誌文件（edits）：用於銜接內存meta data和持久化元數據鏡像fsimage之間的操作日誌文件。保存了自最後一次檢查點之後所有針對hdfs文件系統的操作。如對文件的增刪改查。

4、如何查看元數據信息？

    因為edits和fsimage文件是經過序列化的，所以不能直接查看。hadoop2.0以上提供了查看兩種文件的工具。

----命令：hdfs oiv 可以將fsimage文件轉換成其他格式，如xml和文本文件。-i 表示輸入fsimage文件。-o 輸出文件路徑，-p 指定輸出文件

                hdfs oev可以查看edits文件。同理需要指定相關參數。

詳情查看： https://www.imooc.com/article/79705

4、datanode的工作機制？

    1）以數據塊的形式存儲hdfs文件

    2）datanode響應客戶端的讀寫請求

    3）周期性的向namenode匯報心跳信息、數據塊信息、緩存數據塊信息

5、secondary namenode工作機制？

    當發生checkpoint機制時會觸發second namenode進行工作。checkpoint：

    新的edists文件不會立即和fsimage文件合並，是在edits文件大小超過（默認）64m，或者時間超過（默認）1小時，會觸發checkpoint操作。當checkpoint時，namenode會新建一個edits.new的文件,此時second namenode將文件fsimage文件和edits文件（http get）到本地，然後載入到內存中進行合並，完成的文件名稱為fsimage.ckpt。最後 second namenode將該文件（http post）到namenode，然後edits.new和fsimage.ckpt文件轉換為fsimage和edits。

6、hdfs的文件副本機制？

    所有的文件都是以塊的形式保存到hdfs中。塊的大小默認為128m。在hdfs-site文件中進行指定。

    動態副本創建策略：默認副本數是3，可以在上傳文件時，顯式設定replication。也可以通過指令修改文件的副本數 hadoop fs -setrep -R 1

7、為實現高可用，hdfs採用了哪些策略？

    副本機制、機架感知、心跳機制、安全模式、校驗和、回收站、元數據保護、快照機制（具體介紹導航- https://www.jianshu.com/writer#/notebooks/44567747/notes/66453316 ）

8、hdfs的存儲過程？

    ①client向hdfs發起寫請求，通過RPC與namenode建立通訊。namenode檢查文件是否存在等信息，返回是否可以存儲。

    ②client將文件切割為一個個block塊，client申請存儲第一塊block。namenode返回可以存儲這個block塊的datanode的地址，假設為ABC。

    ③A到B到C逐級構建pipeline。client向A上傳第一個packet，默認為64k。A收到一個packet後會將packet傳給B，再傳給C。pipeline反方向返回ack信息。最終由第一個節點A將pipelineack發送給client

    ④一個block完成之後，再進行下一個block的存儲過程。

9、hdfs的讀過程？

10、hdfs的垃圾桶機制？

    hdfs的垃圾桶機制默認是關閉的，需要手動開啟。hdfs刪除的文件不會立刻就刪除，而是在設定的時間後進行刪除。

11、hdfs的擴容和縮容

【

12、