基于Delta Table按唯一列保留最新记录的优化方案问询

问题回顾 #

现有Delta格式的main表，采用ZORDER BY uniq做性能优化，白天以append方式写入流数据，夜间重新执行ZORDER优化。需构建一张gold表，仅保留每个uniq对应的最新全量记录以降低查询延迟，已尝试DENSE_RANK()/QUALIFY重建表、Upsert（Merge）、Delta变更数据捕获（CDC）、按uniq分区等方案但均未解决问题，考虑引入Redis等内存KV存储寻求最优解。

数据示例 #

main表初始数据 #

date | uniq | key | value 
2022-12-13 | 1 | "key1" | 1
2022-12-13 | 1 | "key55" | 5
2022-12-13 | 2 | "key105" | 3

新增批次数据 #

date | uniq | key | value 
2022-12-14 | 1 | "key3" | 0
2022-12-14 | 1 | "key4" | 1
2022-12-14 | 1 | "key5" | 0
2022-12-14 | 1 | "key6" | 1

目标gold表数据 #

date | uniq | key | value 
2022-12-13  | 2 | "key105" | 3
2022-12-14 | 1 | "key3" | 0
2022-12-14 | 1 | "key4" | 1
2022-12-14 | 1 | "key5" | 0
2022-12-14 | 1 | "key6" | 1

推荐方案：Redis+Delta分层架构 #

1. 白天流数据实时写入Redis（低延迟更新） #

• Key设计：以uniq作为Redis的Key，Value存储该uniq对应的最新全量记录（可序列化为JSON格式）。
• 写入逻辑：流数据通过AutoLoader进入后，直接覆盖Redis中对应uniq的Value——流数据本身是该uniq的最新状态，无需处理历史数据，操作极简。
• 优势：内存读写延迟达毫秒级，完全满足实时查询需求；避开Delta表批量操作的延迟问题。

2. 夜间批量同步Redis数据到Delta gold表（持久化+离线查询） #

• 同步逻辑：main表完成夜间OPTIMIZE ZORDER后，将Redis全量数据导出，采用覆盖写入或Merge方式更新Delta格式的gold表。若采用Merge，可仅同步当日有更新的uniq记录，减少处理量。
• 性能优化：gold表同样配置ZORDER BY uniq，若数据量过大，可按date+uniq做分区进一步缩小查询扫描范围。

3. 备选方案：改进Delta Merge Upsert逻辑（无需引入Redis） #

若不想新增组件，可针对之前Merge方案的痛点优化：

• 增量范围锁定：利用Delta的CDC功能获取当日新增的uniq列表，仅对这些uniq执行Merge——先删除gold表中对应uniq的旧记录，再插入最新批次数据，避免全表扫描。
• 时间窗口过滤：Merge时通过date字段限定仅处理最新日期的uniq数据，大幅降低数据处理规模。

方案对比 #

ETL流程调整建议 #

原始数据（raw）→ AutoLoader → 双分支并行处理：

• 分支1：append写入main表（夜间执行OPTIMIZE ZORDER BY uniq）
• 分支2：实时更新Redis（维护uniq最新记录）
• 夜间定时任务：将Redis全量数据同步到Delta gold表

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