2010-08-04 71 views
0

我一直負責爲我的公司處理多TB價值的SCM數據。我建立了一個hadoop集羣,並有一個腳本來從我們的SCM服務器獲取數據。Hadoop塊大小問題

由於我通過流式接口通過批處理數據,遇到了O'Reilly的Hadoop書籍似乎無法解決的塊大小問題:跨兩個塊的數據會發生什麼情況? wordcount示例如何解決這個問題?爲了解決這個問題,我們採取了讓每個輸入文件小於64mb的方法。

思考Reducer腳本時再次出現問題;如何存儲地圖的彙總數據?這個問題在減少時會出現嗎?

+0

什麼是SCM在你的情況? – wlk 2010-08-04 18:59:43

+0

我們使用Perforce。 – bhargav 2010-08-04 19:25:25

回答

1

這應該不是一個問題,只要每個塊都可以乾淨地分割分割數據的一部分(如通過換行符)。如果你的數據不是一行一行的數據集,那麼是的,這可能是一個問題。您也可以增加羣集上塊的大小(dfs.block.size)。

您也可以自定義自己的流媒體的投入是如何進入你的映射器

http://hadoop.apache.org/common/docs/current/streaming.html#Customizing+the+Way+to+Split+Lines+into+Key%2FValue+Pairs

數據從地圖步驟中,基於對地圖的關鍵一partioner類被整理到一起。

http://hadoop.apache.org/common/docs/r0.15.2/streaming.html#A+Useful+Partitioner+Class+%28secondary+sort%2C+the+-partitioner+org.apache.hadoop.mapred.lib.KeyFieldBasedPartitioner+option%29

然後數據被洗牌在一起,使所有的映射鍵扎堆,然後轉移到減速。有時候在減速步驟發生之前,如果你喜歡,可以使用組合器。

最有可能的,你可以創建自己的自定義-inputreader(我這裏是怎麼流的XML文檔http://hadoop.apache.org/common/docs/current/api/org/apache/hadoop/streaming/StreamXmlRecordReader.html

+0

這是完美的。我的大部分問題都是通過將文件分割大小限制爲64MB(塊的大小)來解決的,因此將每個文件(適合一個塊)映射到單個映射進程。在2節點集羣上,我們在3分鐘內處理了大約2GB的數據 - 可笑的是速度快:) – bhargav 2010-08-08 20:08:51

+0

我不認爲應該存在「分割」記錄問題:就像使用常規文件系統一樣,塊大小是物理結構這在邏輯層面上並不一定有深遠的影響。所以,雖然可以將文件大小設置爲塊大小(理想情況下較小),但爲了避免負面的性能問題,不必爲了正確而進行分割。 – StaxMan 2011-01-20 00:33:29

0

如果你有多TB的輸入,你應該考慮設置塊大小,甚至超過128MB。

如果文件大於一個塊,它可以被分割,因此每個文件塊將轉到不同的映射器,或者整個文件可以轉到一個映射器(例如,如果此文件被壓縮)。但我想你可以使用一些配置選項來設置它。

拆分自動處理,你不應該擔心。地圖輸出存儲在hdfs的tmp目錄中。

0

您對「數據跨越兩個街區」是什麼RecordReader處理問題。一個RecordReader的目的是3倍:

  1. 確保每個k,V對被處理
  2. 確保每個k,V對僅處理一次
  3. 手柄K,V對它們跨越塊
  4. 分裂

實際發生在(3)中的是RecordReader返回到NameNode,獲取下一個塊所在的DataNode的句柄,然後通過RPC伸出來拉入該完整塊並讀取剩餘的第一條記錄的一部分直至記錄分隔符。