这是 Fluss 系列的第四篇文章了，我们先回顾一下前面三篇文章主要说了哪些内容。

1. Fluss 部署，带领大家部署Fluss 环境，体验一下 Fluss 的功能
2. Fluss 整合数据湖的操作，体验Fluss 与数据湖的结合
3. 讲解了 Fluss、Kafka、Paimon 之间的区别和联系

前面三篇文章可以让大家上手玩起来 Fluss 这个框架，并说明了它与 Kafka、Paimon 数据湖的关系，接下来的文章

就深入 Fluss 细节来说一下它的实现原理了，今天给大家带来的是 Fluss 架构方法的知识。

Fluss 架构

Fluss 集群由两个主要进程组成：CoordinatorServer 和 TabletServer。

从上面的图片看 Fluss 是一个典型的主从架构，有Client、CoordinatorServer 、TabletServer等进程，我第一眼看到这个架构感觉就有点熟悉，这分区多副本和 Kafka 架构非常像。

下面我通过一条数据的生命周期的小故事给大家描述 Fluss 架构中这些服务组件的主要功能和工作流程。

1. 小数据的诞生（Client：我是从哪里来的？）

一个风和日丽的早晨，小数据“订单 1001”诞生了。它的妈妈是个电商用户小明，爸爸是一条代码（API）。小明通过 Fluss 的 App（Client）下了一单，内容如下：

订单号：1001，金额：4999 元，状态：待发货，时间：2024-12-25 09:00:00

在被创建的瞬间，小数据便穿过了网络，奔向 Fluss 的大门。它的梦想是被记录、管理、查询，甚至有朝一日成为运营分析的明星数据！

2. 走进总部大脑（CoordinatorServer：一个靠谱的“人生规划师”）

小数据“订单 1001”刚一到达 Fluss，就立刻被送到了 CoordinatorServer（总部控制中心），它可是 Fluss 的大脑！CoordinatorServer 一看到小数据，立刻开始规划它的未来，像极了一个靠谱的职业规划师：

• 元数据登记：CoordinatorServer 先给小数据发了个“身份证”，记录了它的订单号、金额、状态和时间。
• 分配节点：CoordinatorServer 仔细分析了一下，“东区分拣中心（TabletServer）”距离小明最近，于是决定把小数据送过去。
• 资源平衡：东区最近有点忙，但 CoordinatorServer 坚信可以处理好这个订单，偶尔也会平衡任务给其他中心。

规划好这一切后，CoordinatorServer 给小数据指了条明路：“去吧，到东区分拣中心报道！”

3. 踏上分拣之旅（TabletServer：我在哪里存活？）

小数据一路风尘仆仆，终于来到了 东区分拣中心（TabletServer）。这里是 Fluss 的数据加工厂，专门负责记录、存储和查询小数据。

东区分拣中心一看到小数据，马上给它安排了两份档案：

• LogStore（日志部门）：
  LogStore 是个勤劳的“打工人”，专门记录小数据的每一步人生足迹：

  [时间：2024-12-25 09:00:00] 创建订单：订单号 1001，状态：待发货
  

  ​ 小数据兴奋极了：“我的人生从这里被记录下来啦！”

• KvStore（仓库）：
  KvStore 是分拣中心的“仓库管理员”，专门保存小数据的状态和内容，以备后续查询。KvStore 给小数据安排了个“货架”：

  货架位置：东区仓库 001，数据状态：待发货
  

​ “好耶！”小数据开心地在自己的货架上安顿下来。

4. 人生中的更新（LogStore + KvStore：我的状态变了！）

就在 9:30，小数据的人生迎来了第一个重要的“更新”。妈妈小明得到了快递信息：“您的订单已发货！”

于是，小数据的状态从“待发货”更新为“已发货”。分拣中心马上展开协作：

1. LogStore 记录变更： LogStore 再次记录下小数据的人生足迹：

   [时间：2024-12-25 09:30:00] 更新状态：已发货
   

2. KvStore 更新状态： KvStore 将仓库里的数据替换为最新状态：

   货架位置：东区仓库 001，数据状态：已发货
   

小数据感叹：“原来我的人生是可以改写的！”

5. 跨仓储的挑战（ZooKeeper：保持系统秩序）

东区分拣中心最近有点忙，有些数据开始超载。就在这时，Fluss 的 “通信协调员”（ZooKeeper）站了出来：“不用慌！一切有我协调。”

