专访｜YashanDB 王义寅：如何体系化构建国产数据库服务生态

导读

针对数据库运维服务的价值以及当前国内数据库服务所面临的挑战与机遇，墨天轮专访了崖山数据库服务与生态总监王义寅，聊一聊YashanDB服务的理念、价值及生态架构，以及他对行业的观点与见解。

人物介绍

王义寅，深圳计算科学研究院核心骨干、YashanDB团队创始人之一、崖山科技公司副总裁、服务与生态总监。曾就职三大运营商、四大行、ICT巨头，二十多年行业从业经验，获多项中美技术专利。

以下为采访全文

Q：首先请您给大家介绍下YashanDB服务团队的组建理念、人员构成，以及YashanDB的服务体系架构，如何实现7*24小时快速响应、全国4小时到达现场的服务能力？

王义寅：服务是数据库厂商的核心竞争力，我们始终以用户为中心，在用户服务能力的构筑上投入了大量的精力和时间。2019年产品还未正式发布前便开始着手专业服务团队的组建工作，从2022年下半年开始正式运转，并构建了标准流程与专业工具体系，目的是让服务能力尽可能固化专业化和可复制规模化。

具体到服务形式，YashanDB提供远程和驻场两类服务。远程服务方面，提供官方400售后技术支持电话、微信群等渠道，确保7*24小时问题快速响应服务。随着客户群体从深圳逐步扩展至全国各地，包括华东、华北等地区。对于现场响应，我们采取两种方式：一是针对紧急情况，快速派遣专业人员前往处理；二是积极寻找全国范围内的服务伙伴，与全国各地的服务伙伴建立深度合作关系，并建立本地的办事处，配备当地服务渠道的骨干人员，共同打造一个全国性的服务网络是YashanDB从1走向100的关键。

目前，我们对合作伙伴体系、培训认证体系、内部文档、沟通渠道以及原厂服务支撑的SLA要求已经做出了清晰的界定，一旦项目启动，就可以迅速调动资源快速响应。

Q：目前YashanDB服务团队的客户主要分布在哪些行业？客户都有哪些严苛要求？服务过程中遇到了哪些的挑战、是如何应对的？

王义寅：目前公司服务的客户主要集中在政务、能源、金融、交通等行业。公司的核心定位是针对核心业务的关系型事务场景的国产化“平替”（软硬件1比1替换）、面向7*24小时在线系统场景提供保障服务并体现优势。这在金融行业表现尤为明显，金融行业对服务能力的要求非常严苛，通常要求业务上线切割时间窗口在秒级到分钟级、系统7*24小时持续可用、业务并发量达到百万级。

目前看来，服务过程中最具挑战的是迁移阶段，我们碰到了TB级数据量、数万个对象、上十万行存储过程的迁移，但服务实施的过程都超过了甲方的预期。以某家金融客户为例，其对数据迁移的数据和元数据迁移校验过程的初始预期将近24个小时，但在使用自研的崖山迁移工具（YMP，Yashan Migration Platform）后，3TB的数据迁移加验证实际只耗费了四、五个小时。

上线过程紧张，但功夫需要花在准备上，对核心业务来说，上线后SQL性能问题是非常关键风险，然而无法获取真实数据导致很难确保上线SQL性能达到预期。YashanDB服务团队能够基于统计信息和元数据，进行符合分布特征的快速规模造数，可以在测试阶段进行SQL性能持续优化，将风险降至最低。

此外，客户通常期望切换过程能够在秒级完成。面对这样的挑战，我们提供异构数据库间在线增量同步的方案，并在切换前期进行各种压力测试以确保系统的性能和稳定性。

Q：YashanDB服务团队在确保系统顺利上线方面采取了哪些措施？

王义寅：项目启动时，服务团队的方案咨询组将配合客户在不同场景下交付计划和方案，会根据存量系统、在研系统、升级系统等不同场景提供针对性的方案设定和验证。

