Data Warebase：实时湖仓 · 多模检索

摘要：回顾过去 30 年，数据技术的发展历经五个阶段：从数据仓库到大数据，从大数据到数据湖，从#数据湖到湖仓融合，再到当下热议的#实时湖仓，每个阶段跨度约五至十年。

导读本文将解读湖仓技术发展脉络，分享 ProtonBase 如何通过增量物化视图实现实时湖仓开发方法论的升级，探讨 Data+AI 的数据开发新范式。

主要内容包括以下几大部分：

1. 湖仓技术演进与挑战

2. 实时湖仓升级数仓开发方法论

3. 多模检索加速应用创新

4. ProtonBase 实践场景与案例分析

5. Data+AI 展望

6. Q&A

分享嘉宾｜刘一鸣 ProtonBase 产品与解决方案负责人

编辑整理｜陈沃晨

内容校对｜李瑶

出品社区｜DataFun

湖仓技术演进与挑战

1. 湖仓技术发展的几个关键阶段

回顾过去 30 年，数据技术的发展历经五个阶段：从数据仓库到大数据，从大数据到数据湖，从#数据湖到湖仓融合，再到当下热议的#实时湖仓，每个阶段跨度约五至十年。

（1）传统数仓（1990s-2010）

早期的数据库与数据仓库主要聚焦结构化数据分析，应用场景多局限于企业内部经营统计，以生成 BI 报表、搭建管理驾驶舱为核心功能。这个阶段，受限于分布式技术的局限，往往处理数据规模有限，时效性低。经典的技术包括 Teradata 等。

（2）大数据时代（2010s 初期）

随着分布式技术的快速迭代，加之数据采集成本大幅降低，以 Hadoop、Spark 为代表的大数据技术凭借分布式架构有效解决了数据规模难题，逐步成为行业主流。在此期间，开源领域涌现出大量创新技术。大数据技术为了更好的吞吐能力，放弃了严格事务一致性和灵活的实时查询能力。

（3）云原生大数据（2010s 末期）

随着大数据技术向云端迁移，云与大数据展现出天然适配性。云端提供的弹性计算与存储服务，高度契合大数据弹性计算负载特性。鉴于大数据作业大多不需要 Long Running，有些任务可以在夜间批量处理、或周期性执行，云平台的弹性资源调配能力得以充分发挥。大数据上云推动了技术架构深度解耦，实现存算分离后，通过高效利用弹性资源，不仅突破了数据规模瓶颈，更显著降低了运营成本。典型技术如 EMR 等。但有了资源的弹性，不等于有了更好的数据价值，大数据平台在数据治理、数据质量方面产品完整度还不高。

（4）湖仓一体（2015-2020）

大约五六年前，湖仓一体概念兴起，数据平台既需要存算灵活性，又需要数据服务可管理性。一方面，数据湖领域的开发者着力优化表格式的可更新能力与事务支持，使数据湖处理能力趋近传统数仓。另一方面，数据仓库技术拓展管理边界，从结构化数据延伸至半结构化、非结构化数据，将元数据管理覆盖至数据湖全域。这双向探索推动了湖仓融合进程，体现出数据系统向集成化演进的趋势。尽管该阶段已实现 ACID 特性与数据更新能力，但与业务场景对数据实时性、鲜活性的需求仍存在一定差距。

（5）实时湖仓（2020s 至今）

近两年来，实时湖仓成为行业关注焦点，如何以更低成本构建实时湖仓体系、实现端到端的低延迟，保障数据新鲜可用，同时支持数据服务场景的多模态，已成为技术探索的核心命题。在可预见的未来，我们看到了数据平台实时化、一体化、智能化的趋势，基于此，本文将重点探讨实时湖仓的技术架构与实践路径。

2. 湖仓平台演进的五个趋势

湖仓平台的演进具有如下五大趋势：

（1）单机架构->分布式架构

所有技术都在从单机架构向分布式架构演变，所有系统都开始注重弹性和可扩展性。未来，规模将不再成为一个问题，如何更好地利用规模才是工作重点。

