化繁为简 -- 百度智能小程序主数据架构实战总结

导读：企业数据孤岛、共享数据管理、数据服务性能面临挑战，高可用的主数据管理服务越来越被企业所重视，本文内容是基于百度智能小程序主数据实战经验的一些总结，从解决百度智能小程序核心业务数据模型的质量和共享协同入手，重新定义业务数据模型边界，提供企业高可用的数据管理服务的演进过程，希望帮助大家在主数据应用的道路上获得更多帮助。

全文 5262 字，预计阅读时间 16 分钟

一、主数据概念

1.1 主数据概念介绍

主数据（Master Data 简称 MD）， 一般指系统间共享数据（如客户、账户和组织等有共享场景的数据内容），所以其核心的价值就是解决数据的共享与一致性的问题。

根据主数据管理实施的复杂程度，参照 Jill Dyche, Evan Levy 的观点大体可以把主数据管理可以分为六个层次，从低到高反映了主数据管理(MDM)的不同成熟度。下面我们简单介绍一下这六个层次，由于对于一般企业通常主要应用 Level3，所以下面只针对 Level0 到 Level3 进行展现介绍，有兴趣的同学可以阅读主数据百科：

(https://baike.baidu.com/item/%E4%B8%BB%E6%95%B0%E6%8D%AE/7310399)。

Level 0 ：没有实施任何主数据管理(MDM)

在 Level 0 的情况下，意味着企业的各个应用之间没有任何的数据共享，整个企业没有数据定义元素存在。由各个系统自己管理自己的数据，共享使用情况是采用网状交换的方式进行。

Level 1 ：提供列表

提供列表，我们可理解采用了为数据执行登记制度，采用手工的方式进行数据信息的登记，包括数据的添加，删除，更新以及冲突处理。这种模式已经有了数据统一管理，维护的动机，只是模式上成本极高， 高度依赖人工管理的流程也容易发生错误。

Level 2 ：同等访问(通过接口的方式，各个系统与主数据主机之间直接互联)

相比提供列表， 引入对主数据的统一登记管理的思路。通过建立数据标准和定义并通过存储在中央知识库(Central Repository)中共享访问，为各个系统间共享使用数据提供了元数据定义的支持。虽然存储的数据还是按照各个系统分开存储的，但是由于有了统一的描述定义，以及信息的同步自动更新，在管控能力与成本降低上有了极大的改进。但由于本质还是分散存储， 管控的成本还是非常高。

Level 3 ：集中总线处理

集中总线处理打破了各个独立应用的组织边界，使用各个系统都能接受的数据标准统一建立和维护主数据。集中处理意味着为 MDM 构建了一个通用的、基于目标构建的平台。这种方案上对主数据有了非常强的约束与保障，当然引入的建设成本与难度也会相应的提高，特别是主数据的性能、稳定性、事务的保障等。

1.2 为何需要主数据？

为何需要主数据？要回答这个问题，我们需要先来分析一下在业务系统中遇到的问题，我们把问题大致可以总结为以下四类：

数据散乱且冗余浪费

企业内的每一个系统、应用、甚至业务部门都会建设自己版本的核心业务实体数据。最好的例子就是客户数据的建设，不同的部门都会因为自己特有的需求分别建设客户数据，例如合同部门的系统会关注客户与合同相关信息；采购部门则会关注客户的产品，售后等内容。但对于客户的主要属性如客户名称和地址信息在企业内各个角落都被重复的记录着。这导致了一个很严重的问题（除了存储成本之外），数据冗余导致数据质量过差，对企业来讲也无法更全面去认识一个完整的客户属性。

数据不一致，校准难

事实上由于企业内数据的不一致，导致企业大量的资源浪费的情况时常发生，这里浪费的资源不仅包括时间、金钱和人力资源等的浪费，也包括对客户体验的影响， 对业务推进工作的影响等。

业务协同低效

数据散乱情况一旦发生，伴随出现的就是低生产力，低效的业务管理，无法统一的客户体验，客户不满意，浪费市场部门的努力等。

变化导致数据无法沉淀

在企业中，业务的变化导致项目的启动与中止是比较常见的情况， 这种高频的变化中，最不应该被流失就是数据，也就是业务的沉淀，但没有主数据业务的应用，数据流失就会被当作很理所当然的情况。

总结分析上述问题，可以看到这些问题的发生，最主要的原因就是没有一个自顶向下的数据治理规范所导致的。主数据的产生本质也是需要企业有一个自上而下的数据治理战略来配合才能高效推动，企业应该建立一个全企业范围的主数据管理，真正去解决主数据问题，而不应该为了逃避建立企业主数据的成本问题而在原有系统上修修改改。

（https://wenku.baidu.com/view/b7cb9e4e2e3f5727a5e962fa.html?re=view）。

二、 主数据架构实战总结

2.1 业务背景分析

主数据建设遇到各种问题和挑战，主要包含以下几点：

2.1.1 问题

• 随着百度小程序业务增长，业务模块务数量激增，都需要对数据有变更与检索的需求。

• 各业务服务模块 SLA 标准不统一，很难提供一个高可用服务，满足业务需求。

• 网状式的数据存储，造成数据冗余、数据一致性、数据安全、数据孤岛等问题。

• 对数据认知存在差异，多系统、跨产品、跨部门之间数据交互困难，无法做数据统一管理。

2.1.2 挑战

• 数据边界划分，哪些数据要纳入主数据？

• 数据模型变更，如何高效管理数据模型？如何高效满足业务快速更新迭代？

• 如何保证数据一致性，正确性，以及服务稳定性?

• 如何保证数据共享实时性，准确性？

2.2 整体架构设计方案与思路

主数据管理服务本身也是一个不断优化和演进的服务，在实战过程中不断探索，理论指导实践，总结出一套符合百度智能小程序业务的方法论，我们首先从分析阶段开始。

2.2.1 分析阶段

目标从需求分析出发，将问题映射到问题空间，对需求进行梳理抽象，理解问题和需求背景，进行数据和流程分析，分析业务领域模型，采用数据流图（Data Flow Diagram）：简称 DFD，以图形方式来表达系统的逻辑功能、数据在系统内部的逻辑流向和逻辑变换过程。在确定了全景事件流之后，需要鉴别出领域边界，通常采用事件风暴方法，进行领域分析建模。

以百度小程序创建使用流程为例：百度小程序创建使用业务流程分析

百度小程序创建使用流程，事件风暴分析结果：

2.2.2 设计实现阶段

将问题空间映射到解决方案空间，抽象业务领域，领域数据建模，划分服务边界，架构设计与实现，设计阶段需要根据需求分析，画出用例图、状态图、实体类图、序列图、ER 图确保用例没有问题，参考“主数据”设计原则，划分服务边界，将数据模型以“切蛋糕”的方式，划分到不同的子服务域以及主服务域中。

参考数据层次划分模型理论，提取关键概念作为子域，主要划分了客户域、产品域、用户域以及基础数据域 4 块，客户域围绕客户进行建模、产品域围绕小程序进行建模、用户域以开发者模型为主，基础数据域提供元数据码表。具体如下：

产品域：小程序、包、类目、等级、权益等业务的核心数据模型

基础数据域：小程序类目、宿主等基础数据模型

用户域：用户、角色、权限等用户域

客户域：主体、资质等客户域

2.3 主数据架构设计目标

小程序主数据旨在解决多系统中共享数据问题，提炼小程序业务核心数据模型，作为基础服务，为主数据范围内的核心数据模型提供一套数据治理的解决方案，包括为各个业务端提供核心数据的存储、检索、分发等服务。

先来看一张图，下面这张图就是主数据服务部署架构：

2.3.1 整体设计目标

• 消除数据冗余；保证数据一致性、安全性

• 统一数据认知

• 统一数据管理，提供高可用服务

• 数据共享，提高多系统、跨产品、跨产品、跨部门之间数据协同力，支持数据多场景、多维度分发

2.3.2 架构设计与实战

数据传输服务概念介绍，数据传输服务（Data Transmission Service），支持关系型数据库、NoSQL、大数据(OLAP)等数据源间的数据传输。它是一种集数据迁移、数据实时同步和数据订阅于一体的数据传输服务。数据传输在公有云、内部私有云、Paas 私有云均有广泛的应用场景，为用户打造安全、易扩展、高可用的数据架构。

2.3.3 关键技术点实现介绍

2.3.3.1 事务/补偿

事务/补偿使用场景分析：多表关联存储操作，主从延迟敏感场景强制读主库，关键异常数据定时补偿/实时重试。

系统开发过程中，需重点关注大事务提交，大事务会导致主从延迟、IO 负载、数据库性能下降等，需合理评估事务操作数据量级，大数据批量操作原则：

1. 事务大小要合理

2. 数据量可控

3. 接口耗时可控

对于 insert/update/delete 操作，每次处理 100~500 条，执行 commit

对于 select 操作，每次查询 100~500 条

推荐：在业务场景可接受范围内，分批成小事务操作

2.3.3.2 高性能读写，高性能检索

服务高性能主要实现方式，缓存、数据库优化、数据同步解耦等，以主数据服务为例，主要使用提高服务性能手段如下：

缓存方面：对于多读少写场景，添加多级缓存【分布式缓存、本地缓存等】减轻数据库压力，保证服务横向扩展。

数据库优化方面：从几个方面入手，不合理的大批量更新写入，导致数据库主从延迟问题；数据库深度分页问题；合理使用子查询优化；索引排序问题。

数据库索引，缺乏合适的索引，一个稍大的表全表扫描，稍微来些并发，就可能导致 DB 响应时间急剧飙升，甚至导致 DB 性能的雪崩。

检索方面：对于多表检索、模糊检索等场景，使用 Es 特性来满足高性能检索。核心关键点保证数据库到 Es 同步时效性以及准确性。

2.3.3.3 可用性

主数据是各个业务端对于核心数据操作的唯一服务，必须保证服务的高可用性，主数据实时服务采用微服务架构，利用百度资源虚拟化能力，实现服务治理、统一配置管理、分布式链路跟踪等功能，支持请求负载均衡、重试，服务自我保护（限流、熔断、降级等），并实现了无人值守的机器故障自愈，充分保障服务可用性。

2.3.3.4 流程机制

设计把关：因主数据的升级，影响面比较广，建议有专业化的独立团队进行把关，确认设计的质量。

开发规范：注重编码质量，保证编码规范统一，定期组织代码 review，提升代码可读性，维护性。

测试验收：除了自测，单测等工作外，主数据还需要更完善的系统级测试， 能实现多方接入业务的联动测试回归。

上线：小流量， 灰度，自动化回退、封禁管理等能力，上线确认机制。

运维：应用生命周期管理，用户权限管理，可观测监控能力， 实时监控与高效问题定位。

2.3.3.5 高时效性数据同步

主数据实时变更数据的同步方案，基于 binlog 监听，多 MQ 并发写入支持横向扩展，保证 binlog 写入速度；统一数据接收分发服务，基于数据版本控制，支持服务横向扩展，保证数据消费，分发时效性；数据监听，补偿服务保证数据共享可靠性。

下面这张图就是主数据服务数据同步分发架构模型：

总结：百度小程序团队早在 2019 年就完成主数据服务上线，基于百度小程序核心数据模型，完成数百张数据模型沉淀，最高支持 9000+QPS，SLA 全年可用性 4 个 9 以上，覆盖百度 10+核心业务产品线接入，保障百度智能小程序整体服务可用性达到 4 个 9 以上。数据一致性达到 4 个 9，通过一致性监控补偿，保证数据最终一致性。

三、 主数据延展思考

3.1 主数据是否还有更多可适用场景？

主数据应用除了服务实时的在线业务系统外，还有很多场景可以应用。例如 基于主数据做 数据资产的审计与监控分析， 将主数据作为重要的数据资产，对其建设、使用等情况进行全面的监控，同时对于主数据的更新、变化趋势，乃至关联数据进行分析，可以一定程度上改善决策支撑，以及发现业务操作上的问题，进行实时审计，促进管理体系的不断完善和业务发展不断提升。又例如基于主数据承接业务画像建设工作，通过主数据本身的数据高实效与正确性的保障，加上主数据比较完善的模型设计， 可以极大的节省业务画像建设的成本。

3.2 如何提升团队的主数据工程能力?

主数据(MDM 系统)的建设是打造数据思维能力的基础工作，是一个需要不断完善进步的过程, 建设过程中涉及所有部门、每一方业务系统设计者的协同与配合。以下也整理了一下相关的总结，希望可以帮助大家提升主数据的思维能力：

1. 加强大家对主数据的学习与认识，最好在机制上进行对齐。建议有强制要求各业务方参与建设。

2. 构建单独的主数据建设团队，以中立的视角来承接，保障建设的合理性，规范化与专业化。

3. 加强模型设计与架构设计的评审工作，确保执行过程的效果，同时加强总结，帮助大家的学习，提升能力。

推荐阅读：

｜百度搜索中台海量数据管理的云原生和智能化实践

｜百度搜索中“鱼龙混杂”的加盟信息，如何靠AI 解决？

｜快速剪辑-助力度咔智能剪辑提效实践

---------- END ----------

百度 Geek 说

百度官方技术公众号上线啦！

技术干货 · 行业资讯 · 线上沙龙 · 行业大会

招聘信息 · 内推信息 · 技术书籍 · 百度周边

欢迎各位同学关注