OceanBase向量技术直击360商业化三大痛点，业务分析AI化进程加速80%
本文摘自《OceanBase社区版在泛互场景的应用案例研究》电子书，获取完整版内容可点击文末”阅读原文”。
作者：管元峥，360商业化业务线数据库负责人
360商业化业务线作为360集团的业务核心，肩负着推动公司商业化进程、开拓市场新篇章的关键使命。在数据处理的过程中，数据库技术对于业务发展的重要影响愈发凸显。在现有的业务线中，应用了多种类型的数据库，包括关系型数据库MySQL、OceanBase、TiDB，以及非关系型数据库Aerospike、Pika等。
其中，OceanBase是我们数据库中的新成员，虽然仅投入使用不到两年，但表现亮眼，帮助我们解决了不少系统难题。此外，我们也将OceanBase应用于四个AI场景，推动了业务的AI化转型。
一、向量化存储和查询需求，OceanBase成最佳选择
从技术角度而言，360商业化业务线分为四类：
- KV类存储场景 — 要求高并发、低延迟，并具备海量存储能力，采用Aerospike和Pika来支撑
- 强AP类业务场景 — 离线分析类场景采用Hive；在线实时分析类场景采用Flink加Doris
- 线上业务场景 — 联机事务类的TP场景采用MySQL结合TiDB来支撑；联机分析类的HTAP场景使用OceanBase作为支撑
- 新场景 — 随着大语言模型的发展，业务中出现了AI创新类场景，要求底层数据库支持向量化存储和查询能力，经过一段时间的调研，也决定选择OceanBase来支撑该业务
二、解决三大痛点，广告实时报表效率提高80%
在互联网广告的整个业务链条中，共分为五个阶段：广告创意与策划、媒体请求、竞价投放、展示/点击/消费、广告报表。
广告报表在整个链条中起到承上启下的作用。它既能将前四个阶段产出的数据具象化为报表，又能指导广告主调整广告投放策略或产品销售策略。因此，报表类业务是商业广告的重要链条之一。
当处理HTAP类离线报表类业务时，采用MapReduce读取HDFS的数据，最终在Hive中形成离线的基表。同时，通过与业务紧密相关的job生成报表，并灌入我们的系统中。在OLTP类系统中，前端页面可以拼接各个维度，以支持运营人员和广告主进行查询。
但这样的处理方式存在一些明显的痛点亟待解决：
1. 查询范围大时容易产生OOM（内存不足）问题。 在查询半年以上的聚合类数据时，行存方式下计算节点会在内存中进行大规模聚合计算，容易产生OOM。
2. 高并发下系统压力较大。 在大规模并发报表查询时，会产生瞬间热点读问题。虽然系统可以识别热点读并迅速进行负载均衡，但负载均衡需要时间。
3. 资源利用率不均衡。 广告类报表的业务高峰期大致在早上9点到11点，下午2点到5点。在这段时间内，广告主和运营人员都会查询报表，导致系统资源迅速消耗。而在业务低峰期，基本没有什么流量。
那么OceanBase的解决方案是什么？
首先，OceanBase通过优化底层存储和并发调度机制，提升了大规模并发计算的能力。运维人员只需开启OceanBase的Auto DOP功能，优化器便会根据SQL语句的复杂度，自动调整并发度以加速SQL执行。
其次，OceanBase提供了分区自动分裂的功能。OceanBase 4.3.5版本中系统可以根据用户指定的大小，自动对单表进行分区。这样，单表的leader不再集中在一个OBServer上，从而避免了资源热点。
再者，OceanBase的物化视图功能非常适合报表类业务。报表类业务的数据域变化不频繁，且join的表相对固定。物化视图可以在业务低峰期进行统一计算，避免业务高峰期重复计算的开销。OceanBase还支持按时间维度对物化视图进行周期性刷新。
此外，OceanBase 4.3.3提出了列存存储模式。在创建表时，可以选择行存、列存或行列混存。如果有对列存副本和行存副本进行隔离的需求，还可以将列存副本单独指定到一个OBServer上存储。这种方案可以减少无关数据的加载，降低I/O开销。
采用上述解决方案后，360商业化的广告实时报表业务分析效率提高了80%，查询时间从5min缩短到40s，查询范围也从六个月扩大到了一年。
三、向AI化演进，赋能四大业务场景
对于360商业化的业务来说，数据库解决现有问题是基础，具备未来拓展能力也至关重要。OceanBase一直在不断增加AI相关的能力，在其所有AI能力中，Embedding是整个流程中的重要环节，它将高维稀疏的语义信息转换成低维稠密的二进制形式。
使用OceanBase进行向量存储有哪些优势呢？
第一个优势是易用性。 对于运维人员来说，他们更擅长处理通用型数据库的能力。OceanBase支持通过标准的搜索方式进行向量化查询，这对我们来说非常友好。对于开发人员来说，他们同样更擅长通用型数据库的增删改查和SQL语句操作。
第二个优势是完善的监控能力。 OceanBase提供了OCP平台，可以对集群进行全方位监控。这让运维人员可以一目了然地了解集群的状况，知道是否产生了瓶颈，或是否需要扩容资源。
第三个优势是水平扩展能力。 AI业务在初期通常需要一切起始资源进行业务模式的实验。OceanBase的水平扩展能力可以让团队灵活调整资源，降低试错成本。
第四个优势是内置了高可用机制。 这为我们的业务提供了额外保障。OceanBase内置的Paxos机制，可以有效保证我们时时刻刻都能查到答案，让大模型的回答更加准确。
在我们的业务中，OceanBase被应用于以下四个业务场景：
第一个业务场景是广告主的查询场景。 我们可以将实时报表和离线报表进行向量化后存储到OceanBase中，使广告主能够通过自然语言进行询问。
第二个业务场景是SRE的运维知识库。 这更像是一个ChatDBA的角色。我们可以结合AI快速检索故障解决方案，帮助新手DBA加速问题定位。
第三个业务场景是开发流程的标准化。 这主要与我们的IDE相结合。我们首先将DBA的最佳实践开发手册向量化到OceanBase中。当开发人员编写效率较低的循环查询时，IDE会自动提示他们。
第四个业务场景涉及Dify。 这是一个大语言应用开发平台。自OceanBase 4.3.3版本后，它支持了向量数据库。而Dify从0.1版本开始，也支持将OceanBase作为其底层向量存储。
四、作为开源用户对OceanBase的期待
以上就是我们在使用OceanBase的过程中感受到的优势，但作为OceanBase的开源用户，我们也期待其在未来能够越来越好。
首先，我们热切期望OceanBase能够支持单机多实例部署。目前OceanBase仅支持单主机部署一个OBServer实例。在如今的胖主机时代，每个主机往往配有多块高性能硬盘，但只能通过RAID或LVM方案整合硬盘资源，这并未能在效率与成本上做到极致。
其次，我们期待OceanBase将隐藏参数透明化。在实际工作中，我曾多次遇到需要调整隐藏参数以恢复集群正常运行的情况。我们希望OceanBase能够开放这些隐藏参数。
最后，我们关注版本兼容性问题。在实际工作中，我曾遇到过OBServer内核新版本发布后，OMS不支持该内核版本的情况，需要手动打补丁来解决。尽管OceanBase工程师后期提供了自动打补丁的解决方案，但我们更希望OceanBase能够减少版本不兼容带来的困扰。