首页
学习
活动
专区
圈层
工具
发布
社区首页 >问答首页 >高效地存储Hadoop中的每日转储

高效地存储Hadoop中的每日转储
EN

Stack Overflow用户
提问于 2017-06-22 16:27:08
回答 1查看 698关注 0票数 2

我认为Hadoop的一个常见使用模式是通过加载来自操作系统的数据定期快照(例如每日)来构建一个“数据湖”。对于许多系统来说,每天的变化率通常不到行的5% (即使行被更新,也只有几个字段可以更改)。

问:这些历史数据如何在HDFS上构建,这样既节省了空间消耗,又有效地访问了.

当然,答案将取决于数据的访问方式。在Hadoop集群中:

  • 大多数作业只读取和处理最新版本的数据。
  • 一些工作处理一段时间的历史数据(例如,1-3个月)
  • 一些作业处理所有可用的历史数据。

这意味着,尽管保存历史数据很重要,但不应以严重放缓那些只想知道昨日停业时数据的情况为代价的工作为代价。

我知道有几种选择似乎都不太令人满意:

  1. 将每个完整转储独立存储为一个新的子目录。-这是最明显的设计,简单,并与MapReduce范例非常兼容。我相信有些人使用这种方法,但我想知道他们如何证明存储的成本是合理的?假设每天加载1Tb,那么这就是每年添加到集群中的大部分重复数据的365 to。我知道现在磁盘很便宜,但大多数预算制定者习惯于基础设施的扩张与业务增长成比例,而不是随着时间的增长而线性增长。
  2. 只存储与前一天的差异(),当源系统更喜欢以增量的形式发送更新时,这是一种自然的选择(这种思维方式似乎可以追溯到数据以光盘形式在系统间传递的时候)。它的空间效率更高,但更难纠正(例如,如何表示删除?),更糟糕的是,它意味着消费者需要扫描整个历史记录,即“事件源”-style,以便达到系统的当前状态。
  3. 将一行的每个版本存储一次,其中包含开始日期和结束日期。以“时变数据”等术语所知的在数据仓库中非常频繁地出现这种模式,在需要存储历史值的关系数据库设计中更是如此。当一行发生更改时,更新前一个版本以设置“结束日期”,然后将新版本插入到今天作为“开始日期”。不幸的是,这并不能很好地转化为Hadoop范式,在Hadoop范式中,只使用附加数据集是可取的,而且没有更新行的原生概念(尽管这种效果可以通过覆盖现有的数据文件来实现)。这种方法需要非常复杂的逻辑来加载数据,但无可否认,使用这种结构可以非常方便地使用数据。

(值得注意的是,它所需的只是一个特别不稳定的字段,每天进行更改,使后一个选项降低到与选项1相同的空间效率)。

So...is还有另一种将空间效率和易用性结合起来的选择吗?

EN

回答 1

Stack Overflow用户

发布于 2017-09-13 03:54:11

我建议一种备选方案3的变体,它尊重HDFS的附加性质。

我们保存了两个不同类型的信息,而不是一个数据集,它们分别存储:

  1. 过期行的历史记录,最有可能是按结束日期(可能是每月)进行分区。这只有在其结束日期已知时才会添加行。
  2. 特定日期(至少包括最近的一天)的快照集合,最有可能按快照日期进行分区。新快照可以每天添加,旧快照可以在几天后删除,因为它们可以从当前快照和过期记录的历史记录中重构。

与选项3不同的是,我们认为未过期的行与过期的行是不同类型的信息。

Pro:与HDFS的附加性质一致。

Pro:使用当前快照的查询可以在添加新的一天时安全运行,只要我们保留快照几天(比运行最长的查询时间更长)。

支持:使用历史记录的查询同样可以安全运行,只要它们显式地对最新的“结束日期”进行绑定,即在运行时排除任何过期行的后续添加。

这不仅仅是一个简单的“更新”或“覆盖”每天。实际上,在HDFS中,这通常需要通过复制和过滤来实现,所以这并不是一个真正的骗局。

Con:许多查询都需要合并这两个数据集。为了缓解这种情况,我们可以创建视图或类似的视图,将两者适当地结合起来,从而产生与选项3完全类似的东西。

Con:找到最新的快照需要找到正确的分区。这可以通过查看每次新快照可用时“翻转”到最新快照来缓解。

票数 2
EN
页面原文内容由Stack Overflow提供。腾讯云小微IT领域专用引擎提供翻译支持
原文链接:

https://stackoverflow.com/questions/44704858

复制
相关文章

相似问题

领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档