在金融数智化转型加速推进的当下，头部银行的技术实践正成为行业最具价值的参考样本。为此，权威媒体《金融电子化》聚焦万亿级银行核心系统升级这一重要议题，持续推出系列专访，深入探访这些银行的技术决策与落地实践。

日前，《金融电子化》记者专访江西农商联合银行金融科技部总经理付攀，围绕分布式数据库在ECIF、业务中台、统一支付、现金管理等核心系统的规模化落地，深入探讨其体系化选型逻辑、整体架构设计、工程难点与风险防控、业务价值兑现，以及面向AI时代的演进规划。

全文 7350 字，阅读约需 8 分钟。

在金融业全面推进国产升级与数字化转型的关键时期，省级农商联合银行如何把握“业务价值驱动”与“安全合规前置”的平衡，构建面向零售业务潮汐波动、多法人异构共存、联机批量混合负载等多重业态的分布式数据底座，已成为业内关注的焦点。

江西农商联合银行于近期完成改制后，正式进入全行统一运营、零售业务集约化发展的新阶段。

在接受《金融电子化》杂志记者郑岩采访时，该行金融科技部总经理付攀分享了江西农商联合银行的思考与实践。

问答实录

Q1

贵行将 OceanBase 分布式数据库规模化应用于 ECIF、业务中台、统一支付、现金管理等全行重要系统，并未走多数机构以信创合规为单一驱动的改造路径，而是更多基于零售业务高并发、云平台生态适配和存量异构升级等实际业务痛点。请问贵行的整体选型逻辑是什么？

付攀：我们把数据库升级看作一项关系到业务发展、运营韧性和自主可控能力的系统工程，而不只是一次产品切换。

选型坚持“业务价值牵引、安全合规前置、技术适配验证、全生命周期评价”，既回应零售业务增长的现实需求，也为全省农商银行数字化转型夯实可持续演进的基础。

一是从业务出发，而不是从产品参数出发。

围绕零售业务峰谷波动、高并发短事务、重要系统持续扩容等需求，重点考察数据库在真实交易模型下的吞吐、时延、稳定性和扩展能力。分布式架构是否适用，最终要由业务场景和验证结果来回答。

二是从整体架构出发，而不是孤立选择数据库。

在选型时，我们重点考量了 OceanBase 与我行私有云百福云的兼容性与适配性，选型既关注数据库自身能力，也关注其与既有云平台及运维体系的适配，减少重复建设和多套技术体系并存带来的管理复杂度。通过兼容性测试、容量规划和运维协作，将产品能力转化为云与数据库协同运行的体系优势。

三是从升级可行性和长期运营能力出发。

OceanBase 兼容两大传统集中式数据库，便于分类承接存量应用，但兼容不等于无需改造。我们综合考虑 SQL 与数据类型差异、迁移工具支持范围、应用改造工作量，以及后续许可、基础设施、运维和人员培养成本，避免只算采购成本、不算转型成本。

四是把自主掌控落实为可验证的能力。

既看产品高可用和一致性机制，也看银行能否掌握架构设计、问题诊断、数据恢复和应急处置能力。自主掌控不只是选择产品，更要将关键技术能力和运行责任掌握在自己手中。

基于这一逻辑，我行以 OceanBase 承载适宜的分布式重要业务场景，结合其他产品，分类适配，不追求一种数据库包办所有需求。

Q2

省级农商联合银行兼具零售业务潮汐波动、多法人存量异构、联机与批量混合负载等典型业态。在场景实践中，OceanBase 的哪些特性得到了验证？

付攀：省级农商机构的特点，是既要发挥平台集约化优势，又要兼顾辖内农商银行的法人边界和差异化经营。我们的思路不是简单让业务适应数据库，而是把技术能力转化为有规则、有边界的服务能力。

• 对于零售业务潮汐波动，发挥分布式扩展和租户资源调整能力，同时将其纳入容量预测、峰值压测、资源预留和变更管理。特别是在私有云环境中，弹性仍受可用物理资源、数据均衡及应用连接方式等条件约束，不能把“可扩展”理解为无限、即时、无影响地扩容。