（2）结构化->半结构化、非结构化

数据类型已从以结构化分析为主导，逐渐转向大量采用非结构化、半结构化数据的 Schema Free 处理模式，同时与 AI 应用场景的融合更为紧密。

（3）报表展示->数据产品

数据应用已从单纯的内部经营分析报表展示，演进为数据产品形态。这一转变意味着数据的使用主体不再局限于企业内部团队，而是通过 API 的形式，开放给上下游合作伙伴及在线用户。特别在 AI 时代，数据交互或将 90% 由 Agent 主导，届时数据价值有望实现质的飞跃。

（4）数据洞察->数据行动

数据分析正从单纯的数据洞察向驱动数据行动转型。众多大数据团队反馈，其职能已从过去的成本中心逐步向企业效益中心蜕变。通过深度参与实时决策、实时推荐及实时风控等业务场景，数据价值得以充分释放，数据团队对企业的战略重要性也与日俱增。

（5）SQL->NoSQL->NewSQL

数据技术演进呈现从 SQL 到 NoSQL 再回归 NewSQL 的轨迹。在此过程中，SQL 展现出强大的生命力 —— 通过描述性语言，而非技术实现语言表达业务需求，所有的数据技术重返 SQL 体系，这一回归显著降低了系统的开发门槛，运维门槛，更为人才培养创造了有利条件。

3. 湖仓应用现实的路径依赖：架构搭积木，挑战复杂度

当前湖仓应用的实现路径常采用 “积木式” 架构叠加，持续推高系统复杂度。源于业务多元需求，结构化数据更新采集后，半结构化文档数据的同步需求接踵而至。从业务库向分析库的数据流转涵盖离线同步、批量同步与实时同步多种模式。同步完成后，结构化分析需求导向传统分析系统，全文检索任务对接专用检索平台。而近年 AI 应用的兴起，更催生了数据向量化需求 —— 需将数据转化为向量格式，存储至向量数据库以支撑模型训练与推理。

在此情形下，数据处理链路愈发冗长复杂，任一环节故障都可能引发系统性灾难。这不仅是当下的普遍难题，更会在长期内持续困扰企业，只要业务与团队不断扩张，每新增一项业务就需要增加新的组件，而每个新组件的引入又会衍生出新的数据同步链路。

4. 湖仓平台核心挑战：孤岛、效率、人才

综上，湖仓平台背后的核心挑战已经不再是吞吐与性能，而是在如下三个方面：

（1）数据冗余：各业务场景独立构建数据存储体系，涵盖结构化、半结构化及对象存储形态，同时存在热数据与冷数据、离线与实时数据的差异，这种分散式建设导致数据冗余问题凸显，不仅消耗大量存储资源，更会带来数据一致性隐患。由于各系统数据更新逻辑由独立团队维护，伴随人员流动，口径统一愈发困难。加之离线计算与实时计算团队虽处理同源数据，却因技术栈差异，不得不重复开发相似的数据处理逻辑，导致开发资源浪费与协同成本攀升。

（2）同步：有多份数据，就意味着存在同步开销，同步操作本身不会创造业务价值，却可能带来诸多问题，传输损耗与处理偏差影响数据准确性，同步延迟导致数据时效性下降等等。随着新系统的增加，同步成本增速远超业务价值增量，使企业陷入资源消耗与价值产出的失衡困境。运维团队每日耗费大量工时追溯数据质量问题的根源，疲于应对因同步链路复杂引发的异常，严重挤压数据迭代创新的资源投入。

（3）复杂架构：冗余的数据架构持续推高系统复杂度，使得人才需求不断增高，而其入职后往往又会陷入平台运维与管控的琐碎事务中。系统复杂导致人才依赖严重，一旦关键人才流失，系统将迅速暴露脆弱性。

5. 大数据已死，大数据永生

让我们稍微回顾一下 IT 行业数据管理的历史，在数据库技术诞生前的六七十年代，程序员需通过文件系统手工管理数据状态，深陷低效复杂的文件管理工作。直至 80 年代 DB2 等关系型数据库兴起，才将程序员从底层存储细节中解放，仅需关注业务逻辑，使生产力得到大幅提升。

