新数科技王翔宇：企业数字化转型中的数据库管理体系建设趋势｜爱分析活动

爱分析ifenxi 2023-01-16

534

2022 年 12 月底，爱分析举办了“2022爱分析·数据智能网络研讨会”。爱分析邀请新数科技副总裁王翔宇进行了题为《企业数字化转型中的数据库管理体系建设趋势》的主题演讲。

数据智能融合大规模数据处理、数据分析与挖掘、机器学习、可视化等多种大数据和人工智能技术，为企业提供数据驱动的智能分析与决策。随着数据规模的持续膨胀与分析场景的更加多元化，企业也对数据基础设施进行持续升级与优化，提升体系化、智能化、安全可控水平。

新数科技副总裁王翔宇在会上的演讲围绕数据库管理展开，详细讲述了数字化转型中企业对数据库管理模式的变化，以及数据库管理体系的建设，并且分享了典型的实践案例。

现将王翔宇副总的演讲实录整理后分享如下：

首先，非常感谢今天能够有机会来做分享。我叫王翔宇，来自北京新数科技。公司在2014年成立至今，围绕着整个数据库生态体系，从最早的监控到现在的统一管理，一直聚焦在数据库领域。今天我会把我们这些年做的相关产品，以及为客户带来的价值给大家做一个分享。

分为四个话题：第一，当前企业数据库发展的现状以及挑战。第二，整个数字化的转型期间，数据库的管理模式的转变。第三，如何更轻松地实现数据库管理体系的建设。第四，我会跟大家分享不同的客户，包括大型金融机构和小型制造企业等，在实际数据库管理体系建设上的实践，以及体系所带来的价值。

企业数据库发展现状及挑战

从整个市场的分布来看，在传统的数据库 1.0 时代，数据库原厂的产品跟服务占了 70% 左右，还有 30% 可能是周边的一些生态。但从 2008 年开始，数据库进入了 2.0 时代，即后关系型数据库阶段。特别是最近两年，我们都更深刻地感受到，各种新型的数据库、分布式数据库以及现在更多在讲的信创的、云化的数据库等开始涌现。据不完全统计，现在国产数据库厂商应该有一百多家，国产数据库产品有两三百种。数据库正在进入一个蓬勃发展的时代。在这个时代下，没有任何一个原厂商能提供对各种各样数据库一个完整的生态服务。所以在整个市场上，面向各种各样的数据库，应运而生的就是我们新数科技，我们来提供数据库 2.0 时代下多种类数据库统一的管理和运维。

在数据库 2.0 的时代，企业使用数据库时会面临着四个挑战：第一，数据库的数量增长非常多。微服务架构带来数据库纵向的拆分，分布式架构带来数据库横向的拆分。另外，企业提供业务的能力在不停地增长，业务互联网化在增长，各种各样的业务系统层出不穷。举个典型的例子，一个股份制银行，在原来的 1.0 时代可能几十个或者几百个数据库，但是到 2.0 时代都是有几千个数据库在使用，基本上是以 10 倍的速度在增长。第二，数据库种类越来越多。刚才讲到国产化的数据库能有两三百种，我想大部分企业少说有三四种数据库在用，多的甚至可以达到十多种，并存着包括Oracle、Db2 和开源的MySQL、MongoDB、Redis 等等，还有像国产的达梦、人大通用等。第三，数据库架构越来越复杂，包括分布式、读写分离、高可用，甚至两地三中心灾备等架构。第四，敏态业务需求变化越来越多。业务的需求变化意味着整个数据库也要跟着变化，随着各种应用发布或者是业务变更越来越频繁、功能不断更新，数据库也要相适应地变更，可能需要增加字段或者增加表。此外，应用互联网化使得资源的动态扩缩容也成为了普遍需求，分布式数据库要能够动态地去增加更多的节点。

数字化转型期企业数据库管理模式

在这些挑战之下，企业使用数据库或者进行运维管理的模式就必然要发生变化。那么怎样来满足这些需求，以及怎样来建设整个数据库的管理模式来应对这些变化跟挑战呢？

在传统的数据库运维模式下，运维团队大部分的工作内容其实是比较确定且单一的，运维团队负责将数据库安装部署并上线，上线后如果出现问题，比如业务方提出来数据库运行变慢，则需要运维团队去查看系统出现了哪些故障。这样的数据库运维往往都是被事件或者需求驱动的。然而在当下数据库种类多样化、数量急剧增长、运行环境愈发复杂的情况下，这种被需求或者事件驱动的模式已经越来越难以持续。

