Fluss：新一代流存储核心技术解析

摘要：近年来，大数据计算正经历一个显著的趋势转变——从离线处理向实时化迈进，各行各业的多种应用场景都在加速这一进程。这种技术变迁不仅体现在架构上，还深刻影响了业务需求的时效性。

导读本次分享题目为 Fluss：新一代流存储核心技术解析。

主要介绍：

1. Fluss 诞生背景

2. Fluss 核心功能与实现原理

3. Fluss 未来规划

4. 参与 Fluss 社区

5. 问答环节

分享嘉宾｜郑云红阿里云计算有限公司研发工程师

编辑整理｜Kathy

内容校对｜李瑶

出品社区｜DataFun

Fluss 诞生背景

1. 行业趋势：从离线走向实时化

近年来，大数据计算正经历一个显著的趋势转变——从离线处理向实时化迈进，各行各业的多种应用场景都在加速这一进程。这种技术变迁不仅体现在架构上，还深刻影响了业务需求的时效性。

传统的大数据计算架构通常是基于以 Hive 为代表的传统数仓，随后引入了 Lakehouse 湖仓架构，继而又发展到当前国内流行的 Paimon 流式湖仓架构。这些架构演进的核心驱动力是业务时效性的不断提升：从传统的 T+1（天级）到 T+1h（小时级），再到 T+1m（分钟级）。然而，基于文件系统的存储在达到分钟级延迟后遇到了瓶颈，难以满足秒级实时性的需求，特别是在搜索推荐、广告归因等场景中，对秒级响应的要求尤为迫切。大数据技术发展至今，仍缺乏一款理想的秒级存储解决方案。

2. 现有实时数仓典型架构的局限性

在提及秒级存储时，Kafka 是最常被想到的名字。Flink 与 Kafka 的组合已成为构建实时数仓的典型架构，因其能够提供低延迟的数据传输和处理能力。然而，这一组合在应用于大数据分析时面临诸多挑战：

（1）不支持更新操作：

Kafka本身不具备更新能力，这使得修正数据变得困难。更糟糕的是，它会保存重复的数据，导致计算引擎需要承担额外的去重成本，这对性能提出了严峻考验。

（2）缺乏数据探查功能：

数据探查是数仓建设中的基础能力之一，但 Kafka 更像是一个“黑盒”，无法直接查询数据，增加了问题排查和数据探索的难度。

（3）数据回溯复杂且昂贵：

数仓中频繁的数据回溯操作，在 Kafka 中却异常艰难且成本高昂。由于 Kafka 通常只保留几天的数据，并且大规模数据回溯需通过 Broker 节点，这不仅降低了回溯效率，还会抢占 Broker 资源，影响其他在线业务。

（4）网络成本高：

网络传输成本占据了 Kafka 整体成本的 80% 以上。尤其在一写多读的场景下，每个消费者仅使用部分数据列，但却需承担全部网络传输开销，造成极大浪费。

3. 为什么要做 Fluss ？

鉴于上述问题，尤其是现有解决方案难以充分满足秒级实时性和高效数据分析的需求，Fluss 应运而生。Fluss 旨在解决以下关键问题：

提升数据新鲜度至秒级：超越传统文件系统所能提供的分钟级延迟，实现更快速的数据访问。为流分析场景设计：不同于 Kafka 主要面向消息队列的设计，Fluss 专注于流式数据分析，提供了更适合此类场景的功能特性。统一管理和优化：寻求一种方法来统一管理湖和流。

Fluss 核心功能与实现原理

1. Fluss : 基础架构

Fluss 是一款专为实时分析设计的流存储引擎，它深度融合了 Lakehouse 架构。

其基础架构特点如下：

热数据本地化：热数据存储在本地服务器上，并持续同步到远程存储。冷数据归档：通过一个 Compaction Service 将冷数据归档至数据湖中。读写支持：既支持流式读写操作，也支持点查（point query），并能无感读取数据湖中的冷数据。

Fluss 的核心特性包括：流式读写、列式裁剪、流式更新、 CDC 订阅、实时点查、湖流一体。

2. Fluss：核心组件

Fluss Cluster：由 Coordinator Server 和 Tablet Server 组成。

Coordinator Server：作为集群的中心控制节点，负责元数据管理、Leader 分配和权限管理。Tablet Server：数据存储节点，包含 Log Store 和 KV Store。KV Store：支持更新和点查操作。Log Store：存储更新产生的 Change Logs。

