目标

假设您正在使用etl构建数据湖和星型模式。存储格式为delta lake。etl的职责之一是构建缓慢变化的维度（scd）表（累积状态）。这意味着，对于每个scd表，etl每天都会读取完整表的状态，应用更新并将其保存回去（完全覆盖）。

问题

我们团队中争论的一个问题是：我们是否应该向scd（完全覆盖）表添加时间分区？意思是，我应该将最新（完整）的表状态保存到“SOME\u DIMENSION/”还是“SOME\u DIMENSION/YEAR=2020/MONTH=12/DAY=04/”？

注意事项

一方面，三角洲湖具有所有必需的特征：时间旅行和酸。当它覆盖整个表时，逻辑删除就会发生，您仍然可以查询旧版本并回滚到它们。所以delta lake几乎为您管理时间分区，代码变得更简单。
另一方面，我之所以说“差不多”，是因为imho time travel&acid并没有涵盖100%的用例。它没有到达时间的概念。例如：

示例（当您需要时间分区时）

ba团队报告说，“一些事实/年=2019/月=07/日=15”数据被破坏（事实必须以时间分区存储，因为数据是按到达时间处理的）。为了在dev/test环境中重现这个问题，您需要1个事实表原始输入和10个scd表。
事实上，一切都很简单，因为您在数据湖中有原始输入。但是对于增量状态（scd表），事情变得复杂了——如何在处理“SOME\u FACT/YEAR=2019/MONTH=07/DAY=15”时获取10个scd表的状态？如何自动执行此操作？
更复杂的是，您的环境可能会经历一系列的错误修复和历史重新处理。意味着2019-07年的数据可能会在2020年重新处理。delta-lake允许您仅基于处理或版本号回滚。所以你不知道该用哪个版本。
另一方面，对于日期划分，您总是可以确定“SOME\u FACT/YEAR=2019/MONTH=07/DAY=15”是在“SOME\u DIMENSION/YEAR=2019/MONTH=07/DAY=15”上计算的。