揭秘Fluss 与 Kafka、Paimon 的区别与联系

当 Fluss 出来之后，很多人都对 Fluss 的定位有些疑惑，有的人说是代替 Kafka 的，有的人说是代替数据湖的，我想每一个关注大数据的小伙伴们都有自己的想法。

这篇文章我就来表达一下自己的观点，个人觉得没有谁替代谁这么一说，只是不同的场景用不同的技术。下面我对这三个框架说一下自己的理解。

我们可以这样理解为：

• Kafka 是一条快速的“数据高速公路”，负责让数据高效流动。
• Fluss 是一个强大的“实时仓库”，既能存储流数据，也能进行实时分析。
• Paimon 是一个“历史档案馆”，用来保存并查询长期存储的数据。

例如，我们经营一家电商平台，需要对订单数据进行处理：

1. 用户下单时，数据需要快速传递到后台（Kafka）。
2. 实时计算销售总额和库存变化（Fluss）。
3. 长期保存订单数据，供月度报表分析使用（Paimon）。

Kafka 在大数据场景下一些缺陷

1. 缺乏分析能力

问题：

Kafka 的主要功能是数据传输，不具备直接分析数据的能力。如果需要对 Kafka 中的数据进行分析，必须借助外部的计算引擎（如 Flink 或 Spark），并且需要额外导出数据到存储系统（如 HDFS 或数据库），这增加了延迟和系统复杂度。

举例：电商平台统计过去 1 分钟的销售总额

Kafka 的流程

1. 用户 A 下单：

   订单ID: 001, 金额: 5000, 时间: 2024-12-25 10:00:00。

   数据写入 Kafka 的 order_topic，写入延迟通常在毫秒级别。

2. 用户 B 下单：

   订单ID: 002, 金额: 2000, 时间: 2024-12-25 10:00:30。

   同样被写入 Kafka。

3. 数据消费和存储：

   • 外部计算引擎（如 Flink）从 Kafka 消费数据。
   • 数据被存储到 HDFS 或数据库，以便后续查询。

4. 数据分析：

   • 计算引擎执行查询：

     SELECT SUM(amount) FROM orders WHERE order_time > CURRENT_TIMESTAMP - INTERVAL '1' MINUTE;

   • 查询结果返回，总销售额为 7000。

问题：

1. 复杂性

   • Kafka 只是传输数据，分析需要依赖外部计算引擎，系统组件多，逻辑复杂。

2. 延迟来源

   • 数据从 Kafka 消费到存储系统、计算引擎运行任务的整体耗时，可能达到秒级甚至更高。

---

Fluss 的解决：优化分析路径

Fluss 的设计：

1. Fluss 不仅能存储流数据，还具备内置的分析能力。
2. 用户无需额外的计算引擎，即可直接查询 Fluss 中的数据。

Fluss 的流程

1. 用户 A 下单，数据直接写入 Fluss 的 Log Store

   订单ID: 001, 金额: 5000, 时间: 2024-12-25 10:00:00。

2. 用户 B 下单，数据同样写入 Fluss：

   订单ID: 002, 金额: 2000, 时间: 2024-12-25 10:00:30。

3. 数据分析：

   • 直接在 Fluss 中运行 SQL 查询：

     SELECT SUM(amount) FROM orders WHERE order_time > CURRENT_TIMESTAMP - INTERVAL '1' MINUTE;

   • 查询秒级返回结果，总销售额为 7000。

优势：

1. 简化架构

   • 数据写入 Fluss 后直接分析，无需额外的计算引擎或存储系统。

2. 低延迟

   • 查询直接运行在 Fluss 的数据存储上，无需额外的消费和存储过程。

2. 数据存储短期化

问题：

Kafka 的数据保留时间通常是几天（通过 Retention 配置），超过这个时间的数据会被自动清理。适合实时数据传递，但不适合长期存储和历史数据管理。

举例：

场景：电商平台需要分析过去一年的销售数据。

• Kafka 的限制：

  1. Kafka 中只能保留最近 7 天的数据（例如配置 Retention=7d）。
  2. 超过 7 天的订单数据会被清理，导致无法查询历史订单。

• 问题：

  • Kafka 无法长期存储数据。
  • 必须额外导出数据到数据湖（如 HDFS 或 Paimon）进行管理。

• Fluss 的解决：

  1. Fluss 可以将实时数据存储在 Log Store 中，并通过 Compaction Service 定期将数据整理为 Paimon 格式（如 Parquet 文件）。
  2. 长期数据存储在远程存储（如 S3 或 HDFS），方便后续批量分析。

  3. 用户可以查询过去一年每个月的销售额：

     SELECT MONTH(order_time), SUM(amount) FROM orders GROUP BY MONTH(order_time);

3. 重复消费和性能瓶颈

问题：

在多消费者的场景下，Kafka 数据会被多个消费组重复拉取，导致网络和存储压力增加。此外，Kafka 的日志存储只能追加写入，不支持高效的实时更新。

举例：

场景：电商平台需要更新订单状态，并实时查看每个用户的订单数量。

• Kafka 的流程：

  1. 用户 A 创建订单：订单ID: 001, 状态: Pending。
  2. 订单状态更新为：订单ID: 001, 状态: Confirmed。

  3. Kafka 的日志存储只支持追加写入，更新后的订单会作为新记录写入：

     • 订单ID: 001, 状态: Pending
     • 订单ID: 001, 状态: Confirmed
  4. 消费者需要额外处理重复的状态记录。

