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

本文摘自 《OceanBase社区版在泛互场景的应用案例研究》电子书，感兴趣的朋友欢迎打开链接观看。
<font >

首先为大家推荐这个 OceanBase 开源负责人老纪的公众号 “老纪的技术唠嗑局”，会持续更新和 #数据库、#AI、#技术架构 相关的各种技术内容。欢迎感兴趣的朋友们关注！
作者：管元峥，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能够减少版本不兼容带来的困扰，从而提高用户体验。


来源：程序园用户自行投稿发布，如果侵权，请联系站长删除
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！