对此，我们的有一个整体的设想：通过建设数据库统一的管理体系，我们可以把各种架构、各种类型的数据库纳管起来，即提供统一的数据库管理平台。该平台提供标准化安装部署、自动监控告警、业务端SQL上线审核优化、自动执行管控等功能。除此之外，平台还支持各种日常的运维操作，比如创建用户等。我们通过一个完整的平台、一种标准化的服务能力来应对前面提到的运维管理被事件驱动的情况，把 DBA 的能力固化在平台上，通过平台来进行输出。

如何更轻松地实现数据库管理体系建设

整个平台是经过我们跟大量的企业一起来解决数据库转型和管理中的各种痛点，逐步打磨出来的。如果我们把整个平台拆开来看，它其实是有各种各样的功能模块来一一对应解决企业在数据库管理当中的各个痛点的。

首先，企业第一个痛点是多样数据库、多种 IT 基础设施环境，并且它们都处于不断变化中。该痛点的解决方法是统一地把数据库都管理起来，并且有一个统一的模型来屏蔽差异。第二个痛点是数据库在转型期开源生态资源不足，面对转型期工具文档少、相关数据库技能缺失、专业服务不足等问题，新数在替换数据库过程中能够提供自动化的监控和运维工具，甚至包括数据迁移的工具。第三，企业数据安全隐患多，对于各种无论主客观的误操作，企业在数据安全管理上要有一个主动的措施来防范各种可能存在的安全隐患。安全管控的平台对数据库去做安全巡检、权限控制还有灾备。此外，随着微服务化态势明显，企业认为传统数据库的安装部署，在即使做了自动化的情况下，依然交付速度太慢，而虚拟化资源浪费又太多，企业希望交付过程能更快更稳定，所以我们也尝试把数据库跑在容器云上面，来提供更高效的交付能力，做更好的资源的隔离。最后，数据库的人才技能缺失也为企业带来了难题。由于各种各样新型数据库的相关技术人员和 DBA 越来越难找，并且培养周期太长，所以我们这个平台要让一个普通的 DBA 能快速地掌握更多数据库的管理能力，或者通过平台来降低数据库管理的门槛。

针对企业各种各样的痛点，我们形成了自己的数据库管理体系全生态矩阵，来解决在现阶段企业管理数据库遇到的难点。首先，数据库云管理平台，或者叫 DMP、DBPaaS ，它从资源交付到监控，再到自动化运维，把数据库全生命周期地管理起来，具备实时监控、性能优化、自动巡检、故障自愈、批量变更等能力。其次，我们的数据库的传输平台DTS提供数据的复制同步、异构迁移、库表转换以及 SQL 改写功能。另外，数据库的安全管控平台DSC提供数据库的权限管理，执行控制，SQL的审核和备份脱敏等功能。最后，是数据库容器云，它通过容器交互的方式，更快、更高效、更符合云原生地来提供数据库的整体服务能力。

首先，我们可以看到整个DMP能够为所有主流数据库提供全生命周期的管理。从最开始的快速交付，到自动部署标准化的参数、安装路径和用户权限，来实现统一的管理。数据库上线之后平台对其进行实时监控、数据采集、SQL语句审核、性能基线告警，甚至主动地预防潜在隐患，及时发现数据库的问题。此外，还包括数据库性能、容量的分析。当平台分析出数据库或者 SQL 存在的问题、系统遇到的瓶颈后，管理模块会把问题提前抛给相关责任人进行预防，督促他们在一定周期内把问题隐患消灭掉，从而形成解决问题的良性闭环。或者当问题告警出来后，平台能够自动修复处理。总体而言，数据库统一管理平台提供20多种产品功能，这些能力基本上可以解决前面提到的各种问题。

目前DMP的产品化程度非常高，产品化率达到 90% 以上，而剩下的10%则需要跟企业现有的运维体系去对接融合来更好地发挥作用。例如，为了更好地服务更多用户，企业需要与单点登录系统去对接；为了能快速准确地纳管各种各样的数据库或者自动创建数据库，企业需要跟CMDB去对接。目前，整个平台已经支持超过18种数据库，基本上覆盖了主流的数据库。