ZooKeeper 通知总部，将一部分数据任务转移到北区的分拣中心，以确保整个系统的平稳运行。小数据惊叹：“原来我有这么多后备选项！”

6. 历史的归宿（Remote Storage：成为数据档案）

随着时间的推移，越来越多的数据涌入东区分拣中心，小数据意识到它的时代要结束了。

为了让分拣中心有更多存储空间，小数据和它的伙伴们被转移到了 远程云存储（Remote Storage）。这就像是档案馆，它保存了所有历史数据。

“虽然我不再活跃，但我的人生还会被查阅！未来的人们可以分析我。”小数据在档案馆安然入眠。

7. 被召唤的高光时刻（查询 + 分析）

就在小数据以为自己会默默无闻地躺着时，突然，一条查询指令将它唤醒：

SELECT status FROM orders WHERE order_id = 1001;

系统快速检索：

• LogStore 提供了变更日志，追踪它的所有历史记录。
• KvStore 提供了最终的状态。

小数据以它的最新状态“已发货”再次出现在查询结果中：“原来，我一直在被需要！”

到了年底，Fluss 公司还通过批量分析指令：

SELECT SUM(amount) FROM orders WHERE year(order_time) = 2024;

运营团队惊喜地发现，小数据贡献了 4999 元销售额！“我成了分析中的重要一环！”

Fluss 小数据的一生

专业解释

下面是 Fluss 架构里面这些进程的详细专业解释：

CoordinatorServer

CoordinatorServer 是集群的核心控制和管理组件，主要负责以下任务：

• 元数据管理：维护元数据。
• 节点分配管理：管理 Tablet 的分配和节点列表。
• 权限管理：处理用户和服务权限。

此外，CoordinatorServer 负责以下关键操作：

• 数据再平衡：在节点扩展或缩减时重新分配数据。
• 数据迁移：当节点发生故障时，管理数据迁移和服务节点切换。
• 表管理：创建或删除表，更新桶（Bucket）的数量。

CoordinatorServer 是整个集群的大脑，确保资源高效分配与无缝管理。

TabletServer

TabletServer 负责数据存储、持久化，并直接为用户提供 I/O 服务。它由以下两个关键组件组成：

1. LogStore：用于存储日志数据，类似数据库的 binlog（变更日志）。
2. KvStore：用于存储表数据，支持更新和删除。

不同表类型对应的行为：

• 主键表（PrimaryKey Table）：支持更新操作，使用 KvStore 存储表数据，并使用 LogStore 存储变更日志。
• 日志表（Log Table）：仅支持追加写入，主要依赖 LogStore 优化写入性能。

LogStore

• 专为存储日志数据而设计，类似于数据库的 binlog。
• 数据只能追加，不可修改，确保数据完整性。
• 主要用于低延迟的流式读取，同时作为 KvStore 的预写日志（WAL）。

KvStore

• 用于存储表格化数据，支持高效的查询、更新和删除操作。
• 生成完整的变更日志以追踪数据修改。
• 适用于需要频繁数据操作的场景。

Tablet / Bucket

• 数据根据桶策略分为多个桶（Bucket）。
• 每个 Tablet 包含 LogTablet 和（可选的）KvTablet，具体取决于表是否支持更新。
• Tablet 通过复制（Replication）机制确保高可用性。
• 注意：目前，KvTablet 不支持复制。

ZooKeeper

• Fluss 当前使用 ZooKeeper 进行集群协调、元数据存储和配置管理。
• 未来版本中，计划用 KvStore 替代 ZooKeeper 的元数据存储功能，并使用 Raft 协议实现集群协调和一致性。

远程存储（Remote Storage）

远程存储主要有两个用途：

1. 分层存储（LogStores）：

• • 减少 LogStore 数据的存储成本。
  • 加速扩展操作。

1. 持久化存储（KvStores）：

• • 为 KvStore 提供持久化存储。
  • 与 LogStore 协作，实现故障恢复。

未来计划支持批量写入操作，优化数据导入流程并提高性能。

客户端（Client）

Fluss 提供的客户端/SDK 支持以下操作：

• 流式读写
• 批量读写
• 数据定义语言（DDL）操作
• 主键点查（Point Queries）

目前，主要的客户端实现是 Flink Connector，用户可以通过 Flink SQL 轻松操作 Fluss 的表和数据。

写在最后

这篇文章说了Fluss 架构中的服务组件的职能和工作流程，后面会对 Fluss 查询数据湖和本地数据合并部分做讲解。欢迎大家关注 "大圣数据星球"一起来讨论大数据技术。