随着大数据发展，因为不同的 IO 要求，不得不把系统分成离线的、在线的，以及结构化的、非结构化的等等。这种过度细分导致系统复杂度激增，伴随副本冗余与多向同步开销，背离了高效架构原则，亟需技术范式革新。

随着分布式技术全面成熟并下沉为数据技术基座，我相信，未来的数据处理体系都会是分布式的，将原生具备大规模处理能力，因此 "大数据" 作为独立技术概念或将逐渐隐退，而数据加工、分析等这些基础思想将持续演进，成为数据技术永恒的核心基因，因此我大胆预言“大数据已死，大数据永生”。

理想的技术架构应让基础设施回归基础设施，让数据回归业务，数据团队能够更专注于价值创造，而非陷入存储调优、链路诊断等技术细节。基础设施应足够稳定、高效、易用。

6. 理想中的下一代实时湖仓平台

一个理想的大数据平台应该接口足够简单，不管是访问结构化的还是半结构化的数据。我们不希望这个平台上数据是割裂的，不需要产生很多的孤岛，不需要那么多数据同步。我们希望数据存储上是能够集中化，统一化。我们也希望平台像所有大数据技术一样，可以水平的扩展，能够处理更大的规模的量。同时扩展上也足够的灵活，像秒级扩缩容。不需要做数据重新的分发，更加的灵活。同时也要满足我们业务上对实时性的需求，更加的敏捷的做决策，支持实时的读写、加工、分析。

理想的大数据平台应具备极简统一的交互接口，实现结构化与半结构化数据的无缝访问。其核心架构需消除数据孤岛，减少数据同步操作，构建集中化、标准化的数据存储体系，从根源上规避冗余与一致性风险。在弹性扩展层面，平台需继承分布式技术的原生优势，支持水平扩展，从容应对数据规模增长。同时，扩展灵活，具备秒级动态扩缩容能力，通过智能资源调度实现节点增减时的数据零迁移、服务无感知，最大化系统灵活性。业务响应维度，平台应深度融合实时计算能力，支撑全链路数据的实时读写、流式加工及交互式分析，实现更加敏捷的决策。

在分析能力上，平台要能够支持更加灵活的多模态分析方式，全面覆盖结构化数据检索统计、海量数据对比分析及向量化排序等场景。在支持多负载查询场景时，能够有良好的隔离方案，还能保证线上系统的稳定可用。

7. ProtonBase：支持实时湖仓、多模检索的云数仓

ProtonBase 是面向上述统一存储、统一计算目标打造的新一代云数仓，深度集成主流云平台的计算、网络及存储资源（如对象存储、块存储等），支持阿里云、华为云、腾讯云、火山引擎、AWS 等跨云部署。存储层包含了两种类型：高性能全托管存储，以及开放的湖上对象存储。计算层采用容器技术，依托 Warebase 弹性节点，提供秒级扩缩容能力，动态适配负载波动。公共的服务管控模块集成了系统监控、计量计费、权限管理等功能。

ProtonBase 的设计目标是用标准的接口和数据模型，解决多场景、多数据类型的挑战，深度优化各场景下的物理性能极限，同时让系统足够简单易用。

8. 分布式 Data Warebase：不是发明而是发现

在实现上述目标的过程中，ProtonBase 既要具备数据库的实时写入、实时更新能力，支持完整的 ACID 语义，确保数据的正确性；又要在面向海量数据时，具备数仓一样的高吞吐和高效分析能力，能够像文档数据库一样实现关键词检索与全文检索功能。因此，我们将这类融合性数据技术定义成一个新的品种，命名为 "Data Warebase"—— 从数据库（Database）与数据仓库（Data Warehouse）中各取一部分关键词。遇到 Data Warebase 是一个发现的过程，是数据平台需求的自然演进，它不是创造新名词。我们相信，数仓、数据库、NoSQL 在接下来发展中一定会向这一形态去融合，减少各种因为 IO 和使用局限造成的数据割裂，会有更多体现 Data Warebase 理念的技术出现。

