向量技术直击 360 商业化三大痛点，助力业务 AI 化进程加速 80%

作者｜管元峥，360 商业化业务线数据库负责人

360 商业化业务线作为 360 集团的业务核心，肩负着推动公司商业化进程、开拓市场新篇章的关键使命。而在数据处理的过程中，数据库技术对于业务发展的重要影响愈发凸显。在我们现有的业务线中，应用了多种类型的数据库，包括关系型数据库 MySQL、OceanBase、TiDB，以及非关系型数据库 Aerospike、Pika 等。

其中，OceanBase 是我们数据库中的新成员，虽然仅投入使用不到两年，但表现亮眼，帮助我们解决了不少系统难题。此外，我们也将 OceanBase 应用于四个 AI 场景，推动了业务的 AI 化转型。在本文中，我将结合 360 商业化业务线的独特业务特点，与 OceanBase 的产品特性相融合，分享 OceanBase 在数据库运维领域的实际应用和突出优势。

向量化存储和查询需求，OceanBase 成最佳选择

在 360 商业化业务线中，OceanBase 的落地背景与我们的实际业务场景紧密相关。

从技术角度而言，360 商业化业务线分为四类。

第一类是 KV 类存储场景，要求高并发、低延迟，并具备海量存储能力，采用 Aerospike 和 Pika 来支撑。

第二类是强 AP 类业务场景。离线分析类场景采用 Hive；在线实时分析类场景采用 Flink 加 Doris。

第三类是线上业务场景。联机事务类的 TP 场景采用 MySQL 结合 TiDB 来支撑；联机分析类的 HTAP 场景使用 OceanBase 作为支撑，该场景也是我们最初选择 OceanBase 的切入点。

第四类为新场景，随着大语言模型的发展，我们的业务中出现了 AI 创新类场景，要求底层数据库支持向量化存储和查询能力，经过一段时间的调研，我们也决定选择 OceanBase 来支撑该业务。

解决三大痛点，广告实时报表效率提高 80%

那么 OceanBase 在 360 商业化业务线中将面临哪些实际场景？

在互联网广告的整个业务链条中，共分为五个阶段，分别是：广告创意与策划、媒体请求、竞价投放、展示/点击/消费、广告报表。

第一阶段：广告创意与策划。广告创意与策划阶段决定广告目标、受众、预算等关键信息，这些信息将用于媒体请求阶段。广告主或代理商根据策划内容，选择合适的广告平台或媒体，并向其提交广告需求，明确广告形式、投放时间、目标人群等。

第二阶段：媒体请求。媒体请求提交后，广告平台会根据广告主的需求，进入竞价投放阶段。

第三阶段：竞价投放。在该阶段，广告平台通过实时竞价（RTB）或程序化购买等方式，将广告主的广告参与竞价。广告平台根据广告主的出价、目标受众匹配度等因素，决定广告展示的机会。

第四阶段：展示/点击/消费。竞价成功后，广告进入展示阶段，并会在用户浏览网页、使用 App 等场景中展示。广告主将根据用户点击广告的行为或展示次数支付费用（CPC 或 CPM）。这一阶段是广告效果的直接体现，也是广告主投入资金的消耗阶段。

第五阶段：广告报表。广告展示、点击和消费数据会被广告平台实时记录。这些数据会被汇总并生成广告报表，提供给广告主。报表中通常包括展示次数、点击次数、点击率、消费金额、转化率等关键指标，帮助广告主评估广告效果。报表数据也会为下一轮广告创意与策划提供依据，比如优化广告创意、调整投放策略、重新定位目标受众或修改预算分配，从而进入新一轮的广告投放循环。

通过这五个阶段的紧密衔接，广告主能够不断优化广告投放策略，提升广告效果。

数据库在互联网广告的整个业务链条中发挥关键作用，我们以第五阶段——广告报表业务为例阐述 OceanBase 在我们业务中的使用情况。

假设我是一个花店老板，想在抖音、快手、小红书等流量媒体平台上投放广告。当抖音有空闲广告位时，我的宣传物料会被填充展示，作为广告主，我应支付给流量媒体宣传费用。我们的业务就是搭建一个撮合流量媒体与广告主达成交易的平台。而广告报表在整个链条中起到承上启下的作用。它既能将前四个阶段产出的数据具象化为报表，又能指导广告主调整广告投放策略或产品销售策略。因此，报表类业务是商业广告的重要链条之一。

从图 1 可见，报表类业务线涵盖多条产品线，而这些只是报表的冰山一角，实际报表的维度非常复杂且众多。每增加一个维度，报表的复杂性就会呈几何级数上升，因为各项数据之间存在笛卡尔积关系。

图 1 报表类业务的产品线

其中关键的一条是商业化产品线的搜索产品线。我们自研了纳米搜索，它支持文字、语音、拍照、视频等多种搜索方式，为用户提供从简单到深入的全方位解答方案，轻松解决识人、识物、解题、旅游、攻略等各类问题。同时，它能直接调用豆包、文心一言等 16 款大型语言模型，并配备数十款智能工具，适用于写作、分析、翻译、旅游规划等多种场景。

