Ⅰ 用java向hdfs上傳文件時，如何實現斷點續傳
@Component("javaLargeFileUploaderServlet")
@WebServlet(name = "javaLargeFileUploaderServlet", urlPatterns = { "/javaLargeFileUploaderServlet" })
public class UploadServlet extends HttpRequestHandlerServlet
implements HttpRequestHandler {
private static final Logger log = LoggerFactory.getLogger(UploadServlet.class);
@Autowired
UploadProcessor uploadProcessor;
@Autowired
FileUploaderHelper fileUploaderHelper;
@Autowired
ExceptionCodeMappingHelper exceptionCodeMappingHelper;
@Autowired
Authorizer authorizer;
@Autowired
StaticStateIdentifierManager staticStateIdentifierManager;
@Override
public void handleRequest(HttpServletRequest request, HttpServletResponse response)
throws IOException {
log.trace("Handling request");
Serializable jsonObject = null;
try {
// extract the action from the request
UploadServletAction actionByParameterName =
UploadServletAction.valueOf(fileUploaderHelper.getParameterValue(request, UploadServletParameter.action));
// check authorization
checkAuthorization(request, actionByParameterName);
// then process the asked action
jsonObject = processAction(actionByParameterName, request);
// if something has to be written to the response
if (jsonObject != null) {
fileUploaderHelper.writeToResponse(jsonObject, response);
}
}
// If exception, write it
catch (Exception e) {
exceptionCodeMappingHelper.processException(e, response);
}
}
private void checkAuthorization(HttpServletRequest request, UploadServletAction actionByParameterName)
throws MissingParameterException, AuthorizationException {
// check authorization
// if its not get progress (because we do not really care about authorization for get
// progress and it uses an array of file ids)
if (!actionByParameterName.equals(UploadServletAction.getProgress)) {
// extract uuid
final String fileIdFieldValue = fileUploaderHelper.getParameterValue(request, UploadServletParameter.fileId, false);
// if this is init, the identifier is the one in parameter
UUID clientOrJobId;
String parameter = fileUploaderHelper.getParameterValue(request, UploadServletParameter.clientId, false);
if (actionByParameterName.equals(UploadServletAction.getConfig) && parameter != null) {
clientOrJobId = UUID.fromString(parameter);
}
// if not, get it from manager
else {
clientOrJobId = staticStateIdentifierManager.getIdentifier();
}
// call authorizer
authorizer.getAuthorization(
request,
actionByParameterName,
clientOrJobId,
fileIdFieldValue != null ? getFileIdsFromString(fileIdFieldValue).toArray(new UUID[] {}) : null);
}
}
private Serializable processAction(UploadServletAction actionByParameterName, HttpServletRequest request)
throws Exception {
log.debug("Processing action " + actionByParameterName.name());
Serializable returnObject = null;
switch (actionByParameterName) {
case getConfig:
String parameterValue = fileUploaderHelper.getParameterValue(request, UploadServletParameter.clientId, false);
returnObject =
uploadProcessor.getConfig(
parameterValue != null ? UUID.fromString(parameterValue) : null);
break;
case verifyCrcOfUncheckedPart:
returnObject = verifyCrcOfUncheckedPart(request);
break;
case prepareUpload:
returnObject = prepareUpload(request);
break;
case clearFile:
uploadProcessor.clearFile(UUID.fromString(fileUploaderHelper.getParameterValue(request, UploadServletParameter.fileId)));
break;
case clearAll:
uploadProcessor.clearAll();
break;
case pauseFile:
List<UUID> uuids = getFileIdsFromString(fileUploaderHelper.getParameterValue(request, UploadServletParameter.fileId));
uploadProcessor.pauseFile(uuids);
break;
case resumeFile:
returnObject =
uploadProcessor.resumeFile(UUID.fromString(fileUploaderHelper.getParameterValue(request, UploadServletParameter.fileId)));
break;
case setRate:
uploadProcessor.setUploadRate(UUID.fromString(fileUploaderHelper.getParameterValue(request, UploadServletParameter.fileId)),
Long.valueOf(fileUploaderHelper.getParameterValue(request, UploadServletParameter.rate)));
break;
case getProgress:
returnObject = getProgress(request);
break;
}
return returnObject;
}
List<UUID> getFileIdsFromString(String fileIds) {
String[] splittedFileIds = fileIds.split(",");
List<UUID> uuids = Lists.newArrayList();
for (int i = 0; i < splittedFileIds.length; i++) {
uuids.add(UUID.fromString(splittedFileIds[i]));
}
return uuids;
}
private Serializable getProgress(HttpServletRequest request)
throws MissingParameterException {
Serializable returnObject;
String[] ids =
new Gson()
.fromJson(fileUploaderHelper.getParameterValue(request, UploadServletParameter.fileId), String[].class);
Collection<UUID> uuids = Collections2.transform(Arrays.asList(ids), new Function<String, UUID>() {
@Override
public UUID apply(String input) {
return UUID.fromString(input);
}
});
returnObject = Maps.newHashMap();
for (UUID fileId : uuids) {
try {
ProgressJson progress = uploadProcessor.getProgress(fileId);
((HashMap<String, ProgressJson>) returnObject).put(fileId.toString(), progress);
}
catch (FileNotFoundException e) {
log.debug("No progress will be retrieved for " + fileId + " because " + e.getMessage());
}
}
return returnObject;
}
private Serializable prepareUpload(HttpServletRequest request)
throws MissingParameterException, IOException {
// extract file information
PrepareUploadJson[] fromJson =
new Gson()
.fromJson(fileUploaderHelper.getParameterValue(request, UploadServletParameter.newFiles), PrepareUploadJson[].class);
// prepare them
final HashMap<String, UUID> prepareUpload = uploadProcessor.prepareUpload(fromJson);
// return them
return Maps.newHashMap(Maps.transformValues(prepareUpload, new Function<UUID, String>() {
public String apply(UUID input) {
return input.toString();
};
}));
}
private Boolean verifyCrcOfUncheckedPart(HttpServletRequest request)
throws IOException, MissingParameterException, FileCorruptedException, FileStillProcessingException {
UUID fileId = UUID.fromString(fileUploaderHelper.getParameterValue(request, UploadServletParameter.fileId));
try {
uploadProcessor.verifyCrcOfUncheckedPart(fileId,
fileUploaderHelper.getParameterValue(request, UploadServletParameter.crc));
}
catch (InvalidCrcException e) {
// no need to log this exception, a fallback behaviour is defined in the
// throwing method.
// but we need to return something!
return Boolean.FALSE;
}
return Boolean.TRUE;
}
}
Ⅱ hdfs 上傳文件 ioutils 和fromlocalfile 有什麼區別
ystem.FromLocalFile(boolean delSrc, boolean overwrite, Path[] srcs, Path dst)等通過FileSystem操作文件的所以就追蹤了一下FileSystem.FromLocalFile的執行過程。
[java] view plain
<span style="font-size:18px;"> public void FromLocalFile(boolean delSrc, boolean overwrite,
Path src, Path dst)
throws IOException {
Configuration conf = getConf();
FileUtil.(getLocal(conf), src, this, dst, delSrc, overwrite, conf);
}</span>
//調用了 FileUtil.(),進到這個()里：
[java] view plain
<span style="font-size:18px;"> public static boolean (FileSystem srcFS, Path src, FileSystem dstFS, Path dst, boolean deleteSource,
boolean overwrite, Configuration conf) throws IOException {
FileStatus fileStatus = srcFS.getFileSt
Ⅲ hadoop 本地文件上傳到 hdfs 失敗
看著像是datanode出問題了，你去master的50070埠看看datanode是否全部正常啟動。
Ⅳ 關於用java寫程序把本地文件上傳到HDFS中的問題
將這FileSystem hdfs = FileSystem.get(config);
改成FileSystem hdfs = FileSystem.get(URI.create("hdfs://master:9000"),config)
上面那句取得的是本地文件系統對象，改成下面這個才是取得hdfs文件系統對象，當你要操作本地文件對象的時候就要用上面那句取得本地文件對象，我在2.7.4剛開始也是跟你一樣的錯誤，改為下面的就可以了
Ⅳ 如何實現讓用戶在網頁中上傳下載文件到HDFS中
hadoop計算需要在hdfs文件系統上進行，文件上傳到hdfs上通常有三種方法：a hadoop自帶的dfs服務，put；b hadoop的API，Writer對象可以實現這一功能；c 調用OTL可執行程序，數據從資料庫直接進入hadoop
hadoop計算需要在hdfs文件系統上進行，因此每次計算之前必須把需要用到的文件(我們稱為原始文件)都上傳到hdfs上。文件上傳到hdfs上通常有三種方法：
a hadoop自帶的dfs服務，put；
b hadoop的API，Writer對象可以實現這一功能；
c 調用OTL可執行程序，數據從資料庫直接進入hadoop
由於存在ETL層，因此第三種方案不予考慮
將a、b方案進行對比，如下：
1 空間：方案a在hdfs上佔用空間同本地，因此假設只上傳日誌文件，則保存一個月日誌文件將消耗掉約10T空間，如果加上這期間的各種維表、事實表，將佔用大約25T空間
方案b經測試，壓縮比大約為3~4:1，因此假設hdfs空間為100T，原來只能保存約4個月的數據，現在可以保存約1年
2 上傳時間：方案a的上傳時間經測試，200G數據上傳約1小時
方案b的上傳時間，程序不做任何優化，大約是以上的4~6倍，但存在一定程度提升速度的餘地
3 運算時間：經過對200G數據，大約4億條記錄的測試，如果程序以IO操作為主，則壓縮數據的計算可以提高大約50%的速度，但如果程序以內存操作為主，則只能提高5%~10%的速度
4 其它：未壓縮的數據還有一個好處是可以直接在hdfs上查看原始數據。壓縮數據想看原始數據只能用程序把它導到本地，或者利用本地備份數據
壓縮格式：按照hadoop api的介紹，壓縮格式分兩種：BLOCK和RECORD,其中RECORD是只對value進行壓縮，一般採用BLOCK進行壓縮。
對壓縮文件進行計算，需要用SequenceFileInputFormat類來讀入壓縮文件，以下是計算程序的典型配置代碼：
JobConf conf = new JobConf(getConf(), log.class);
conf.setJobName(」log」);
conf.setOutputKeyClass(Text.class);//set the map output key type
conf.setOutputValueClass(Text.class);//set the map output value type
conf.setMapperClass(MapClass.class);
//conf.setCombinerClass(Rece.class);//set the combiner class ,if havenot, use Recuce class for default
conf.setRecerClass(Rece.class);
conf.setInputFormat(SequenceFileInputFormat.class);//necessary if use compress
接下來的處理與非壓縮格式的處理一樣
Ⅵ java調用hadoop api向hdfs上傳文件問題
var baseText3=null
function srsd(){
var popUp3=document.getElementById("popupcontent3");
popUp3.style.top="";
popUp3.style.left="";
if (baseText3==null){
baseText3=popUp3.innerHTML;
popUp3.innerHTML=baseText3+"<div id=\"statusbar3\"><a onclick=\"hidePopup3();\">
</a></div>";
}
Ⅶ java用org.apache.hadoop.fs 這個api向hdfs上傳文件是根據什麼協議
HTTP是很常見的協議，雖然用得很多，但對細節的了解卻是很淺，這回通過向服務端上傳文件信息來理解細節。網路庫的選擇：1、WinHTTP是windows下常用的庫；2、CURL是廣受喜愛的開源庫。對於我來說，libcurl最大的優點是使用方便，可以把注意力更多的集中到業務層上，提高工作效率，避免重造輪子；缺點是略大（MD編譯有264KB，MT編譯有340KB），不像WinHTTP可以由windows操作系統集成。下邊展示如何使用這兩種網路庫實現表單POST文件。
Ⅷ hadoop上傳文件效率特別慢，怎麼解決
基於任何平台實現的雲盤系統，面臨的首要的技術問題就是客戶端上傳和下載效率優化問題。基於Hadoop實現的雲盤系統，受到Hadoop文件讀寫機制的影響，採用Hadoop提供的API進行HDFS文件系統訪問，文件讀取時默認是順序、逐block讀取；寫入時是順序寫入。
一、讀寫機制
首先來看文件讀取機制：盡管DataNode實現了文件存儲空間的水平擴展和多副本機制，但是針對單個具體文件的讀取，Hadoop默認的API介面並沒有提供多DataNode的並行讀取機制。基於Hadoop提供的API介面實現的雲盤客戶端也自然面臨同樣的問題。Hadoop的文件讀取流程如下圖所示：
使用HDFS提供的客戶端開發庫，向遠程的Namenode發起RPC請求；
Namenode會檢查要創建的文件是否已經存在，創建者是否有許可權進行操作，成功則會為文件創建一個記錄，否則會讓客戶端拋出異常；
當客戶端開始寫入文件的時候，開發庫會將文件切分成多個packets，並在內部以"data queue"的形式管理這些packets，並向Namenode申請新的blocks，獲取用來存儲replicas的合適的datanodes列表， 列表的大小根據在Namenode中對replication的設置而定。開始以pipeline（管道）的形式將packet寫入所有的replicas中。開發庫把packet以流的方式寫入第一個 datanode，該datanode把該packet存儲之後，再將其傳遞給在此pipeline中的下一個datanode，直到最後一個 datanode，這種寫數據的方式呈流水線的形式。
最後一個datanode成功存儲之後會返回一個ack packet，在pipeline里傳遞至客戶端，在客戶端的開發庫內部維護著"ack queue"，成功收到datanode返回的ack packet後會從"ack queue"移除相應的packet。
如果傳輸過程中，有某個datanode出現了故障，那麼當前的pipeline會被關閉，出現故障的datanode會從當前的 pipeline中移除，剩餘的block會繼續剩下的datanode中繼續以pipeline的形式傳輸，同時Namenode會分配一個新的 datanode，保持replicas設定的數量。
關鍵詞：開發庫把packet以流的方式寫入第一個datanode，該datanode將其傳遞給pipeline中的下一個datanode，知道最後一個Datanode，這種寫數據的方式呈流水線方式。
二、解決方案
1.下載效率優化
通過以上讀寫機制的分析，我們可以發現基於Hadoop實現的雲盤客戶段下載效率的優化可以從兩個層級著手：
1.文件整體層面：採用並行訪問多線程（多進程）份多文件並行讀取。
2.Block塊讀取：改寫Hadoop介面擴展，多Block並行讀取。
2.上傳效率優化
上傳效率優化只能採用文件整體層面的並行處理，不支持分Block機制的多Block並行讀取。
HDFS處理大量小文件時的問題
小文件指的是那些size比HDFS 的block size(默認64M)小的多的文件。如果在HDFS中存儲小文件，那麼在HDFS中肯定會含有許許多多這樣的小文件(不然就不會用hadoop了)。
而HDFS的問題在於無法很有效的處理大量小文件。
任何一個文件，目錄和block，在HDFS中都會被表示為一個object存儲在namenode的內存中，沒一個object佔用150 bytes的內存空間。所以，如果有10million個文件，
沒一個文件對應一個block，那麼就將要消耗namenode 3G的內存來保存這些block的信息。如果規模再大一些，那麼將會超出現階段計算機硬體所能滿足的極限。
不僅如此，HDFS並不是為了有效的處理大量小文件而存在的。它主要是為了流式的訪問大文件而設計的。對小文件的讀取通常會造成大量從
datanode到datanode的seeks和hopping來retrieve文件，而這樣是非常的低效的一種訪問方式。
大量小文件在maprece中的問題
Map tasks通常是每次處理一個block的input(默認使用FileInputFormat)。如果文件非常的小，並且擁有大量的這種小文件，那麼每一個map task都僅僅處理了非常小的input數據，
並且會產生大量的map tasks，每一個map task都會消耗一定量的bookkeeping的資源。比較一個1GB的文件，默認block size為64M，和1Gb的文件，沒一個文件100KB，
那麼後者沒一個小文件使用一個map task，那麼job的時間將會十倍甚至百倍慢於前者。
hadoop中有一些特性可以用來減輕這種問題：可以在一個JVM中允許task reuse，以支持在一個JVM中運行多個map task，以此來減少一些JVM的啟動消耗
(通過設置mapred.job.reuse.jvm.num.tasks屬性，默認為1，－1為無限制)。另一種方法為使用MultiFileInputSplit，它可以使得一個map中能夠處理多個split。
為什麼會產生大量的小文件？
至少有兩種情況下會產生大量的小文件
1. 這些小文件都是一個大的邏輯文件的pieces。由於HDFS僅僅在不久前才剛剛支持對文件的append，因此以前用來向unbounde files(例如log文件)添加內容的方式都是通過將這些數據用許多chunks的方式寫入HDFS中。
2. 文件本身就是很小。例如許許多多的小圖片文件。每一個圖片都是一個獨立的文件。並且沒有一種很有效的方法來將這些文件合並為一個大的文件
這兩種情況需要有不同的解決方 式。對於第一種情況，文件是由許許多多的records組成的，那麼可以通過件邪行的調用HDFS的sync()方法(和append方法結合使用)來解 決。或者，可以通過些一個程序來專門合並這些小文件(see Nathan Marz』s post about a tool called the Consolidator which does exactly this).
對於第二種情況，就需要某種形式的容器來通過某種方式來group這些file。hadoop提供了一些選擇：
* HAR files
Hadoop Archives (HAR files)是在0.18.0版本中引入的，它的出現就是為了緩解大量小文件消耗namenode內存的問題。HAR文件是通過在HDFS上構建一個層次化的文件系統來工作。一個HAR文件是通過hadoop的archive命令來創建，而這個命令實 際上也是運行了一個MapRece任務來將小文件打包成HAR。對於client端來說，使用HAR文件沒有任何影響。所有的原始文件都 visible && accessible（using har://URL）。但在HDFS端它內部的文件數減少了。
通 過HAR來讀取一個文件並不會比直接從HDFS中讀取文件高效，而且實際上可能還會稍微低效一點，因為對每一個HAR文件的訪問都需要完成兩層index 文件的讀取和文件本身數據的讀取(見上圖)。並且盡管HAR文件可以被用來作為MapRece job的input，但是並沒有特殊的方法來使maps將HAR文件中打包的文件當作一個HDFS文件處理。 可以考慮通過創建一種input format，利用HAR文件的優勢來提高MapRece的效率，但是目前還沒有人作這種input format。 需要注意的是：MultiFileInputSplit，即使在HADOOP-4565的改進(choose files in a split that are node local)，但始終還是需要seek per small file。
* Sequence Files
通 常對於「the small files problem」的回應會是：使用SequenceFile。這種方法是說，使用filename作為key，並且file contents作為value。實踐中這種方式非常管用。回到10000個100KB的文件，可以寫一個程序來將這些小文件寫入到一個單獨的 SequenceFile中去，然後就可以在一個streaming fashion(directly or using maprece)中來使用這個sequenceFile。不僅如此，SequenceFiles也是splittable的，所以maprece 可以break them into chunks，並且分別的被獨立的處理。和HAR不同的是，這種方式還支持壓縮。block的壓縮在許多情況下都是最好的選擇，因為它將多個 records壓縮到一起，而不是一個record一個壓縮。
將已有的許多小文件轉換成一個SequenceFiles可能會比較慢。但 是，完全有可能通過並行的方式來創建一個一系列的SequenceFiles。(Stuart Sierra has written a very useful post about converting a tar file into a SequenceFile — tools like this are very useful).更進一步，如果有可能最好設計自己的數據pipeline來將數據直接寫入一個SequenceFile。
閱讀全文
Ⅸ eclipse 向hdfs 上傳文件為空怎麼解決
eclipse 向hdfs 上傳文件為空怎麼解決
首先，代碼稍微改一下【】---->【】其次，你這種做法是無法上傳文件的，只是將form中的所有數據寫到文件中。必須要能判斷【request.getInputStream();】流中，哪些是文件流，哪些是文本域的流或者其他信息的判斷。我這邊幫你寫了一個，用到了一個組件【】two.jsp:MyJSP'UpLoadProcess.jsp'startingpageitems=upload.parseRequest(request);Iteratorit=items.iterator();System.out.println(it.hasNext());while(it.hasNext()){FileItemitem=(FileItem)it.next();if(!item.isFormField()){FilefullFile=newFile(item.getName());FilesavedFile=newFile(uploadPath,fullFile.getName());item.write(savedFile);}}}%>
Ⅹ 怎樣將hdfs上的文件導入數據
額，是指什麼？啥叫將hdfs上的文件導入數據
上傳 hdfs dfs -put
下載 hdfs dfs -get
如果已經存在的文件似乎是不能修改的，比如HIVE輸出結果到目錄就是覆蓋（而不是修改）。