大資料篇：HDFS
阿新 • • 發佈：2020-02-17
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吧。