在统一的管理平台下，还延伸出了刚才提到的各种大的功能模块。SQL 审核体系覆盖了数据库从开发测试到生产的整个阶段，并且会跟 DevOps 做标准的集成，在开发阶段就把写得不好或者有性能隐患的语句排查出来，指出该语句的写法违反了什么样的规则，甚至提出一些修改建议。此外，平台还会在测试阶段发现查询计划的缺陷，并且自动地抛出这些问题。在传统的数据库运维管理模式下，这些隐患问题其实是在SQL上线后，如果业务方发现性能变慢了，再告诉 DBA 去做数据库的优化或者SQL的更改，整个过程是后置的。而且想去改变已经上线的 SQL 语句，往往是非常困难的。通过整个 SQL 审核体系，我们可以在开发阶段就发现这些问题。其实有不少我们的客户做过 SQL 审核上线前后的对比，比如某股份制银行，通过 SQL 审核模块，在开发阶段进行严格把关，新上线的系统跟以前旧的系统对比，能显著减少 80% 的 SQL 性能问题，所以这个模块发挥的作用是非常大的。

在整个产品体系当中，ShinData DSC 数据库安全管控平台从 SQL 开发、测试到生产上线，主要来确保 SQL 执行是不越权、合规、按照计划去执行的。而且它会自动地把执行操作记录下来——谁几点几分做了什么样的执行，执行结果是什么样的。整个安全管控的执行流程也是简化的，比如开发一个新的应用，里面涉及到一个 SQL 的变更，传统模式下可能是开发人员让 DBA 来把 SQL 变更好。在有安全管控平台的模式下，开发人员通过自助申请 SQL 变更，SQL 通过 DBA 或者管理员审批，并且约定好 12 点执行，平台就会在 12 点自动地去执行这些 SQL。同时，我们可以选择在执行前是否去做变更前的备份，如果变更失败，还可以选择是否去做回滚。

这里很重要的一个设计点是安全。在传统模式下，去查询，或者去做变更，最容易发生的其实是越权，无论是主动去删，还是误操作删除，发生的概率其实都是存在的。但是像这种误操作，对于企业数据库生产来说，其实是非常致命的。平台的自动化，不仅提高了SQL变更效率，更重要的是能够提前地预防安全隐患。传统的模式都是执行完成后记录下来，进行事后的审计。但是通过安全管控，保证了在数据库上执行的语句都是合规且不越权的。

另外，平台还有一个模块叫做 ShinData DTS 数据传输迁移平台。在企业上线新的数据库时，必然会面临着数据库异构迁移的问题，包括如何迁移评估、SQL 如何改写等等，并且企业希望迁移过程是不停机、保证数据实时复制的。DTS 数据传输迁移平台会提供一站式迁移服务，包括迁移评估、迁移后的验证、数据比对等在内的完整迁移流程，开发团队能够依赖迁移平台自助化地完成整个数据库的迁移。

此外，我们还有一个用于监控和性能容量分析的软件ShinSight，它在DMP里对应的其实是一个完整的性能容量分析的模块。但是有一些偏中小规模的数据库运维需求，他们更多的是希望把整个数据库监控起来，数据库出现问题能够及时发现，即能够进行自动化的监控巡检。所以我们也推出了这样一个轻量级的软件来满足此类需求。ShinSight有各种各样不同的版本，其中，社区版是可以免费下载使用的，它主要起到的是数据库监控和性能分析的作用。

数据库容器云平台ShinDB基于容器化来提供数据库云原生的服务，支持多种类的数据库，比如 MySQL、openGauss、Redis、MongoDB 等，ShinDB通过容器化K8S快速地通过容器化来建设企业数据库私有云体系，并且能够很好地做到资源隔离。比如，一个业务系统要跑在 4C16G MySQL 某个版本的数据库上，ShinDB可以通过容器化云原生的方式，快速地在几分钟之内，提供包括从硬件、软件到各种架构的服务。如果用户需要更多的节点，ShinDB也能够实时地进行资源弹性伸缩。总体而言，通过容器化平台实现数据库的云原生交付，企业能够快速方便地建设数据库私有云体系。

数据库管理体系建设实践分享