• 对于多法人、多系统并存，按法人数据边界、业务重要性和运行风险设计租户及资源布局，结合资源配额、访问控制、审计和必要的独立部署，控制相互影响。多租户能够提升集约化水平，但技术隔离不能替代权责梳理、数据授权和管理责任。

• 对于联机与批量并存，首先区分事务型批量和分析型负载。计息、归集等批量作业仍涉及事务一致性、锁冲突和业务顺序，通过任务拆分、并行度控制、错峰调度及 SQL 优化保障交易优先；适宜的查询分析场景，再结合已部署版本能力评估 HTAP。我们的原则是用负载实测决定混合承载还是分离部署，而不是为了采用某项特性而增加重要业务风险。

Q3

ECIF、业务中台、统一支付、现金管理四类系统在业务属性、交易模型和数据体量上差异显著。贵行同步推进多类关键系统的分布式改造，在整体技术架构上如何统一规划租户资源，实现业务隔离与弹性调度的平衡？

付攀：我们坚持“统一规划、分类承载、分域隔离、按需供给”。统一的是技术标准、管理规则和运维能力，不是把所有系统放进同一个集群，更不是抹平不同业务和法人的边界。

在资源布局上

根据 ECIF、业务中台、统一支付、现金管理等系统的业务等级、交易特征和容量需求，分别规划租户与资源。对重要交易业务优先保障资源，对可以集约承载的负载设置资源配额和容量边界；隔离要求更高的场景，采用独立资源或独立集群，控制单一故障的影响范围。

在调度机制上

我们进一步完善了资源申请、容量评估、扩缩容审批、上线验证和使用复盘的衔接机制。租户级 CPU、内存和 I/O 等资源控制有助于降低相互干扰，共享底层设施则需要持续监测和压力验证。弹性调整必须服从业务优先级和变更纪律，在保障业务稳定的前提下提升资源使用效率。

在平台运营上

依托 OCP 等工具开展多集群监控、告警和运维管理，并与备份恢复、变更管理、应急处置流程衔接。我们更看重的是把工具能力沉淀为可复制的服务标准，让每套系统的容量、责任人、保障等级和应急路径都清晰可查。

Q4

四类系统在业务连续性要求和风险等级上各不相同。贵行分别采取了哪些差异化的升级部署与适配的方案？

付攀：多系统并行推进，不能采用同一套参数、同一种切换节奏。我们的做法是统一工程规范和验收要求，再根据各系统的关键业务风险设计差异化方案。

ECIF 的重点是客户信息完整性与主数据一致性。

通过大表分区、索引优化和符合留存要求的历史数据管理改善访问效率；升级除了校验和字段外，还应重点核验客户标识、关联关系及上下游接口结果，防止“数据搬过去了，客户关系却对不上”。

业务中台的重点是能力中心间的依赖关系。

围绕营销、合约、产品等模块梳理接口和交易链路，分模块适配、分批验证、按条件切换，并关注跨中心调用、异常补偿和接口兼容，避免局部改造影响整体服务。

统一支付的重点是交易正确性与峰值韧性。

围绕高并发短事务、热点账户更新和高频写入开展针对性优化，同时把幂等控制、超时重试、重复交易防范和对账纳入联合验证。数据库事务一致性是基础，但支付正确性还需要应用、数据库和业务控制共同保障。

现金管理的重点是联机服务与日终作业协同。

结合银企直连、资金归集、计息和对账的不同特征，优化任务依赖、分批策略、SQL 和并行度，控制批量作业对联机交易的影响，并以业务处理窗口和对账结果作为重要验收依据。

贯穿各系统的管理要求，是将技术验证与业务验收结合起来：既验证性能和稳定性，也验证业务结果；既验证正常路径，也验证异常处理。多系统并行建设不等于同时割接，投产节奏必须由准备成熟度和风险评估决定。

Q5

