• 场景挑战：指标数据与维度数据进行关联，其中维度数据量比较大，指标数据 QPS 比较高，导致数据可能会产出延迟。

• 当前方案：将部分维度数据缓存起起来，缓解高 QPS 下访问维度数据存储引擎产生的任务背压问题。

• 存在问题：由于业务方的维度数据和指标数据时间差比较大，所以指标数据流无法设置合理的 TTL；而且存在 Cache 中维度数据没有及时更新，导致下游数据不准确的问题。

• 场景挑战：多个指标数据进行关联，不同指标数据可能会出现时间差比较大的异常情况。
• 当前方案：使用基于窗口的 JOIN，并且维持一个比较大的状态。
• 存在问题：维持大的状态不仅会给内存带来的一定的压力，同时 Checkpoint 和 Restore 的时间会变 得更长，可能会导致任务背压。

• 由于多流之间时间差比较大，需要维持大状态，同时 TTL 不好设置。
• 由于对维度数据做了 Cache，维度数据数据更新不及时，导致下游数据不准确。

1. 多流数据完全在存储层进行拼接，与计算引擎无关，因此不需要保留状态及其 TTL 的设置。

1. 维度数据和指标数据作为不同的流独立更新，更新过程中不需要做多流数据合并，下游读取时再 Merge 多流数据，因此不需要缓存维度数据，同时可以在执行 Compact 时进行 Merge，加速下游查询。

• 内置通用模板，支持数据去重等通用接口，同时可满足用户定制化数据处理需求。
• 支持离线场景和流批混合场景。

1. 流 1 的 Schema 包含三列 (A，B，C)，流 2 的 Schema 包含两列 (A，D)。

1. 在并发写入的时候，先在 Hudi MetaStore 对两个任务发起的 DeltaCommit 做列冲突检查，即除了主键列外的其它列是否存在交集，如图中的 (B，C) 和 (D)：
1. 如果有交集，则后发起的 DeltaCommit 失败。
2. 如果没有交集，则两个任务继续后续的写入。

接下来，介绍多流拼接场景下 Snapshot Query 的核心过程，即先对 LogFile 进行去重合并，然后再合并 BaseFile 和 去重后的 LogFile 中的数据。图 3 显示了整个数据合并的过程，具体可以拆分成以下 两个过程：

目前，基于 Hudi 多流拼接方案易用性不足，单个任务至少需要配置超过 10 个参数，为了进一步降低用户使用成本，后续会做部分列插入和更新的 SQL 的语法支持以及参数的收敛。

除此之外，为了进一步提升宽表数据查询性能，还计划在多流拼接场景下支持基于列存格式的 LogFile，提供列裁剪和过滤条件下推等功能。

推荐阅读

Halodoc使用Apache Hudi构建Lakehouse的关键经验

印尼医疗龙头企业Halodoc的数据平台转型之Lakehouse架构

基于 Flink + Hudi 的实时数仓在 Shopee 的实践

Apache Hudi 0.11.0版本重磅发布！

印尼医疗龙头企业Halodoc的数据平台转型之路：基于Apache Hudi的数据平台V2.0