客户确认项目系统可上线后，服务团队会立即着手了解目标系统的具体需求以及存储部署的环境要求等等。例如，对于监控健康检查，并非等到系统上线后才开展，而是持续进行监控和巡检，确保生产环境的执行计划保持较高的质量水平，避免系统变更对业务SQL性能可能产生冲击。

Q：未来有怎样的服务伙伴计划？

王义寅：针对服务伙伴计划会从两方面准备，一是对于我们的原厂服务体系和团队，需要具备能兜底的能力；二是对于渠道伙伴，最终的目标是80%的客户都能由渠道伙伴完成实时交付和后期的上线保障工作。尤其是驻场类服务，希望渠道伙伴承担更多也收获更多。

客户服务的过程中，其实需要投入大量的时间与客户沟通、陪伴。渠道合作伙伴通常会为多款数据库或其他产品提供运维服务，这时需要一个团队常驻现场。在这种情况下，他们在客户现场产生的综合效益比原厂单一数据库服务的效益更高，客户也愿意为此付出相应的费用。

当然，在面对极其关键的场景和客户时，原厂和合作伙伴会共同加入进来，发挥双方的优势，更好地服务我们的客户。

Q：YashanDB服务团队应对故障的处理流程是怎样的？会出现客户现场中有定制化版本的情况吗？以及这些修复的BUG补丁如何同步到其他客户？

王义寅：针对产品使用问题制定标准化流程。YashanDB的服务体系中始终坚持的原则是洞察客户的需求，做到专人管理，流程规范，多岗协同，为用户提供专业化高水准的服务。

上线前阶段，通过充分验证提前发现问题，若遇到紧急问题会由服务和研发组成的专项工作组找到解决方案，并提供已进行充分验证的修复版本，时间上更是有严格要求：必须在24小时内将问题规避过去，并在一周内将问题彻底解决并发布补丁；上线后阶段，第一周通常会进行重保，每日都会对系统进行监控、健康检查和运行稳定性等充分调研和保障；一周后持续会进行原厂监控、健康检查。

其次，我们建立了完善的客户系统和版本记录表，并由专人维护。当发现BUG时，我们会根据这个维护表找到受影响的所有系统，并通知对应的服务人员与客户沟通规划上线计划，通常在客户并未触发的情况下就能将BUG修复。

最后，为了确保所有问题得到及时处理和解决，我们设立了专人管理问题单，并全程监控问题解决过程和结果，并将结果与影响反馈给所有客户。

Q：前段时间个人版对外发布，若用户使用过程中遇到问题如何才能对接到原厂专家？有哪些资源和渠道可以供个人学习和交流？

王义寅：YashanDB个人版的公开发布具有重要意义。个人版和服务都可以作为与外部沟通的重要渠道，通过个人版的正式开放，服务团队可以与更多用户进行更密切的沟通，深入了解用户需求和收集产品反馈，有助于形成良好的正向机制，推动产品的成熟和完善。

为积极响应用户的需求，我们创建了沟通群，方便实时解答用户提出的使用问题。若想与专家建立联系，往往可以通过一些线下活动进行。官网提供官方产品文档、FAQ、学习视频，公众号和B站不定期更新技术文章与视频，欢迎大家学习和交流。

当前我们对个人版的定位主要是开放产品体验，且以用户兴趣爱好为主。企业若想与服务团队的建立服务体系SLA等密切联系，还是推荐使用企业级版本。

Q：我们知道YashanDB高度兼容Oracle，请问可以做到直接改应用的连接字符串就直接运用吗？另外在做Oracle迁移到YashanDB最大的几个挑战是什么？是如何解决的？

王义寅：在YashanDB产品设计之初便对深度兼容提出了高要求，从存储引擎等内核模块到产品化特性的检测项、监控项等都预留了兼容性方面的设计方案，从第一行代码开始就瞄准了Oracle全面兼容的目标，未来我们还会做MySQL的高度兼容。

早期我们曾尝试和一些外部软件做适配，直接将Oracle的JDBC换成我们的JDBC驱动，跑得还不错，这让我很是惊喜。从企业级角度考虑，兼容性是牵引我们产品逐渐走向成熟的试金石，我们内部也的确对此提出了非常高的要求，尤其是关注客户使用场景中的细节。然而Oracle经过几十年的打磨出现了如此的多特性，做到全部兼容是不太现实的。我们认为，当前YashanDB针对零修改迁移Oracle 数据库50%常用的核心功能是已经完成的，这能覆盖80%到90%的场景。

为了解决迁移可能出现的问题，我们开发了一个迁移工具（YMP），它可以精确评估数据类型、存储过程等方面与Oracle的不兼容项。评估结果出来后，若是较为简单的不兼容情况，则会尝试通过简单的改写解决问题。如果体验不好，便会针对问题在一周之内开发相应的功能进行补充，这其实得益于我们完全自研的优势。客户在做迁移的时候，通过工具生成的报告会直观展示是否能够百分之百迁移过去，其次是帮助团队在识别YashanDB在兼容性上与Oracle的差距。

现阶段YashanDB在内置的复杂监控指标、系统包、高级包等方面跟Oracle还有一些差距。但为此我们开发了PLSQL开发工具，提供了PLSQL debugger工具，通过Dbeaver工具能够让我们的生态伙伴自己就完成常用的高级包开发与使用。

实际上，从Oracle数据对象简单迁移到YashanDB并不难，但我们的目标是迁移之后性能不能变差。由于两种数据库存在很大差别，比如优化器的实现机制是不同的，如何才能做到每一个SQL执行下来都没有差别呢？这是我们的挑战，这就要求我们通过持续积累优化器能力和最佳实践去解决。我们最终的目标是能覆盖Oracle 70%到80%的主要功能，让客户几乎在99.9%的场景中都可以直接、放心地迁移。

Q：YashanDB会跟Oracle一样出现物理坏块、系统文件损坏、掉电无法启动的情况吗？如何避免这种情况发生？如果发生如何在短时间内恢复？

王义寅：任何软件系统都无法避免这种场景的出现，因为按照电子电路的基本物理属性，出现物理损伤的场景是常见的，软件需要的是在这种情况下提供修复能力。

YashanDB已开放多种功能，如涉及稳定性方面，我们具备坏块检测与修复能力，通过技术手段自行解决关键问题。同时，也支持生成相应的日志，这对于运维人员来说极为重要。此外，针对人为操作失误等情况，我们也提供Flashback闪回特性。

Q：Oracle为DBA开放了非常多的开关和手段，比如参数、Event、Hint、SQL Profile、oradebug等，直接在线解决生产中绝大多数的故障和需求。而据说国产数据库DBA除了重启能做的事情很少，多数故障要升级到研发改代码。请问YashanDB是这样的吗？

王义寅：目前YashanDB在内核中预留了大量的Event类型来对应参数调优的识别手段，后续也会根据业务场景的需要，将这些场景的功能逐步做多做全。目前，在数据库内核调优参数方面内置了大量的对缓存、存储、优化器等行为调优的参数，未来将会随着产品的版本迭代逐步对外开放。

此外，YashanDB中很多的系统参数可以不用启停Instance就可以做到。YashanDB支持Hint，可以很精准地定位算子，做指定的行为；可以Trace会话里的SQL执行情况，看某一个时段里的Top SQL；也提供了非常多的监控运维视图，例如查看Index、Trigger/Sequence的状态是否有效；另外统计信息能够自动收集更新，也可以手动地指定不同对象按不同的要求去采集，为CBO优化器提供可靠的统计信息。

对于DBA来说，很多时候需要进行非常精准的手术式故障定位和性能判断，这其实需要更加丰富的工具。为了解决这个问题，我们提供了一套完整的健康检查YHC和故障信息收集工具YTC，以及类似AIX Topas的YasTop工具，收集实例内的信息、操作系统的硬件配置信息、故障信息等，并进行统一的分析处理，同时内置会话级SQL等精准定位能力。这样，一线人员只需通过简单的操作就可以快速获取所有的信息并生成报告，大大降低了服务过程沟通不确定性，缩短了解决问题的周期。未来，我们希望进一步提升这些能力，使其能够真正达到手术刀式的精准程度。

Q：现在厂商针对数据库易运维性有两个方向，一个是开放给更多的接口或者开关给DBA，让专职DBA去管理维护好数据库；另一个是将数据库做得更智能、自动化或者平台化，不需要DBA介入，您对此持何观点？

王义寅：我认为这是相辅相成的。在做产品时我们要始终认识到做的人没有用的人厉害，只有用的人才知道产品应该具备什么样的特性。在这个过程中，用的人始终走在前面。

产品的研发一定要有了解如何使用产品的业务专家共同参与，他们对客户需求的准确判断可以指导我们做好产品。产品的自动化应该是后续发展的结果，只有当我们确定了具体的场景和需求时，产品的自动化才能实现。

同时，厂商无法独立实现自动化，服务商的重要性不言而喻。如果厂商按照License的商业模式，很难有足够的动力去提升产品的核心能力。相反，服务商为了应对客户的挑战和需求，可能会推荐其他竞争力更强的同类产品，差异化的服务方式可以为我们提供更多的反馈和建议，帮助我们不断改进产品。因此，共生关系是必不可少的。

Q：数据库的性能问题可能80%都是SQL的问题，但是多数情况下无法修改SQL，请问这种不能改SQL的场景下，YashanDB是如何解决性能问题的？

王义寅：YashanDB支持实例级的缓存与存储调优手段，在无法通过存储参数和缓存机制进行调优的场景下，提供了Hint、Outline等技术手段来改变优化器行为，解决生产上特定SQL的性能问题，并且通过AWR来获取数据库负载特征，对数据库压力趋势做提前规划。我们在内核机制针对常见性能痛点有很多天然的性能优势，如内置的变量窥视技术，缓存与索引等免锁技术等等。

Q：YashanDB的服务大约占license费用的多少？另外YashanDB的服务市场规模有多大？未来如果想做YashanDB的DBA，有哪些就业途径？职业发展的路线是怎样的？

王义寅：目前YashanDB的服务分为实施型服务、维保型服务和驻场型服务，维保型服务通常与License相关，是License费用的22%，其他两种类型的服务与客户的实际场景需求密切相关。目前服务与销售是相辅相成的，虽然目前才刚刚起步，但是我们相信通过专业的能力以及以客户为中心的理念，YashanDB未来的市场规模是值得期待的。

我们打造了一套职业培训认证体系，欢迎有志做YashanDB的DBA参与进来，一起打造YashanDB的服务生态。针对优秀的DBA我们将持续提供原厂的工作岗位，同时也期待他们成为服务公司的老板，共同分润实现共赢。

Q：有的客户可能觉得买了维保数据库运行正常，每年常规工作也就几次巡检，觉得这个钱白花了，您赞同这种观点吗？您觉得数据库技术服务为客户提供了什么价值，客户获得了哪些收益？

王义寅：维保本身是具有保险性质的，是一种商业保障和承诺，原厂服务后面是整个YashanDB厂商，包含原厂商后端的服务和研发团队，能为所有的问题兜底。此外也是原厂与客户间日常产品与技术的沟通渠道，很多实战经验都是通过故障处理和健康检查相互成就并积累起来的。

YashanDB产品对于用户来说经历了陌生到熟悉的过程。维保服务能够增加客户的信心，成就客户的业务发展，在前期的项目中，YashanDB团队与客户并肩作战，完成了核心系统国产化改造的重点项目，在相互成就的过程中，我们团队获得了客户认可，收到了客户的口头和书面表扬，客户的国产化改造项目也因此得以顺利完成，并树立了行业标杆。我们深感荣幸，也倍感责任重大。

Q：对于甲方客户来说，基于投入成本和产品安全稳定来说，应该如何构建自己的数据库服务力量，是培养自己的技术团队，还是采购远程维保、三方服务、原厂维保、驻场维保，您有什么样的建议？

王义寅：建议量入为出，在保障业务最大化高可用稳定运行的前提下，采用适合自己的服务方案。通常情况下可根据公司的数据库规模、复杂度进行判断。 

对于自身监管要求或业务运转要求极高且较为复杂的大型企业，他们必须拥有自己的技术团队，这样才具备可延续性，同时原厂或三方服务也是不可或缺的；对于中等规模的客户，他们最关注的是数据和数据库服务，建议他们同时使用原厂和第三方服务；对于小型企业，建议不必考虑专职的数据库管理员，而是应有一个全栈负责人，具备良好的沟通能力，能够准确描述问题并调动资源解决问题。当然，如果小企业的数据非常重要，那么就应考虑大型和中型企业的要求。

Q：近些年随着开源和国产数据库的兴起，数据库服务市场和需求面临比较大的转折，请分享下在这个转折点您看到的挑战和机遇分别有哪些？

王义寅：这么多年来关系型数据库的本质未发生太大的变化，其概念体系和使用体验基本不变，当前客户在选用数据库时，遇到的各种难以处理的场景，本质上与产品的成熟度有关系。越成熟的产品，需要付出的服务代价应当越少。当前我们遇到很多的行业产品之所以运维门槛很高，本质上是其产品成熟度不够。

我们希望提供简单直接的产品，让运维人员专注于业务问题，未来将聚焦在如何让产品的使用更简单、高效和稳定。当然随着数据的爆发和业务场景的不断更新换代，会催生出很多新的数据库特性和产品，我们期待这些一开始是处于利基市场的产品颠覆现有的主流产品。

Q：当前数据库越来越智能，整个架构趋向自动化、一体化、平台化，很多人觉得传统DBA这个职业会消失，DBA的地位也越来越低，您认同吗？您对这些迷茫焦虑的DBA有什么样的建议？如果转行做国产数据库DBA有哪些路径或者经验分享给大家？

王义寅：运维与调优是一个很专业的领域，很多特定的场景和问题是难以通过一个通用的模型或程序进行高效的处理，需要经验的积累，所以通过自动化、一体化、平台化的方式，几十年来也没有找到答案，完全替代DBA的现象可能还没有出现，但围绕着如何在无风险的操作下快速地把问题解决，对DBA的综合能力要求越来越高。

首先，对DBA的技能要求越来越高。不仅需要精通数据库管理，还需要了解数据存储、数据安全等各方面的知识。同时，随着人工智能AI技术的发展，DBA还需要具备一定的编程能力，能够利用AI技术解决一些复杂的问题。

其次，DBA的职业门槛看似正在降低，但实际上对其接受新事物的广度要求却越来越高。以前DBA可能只需要解决数据库内部的问题，但现在却需要从整个数据中心的视角去发现、解决问题，这需要大量的工具和经验，经验则需要通过不断的学习和实践来积累。

最后，DBA需要具备业务和技术的综合能力。在数据驱动的时代，DBA不仅需要懂得IT技术，还需要了解业务需求和趋势。只有这样，才能更好地为业务提供技术支持，并且成为行业内的专家。

不得不承认的是，DBA日常有大量的重复性的工作，这些应该通过工具提高效率。未来DBA的生态里面需要的是真正能够理解业务、懂透技术的服务型专家，他们的经验和认知会牵引整个服务行业的工具发展以及自动化水平。