9. 数据开发的新范式

Data Warebase 的融合架构为数据架构提供了新范式。相较于传统的从 TP 到 AP，再到对象存储、中间件、分析库、向量库的架构，Data Warebase 通过统一的数据底座，彻底消除了跨系统的数据同步链路与冗余副本，系统架构得以简化，在一个平台上即可完成数据的加工、分析和检索服务。

接下来将分享如何利用这套架构为企业实现降本增效。

实时湖仓升级数仓开发方法论

1. 实时湖仓如何提高开发和运维效率

优质实时湖仓平台需具备端到端的实时处理能力，以支撑实时分析、实时决策，例如直播统计、实时风控、实时营销、实时质量监控等场景。

数据质量是实时平台的核心痛点。传统烟囱式开发为追求实时性，常将数据接入与加工强耦合生成结果集，虽能快速响应，但质量验证困难。流式数据特性导致加工逻辑错误与源数据异常难以溯源，一旦实时口径偏差，数据可信度将大幅降低，指标价值随之失效。因此，理想的实时湖仓平台需内置数据质量检测与自动修正机制，确保数据全链路可追溯、可验证。

实时湖仓平台常被诟病成本高昂，根源在于传统开发模式过度依赖复杂架构。以 Lambda 与 Kappa 架构为例，消息中间件、流式计算引擎及结果存储数据库的叠加，不仅增加组件耦合度，更造成数据多节点流转损耗。ProtonBase 致力于通过技术内敛，精简组件，减少数据流动，使系统更加稳健，成本更加可控。

我们希望能够做到技术和业务的解耦，实现“平台赋能、业务自治”的开发模式，能够让业务团队自助进行开发，因此我们的平台层要足够健壮、具有隔离能力、且具有足够的弹性去满足不同的业务需求。

2. ProtonBase：实时、吞吐、稳定的一站式实时湖仓

针对上述目标，ProtonBase 实现了多项技术创新：

（1）实时写入、实时更新：采用 LSM 存储结构，支持以行或列为单位的数据写入和更新，且更新即可见。用户不仅可以选择写入到数仓中，也可以选择写到湖中，ProtonBase 支持 Iceberg 格式实时入湖。

（2）弹性与稳定性：基于动态流量差异，有时需要高并发处理，有时则需要减少资源节约成本，因此平台实现了秒级弹性，以应对处理规模变化。

（3）事件驱动的开发：传统的实时数仓开发往往需要 Kafka 来实现事件驱动，而 Kafka 非常不利于数据诊断和数据修正，它只能消费、驱动，但不可 Debug 或查看。ProtonBase 支持 PG 原生的 Streaming Replication Protocol, 吐出 CDC 变更事件，作为有状态的存储引擎，可以替代 Kafka，可使用 Flink+ProtonBase 搭建端到端事件驱动的开发方案。

（4）时间旅行（time travel）：数据变更采用多版本 MVCC 方式记录，可回溯数据状态到任意历史节点，用于数据质量排查和数据修正。

（5）增量物化视图与 ZeroETL：支持全量和增量物化视图刷新策略，通过描述性语言构建 ZeroETL 开发范式。通过批流一体的数据加工，实现一份数据，一份脚本，使得可以更低成本实现数据的实时加工。

（6）高吞吐并行导入：全分布式架构，支持横向扩展，并且支持 INSERT、COPY 多接口。

3. 分层的实时湖仓：From Brown Zone to Golden Zone

与离线数仓一样，实时湖仓也需要进行分层。数仓经典理论中常分为 ODS 层、DWD 层、DWS 层和 ADS 层。

在明细层，用户可基于成本和使用方式选择数据入库或入湖，无论入库还是入湖，ProtonBase 都提供了灵活的更新能力，支持 Iceberg、DeltaLake 等格式的湖存储。

