hadoop - 在 Hadoop HDFS 中高效存储每日转储

Question

我认为 Hadoop 的一个常见使用模式是通过从操作系统加载定期(例如每天)数据快照来构建“数据湖”。对于许多系统，每天的变化率通常小于行的 5%(即使更新了行，也只有少数字段可能发生变化)。

问:这样的历史数据如何在HDFS上进行结构化，既节省空间又高效访问。

当然，答案取决于数据的访问方式。在我们的 Hadoop 集群上:

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

这意味着，虽然保留历史数据很重要，但不应以严重减慢那些只想知道昨天营业结束时的数据情况的作业为代价。

我知道几个选项，但没有一个看起来很令人满意:

1. 将每个完整转储独立存储为一个新的子目录。这是最明显的设计，简单，并且与 MapReduce 范式非常兼容。我敢肯定有些人使用这种方法，但我想知道他们如何证明存储成本的合理性？假设每天加载 1Tb，那么每年有 365Tb 添加到集群中，其中大部分是重复数据。我知道现在磁盘很便宜，但大多数预算制定者都习惯于基础设施随业务增长成比例扩展，而不是随时间线性增长。

2. 仅存储与前一天的差异(delta)。当源系统更喜欢以 delta 的形式发送更新(一种似乎过时的思维方式)时，这是一个自然的选择从数据以 CD-ROM 形式在系统之间传递的时间开始)。它更节省空间，但更难正确处理(例如，你如何表示删除？)，更糟糕的是，它意味着消费者需要扫描整个历史记录，“事件溯源”风格，以便到达在系统的当前状态下。

3. 将行的每个版本存储一次，并附上开始日期和结束日期。以“时变数据”等术语而闻名，这种模式在数据仓库中经常出现，并且当需要存储历史值时，在关系数据库设计中更普遍。当一行发生变化时，更新以前的版本以设置“结束日期”，然后插入以今天为“开始日期”的新版本。不幸的是，这并不能很好地转化为 Hadoop 范例，在 Hadoop 范例中，仅附加数据集受到青睐，并且没有更新行的 native 概念(尽管可以通过覆盖现有数据文件来实现这种效果)。这种方法需要相当复杂的逻辑来加载数据，但不可否认，使用这种结构使用数据会非常方便。

(值得注意的是，只需要一个特别不稳定的字段每天都在变化，就可以使后面的选项降级到与选项 1 相同的空间效率)。

那么...是否有另一种选择既能节省空间又易于使用？

Answer 1

我建议采用选项 3 的变体，它尊重 HDFS 的仅追加特性。

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

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

与选项 3 的不同之处在于，我们认为未过期的行与过期的行是不同类型的信息。

优点:与 HDFS 的仅追加性质一致。

优点:只要我们将快照保留几天(比运行最长查询所需的时间长)，使用当前快照的查询就可以在添加新的一天时安全运行。

优点:使用历史记录的查询同样可以安全运行，只要它们明确给出最新“结束日期”的界限，不包括在运行时任何后续添加的过期行。

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

缺点:许多查询需要结合两个数据集。为了缓解这种情况，我们可以创建 View 或类似的 View ，将两者适本地结合起来，以产生看起来与选项 3 完全一样的东西。

缺点:找到最新的快照需要找到正确的分区。每次有新快照可用时， View 都会“滚动”到最新快照，这可以缓解这种情况。