你可能想做很多事情，每一件都有自己的解决方案。如果不止一个用例与您相关，您可能希望并行实现多个解决方案。

1. 存储文件以供使用

如果您希望以一种能够有效地（分布式）提取文件的方式存储文件，那么解决方案很简单：将文件放在hdfs上

2. 存储信息以供使用

如果您想使用这些信息，而不是存储文件，那么您应该感兴趣的是以一种能够有效地提取信息的方式来存储这些信息。这里的一般解决方案是：以无损的方式解析文件并将其信息存储在数据库中
您可能会发现，将信息存储在（分区的）orc文件中可以很好地实现这一点。您可以使用pive、pig甚至pig中的udf（例如python）来实现这一点。

3. 为将来保存这些文件

在这种情况下，您最关心的是保存文件，而不是访问的方便性。这里推荐的解决方案是：使用适当的备份存储压缩文件
请注意，hdfs所做的复制是为了更有效地处理数据（和硬件问题）。将数据放在hdfs上并不意味着它已经备份。

我假设您希望存储包含数据的文件—实际上是一个可搜索的文件存档。
文件本身可以存储在hdfs中。。。或者你会发现像亚马逊s3这样的系统更便宜、更灵活。在存储文件时，您可以通过附加到另一个文件来管理有关数据的其他数据，即：位置、源和创建时间—一个简单的选项卡分隔文件或hadoop支持的其他几种格式使这变得简单。
您可以在hadoop工具上使用配置单元或其他sql来管理和查询文件。实际上，您正在创建一个具有特殊属性的简单文件系统，因此技巧是确保每次编写文件时，您也要编写元数据。您可能需要处理诸如写入失败、删除、重命名或移动文件时发生的情况（我知道，您会说“从不”）。
根据您的需要，您的解决方案可能更简单，您可能会发现将数据存储在hdfs（或awss3）的子目录中更简单。如果您想存储源“foo”中的dbf文件，以及2015年12月1日创建的“bar”中的xls文件，您可以简单地创建如下目录结构

/2015/12/01/foo/dbf/myfile.dbf
/2015/12/01/bar/xls/myexcel.xls

这个解决方案的优点是可以自我维护——文件路径存储元数据，这使得它非常可移植和简单，只需要一个shell脚本即可实现。
我认为没有任何理由使解决办法变得比必要的更复杂。hadoop或s3对于长期、高持久性的存储和查询都很好。我的公司发现，在hadoop中存储文件的信息（我们将其用于许多其他目的）并将文件本身存储在awss3上要简单得多，更容易保护，也更便宜。