不使用Delta Lake在Spark中实现SCD Type2的方案是否有效？

方案可行性判定 #

你给出的实现方案仅能实现基础的状态标记逻辑，但不符合标准SCD Type2的设计要求，存在核心功能缺失，具体分析如下：

方案可取之处 #

• 基于业务主键（col1/col2/col3）拼接校验字段区分新增、未变更、待过期数据的逻辑思路是合理的，可准确识别数据匹配关系
• 针对Spark原生不支持同表同时读写的冲突问题，采用临时中转表的规避方案是正确的，可有效避免读取快照和写入的一致性冲突

存在的核心问题 #

1. 缺失SCD Type2最核心的历史版本保留能力
   现有逻辑中common_records直接复用原有活跃记录，没有对属性发生变化的旧活跃记录做过期标记，也没有写入日增表中携带新属性的新版本记录，完全无法保留数据变更的历史链路，不符合SCD Type2保留全量历史版本的核心要求。
2. 缺少必要的时间维度字段
   标准SCD Type2必须包含生效时间（start_date）、失效时间（end_date）字段，仅靠record_status无法追溯某条记录的生效时间范围，无法满足历史快照回溯的需求。
3. 主键拼接逻辑存在风险
   使用concat拼接多个业务主键时，若任意字段为null，拼接结果会直接变为null，导致匹配逻辑出错，建议改用concat_ws('|', col('col1'), col('col2'), col('col3'))或者直接用多列作为join关联条件，避免单列拼接的异常问题。
4. 合并逻辑稳定性不足
   直接使用union合并DataFrame依赖列顺序完全一致，很容易出现数据错位问题，建议改用unionByName保证按列名合并，逻辑更健壮。
5. 全量覆盖写入性能损耗大
   现有逻辑每次都全量重写目标表，数据量大时性能极低，建议开启Hive动态分区，仅重写涉及变更的record_status分区，不需要全表覆盖。

核心逻辑修正建议 #

针对属性变更的场景，需要调整common_records部分的逻辑：

• 第一步：将匹配上日增数据的旧活跃记录标记为expired，同时填充失效时间为当前日期
• 第二步：将日增表中对应匹配上的记录作为新版本，标记为active，填充生效时间为当前日期
• 再和其他未变更、新增、已过期的记录合并，才符合SCD Type2的要求

# 示例修正后的变更记录处理逻辑
# 旧版本标记过期
expired_old_records = common_records.withColumn('record_status', lit('expired'))\
                                    .withColumn('end_date', lit(current_date()))
# 新版本写入
new_version_records = daily.join(active.select('check_update_keys'), on=['check_update_keys'])\
                           .withColumn('record_status', lit('active'))\
                           .withColumn('start_date', lit(current_date()))\
                           .withColumn('end_date', lit('9999-12-31'))

# 合并时替换原有common_records的部分
final_df = expired_old_records.unionByName(new_version_records)\
                              .unionByName(new_records)\
                              .unionByName(old_records)\
                              .drop('check_update_keys')\
                              .unionByName(expired)

内容的提问来源于stack exchange，提问作者Lambda-Square