--- title: 信也科技案例-客户案例-分布式数据库-OceanBase description: 信也科技 × OceanBase ：从风控核心到 AI 数据底座的探索。LSM-Tree 引擎对海量数据的存储重塑，89TB 的数据被压缩至 29TB，存储空间节约 67%。整体资源利用率提升 40%，新业务节点部署周期缩短 90%。OceanBase 彻底统一在线交易与历史归档技术栈，自动化维护分区全生命周期，带来了海量历史数据存储成本骤降 70%、主租户核心库查询性能跃升 30% 的效果。 image: https://mdn.alipayobjects.com/huamei_22khvb/afts/img/A*OSPzQ6GUQF4AAAAAQHAAAAgAeiGDAQ/original --- 切换语言 - 中文站 - 简体中文 - International - English - 日本站 - 日本語 [AI](https://www.oceanbase.com/obi) 咨询热线 ![](https://mdn.alipayobjects.com/huamei_22khvb/afts/img/A*8a9uRYQL-jYAAAAAQCAAAAgAeiGDAQ/original) # 信也科技 × OceanBase ：从风控核心 到 AI 数据底座的探索 - 70 % 历史数据存储成本骤降 - 30 % 查询性能跃升 - 67 % 存储空间节约 信也科技[FINV]作为纽交所上市的金融科技集团，受最严格的监管，对数据合规、隐私保护与系统安全有着极致的追求，如绝对的数据一致性、极致的高可用，以及应对突发流量的极致弹性。 依托于海量数据与前沿 AI 技术，信也科技打造了行业领先的智能风控体系，支撑高频、复杂的金融交易场景，业务版图已从国内成功延伸至东南亚、澳洲等全球市场。与此同时，也面临跨地域、多时区、高并发的复杂技术挑战。 本文主要阐述信也科技联合 OceanBase，从风控核心到 AI 数据底座的探索。作者为信也科技 DBA 负责人夏平。 ## 历史架构痛点：传统 MySQL 分库分表的技术挑战 信也许多业务最初使用 MySQL 分库分表方案支撑，在该方案中，以下四个痛点对 DBA 而言应该并不陌生。 **第一，研发效能黑洞，跨库查询与分表治理问题。**我们内部有一套面向研发的自动化平台，但当分表数量较多时，排查问题需要做跨分片聚合查询，往往需要 DBA 协助，流程比较繁琐。而且，大部分业务代码被迫适配中间件逻辑，严重拖累敏捷迭代的交付节奏。 **第二，扩容如履薄冰，极高运维风险。**一方面随着业务持续增长，分库分表方案最终必然面临扩容需求。长期来看，分片维护等工作相当枯燥，且存在扩容窗口期的风险。另一方面，面对突发流量洪峰，分库分表后的数据 Rebalance 耗时极长。操作极其繁琐，而且极易引发线上业务剧烈抖动，扩容变高危。 **第三，成本指数膨胀，单机容量触顶。**原有的 MySQL 系统容量和压缩能力有限，随着海量历史冷数据堆积，SSD 存储账单呈指数级飙升，同时闪迪（SanDisk）、美光（Micron）等存储厂商的股价上涨也反映出内存和存储硬件的涨价趋势，给企业成本带来较大压力。 **第四，敏捷迭代绊脚石，DDL 变更阻塞。**第四，敏捷迭代绊脚石，DDL 变更阻塞。成百上千个数据分片形成了“管理孤岛”，导致我们对分库分表做表结构变更（如加字段、改结构等）不仅相当麻烦，而且耗时数天，很难做全局统一管理。目前主流方案是 GH-OST 做在线 DDL，但其在切换时有一个短暂的锁表动作，即使放在业务低峰期，仍可能导致线上事故。 我们曾采用的一种改进方案是：在高峰期暂停 DDL 操作，等窗口期再恢复。但暂停期间会产生大量 binlog，可能会导致该表程序卡死。后来我们调整为：DDL 仅在低峰期执行，过了窗口期后持续等待下一周期，以此规避风险。 ## 分布式数据库选型历程 我们最初并没有主动考虑数据库选型的问题。随着数据不断膨胀，MySQL 分库分表的方案反复面临扩容和成本挑战。当时的解决思路之一是将冷数据切换到成本更低的存储系统。 在选型早期，我们调研过其他数据库产品，因为一些原因最后放弃。恰逢 OceanBase 开源，我们将其纳入调研范围，使用后发现效果不错，与我们内部的自动化平台融合度较高。 选择 OceanBase 主要基于三点： **· 存储成本降低。**OceanBase 采用 LSM-Tree 算法，且在压缩层面做了深度优化，显著降低了存储成本。 **· 弹性扩容便捷。**作为分布式数据库，当归档集群资源不足时，可以平滑地增加几台 OBServer 节点即可解决问题，操作简单。 **· 金融级高可用方案。**作为互联网金融企业，对数据一致性要求极高，OceanBase 的金融级高可用架构满足这一需求。 ## 如何推动研发团队用 OceanBase 选定产品后，推动研发团队使用是另一大挑战。 研发人员没有业务诉求或上级压力时，通常不会主动更换正在稳定运行的 MySQL 方案。如何保证升级后的性能表现，是打消顾虑的关键。 OceanBase 提供了不错的配套工具： **· 迁移评估工具OMA（OceanBase Migration Assessment）可以提供精准的语法兼容性评估。**基于全链路压测思维，制定详尽的割接 SOP。在迁移前，我们可以利用 OMA 抓取源库真实业务流量并在目标库进行仿真回放，预知高并发下的性能风险与锁冲突。 **· 迁移服务 OMS（OceanBase Migration Service）配套完善，支持实时同步和反向同步。**迁移服务 OMS（OceanBase Migration Service）配套完善，支持实时同步和反向同步。这样一来，建立稳固的全量 + 增量实时数据同步链路，在割接窗口期，配合数据实时一致性校验，确保新旧库数据绝对平齐。割接的最强底气在于开启从 OceanBase 到源库的逆向同步链路，并保持老库数据实时鲜活，为随时可能的紧急回滚提供待命的底座。 **我们主要采用两种方案：**一是通过 OMS 同步后在低峰期做割接；二是通过研发控制双写，这是目前使用较多的方案。 双写方案回滚方便，可分别控制读和写，通过灰度流量验证，一旦灰度期间监控发现异常，无需重启应用，直接通过配置中心一键拉回流量，实现秒级无损切回，真正做到进可攻，退可守。 ## 实战破局：从核心业务场景落地到自动化运维 ### 技术升级，实现降本增效、高可用、高可靠 **1.极致降本：LSM-Tree 引擎对海量数据的存储重塑** 使用 OceanBase 后，告别了传统 MySQL B+ 树的页分裂与空间碎片，采用 LSM-Tree 存储引擎将随机写转化为顺序追加写，实现极致的写入性能与双层数据压缩。89TB 的数据被压缩至 29TB，存储空间节约 67%。 **业务场景一：**历史存量业务 (冷热分离)。存量数据的日常访问频次极低且无法下线，占用着大量昂贵的 SSD 存储资源。我们考虑将部分数据切换到 OceanBase，利用其极致压缩能力将海量数据在线归档。在不影响偶尔查询的前提下，大幅削减硬件成本，实现“冷热数据”高效治理。 **业务场景二：**营销投放业务 (高频并发)。这是一个典型的写密集型业务，流水产生极快，且因合规与对账要求，保留周期极长，极易引发容量危机。在 MySQL 分表方案中，每台机器配置两块数据盘，使用压力经常达到 85%。 DBA 需要频繁做归档和表空间收缩，运维压力很大。OceanBase 采用 LSM-Tree 架构，增量数据写入后通过定期合并完成空间回收，无需手动收缩，整体运维压力大幅降低。 值得一提的是， OceanBase “内存追加写”特性完美消除高频写入的 I/O 瓶颈，底层高压缩比彻底瓦解长期保留的容量焦虑，让业务敢于记录详尽流水。 **2.同城双活架构与极致高可用实践** **业务场景三：**同城双活演练。我们每年进行两次同城双活演练，两个机房之间将流量和数据库全部切换。 ![同城双活演练](https://mdn.alipayobjects.com/huamei_22khvb/afts/img/A*Zvw3Toi-Yp4AAAAAQNAAAAgAeiGDAQ/original) **备租户 (Standby Tenant) 容灾体系。**打破传统主备架构局限，基于底层 Redo Log 异步/强同步传输，实现跨机房的“租户级”物理容灾。无论遭遇多极端的机房级故障，坚守底层数据零丢失的绝对红线。 **“切浦江”常态化双活演练。**告别纸上谈兵，将主备角色平滑互换演练融入日常运维。结合业务流量管控与紧急回滚预案，验证全链路可靠性，确保极端场景下核心交易流量接管无感丝滑。 在演练过程中，MySQL 及其他关键数据库会出现抖动，对业务有一定影响。公司管理层也在关注如何将切换影响降到更低、更平滑。OceanBase 的架构天然适配这一需求，通过 OBProxy 和 Service 层访问，切换更加丝滑。如果线上核心业务使用 OceanBase，强烈建议配置 OBProxy。 **3.资源池化与多租户架构：打破物理孤岛，实现极致弹性** **业务场景四：**多租户资源隔离。很多 DBA 在银行类金融场景下按需开机器、部署交付即可，但需要思考成本与交付的平衡。 当前的痛点是：研发强调业务重要，要求独立资源。我们目前采用物理机部署，对于业务压力并不高的“核心”业务，只能给三副本 5TB 存储，造成资源浪费。同时，多条业务线部署在同一组物理机上，某个业务线的慢查询接口可能影响其他业务。 OceanBase 的多租户能力可以解决这一问题。 **· 告别物理机孤岛：**打破传统架构按“峰值”预占硬件的痛点，实现资源池化管理。按需动态分配 CPU/内存，彻底消除物理机闲置造成的成本浪费。 **· 租户级物理硬隔离：**通过底层的 CPU 绑核与 IOPS 阈值控制，实现租户间的物理级硬隔离。确保营销等高 I/O 业务突发打满时，核心交易链路绝对不受“噪音效应”干扰。 **· 分钟级动态扩缩容：**以 Unit 为最小迁移单位，实现业务零感知的在线扩容与缩容。轻松应对跨地域、多时区的突发业务洪峰与节假日高并发。 ![OceanBase 统一资源池](https://mdn.alipayobjects.com/huamei_22khvb/afts/img/A*AY3zT6YBgFQAAAAAQkAAAAgAeiGDAQ/original) 使用 OceanBase 后，整体资源利用率提升 40%，新业务节点部署周期缩短 90%。此外，对于如何避免资源浪费问题，我们在早期采购机器时得到一个经验：CPU 核数买得太少，存储配置较大，导致 CPU 资源用完后仍剩余大量存储空间。建议采购时选择高 CPU 规格（如 96C），与内存配比大约 1:2。迁移单位，实现业务零感知的在线扩容与缩容。轻松应对跨地域、多时区的突发业务洪峰与节假日高并发。 ### 自动化运维与生态打通 将新数据库纳入既有运维体系是一个常见问题。信也科技数据库种类较多，包括 MySQL、Redis、OceanBase、Elasticsearch 等多种关系型和非关系型数据库。我们有一套面向研发和 DBA 的管理平台，已将 OceanBase 的自动化流程纳入其中。 在 SQL 变更方面，我们采用双重验证机制：通过 OCP 平台和内部工具进行交叉验证，确认无误后直接执行；如有风险则走工单审批流程。但工单执行也存在问题——大表改表操作耗时非常长，业务方能否等待是一个问题，同时改表过程中本身存在锁开销等风险。 我们的做法是安排在每天 21 点执行，如果到早上窗口期结束仍未完成，则进行抑制操作，暂停 DDL 避免影响业务。 在开发平台方面，我们参考了阿里云的建表体验，将开发规范内置到平台中，研发人员无需关心索引、表备注、字符集等规范细节，只需填写表名、备注和字段类型，提交后平台自动处理。 ![变更防御矩阵：日常运维自动化闭环](https://mdn.alipayobjects.com/huamei_22khvb/afts/img/A*CvMiQb4B8B4AAAAAQzAAAAgAeiGDAQ/original) 一个重要的经验教训是：早期未配置 OBProxy 时，在大数据抽数场景中，复杂查询任务直连主租户 (Primary Tenant)。凌晨抽数高峰期引发大面积全表扫描，导致主库 CPU 飙升、I/O 触及瓶颈，严重威胁核心交易链路安全。后来我们将所有离线抽数、报表分析流量无缝引流至备租户 (Standby Tenant)，彻底实现底层读写分离，物理隔离 OLAP 与 OLTP，主库性能稳如磐石。 ## 未来规划：探索一体化向量底座与全自动运维 我们在 2024 年开始使用 OceanBase，从特定场景到核心业务依次上线，基于其在这两年的稳定表现，我们计划持续扩大 OceanBase 的使用范围。例如，将部分其他数据库支持的业务场景切换到 OceanBase，以降低数据库成本。 未来，我们还将基于 OceanBase 优化 AIOps、重塑归档体系、演进一体化向量底座。 ### 从手工救火到 AIOps 智能自愈体系的蜕变 如何将 OceanBase 与自动化运维体系及 AIOps 深度结合，实现数据库问题的自动判断甚至自愈？这是我们要解决的问题。 目前已有巡检系统，可以检测隐患与风险，但治理工作仍依赖 DBA 人工处理。未来，我们希望实现：巡检发现问题后自动治理，以及报警触发后自动分析并给出执行路径，经 DBA 确认后即可执行。这对缩短故障处理时间、提升 MTTR（平均修复时间）指标至关重要，对 DBA 完成 SLA（如9999或99999）的考核也有直接帮助。 为此，我们将通过三方面构建全链路治理体系。 **· 防线左移：**前置 AI 质量拦截。自动化 SQL Review 平台引入 AI 辅助代码审核，在研发流水线中精准识别并提前掐断易引发“全表扫描”的劣质计划。 **· 极速响应：**智能 RCA 与自动止血。打破传统堆砌告警模式，构建基于监控日志的智能根因分析 (RCA)。实现“诊断->止血”联动，将人工排查时间从分钟级压缩至秒级。 **· 底盘稳固：**演练与黑屏 SOP。沉淀极端场景下的应急经验，针对复杂故障强化团队黑屏排雷与实操能力，知其然更知其所以然。 与此同时，探索基于大语言模型 Agent 的数据库常态化巡检，结合历史负载特征，实现数据库底层参数的动态自适应调优。逐步落地智能化故障自愈机制，从“被动响应”向“主动防御”演进，极大降低业务连续性对人工经验的依赖。 ### 重塑归档体系：从底座演进到全链路自动化治理 冷热数据分离是线上频繁使用的场景，数据分离后仍需保留以满足审计或业务需求。以往，我们的做法非常笨拙：通过 rename 方式定期清理过期数据并重建新表。 使用 OceanBase 后可以按分区进行添加和删除，操作非常丝滑。还可以按时间要求定时执行归档，支持不同租户或实例串行归档，也提供并发数和优先级支持。考虑到我们在东南亚（菲律宾、印尼）、澳洲、非洲等地区都有业务，OceanBase 还支持归档时配置不同存储介质，满足当地数据驻留的合规要求。 此外，OceanBase 彻底统一在线交易与历史归档技术栈，自动化维护分区全生命周期，带来了海量历史数据存储成本骤降 70%、主租户核心库查询性能跃升 30% 的效果。 ### AI Native：一体化向量底座与业务展望 如今，信也内部推动“All in AI”，DBA 团队的相关后台系统已 100% 使用 AI 编写，AI 平台和开发团队将向量数据库作为存储底座。 在 AI 趋势与业务需求的双重压力下，我们计划探索将 OceanBase 作为一体化向量底座的效果，比如在海量数据场景下使用，以及在智能风控场景使用 OceanBase 的向量相似度匹配，精准捕捉跨业务线的隐秘欺诈团伙，提升风控模型的召回率与时效性。 OceanBase 向量功能迭代迅速，推出 SQL + 向量一体化检索架构，无需异构同步，确保数据实时强一致与金融级可靠性。如今已支持 HNSW、IVFFlat 等主流索引，可承载 16000 维超高维检索，满足大模型长文境需求。据官方透露，后续版本的向量能力将有更大提升。 对于我们来说，**OceanBase 最大的优势在于一个数据库同时处理关系型、KV 及向量数据，极大降低 AI 原生应用的开发与运维复杂度。** AI 大势所趋，对 DBA 提出了新的技能要求。在交流时，了解到他们通过海量故障数据构建知识库并存储在向量数据库中，当故障发生时通过向量搜索匹配标准 SOP，再分发给相应人员处理。 所以我们将构建基于 RAG 的运维知识库，实现故障特征的秒级检索与自动化处置。同时，依托 OceanBase 的一体化底座简化技术栈，降低 AI 落地门槛，实现从“数据治理”向“AI 资产赋能”的跨越。 ![信也科技](https://mdn.alipayobjects.com/huamei_22khvb/afts/img/A*xyUXQ6KeJvcAAAAAQCAAAAgAeiGDAQ/original) 信也科技成立于2007年，是领先的金融科技集团，力图通过大数据、人工智能等技术实现“科技，让金融更美好”的使命。 作为中国信贷科技的初代探索者，信也科技已在金融机构科技服务和消费金融便利化领域占据行业领先地位。集团围绕信贷科技、国际化业务以及科技生态孵化三大板块，以创新科技赋能机构，持续服务合作伙伴，助力实体经济高质量发展。 信也科技已于2017年在美国纽交所上市。 [ 行 业 ] [其他行业](https://www.oceanbase.com/customer/home?industry=other&floor=more) [ 应用场景 ] [全场景业务系统 OLTP 解决方案](https://www.oceanbase.com/solution/oltp) ### 目录 - [历史架构痛点：传统 MySQL 分库分表的技术挑战](#jishutiaozhan) - [分布式数据库选型历程](#xuanxing) - [如何推动研发团队用 OceanBase](#tuidongyanfa) - [实战破局：从核心业务场景落地到自动化运维](#shizhanpoju) - [未来规划：探索一体化向量底座与全自动运维](#guihua) 获取同款解决方案 [立即咨询]()