不同客户其实是可以有选择地来建设数据库管理平台的。大家可以根据自己的实际需求来建设，我们会选择其中的一些模块来进行介绍：

（一）某股份制银行案例

首先，第一个例子是某股份制银行的，该银行因为规模较大，所以整个 dbPaaS 的功能建设是比较完备的。它所面临的痛点其实跟咱们前面描述的是非常一致的：数据库种类繁多，其中包含了商业数据库、开源数据库和国产数据库，总共大约有十多种。整个数据库的节点有几千，甚至接近上万个。在传统模式下，该银行很难实现对数据库的统一管理。该银行很难同时使用这么多不同的工具。而且，各种工具的对接、集成也非常困难。

在这种情况下，该银行建设了一个完整的 dbPaaS 管理平台，通过标准化的产品加上定制开发来满足自身需求。定制开发根据该银行的实际情况，跟CMDB、DevOps、单点登录、统一告警、工单下发等各种系统进行完整对接，让 dbPaaS 成为数据库管理中的一个环节。所有对数据库进行管理的操作，都会通过 dbPaaS 这个门户来进入，包括数据库创建、状态监控、巡检、性能分析、自动化运维，以及包括刚才提到的执行变更等。此外，该银行还进一步地建设了容器化平台，所有在容器化平台上创建的数据库也会被纳入进行统一管理。

通过 dbPaaS 的建设，该行形成了一个全行统一数据库的管理体系，整个 dbPaaS 成为了数据库管理、服务的唯一入口，从而有效降低了各种开源和商业数据库的运维的门槛。企业数据库的管理运维团队还是那些人，他们原先可能是做 Db2 、Oracle或者 MySQL 的，但是现在种类多了之后，团队通过平台也能够来提供相对不同新类型数据库的服务。此外，在做数据库替换的过程中，借助 dbPaaS 的能力，该银行也能够对新引入的数据库进行管理。因为新数据库是一个分布式的数据库，节点会越来越多，而且走的是开源的技术路线，平台能够有效助力核心数据库的转型。

（二）某制造企业案例

我分享的第二个案例来自某制造企业，该企业对于管理平台的主要诉求是对在运行的三四种、不到二十套的数据库进行监控，并且对问题及时告警，或者自动巡检来提前排查隐患。传统模式下，DBA需要每个月去巡检，甚至每天亲自上手去检查，工作费时费力，也未必能发现问题。

该平台产品交付的形态是针对不同种类，例如Oracle、MySQL、 SQL Server、MongoDB、HANA等数据库，ShinSight会有统一的模型来打通不同种类数据库之间的差异。有些企业可能只有一个DBA，但是这个 DBA 有统一的模型支持，就可以发现数据库相应的问题。当数据库上某个地方出现问题了，平台会自动地告警出来，并且产出巡检报告。通过ShinSight，系统的故障率较以前下降了 80% 。而且平台并不是在故障发现了之后进行告警，而是通过统一的模型，提前去排查数据库的隐患。我举个典型的例子，比如数据库的存储快满了，平台能够提前告警出来，而不是等到数据库停止运行了再告警出来。

（三）某金融企业案例

第三个案例，某金融企业基于容器实现了整个数据库的云原生化。该企业的痛点其实非常简单：随着业务互联网化，各种各样的数据库的开发测试和运维工作亟待交付。虽然已经建设了交付半自动化的模式，但整体还是依赖于虚拟机、半脚本化的方式去安装部署。整体周期比较长，甚至是脱节的。因此，该企业希望通过整个数据库容器云来实现快速的、达到分钟级别的数据库交付，同时也要尽量节约资源。

我们通过帮助客户建立了整个数据库的容器云，真正地实现了从底层硬件资源到最终标准化数据库的自助化交付。它的交付形式非常简单，比如某个业务说，我需要4C16G的一个 MySQL 的数据库，数据库容器云可以在分钟级把这个架构拉起来，自动化资源申请和适配大幅度降低了企业运营成本。同时，所有通过容器化来交付的数据库，都会全生命周期地纳入到数据库的统一管理平台里面去。

（四）某保险集团案例

这是另外一个保险集团做自动化运维平台的案例，他们的侧重点跟前面的不太一样。由于数据库数量较多，而且运维团队人员有限，希望通过一个自动化的平台，把一些例如数据库赋权、Top SQL 查询、报告等常用功能通过平台来自动化地完成。