作者：苟琳，中国恩菲工程技术有限公司大数据平台负责人

作为有色行业数字化转型的引领者，中国恩菲一直在积极推进企业数字化、智能化转型。随着业务的发展，数据呈爆炸式增长，在传统数据库应对乏力时，中国恩菲果断进行了部分新业务数据库替换和迁移，在安全稳定的要求下应用 OceanBase，实现大数据平台整体成本极大缩减，分析型大数据加工处理能力显著提升 。本文分享中国恩菲应用 OceanBase 替换传统数据库实现大数据平台升级的实践经验。

企业背景：

世界五百强企业中国五矿中冶集团子企业之一

中国有色工程有限公司暨中国恩菲工程技术有限公司（原中国有色工程设计研究总院，简称“中国恩菲”）成立于 1953 年，现为世界五百强企业中国五矿中冶集团子企业之一，拥有全行业工程设计综合甲级资质。在全球 30 多个国家和地区参与了 1.2 万个工程项目，立足有色矿冶工程，在产业领域，是国内少有的具备咨询、设计、建设、投资、运营“五位一体”服务能力的企业之一。

在国家大力发展工业互联网、推进智能制造的浪潮之下，中国恩菲作为有色行业数字化转型的引领者，积极推进企业数字化、智能化转型，布局智能工厂、智能矿山领域，积极探索传统工业数智化转型的实践路径。

在 2020 年，围绕打造“数字五矿”战略任务要求，我们推出了“MIM+”数字一体化解决方案。如下图所示，左上角是数字孪生平台；右上角是数字设计平台；左下角是数字化交付协同平台；右下角是矿山智能管控平台。

在“MM+”数字一体化解决方案的整体框架下，中国恩菲在工业互联网领域进一步打造“MIM+”工业互联网平台（见下图），包含四个子平台：基础平台、物联网平台、大数据平台、应用快速开发平台，以满足业务需求。

平台基于“1+1+N”进行整体架构设计，即 1 个中心，1 个平台，N 个应用。“1 个中心”即建设覆盖全厂范围的大规模集控、无边界协同的智慧运营中心；“1 个平台”即搭建工业互联网平台作为工厂生产管控、经营决策的数字化底座；“N 个应用”即基于工业互联网平台开发的多种智能应用和智能装备。

“MIM+”工业互联网平台具备自主可控能力，涵盖统一 IT 资源管理、统一数据采集管理、统一数据应用管理，拥有统一应用门户、统一标准规范、统一平台安全，具备专有工业知识模型开发和应用等核心能力。平台基于设备互联互通释放工业大数据潜能，完美融合“MIM+”数字一体化解快方案，通过“数据+模型+应用”的方式，优化企业传统的生产经营和服务模式。针对工业全要素数据的采集、融合和共享，平台对下可与控制系统、智能装备和仪表等互联，同时提供数据存储、融合、建模和分析的能力；对上可支撑生产管理、经营管理，优化控制、运营决策等生产和公辅应用系统的数据服务，实现系统的集成及企业门户的统一。

业务背景：“MIM+”工业互联网平台特点

基于工业互联网平台，我们做了一些落地项目，如青海盐湖智能工厂、洛阳中硅高科智能工厂等。但在以“MIM+”工业互联网平台为基础进行数字化转型的发展中，我们在数据的处理上存在一些痛点。

下图展示了我们的业务数据流转过程。左上角列举了多种承载信息采集工作的工业互联网设备，这是一部分数据产生的源头，另一部分数据则来源于工厂管控系统。通过数据采集站点，数据被传送到 IoT 物联网平台，业务数据通过开源组件传输至数据底座，进入图中右侧的大数据平台。经过大数据平台的层层处理，最终为业务层提供数据分析报表，以协助生产决策，形成良性循环。

在数据流转过程中，工业互联网数据底座面临两大主要挑战。

一是 IoT 海量分散数据面对业务需求高实时性的挑战。业务系统的状态复杂多变，需要我们实时获取和捕捉有效信息，以便快速决策，及时应对。用于采集数据的 IoT 设备点位很多（少则 5 千多则上万），数据传输频率快，传输频率不一致，因此采集的数据不仅量大，且较为分散，还有一些定时归零的点位和累计总量数据的点位，这些因素导致了业务统计容易出现偏差。因此，数据要能够实时显示到端以辅助快速准确的管理，比如 web 页面上需要显示一些设备的温度和告警，我们期望能有一款数据库承载 IoT 设备的时序数据，以应对更多的业务计算场景。

