Hadoop過程WARC文件

我有一個關於Hadoop文件分割和多個映射器的一般問題。我是Hadoop的新手，並試圖掌握如何設置最佳性能。我的項目目前正在處理GZIPed的WARC文件。Hadoop過程WARC文件

使用當前的InputFileFormat，文件被髮送到一個映射器並且不被分割。我知道這是加密文件的正確行爲。在運行作業之前解密文件作爲一箇中間步驟，以允許拆分作業並因此使用更多映射器，會有性能優勢嗎？這可能嗎？是否有更多的映射器會在延遲上創建更多的開銷，或者有更好的映射器嗎？謝謝你的幫助。

來源

2016-10-30 user1738628

基本上它取決於你在哪裏運行它。如果你在一臺機器上運行它，那麼我不認爲會有很多性能改進。但是如果你在分佈式環境中運行它，那麼會有。您可以拆分文件並將其發送到多個映射器，然後在其他機器上同時運行多個映射器。這樣你可以更快地得到答案。假設程序在一臺機器上運行10個小時。現在，如果您有10臺機器並將其映射到這10臺機器，並行執行1小時，您可以查看結果。 –

感謝您的回覆。我正在使用Amazon Elastic Map Reduce服務進行處理。使用當前配置，我只利用了一個映射器，這意味着其他節點閒置，這對我來說似乎是一種浪費。理想情況下，我希望將文件拆分爲多個映射器以利用我配置的所有節點。我想你已經回答了我是否應該首先將文件解密到本地存儲的問題，以便可以通過hadoop系統將其分割爲多個映射器。 – user1738628

儘管WARC文件被壓縮，但它們是可拆分的（參見Best splittable compression for Hadoop input = bz2?），因爲每個記錄都有其自己的壓縮塊。但是記錄偏移量必須事先知道。

但這真的有必要嗎？常見爬網WARC文件大小約爲1 GB，應在最大範圍內正常處理。 15分鐘。考慮到啓動映射任務的開銷，這是映射器運行的合理時間。 Ev。，映射程序也可以處理一些WARC文件，但重要的是您有足夠的輸入WARC文件列表拆分，以便所有節點都在運行任務。在Hadoop上處理單個WARC文件意味着很多不必要的開銷。

來源

2016-10-30 20:39:58

感謝Sebastian的迴應。我的映射器在GZipped WARC文件中包含的每個記錄上執行繁重的解析任務。我最初的測試需要大約30分鐘來映射和減少1 GZipped文件。我在本地測試了一個生產者/消費者方法，讓一個線程遍歷流中的所有記錄，並將其置於隊列中以供消費者線程解析出內容主體。如果我可以分割出更多的mapper並行運行，那麼我可能會將每個WARC Archive文件的時間縮短爲幾分鐘。這聽起來合理嗎，還是錯誤的方法？ – user1738628

Hadoop過程WARC文件

回答

相關問題