省级农商机构普遍存在存量系统老旧、数据标准杂乱、多法人历史业务复杂、业务零中断要求高等痛点，多系统同步改造的风险更为集中。在向 OceanBase 升级的过程中，贵行重点攻克了哪些工程难题？特别是在数据切换、应用适配、批量处理和新旧系统并行方面，有哪些关键挑战与应对经验？

付攀：最难的不是把数据从一个数据库搬到另一个数据库，而是在复杂存量环境下，把数据、应用、业务和投产组织一并切换好。

我们重点解决四类问题：

一是数据切换的完整性和一致性。针对存量数据库，利用 OMA、OMS 等工具开展评估和切换，并根据源库、目标兼容模式及版本确认支持范围。在全量切换、增量追平和技术校验之外，结合关键业务要素、账务结果及系统间对账，形成技术校验与业务验收相结合的质量要求。

二是应用从“能运行”到“运行好”的适配。除语法和数据类型差异外，重点处理事务边界、隔离级别、热点访问、大事务和分区设计等问题，将适配规范、SQL 审核、回归测试和容量压测贯穿开发到投产全过程，避免兼容模式掩盖潜在的架构问题。

三是批量作业效率与业务正确性的平衡。对计息、归集、客户标签更新等作业分别识别瓶颈，通过合理分区、并行计算和任务编排提升效率，同时验证作业顺序、可重入性和失败重跑机制。跑得更快，不能以打乱业务依赖或重复处理为代价。

四是新旧系统切换期间的状态一致。根据系统条件采用分批升级、灰度验证和受控并行，明确最终增量追平、写入权切换、业务验证及回退判定。对于涉及双写的方案，要额外解决幂等、冲突和对账问题，不能将双写作为所有系统的默认路径。回切也必须具备数据回流、差异处理和演练验证等条件，不能理解为简单切回连接地址。

我们坚持将业务连续性作为硬约束，通过风险识别、全过程验证和有准备的应急处置，尽可能降低升级对客户服务的影响，让每一次切换都有依据、有把握、有保障。

Q6

在快速推进业务迭代与分布式改造的同时，贵行如何构建覆盖全生命周期的运维保障机制，持续守住金融业务稳定运行的底线？

付攀：稳定运行不能只靠运维人员兜底，而要靠覆盖全生命周期的责任体系。我们在变更、监控、演练和复盘机制基础上，进一步强调“责任到人、关口前移、协同处置、能力沉淀”。

一是把风险控制前移到需求、设计和准入。数据库变更、切换割接和参数调整，落实方案评审、风险评估、回退预案与双人复核。重要变更应将业务验证、上下游依赖和应急资源准备纳入放行条件，明确谁提出、谁审核、谁操作、谁验收。

二是以业务服务水平牵引运行保障。除集群负载、事务时延、慢 SQL 等技术指标外，还要关联交易成功率、服务响应和批量完成情况，形成从基础设施到应用、再到业务的观察链路。恢复时间目标和恢复点目标应按系统重要性分类确定，并通过端到端演练验证，不能只看数据库组件的切换速度。

三是把演练和复盘转化为组织改进。常态化开展故障切换、备份恢复和容量压测，对发现的问题明确责任、整改期限和复测要求，以实际恢复结果检验备份质量，以演练效果检验预案的可执行性。

四是把人才培养嵌入项目和日常运营。我们强调业务、开发、测试、运维与安全人员共同参与。下一步，将围绕真实升级、故障诊断和恢复演练加强骨干培养，推动厂商经验向行内规范、知识库和实战能力转化，并强化关键岗位梯队建设，降低对单一人员和外部支持的依赖，让平台能力真正沉淀为银行自身的能力。

Q7

OceanBase 的落地，不仅完成了技术升级，更重塑了零售业务的数据支撑能力。请您谈谈，统一数据底座建成后，对全行客户统一视图构建、多渠道合约管控、统一支付高频交易承载、现金管理银企场景融合等方面带来了哪些实质性提升？

付攀：评价数据库升级，不能只看设备替换和技术指标，更要看是否增强客户服务连续性、业务协同效率和产品创新能力。这次建设的价值，是为客户、合约、支付和现金管理等共性业务能力提供了更可靠、可扩展的数据承载。

