大資料篇:HDFS
HDFS
HDFS是什麼?
Hadoop分散式檔案系統(HDFS)是指被設計成適合執行在通用硬體(commodity hardware)上的分散式檔案系統(Distributed File System)。它和現有的分散式檔案系統有很多共同點。但同時,它和其他的分散式檔案系統的區別也是很明顯的。HDFS是一個高度容錯性的系統,適合部署在廉價的機器上。HDFS能提供高吞吐量的資料訪問,非常適合大規模資料集上的應用。HDFS放寬了一部分POSIX約束,來實現流式讀取檔案系統資料的目的。HDFS在最開始是作為Apache Nutch搜尋引擎專案的基礎架構而開發的。HDFS是Apache Hadoop Core專案的一部分。
如果沒有HDFS!
- 大檔案的儲存我們必須要拓展硬碟。
- 硬碟拓展到一定的量以後,我們就不能在一個硬碟上儲存檔案了,要換一個硬碟,這樣檔案管理就成了問題。
- 為了防止檔案的損壞嗎,我們需要建立副本,副本的管理也成了問題。
- 分散式計算非常麻煩。
1 HDFS出現原因
1.1 早期檔案伺服器
- 從上圖中,我們可以看出,儲存一個檔案,我們一直往一個機子上面存是不夠的,那麼我們在儲存量不夠的時候就會加機子。
- 但是如果一個檔案放在一臺機子上,如果該機器掛了,那麼檔案就丟失了,不安全。
所以我們會把一個檔案放在多臺機子上,建立一個索引檔案來儲存檔案的指標,如圖中的file1儲存在node1,node2,node3上面,以此類推 - 缺點:
- 難以實現負載均衡
- 檔案大小不同,負載均衡不易實現
- 使用者自己控制檔案大小
- 難以並行化處理
- 只能利用一個節點資源處理一個檔案
- 無法動用叢集資源處理同一個檔案
- 難以實現負載均衡
1.2 HDFS檔案伺服器
- HDFS前提和設計目標
- 儲存超大檔案
- HDFS適合儲存大檔案,單個檔案大小通常在百MB以上
- HDFS適合儲存海量檔案,總儲存量可達PB,EB級
- 硬體容錯
- 基於普通機器搭建,硬體錯誤是常態而不是異常,因此錯誤檢測和快速、自動的恢復是HDFS最核心的架構目標
- 流式資料訪問
- 為資料批處理而設計,關注資料訪問的高吞吐量
- 簡單的一致性模型
- 一次寫入,多次讀取
- 一個檔案經過建立、寫入和關閉之後就不需要改變
- 如果是update操作其實是增加了版本號,並沒有修改原始檔
- 本地計算
- 將計算移動到資料附近(資料在哪個節點就在哪裡計算)
- 儲存超大檔案
- 從上圖我們看出,HDFS是把一個大的資料,拆成很多個block塊,然後在將block儲存在各個機子上。
建立檔案對應block的指標檔案,和block對應的節點node的指標檔案。 - 源自於Google的GFS論文
- 發表於2003年10月
- HDFS是GFS克隆版
- 易於擴充套件的分散式檔案系統
- 執行在大量普通廉價機器上,提供容錯機制
- 為大量使用者提供效能不錯的檔案存取服務
1.3 HDFS優缺點
- 優點
- 高容錯性
- 資料自動儲存多個副本
- 副本丟失後,自動恢復
- 適合批處理
- 移動計算而非資料
- 資料位置暴露給計算框架
- 適合大資料處理
- GB、TB、甚至PB級資料
- 百萬規模以上的檔案數量
- 10K+節點規模
- 流式檔案訪問
- 一次性寫入,多次讀取
- 保證資料一致性
- 可構建在廉價機器上
- 通過多副本提高可靠性
- 提供了容錯和恢復機制
- 高容錯性
- 缺點
- 低延遲資料訪問(慢)
- 比如毫秒級
- 低延遲與高吞吐率
- 小檔案存取
- 佔用NameNode大量記憶體
- 尋道時間超過讀取時間
- 併發寫入、檔案隨機修改
- 一個檔案只能有一個寫者
- 僅支援append(追加)
- 低延遲資料訪問(慢)
- 適用場景:適合一次寫入,多次讀出的場景,支援追加資料且不支援檔案的修改。
1.4 基本構成
- 資料塊
- 檔案以塊為單位進行切分儲存,塊通常設定的比較大(最小6M,預設128M),根據網路頻寬計算最佳值。
- 塊越大,定址越快,讀取效率越高,但同時由於MapReduce任務也是以塊為最小單位來處理,所以太大的塊不利於於對資料的並行處理。
- 一個檔案至少佔用一個塊(如果一個1KB檔案,佔用一個塊,但是佔用空間還是1KB)
- 我們在讀取HDFS上檔案的時候,NameNode會去尋找block地址,定址時間為傳輸時間的1%時,則為最佳狀態。
- 目前磁碟的傳輸速度普遍為100MB/S
- 如果定址時間約為10ms,則傳輸時間=10ms/0.01=1000ms=1s
- 如果傳輸時間為1S,傳輸速度為100MB/S,那麼一秒鐘我們就可以向HDFS傳送100MB檔案,設定塊大小128M比較合適。
- 如果頻寬為200MB/S,那麼可以將block塊大小設定為256M比較合適。
- Namenode(master管理者)
- 管理HDFS的檔案樹及名稱空間
- 資料複製策略
- 管理資料塊(Block)的對映資訊
- 處理客戶端讀寫請求。
- Datanode(slave實際操作者)
- 儲存實際的資料塊
- 執行資料塊的讀寫請求
- Client(客戶端)
- 檔案切分,上傳HDFS時,將檔案切分成一個一個Block,然後進行上傳。
- 與Namenode互動,獲取檔案位置資訊。
- 與Datanode互動,讀取或者寫入資料。
- 提供API來管理HDFS。
- SecondaryNameNode
- 並非是NameNode的熱備,當NameNode掛掉的時候,它並不能馬上替換NameNode並提供服務。
- 輔助NameNode,比如根據檢查點,定期合併Fsimage和Edits,並推送給NameNode。
1.5 所處角色
2 HDFS物理網路環境(叢集結構)
- 比較重要服務功能最好能部署在不同的節點上,如:NN。
- 不重要的可以在一個節點上,如:DN。
- 副本選擇機制:當副本為3的時候,第一個為本地最近的節點,第二個為同機架的不同節點,第三個為不同機架的不同節點。
3 HDFS 讀寫工作原理
3.1 HDFS檔案寫入流程
- 客戶端建立 DistributedFileSystem 物件.
- DistributedFileSystem 物件呼叫元資料節點,在檔案系統的名稱空間中建立一個新的檔案,元資料節點首先確定檔案原來不存在,並且客戶端有建立檔案的許可權,然後建立新檔案,並標識為“上傳中”狀態,即可以看見,但不能使用。
- DistributedFileSystem 返回 DFSOutputStream,客戶端用於寫資料。
- 客戶端開始寫入資料,DFSOutputStream 將資料分成塊,寫入 data queue(Data queue 由 Data Streamer 讀取),並通知元資料節點分配資料節點,用來儲存資料塊(每塊預設複製 3 塊)。分配的資料節點放在一個 pipeline 裡。Data Streamer 將資料塊寫入 pipeline 中的第一個資料節點。第一個資料節點將資料塊傳送給第二個資料節點。第二個資料節點將資料傳送給第三個資料節點。注意:並不是第一個資料節點完全接收完 block 後再發送給後面的資料節點,而是接收到一部分 就傳送,所以三個節點幾乎是同時接收到完整的 block 的。DFSOutputStream 為發出去的資料塊儲存了 ack queue,等待 pipeline 中的資料節點告知資料已經寫入成功。如果 block 在某個節點的寫入的過程中失敗:關閉 pipeline,將 ack queue 放 至 data queue 的開始。已經寫入節點中的那些 block 部分會被元資料節點賦予新 的標示,發生錯誤的節點重啟後能夠察覺其資料塊是過時的,會被刪除。失敗的節點從 pipeline 中移除,block 的其他副本則寫入 pipeline 中的另外兩個資料節點。元資料節點則被通知此 block 的副本不足,將來會再建立第三份備份。
- ack queue 返回成功。
- 客戶端結束寫入資料,則呼叫 stream 的 close 函式,
- 最後通知元資料節點寫入完畢
總結:
客戶端切分檔案 Block,按 Block 線性地和 NN 獲取 DN 列表(副本數),驗證 DN 列表後以更小的單位流式傳輸資料,各節點兩兩通訊確定可用,Block 傳輸結束後,DN 向 NN 彙報 Block 資訊,DN 向 Client 彙報完成,Client 向 NN 彙報完成,獲取下一個 Block 存放的 DN 列表,最終 Client 彙報完成,NN 會在寫流程更新檔案狀態。
3.2 HDFS檔案讀取流程
- 客戶端(client)用 FileSystem 的 open()函式開啟檔案。
- DistributedFileSystem 呼叫元資料節點,得到檔案的資料塊資訊。對於每一個數據塊,元資料節點返回儲存資料塊的資料節點的地址。
- DistributedFileSystem 返回 FSDataInputStream 給客戶端,用來讀取資料。
- 客戶端呼叫 stream 的 read()函式開始讀取資料(也會讀取 block 的元資料)。DFSInputStream 連線儲存此檔案第一個資料塊的最近的資料節點(優先讀取同機架的 block)。
- Data 從資料節點讀到客戶端。當此資料塊讀取完畢時,DFSInputStream 關閉和此資料節點的連線,然後連線此檔案下一個資料塊的最近的資料節點。
- 當客戶端讀取完畢資料的時候,呼叫 FSDataInputStream 的 close 函式。
- 在讀取資料的過程中,如果客戶端在與資料節點通訊出現錯誤,則嘗試連線包含此資料塊的下一個資料節點。失敗的資料節點將被記錄,以後不再連線。
總結:
客戶端和 NN 獲取一部分 Block(獲取部分 block 資訊,而不是整個檔案全部的 block 信 息,讀完這部分 block 後,再獲取另一個部分 block 的資訊)副本位置列表,線性地和 DN 獲取 Block,最終合併為一個檔案,在 Block 副本列表中按距離擇優選取,如果選取到的副本完整就返回,否則找下一個副本。
4 深入
4.1 NameNode和SecondaryNameNode
- 作用:
- Namespace管理:負責管理檔案系統中的樹狀目錄結構以及檔案與資料塊的對映關係
- 塊資訊管理:負責管理檔案系統中檔案的物理塊與實際儲存位置的對映關係BlocksMap
- 叢集資訊管理:機架資訊,datanode資訊
- 集中式快取管理:從Hadoop2.3 開始,支援datanode將檔案快取到記憶體中,這部分快取通過NN集中管理
- 儲存結構:
- 記憶體: Namespace資料,BlocksMap資料,其他資訊
- 檔案:
- 已持久化的namespace資料:FsImage
- 未持久化的namespace操作:Edits
合併流程:
- NN 建立一個新的 edits log 來接替老的 edits 的工作
- NN 將 fsimage 和舊的 edits 拷備到 SNN 上
- SNN 上進行合併操作,產生一個新的 fsimage
- 將新的 fsimage 複製一份到 NN 上
- 使用新的 fsimage 和新的 edits log
4.2 叢集啟動過程
開啟安全模式:不能執行資料修改操作
載入fsimage
逐個執行所有Edits檔案中的每一條操作將操作合併到fsimage,完成後生成一個空的edits檔案
接收datanode傳送來的心跳訊息和塊資訊
根據以上資訊確定檔案系統狀態
退出安全模式
4.3 安全模式
- 安全模式:檔案系統只接受讀資料請求,而不接受刪除、修改等變更請求
- 什麼情況下進入:NameNode主節點啟動時,HDFS進入安全模式
- 什麼時候時候退出:系統達到安全標準時,HDFS退出安全模式
- dfs.namenode.safemode.min.datanodes: 最小可用datanode數量
- dfs.namenode.safemode.threshold-pct: 副本數達到最小要求的block佔系統總檔案block數的百分比
- 總檔案block數100個,每個block需要有3個副本,滿足3個副本的block數量為70個,那麼pct=70%(預設0.999)
- 常見進入安全模式不退出就是因為學習機器不夠,副本數低於3,這個引數進行驗證不通過。
- dfs.namenode.safemode.extension: 穩定時間
- 相關命令:
- hdfs dfsadmin -safemode get:檢視當前狀態
- hdfs dfsadmin -safemode enter:進入安全模式
- hdfs dfsadmin -safemode leave:強制離開安全模式
- hdfs dfsadmin -safemode wait:一直等待直到安全模式結束
5 HDFS Federation (聯邦)
通過多個 namenode/namespace 把元資料的儲存和管理分散到多個節點中,使到namenode/namespace 可以通過增加機器來進行水平擴充套件。能把單個 namenode 的負載分散到多個節點中,在 HDFS 資料規模較大的時候不會也降低 HDFS 的效能。可以通過多個namespace 來隔離不同型別的應用,把不同型別應用的 HDFS 元資料的儲存和管理分派到不同的 namenode 中。核心:多臺 namenode 管理的是同一個叢集!
假設伺服器記憶體:128G=137438953472位元組 ,一個塊大概使用150位元組,那麼可以儲存的塊數量為:916259689g個,因為一個預設塊大小為128M,那麼可以儲存的檔案大小為109PB左右,遠遠達不到大資料的規模(目前有些大公司能達到一臺NameNode管理上EB的資料),這個時候就需要Federation(聯邦),多個NameNode管理一套叢集。
6 HDFS HA(High Availability高可用)
6.1 高可用架構圖
- 主備 NameNode,解決單點故障:
- ANN:ActiveNameNode,對外提供服務,SNN 同步 ANN 元資料,以待切換。
- SNN:StandbyNameNode,完成了 edits.log 檔案的合併產生新的 image,推送回 ANN。
- JNN:JournalNode,ANN 和 SNN 通過 JNN 叢集來共享資訊。兩個 NameNode 為了資料同步,會通過一組稱作 JournalNodes 的獨立程序進行相互通訊。當 ANN 的名稱空間有任何修改時,會告知大部分的 JournalNodes 程序。SNN 有能力讀取 JNs 中的變更資訊,並且一直監控 edit log 的變化,把變化應用於自己的名稱空間。SNN 可以確保在叢集出錯時,名稱空間狀態已經完全同步了。在 HA 架構裡面 SecondaryNameNode 這個冷備角色已經不存在了,為了保持 SNN 實時的與 ANN 的元資料保持一致,他們之間互動通過一系列守護的輕量級程序 JournalNode。基本原理就是用 2N+1 臺 JN 儲存 editlog,每次寫資料操作有超過 半數(>=N+1)返回成功時即認為該次寫成功,資料不會丟失了。當然這個演算法所能容忍 的是最多有 N 臺機器掛掉,如果多於 N 臺掛掉,這個演算法就失效了。任何修改操作在 ANN上執行時,JN 程序同時也會記錄修改 log 到至少半數以上的 JN 中,這時 SNN 監測到 JN 裡面的同步 log 發生變化了會讀取 JN 裡面的修改 log,然後同步到自己的的目錄映象樹裡面。當發生故障時,ANN 掛掉後,SNN 會在它成為 ANN 前,讀取所有的 JN 裡面的修改日誌,這樣就能高可靠的保證與掛掉的 NN 的目錄映象樹一致,然後無縫的接替它的職責,維護來自客戶端請求,從而達到一個高可用的目的。
- DN:同時向兩個 NameNode 彙報資料塊資訊(位置)。
- 兩個 NN 之間的切換:
- 手動切換:通過命令實現主備之間的切換,可以用 HDFS 升級等場合。
- 自動切換:基於 Zookeeper 實現。
- HDFS 2.x 提供了 ZookeeperFailoverController 角色,部署在每個 NameNode 的節點上,作為一個 deamon 程序, 簡稱 zkfc,zkfc 主要包括三個元件:
- HealthMonitor:監控 NameNode 是否處於 unavailable 或 unhealthy 狀態。當前通過RPC 呼叫 NN 相應的方法完成。
- ActiveStandbyElector:管理和監控自己在 ZK 中的狀態。
- ZKFailoverController:它訂閱 HealthMonitor 和 ActiveStandbyElector 的事件,並管理NameNode 的狀態。
- 簡稱ZKFC,就是Zookeeper客戶端。
- ZKFailoverController 主要職責:
- 健康監測:週期性的向它監控的 NN 傳送健康探測命令,從而來確定某個NameNode 是否處於健康狀態,如果機器宕機,心跳失敗,那麼 zkfc 就會標記它處於一個不健康的狀態
- 會話管理:如果 NN 是健康的,zkfc 就會在 zookeeper 中保持一個開啟的會話,如果 NameNode 同時還是 Active 狀態的,那麼 zkfc 還會在 Zookeeper 中佔有一個型別為短暫型別的 znode,當這個 NN 掛掉時,這個 znode 將會被刪除,然後備用的NN,將會得到這把鎖,升級為主 NN,同時標記狀態為 Active,當宕機的 NN 新啟動時,它會再次註冊 zookeper,發現已經有 znode 鎖了,便會自動變為 Standby狀態,如此往復迴圈,保證高可靠,需要注意,目前僅僅支援最多配置 2 個 NN.
- master 選舉:如上所述,通過在 zookeeper 中維持一個短暫型別的 znode,來實現搶佔式的鎖機制,從而判斷那個 NameNode 為 Active 狀態。
6.2 故障轉移流程
- 上圖注意:SecondaryNameNode被另一臺NameNode取代,edits檔案交由qjournal管理。
6.3 CM配置HA注意點:
cdh01.com--------
QuorumPeerMain(zk)
DFSZKFailoverController
NameNode
JournalNode
cdh02.com--------
QuorumPeerMain(zk)
DFSZKFailoverController
JournalNode
DataNode
cdh03.com--------
QuorumPeerMain(zk)
JournalNode
DataNode
7 HDFS糾刪碼(時間換空間)
hdfs3.0後引入糾刪碼
- 複製策略:1tb資料,需要3tb磁碟空間
糾刪碼:只需要複製策略一半左右的磁碟空間,而且同樣可以保證資料的可靠性
a=1
b=2
c=3
a+b+c=6
a+2b+3c=14
a+3b+4c=19
我們需要求出a,b,c的值,那麼最少需要的方程數為?3個
如果有4個方程,就允許丟失任意一個方程
如果有5個方程,就允許丟失任意兩個方程
a=1
b=2
c=3
視為資料
a+b+c=6
a+2b+3c=14
a+3b+4c=19
視為一個效驗/沉餘數據
如果是複製策略,要允許丟失任意2份資料,我們需要3*3=9份空間
如果是究刪碼策略,要允許丟失任意2份資料,我們需要3+2=5份空間
8 HDFS檔案型別
檔案格式 | 型別 | 儲存方式 | 是否帶schema | 特點描述 | 出處 |
---|---|---|---|---|---|
txt,json,csv | 行式 | 文字 | 否 | 預設儲存方式(txt),資料內容可以直接cat檢視,儲存效率較高,處理效率低。壓縮比較低 | Hadoop |
Sequence file | 行式 | 二進位制 | 是 | 以key,value對的方式儲存。壓縮比中等 | Hadoop |
Avro | 行式 | 二進位制 | 是 | 資料序列化框架,同時支援RPC,資料自帶schema,支援比較豐富的資料型別。與protobuf, thrift 類似。壓縮比中等 | Hadoop |
RC(record columnar) | 列式 | 二進位制 | 是 | 列式儲存,將資料按照行組分塊,讀取以行組為單位,但是行組中可以跳過不需要的列。壓縮比中等 | Hive |
ORC(optimized record columnar) | 列式 | 二進位制 | 是 | 升級版的RC,使用了更優化的儲存結構,從而獲得更好的效能,另外支援對資料的修改和ACID。壓縮比高 | Hive |
Parquet | 列式 | 二進位制 | 是 | 支援巢狀型別,可高效實現對列的查詢或統計。壓縮比高 | Impala |
9 資料壓縮型別
壓縮格式 | split | 壓縮率 | 壓縮速度 | 是否 hadoop自帶 | linux命令 | 換成壓縮格式後,原來的應用程式是否要修改 | 使用建議 |
---|---|---|---|---|---|---|---|
gzip | 否 | 很高 | 比較快 | 是 | 有 | 和文字處理一樣,不需要修改 | • 使用方便 • 當每個檔案壓縮之後在130M以內的(1個塊大小內),都可以考慮用gzip壓縮格式 |
lzo | 是 | 比較高 | 很快 | 否,需要安裝 | 有 | 需要建索引,還需要指定輸入格式 | • 壓縮率和壓縮速度綜合考慮 • 支援split,是hadoop中最流行的壓縮格式; • 一個很大的文字檔案,壓縮之後還大於200M以上的可以考慮,而且單個檔案越大,lzo優點越明顯 • cloudera&twitter |
snappy | 否 | 比較高 | 很快 | 否,需要安裝 | 沒有 | 和文字處理一樣,不需要修改 | • 壓縮率和壓縮速度綜合考慮 • 當mapreduce作業的map輸出的資料比較大的時候,作為map到reduce的中間資料的壓縮格式 • spark預設壓縮格式 • google出品 |
bzip2 | 是 | 最高 | 慢 | 是 | 有 | 和文字處理一樣,不需要修改 | • 壓縮率高 • 適合對速度要求不高,但需要較高的壓縮率,比如資料比較大,需要壓縮存檔減少磁碟空間並且以後資料用得比較少的情況 |
10 HDFS常用命令
-help
:輸出這個命令引數。如:hadoop fs -help ls (輸出ls命令的引數)-ls
:顯示目錄資訊。如:hadoop fs -ls / (查詢hdfs上根目錄的目錄,,遞迴建立加 -R引數)-mkdir
:在hdfs上建立目錄。如:hadoop fs -mkdir /haha (根目錄下建立haha資料夾,遞迴建立加 -p引數)-moveFromLocal
:從本地剪下貼上到hdfs。如:hadoop fs -moveFromLocal /haha/xixi.txt / (將本地haha資料夾下的xixi.txt檔案剪下貼上到hdfs的根目錄下)-copyFromLocal
:從本地拷貝到hdfs上。如:用法同上-copyToLocal
:從hdfs上拷貝到本地。如:用法同上-cp:從hdfs
的一個路徑拷貝到hdfs的另一個路徑。如:方法同上-mv
:從hdfs上的一個路徑移動到hdfs的另一個路徑。如:方法同上-appendToFile
:追加一個檔案到已經存在的檔案末尾。如:hadoop fs -appendToFile /haha/lala.txt /xixi.txt (將本地lala.txt檔案內容追加到hdfs上xixi.txt裡)-cat
:顯示檔案內容。如:hadoop fs -cat /xixi.txt (檢視xixi.txt)-tail
:顯示一個檔案的末尾。-chmod
:修改檔案許可權。如:hadoop fs -chmod 777 /xixi.txt (修改xixi.txt檔案的許可權)-get
:等同於copyToLocal,就是從hdfs下載檔案到本地。如:hadoop fs -get /xixi.txt ./ (下載到當前本地路徑)-getmerge
:合併下載多個檔案,如:hadoop fs -getmerge /log/*.txt ./sum.txt (將hdfs上log資料夾下的所有.txt檔案整合在一起,下載到本地,名字為sum.txt)-put
:等同於copyFromLocal,就是上傳檔案到hdfs。如:hadoop fs -put /xixi.txt / (上傳到hdfs的根路徑)-rmr
:刪除檔案或目錄-df
:統計檔案系統的可用空間資訊。如:hadoop fs -df -h /-du
:統計資料夾的大小資訊。如:-s總大小、-h單位-count
:統計一個指定目錄下的檔案節點數。如:結果2 2 199 (第一個引數說的是最多有幾級目錄,第二個引數說的是一共有多少檔案)
11 HDFS SHELL操作
11.1 hdfs常用基礎命令
- 幫助:hadoop fs -help
- 檢視結構:hdfs dfs -ls [/檢視目錄名稱]
- 上傳:hdfs dfs -put [檔案] [/上傳目錄名稱]
- 拷貝:hdfs dfs -cp [原始檔名] [目標檔名]
- 檢視檔案:hdfs dfs -cat [檔名]
- 刪除:hdfs dfs -rmr [檔案]
- 修改許可權(同linux):hdfs dfs -chmod [許可權級別] [檔案]
- 檢視硬碟:hdfs dfs -df -h
- 檢視每個檔案佔用大小:hdfs dfs -du -h [目錄]
11.2 本地->HDFS命令
- 上傳:hdfs dfs -put [檔案] [/上傳目錄名稱]
- 上傳(同put):hdfs dfs -copyFromLocal [檔案] [/上傳目錄名稱]
- 剪下上傳:hdfs dfs -moveFromLocal [檔案] [/上傳目錄名稱]
- 追加:hdfs dfs -appendToFile [原始檔] [/需要追加的檔案]
11.3 HDFS->本地命令
- 下載:hdfs dfs -get [/HDFS原始檔] [本地路徑]
- 下載(同get):hdfs dfs -copyToLocal [/HDFS原始檔] [本地路徑]
- 合併下載:hdfs dfs -getmerge [/HDFS原始檔] [本地檔名]
11.4 合併小檔案
- 打包:hadoop archive -archiveName [har包名稱] -p [/需要打包檔案] [/打包檔案存放地址]
- 檢視包:hdfs dfs -ls har://[har包檔案]
12 windows 大資料開發環境配置
- 下載winutils解壓
- 配置對應版本的環境變數名為:HADOOP_HOME 值為:解壓目錄如上F:\bigdatasoft\hadoop\winutils-master\hadoop-3.0.0
- 環境變數Path新增:%HADOOP_HOME%\bin
- 重啟電腦,開啟cmd,輸入winutils,出現下圖證明配置成功
-
13 基本API使用
專案地址:https://github.com/70416450/Bigdata-Util
- 修改hdfs.properties中的配置資訊
- 使用單元測試類測試每一個API吧。