当处理 HTAP 类离线报表类业务时，我们采用 MapReduce 读取 HDFS 的数据，最终在 Hive 中形成离线的基表。同时，通过与业务紧密相关的 job 生成报表，并灌入我们的系统中，如图 2 所示。在 OLTP 类系统中，前端页面可以拼接各个维度，以支持运营人员和广告主进行查询。

图 2 离线报表类业务处理方式

但这样的处理方式存在一些明显的痛点亟待解决。

1.查询范围大时容易产生 OOM（内存不足）问题。

我们进行过极限测试，在查询半年以内的聚合类数据时，行存方式下没有问题，因为计算节点会在内存中进行大规模聚合计算。但如果查询时间范围扩大至半年以上，计算节点在行存方式下容易产生 OOM。这导致我们在业务侧不得不做出取舍，要么保证数据库稳定性，要么保证服务可用性。甚至可能需要限制业务方查询半年以上的数据，若需查询，则需使用 Hive 等大数据 ETL 系统。

2.高并发下系统压力较大。

在大规模并发报表查询时，会产生瞬间热点读问题。虽然系统可以识别热点读并迅速进行负载均衡，但负载均衡需要时间。更糟糕的是，如果业务方设置了搜索域超时时间，并经常在查询未按时返回时再次触发查询，这会加重系统负载。

3.资源利用率不均衡。

广告类报表的业务高峰期大致在早上 9 点到 11 点，下午 2 点到 5 点，这与互联网人的黄金工作时间非常吻合。在这段时间内，广告主和运营人员都会查询昨天产出的报表和实时在线报表，导致系统资源迅速消耗。而在业务低峰期，基本没有什么流量。这就要求数据库具备错峰计算和横向扩缩容的能力。

那么 OceanBase 的解决方案是什么？

首先，OceanBase 通过优化底层存储和并发调度机制，提升了大规模并发计算的能力。运维人员只需开启 OceanBase 的 Auto DOP 功能，优化器便会根据 SQL 语句的复杂度，自动调整并发度以加速 SQL 执行。

其次，OceanBase 提供了分区自动分裂的功能。OceanBase 4.3.5 版本中系统可以根据用户指定的大小，自动对单表进行分区。这样，单表的 leader 不再集中在一个 OBServer 上，从而避免了资源热点，提高了资源使用率。以 1-1-1 架构的集群为例，原本全表扫描时，只能使用一个 C 的资源；但开启分区自动分裂功能后，资源可以均匀分配到每个 OBServer 上，从而充分利用资源。

再者，OceanBase 的物化视图功能非常适合报表类业务。报表类业务的数据域变化不频繁，且 join 的表相对固定，但前端传过来的查询条件却不可预知。物化视图可以在业务低峰期进行统一计算，避免业务高峰期重复计算的开销。虽然物化视图会占用底层 OceanBase 存储层面的磁盘空间，但这是一种用空间换时间的策略。OceanBase 还支持按时间维度对物化视图进行周期性刷新，不过在某些数据相对固定的场景中，可以通过 DBMS 包手动刷新。如果 join 出的数据量大且并发查询慢，还可以在物化视图上创建索引来加速查询。

此外，OceanBase 4.3.3 提出了列存存储模式。在创建表时，可以选择行存、列存或行列混存。如果有对列存副本和行存副本进行隔离的需求，还可以将列存副本单独指定到一个 OBServer 上存储。这种方案可以减少无关数据的加载，降低 I/O 开销，非常适合大规模的分析类业务场景。

采用上述解决方案后，360 商业化的广告实时报表业务分析效率提高了 80%，查询时间从 5min 缩短到 40s，查询范围也从六个月扩大到了一年。同时，我们为广告主和运营人员提供了稳定的商业化报表服务，如图 3 所示。

图 3  360 商业化的广告实时报表业务分析

向 AI 化演进，赋能四大业务场景

对于 360 商业化的业务来说，数据库解决现有问题是基础，具备未来拓展能力也至关重要。 OceanBase 一直在不断增加 AI 相关的能力，在其所有 AI 能力中，Embedding 是整个流程中的重要环节，它将高维稀疏的语义信息转换成低维稠密的二进制形式。简而言之，就是将文档等文本内容转换为向量进行存储，这些转换后的数据被存储在 OceanBase 中。通过 Embedding 将文本（如广告文案、用户行为数据、商品描述等）转换为向量，能够更准确地捕捉语义信息，Embedding 后的文本，更像是扩展了大模型处理专业知识的能力，这种能力不需要进行模型微调，对既想用大模型能力且又没有模型微调手段的业务场景比较适用。

OceanBase 在底层存储层面支持向量存储，能够容纳这种稠密的二进制数据。此外，OceanBase 还在其上层提供了常用的索引支持，如 hnsw 等，以进一步优化数据的检索和管理效率。不仅如此，OceanBase 还配备了一层向量搜索层，便于用户进行高效的向量数据搜索。

