本文整理自阿里云高级开发工程师，Flink Committer 罗宇侠老师在 Flink Forward Asia 2024上海站分论坛流批一体（二）中的分享，内容主要分为以下四个部分：
一、湖流割裂的现状和挑战
二、Fluss 湖流一体架构
三、湖流一体架构的收益
四、未来规划
在大数据处理领域，Lambda 架构是使用非常广泛的一种架构。Lambda 架构将数据处理分成单独的两条链路，一条是离线计算链路，通常由 Hive 作为离线计算链路的存储，另外一条是实时链路，通常由流存储，如 Kafka 作为实时链路的存储。
随着技术的演进， Apache Paimon，Apache Iceberg ，Apache Hudi 等湖存储在支持大数据量的批式计算的基础上，还可以提供分钟级别的数据新鲜度，Lamda 架构中的两套不同的存储逐渐被统一的数据湖存储替代了。数据湖统一存储极大地简化整个架构，并且可以同时满足离线和近实时（分钟级别数据新鲜度）的需求，逐渐开始变得流行。
尽管数据湖统一存储架构非常简洁和高效，但是最多只能提供分钟级别的数据新鲜度。虽然部分场景对数据新鲜度要求不高，但是数据新鲜度的重要性依然不容忽视。在对数据新鲜度具有强诉求（秒级延迟）的场景下，如实时用户圈选，异常检测，广告归因等等，不可避免地将在整个架构中又引入可以提供秒级数据新鲜度的流存储，如 Kafka。
湖流割裂面临的挑战
当引入 Kafka 后，整个架构又回到了 Lambda 架构了，依然是两套存储，只不过传统的 Lambda 架构的 Hive 换成了湖存储而已。
湖存储和流存储割裂地混在 Lambda 架构当中，湖流割裂在架构层面和数据层面都面临着不小的挑战：
引入流存储本身并不是一个问题，天下没有免费的午餐，要秒级的数据新鲜度势必要引入流存储。核心问题在于不能让流存储和湖存储互相割裂，理想的架构应该是流和湖互为一体，互为补充，湖提供高效的历史数据处理能力，而流存储提供秒级数据新鲜度和Serving 能力。
业界知名的流存储厂商也在湖流一体方向上做了不少工作，Kafka 的商业化公司 Confluent 提出 TableFlow，Kafka 中的数据将被 TableFlow 转成 Iceberg 格式，分析引擎可以直接在 Iceberg 格式的数据上进行高效查询；RedPanda 公司也提出了 Iceberg Topic，如果一个 Topic 是 Iceberg Topic，数据也将同时转成 Iceberg 格式，分析引擎也可以查 Iceberg 格式的表。
可以看到，流和湖之间正在逐步靠拢，各补所长，可以预见，未来流和湖的结合只会越来越紧密。不过他们提出的湖与流的结合还有很多改进空间，比如数据依然存在冗余存储的问题，读依然是两套 API 等。并且它们其实是自己在已有的流存储的基础上与湖进行结合，很难做到完美融合，比如流存储在数据分布上其实就很难和湖存储对齐，湖存储有分区表的概念，但是Kafka 就没有。当然，还会有各种各样的其他的问题，简而言之，它们并不是湖原生的。