在大数据领域，腾讯的湖流一体存储引擎 BiFang 基于 Pulsar 构建，融合了消息队列与数据湖的能力，实现了流批数据处理入口统一，还具备全增量查询、实时可见等优势，为大数据处理带来全新体验。
Apache Pulsar 是构建高效大数据解决方案的核心基础之一，能助力企业更好地应对大数据挑战，实现数据价值最大化。
毕方 BiFang x Apache Pulsar- BiFang 联合 Pulsar 为湖流一体带来新体验 -
BiFang，中文为毕方，中国古神话中的神鸟，象征着变革和能量，隐喻湖流一体存储引擎的先进和可靠。
在大数据领域，流计算和数据湖是两个核心组件，各自具有独特的功能和优势，流计算聚焦实时数据流处理，
数据湖专注海量数据存储分析。随着数据量的增长和实时分析需求的增加，将流计算与数据湖相结合的需求日益凸显，行业希望通过整合流计算与数据湖技术，逐步形成湖流一体技术范式。
腾讯天穹大数据去年发布了湖流一体的雏形系统------BSS 流批一体存储，该方案基于天穹 Pulsar 实现了消息队列和数据湖使用同一份数据，统一流和湖的客户端，支持数据秒级写入和查询，完成和 InLong 数据集成、Iceberg 数据湖等生态对接。过去半年，腾讯大数据实时团队对 BSS 进一步重构和优化，系统升级为 BiFang 湖流一体存储引擎，新架构支持全增量数据查询、端到端数据实时可见，预计节省 40% 存储成本、降低 70% 运维复杂度，并且已在腾讯视频、游戏、AI 多模态管道等业务领域落地。
01 关于 BiFang
1.1. 系统定位
BiFang 是一个湖流一体存储引擎，通过融合消息队列和数据湖的能力，实现流批数据处理入口统一。BiFang 支持全增量数据查询、端到端数据实时可见，兼容主流的批流计算引擎，满足业务对数据实时性、一致性和灵活性的多样化需求。
1.2. 适用场景
场景1：全增量查询消息队列数据
BiFang 基于天穹 Pulsar 构建，具备消息队列完整功能，但原生的消息队列数据只支持消费，并不支持实时查询。在设计上，BiFang 通过实时组织队列数据的 Manifest，使用统一的元数据目录，实现直接查询消息队列中的数据。此外，BiFang 内置的 Offload Service 会把数据存储到长期存储的介质，消除 Pulsar 存储周期限制，实现对长周期历史数据的查询。
![]()
场景2：数据湖数据实时可见
Iceberg 等湖格式支持通过流式方式读取增量数据，上游组件将数据写入完成后，下游组件能及时读取、查询到最新数据，满足业务对数据新鲜度的要求。但 Iceberg 流读可见性受限于 Flink Checkpoint 和 Commit 的周期，数据延迟通常为分钟级别。在 BiFang 的设计中，通过实时融合 Pulsar Manifest + Iceberg Manifest，用户可以实时查询 Iceberg 中的数据，将数据可见性从分钟级提高到亚秒级别，实现业务数据无延迟交付。
场景3：统一湖流数据存储
BiFang 同时支持流、批处理引擎，比如 Apache Flink 和 Spark，实现"一份数据"同时具备消息队列 + 离线数仓的能力。原先使用 Lambda 架构建设的数仓，现在可以通过 BiFang 直接将离线数仓和实时消息队列二合一，数据由原来的消息队列、数仓各存一份升级为只在 BiFang 存一份。基于 BiFang 的统一数据存储，既可以做实时消费又可以做离线分析，实现存储成本预计降低 40%，运维复杂度预计降低 70%。
![]()
场景4：实时多维分析报表
BiFang 具备灵活的拓展能力，支持快速对接 OLAP 查询引擎。比如 BiFang 可以作为 StarRocks 外表查询，通过 BiFang 提供的全量数据无延迟查询能力，基于 StarRocks 的在线报表可以做到数据实时响应。融合 BiFang 的实时多维分析，实现了冷热数据隔离，既保证了查询性能，又降低了存储成本。
场景5：高效低成本多流拼接
BiFang 后续将支持 Kev/Value 存储，能够在流处理过程中实现数据的实时拼接。与传统的 Apache Flink 在线计算相比，BiFang 的流式处理机制能够更高效地管理数据流，减少不必要的计算步骤。BiFang 支持事务，能够避免数据丢失，确保数据的完整性和一致性。相较于 Iceberg 的多流拼接方案，BiFang 通过高效的流处理逻辑和存储机制，能够更快完成数据拼接，拼接后的数据实现亚秒级可见。
![]()
1.3. 业界对比
业内希望通过湖流一体，实现数据整合、简化数据治理，进一步优化现有的 Lambda、Kappa 架构，降低开发和维护成本。目前业界湖流一体技术方案都是数据分钟或者秒级可见，无法真正替代原有实时数据流业务场景，比如阿里的 Fluss 、抖音的 BTS 等。
相比较 Fluss 和 BTS，BiFang 实现湖流一体存储，实现流批入口统一，支持端到端数据实时可见，并且已在业务生产环境中实践。下表针对 BiFang、Fluss 和 BTS 做了更多维度的对比：
![]()
02 架构原理
BiFang 是一个湖流一体存储引擎，统一消息队列和数据湖的能力，实现流数据和批数据处理架构融合。在实现过程中，BiFang 融合了 Apache Pulsar 消息队列和 Iceberg 数据湖能力，统一库表元数据目录，支持高性能批量查询和点查；通过提供批/流统一 API，简化数据写入和读取，同时支持和 Apache Flink、Apache Spark、StarRocks 等引擎快速集成。本章节将详细介绍 BiFang 的架构细节。
2.1. 整体架构
![]()
上图为 BiFang 整体架构图，主要包含
BiFang Client、BiFang Server、Lakehouse Storage
（目前支持 Iceberg）三部分，为了实现湖流一体统一存储，BiFang Server 对 Pulsar Broker 做了升级和功能拓展，涉及模块包括：
- Log Writer：负责数据持久化写入，每次 Message Batch 写入完成后，同步组织 Delta Manifest 持久化到 Manifest Store。
- Offload Service：负责将数据写到 HDFS ，Offload 到 HDFS 的数据文件跟 Iceberg Manifest 中的 BiFang 逻辑文件对应。
- Transaction Manager：负责协调和管理分布式事务，确保消息传递的精确一次( Exactly-Once)，能够区分生产/消费侧事务。
- Manifest Store：内部的 Pulsar Topic，用于实时存储 Delta Manifest，从上一次读取进度恢复，并保证一致性。
- Manifest Service：负责管理实时产生的 BiFang 逻辑文件，通过读取 Delta Manifest 并组织生成逻辑文件，支持逻辑文件组织/查询/恢复。
- File Service：负责数据读取，可以通过 BiFang 逻辑文件和 Offload 文件读取对应的 Ledger 实际数据，支持批量指定某个点位或者范围来获取数据。
- BiFang Client：BiFang 统一的客户端，支持从消息队列中高效写入和读取流式数据（带 Schema），同时支持全增量读取。
2.2. 核心流程
![]()
上图为 BiFang 读写数据的核心流程，支持数据流式写入和读取，结合架构图中 BiFang 的各个模块，核心流程包括：
-
数据经 Log Writer 以行存格式写入 BiFang Server，每次写入一批数据，都会生成 Delta Manifest 并持久化到 Menifest Store 中；
-
Manifest Service 负责消费 Manifest Store 中的 Delta Manifest，生成 BiFang 逻辑文件，并在内存中构建 Manifest File：
- Manifest File 会定时提交到 Iceberg，完成元数据的持久化；
- anifest Service 提供 Manifest File 查询服务，供 Iceberg 查询实时的 Manifest 信息，近而实现无延迟访问；
-
提交到 Iceberg 的 Manifest File，由 AO（Auto Optimizer）服务统一管理和优化。AO 服务将 Manifest File 中的 BiFang 逻辑文件进行合并，通过 File Service 提供的接口，读取到 BiFang 逻辑文件对应的实际数据，并转换为 Parquet 数据文件；
-
Offload Service 把 Pulsar Bookie 中的数据转移到长期且低成本的 HDFS 存储中，客户端读取 BiFang 逻辑文件时，可无缝切换到读取 HDFS 上的数据文件，以满足大规模历史数据查询场景的需求。
2.3. 技术优势
优势1：统一表管理与元数据治理
BiFang 统一使用 Iceberg 来表示湖流一体表，从用户视角只感知一种表，无需维护多套元数据系统。Table 相关的元数据统一放在 Iceberg 元数据，表相关操作不经过 BiFang，BiFang 根据 Hive Catalog 或者统一 Catalog 访问 Spec/Schema Change，实现元数据统一治理。
优势2：支持端到端数据实时可见
BiFang 结合 Manifest Service 提供的实时 Manifest 查询能力，扩展 Iceberg runtime 支持远端 Manifest，引入一个特殊的读取模式：支持读到 Pulsar 事务已提交、但是未提交到 Iceberg 的数据。通过这种读取模式，业务可以通过 BiFang 实时查询最新的数据，实现端到端数据实时可见。
优势3：湖流存储一体化实现成本优化
BiFang 支持行列混合存储，增量数据以行式格式（Pulsar Log）存储，历史数据自动合并为列式格式（Iceberg Parquet），结合 AO Service 实现小文件合并与存储优化。基于 BiFang 的存储一体化，行式存储保障实时写入性能，列式存储提升批量查询效率，有效消除 Lambda 架构下的双存储冗余问题，减少存储浪费。
优势4：支持 Exactly-Once 语义
BiFang 基于 Pulsar Transaction 实现生产侧事务隔离，确保数据不丢不重，实现 Exactly-Once；支持 Read Committed 隔离级别，避免脏读问题，可满足金融交易、物联网设备状态同步等高一致性场景需求，简化业务端异常处理逻辑，降低开发复杂度。
优势5：多引擎兼容与生态融合
BiFang 具备灵活的拓展能力，支持无缝集成 Apache Flink、Apache Spark、StarRocks 等主流引擎。同时支持复用 Apache Iceberg 生态，无缝对接 Iceberg 的元数据管理、版本控制与时间旅行能力。用户无需改造现有计算任务，可直接复用业务代码，实现零成本迁移。
03 业务实践
![]()
上图为腾讯视频点击&播放等数据链路经过 BiFang 改造后的对比，业务数据经过大同数据上报、InLong 数据集成等平台后，数据会统一入湖（Iceberg）。在原有的链路中，消息队列中的数据通过启动一个 Flink 实时任务实现入湖，如果该任务异常出现丢数据等情况，会通过旁路的离线链路进行对账或者补录。通过 BiFang 改造后的新链路，实现将原有消息队列、Flink 实时任务、入 Iceberg 等过程缩减为一步，实现架构上的精简；同时，由于 BiFang 对数据准确性的保障，用于数据对账或者补录的离线链路可以完全省略。除了架构精简带来的运维便利性，腾讯视频通过 BiFang 统一湖流存储还实现以下效果：
![]()
04 未来规划
BiFang 近期发布 1.0 版本，实现消息队列和数据湖基础能力的统一，完成流数据和批数据的无缝处理。为了进一步提高 BiFang 的技术竞争力，未来将持续优化架构、丰富内核能力、完善生态拓展等，具体包括：
- 架构优化：围绕提高数据读写性能和系统稳定性，比如通过 IO 请求合并优化逻辑文件读取、AO 支持 BiFang 专用行转列任务提升性能，其它包括数据降冷支持列存、优化计算和存储组件的负载均衡等；
- 核心能力：统一 Lakehouse 和 BiFang 数据生命周期，进一步细化统一存储；拓展主建表能力，包括支持点查询、支持实时 KV 和 Changelog，支持 Arrow 流式列存储格式和列裁剪等；
- 生态完善：丰富上下游生态系统，比如支持 Apache InLong 集成、StarRocks 集成，打通 Oceanus 实时平台 SQL 和画布能力，实现 BiFang 在 WeData 数据治理平台的产品化等；