那么，使用 OceanBase 进行向量存储有哪些优势呢？

第一个优势是易用性。我们之前调研过 Milvus，其涉及的组件非常多且用 K8s 来管理，同时每个组件都需要监控。因此，监控链路比较复杂，运维人员也面临 K8s 和各组件的学习成本问题。相较之下，OceanBase 的易用性优势主要体现在两方面：

• 对于运维人员来说，他们更擅长处理通用型数据库的能力，如运维和查询。我们希望这种能力能快速复制到向量化数据库中。OceanBase 支持通过标准的搜索方式进行向量化查询，这对我们来说非常友好。

• 对于开发人员来说，他们同样更擅长通用型数据库的增删改查和 SQL 语句操作。他们的时间应更多地用于业务逻辑代码的开发。学习一款新的向量查询语言对他们来说是有一定成本的。而 OceanBase 的易用性降低了这一成本。

第二个优势是完善的监控能力。OceanBase 提供了 OCP 平台，可以对集群进行管理。在 OCP 平台上，可以从主机集群和租户级别进行全方位监控。这让运维人员可以一目了然地了解集群的状况，知道是否产生了瓶颈，或是否需要扩容资源。

第三个优势是水平扩展能力。 AI 业务在初期通常需要一切起始资源进行业务模式的实验，业务是否能成功存在不确定性。OceanBase 的水平扩展能力可以让团队灵活调整资源，降低试错成本。例如，AI 业务突然爆火（如某个推荐算法效果极佳），此时限量租户发生资源瓶颈，需要快速扩展资源以应对激增的用户请求。我们可以采取增加 unit 的数量或提高 unit 规格的方式灵活调整资源。OceanBase 的水平扩展能力可以确保系统在高并发场景下稳定运行。如果业务表现不佳，则可以缩减资源，降低成本。

第四个优势是内置了高可用机制。这为我们的业务提供了额外保障。在进行向量搜索后，如果未查到答案，直接传到大模型中可能导致大模型无法准确回答。而 OceanBase 内置的 Paxos 机制，可以有效保证我们时时刻刻都能查到答案，让大模型的回答更加准确。

在我们的业务中，OceanBase 被应用于以下四个业务场景，如图 4 所示。

第一个业务场景是广告主的查询场景。我们可以将实时报表和离线报表进行向量化后存储到 OceanBase 中，使广告主能够通过自然语言进行询问。例如，询问今年情人节鲜花与去年情人节鲜花的收益情况，或如何调整链路以提高收益。

第二个业务场景是 SRE 的运维知识库。这更像是一个 ChatDBA 的角色。我们可以结合 AI 快速检索故障解决方案，帮助新手 DBA 加速问题定位，从而减少服务的不连续性。

第三个业务场景是开发流程的标准化，这主要与我们的 IDE 相结合。例如，对于开发人员，我们首先将 DBA 的最佳实践开发手册向量化到 OceanBase 中。当开发人员编写效率较低的循环查询时，IDE 会自动提示他们。例如，如果开发人员编写了一个选择所有列的查询语句 SELECT * FROM t，IDE 会自动提醒他们这可能会加载无关列，同时建议其在循环语句中添加 WHERE 条件，以减少线上负担，避免不必要的循环，从而提高代码质量。

第四个业务场景涉及 Dify，这是一个大语言应用开发平台。自 OceanBase 4.3.3 版本后，它支持了向量数据库。而 Dify 从 0.1 版本开始，也支持将 OceanBase 作为其底层向量存储。

图 4  OceanBase 被应用于四个业务场景

作为开源用户对 OceanBase 的期待

以上就是我们在使用 OceanBase 的过程中感受到的优势，但作为 OceanBase 的开源用户，我们也期待其在未来能够越来越好。

首先，我们热切期望 OceanBase 能够支持单机多实例部署。目前 OceanBase 仅支持单主机部署一个 OBServer 实例。在如今的胖主机时代，每个主机往往配有多块高性能硬盘，但只能通过 RAID 或 LVM 方案整合硬盘资源，这并未能在效率与成本上做到极致。期待 OceanBase 后续能支持单机多实例的部署方案，以更好地利用主机资源。同时，我们也希望 OceanBase 社区能持续分享最佳实践，鼓励用户积极参与讨论和反馈，共同促进 OceanBase 的发展。

其次，我们期待 OceanBase 将隐藏参数透明化。在实际工作中，我曾多次遇到需要调整隐藏参数以恢复集群正常运行的情况。我们希望 OceanBase 能够开放这些隐藏参数，让用户更好地了解 OceanBase 的运行机制。

最后，我们关注版本兼容性问题。在实际工作中， 我曾遇到过 OBServer 内核新版本发布后，OMS 不支持该内核版本的情况，需要手动打补丁来解决。尽管 OceanBase 工程师后期提供了自动打补丁的解决方案，但我们更希望 OceanBase 能够减少版本不兼容带来的困扰，从而提高用户体验。