【实时数仓篇】（04）利用 Flink 实现实时状态复用场景

写在前面：我是「云祁」，一枚热爱技术、会写诗的大数据开发猿。昵称来源于王安石诗中一句 [ 云之祁祁，或雨于渊 ] ，甚是喜欢。


写博客一方面是对自己学习的一点点总结及记录，另一方面则是希望能够帮助更多对大数据感兴趣的朋友。如果你也对 数据中台、数据建模、数据分析以及Flink/Spark/Hadoop/数仓开发 感兴趣，可以关注我的动态 https://blog.csdn.net/BeiisBei ，让我们一起挖掘数据的价值~


每天都要进步一点点，生命不是要超越别人，而是要超越自己！ (ง •_•)ง

一、浅谈实时数仓

整理自：【实时数仓篇】利用 Flink 实现实时状态复用场景
讲师：李晨（菜鸟 数据工程师）

1.1 实时数仓体系

1.2 实时 & 离线

TT 类似于Kafka ，选用 TT ，是因为既可以做离线计算的数据源，也可以做实时计算的数据源。

架构的亮点：connector 实现了离线计算的数据和实时计算的互通。

二、状态复用场景

2.1 问题

问题
场景一：job的operator变化（sql修改），checkpoint无法自动恢复，savepoint恢复机制无法满足，比如增加group by 和 join 。 集群或调度异常情况下导致job在恢复重启时路径 or 目录丢失，重新消费历史数据会依赖上游数据源存储失效。比如近一个月的数据，要将一个月甚至更长的消息存储在Kafka/TT里。

场景二：用户state生命周期（ttl）设置过小可能会导致一些长周期业务数据到期join不到丢失，retract 时产生NPE报错等。设置过大，资源消耗大。

2.2 解决方案

2.2.1 方案一

last_value: https://www.alibabacloud.com/help/zh/faq-detail/62791.htm

2.2.2 方案二