StreamNative Ursa：基于对象存储的LakeHouse-Native 架构

Ursa 是 StreamNative 推出的闭源消息引擎，定位是 Pulsar 的替代方案（个人认为的～），核心目标是兼容 Kafka 协议并针对云部署场景优化。目标场景很明确：日志流场景下，允许较高延迟（200-500ms），但有成本痛点，且需要通过 Connector 将数据 ETL 到数据湖的一体化场景。通过直接写入 LakeHouse 格式和消除跨区复制，Ursa 实现了 10 倍（官网PR）的成本降低。

2025 年 9 月，StreamNative 的 Ursa 论文获得了 VLDB（Very Large Data Bases）最佳工业论文奖。今天想和大家分享一下我对 Ursa 的理解。

Ursa 提出了一个问题：能否在保持 Kafka API 完全兼容的前提下，将基础设施成本降低 10 倍？这也是近两年消息队列方向大家一直在讨论的，Redpanda、AutoMQ 针对 Apache Kafka 的优化中，成本也是最重要的点。

从成本优化的角度，方向集中在三个方面：使用对象存储代替本地存储、减少跨可用区的通信费用、存算分离解绑让系统更弹性。下面来看一下 Ursa 的具体设计。

要解决的核心问题

Ursa 的定位是解决云部署状态下成本高昂和流分析割裂两个问题。

成本问题来自多个方面。跨可用区数据传输是最大的开销，Kafka 的 Leader-Follower 模式需要将数据从 Leader 复制到其他可用区的 Follower，对于每天处理 TB 级数据的系统，这个成本可能达到每月几万美元。基于磁盘的副本复制同样昂贵，Kafka 假设配置 3 副本，那么每份数据在 SSD 上存储 3 次，SSD 的成本是对象存储的 5-10 倍。存算一体导致的过度配置进一步加剧了问题，因为计算和存储绑定在一起，增加存储容量就必须增加 Broker，即使 CPU 是闲置的。此外，将数据从 Kafka 搬运到数据湖需要独立的 Kafka Connect 集群，而数据重复存储在多个地方，进一步抬高成本并带来治理复杂度。

流和分析的割裂是另一个关键问题。实时流数据和分析系统通常是分离的基础设施，数据先进入 Kafka 供实时应用消费，然后定期通过 ETL 工具搬运到数据湖供分析使用。这带来了数据延迟（实时数据要等到 ETL 才能分析）、系统复杂度（维护两套系统）、数据一致性（两份数据可能不同步）等问题。真正的统一应该是流数据天然就在 Lake 中，不需要额外的搬运。

核心特性

为了实现这些目标，Ursa 的技术路径可以用三个关键词概括：Leaderless、LakeHouse-Native、Kafka 兼容。

Leaderless 消除了 Partition Leader，任何 Broker 都可以处理任何 Partition 的请求，通过集中式的元数据服务（Oxia）保证 offset 的顺序性。这消除了跨可用区的副本复制，大幅降低网络成本。

LakeHouse-Native 将流数据直接写成 Parquet 格式并注册到 Iceberg/Delta Lake 表中，同一份数据既可以被 Kafka Consumer 消费，也可以被分析引擎查询，实现了流表二元性。这消除了 ETL 和数据重复。

Kafka 兼容 完全支持 Kafka API，用户不需要重写应用代码，现有的 Kafka 客户端、工具、监控系统都可以直接使用，让用户可以无缝迁移。

技术实现

架构设计：三层分离

Ursa 采用了清晰的三层架构。元数据服务层使用 Oxia (类似Kraft 的内置的元数据存储服务、跟 RobustMQ 中Meta Service的定位一样)实现，负责 offset 分配、partition 元数据和事务状态，每秒可以处理数百万次操作。流存储层将存储和计算分离，新数据首先写入 WAL，然后通过 Compaction Service 转换成 Parquet 文件。WAL 支持两种模式：延迟优化模式使用 BookKeeper（延迟在个位数毫秒），成本优化模式使用对象存储（延迟在几百毫秒）。如果是低延迟场景，可以选择 BookKeeper，如果更关注成本且允许较高延迟，可以使用对象存储。无状态 Broker 层负责处理客户端请求，不维护 partition 状态，可以随意扩缩容。Zone-aware 路由确保同一可用区的 Producer 和 Consumer 连接到本地 Broker，减少跨区流量。

顺序性保证：Oxia 的集中式 Offset 分配