从 ODS 层到 DWD 层有几种加工方式：如果数据需要毫秒级的实时，可以通过 Flink+CDC 的方式做毫秒级事件驱动的加工，从 ODS 加工到 DWD 去做一些数据口径的对齐、数据质量的清理；如果实时性需求在分钟级，那么可以使用成本更低、表达方式更友好、开发方式更友好的增量物化视图方式去定义加工过程。

至于是否还需要向上聚合，由具体需求决定。有些数仓团队加工成 DWD 层，数据质量就可以保证，就可以将数据分享给业务团队去加工成更多的主题。

我们希望 ADS 层能够更薄，因为 ADS 层会牺牲很多数据细节。但是我们看到整个数据分析的行业趋势就是越来越灵活、探索、可自助，所以过去把数据精装修成 ADS 层的场景一定会越来越少，只针对那些对性能有极致要求的场景才会加工成 ADS 层。加工 ADS 层的时候，也会选择不同的方法。一般而言，一个新业务上线或者业务不确定的时候，通常可以定义成视图，通过视图来验证口径是否正确，是否满足需求。当对该视图的访问量增加到一定程度，再将其物化下来，这才是一个相对合理的实时数仓开发方法。

不同层也会面对不同场景，明细层更多是面对数据挖掘、机器学习这种可扩展、偏内部团队使用的场景；DWD 层更多面向有质量保障数据，可被分享的场景；当要将数据分享给业务方、消费方或者变成一个数据产品的时候，需要一定的高并发、低延迟，通常会把将其加工到 DWS 层；当对性能有极致要求或者多种访问口径，不需要那么灵活，只希望访问相对固化的口径时，则会加工成ADS层。

综上，实时湖仓的开发方法论和离线数据的方法论非常接近，这套方法论能够帮助企业将数据从低价值的裸数据加工成高价值的主题数据。

4. ProtonBase on AWS 实时湖仓参考架构

这是 ProtonBase 在 AWS 的实时湖仓架构参考图，异构数据源使用 Teleport 数据同步服务，提供高吞吐、异构数据源的实时同步能力，支持批量和增量同步方式，同步之后用户可以选择先落湖，参考架构中选择的是通过 Iceberg 表入到湖中，存储在 AWS S3 上。然后通过 Spark 微批调度，以分钟级逐步加工到 Silver Zone。Silver Zone 再向上可以通过增量的物化视图方式，消费 Iceberg 的增量数据，即可实现湖到仓之间的 ZeroETL 模式。湖和仓之间通过共享的元数据，ProtonBase 选择 Iceberg REST 协议，所以能够对接市面上所有主流的支持 Iceberg REST API 的系统，如 Glue 等。如果数据不需要高并发和低延迟访问，可以通过 ProtonBase 的外表方式直接进行查询。ProtonBase 还提供了分布式缓存服务，通过缓存从而减少对底层 S3 的直接访问，实现更好的效率与成本的平衡。

5. 离线实时一体化架构演进

在批流一体架构被广泛使用之前，因为系统的局限性，通常有实时链路、离线链路，有服务层或者加速层。因为当时没有好的计算引擎和存储引擎，所以我们发现这套架构虽然能算出指标，看起来能够更实时化一些，但实际上开发成本极其高昂，大部分团队都会因为这套架构建立自己的离线团队、实时团队。离线团队往往会使用像 Spark 和 HDFS 这样的技术，实时团队则使用另外一套 Flink+Kafka+HBase+CK 的技术。两个团队有越来越多交叉指标，重复建设导致效率低下且存在指标口径不一致的问题。

解决上述问题经历了若干阶段：

第一个阶段是计算引擎的统一。在计算引擎层上做创新，Spark、Flink 都在其计算引擎层面上既提供批的模式，又提供流的模式。这时尽管引擎层面和运行时是统一的，但实际上开发作业并没有统一，存储也没有统一。

第二个阶段是存储统一。在块存储上提供了更好的随机更新能力，这样离线团队和实时团队就可以共享同一个存储引擎，可以做范围的扫描、增量的读取，也可以做灵活的更新。

至此，实时算子和离线算子依旧是两分语义，我们还是不得不开发两套 SQL。当作业迭代时，就不得不对两套作业都进行调整修正。因此技术需要进一步融合、简化。

