何时优先使用Dynamic Lookup而非static lookup 可否用其实现SCD type1和type2

• 实时/近实时数据集成场景：当映射运行过程中源数据会持续产生新增、更新操作，需要lookup的结果能同步捕获同运行周期内刚写入的目标表/中间表数据时，必须用Dynamic Lookup。Static Lookup只会在映射初始化时加载一次缓存，运行过程中不会更新，返回的都是缓存加载时的过时数据，无法满足实时匹配需求。
• 同一映射内存在「先写入lookup源、后查询lookup源」的处理链路：比如在同一个映射中先向维度表插入新数据，后续处理其他关联记录时需要用到刚插入的维度键做关联，Static Lookup加载不到本次运行写入的内容，会触发重复插入冗余维度数据的问题，这种场景必须选择Dynamic Lookup。
• 大维度表的增量同步场景：如果每次同步仅处理增量变更数据，用Dynamic Lookup可以在缓存中实时更新增量变更的维度属性，不需要每次映射运行都全量重新加载整个维度表缓存，能大幅提升lookup的查询性能。
• 同运行周期内的数据校验场景：需要对比本次映射处理前后的数据差异，判断记录是新增、更新还是重复时，Dynamic Lookup可以实时缓存已经处理过的记录，直接在内存中完成校验，不需要反复查询物理表，减少IO开销。

是否支持 SCD Type2 实现 #

完全可以实现，核心是利用Dynamic Lookup的缓存自动刷新能力，配合返回的缓存匹配状态字段（比如Informatica里的NewLookupRow字段）做分支判断即可：

• 当lookup没有匹配到记录时，判定为新增维度，直接插入新的生效版本，同时将这条新记录同步更新到Dynamic缓存中
• 当lookup匹配到记录，且维度业务属性发生变更时，先把旧版本的维度记录置为失效，再插入新的生效版本，同时将新版本的记录更新到Dynamic缓存中

实现注意：需要配置Dynamic Lookup的缓存更新策略为仅插入/更新维度的生效版本记录，避免缓存中留存旧的失效版本数据影响后续的匹配逻辑。

是否同时支持 SCD Type1 实现 #

完全支持，且实现逻辑比SCD Type2更简单：
当lookup匹配到记录且业务属性发生变更时，直接更新物理维度表对应的属性值，同时同步更新Dynamic Lookup缓存里的对应记录即可，不需要处理版本链路，同一个维度键的缓存永远保留最新的属性值，后续匹配时直接返回最新结果即可。

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