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

:

重要的是，湖中的所有数据都应有清晰的图像 出处的地点和时间。每个数据项都应该有一个清晰的 跟踪数据来自哪个系统以及数据是何时产生的。这个 数据湖因此包含了一个历史记录。这可能来自 将域事件馈送到湖中，与事件源自然契合 系统。但它也可能来自定期转储数据的系统 湖的当前状态-当 源系统没有任何临时功能，但您需要一个 对其数据进行时间分析。这样做的结果是，数据 进入湖中是不可改变的，一次陈述的观察是不可改变的 删除（尽管稍后可能会被反驳），您也应该期望 矛盾的观察

规则中是否有一些例外，覆盖数据湖中的数据可能被认为是一种良好的做法？我想没有，但是有些队友有不同的理解

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

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

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

规则中是否有一些例外，覆盖数据湖中的数据可能被认为是一种良好的做法

最好的做法是不要覆盖数据池中的数据。以防生成带有错误或bug的事件。应产生补偿前一个事件的新事件。通过这种方式，数据湖记录所有事件历史，包括补偿事件和最终的再处理

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

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

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

---

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

感谢您提供如此详细的答案，我已经阅读了多次。不幸的是，我不明白这一点，事先对此表示歉意。在第2节-对于我来说，仍然不清楚为什么非累积算法需要事件历史；以及业务/运营/沟通事件术语如何影响答案。你能举个例子吗？第3节-对我来说，听起来像是一个术语游戏：“数据湖应该是不可变的，但如果它是可重复的，就让我们称之为一个开始事件。”第2节示例。想象我们需要计算税收的购买。我们需要一个带有税率的事件（税率更新）和一个物品购买事件（物品结帐）。最终值（生成的事件）不依赖于DataLake，也不使用累积算法。这同样适用于折扣券。第3节。不变性发生在事件级别。数据湖应该只会增加。数据湖中记录的事件是不可变的。不应该改变。我们可以把它比作一条以大坝为终点的河流。水坝的大小在变化。但是水仍然是一样的（不变的）。关于“业务/运营/通信事件术语影响答案”，只是要澄清，并非系统中发生的所有事件都应该记录。但只有那些与业务相关且我们需要再处理且对业务有价值的活动。事件源是DataLake的一项潜在功能，但不是主要目标。数据湖应被视为公司资产。新的解决方案和分析可以使用数据湖中的数据，而不仅仅限于事件来源。事件源支持重建应用程序状态、进行临时查询（某个时间点的应用程序阶段）和事件重播（如果需要，重新发布事件）。