《Apache Flink 案例集（2022版）》——2.数据分析——美团-Flink 的实时数仓平台建设（1） https://developer.aliyun.com/article/1228308

应用场景

美团实时数仓业务主要包含两类实时生产链路：

第一类应用场景是基于 FlinkSQL + OLAP 的实时生产链路。这个业务链路的实时数据源有两个，分别是业务 DB 的变更事件和业务服务的日志事件，这些事件首先会被收集到 Kafka 中，然后 DB 事件会按表名分发到新的 Kafka 中，DB 和日志的数据也会在这一层进行格式上的统一并完成实时数仓的 ODS 层。然后业务会使用 FlinkSQL 来清洗和关联 ODS 层的数据，生成实时数仓的主题宽表，最后写入 OLAP 查询引擎做实时分析。对于时效性要求不高的场景，部分业务还会在 OLAP 引擎上配置分钟级别的调度来减少相同查询的压力；

第二类应用场景的不同点在于，业务实时数仓的主题宽表数据并不是直接写入 OLAP 查询引擎，而是继续写入 Kafka，使用 FlinkSQL 做 APP 层的指标聚合，最终把预计算的指标数据写入 OLAP、DB 或 KV 这类应用层的存储。这种方式更适合对接数据服务，因为它兼顾了数据的时效性和高 QPS 的查询。

生产实践

在实际推广 FlinkSQL 的过程中，美团也面临了不少挑战。  

第1个问题是双流关联的大状态问题，FlinkSQL 的双流关联会保留左右流的历史数据来互相关联，需要关联的时间间隔越长，保存的历史数据就会越多，状态也就会越大。比如，要关联订单的下单事件和退款事件，并保证计算结果的正确性，需要考虑这两个事件发生的间隔，可能是一个月甚至更久。  

上图左侧是一个双流关联的有状态 SQL 作业，图中的 Mem 和 Disk 组成了 SQL 作业的 TaskManager 节点，SQL 作业状态后端使用 RocksDB，状态持久化在 HDFS 文件系统上。一开始我们尝试把 SQL 作业的状态设置为保留一个月，但 SQL 作业会变得不稳定，出现内存超限、状态读取性能下降等问题，只能不断增加作业的 TM 数和内存大小来缓解。  

即使这样，业务上仍然存在两个痛点。首先是关联数据初始化难，目前公司 Kafka 数据源对历史回溯有限制，因此业务不能构建出完整的历史状态，即使 Kafka 支持了更久的回溯，状态初始化的效率也依然是一个问题。其次，内存资源开销大，特别是当多个 SQL 作业关联相同的数据源时，需要为每个 SQL 作业都分配相应的内存资源，不同 SQL 作业间的状态是隔离的，作业间相同的关联数据不能复用。  

《Apache Flink 案例集（2022版）》——2.数据分析——美团-Flink 的实时数仓平台建设（3） https://developer.aliyun.com/article/1228304