使用HDFS存储不同大小的文件

时间:2017-06-17 08:04:38

标签: java-ee filesystems hbase hdfs parquet

我有一个相当理论上的问题。

我的团队正在开发和支持一个中型Java应用程序(目前有400k行),它可以处理很多二进制文件。目前,我们将所有数据存储在FS存储中。我们开发了一个小的“框架”,这将允许我们在未来扩展文件存储,但是,我强烈怀疑将数据存储在Windows / Linux文件系统上仍然是一个瓶颈(不用说重新发明一个轮子在分布式数据处理中然后依赖它似乎不是一个非常好的解决方案:))。

我们处理的数据大小范围从每个文件1-2mb到数百mb(很少千兆字节),并且经常访问。但我想强调文件大多是小。此外,考虑到我们的大数据和ML分析的长期计划,我正在研究将Hadoop生态系统集成到我们的应用程序中的可能性。

我目前的问题是HDFS和HBase在我们的环境中是否会发挥良好作用?据我所知,HDFS设计用于存储非常大的二进制数据,但是可能使用HBase和一些配置调优可以使这个东西工作更小的数据?我还必须提到读取和写入文件的性能确实重要

我很想听听您对我提到的技术的体验,也许任何人都可以推荐任何替代解决方案(Apache Parquet?)。

此外,我们的团队没有Hadoop提供的分布式大数据解决方案的经验,所以如果您认为这些框架可能适用于我们的案例,也许您可​​以就其集成或任何有关何处的提示提供反馈开始我的调查。感谢您的关注。 :)

P.S。除了FS之外,我们还使用S3来存档旧数据并存储大型(> 1gb)二进制文件,因此从这个角度来看,引入单个存储系统也会很酷。

1 个答案:

答案 0 :(得分:0)

经过小规模调查后,我了解到HDFS和noSQL存储等分布式文件存储不太适合低延迟的应用程序。

这些系统旨在在大数据世界中运行,其中高总体吞吐量比延迟更有价值,并且二进制文件的大小非常大。

对于大多数与真实用户交互或为此类应用程序提供服务的基于云的应用程序,最合适的数据存储是对象存储,例如Amazon S3。它们提供方便的API,合理的延迟,高可用性和几乎无限制。最重要的是,他们通常由第三方管理,这消除了开发人员方面的大量工作和担忧。