6. 离线实时一体终态：增量物化视图/增量计算

第三阶段，通过增量物化视图或增量计算的方式，能够很好地抽象离线计算与实时计算。计算过程并不需要每次刷新表的全部状态，而是把表的更新状态记录下来，可累加性的指标通过计算表的增量变更，这样每次关联或者汇聚时的开销仅是全量刷新的五分之一左右。同时通过增量计算，不需要常驻的 CPU 资源、内存资源，可以分钟级调度计算过程。所以相对于 Flink 或者流式计算常驻资源的方式，成本可显著下降，只需要十分之一的流式计算资源即可实现接近的效果。同时增量计算会复用大量数据库中已有的技术，比如状态存储，Flink 数据库里面的表就是典型的状态存储。使用数据库做增量计算可以本质性解决传统 Flink 双流 Join 的 TTL 过期造成的数据不一致问题，数据晚到不再是问题。

这里提出一个开放性问题，什么是好的增量计算技术？并不是有增量计算就一定好，而是在于算子支持的细节上，在 SQL 支持的完整度上。如果所有离线场景下的算子都能够被增量重写，则是非常了不起的事情，但在现实中相距甚远。现在大多数仓都会提供某种增量技术，但实现的效率和方式存在很大差异，比如对 Join 类型的支持，窗口函数的支持等。

7. 实时数据加工链路方案对比

上图中对实时数仓的 Lambda 架构、Kappa 架构和 ProtonBase 批流一体方案进行了对比。可以发现，实时开发链路学习起来确实比较难，有很多新概念，数据状态有多个链路、多个存储，存储的状态多了就很难做到口径一致，多链路、多状态也会增加存储成本。Flink 作业开发难，调试难，运维难阻碍了很多团队的业务迭代，非常适合用 ProtonBase 的增量物化视图技术来提升作业开发效率。

采用 ProtonBase 批流一体方案，可实现数据只存一份，无需中间存储，因此存储成本可大幅降低。同时因为数据质量可以随时检查和修正，数据结构也随时在变更，所以对数据质量的保障也会有本质上的改善。另外，不需要把数据导到另外一个平台中，同一数仓即可支持分析服务、检索服务。

多模检索加速应用创新

1. 从多模数据到多模检索

传统多模数据聚焦存储形态，涵盖结构化、图形、网状等异构数据类型。而新一代多模检索进一步拓展概念边界，将数据使用模式纳入考量范畴：从基于字段的条件过滤、OLAP 多维分析，到多样化数据建模（星型模型、雪花模型、宽表、K-V 存储、无模式架构）；从全文检索、模糊匹配，到语义理解、向量相似度查询，数据应用场景呈现指数级增长。

理想的多模检索系统需构建统一技术底座，以单一平台支撑全链路数据操作。研究表明，SQL 作为描述性语言，凭借强大的语义表达能力，能够有效兼容多元数据模型与应用场景，成为打破数据孤岛、消除冗余存储的关键技术桥梁。通过整合数据存储与使用模式，多模检索技术正推动数据基础设施向集约化、高效化方向演进。

2. 多模检索的核心需求

多模检索的核心需求包括：

首先是性能可预期。不同业务场景对性能需求差异显著，伴随数据消费向数据产品化转型，外部 API 调用量激增，对服务稳定性提出严苛要求。数据平台需在高并发场景下，同时满足低延迟、低抖动与实时性需求，确保查询性能稳定可预测，而非单纯追求速度。这一技术挑战要求架构设计具备卓越的资源调度与负载均衡能力。

第二是能够提供针对多场景的索引优化。全文检索、单字段过滤、统计分析等场景下的数据访问模式差异显著，唯有通过定制化索引策略，为每种场景匹配最优索引结构（如倒排索引用于全文检索、B 树索引支持快速过滤、列式存储优化统计分析，全局二级索引提高 QPS），才能实现系统对复杂场景的灵活支持，确保多模态数据查询的高效性与稳定性。同时，索引的增加也不应该显著降低系统的写入更新吞吐，否则会牺牲系统的实时性，这对索引的实现能力提出了更高的要求。

