手机打字，篇幅不长，主要讲一下FFA中关于Flink2.0的未来趋势，直接看重点。
Flink Forward Asia 2024主会场有一场关于Flink2.0的演讲，很精彩，官方也发布了一些关于Flink2.0的展望和要解决的问题。
1.0时代和2.0时代避免不了一些兼容性改动，例如配置文件、状态兼容以及一些常见的API，当然这些问题都不是用户需要考虑的，平台要做好升级。
那么作为普通的开发者应该注意到的未来趋势有哪些？
存算分离
存算分离是所有数据领域组件都在解决的一个问题，比如Apache Doris、Apache Pulsar等等，Flink同样面临这样的问题，因为在2.0中一个显著的课题就是「存算分离云原生化架构升级」。
Flink官方给出了四个要解决的诉求：
计算和存储解绑、容器化资源的均匀使用、利用海量低价云存储、带状态的快速扩缩容。
Flink 2.0 中的存算分离归根结底是存储的问题，因此引入了新开发的ForSt DB来解决这个问题。
如果存算分离能够很好的实现，未来Flink任务的迁移和升级将会十分方便和快捷，尤其是带大状态的任务，目前这个痛点相信困扰了很多很多人。
批流一体的解决方案
Flink2.0引入了全新的流批一体 Materialized Table(物化表)的概念来解决Streaming任务和Batch任务在代码层面的不一致性。
除了帮助用户实现只写一份代码、提高开发运维效率之外，Materialized Table 还提供了更多的成本优化空间。Materialized Table 支持流式持续刷新、批式全量刷新以及增量刷新 3 种模式，通过修改数据新鲜度FRESHNESS的定义来实现代码的批和流运行。
关于这一点，本人还是持谨慎怀疑的态度。
从某种意义上来说，代码层面的统一仅仅是解决批流一体中的「代码兼容性问题」，这是批流一体很小的一部分。
Flink社区对批流一体的关注点在于成本的节省，非常低成本的任务时效切换，但是其实这个点其实是批流一体场景中最不重要的一点。
因为能做到这种切换的业务场景其实并不多，大部分场景无法做到完全的批流一体，不过这仍然是一种进度。
Streaming WareHouse
这个已经是老生常谈的话题了。社区未来会进行Flink和Paimon的深度集成。
但是我还是之前的观点，Paimon并没有给传统的数仓开发模式带来「革命性的进步」，但是的确解决了部分痛点。
Streaming warehouse要解决的是传统的离线/实时数仓中的痛点，而不是为了构建「纯流式的数据仓库」。
Paimon未来作为批流一体存储引擎前途仍然光明。
最后是关于一些AI的话题，这个就不过多介绍了，和大多数读者没关系。
如果这个文章对你有帮助，不要忘记 「在看」 「点赞」 「收藏」 三连啊喂！
Flink CDC我吃定了耶稣也留不住他！| Flink CDC线上问题小盘点