二是系统运行效率面对大量计算任务的挑战。由于业务部门多，数据互相交织，而且系统开发时间早，大量使用自定义函数、存储过程等，导致系统运行效率较低、维护难度较大。因此，我们考虑对这些超大、超长的业务数据通过新的处理方式进行优化，让业务代码简化，减轻应用的维护难度。

面对上述挑战，为了满足业务需求，需要更加稳定强大的数据底座作为支撑。过去，中国恩菲的一些业务服务数据存储在 MySQL 上，由于集中式数据库的设计特点，偶尔会出现 CPU 占用很高，服务中断无法正常运行的情况。对于上游来说，会出现超时问题。如果访问量大且重试操作过多，可能带来“毁灭级”的阶梯效应，服务面临被打垮的风险。

越来越多的案例证明，在有色行业数字化场景下，面对庞大的数据处理需求，Oracle、PostgreSQL、MySQL 等传统关系型数据库应对乏力。具体而言，压力来自于四个方面：

• 数据爆炸。工业互联网每天的 IoT 数采增量数据激增，传统关系型数据库架构，已越来越无法支撑业务的快速发展。
• 性能瓶颈。工业互联网需要结合大数据平台进行海量数据运算的高并发、高吞吐场景，传统数据库很容易达到性能瓶颈。
• 信息化升级挑战。传统封闭式架构给数据互通、智能化驱动带来限制，亟需运用科技手段真正实现数字化大脑，从整体上改造有色行业信息化的前后台 IT 系统架构，实现包括快速的后台数据处理、高并发稳定性等系统处理能力。
• 数据安全威胁。工控数据安全泄露风险日益增长。

此外，随着业务的发展，无论是存储成本，还是数据查询的性能、数据治理，都对企业提出了更高的要求。而如何让数据快速发挥价值，带给用户最真实、最实时的数据，且不会造成成本的过度浪费，成为了企业亟待解决的问题。

基于业务特点和数据处理的痛点，中国恩菲开始了数据库选型和替换之路。

选型过程：选择 OceanBase 的原因

精准定位问题后，下一步必然就是全力以赴解决问题。要进行数据库现代化升级，就要从底层架构上做出改变，而更加灵活、扩展性更好、可用性更高的分布式架构则是理想选择。

在众多同类型数据库产品中，为什么我们最终会选择 OceanBase？

中国恩菲对于数据库的选型，需要符合四个基础条件：

• 必须满足自主掌控、安全稳定要求。
• 能够解决分库分表带来的各种不便，比如扩展性问题，具备天然的负载均衡能力。
• 兼容 MySQL，技术迁移成本低，对后端组和数据组同学友好。
• 具备 HTAP 能力。

此外，我们希望最好能够低成本甚至零成本完成数据库的替换。

选择 OceanBase，是因为其几乎满足各方面的要求。并且通过评估、改造、实施迁移、开发、管理、生产、运维、复制订阅、安全管控、诊断资质等流程评估，我们发现 OceanBase 在各环节中均表现不俗。

• OceanBase 是蚂蚁集团完全自主研发的数据库，满足自主可控、安全稳定要求。
• OceanBase 原生分布式的特性带来了强大的扩展能力，其中横向扩展通过加减机器即可应对业务的扩缩容，保证业务的服务质量。结合“MIM+”工业互联网平台，具备在线扩缩容能力，有效应对瞬时流量洪峰等场景。另外，OBProxy 也功不可没，使我们再也不用担忧分库分表带来的问题，减少了技术负债。
• OceanBase 高度兼容 MySQL，在不改造代码的情况下无缝迁移，减轻后端同学的工作压力。
• OceanBase 拥有丰富的生态体系，这一点对于数据库服务的可持续性至关重要。比如 OMS 方便历史数据迁移，OBD、OCP 等黑白屏工具便于运维同学顺利完成工作。
• 此外，OceanBase 还提供 Oracle 体系支持、DBLINK、通信加密、存储加密等功能，也加速了我们的选型

应用过程：整体成本极大缩减

大数据加工处理能力显著提升

有了 OceanBase 的助力，“MIM+”工业互联网平台的资源管理能力和资源利用率大幅提升，同时显著缩减成本。具体表现在：

• 通过整合竖井式应用，集中化管控，统一资源分配和运维，在承载与原数据库相同业务水平的情况下，业务数据库容量得到释放，大大提升了资源利用效率。
• 成本方面，依靠 OceanBase 强大的资源整合与运维管控能力，使用 OceanBase 数据库后平台整体成本极大缩减。
• 此外，整个迁移过程也并未带来繁重的迁移成本，OceanBase 对 MySQL 的高兼容能力和平滑迁移方案，帮助我们避免了上千万行老核心代码的重写。

