1

数据湖应该是不可变的：

重要的是，放入湖中的所有数据都应具有明确的出处和时间。每个数据项都应该清楚地跟踪它来自哪个系统以及数据的生成时间。因此，数据湖包含历史记录。这可能来自于将领域事件馈入湖中，这与事件源系统自然契合。但它也可能来自系统将当前状态定期转储到湖中 - 当源系统没有任何时间功能但您想要对其数据进行时间分析时，这种方法很有价值。这样做的结果是放入湖中的数据是不可变的，一旦声明的观察不能被删除（尽管稍后可能会被驳斥），您还应该期待 ContradictoryObservations。

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

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

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

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

4

1 回答 1

1

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

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

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

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

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

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

于 2020-03-25T20:24:01.423 回答