数据湖不变性规则的例外情况

Question

Data Lake should be immutable:

重要的是，放入湖中的所有数据都应该清晰 出处地点和时间。每个数据项都应该有一个明确的 追溯它来自哪个系统以及数据的生成时间。这 因此，数据湖包含历史记录。这可能来自 将领域事件馈入湖中，与 Event Sourced 天然契合 系统。但它也可能来自定期转储的系统 当前状态进入湖中 - 一种有价值的方法 源系统没有任何时间能力，但你想要一个 对其数据进行时间分析。这样做的结果是数据 入湖不可更改，一经陈述的观察不能 已删除（尽管稍后可能会被驳斥），您还应该期待 矛盾的观察。

规则是否有任何例外，在哪些情况下覆盖 Data Lake 中的数据可能被认为是一种好习惯？我想没有，但有些队友有不同的理解。

我认为在累积算法的情况下需要数据来源和可追溯性，以便能够重现最终状态。如果最终状态不依赖于先前的结果怎么办？如果他说 Data Lake 中的 Data Lake 不变性（事件溯源）仅用于累积算法，那么有人说得对吗？

例如，您每天满负荷摄取表 A 和 B，然后计算表 C。如果用户只对 C 的最新结果感兴趣，是否有任何理由保留历史记录 ( A、B、C 的基于日期划分的事件溯源？

另一个问题可能是 ACID 合规性 - 您的文件可能已损坏或部分写入。但是假设我们正在讨论可以从源系统轻松恢复 A 和 B 的最新状态的情况。

Answer 1

规则是否有任何例外情况，在哪些情况下覆盖 Data Lake 中的数据可能被认为是一种好的做法？

最好的做法是不要覆盖数据湖中的数据。以防某些事件因错误或错误而生成。应该产生补偿前一个事件的新事件。这样，Datalake 会记录所有事件历史记录，包括补偿事件和最终的重新处理。

我认为在累积算法的情况下需要数据来源和可追溯性，以便能够重现最终状态。如果最终状态不依赖于先前的结果怎么办？如果他说只有累积算法才需要 Data Lake 中的 Data Lake 不变性（事件溯源），那么有人说得对吗？

DataLake 是所有相关事件的最终归宿。并非所有事件都需要记录在数据湖中。通常，我们区分操作/通信和业务事件。 DataLake 中记录的业务事件可用于重新处理或用于依赖于事件历史的新功能。也可以生成不依赖于事件历史的孤立事件并将其添加到历史中。因此，我们可以推断出最终状态不违反不变性原则。对于一组在时间上连续的不可变事件，我们总是可以产生最终状态。所以，答案不仅仅针对累积算法。

例如，您每天对表 A 和 B 进行全负载摄取，然后计算表 C。如果用户只对 C 的最新结果感兴趣，是否有任何理由保留历史记录（基于事件溯源A、B、C的日期划分）？

事件历史的起始事件无法重现。只有在第一个事件之后，我们才能考虑最终状态。在这种特殊情况下，不应将 A 和 B 元组和聚合视为事件。而是计算函数输入。计算函数输入应作为业务事件记录在数据湖中。最后的事件X（计算输入）产生事件Y。如果事件X没有记录在事件的历史中，则Y应该被认为是开始事件。