我认为 Hadoop 的常见使用模式是通过从操作系统加载定期(例如每日)数据快照来构建“数据湖”。对于许多系统来说，每天的变化率通常小于行的 5%(即使更新一行，也只有少数字段可能会发生变化)。
问:这样的历史数据如何在HDFS上结构化，既节省空间消耗，又高效访问。
当然，答案取决于数据的通常访问方式。在我们的 Hadoop 集群上:
- 大多数作业仅读取和处理最新版本的数据
- 少数作业处理一段时间的历史数据(例如 1 - 3 个月)
- 一些作业会处理所有可用的历史数据
这意味着，虽然保留历史数据很重要，但它不应该以严重减慢那些只想知道昨天收盘时的数据情况的工作为代价。
我知道一些选择，但没有一个看起来令人满意:
将每个完整转储独立存储为一个新的子目录。这是最明显的设计，简单，并且与 MapReduce 范例非常兼容。我确信有些人使用这种方法，但我想知道他们如何证明存储成本的合理性？假设每天加载 1Tb，那么每年向集群添加 365Tb 的大部分重复数据。我知道现在磁盘很便宜，但大多数预算制定者习惯于基础设施与业务增长成比例扩展，而不是随着时间的推移线性增长。
仅存储与前一天的差异(增量)。当源系统更喜欢以增量形式发送更新时(这种心态似乎已经过时了)，这是一个自然的选择从数据以 CD-ROM 形式在系统之间传递开始)。它更节省空间，但更难做到正确(例如，如何表示删除？)，更糟糕的是，它意味着消费者需要扫描整个历史记录，“事件溯源”式，才能到达在系统的当前状态。
将行的每个版本存储一次，并带有开始日期和结束日期。这种模式以“时间变量数据”等术语而闻名，在数据仓库中非常频繁地出现，并且更常见的是在关系数据库设计中，当需要存储历史值时。当一行更改时，更新以前的版本以设置“结束日期”，然后插入新版本，并以今天作为“开始日期”。不幸的是，这并不能很好地转化为 Hadoop 范式，其中只支持追加数据集，并且没有更新行的 native 概念(尽管可以通过覆盖现有数据文件来实现该效果)。这种方法需要相当复杂的逻辑来加载数据，但无可否认，使用这种结构消费数据非常方便。
(值得注意的是，只需要一个每天都在变化的特别不稳定的字段，就能使后一个选项降级到与选项 1 相同的空间效率)。
那么...是否还有另一种将空间效率与易用性结合起来的选择？
最佳答案
我建议使用选项 3 的变体，该变体尊重 HDFS 的仅附加性质。
我们没有保留一个数据集，而是保留两个具有不同类型信息的数据集，并单独存储:
- 过期行的历史记录，很可能按结束日期(可能每月)分区。仅当行的结束日期已知时才会添加行。
- 特定日期的快照集合，至少包括最近一天，很可能按快照日期分区。每天都可以添加新快照，几天后可以删除旧快照，因为它们可以根据当前快照和过期记录的历史重建。
与选项 3 的区别只是我们认为未过期的行与过期的行是不同类型的信息。
优点:与 HDFS 的仅附加性质一致。
优点:只要我们将快照保留几天(比运行最长查询所需的时间更长)，使用当前快照的查询就可以在添加新的一天时安全运行。
优点:使用历史记录的查询同样可以安全地运行，只要它们明确给出最新“结束日期”的界限，排除运行时任何后续添加的过期行。
缺点:这不仅仅是简单的每天“更新”或“覆盖”。在 HDFS 的实践中，这通常需要通过复制和过滤来实现，所以这并不是一个真正的骗局。
缺点:许多查询需要组合两个数据集。为了缓解这个问题，我们可以创建 View 或类似的 View ，将两者适本地结合起来，以生成看起来与选项 3 完全相同的东西。
缺点:查找最新快照需要找到正确的分区。通过让 View 在每次有新快照可用时“滚动”到最新快照，可以缓解这一问题。
关于hadoop - 在 Hadoop HDFS 中高效存储每日转储，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/44704858/