在成本缩减的同时，使用 OceanBase 后，系统的性能和安全性也明显提升：分析型大数据加工处理能力显著提升；系统开启数据加密，保障数据安全的同时，对性能的影响不足 5%。

在一个实际应用案例中，我们希望建立以工业互联网为基础的信息化业务管理系统，对下辖的多家子企业建立统一平台，统一管控，做到上下级生产数据上传下达，高效安全的传输和存储，以便集团总部能够从各个子企业的数据进行汇总分析，挖掘企业生产管理、行业动向等相关的数据价值。

从上图可知，总部下分三个子企业，每个子企业下都有各自的业务场景，每个场景中都设有 IoT 设备。“MIM+”工业互联网平台部署在总部及各个子企业，数据库集群也相应部署在总部本地和子企业本地。我们在每个企业均部署了 OceanBase 集群，均采用同机房一中心三副本。在该架构下，对比原来的 MySQL 方案，OceanBase 方案减少存储硬件配置达 17%，缩减信息化改造的工作量达 22% 。

在该项目中，我们也积累了一些 OceanBase 使用经验，供大家参考。

💡 经验 1：测试环境使用 OBD 部署集群。

我们在测试环境使用 OBD 部署集群曾遇到操作失败的情况，我们归纳了两种错误原因，并整理了以下使用心得和建议：

第一种错误情况是在使用配置文件进行部署时，默认采用了生产模式，生产模式下会按照生产环境最低资源配置进行服务器资源检验，而当测试环境的内存低于生产要求时，会导致操作失败。我们的内存配置小于 16G（低于生产要求）导致集群不能正常运行。解决方法为关闭生产模式验证参数 production_mode: false，生产环境建议按照官方要求的资源规格配置。

💡 经验 2：机器配置影响 OceanBase 服务启动。

我们当时使用的 OceanBase 4.0 版本暂不支持自动重启服务（4.2 版本开始支持），我们对现场部署 OceanBase 的机器做了重启，但 OceanBase 没有自动拉起，查看 obd cluster list 显示状态是 running。这是因为 OBD 服务状态是命令触发更新的，重启机器时 OBD 会保持运行前的状态，需要重置 OBD 的服务状态：obd cluster stop ，再执行启动命令 obd cluster start， 启动服务。

我们进行上述操作后，仍启动失败，机器挂载磁盘顺序乱了，导致 Clog 文件软连接失效。这是现场硬件环境引发的挂载配置问题，根据其他节点部署配置或者部署配置文件中的信息调整为正确的磁盘挂载就能解决问题。

💡 经验 3：sys 管理租户与业务租户的混用。

OceanBase 提供多租户能力，可以帮助业务整合不同数据库实例，简化运维管理。但在真实的业务场景中，我们观察到，有时业务团队会错误地把 sys 管理租户当成生产租户来使用。sys 系统租户是仅管理租户，配置的资源占比较少，如果将其作为生产租户使用，则可能会出现性能问题，且系统租户有部分业务功能不支持。而按需自建的业务租户不存这些限制，能够更好地支撑业务运行。因此，在设置租户时，需要注意避免将 sys 管理租户与业务租户混用。

未来展望：立足 OceanBase 打造数据底座

当前 OceanBase 已接入中国恩菲大数据平台，提供数据底座支撑，保障业务数据的平稳对接。我们计划将更多业务数据接入 OceanBase 中，参与数仓建设，为公司提供扎实的业务支撑。

现在各个业务部门的数据越来越多，数据的整合渠道越来越多，参考维度和指标设定也越来越复杂，对数据的要求就越来越高，不仅数据质量需要保证完整性、一致性、准确性、唯一性、及时性，还要保证数据符合国家级、行业级、企业级的标准，再以海量的数据作为支撑，为企业提供更好的数据资产应用服务，一个强有力的数据底座是有非常重要的意义的。借助 OceanBase 提供的数据底座能力，我们坚持在数据治理层面降本增效，减少多个数据库体系带来的不便，上下层齐步走，统一数据战线。

数据仓库的建设是一个长期持续的过程，它需要不断地优化和升级以适应不断变化的市场环境、业务需求和技术迭代。只有拥有稳定、可靠的数据底座，才能更好地推动数字化转型的进程。在未来的数据业务发展中，我们将继续加强对大数据平台的投入和研发，不断提升其在数据处理和分析方面的能力，以满足更广泛、更深入的应用场景需求。

转载自OceanBase官方，原文链接：https://mp.weixin.qq.com/s/biBLghr7oTdZY8-oV11Y_w

想了解更多资讯

截图至微信扫码关注👇

了解更多考试相关

扫码添加上智启元官方客服微信👇