近实时DWH架构设计咨询：多数据源及硬删除场景优化方案

1. 统一实时+批量数据源的处理链路 #

• 去掉Firehose中转环节，用Flink直接对接Kafka实时CDC事件，同时支持批量读取S3/HDFS上的批量数据源文件，实现单引擎统一处理实时与批量数据，减少链路节点。
• 落地数据湖分层逻辑：
  • Raw层：直接存储原始Kafka事件（包含DELETE类型的CDC事件）和批量源文件，保留全量原始数据以确保可回溯。
  • Clean层：通过Flink完成数据清洗、去重、主键关联，对实体的增删改事件做状态聚合，生成每个实体的最新状态（标记删除状态），写入S3的列式存储（如Parquet）。
  • Mart层：基于Clean层数据，用Flink SQL实时生成业务实体表，或同步到Snowflake后做进一步加工。

2. 高效同步Hard Deletes到Snowflake #

• 在Flink处理阶段，识别CDC事件中的DELETE标记，在Clean层数据中为实体添加is_deleted字段（或直接保留DELETE事件）。
• 写入Snowflake时，使用MERGE INTO语句：匹配实体主键，若为DELETE事件则执行DELETE操作，若为新增/更新则执行INSERT或UPDATE，确保DWH最终表与源端删除状态完全同步。
• 若依赖Snowflake原生能力，可将Clean层数据同步到Snowflake的临时变更表，通过Snowflake Streams捕获表中所有变更（含删除），再用Tasks自动触发Merge逻辑到最终实体表，减少Flink侧的业务逻辑复杂度。

3. 平衡实时能力与业务逻辑灵活性 #

• 保留数据湖分层的同时，用Flink SQL替代部分dbt批量逻辑，实现实时数据加工；对于非实时敏感的业务规则，仍可定期用dbt基于Clean层数据做批量补全或校验，兼顾灵活性与实时性。
• 利用Flink的状态管理能力，在Clean层维护实体的全量状态，避免重复计算，同时支持回溯重跑，确保数据一致性。

4. 简化架构的可选变体 #

如果希望进一步精简链路，可采用：

• Kafka CDC事件 → Flink（直接处理增删改+状态聚合）→ 同时写入S3 Raw层和Snowflake最终表，省略中间Clean层的中转，但需确保Flink逻辑足够健壮以避免数据丢失。
• 批量数据源直接上传到S3 Raw层，Flink定期扫描Raw层批量文件，与实时事件合并处理后同步到Snowflake。

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