数据架构咨询：员工主数据每日快照存储方案选型

两种方案优劣势对比 #

• 方案1：每日存储全量快照
  • 优势：
    • 开发成本极低：不需要做版本对比逻辑，拉取到全量数据后直接按日期分区存储即可，出现问题回滚也很方便，直接重新拉取对应日期的全量数据覆盖即可
    • 查询逻辑极简：要统计任意日期的FTE，直接过滤对应日期分区的数据计算即可，不需要做版本拼接、生效时间判断，大幅降低统计口径出错的概率
    • 适配API不可靠性：如果某天API调用出现缺数、漏数的问题，后续排查校验很简单，直接和当日原始接口返回值做一致性比对即可
  • 劣势：
    • 存储成本相对更高：如果员工基数较大（比如超过10万），长期累积的全量快照会占用较多存储资源，不过现阶段云存储、数仓存储成本已经很低，大部分场景下这个劣势可以忽略
• 方案2：仅存储变更记录（即缓慢变化维SCD Type2模式）
  • 优势：
    • 存储成本极低：只有员工的岗位、在职状态、FTE系数等核心字段发生变更时才新增一条记录，长期来看存储量仅为全量快照的几十分之一甚至更低
    • 数据溯源性更强：可以直接查询单个员工的所有历史变更轨迹，不需要跨日期快照对比，适合需要追溯变更原因的场景
  • 劣势：
    • 开发成本高：需要对比当日全量数据和上一版本的全量数据，识别出新增、变更、失效的记录，还要维护每条记录的生效开始日期、生效结束日期、是否最新版本等标识字段，逻辑出错的概率更高
    • 查询逻辑复杂：要统计任意日期的FTE，需要过滤出生效开始日期 <= 统计日期 AND 生效结束日期 > 统计日期的记录，对不熟悉数据模型的使用者很不友好，容易出现统计错误

选型建议 #

如果团队研发资源有限、核心诉求是快速上线且统计逻辑不允许出错，优先选每日全量快照方案。
如果员工基数超过100万、存储成本压力较大，且有专门的数仓开发人员维护数据模型，优先选变更记录存储方案。

该场景的通用设计原则 #

• 数据可回溯原则：所有存储的原始数据不允许修改、删除，哪怕后续发现历史数据有问题，也要用新增修正版本的方式处理，保证任意时间点的统计结果都可以复现
• 口径一致性原则：所有和FTE计算相关的核心字段（岗位、在职状态、FTE系数、部门归属等）的变更都要纳入版本跟踪，不能出现部分字段变更不记录的情况
• 校验兜底原则：不管选哪种存储方案，都要每天做数据一致性校验：比如当日全量数据统计的在职人数、总FTE要和HR系统的官方统计值对齐，避免API拉取缺数导致的统计错误
• 查询易用性原则：如果面向的使用方是业务分析人员，尽量对外提供封装好的全量快照宽表，不要让使用方自己处理变更记录的生效逻辑，降低用数门槛

内容的提问来源于stack exchange，提问作者gip