摘要：本文整理自阿里云智能 Flink SQL和数据通道负责人、Apache Flink PMC 伍翀（花名：云邪）老师，在 Flink Forward Asia 2024 主会场的分享。主要分享了一种专为流分析设计的新一代存储解决方案——Fluss，并由阿里巴巴开源委员会副主席王峰先生，在 FFA 2024 现场进行了 Fluss 项目的开源。内容分为以下五个部分：

一、Kafka 在实时分析场景遇到的问题

二、Fluss：Flink Unified Streaming Storage

三、Fluss 核心特性

四、Fluss 未来规划

五、Fluss 开源

当前业界呈现出一个显著的趋势，即大数据的处理正在从离线模式转向实时化。我们可以观察到，多个行业和应用场景都在进行实时化的演进。例如，互联网、车联网和金融等领域都正通过挖掘实时数据来提升业务价值。

在技术方面，大数据计算架构经历了显著的演变。从最初的 Hive 传统数据仓库，到引入 Lakehouse 湖仓架构，再到目前国内流行的 Paimon 流式湖仓架构，这些演进的核心驱动力在于提升业务的时效性。从传统的 T+1 天模式，逐步缩短到 T+1 小时，再到 T+1 分钟。然而，由于湖存储架构是基于文件系统的，其分钟级延迟几乎是极限。但是许多业务场景，如搜索推荐、广告归因和异常检测，都要求秒级的实时响应。因此，业界亟需能够支持秒级存储的解决方案。尽管大数据技术已经取得了长足的发展，但在大数据分析场景中，仍然缺乏一款能够有效支持秒级存储的解决方案。

那么在大数据里面最常用的秒级存储是什么呢？当然是 Apache Kafka。Flink 与 Kafka 的组合也已经成为业界构建实时数仓的典型架构。然而，这个组合在实际应用中并不总是那么理想，原因在于当我们将 Kafka 应用于大数据分析时，会遇到一系列挑战和问题。

Kafka 在实时分析场景遇到的问题

一个主要的问题是，Kafka 不支持数据更新功能。在数据仓库中，“更新”是一个非常重要的功能，对于一个数仓来说，经常需要“更新”的能力去修正一些数据。由于 Kafka 不支持更新，所以它只能将主键上重复的数据都存储下来。当计算引擎消费这些数据时，就会接收到重复的数据。

为了确保计算结果的准确性，计算引擎必须执行去重操作。然而，这个去重过程本身是非常耗费资源的。在 Flink 中，这需要使用 State 来物化上游的全部数据，并且每次消费 Kafka 数据时，都必须承担去重的成本，这个成本是相当高的。这种高成本的去重要求限制了 Kafka 数据的业务复用能力。例如，在淘天集团构建实时数据中间层的过程中，由于 Kafka 的这些限制，他们选择不构建 DWS 层。

第二个主要问题是，Kafka 不支持数据探查功能。在数据仓库建设中，数据探查是一个基本能力。无论是排查问题还是进行数据探索，都需要进行数据查询。然而，Kafka 本质上是一个黑盒，不支持直接查询。为了解决这个问题，业界通常采用两种方案：

同步到 OLAP 系统：将 Kafka 数据同步到 OLAP 系统中进行查询。不过，这种方法会引入额外的系统组件，增加复杂性和成本。此外，数据在不同系统间的同步也可能导致不一致性。
使用 Trino 等查询引擎直接查询 Kafka：这种方法避免了数据同步问题，但由于 Kafka 仅支持 Full Scan，无法实现 Data Skipping，因此在处理大规模数据时效率较低。例如，在 1GB 数据上进行简单查询都可能需要一分钟，这使得这种方法在大规模应用中基本上不可行。

第三个问题是数据回溯的困难。在数据仓库中，数据回溯是常见需求，例如在物流行业中，可能需要回溯几个月的数据进行分析。然而，在 Kafka 中，长时间存储大量数据会导致成本过高，因此通常只能存储几天的数据。此外，当进行大规模数据回溯时，所有数据流量都必须经过 Kafka Broker，这会导致回溯操作的性能非常慢。同时，这种操作还会消耗 Broker 的 CPU 资源，污染其页面缓存（page cache），从而对其他在线业务产生负面影响。