适用于：Microsoft Fabric 中的✅ 仓库
在Microsoft Fabric中，仓库根据配置的保留期自动保留和维护各种版本的数据。 此保留期确定可以执行 时间旅行 查询、创建 表克隆、使用 还原点和创建 仓库快照的时间。
创建仓库时，数据保留会自动启动。 默认情况下，仓库将数据历史记录保留 30 个日历天。 可以将保留期配置为 1 到 120 天之间的任何值。 系统会在保留期结束后自动删除过期的文件。
仓库在配置的保留期内保留所有插入、更新和删除。
- 增加保留期 为时间旅行查询、过去时间点的表克隆、还原点和数据仓库快照提供了更长的时间窗口。 但是，更长的保留期会增加存储消耗和相关成本。
- 减少保留期 可降低存储成本，但会限制可以查询或恢复历史数据的时间。
数据保留的工作原理
修改数据后，仓库不会立即放弃以前的版本状态。 相反，以前的数据版本将保留为 Delta Lake 事务日志的一部分。 此版本控制机制使时间旅行、表克隆、还原点和仓库快照能够正常运行。
当历史数据版本超过配置的保留期时，后台垃圾回收过程会自动从 OneLake 中删除过期的文件。 此清理进程以异步方式运行，不会影响活动查询或正在进行的事务。
仓库自创建数据版本之时起，按绝对日历日计算已保留数据的留存时长，其中包括 Microsoft Fabric 容量暂停期间的时间。
保留期范围
如果未显式配置保留期，现有仓库将使用默认保留期 30 个日历天。 可以将数据保留期配置为 1 到 120 天。
配置数据保留
使用 ALTER DATABASE ... SET T-SQL 命令设置数据仓库的数据保留期。 有关步骤和详细信息，请参阅 如何在 Fabric Data Warehouse 中配置数据保留。
更改保留期时的行为
了解更改保留期时的行为有助于规划更改以避免意外数据丢失或存储大小增加。
增加保留期
增加保留期时，新设置将立即生效。 但是，无法恢复系统在上一个较短的保留期下清理的历史数据。 只有在更改期间 OneLake 中仍然存在的数据版本才会受益于延长的保留期。
例如，如果仓库当前具有 7 天的保留期，并且将其增加到 60 天，则更改将从该点向前应用。 在更改之前已被系统清理的数据版本（超过 7 天的版本）无法恢复。 更改时，仍在7天时段内的所有数据版本以及之后新创建的版本，将被保留最多60天。
减少保留期
减少保留期时，现在超出新较短保留期的数据版本将有资格进行清理。 清理进程在后台异步运行，不会即时发生。 正在进行的查询不会受到影响。
例如，如果仓库的保留期为 30 天，并且将其减少到 7 天，则 8 到 30 天之间的数据版本有资格进行后台清理。
Important
从数据访问的角度来看，减少保留期是不可逆的。
即便在不久后再次延长保留期，属于较短窗口之外的数据在此期间依然无法访问。 在减少保留期之前，请确保新的保留期满足组织的数据恢复和合规性要求。
保留截止日期
time_travel_retention_cutoff_date
sys.databases 系统目录视图中的列反映了从中获取时间旅行数据的实际最早日期，而不是当前配置的保留期。 最早的实际数据可以不同于配置的保留期。
用户配置的保留期定义系统将来应保留的历史记录天数。 但是，实际可恢复的历史记录 取决于在进行任何保留更改之前所保留的数据。
两种情况会导致配置的保留期与实际可用历史记录之间存在分歧：
- 保留期减少 - 仓库会立即标记超过垃圾回收新保留期的历史数据，并永久删除它。
- 随后延长了保留期 - 数据仓库无法恢复已删除的历史记录。 它必须等到新历史记录累积后，完整配置窗口才会可用。
数据保留方案
在决定如何配置保留期时，请考虑以下方案：
合规性和审计
符合法规或合规性要求的组织可能需要在较长时间内保留数据，以满足审核义务。 配置保留期为 90 或 120 天可以提供更广泛的历史窗口，供审核员查看随时间推移的数据更改。
开发和测试
对于历史数据不太重要的开发或测试工作区，较短的保留期为 1 到 7 天可降低存储成本。 当工作区用于快速原型制作或迭代开发时，这种减少非常有用。
成本优化
如果仓库经常进行大规模数据修改（例如每日满负荷），则保留的历史数据量可能会大幅增长。 在这些情况下，减少保留期有助于控制存储成本，同时仍保持合理的恢复时段。
数据恢复准备
对于生产仓库，如果发生意外的数据损坏，则保持更长的保留期为通过 还原点、 表克隆和 时间旅行 查询来恢复数据提供了更大的灵活性。
可配置的保留如何影响依赖功能
对以下功能，Fabric 数据仓库将统一应用配置的保留期。 更改保留期直接影响这些功能的可用性和行为。
时间旅行
通过时间旅行 ，您可以在保留期内查询某个过去时间点的数据。 查询 FOR TIMESTAMP AS OF 提示可以从配置的保留期内的任何点检索数据。
例如，如果将保留期设置为 15 天，则可以查询数据，因为数据在过去最多存在 15 个日历天。
克隆表
表克隆 依赖于数据保留期。 您只能在配置的保留期内的过去某个时间点创建表的克隆。 如果请求超出保留期的克隆，则会发生错误。
还原点
使用 还原点来还原仓库。 系统在配置的保留期内保留系统生成的恢复点和用户定义的恢复点。 保留期到期后，系统会自动删除还原点。
- 仓库每 8 小时自动创建系统生成的还原点。 这些恢复点可以在配置保留期内使用。
- 用户定义的还原点可在配置的保留期内使用。 系统会在过期后自动删除这些还原点。
Fabric维护最少数量的还原点，以确保有足够的还原点始终可用。
仓库快照
仓库快照 可以在配置的保留期内引用数据。 快照时间戳可以设置为配置保留期内的任何点或数据库创建时间（以以后为准）。
存储计费
数据保留直接影响 OneLake 存储消耗。 每个保留版本的数据占用存储空间，较长的保留期会累积更多的历史版本。
在规划保留配置时，请权衡访问更长数据历史记录的优点与相关存储成本之间的关系。 有关监视存储的详细信息，请参阅 Fabric Data Warehouse 中的
- 保留的数据文件：存储在 OneLake 中的数据历史版本作为 parquet 文件，占用存储空间。 存储成本与保留期内数据修改的数量和频率成正比。
- 还原点：系统生成的还原点和用户定义的还原点的元数据也使用存储。 但是，还原点主要存储元数据和引用现有数据文件，因此其存储开销相对较小。
- 没有保留的计算费用：仅保留历史数据不会产生计算费用。 计算费用仅适用于主动查询或还原数据时。
若要估计保留期更改的存储影响，请考虑：
- 仓库中数据修改的平均每日量。
- 当前保留期和建议的新保留期。
- 两个周期之间的增量与平均每日变动量相乘，可估算存储消耗的变化幅度。
设计注意事项
- 根据组织的数据恢复、合规性和成本要求配置保留期。 默认值为 30 天，为大多数工作负荷提供数据可用性和存储成本之间的平衡。
- 使用备份和灾难恢复策略协调保留期更改。 确保保留期与恢复点目标（RPO）保持一致。
- 在更改保留期后监视 OneLake 存储消耗量，以了解对存储成本的影响。
- 如果可能，请在低活动时段规划保留期变更，以免影响用户。
- 保留期在仓库级别设置。 如果需要不同数据集的不同保留期，请考虑将它们组织到单独的仓库中。 目前不支持单个表级保留设置。
局限性
- 指定保留期的天数。 不支持分数值。
- 减少保留期不会立即回收存储。 过期数据的清理是在后台异步进行的。
- 暂停Microsoft Fabric容量会影响垃圾清理活动。 在容量暂停时，此过程不会删除早于数据保留设置要求的历史数据。 一旦能力恢复，清理活动就会赶上。
- 保留设置仅适用于仓库。 不支持 Lakehouse 的 SQL 分析端点。
- Query Insights 和 SQL 审核日志不受此数据保留策略的约束，并且单独进行管理。
已删除项目保留期（预览版）
已删除项保留会在仓库及其关联的表、架构、快照、权限和已保存查询被删除后，于可配置的时间段内继续保留它们。 这可确保意外删除不会造成永久性数据丢失或业务影响中断。 已删除的保留期保证最短保留期为 7 个日历天，并且具有单独的租户级保留配置。 可以在 Item Recovery 租户设置中配置已删除的项保留期。