Hadoop處理非常大的二進制文件

Question

我有一個系統，我希望分發的地方，我有一些非常大的非分裂二進制文件，我希望以分佈式方式處理。這些是幾百Gb的順序。對於各種固定的，特定於實現的原因，這些文件不能並行處理，而是必須由相同的進程順序處理，直到最後。

該應用程序是用C++開發的，因此我將考慮使用Hadoop管道將數據流入和流出。每個實例需要按照自己的數據（當前存儲在一個文件中）順序處理100Gb到200Gb的順序，並且應用程序當前（可能）是IO限制的，因此每個作業完全在本地運行很重要。

我非常熱衷於HDFS託管這些數據 - 自動維護冗餘副本並在添加新節點時重新平衡的能力將非常有用。我也熱衷於縮減地圖，因爲它簡單的計算和要求儘可能接近數據的計算。但是，我想知道Hadoop對於這個特定的應用程序有多合適。

我知道，爲了表示我的數據，可以生成不可拆分的文件，或者生成大量的序列文件（在我的情況下，對於單個文件，這些文件的大小應該是10Tb） - 如果我打包我所有的數據都放入其中）。因此，它可能是使用Hadoop處理我的數據。但是，好像我的模型並不適合Hadoop：社區是否同意？或者有建議將這些數據最優化？或者甚至對於可能更適合該模型的其他集羣計算系統更好？

這個問題也許是關於hadoop的現有問題的重複，但是除了我的系統需要每個單獨文件一個數量級或兩個以上的數據之外（以前我已經看到了關於幾個單個文件的問題Gb）。所以如果之前已經回答了這個問題，請原諒我 - 即使是這樣大小的數據。

感謝，

亞歷

Answer 1

好像你與大文件的數量相對較少的工作。由於您的文件非常龐大而且不可拆分，因此Hadoop將無法有效地在羣集中安排和分配作業。我認爲您在一批中處理的文件越多（如數百個），使用Hadoop就越有價值。

由於您只使用一些文件，您是否嘗試過更簡單的分發機制，例如使用ssh在多臺機器上啓動進程，或者使用GNU Parallel？對於簡單的任務，我已經取得了很大的成功。在所有節點上使用NFS掛載的驅動器可以共享限制您必須執行的複製數量。

Answer 2

你可以爲你的文件寫一個自定義的InputSplit，但是因爲bajafresh4life說它不會真的很理想，因爲除非你的HDFS塊大小和你的文件大小相同，否則你的文件將會遍佈四處，成爲網絡開銷。或者，如果您確實使您的HDFS大小與您的文件大小相匹配，那麼您沒有獲得所有羣集磁盤的好處。底線是Hadoop可能不是您最好的工具。