在hadoop中,映射程序接收鍵作爲文件中的位置,如「0,23,45,76,123」,我認爲這是字節偏移量。hadoop對鍵進行排序並更改鍵值
我有兩個大的輸入文件,我需要以文件的相同區域(按行數,例如400行)獲取相同密鑰的方式進行分割。字節偏移顯然不是最好的選擇。
我想知道是否有方法或選項將鍵更改爲整數,所以輸出鍵將是:「1,2,3,4,5」而不是「0,23,45,76, 123" ?
謝謝!
在hadoop中,映射程序接收鍵作爲文件中的位置,如「0,23,45,76,123」,我認爲這是字節偏移量。hadoop對鍵進行排序並更改鍵值
我有兩個大的輸入文件,我需要以文件的相同區域(按行數,例如400行)獲取相同密鑰的方式進行分割。字節偏移顯然不是最好的選擇。
我想知道是否有方法或選項將鍵更改爲整數,所以輸出鍵將是:「1,2,3,4,5」而不是「0,23,45,76, 123" ?
謝謝!
在hadoop中,映射程序接收密鑰作爲文件 (如「0,23,45,76,123」)中的位置,我認爲這是字節偏移量。
是的。但不總是。這是真的,如果你使用TextInputFormat(如你的情況)。鍵和值取決於您使用的InputFormat的類型並相應地進行更改。
我想知道如果有一種方法或選項來改變鍵的 整數所以輸出密鑰將是:「1,2,3,4,5」,而不是「0,23, 45,76,123「?
您可以通過繼承FileInputFormat來編寫自己的自定義InputFormat來實現此目的。
您可以跟蹤自己的行號的映射:
protected int recNo = 0;
protected void map(LongWritable key, Text value, Context context) {
++recNo;
// mapper implementation
// ...
}
但這並不佔splitable文件(存儲在2首或更多個街區,splitable文件 - 不使用gzip壓縮的例)。在這種情況下,每個分割都將被編號爲1的行號,而不是文件開頭的行號。你提到你有兩個大文件 - 所以要麼你需要強制輸入格式的最小分割大小大於文件的大小,要麼使用不可分割的壓縮編解碼器壓縮文件(強制每個文件處理單個任務),例如作爲gzip。
這是可能的,如果我得到正確的,那麼你想要以增量順序索引所有記錄。
我已經這樣做了。你可以利用框架。這是我們如何在GPU中編程的。 概述您可以按照每條記錄的相同編號拆分文件。這將允許你索引特定的索引。 文件拆分後的公式是
ActualIndex = splitNubmer * Num_Of_record_Per_Split + record_Offset
現在將詳細討論。 首先使用NLineInputFormat
創建拆分,從而允許在特定拆分中對記錄進行索引。埃米特與密鑰記錄爲splitId + redordIndex in split + actual record
。現在我們已經在Map階段進行了索引分割。 然後您需要使用自定義SortComaprator
,其中鍵SplitId
的中間輸出排序。然後服裝groupComarator
其中所有鍵與SplitId
相同。 現在在減速機中,您可以使用上述公式。索引記錄。 但問題是我們如何以升序識別splitNumber。我解決了這個問題。 Hadoop的分割文件通過file_HDFS_URL/file_name:StartOffset+Length
example: hdfs://server:8020/file.txt:0+400, hdfs://server:8020/file.txt:400+700, and So on.
我創建了一個文件在HDFS那個記錄的分裂開始偏移。然後在Reducer中使用它。 這種使用方式可以使用完全平行的記錄索引。
謝謝,我會盡量使用不可拼接的壓縮 – Yukun