《Apache Flink 案例集（2022版）》——2.数据分析——美团-Flink 的实时数仓平台建设（2） /article/1228306
对于上述问题，我们提出了冷热关联分离的解决方案。假设关联两天前的数据是相对低频的且状态回滚不会超过两天，那么可以定义两天前的数据为冷数据，两天之内的数据为热数据。
如上图所示，左侧的 SQL 作业通过设置状态保留时长，只保留 T+0 和 T+1 这两天的热数据，而 T+2 及更久以前的冷数据则通过批任务每天从 Hive 同步到外存 KV 中。关联时，若状态中的热数据不存在，则再通过访问外存 KV 来关联冷数据。右侧是另外一个 SQL 作业需要关联相同的数据源，它与左侧的 SQL 作业共享外层 KV 中的冷数据。
对于第一个痛点，因为状态控制在了两天内，SQL 作业上线时，关联数据初始化的数据量得到了控制。对于第二个痛点，因为两天前的大部分数据都保存在外层KV中，不同的 SQL 作业都可以查询外存 KV，从而可以节省大量内存资源。
第2个问题是有状态 SQL 逻辑变更后状态如何恢复？FlinkSQL 支持有状态的增量计算，状态是增量计算的历史累计，实际上业务需要修改逻辑的情况很多。
上图右侧列出了一些常见的 SQL 变更情况，比如新增聚合指标、修改原指标口径、增加过滤条件、新增数据流关联、增加聚合维度等。举例来说，如果业务增加了更多服务维度，在数据产品上就需要扩展分析的维度，因此也需要修改 FlinkSQL 增加聚合维度。但是上述 SQL 逻辑变化后却不能从之前的状态恢复，因为历史状态对于变更后的 SQL 不能保证其完整性，即使恢复后也不能百分百保证后续计算的正确性。这种情况下，业务为了保证数据的正确性，需要从历史回溯重新计算，回溯的过程会导致线上断流，但业务又不希望牺牲太多的时效性。
针对这个问题，美团给出了三种解决方案：
解法 1：双链路切换。此解法的关键是再搭建一条相同的实时链路作为备用链路，当变更有状态 SQL 时，可以在备用链路上做回溯，重新计算历史数据，回溯完成后先验证备用链路的结果数据，确保没问题后再在链路最下游的数据服务层切换读取的表，完成整个变更流程；
解法 2：旁路状态生成。与双链路切换不同点在于，这里变更的是链路上的单个作业，思路是临时启动一个旁路作业来回溯，构建出新逻辑的状态，验证数据完成后再重启线上作业，以此完成 SQL 和状态的同时切换；
解法 3：历史状态迁移，前两个方法的思路比较类似，都是基于历史数据重新计算，构建出新状态。但这个思路是基于历史状态迁移出新状态，这种方法构建出的新状态虽然不能保证完整性，但在某些情况下，业务也是可以接受的。
上述三种方式各有优点，可以从普适性、资源成本、线上断流、等待时长四个维度来对以上三个解决方案进行横向比较。
普适性是指在保证数据正确的前提下支持的 SQL 变更范围，前两个方法都是重新计算，状态是完整的，因此比方案 3 的普适性更高；
资源成本是指完成 SQL 变更所需要的额外 Flink 或 Kafka 资源，方法 1 需要构建整条链路，需要更多的 Flink 和 Kafka 资源，因此成本最高。
线上断流指的是在变更过程中导致下游数据延迟的时长，方法 1 是在数据服务层做切换，几乎没有断流；方法 2 的断流时长取决于作业从状态恢复的速度；方法 3 除了状态恢复，还需要考虑状态迁移的速度；
等待时长指的是完成整个变更流程需要的时间，前两个方法都需要重新计算，因此比方法 3 的等待时间更长。
《Apache Flink 案例集（2022版）》——2.数据分析——美团-Flink 的实时数仓平台建设（4） /article/1228303