• 在客户统一视图方面，ECIF 的稳定存储和高效访问为跨渠道识别客户、共享客户信息提供基础。真正形成统一视图，还需要客户标识、主数据标准、数据质量和授权规则共同发挥作用，不能把数据库集中部署等同于客户数据已经统一。

• 在多渠道合约管控方面，底座支撑合约信息的集中管理、状态更新和查询调用，配合上层合约中心的规则统一和应用同步机制，向渠道输出一致的服务能力，减少因信息不同步带来的业务衔接问题。

• 在支付方面，通过事务处理、容量扩展和针对性优化增强峰值承载能力，为支付高峰期的服务连续性提供支撑。最终效果应落实到交易成功率、响应时间和差错处理等客户可感知、业务可检验的指标上，而不只体现为数据库测试成绩。

• 在现金管理方面，增强银企联机服务与批量作业的协同承载能力，为账户查询、资金归集、计息和对账等服务提供稳定支撑，使上层系统能够更从容地响应企业资金管理需求。

• 从管理价值看，共性底座和标准化运维有助于减少重复建设，将更多科技资源投入业务创新。我们希望把性能、稳定性、资源投入和业务成效纳入同一评价框架，持续检验技术投入是否转化为服务“三农”、小微企业和县域经济的实际能力。

Q8

从数据治理角度看，统一数据底座如何助力全行零售业务精细化运营与数字化中台能力沉淀？

付攀：数据库建设与数据治理相互支撑，但不能相互替代。统一技术底座解决的是数据能否稳定承载、高效访问的问题；精细化运营还要解决数据是否准确、定义是否一致、责任是否清晰、使用是否合规的问题。

首先是把数据责任落实到业务。客户、账户、产品、合约等关键数据，应明确业务归口、管理责任和质量要求，科技部门负责提供技术实现与控制手段，避免出现“数据归技术管、问题却无人负责”的脱节。

其次是把标准和质量控制嵌入流程。推动统一客户标识、关键指标口径和数据模型，关注从源头采集、业务处理到下游使用的完整链路。对缺失、重复、关联异常等质量问题，形成发现、认领、整改和复核的闭环，而不是只在报表环节补救。

再次是把数据共享做成受控的服务。结合元数据、数据血缘、分类分级和授权管理，在法人边界与合规要求下形成可复用的数据服务，减少不同应用重复取数、重复加工和口径分歧。

对于零售经营，还应建立应用效果反馈机制，把客户服务、产品适配和风险识别的实际效果反馈到数据质量与服务改进中。我们希望通过“业务定规则、科技建能力、使用促改进”的协同，让数据中台沉淀的不只是技术组件，更是可复用的经营能力和清晰的数据责任。

Q9

贵行已完成农商联合银行改制，进入全行统一运营、零售业务集约化发展的新阶段。基于当前 OceanBase 在零售系统与业务中台的落地成效，贵行未来在数据库架构迭代、全域业务分布式升级和国产升级运维体系建设上有哪些整体规划？

付攀：改制为联合银行后，我们更加注重发挥省级平台的科技服务和集约化支撑作用，同时尊重辖内农商银行的法人治理、数据权责和差异化需求。未来不是简单追求系统切换数量，而是形成架构可演进、风险可控制、服务可衡量、人才可接续的长效能力。

一是完善分类分层的架构路线。结合系统重要性、负载特征和改造收益，持续优化租户与集群布局，对单元化部署、交易与分析分离、混合负载承载等方案开展场景化验证。不把分布式化本身作为目的，也不以单一技术路线覆盖所有业务。

二是按成熟度稳步推进关键领域改造。在已有实践基础上，评估向新一代核心、信贷、新一代 CRM 等领域拓展的可行性，明确依赖条件、验证标准和投产门槛，坚持分阶段实施、分系统验收，避免为赶进度积累运行风险。