Leaderless 架构的关键挑战是如何保证消息顺序性。Ursa 的解决方案是将顺序性保证从数据层移到元数据层。虽然多个 Broker 可以并发处理写入请求，但 offset 的分配通过 Oxia 事务串行化。Broker 写入消息到 WAL 后，向 Oxia 请求 offset，Oxia 使用事务读取当前最大 offset，计算新的 offset 范围，然后原子性地更新索引。整个过程通过 Raft 协议保证全局有序。这个设计将数据流去中心化（任何 Broker 都能写），但元数据流中心化（Oxia 保证顺序），既获得了 Leaderless 的灵活性，又保持了 Kafka 的顺序语义。

Stream-Table Duality：一份数据的双重身份

Stream-Table Duality（流表二元性）是 Ursa 最核心的创新。同一份 Parquet 数据，既是 Kafka Topic，也是 Iceberg/Delta Lake Table。实现机制是双重元数据：写入时，数据被转换成 Parquet 格式存储在对象存储中，同时构建两套元数据。Kafka 元数据记录 Topic、Partition、Offset 范围和文件位置，Iceberg/Delta 元数据记录 Table Schema、Snapshot、Partition 和文件位置，两套元数据指向同一个 Parquet 文件。读取时，Kafka Consumer 通过 Kafka 元数据按 offset 顺序读取，分析引擎通过 Iceberg/Delta 元数据按列式方式查询。物理上只有一份数据，逻辑上可以用两种方式访问，既消除了数据重复，也消除了 ETL 的需要。

Compaction Service：后台的行列转换

Compaction Service 负责将行式的 WAL 对象转换成列式的 Parquet 文件，采用三阶段管道设计。第一阶段，Leader 节点检查 offset 范围，根据吞吐量动态划分压缩任务，每 30 秒 checkpoint 到 Oxia。第二阶段，Worker 节点并行处理，从 WAL 读取数据，使用相应的 schema 反序列化后写成 Parquet 文件。第三阶段，Leader 收集元数据，批量更新 offset index，同时原子性地提交到 Iceberg/Delta catalog。整个过程保证 exactly-once 语义，offset index 保持中心化，确保数据不会重复、乱序或丢失。

Zone-Aware 路由：降低跨区成本

Zone-Aware 路由是 Ursa 降低跨可用区网络成本的核心机制。每个 Broker 启动时从 Kubernetes 或 EC2 metadata 读取自己的可用区，注册到 Oxia。当客户端在 client.id 中包含 zone 信息时，Broker 使用一致性哈希计算该 zone 的"负责 Broker"，并在 Metadata 响应中返回。客户端后续所有请求都发往这个本地 Broker。这让 Producer 和 Consumer 只与本地可用区的 Broker 通信，完全消除了客户端到 Broker 的跨区流量。而且同一 Partition 在同一 zone 总是路由到同一个 Broker，Broker 可以维护本地的 write buffer，最新数据直接从内存返回，不需要访问 S3。

设计中的思考和权衡

延迟换成本

Ursa 最核心的权衡是用延迟换成本。传统 Kafka 使用本地 SSD，写入延迟在几毫秒，Ursa 使用对象存储，写入延迟在几十到几百毫秒。这个增加是显著的，但对很多场景可以接受。系统提出了"New CAP Theorem"的概念，指出成本、可用性和性能容忍度不能同时最大化。Sub-50ms 延迟加上多可用区高可用需要昂贵的跨区复制，但如果应用能容忍 200-500ms 延迟，就可以用对象存储实现巨大的成本节省。大部分数据密集型摄入场景（日志收集、用户行为追踪、CDC、数据管道）并不真正需要个位数毫秒的延迟，几百毫秒对业务价值影响很小，但成本降低 10 倍的吸引力是巨大的。

StreamNative 保留了双引擎策略，Classic Pulsar Engine 使用 BookKeeper（延迟在 10ms 以下），Ursa Engine 使用对象存储（延迟在几百毫秒）。用户根据场景选择：超低延迟的关键业务用 Classic Pulsar，成本敏感的数据摄入用 Ursa。而且 Ursa Storage Extension 允许在 Classic Pulsar 集群上启用 Ursa 的 LakeHouse 存储，热数据在 BookKeeper（低延迟），冷数据自动迁移到对象存储（低成本），这种渐进式迁移路径降低了采用门槛。

集中式元数据的选择

Ursa 的 Leaderless 不是完全去中心化，Broker 层是 leaderless 的，但元数据层（Oxia）是集中式的。完全去中心化的系统（如 Cassandra）可以消除所有单点，但代价是无法保证全局顺序。Kafka 的核心语义就是严格的顺序保证，这是不能妥协的。Ursa 选择了务实的路径：数据层去中心化，元数据层集中化，既保持了 Kafka 的语义，又获得了 Leaderless 的优势。Oxia 使用 Raft 协议，支持 sharding，每秒可以处理数百万次操作，对绝大部分场景不会成为瓶颈。

