实时数仓的架构实现如图所示。首先，ODS 层的数据主要来自于客户端埋点、服务端日志和业务库数据。从 ODS 层到 APP 层的建设，采用行业较为成熟的 Flink + MQ 方案实现。其中，在 DWD 层主要进行数据的 ETL 和维表关联（打宽）处理。
维表关联主要通过两种方式实现：
使用 KV 存储实现 Lookup Join。对于时效性要求较高或流量较大的场景，通常采用此方式，并在 Flink 内部通过 Keyed State 和 distributeBy 等多种优化手段，充分利用 Flink 的缓存以提升整体查询性能。但在巨大流量的冲击下，此方案依然对外部 KV 存储的稳定性构成巨大挑战。
基于 Hive 或 MySQL 实现 Broadcast Join。对于时效性要求较低的维表（如 T+1 维表），通常采用此方式进行维度关联，当 Hive 分区就绪时，会触发维表的更新。
在 DWD 层，由于内部 MQ 尚不支持精准一次（Exactly-Once）语义，因此需要进行数据去重。APP 层主要是根据业务诉求进行定制化的逻辑开发。最后，会将 ODS 层和 APP 层的数据写入下游的 OLAP 引擎或 KV 存储中，对外提供指标查询服务。
对于整个测试流程，以 DWS 层的测试为例，由于 MQ 不支持直接查询，因此需要将每一层的 MQ 数据同步至 Hive，再基于 Hive 进行数据比对，导致整体测试成本非常高。随着业务的发展，当前架构的痛点也愈发显著。为解决以上问题，团队调研了社区众多开源数据湖引擎，最终决定采用 Paimon 作为数据湖底座，重构实时数仓。