Fluss Client：客户端组件，用于与 Fluss 集群交互。

ZK（ZooKeeper）：用于集群协调和元数据管理。

Remote Storage：远程存储，用于冷数据的归档。

3. 核心功能及其实现原理

（1）流式列存储

Fluss 采用流式列存储格式，重点优化了列裁剪能力。具体实现如下：

•列裁剪：Fluss 采用 Apache Arrow 的 IPC Streaming Format 协议进行文件存储，基于 Arrow 实现高效的列裁剪性能，保持流式读写的毫秒级延迟，节省大量网络成本。读取时支持端到端的 Zero-copy。列压缩：从 V0.6 版本开始，Fluss 支持列压缩，压缩比可达 7 倍，支持 ZSTD 和 LZ4 压缩算法。

（2）实时更新与 CDC

为了支持高效的实时更新，Fluss 结合了 Log Tablet 和 KV Tablet，具体机制如下：

底层结构：以 Log Tablet 为基础，在其上构建 KV 索引，支持大规模实时更新。KV 更新会生成 Changelogs，写入 Log Tablet。故障恢复：在故障恢复时，Log Tablet 数据用于恢复 KV Tablet。流读 Changelog 无需去重：KV 表生成的 Changelog 可直接流式读取，无需额外去重，节省计算资源并促进数据复用。

Merge Engine：从 V0.6 版本开始，Fluss 支持按不同 Merge Engine 进行更新，包括 First Row 和 Version-Based Merge Engine。First Row：对于同一主键（PK），只写入第一次的值，下游 Changelog 输出 append_only 流。Version-Based：根据表的某个字段（如 Event_time）进行更新，选择值更大的记录进行更新。

（3）Delta Join

Flink 中的双流 Join 功能用于构建宽表，但需要在 State 中维护上游全量数据，导致状态过大，资源消耗高。Fluss 结合 Flink 推出了 Delta Join 算子，利用 Fluss 的 CDC 流读和索引点查能力，实现双边驱动的维表 Join。

实现逻辑：左右流均为 Fluss 表，当 Log 到达时，根据 Join Key 进行点查。如果 Local Cache 未命中，则通过 Flink 的 Async Lookup 算子查询 Fluss。性能优化：Delta Join 可以显著减少 Flink 的状态大小，降低资源消耗。以淘宝成交作业为例，该作业原本需要消耗 50TB 的状态，迁移到 Delta Join 后，不仅减免了大状态带来的成本，还提高了作业的稳定性和效率。Flink 的资源从 2300 CU 降低到 200 CU。回溯优化：利用归档到 Paimon 表的冷数据和 Flink Batch join 进行高效的历史数据回溯，大幅缩短处理时间。例如，将一天的数据回溯时间从以前的 4 小时降低到 0.5 小时。灵活性提升：Delta Join 将状态与作业解耦，使用户可以更灵活地修改作业逻辑而不需重新计算状态。且支持可探查和可分析的数据，提升业务灵活性和开发效率。
Flink Delta Join 算子：Flink 侧引入 Delta Join 算子，支持流式 Join 操作。算子内部通过 Async Lookup 算子异步查询 Fluss，确保低延迟和高吞吐量。

Fluss 侧的 Prefix Lookup：为了支持 Delta Join，Fluss 引入了 Prefix Lookup 功能。在表的 Primary Key 前添加 Bucket Key 作为前缀，确保数据在存储时按照 Bucket Key 进行分区。通过 Prefix Lookup，Flink 可以直接定位到所需的 TableServer 和 Bucket，避免网络放大问题，显著提升查询效率。

（4）为什么要做湖流一体

为了解决传统架构中湖和流割裂的问题，Fluss 推出了湖流一体特性，旨在统一管理湖存储和流存储的数据。

在现代数据处理架构中，湖存储和流存储通常被分开设计和管理。这种割裂的架构带来了诸多问题：

架构复杂性：需要维护两套独立的存储和代码。资源浪费：相同的计算逻辑需要计算两遍。数据一致性难以保证：流存储和湖存储之间的数据一致性难以保证，通常需要工程师手动干预。数据冗余：同样的数据可能会在湖和流中各存一份，增加了存储成本。