Schema 演进的实用主义

Ursa 在 schema 演进上采用了流式友好的策略。传统数据库在写入时进行严格的 schema 验证，不兼容的数据会被拒绝，这对流式系统可能导致数据丢失。Ursa 的做法是写入时不做 schema 检查，每条消息带 schema-ID，在 Compaction 时才处理。遇到不兼容的数据路由到 Dead-Letter Topic，而不是丢弃，offset 依然记录，保持 gap-free ordering。LakeHouse 侧通过 union-merge 所有历史 schema 版本，新增字段标记为 nullable，保持向后兼容。

我的一些看法

需要说明的是，Ursa 是 StreamNative 的闭源商业产品，只在 StreamNative Cloud 上提供服务，不是开源项目。用户需要付费使用，无法自行部署或修改代码。

从技术角度看，Ursa 是针对云部署场景下消息流平台的成本、弹性痛点的思考和实现，核心目标是解决成本、ETL、数据湖集成、弹性扩展等痛点。这是专门为云部署场景设计的云原生架构，和传统的本地部署架构有本质区别。

LakeHouse-Native 是最核心的创新点。直接将流数据写入 Parquet 并注册到 Iceberg/Delta Lake，这不仅仅是格式转换，而是重新定义了流和分析的关系。传统架构中流和分析是两个独立系统，中间需要 ETL 连接。Ursa 让流数据天然就在 LakeHouse 中，消除了这个割裂。数据写入后立即可以被 SQL 引擎查询，不需要等待定时的 ETL 任务。而且使用开放标准（Iceberg/Delta）意味着数据不被锁定，可以被任何支持这些格式的引擎访问。

Leaderless 加上 Centralized Metadata 的组合很巧妙，既保持了 Kafka 的核心语义（顺序、exactly-once），又获得了新的优势（无 Leader 选举、低网络成本、快速恢复）。通过 Oxia 集中管理 offset 分配，在保证顺序的同时实现了 Broker 层的去中心化。这个架构在云环境下特别有价值，因为它消除了跨可用区的副本复制，这是云环境成本的主要来源。

成本降低 10 倍有数据支撑，StreamNative Cloud 上的生产数据（5 GB/s 工作负载，5% 成本）验证了这个数字。但作为一个相对年轻的系统，技术稳定性和市场表现还需要时间观察。技术创新是否能转化为商业成功，取决于更多因素。

生态策略值得关注。100% Kafka API 兼容让用户无痛迁移，不需要重写应用和工具，避免了 Pulsar 当年面临的生态困境。使用开放标准（Iceberg、Delta Lake、Parquet）降低了厂商锁定风险，这些选择体现了对市场现实的理解。

Ursa 的定位很明确：成本敏感、延迟要求宽松的数据密集型工作负载，延迟在几百毫秒级别，不适合超低延迟场景。这种清晰的边界划分是务实的。StreamNative 保留双引擎策略，让用户根据场景选择，超低延迟用 Classic Pulsar，成本敏感用 Ursa，这种灵活性符合真实业务的多样化需求。

Ursa 对消息队列行业提供了一些有价值的参考。成本优化是真实的市场需求，云计算的普及让基础设施成本成为企业的重要考量，单纯追求性能可能不如追求成本优化更有市场吸引力。架构创新比工程优化更难被复制，用新语言重写、用新 I/O 库优化容易被复制，但架构层面的创新能建立更深的护城河。生态兼容性的重要性不容忽视，新协议的生态建设极其困难，兼容现有生态是更现实的路径。开放标准的价值也在显现，使用开放格式不仅降低厂商锁定风险，也让系统可以融入更广泛的数据生态。

总结

Ursa 是一个在架构层面有创新的消息流平台。通过 Leaderless 架构（解决跨可用区成本）、LakeHouse-Native 存储（解决本地硬盘的存储成本）、Stream-Table Duality（解决流数据到LakeHouse的ETL ），它针对云部署场景解决了传统消息队列的成本问题和流分析割裂问题。极大降低通过消除跨区网络、使用对象存储、消除 ETL 等多个优化实现。Kafka API 兼容和开放标准的选择，让 Ursa 避免了新协议的生态困境。清晰的权衡和定位，让用户可以根据场景做出理性选择。

VLDB 2025 最佳工业论文奖是对 Ursa 技术价值的认可。虽然系统已经在 StreamNative Cloud 上运行了两年，但长期的技术和市场表现还需要持续观察。作为专门为云部署场景设计的云原生架构，Ursa 代表了消息流平台的一个重要方向：通过架构创新实现数量级的成本降低，同时保持生态兼容性。这对正在做基础软件的人来说，提供了很多值得思考的地方。