2017-06-17 90 views
0

我有一个相当理论上的问题。使用HDFS来存储不同大小的文件

我的团队正在开发和支持一个中等规模的java应用程序(目前有40万行),它处理二进制文件。目前我们将所有数据存储在FS存储上。我们开发了一个小型“框架”,使我们能够在未来扩展文件存储,但是,我强烈怀疑将我们的数据存储在Windows/Linux文件系统中仍然是一个瓶颈(不用说,重新创建一个轮子在分布式数据处理,然后依靠它似乎并不是一个很好的解决方案:))。

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

我现在的问题是如果HDFS和HBase可能会在我们的环境中发挥出色吗?据我所知,HDFS的设计是存储非常大的二进制数据,但也许使用HBase和一些配置调整,可以使这个工作的数据更小?我还必须提及的性能对于读取和写入文件都是重要的

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

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

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

+0

对于单个文件,是否一次写入并多次读取? – daemon12

+0

@ daemon12是的,这是正确的。目前我们还有很多复制操作,但是当我们转移到另一个存储系统时,我们可以避免这种情况。此外,目前大部分代码都是遗留的,我们正在逐个模块地移植到一个新的平台模块,所以也许我们可以重构业务逻辑,以便它不需要太多复制。 –

回答

0

经过小小的调查后,我了解到分布式文件存储(如HDFS和noSQL存储)不太适合以低延迟为目标的应用程序。

这些系统被设计为在大数据世界中运行,其中高整体吞吐量比延迟更有价值,并且二进制文件的大小很大。

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