HDFS中的大数据和小文件问题


HDFS中的大数据和小文件问题

> Lost person looking for answers. Image by VisionPic .net

这些天,每个人都在谈论"大数据",但每个人都知道什么使大数据成为大数据吗? 只需尝试阅读Wikipedia上"大数据"一词的定义即可; "一个……处理的数据集太大或太复杂而无法处理的字段……",在任何地方都找不到使数据太大或太复杂的数字。

定义"大数据"

作为拥有一年历史的大数据团队的团队负责人,我们不了解BIG的定义,而我们的组织则不了解!

该项目的目的是处理来自不同来源的日志数据,以提高我们网络的安全性。 日志数据主要由事件组成,平均为500个字节。 有些甚至是200个字节。

之前,我们在Hadoop HDFS中存在稳定性问题,因为我们忽略了一个基本假设。 HDFS被编程用于大文件(1 GB及更大)。 当不稳定袭击我们时,我们开始重新思考什么使我们成为大数据! 毕竟,我们来自一个没有大数据的世界(和组织),过去并且总是很难建立一个牢固的知识库。

我们将Flume(我们的提取工具)配置为以5分钟为一批来提取数据,并将其写入HDFS,每个事件500字节; 输入范围是15个事件/秒到10,000个事件/秒,我们有许多文件,范围从8kb到140kb。 考虑到所有输入的数据,我们得出的输入速率约为55GB /小时,这足以被认为是大数据。

在寻找任何绝对答案的困惑中,我遇到了这个博客,尽管它语言粗糙,但简洁明了,在考虑使用BIG(数据)时将为您节省宝贵的时间和金钱。

该页面专门讨论了采用Hadoop生态系统作为您的大数据平台。 即使本文提供了一些数字,可以使我们更清楚地了解这些数字,但从不同的角度来看,这些数字还是不准确的,因此应予以考虑。

首先,该页面写于2013年,当时Hadoop的版本为2.2.0。 只是为了弄清楚,今天我们的版本是3.2,所以情况已经改变。

其次,如果我们用Wikipedia中的定义替换页面上的数字,则可以说作者认为5TB +是一个太大而复杂的数据集,无法处理。 5TB固然很大,但相对于数字世界中其他数据以及我们拥有的处理能力而言,庞大而复杂是相对形容词。 以下预测将确定这些变化会迅速发生:

1.仅在一年内,累积的世界数据将增长到44兆字节(即44万亿千兆字节)! 为了进行比较,今天大约是4.4 ZB。 从hostingtribunal.com检索。

2.摩尔定律说,计算能力将每两年增加一倍(保持到3nm)。 从维基百科检索。

总而言之,今天的5TB可能超过20TB(使用不考虑软件限制的最新技术)。

另外,在大多数情况下,您可能会流式传输新数据(或每X次加载增量数据),因此数据将具有增长的因素。 这与考虑增长是否反映在您或客户查询的数据集中有关。

数据集中的增长可以来自多种来源。 它可以在您希望扩展查询的时间范围时形成,另一个增长源可以从相同的输入(以发送的消息的速率)发展,最后通过添加您要处理的其他数据输入

了解数据集的定义是至关重要的。

当我们更好地了解了客户的数据集后,我们发现各种研究问题都需要基于天,月甚至几年的数据。 这些数据集的处理数据从100MB到100TB不等。 所以这很大!

不幸的是,对于Hadoop来说,不足1GB的文件被滥用,因此,我们在存储数据方面仍然存在问题。

尽管问题仍然存在,但回答BIG问题仍然很艰巨,需要进行修订以验证我们的要求没有在我们脚下改变。

解决HDFS的小文件

在项目的这一点上,已经有活动的客户端正在使用存储在Hadoop上的数据,我们根本无法转移到Cassandra(这比处理带有小文件的Hadoop更好-我认为选择Cassandra而不是Hadoop是最合适的决定) 满足我们的最初要求,但这全是事后所见)。 因此,我们需要基于与当前目录结构向后兼容的相同架构,找到一个更简单的解决方案。

从那时起,我们想到了每小时进行一次数据聚合以充分利用当前的索引约定(请查阅上一则故事),以获取每小时可能最大的单个文件。

这是一个简单的程序,它从特定的(过去)小时读取Flume写入的数据,并将它们写入另一个并行目录结构中的一个Parquet文件中。 这种优化为我们节省了HDFS中的大量空间和文件数量,这又由于降低了节点的RAM使用率而提高了HDFS的性能和稳定性。 您可以在不同格式之间查看这些基准,这是我们数据工程师必须知道的基本知识!

这种简单的策略运行得很好,这就是为什么我们扩展其功能以支持各种流应用程序输出并通过输入/输出目录结构变得更加灵活的原因。

我们评估了该解决方案仅能保留一两年,但是事实证明,它的使用寿命超出了我们的预期。 此外,由于将原始数据和已发布的数据格式分离,因此为我们提供了灵活性。 我们从纯文本和JSON格式开始,然后,转移到Parquet作为客户的最终发布数据格式,同时保持了原始数据格式的灵活性(我们在输入数据类型中使用了更适合的格式), 该应用程序在两者之间进行了转换。 后来,当我们添加新格式时,很容易在聚合应用程序中实现转换。

重新考虑项目的假设和基础有利于增强您对所采取的行动和做出的决定的信念。 请记住,在做出这些决定时,请保持最简单,最容易的一面,以保留未来的灵活性。

(本文翻译自Eyal Yoli Abs的文章《Big data & small files problem in HDFS》,参考:https://medium.com/datadriveninvestor/big-data-small-files-problem-in-hdfs-ba8707ec46b)


分享到:


相關文章: