编者按
在 11 月 18 日举行的 2025 OceanBase 年度发布会上,OceanBase CEO 杨冰在分享商业化 5 年来取得的进展时,提到 OceanBase 以一体化架构,灵活支持从分布式到单机、TP 到 AP 场景的客户需求,正为更广阔的集中式与实时分析市场提供一条可行路径。
本文是 OceanBase 实时分析能力解读系列文章的第四篇,详细介绍了 OceanBase 的旁路导入( Direct Load )能力,而这项技术,也是 OceanBase 实现“HTAP 一体化”的关键技术之一。
作者 | 剑鸣,OceanBase 研发团队技术专家
过去,人们说 OceanBase 是“TP 强”;今天,我们用旁路导入证明:OceanBase 同样“AP 快”。
提到 OceanBase,很多人的第一反应是:“支付宝那个做高并发事务的数据库吧?”没错,在 TP(事务处理)领域,OceanBase 确实久经考验——支撑“双11 ”每秒百万级支付交易、银行核心系统 7×24 小时不间断运行……
但你可能不知道:在 AP 场景下,OceanBase 也开始逐步向第一梯队产品能力看齐。
今天,我们就来聊聊 OceanBase 的旁路导入( Direct Load )能力——这项技术,正是 OceanBase 实现“HTAP 一体化”的关键技术之一。
一张表,两种写入:TP 与 AP 无缝共存
在传统数据库世界里,TP 和 AP 往往是“鱼与熊掌”:
MySQL:擅长事务处理,但批量导入慢,大数据量分析查询性能不佳;
ClickHouse/Doris:批量导入快、分析性能强,但不支持高并发事务写入,难以保证事务一致性
而 OceanBase 做到了“既要又要”。
同一张表,可以:
处理高并发的 INSERT/UPDATE/DELETE(TP 实时写入);
需要时通过旁路导入快速加载 PB 级数据(AP 批量写入)
更重要的是——两者互不干扰。得益于 OceanBase 内置的资源隔离( Resource Group )机制,用户可以对旁路导入任务占用的 CPU 和 I/O 进行配额限制。这意味着,即便是业务高峰期的实时交易与后台的大规模数据导入并行发生,系统也能通过资源隔离确保核心交易链路的响应稳定,真正实现 TP 与 AP 业务在同一节点上的资源解耦与互不干扰。
这背后的秘密,就是 OceanBase 基于 LSM-Tree 的存储架构,天然支持高效的批量写入与实时事务处理。
旁路导入到底有多快?快在哪?
简单说,旁路导入就是绕过常规事务路径,直接将数据批量构建为存储层可识别的 SSTable 文件。
旁路导入 AP 写入路径:
数据输入 → 排序去重 → 直接构建 SSTable → 批量写入存储 → 多副本同步 → 立即可见
OceanBase 的存储引擎是一种 LSM-Tree 结构的存储引擎,数据分成基线数据和增量数据两种。基线数据 Major SSTable,目前在 AP 应用中会配置为列存格式。
增量数据包含 MemTable, Mini SSTable, Minor SSTable等等数据,目前是行存格式。旁路导入的根据数据写的位置,分成全量旁路导入和增量旁路导入。全量旁路导入会把已有的数据和导入的数据写成基线,适用于空表和数据量比较小的表。增量旁路导入会把数据写到增量的 Mini SSTable 中。以下是全量和增量旁路导入的数据操作示意图。
全量旁路导入
全量旁路导入会把导入的数据(图中的 CSV ) 按照主键进行排序,然后再和已有的数据进行归并以后直接写到基线的 Major SSTable 中。
增量旁路导入
增量旁路导入会把导入的数据(图中的 CSV )按照主键进行排序,直接写到 Mini SSTable 中。
这两种导入方式都直接绕过了 LSM-Tree 的层层结构(例如 MemTable 复杂的 BTree 结构),通过高效的排序直接写成 SSTable,极大地提高了批量数据写入的速度。
核心技术优势
实测性能数据
在行业公认的 ClickBench 分析型数据库基准测试中,OceanBase 在 c6a.4xlarge 机型上取得了 198s(Load Time) 的导入成绩(我们导入的性能能目标是 clickbench 做到 200s 以内,目前达到了这个目标),通用的单核导入速度在 2-5 万行/s。
详情可参考 ClickBench 官网: https://benchmark.clickhouse.com/#system=-&type=-&machine=+ca4e&cluster_size=-&opensource=-&tuned=+n&metric=load&queries=-
这一数据表明,OceanBase 的旁路导入效率已经达到了主流专用 OLAP 数据库(如列存分析引擎)的性能水位,能够满足 PB 级数据仓库场景下的严苛时效要求。
更重要的是,OceanBase 的 PB 级数据导入时 CPU 和 I/O 资源占用可通过资源管理模块控制,不影响在线业务。
提供完整的数据库特性支持
索引与约束
主键、全局索引、局部索引,导入时自动并行构建
唯一性约束、非空约束,导入时实时校验
冲突处理:支持 IGNORE、REPLACE 等策略
分区表支持
支持 Range、Hash、List 等各类分区策略
多级分区完全兼容
分区级并行导入,充分发挥分布式优势
可以指定分区导入,只导入特定分区
事务一致性
导入过程中数据对外不可见
支持导入失败自动回滚
数据类型完整支持
所有标准 SQL 数据类型
LOB 大对象(CLOB/BLOB)
JSON、GIS 等扩展类型(持续完善中)
旁路导入在不牺牲原有数据库功能的情况下提供了快速的数据导入性能。举个交易历史库的例子:
用户的历史订单数据通常会放到交易历史库里面,历史库和在线库的区别是历史库存储的数据量大,但是查询较少。历史库通常使用 IOPS 比较低的大容量存储来降低成本。用户的订单数据会定期从在线库迁移到历史库,这个迁移的过程使用的就是旁路导入。历史库也需要原来在线库的索引来支撑用户各个维度的查询。旁路导入支持各种已有的索引就是必然选择。
开发者友好:多种方式,随心接入
无论你是 DBA、数据工程师还是应用开发者,都能轻松上手。
SQL 原生支持
兼容 MySQL LOAD DATA 语法,一行命令搞定
-- 从本地文件导入LOAD DATA /* direct(true, 0) parallel(32) */ INFILE 'orders.csv' INTO TABLE orders;-- 从远程存储导入(支持 OSS/S3)LOAD DATA /* direct(true, 0) parallel(32) */ INFILE 'oss://bucket/path/data.csv' INTO TABLE orders;
INSERT SELECT + 内部表/外表
-- OceanBase insert select做ETLINSERT /* direct(true, 0) enable_parallel_dml parallel(32) */INTO summary_tableSELECT * FROM detail_tableWHERE date >= '2024-01-01';-- OceanBase insert select url外表导入数据INSERT /* direct(true, 0) enable_parallel_dml parallel(32) */INTO detail_tableSELECT * FROM FILES(location = 's3://bucket/path', type = 'parquet', pattern='*');
专业工具
OB Loader 命令行工具
obloader -h 127.0.0.1 -P 2881 \-u user@tenant#cluster -p password \--table=logs \--direct-load \--file-path=/data/logs/
Table API(适用于 KV 场景)
通过 OceanBase Table API,支持 KV 模式的批量写入,同样可以走旁路导入路径。
数据源与格式支持
文件格式:CSV、JSON、Parquet、ORC
存储源:本地磁盘、OSS、S3、HDFS、NFS, COS, OBS, ODPS
字符集:UTF-8、GBK 等多种字符集
压缩格式:gzip、snappy, lz4, zstd 等
开箱即用,无需额外组件或中间件。
回归业务价值:用一套架构,兼顾高频交易与海量分析
旁路导入,看似只是一个“导入优化”,实则是 OceanBase 原生 HTAP 架构的自然体现。
架构优势支撑
LSM-Tree 存储引擎
天然分层存储:MemTable(热数据) + SSTable(冷数据)
旁路导入直接生成 SSTable,与 TP 写入的 MemTable 各司其职
后台自动 Compaction,数据归并优化,查询性能不衰减
Paxos 多副本协议
旁路导入的 SSTable 文件同样通过 Paxos 协议同步到多副本
保证强一致性,任一副本故障数据不丢失
高可用与高性能两不误
并行执行框架(PX)
旁路导入天然基于 PX 框架实现
多个分区、多个索引并行构建
充分利用多核 CPU 和分布式资源,线性扩展能力
原生分布式架构
计算层与存储层分离,资源弹性调度
分区级数据分布,单表可扩展到 PB 级
一份数据,既能高并发交易,又能大规模分析
OceanBase 旁路导入能力的完善,为架构师提供了一种新的选择:在某些对实时性要求极高的混合负载场景下,我们或许不再需要维护一套独立的 OLAP 数据库及复杂的数据同步链路。 一套系统,一份数据,即可兼顾高频交易与高速分析。
在线咨询
优质资料下载
往期推荐
▼ 点击「阅读原文」,查看更多技术干货

