⑴ HDFS 上的文件支持修改操作嗎若支持，如何修改hdfs文件
看來你是開啟了hdfs的許可權檢查功能，這樣你訪問hdfs，namenode都會檢查訪問用戶的許可權的。
你現在想要修改/process/startall.txt文件的許可權，那process目錄以及startall.txt的有效用戶、有效組以及其許可權是什麼呢？
假設process目錄與startall.txt原始的有效用戶和有效組分別為root和supergroup，原始許可權為750的話，你若在自己電腦運行上述程序，它會自動獲取當前計算機的登錄用戶，假設為wyc,去訪問hdfs，很顯然，你的程序連process目錄都進不去的。
此外，想要更改一個目錄或文件的許可權，當前用戶則必須是有效用戶或超級用戶才可以。
想要解決的話，嘿嘿， 如果你設置的hadoop.security.authentication property，也就是認證方式為simple的話（默認就是simple），那還可以鑽該認證方式的空子，運行程序是偽裝成有效用戶或者超級用戶即可。
此外，有一行代碼需要修改一下，我在實驗後發現設置許可權那一行有誤，如下：
//hdfs.setpermission(dstpath, new fspermission((short) 775));
hdfs.setpermission(dstpath, new fspermission("755"));
⑵ HDFS和本地文件系統文件互導
初步了解一下情況，後續根據給出案例
一、從本地文件系統到HDFS
使用hdfs自帶的命令
命令：hdfs dfs -FromLocal inputPath outputPath
inputPath：本地文件目錄的路徑
outputPath：hdfs文件目錄路徑，即存儲路徑
二、從HDFS到本地文件系統
命令：hdfs dfs -ToLocal inputPath outputPath
inputPath：hdfs文件目錄
outputPath：本地文件文件目錄，即本地存儲路徑
因為Hbas和Hive都在存儲在HDFS中，所以可以通過該條命令可以把Hbase和Hive存儲在HDFS中的文件復制出來。但是經過實踐，通過這種方式復制出來的Hbase文件是亂碼。Hive里的文件有時候也會亂碼，這取決於Hive數據的插入方式。
三、文件在HDFS內的移動
1、從Hbase表導出數據到HDFS
命令：hbase org.apache.hadoop.hbase.maprece.Export tableName outputPaht
例子：hbase org.apache.hadoop.hbase.maprece.Export test /user/data
test為需要從Hbase中導出的表，／user/data為hdfs上的路徑，即存儲路徑，如果最後一個參數有前綴file：// 則為本地上的文件存儲系統
2、從HDFS導入到Hbase表中，需要事先建立好表結構
命令：hbase org.apache.hadoop.hbase.maprece.Export tableName inputPaht
例子：hbase org.apache.hadoop.hbase.maprece.Import test1 /temp/part-m-00000
案列：
兩個不同環境數據，數據導入
過程描述：
導出正式環境數據到hdfs中，然後從hdfs中導出到本地，本地傳到測試環境主機，然後從本地導入到hdfs中，再從hdfs中導入到hbase中。
處理過程：
1、注意事項：1、許可權問題使用hdfs：sudo -u hdfs ；
2、存放上傳路徑最好不要在root下
3、上傳完成後，查看是否在使用，數據已經插入。
1、sudo -u hdfs hbase org.apache.hadoop.hbase.maprece.Export ** /hbase/**_bak （導出到hdfs中的**_bak）
2、hdfs dfs -ToLocal /hbase/sw_bak /test (導出hdfs中文件到本地test，註：提前建好目錄)
3、scp -r test_bak [email protected].**:/root/test （傳送目錄到測試環境主機目錄下，註：傳到測試環境後，把文件不要放到root的目錄下，換家目錄下）
4、sudo -u hdfs hdfs dfs -FromLocal /chenzeng/text_bak /data （把sw傳到hdfs 中，注意上傳時，文件路徑要對，放在data路徑下比較好）
5、sudo -u hdfs hbase org.apache.hadoop.hbase.maprece.Import test /data/test_bak/part-m-0000 （注意上次文件）
6、在hbase shell 中查看test ：count 'test' 確認是否上傳成功
優化：
truncate 『』
正式環境導入至hdfs中時，
可以直接在另一個環境的執行sudo -u hdfs hbase org.apache.hadoop.hbase.maprece.Import test hdfs://server243:8020/hbase**** 可以直接加主機和對應路徑進行put。
⑶ 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、不支持用戶的並行寫：同一時間內，只能有一個用戶執行寫操作。
⑷ HDFS 上的文件支持修改操作嗎若支持，如何修改hdfs文件
當前穩定版本的hdfs(1.1.2)不支持文件的修改操作，要修改文件只能先把文件從hdfs拷貝到本地硬碟，修改後刪除hdfs里的文件，上傳修改後的文件到hdfs。
⑸ 如何把hdfs上的多個目錄下的文件合並為一個文件
hdfs dfs -cat /folderpath/folder* | hdfs dfs -FromLocal - /newfolderpath/file
1
1
這樣可以把文件hdfs上 /folderpath目錄下的/folder開頭的文件，還不合並到/newfolderpath目錄下的file一個文件中 注意/folder*必須是文件，而不能是文件夾，如果是文件夾，可以/folder*/*
cat test.txt | ssh test@masternode "hadoop dfs -put - hadoopFoldername/"
1
1
可以這樣把本機的文件put到HDFS上面，而不用先復制文件到集群機器上
⑹ 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和數據交換。
⑺ 「HDFS 採用數據流方式來訪問文件，只支持單個客戶端向一個文件追加數據」是什麼意思啊
上半句話，訪問文件不外乎讀和寫，需要讀寫時調用函數FileSystem&open()和FileSystem&create()，返回的對象是FSDataInputStream和FSDataOutputStream。 data直譯成中文就是數據，stream直譯成中文就是流。 這兩個對象分別繼承於java.io.DataInputStream和java.io.DataOutputStream， 是java的常用的文件讀寫類。 需要讀時用DataInputStream的函數readInt(), readFloat()...，寫時也差不多。
下半句話，兩個關鍵詞， 」單個客戶「和」追加「。單個客戶指不能有兩個線程同時寫；追加指寫的形式只能是在文件後加內容(append)，不能覆蓋(overwrite)。 這兩個限制都是設計上簡化考慮。 多個線程同時append時，由於hdfs是一份文件存於多個機器，保證在每台機器上兩個線程寫的順序一致(從而結果一致)是一個很難的問題（當然不是做不到）， 出於簡單考慮， 就不這么做了。 多個線程同時overwrite就更麻煩。
⑻ 什麼是HDFS
Hadoop分布式文件系統(HDFS)是指被設計成適合運行在通用硬體(commodity hardware)上的分布式文件系統（Distributed File System）。它和現有的分布式文件系統有很多共同點。但同時，它和其他的分布式文件系統的區別也是很明顯的。HDFS是一個高度容錯性的系統，適合部署在廉價的機器上。HDFS能提供高吞吐量的數據訪問，非常適合大規模數據集上的應用。HDFS放寬了一部分POSIX約束，來實現流式讀取文件系統數據的目的。HDFS在最開始是作為Apache Nutch搜索引擎項目的基礎架構而開發的。HDFS是Apache Hadoop Core項目的一部分。
HDFS有著高容錯性（fault-tolerant）的特點，並且設計用來部署在低廉的（low-cost）硬體上。而且它提供高吞吐量（high throughput）來訪問應用程序的數據，適合那些有著超大數據集（large data set）的應用程序。HDFS放寬了（relax）POSIX的要求（requirements）這樣可以實現流的形式訪問（streaming access）文件系統中的數據。