关于后端:化繁为简百度智能小程序主数据架构实战总结

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

全文 5262 字，预计浏览工夫 16 分钟

一、主数据概念

1.1 主数据概念介绍

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

依据主数据管理施行的复杂程度，参照 Jill Dyche, Evan Levy 的观点大体能够把主数据管理能够分为六个档次，从低到高反映了主数据管理 (MDM) 的不同成熟度。上面咱们简略介绍一下这六个档次，因为对于个别企业通常次要利用 Level3，所以上面只针对 Level0 到 Level3 进行展示介绍，有趣味的同学能够浏览主数据百科：

(https://baike.baidu.com/item/…)。

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

在 Level 0 的状况下，意味着企业的各个利用之间没有任何的数据共享，整个企业没有数据定义元素存在。由各个系统本人治理本人的数据，共享应用状况是采纳网状替换的形式进行。

Level 1：提供列表

提供列表，咱们可了解采纳了为数据执行注销制度，采纳手工的形式进行数据信息的注销，包含数据的增加，删除，更新以及抵触解决。这种模式曾经有了数据对立治理，保护的动机，只是模式上老本极高，高度依赖人工治理的流程也容易产生谬误。

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

相比提供列表，引入对主数据的对立注销治理的思路。通过建设数据规范和定义并通过存储在地方知识库 (Central Repository) 中共享拜访，为各个系统间共享应用数据提供了元数据定义的反对。尽管存储的数据还是依照各个系统离开存储的，然而因为有了对立的形容定义，以及信息的同步自动更新，在管控能力与老本升高上有了极大的改良。但因为实质还是扩散存储，管控的老本还是十分高。

Level 3：集中总线解决

集中总线解决突破了各个独立利用的组织边界，应用各个系统都能承受的数据规范对立建设和保护主数据。集中处理意味着为 MDM 构建了一个通用的、基于指标构建的平台。这种计划上对主数据有了十分强的束缚与保障，当然引入的建设老本与难度也会相应的进步，特地是主数据的性能、稳定性、事务的保障等。

1.2 为何须要主数据？

为何须要主数据？要答复这个问题，咱们须要先来剖析一下在业务零碎中遇到的问题，咱们把问题大抵能够总结为以下四类：

数据散乱且冗余节约

企业内的每一个零碎、利用、甚至业务部门都会建设本人版本的外围业务实体数据。最好的例子就是客户数据的建设，不同的部门都会因为本人特有的需要别离建设客户数据，例如合同部门的零碎会关注客户与合同相干信息；洽购部门则会关注客户的产品，售后等内容。但对于客户的次要属性如客户名称和地址信息在企业内各个角落都被反复的记录着。这导致了一个很重大的问题（除了存储老本之外），数据冗余导致数据品质过差，对企业来讲也无奈更全面去意识一个残缺的客户属性。

数据不统一，校准难

事实上因为企业内数据的不统一，导致企业大量的资源节约的状况时常产生，这里节约的资源不仅包含工夫、金钱和人力资源等的节约，也包含对客户体验的影响，对业务推动工作的影响等。

业务协同低效

数据散乱状况一旦产生，随同呈现的就是低生产力，低效的业务管理，无奈对立的客户体验，客户不称心，节约市场部门的致力等。

变动导致数据无奈积淀

在企业中，业务的变动导致我的项目的启动与停止是比拟常见的状况，这种高频的变动中，最不应该被散失就是数据，也就是业务的积淀，但没有主数据业务的利用，数据散失就会被当作很天经地义的状况。

总结剖析上述问题，能够看到这些问题的产生，最次要的起因就是没有一个自顶向下的数据治理标准所导致的。主数据的产生实质也是须要企业有一个自上而下的数据治理策略来配合能力高效推动，企业应该建设一个全企业范畴的主数据管理，真正去解决主数据问题，而不应该为了回避建设企业主数据的老本问题而在原有零碎上修修改改。

（https://wenku.baidu.com/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 说

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

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

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

欢送各位同学关注