还有一个核心问题就是系统架构的可靠性，如何做到系统之间的隔离，让高 SLA 的业务和低 SLA 业务能够隔离开，这是系统建设中的关键能力。

3. ProtonBase 索引、性能、自适应

ProtonBase 在存储上也进行了创新：

支持行存、列存、混存，行存面向吞吐更友好，列存面向分析更友好，用户可根据使用场景自由选择。支持多类型索引，通过查询优化器智能选择合适的索引，实现了系统的收敛和运维上的简化。在数据模型上将 JSON 作为核心数据结构，更具灵活性，可使用 Schema Free 方式处理埋点数据、IoT 数据。对 JSON 数据实现了列式自适应压缩，可将高频字段自动抽取成内部列，做进一步的压缩，以节省存储空间，查询效率上也得到了提升。另外，实现了深度的 JSON 倒排索引，不管是通过 JSON PATH 过滤，还是 JSON 字段检索，都能够实现跟原生列一样的吞吐效率。全局二级索引也是 ProtonBase 的一大特色，很多 MPP 系统往往会因为一个查询而占用大量 CPU 资源，为了追求低延迟会把所有机器资源都利用起来。ProtonBase 为更好地支持高 QPS 场景，实现了一套全局二级索引。在系统运行时，无需将所有节点都拉起，而是可以根据查询访问的 Pattern 快速定位数据，通过更少的节点和 IO 降低每个查询的负载，从而提高整个系统的吞吐。全局二级索引和列存自适应索引的组合搭配，可以用更少的索引支持更高的 QPS，且不降低系统的实时吞吐能力。ProtonBase 具有很多自适应能力，这意味着用户不需要指定并发度，不需要做数据的分片，不需要考虑数据扩容时再搬迁，而是由系统自动根据数据规模和查询特点选择合适的并行度，以提供更好的吞吐和延迟。

4. 融合传统搜索技术和向量检索

在 AI 领域，向量检索需求驱动数据库能力迭代升级。传统向量数据库单一检索模式已难以满足复杂业务需求，行业研究表明，采用向量检索与关键词混合的融合搜索策略，可使 RAG（检索增强生成）系统查询准确率从 20%-40% 跃升至 90% 以上。未来，向量检索场景将向标量与向量数据融合检索演进，唯有将传统数据库技术与向量处理能力深度整合，才能构建高效、精准的智能检索解决方案。ProtonBase 支持向量数据融合搜索，支持 HNSW 和 IVFFlat 多种向量索引。

5. 实时 AI 工作流，Feature Store 落地 Data + AI

上图中展示了一个 Data+AI 实时工作流。通过大数据平台采集数据，在数据平台中进行数据加工，加工好的数据投递到 Feature Store，用来支持各种在线推荐、风控等，然后再采集效果数据对推荐策略进行评估，同时实时加工新的行为数据，实时更新对应特征。

这是一套几乎所有推荐系统都会采用的工作流，过去系统能力有限，这套工作流往往会分成实时和离线两条链路，还会分成加工工作流、服务工作流，非常分散。

下一代的 Feature Store 应该是统一的，既可以做特征加工，又可以做特征服务。数据进来之后，数据科学家对数据进行抽象转换、特征提取，同时特征服务支撑在线推荐系统高并发、低延迟、毫秒级的快速响应。 Feature Store 需要及时更新特征指标，以反应上下文的变化。实时与离线特征结合，推荐系统的效果才会更准确。

6. ProtonBase：离在线一体的 Feature Store

ProtonBase 离在线一体 Feature Store 构建了高性能多模检索引擎，包含正排、倒排、向量及全文检索功能，取代传统 HBase、Redis、ClickHouse 等多系统架构，实现了多场景一站式支持。其统一计算框架覆盖离线与在线特征全生命周期管理，通过同一引擎完成特征更新计算，消除了系统间数据同步障碍。依托智能物化视图机制，底层事件数据触发特征联动更新，可大幅提升数据处理效率。同时，时间点恢复（PITR）功能支持特征版本回溯，可灵活回滚至任意历史状态，保障数据可追溯性与系统容错能力。