三是推动国产升级运维从工具建设走向服务运营。完善覆盖基础设施、数据库、中间件和应用的全链路管理，加强全栈国产升级环境的兼容适配、版本协同、自动化运维与自主保障能力，持续做好容量、变更、备份恢复和供应商协同管理，并以服务水平、恢复验证和全生命周期成本检验运行质量。

四是同步建设自主运维与复合人才体系。通过项目实战、联合攻关、岗位轮训和应急演练，培养既理解数据库架构、又理解金融业务和风险控制的骨干，把升级规范、诊断方法和应急经验沉淀为组织资产。数据库建设不能只交付一套系统，还要交付一支能够持续运营和演进系统的队伍。

Q10

当前，银行 AI 应用正从单点探索逐步走向体系化落地，数据底座也不再仅仅是支撑交易处理。您认为下一代 AI 数据底座应具备哪些核心能力？

付攀：AI 时代的数据底座不能简单理解为“数据库+大模型”，而应是数据、算力、平台和治理能力协同构成的体系。既要守住金融交易的确定性和安全底线，也要为智能化应用提供高质量数据、适配的计算资源和可持续的运营机制。

在这方面，江西农商联合银行已经依托百福云平台，实现了通用算力与智能算力的双重纳管。这一步的意义，不只是增加一类计算资源，更是为传统业务与 AI 应用在统一平台框架下的协同规划、分类管理和持续演进建立基础。

这一布局着眼于 AI 规模化应用的长期需求：通过统一平台减少普算与智算的管理割裂，增强资源可视性，为减少重复建设、优化资源投入和明确运营责任提供基础，使智能化建设能够复用既有云平台的管理经验，而不必另起一套相互脱节的治理体系。

在这一基础上，我们将坚持统一平台与分域保障相结合，重点完善五方面能力：

一是高质量、可追溯的数据供给能力。把客户、账户、交易等结构化数据与经授权使用的文档、知识资料纳入相应的治理流程，明确来源、版本、质量和使用边界，通过标准化服务支撑特征加工、知识检索与模型调用。AI 需要的不只是更多数据，更是准确、适用、可解释来源的数据。

二是普算与智算协同的资源治理能力。在双重纳管基础上，进一步完善资源目录、配额、交付、监测和成本评价机制，使数据加工、模型训练和在线推理获得与负载特征相匹配的资源。对重要交易和 AI 任务实行分级保障、分域隔离；对共享环境难以满足保障要求的场景，采用独立资源或集群，不以提高资源利用率为由牺牲交易稳定性。

三是适配不同场景的数据服务能力。根据需求组合事务数据库、分析平台、对象存储及向量检索等能力，而不是要求单一数据库包办全部任务。HTAP 可以服务适宜的近实时分析，但模型训练和推理仍需配套计算与模型服务体系，不能将数据库扩容等同于 AI 算力扩容。

四是贯穿数据与模型生命周期的安全治理能力。私有云部署提供了受控环境，但不天然等于合规。还要落实分类分级、最小权限、脱敏、加密与审计，关注知识检索越权、敏感信息泄露、模型输出不准确等风险。对涉及客户权益和关键业务决策的场景，坚持必要的人工复核与责任约束。

五是以业务价值为导向的持续运营能力。下一步应优先选择边界清晰、价值可衡量、风险可控制的场景，将效果评估、版本变更、运行监测和退出机制纳入闭环，同步培养懂业务、懂数据、懂模型治理的复合型人才。

我们的目标是依托百福云推进“统一纳管、分域保障、协同演进”，把算力资源转化为可持续的服务能力，让 AI 创新既有可用的基础，又有可控的边界，更有服务实体经济的实际成效。

活动预告

金融 × AI，会碰撞出什么火花？11 月 2—3 日OceanBase 亮相香港金融展！展示从分布式数据库迈向 AI 数据平台的新进阶想体验企业级 AI 数据分析？来现场，上手 OceanBase DataPilot一起解锁金融 AI 新可能！📍香港湾仔·香港会议展览中心 5 楼📌展位：5E-TA05现场见，等你来打卡！

立即试用 OceanBase 企业版，体验国产数据库能力 立即试用 OceanBase 企业版，体验国产数据库能力