为了解决上述问题，Fluss 推出了湖流一体特性，旨在统一管理和优化湖存储和流存储的数据处理流程，从而避免了数据的冗余存储。在底层，Fluss 会维护一个 Compaction Service，自动将 Fluss 数据转为湖格式数据，并且保证两边元数据的一致，在读的时候可以通过 Fluss 直接完成对 lakehouse 上数据的操作。因此，Fluss 湖流一体简化了整体架构，降低了成本，并提高了数据的一致性和实时性。

统一元数据：确保湖和流两层数据的一致性，减少冗余存储，仅需维护一份元数据。Fluss 维护了一个统一的 Catalog，无论是流数据还是湖数据，都可通过这个单一入口访问。数据分布对齐：Fluss 的 Bucket 和数据湖中的 Bucket 一一对应，分区也是一一对齐的，确保了数据在存储和管理上的统一。
联合读取：提供对湖和流数据的统一读取接口，使得两者能够相互补充，形成完整的时间线视图。Union Read 功能让用户可以在一次查询中同时获取流数据和历史湖数据，实现秒级新鲜度的分析。开放兼容性：遵守湖的开放格式标准，允许其他查询引擎无缝对接，扩展数据分析能力，即下图中提到的 DataLake Reads 功能。Fluss 目前已完成与 Paimon 的全面集成，正在做 Lakehouse API 的抽象，后续将对接 Iceberg、Hudi、DeltaLake 等更多数据湖引擎。

Fluss 未来规划

Fluss 规划中的工作主要包括以下几大方面。

1. 架构完善

去除 Zookeeper，引入 Raft 协议优化集群运维手段：Re-balance、灰度升级等Zero Disks 架构，完全消除对本地磁盘的依赖

2. 深度集成 Flink

支持 Flink Data Stream API支持各种 Pushdown 优化为 Flink Cost-Based 优化提供存储支持

3. 增强湖流一体能力：

通用 API 抽象，并支持 lcebege、DeltaLake、HudiLake tiering Service 服务内置Union read 对接其他查询引擎

4. 生态集成

兼容 Kafka API丰富 Connector 支持：Spark、Presto、DuckDB

参与 Fluss 社区

Fluss 开发团队非常欢迎大家参与到 Fluss 的开发和讨论中来。以下是几种主要的参与方式和支持资源。

获取源码与文档

GitHub链接：https://github.com/alibaba/fluss文档地址：https://alibaba.github.io/fluss-docs/钉钉群

问答环节

Q1：是否必须有 Lakehouse Storage 支持历史数据层？

A1：在 Fluss 的架构中，虽然使用 Lakehouse storage（如 Lakehouse）作为冷数据管理层是一种优化策略，但它并非强制要求。Fluss 集群本身具备 remote storage 功能，可以作为冷数据的存储位置。Remote storage 不仅充当了冷数据的存储角色，而且其存储成本相对较低，比存储在 Tablet Server 上更加经济。

Q2：是否会增加一些 Good First Issue 来帮助新人上手？

A2：是的，Fluss 社区已经在 GitHub 上标记了一些 "good first issue"，这些任务适合新手快速上手。这类任务通常包括一些小规模的架构调整和测试完善。如果有任何疑问或需要帮助，社区成员可以通过钉钉群等渠道进行交流，并获得及时的支持。

Q3：当 Remote Storage 是 HDFS 时，点查场景是否有性能影响？

A3：目前点查不会受到性能影响，因为 Fluss 会维护一个全量的 Snapshot。点查操作会经过 Service Server 层。

Q4：Fluss 和 Paimon 的适用场景及其优缺点是什么？

A4：

Fluss：主要定位于提供秒级的新鲜度和点查能力，特别适用于需要高实时性的应用场景。它的设计目标是在秒级范围内提供高效的数据处理和分析能力。Paimon：与 Fluss 结合使用时，能够补充 Fluss 在冷数据管理和低成本存储方面的不足。Paimon 擅长于长期数据存储和大规模数据分析，具有较高的成本效益。两者结合使用可以实现优势互补：数据新鲜度：Fluss 提供秒级的新鲜度，而 Paimon 则用于长期数据存储和分析。分析能力与成本：Paimon 具备强大的分析能力和较低的存储成本，Fluss 可以借助这种低成本特性来提高整体系统的经济效益。此外，两者联合使用还能提供统一的 Union Read，使得用户可以在一次查询中同时访问实时和历史数据，进一步提升分析灵活性和效率。

以上就是本次分享的内容，谢谢大家。