7. ProtonBase：弹性、隔离，保障 SLA

资源隔离是保障系统可靠性的核心能力。ProtonBase 在共享存储架构上，构建了高度灵活的业务单元隔离体系，可在一份共享存储上根据数据写入、高并发查询、离线 ETL 等差异化业务场景划分不同业务单元。每个业务单元均可根据需求实现弹性伸缩，针对离线大数据回归等场景，采用垂直弹性策略，灵活扩展节点数量（如从 10 节点扩容至 100 节点）以应对周期性负载。面向在线高并发场景（如促销活动），通过横向扩展多个同构计算节点，利用负载均衡技术可实现 QPS 的横向扩展。该架构在确保业务单元 SLA 独立保障的同时，实现了数据的统一管理与共享，减少了数据割裂，构建了理想的隔离与保障基础架构。

ProtonBase 实践场景与案例分析

ProtonBase 凭借上述优势，在多领域积累了丰富经验，下面将分享一些典型案例。

1. 服务质量监控：实时链路升级、稳定性提升

第一个场景是服务质量监控。以往，众多中小型企业采用 Flink 开发实时链路监控系统，面临开发难度高、学习成本大的挑战，且流式驱动模式存在资源长期占用、消耗量大的问题。

经 ProtonBase 改造后，系统将事件驱动计算转换为仓内物化视图计算，复用数仓离线开发脚本构建增量物化视图，实现了实时刷新，在保障实时监控能力的同时，使架构得到大幅简化。用户无需掌握多套开发语言，仅需使用单一SQL 即可完成操作。此外，系统不仅保留结果数据，还留存明细数据，支持企业在 OLAP 场景下开展深度数据分析，相比传统单机数据库，查询效率得到了显著提升。

2. SaaS 服务商：多模检索、负载隔离、数据强一致

第二个场景是，针对 SaaS 服务商数据接入源多样（涵盖结构化、文档及流式数据），且不同规模客户（大客户、小客户及长尾客户）数据吞吐量差异大、数据一致性要求高的痛点，ProtonBase 提供了优化方案。传统数仓平台难以保障 ACID 一致性，仅能实现最终一致性，而 ProtonBase 通过数据同步服务实时整合多元数据，并依托灵活的隔离机制，为不同客户划分独立业务单元。在此基础上，ProtonBase 通过优化索引结构提升系统性能与吞吐量，同时支持各业务单元独立进行弹性扩缩容，确保不同客户的 SLA 得到精准保障，有效解决数据一致性与服务差异化难题。

3. 实时湖仓汇聚，实时 AP 分析

第三个场景是在 AWS 应用中，某头部出海电商客户原采用云原生湖仓架构，试图通过可更新的数据湖格式整合异构数据源，但受限于 Hudi 数据结构，Schema 演变能力薄弱，上游数据结构变更时需手动调整同步链路，且不支持分库分表数据合并至数仓。此外，数据经 S3 加工后投递至 Redshift 消费时，面临吞吐与并发性能瓶颈。

ProtonBase 介入后，采用 Iceberg 格式优化数据接入流程，显著提升了数据处理吞吐能力，成功攻克 Redshift 高并发场景下的延迟难题，将原本耗时几十分钟的作业处理效率提升至分钟级，大幅优化了数据处理链路与分析时效性。

Data + AI 展望

1. Data + AI 完整的系统架构

随着 Data 与 AI 深度融合，数据架构将迎来全新变革。如图所示，当前实时湖仓架构已存在复杂的数据同步链路，以支撑多样化的数据消费需求。而 AI 平台的引入，进一步拓展了数据消费场景，其对离线特征、在线特征、向量特征以及倒排索引等数据的存取依赖，使得数据平台不仅要满足传统报表分析需求，更需适配 AI 训练与推理场景。这无疑将加剧系统架构的复杂性，对数据平台的性能、灵活性与兼容性提出更高要求。

2. 数据智能的新范式 Pro