演讲嘉宾｜罗宇侠 天添盈
编辑 ｜ Kitty
策划 ｜QCon 全球软件开发大会
湖仓一体 Lakehouse 凭借其开放性和成本效益，已经成为当今数据平台的主流架构。然而在 LakeHouse 架构下，数据的时效性最多只能达到分钟级。为了满足企业对实时数据分析的需求，通常需要额外引入秒级延迟的流存储（如 Kafka）。流存储游离在 LakeHouse 架构外，带来的成本、一致性、治理等问题都面临很大的挑战。
在 InfoQ 举办的 QCon 全球软件开发大会（北京站）上，阿里云高级开发工程师罗宇侠做了专题演讲“Fluss 湖流一体：Lakehouse 架构实时化演进”，他分享了流存储和 LakeHouse 架构割裂的现状下用户面临的问题和挑战，以及目前业界在融合两者上的趋势。并介绍了流存储 Fluss 如何完美地融入进 LakeHouse 架构，无缝地将 LakeHouse 架构进行实时化改造，深度解析其技术架构和原理，分析该架构相比割裂地使用流存储和 LakeHouse 架构能带来的收益。最后他还分享了基于 Fluss 来构建实时 LakeHouse 架构的最佳实践。
展开剩余95%预告：DeepSeek 的横空出世，对 LLM 领域产生了多维度、深层次的变革，促进了 LLM 技术的民主化及创新的去中心化。将于 10 月 23 - 25 召开的 QCon 上海站设计了「 Data Infra for AI」专题，将从 LLM、多模态数据处理、多模态数据湖、多模态数据管理等方向，结合头部企业实践，探讨大模型时代的 Data Infra 演进方向。敬请关注。
以下是演讲实录（经 InfoQ 进行不改变原意的编辑整理）。
Al 时代湖流融合的趋势
在 AI 时代，湖流融合是一个重要的趋势。一方面，Lakehouse 架构的重要性日益凸显。Lakehouse 架构是开放的，能够存储多模态数据，包括结构化数据和文本、图像等非结构化数据，满足大模型训练对多模态数据的需求。同时，Lakehouse 架构通过统一的 Catalog 管理所有数据，无论是结构化还是非结构化数据，都可以进行数据溯源和权限管理，保证大模型训练数据的质量和可追踪性。其底层依赖廉价的存储，如 OSS、S3 等，这些存储方式成本低，能够应对大模型时代数据量指数级增长的需求。
另一方面，AI 时代需要实时数据，实时数据的重要性体现在多个方面：一是知识库可能会滞后，实时数据能够实时更新数据库和知识库，提升模型的准确性；二是实时数据能够感知用户的上下文，通过传感器等实时获取用户当前状态，从而更精准地满足用户需求；三是实时数据支持模型的在线学习，即模型可以实时进行机器学习；四是实时数据有助于模型根据用户的反馈迭代推理能力。
在湖流融合的业界趋势方面，目前有多种发展方向。例如，Kafka 背后的商业化公司 Confluent 提供了 Tableflow，它将 Kafka 中的业务数据实时导入到数据湖中，其实它就是一个 Flink 作业，但用户无需手动管理 Flink 作业。Red Panda 是一家估值十几亿美元的创业公司，提出了 Iceberg Topic，将数据转化为 Iceberg 湖格式，便于分析引擎进行高效查询和 OLAP 分析。AutoMQ 是国内一家新兴的创业公司，提出了 Table Topic，将 Kafka 数据转化为 Iceberg 湖格式，支持直接在 Iceberg 上进行分析。Pulsar 背后的商业化公司 StreamNative 也提出了类似的思路，这些公司都在积极探索湖流融合的方向。目前，Lakehouse 架构已经在多家公司落地应用，未来 Lakehouse 和实时数据的融合将越来越紧密。
目前这些融合方案大多是基于已有的消息队列进行融合，这就导致与湖的融合或多或少不够直接。
例如 Kafka 是无 Schema 的，无分区概念的，而湖格式却有 Schema 和分区的概念，消息队列和湖很难对齐。因此，我们提出了一种从一开始就面向数据湖设计的实时存储方案 Fluss。
Fluss 湖流一体架构和技术解析
Fluss 湖流一体架构
Fluss 湖流一体的架构如下所示：数据可能来源于消息队列、业务数据库或业务数据，这些数据进入 Fluss 集群。在 Fluss 集群中有一个 Lake Tiering Service，其作用是将数据从 Fluss 集群实时同步到数据湖中。这种同步过程被称为 Tiering（分层），而不是简单的 Copy。通过 Tiering，实时数据被写入数据湖，之后可以使用 Spark， StarRocks，Trino 等工具直接在数据湖上进行高效分析。此外，Fluss 还提供了一个 Union Read（联合读取）功能，即将 Fluss 集群中最新的实时数据与数据湖中稍早的数据（例如 3 分钟前的数据）进行联合，从而得到最新的数据视图。
Fluss 表模型
在深入了解之前，先介绍一下 Fluss 的表模型。Fluss 的表具有分区功能，通过分区列将表分成若干分区，这是数据仓库中的一个重要概念。每个分区还会通过分桶列（Bucket）进一步分桶，以实现分布式高性能的写入和读取。这种表模型与常见的数据湖表模型非常相似，几乎没有区别，这也是为什么说 Fluss 是面向 Lakehouse 架构设计的存储系统。
Fluss 湖流一体技术解析
Lake Tiering Service
接下来是技术解析的核心部分——Lake Tiering Service（数据湖分层服务）。它负责将数据分层写入数据湖。目前，Tiering 服务是一个 Flink 作业，但理论上也可以是 Spark 作业或其他类型的作业，因为其逻辑不依赖于 Flink 的特定特性。整个过程包括三个主要步骤：
Tiering Coordinator：从 Fluss 集群中获取需要 Tiering 的表的信息，并将其分配给 Tiering Worker 进行湖格式转换。
Tiering Coordinator：从 Fluss 集群中获取需要 Tiering 的表的信息，并将其分配给 Tiering Worker 进行湖格式转换。
Tiering Worker：实际执行数据转换工作天添盈，它将 Fluss 集群中存储的数据（以 Arrow 格式存储）转换为湖格式（如 Parquet 文件）。转换完成后，将这些文件信息发送给 Tiering Committer
Tiering Worker：实际执行数据转换工作，它将 Fluss 集群中存储的数据（以 Arrow 格式存储）转换为湖格式（如 Parquet 文件）。转换完成后，将这些文件信息发送给 Tiering Committer
Tiering Commiter：向数据湖提交写入的湖格式，并且将数据湖的快照提交回 Fluss 集群，使 Fluss 集群能够管理和利用这些数据。
Tiering Commiter：向数据湖提交写入的湖格式，并且将数据湖的快照提交回 Fluss 集群，使 Fluss 集群能够管理和利用这些数据。
Tiering 服务是无状态的，这意味着它可以快速进行横向 / 纵向扩展。如果一个 Tiering 服务出现反压（即转换速度跟不上），可以快速启动更多的 Tiering 服务实例，或者增加 Tiering Worker 的并发数量，从而解决转换瓶颈问题。这种无状态设计使得扩容非常迅速，无需进行状态迁移，能够有效应对数据 Tiering 的高压力场景。
Union read
在从 Fluss 到数据湖的过程中，Tiering Service 的工作实际上可以使用任何其他同步工具来完成，比如 Flink CDC。通过 Flink CDC 将数据从 Fluss 同步到数据湖是可行的，虽然这种方式没有 Fluss 自带的 Tiering Service 那么高效，也没有 Fluss 的无状态特性，但这并不是一个很大的问题。关键在于，数据从 Fluss 进入 Lakehouse 之后，这些数据是否能够被 Fluss 所利用。这也是我接下来要讲的 Union Read 能力的核心所在。
Union Read 的作用是将 Fluss 中的实时数据与数据湖中的历史数据进行合并。假设一开始我们有一些历史数据，比如“张三 15 岁”、“李四 20 岁”，这些数据已经被写入数据湖（例如 Paimon）。但随后我们发现最新的数据表明张三不是 15 岁，而是 35 岁，这条实时数据进入了 Fluss。如果某个查询想要获取最新的数据，查询引擎就可以使用 Union Read 功能，将 Fluss 中的实时数据（张三 35 岁）与数据湖中的历史数据进行合并。最终得到的结果是“张三 35 岁”、“李四 20 岁”。这样，Union Read 实际上打破了 Lakehouse 的延迟限制，将数据的新鲜度提升到了秒级。
Union Read 是如何实现的呢？其实并没有什么特别复杂的“黑魔法”。核心在于 Fluss 能够管理数据湖中的数据。具体来说，当 Tiering Service 将数据从 Fluss 提交到数据湖时，Fluss 会记录一些关键信息。首先，它会记录一个快照，表示这个快照已经包含了当前所有提交到数据湖的数据。其次，它会记录一个 bucket 和 offset 的对应关系，表示某个 bucket 中 offset 之前的全部数据已经成功写入数据湖。通过这种方式，Fluss 知道哪些数据已经进入数据湖，以及这些数据对应的快照版本。
高效转成湖格式的利器
Union Read 的实现依赖于一个重要的机制：Bucket 对齐，即 Fluss 的 bucket 和 Paimon 的 bucket 是一一对应的。通过 Bucket 对齐，对于 Fluss 的某一个 bucket 的数据，Union Read 只需要将其与 Paimon 对应的那个 bucket 进行 union 即可，而不需要 union Paimon 所有的 bucket。
Bucket 对齐的另一个好处是它能够帮助我们高效地将数据转换为湖格式（如 Parquet）。虽然其他系统也可以进行这种转换，但 Fluss 的优势在于数据分布的对齐。具体来说，Fluss 表和 Paimon 表都具有分区和分桶的结构，且它们的 Bucket 是对齐的。这意味着一条数据在 Fluss 中位于某个 Bucket 中时，它在 Paimon 中也一定位于同一个 Bucket 中。这种对齐方式避免了数据在转换过程中需要进行 Shuffle 的开销，从而提高了效率。此外，Fluss 的底层存储格式是 Arrow，而 Arrow 社区已经提供了非常成熟的转换方案，通过高效的 C++ 实现，可以将 Arrow 数据高效地转换为 Parquet 格式，性能提升显著。这也是 Fluss 湖流一体架构能够高效转换为湖格式的关键所在。
统一元数据
在传统架构中，元数据管理通常较为复杂。例如，Kafka 使用 Schema Registry，而 Paimon 使用自己的 Catalog。在这种情况下，需要通过 Flink 作业进行 Schema 同步，且在读取数据时需要在不同的 Catalog 之间切换，这使得数据同步和使用变得不够方便。然而，在 Fluss 湖流一体架构中，虽然仍然存在两个单独的 Catalog（Fluss 的 Catalog 和 Paimon 的 Catalog），但 Fluss 会自动同步 Schema，并且对外暴露的是一个 Catalog，这样在查询时看到的是一张统一的表，无需在不同的 Catalog 之间切换，用户不需要切换 Catalog 既可以查到 Fluss 的最新数据，也可以查到 Paimon 中的历史数据。
Flink SQL on Fluss
这种统一元数据的实现方式使得用户在查询时更加方便。如果用户不需要最新的实时数据，而只需要 3 分钟前在 Paimon 中的数据，可以通过在 SQL 查询中添加 $lake 修饰符来直接从 Paimon 中读取数据。这种方式继承了 Paimon 表作为 Flink Source 的所有能力，包括高效的读取、列裁剪和过滤条件下推等。用户无需切换表或 Catalog，即可实现高效的 OLAP 查询和实时数据读取。
Fluss 湖流一体核心优势
成本降低
在传统架构中，Kafka 通常用于存储实时数据，但其本地磁盘存储成本较高，且数据需要通过同步作业转移到数据湖中。而 Fluss 湖流一体架构将历史数据直接同步到数据湖中，并且这些数据仍然可以被 Fluss 使用。这意味着 Fluss 本地不再需要存储大量历史数据（例如 3 天），而可能只需要存储 6 个小时的数据，从而大幅减少了磁盘和存储成本，流存储成本可以降低到原来的十分之一。
高效的数据回追与流读
在某些场景下，需要从历史数据回溯到实时数据。Fluss 的历史数据存储在 Paimon 中，而 Paimon 的优势在于其高效的批量读取能力。它借助湖格式的高效条件过滤、列裁剪和压缩，使得读取速度非常快。在需要回溯时，Fluss 会自动从数据湖读取历史数据，然后切换到实时流读取，无需手动干预。这种设计实现了真正的流批融合，数据既不会丢失也不会重复。
数据湖时效性提升至秒级
传统数据湖的时效性通常在分钟级别（例如 Iceberg 可能是十几分钟，Paimon 是 3 分钟）。然而，在 Fluss 湖流一体架构下，数据的时效性可以提升到秒级。因为 Fluss 的端到端延迟是秒级的，数据一旦进入 Fluss，用户就可以立即读取。这种架构可以在不破坏原有架构的情况下，通过引入 Fluss 来实现秒级数据可见性，而无需对现有基建进行大规模改动。
数仓分层新鲜度的提升
在传统数仓架构中，数据分层（如 ODS、DWD、ADS）会导致数据新鲜度逐层降低。例如，如果每层的 Flink checkpoint 时间为 3 分钟，那么数据从 ODS 层到 ADS 层可能需要 9 分钟（3 层 × 3 分钟）。然而，在 Fluss 湖流一体架构下，数据在每一层的延迟都是秒级的。数据进入 Fluss 后，会立即生成 Change Log 并流向下游层，同时也会同步到 Paimon 中。这意味着无论数据经过多少层，其新鲜度都不会受到层级的影响，最终数据在数据湖中的可见性仍然可以保持在 3 分钟以内。
更高效的 CDC 生成
Paimon 支持两种 Change Log 生成方式：Lookup Change Log Producer 和 Full Compaction Change Log Producer。Lookup Change Log Producer 时效性高，但资源消耗大；Full Compaction Change Log Producer 资源消耗低，但需要等待多个 Checkpoint 后数据才可见。而 Fluss 生成 Change Log 是秒级的，因为它天然支持生成 Change Log。Fluss 的 Change Log 可以直接转化为 Paimon 的 Change Log，兼顾了时效性和性能。
与 Confluent Table Flow 的对比
Confluent Table Flow 是一个将 Kafka 数据通过 Flink 作业同步到数据湖的解决方案。虽然它简化了数据转换过程，但数据需要在 Kafka 和数据湖中保存两份，增加了存储成本。而 Fluss 湖流一体架构中，数据只需要保存一份，历史数据直接存储在数据湖中，Fluss 中只保留最近几小时的数据，从而降低了成本。此外，Fluss 的 Union Read 能力可以将数据湖的时效性提升到秒级，而 Confluent Table Flow 并没有增强数据湖的时效性。此外，Kafka 的 Topic 没有 Schema 和分区表的概念，这在使用时会带来诸多不便。而 Fluss 的表模型是基于数据湖设计的，支持分区表和分桶，与 Paimon 完全对齐，避免了数据模型不一致的问题。
Fluss 湖流一体 QuickStart
接下来通过一个简单的 Quick Start 来了解 Fluss 湖流一体的使用方法。实际上，Quick Start 在我们的开源社区中也非常容易找到。只要打开社区文档，点击 Quick Start，就能找到。Quick Start 也是一个基于 Docker 的环境，可以帮助大家快速体验 Fluss 湖流一体的功能，非常简便。
Quick Start 会涵盖我之前介绍的所有内容。首先是一个 Lake Tiering Service。这个服务是我们提供的，你不需要手动去完成 Tiering 工作。只需要运行一个命令，带上一些 Flink 参数（因为目前 Tiering Service 是一个 Flink 作业），就可以启动这个服务。启动后，你可以在 Flink UI 上看到这个作业。
一个普通的表如果你想让它成为湖表，需要进行一些设置。具体来说，你需要通过添加一个 properties（属性）来指定这张表是湖表，并开启湖表功能。这样，Lake Tiering Service 才会感知到这张表，将其转换为湖格式。
完成设置后，你可以直接向 Fluss 表中插入数据。插入数据后，就可以进行数据读取了。因为 Tiering Service 在后台会进行数据转换，所以当转换完成后，你就可以直接从数据湖中读取数据，并利用 Union Read（联合读取）能力，读取全量数据。
例如，执行一个简单的 SQL 查询：select count (1) as order_count from dwd_enriched _orders where n_name = 'CHINA'，最终可能会返回 1000 多条数据，这是最新的全量数据，因为 Union Read 先从 Paimon 中读取数据，再从 Fluss 中读取实时数据。
如果你只想读取数据湖中的数据，或者只关注某个快照之前的数据，而不需要实时数据，你可以直接在查询中指定 $lake。这样，查询就会直接从数据湖中读取数据，而不需要切换 Catalog。例如，指定 $lake 后，可能在 9 秒内就能读取到 3 条数据。这里需要注意的是，数据湖中的数据并不是最新的，它可能有 3 分钟的延迟，这是正常的。
你也可以选择使用 StarRocks 来读取数据。因为数据已经是 Paimon 的湖格式，你只需要指定 Paimon 的路径（warehouse path），创建一个 StarRocks 的 Catalog，就可以直接使用 StarRocks 进行读取和分析。
未来规划
支持更多查询引擎
目前，我们的 Unon Read 能力已经对接了 Flink，因为我们本身是一个 Flink 团队，所以优先支持 Flink 是很自然的选择。然而，我们的架构并不局限于 Flink。未来，我们计划对接更多查询引擎，比如 StarRocks 和 Spark。这样一来，用户可以直接使用 StarRocks 和 Spark 进行 Union Read，查询数据湖和 Fluss 中的数据，从而实现数据的极致新鲜度。
湖生态对接 Iceberg 和 Hudi
目前，我们主要对接了 Paimon，不过在社区中已经有针对 Iceberg 和 Hudi 的初步开发和贡献。我们期待这些功能能够尽快完成并发布，进一步丰富我们的湖生态支持。
支持 Deletion Vector
我们计划在 Union Read 中支持 Deletion Vector。Deletion Vector 主要用于优化主键表的读取性能。目前，Paimon 社区已经支持了 Deletion Vector，我们也希望尽快对接这一功能，从而大幅提升读取主键表的性能，减少数据 union 的开销，提高整体效率。
发布于：北京市恒正网配资提示：文章来自网络，不代表本站观点。