• 问题：

  • 数据冗余增加，导致存储和网络成本增加。
  • 数据更新效率低。

• Fluss 的解决：

  1. Fluss 在日志表之上构建了 键值索引（Key-Value Index），支持高效的主键更新和查询。

  2. 订单状态更新可以直接覆盖旧记录：

     sql
     
     
     复制代码
     UPDATE orders SET status = 'Confirmed' WHERE order_id = '001';

  3. 数据更新后的结果：

     • 订单ID: 001, 状态: Confirmed（旧记录被覆盖）。

  4. 实时查询每个用户的订单数量：

     SELECT user_id, COUNT(*) FROM orders GROUP BY user_id;

Fluss 和 Paimon 数据湖的联系和区别

Fluss 和 Paimon 是大数据存储和处理领域的两种工具，它们各自有专注的场景，但也可以无缝结合使用。通过一个通俗易懂的例子来说明两者的联系和区别。

---

1. 简单定义

• Fluss：流存储，专注于实时数据的高效写入和查询，适合处理短期的数据分析和更新。
• Paimon：数据湖，专注于长期存储和批量分析，适合管理历史数据和大规模计算。

两者的关系

• Fluss 是数据流的入口，接收和存储实时写入的数据。
• Paimon 是数据流的出口，用于存储整理后的长期数据。
• Fluss 和 Paimon 通过“流湖一体”架构连接，实时数据从 Fluss 同步到 Paimon，Paimon 负责长期存储和批量分析。

---

2. 举例：电商平台订单系统

场景描述

某电商平台有一个订单系统，记录用户的下单和状态更新。假设用户的数据变化如下：

1. 实时写入数据：用户 A 下单，订单状态从 Pending 到 Confirmed。
2. 长期存储需求：系统需要记录所有订单的完整历史，用于年终分析。

---

2.1 Fluss 的工作流程

1. 用户 A 下单：

   订单ID: 001, 用户ID: A, 金额: 100, 状态: Pending, 时间: 2024-12-25 10:00:00。

   数据被写入 Fluss 的 Log Store，实时存储，供秒级查询。

2. 用户 A 更新订单状态：

   订单ID: 001, 用户ID: A, 金额: 100, 状态: Confirmed, 时间: 2024-12-25 10:05:00。

   新数据也实时写入 Fluss，覆盖旧状态（基于主键去重）。

实时查询：

• 用户希望查看订单的最新状态：

  SELECT * FROM orders WHERE order_id = '001';

  Fluss 返回最新状态：

  订单ID: 001, 用户ID: A, 金额: 100, 状态: Confirmed。

---

2.2 Paimon 的工作流程

1. Fluss 定期将数据同步到 Paimon：

   • 用户的订单记录被整理成 Paimon 的批量存储格式（如 Parquet 文件）。

   • 假设 Fluss 中的状态变化如下：

     Fluss 日志：
     [Offset=1] 订单ID: 001, 用户ID: A, 金额: 100, 状态: Pending。
     [Offset=2] 订单ID: 001, 用户ID: A, 金额: 100, 状态: Confirmed。

   • Paimon 存储最终整理后的数据（合并 Fluss 的日志）：

     Paimon 数据：
     订单ID: 001, 用户ID: A, 金额: 100, 状态: Confirmed。

2. 长期分析：

   • 年终，运营团队需要分析全年订单的状态和金额分布：

     SELECT COUNT(*) AS total_orders, SUM(amount) AS total_revenue FROM orders$lake WHERE year(order_time) = 2024;

   • Paimon 提供大规模批量查询的支持，返回结果：

     total_orders: 1000000, total_revenue: 50000000。

---

2.3 Fluss 和 Paimon 的联合查询

1. 用户需要实时查询所有订单的最新状态：

   • Fluss 读取最新的日志数据。
   • Paimon 提供历史快照数据。

2. 查询逻辑：

   • Fluss 和 Paimon 的数据合并时，通过主键去重：

     • Paimon 提供历史快照（订单ID: 001, 状态: Pending）。
     • Fluss 提供实时更新（订单ID: 001, 状态: Confirmed）。

   • 最终查询结果：

     订单ID: 001, 用户ID: A, 金额: 100, 状态: Confirmed。

---

3. 区别总结

特性	Fluss	Paimon
定位	实时流存储，适合短期数据处理	长期数据存储，适合历史数据分析
性能优化	秒级写入和查询，支持实时更新	高效批量存储，支持大规模查询
存储方式	日志存储（Log Store）	文件存储（如 Parquet）
应用场景	查询最新状态、实时流分析	大规模历史数据分析、离线计算
数据生命周期	短期存储（实时数据更新）	长期存储（历史数据）
典型查询	查询最新订单状态：SELECT *	查询全年收入：SELECT SUM(amount)

写在最后

上面列举了一些Kafka 在大数据分析领域目前可能存在的劣势，但是不是说 Fluss 就能代替 Kafka ，这显然是不现实的。Kafka 的超高性能，系统解耦，稳定度，社区活跃度等这些都是非常好的，只能说每个服务组件都有自己的应用的场景。

这篇文章也只是站在大数据分析场景中讨论 Fluss、Kafka、Paimon 的一些特点。后面会给大家更新 Fluss 的数据查询方面的知识，欢迎大家一起来讨论。