摘要：MDM平台作为基础数据治理平台，主要解决企业内部主数据的统一、治理、标准化的问题，通过MDM平台建立主数据的治理体系，形成从申请到归档的主数据全生命周期管理流程，保证企业内部主数据的一致性、完整性和准确性。

MDM平台作为基础数据治理平台，主要解决企业内部主数据的统一、治理、标准化的问题，通过MDM平台建立主数据的治理体系，形成从申请到归档的主数据全生命周期管理流程，保证企业内部主数据的一致性、完整性和准确性。

一般情况下，MDM平台主要管理结构化的共享数据，如客户、供应商、物料、项目等主数据的基础信息，用于实现跨系统的数据共享，但为了保证数据的准确性和一致性，主数据也会存储一些文件类数据，如客户、供应商的营业执照、物料的图片或项目的立项文件等。具体的场景不同，这些文件类数据的大小也会有所区别，尤其是项目的立项等文件，可能会比较大，在同步到MDM平台需要处理文件大小的限制。

MDM主数据管理平台围绕主数据的全生命周期管理，通过标准、规范的数据管理流程，确保主数据管理的合规性和高效性。旨在提供统一、标准、高质量的主数据，支撑各业务系统的顺畅运行。

1.体系架构

MDM 主数据管理平台是企业IT架构体系的数据枢纽，遵循“集中管理、分布式应用”原则，串联数据层、服务层、应用层与集成层，实现与内部业务系统、外部第三方系统联动。

MDM主数据管理平台提供全生命周期的数据管理，以及数据模型、数据质量、数据安全、数据集成等数据管控能力，实现主数据的标准化和规范化，建立统一、标准的主数据体系。同时MDM平台通过ESB企业服务总线平台打通上下游系统的服务接口，实现异构系统的数据交互，满足组织、财务、物料、客商等各类主数据的集成需求，保证跨系统主数据的一致性，以支持业务系统间的业务贯穿，满足数据的深度应用需求。

2.功能架构

MDM平台功能架构围绕主数据“全生命周期管理”模式，分主数据管理平台和主数据控制台两大模块以及多个关键功能模块，这些模块相互配合，共同完成主数据管理的全部过程。

主数据管理主要是进行对主数据的申请、变更、校验、审核、归档等全生命周期的管理流程，以及数据清洗、数据质量、巡检、统计等功能。主数据控制台提供数据建模、功能建模、流程建模，以及数据集成、规则定义等相关配置能力。

3.文件存储

由于主数据治理只要针对各系统共享的基础资料进行统一规范，文件类数据也都是主数据的某些属性，不过是以图片、文档等形式存储或查看的，所以对于主数据相关的文件数据一般都比较少或者比较小，存储方式也相对简单。

1.文件服务器：建立统一的文件存储服务器，统一进行文件的管理维护；

2.主数据平台：MDM平台本身支持内部文件的管理维护，可以通过MDM平台直接将文件存储到本地服务器目录中；

3.数据库存储：由于主数据的文件相对单一、文件小，所以可以直接以二进制的方式存储到数据库，在使用时再将二进制转换为文件。

对于主数据而言，文件类数据一般都是作为主数据的附属资料存在，是随着主数据的同步、分发集成而同步传输的，所以在进行主数据集成时，文件往往都是作为主数据内的资料歘传递。根据不同的文件管理策略，文件数据的传递方式也有所不同。

1.文件服务器

统一存储、文件共享：建立企业统一的文件存储服务器，将文件类按照类别统一存储到文件服务器中，实现文件的统一管理与维护。不同的业务系统使用文件时，直接从文件服务器中读取相关文件。

文件服务器是最理想化的文件管理方式，但是需要搭建文件服务器，并且需要建立统一的管理流程和制度，控制好权限策略，保证文件存储、使用的安全。

如果是以文件服务器统一管理文件，由于各个应用使用的是相同的文件，所以在传输时不需要传递文件，主要是传递文件在服务器中的访问地址即可，不同系统使用时根据访问地址获取文件进行展示。

2.主数据平台

本地存储、独立管理：文件服务器是面向企业内部全部系统的统一管理，而主数据平台的文件管理只负责主数据内部，文件数据也是存储在主数据的服务器上（或者通过挂载的方式独立存储），但文件的管理是通过主数据平台统一管理，一般只适用于主数据平台使用的文件，不适合管理外部文件。

由于主数据是独立管理文件的，在和其他系统交互时需要通过接口传输，在传输数据时将文件转换为二进制流进行传递，不同系统接收后再将二进制流处理成文件进行存储和展示。

3.数据库存储

二进制存储、共同管理：相对于文件存储，数据库存储并不建立独立文件，直接将文件以二进制的方式存储到数据库，如果使用可以直接通过二级制传输，或者将二进制转换为文件进行查看。数据库存储无法对文件进行单独管理，一般都是随主数据传递，作为主数据的一个属性进行使用。

和主数据平台管理的传输方式类似，也是以二进制流的方式传输文件数据，不同在于主数据平台在接收和推送时，不需要将二进制流转换成文件，直接传输二进制流即可，至于业务系统可以根据使用需要确定是否转换成文件。

在主数据项目中文件传输常见的问题有两个：一是二进制转换的问题，二是文件大小的问题。

1.二进制转换：主要是通过二进制传输数据时，可能需要进行文件与二进制流的相互转换，不同系统需要统一转换策略，避免由于转换、处理方式的不同导致文件无法解析、乱码等问题；

2.文件大小：在生产环境下，无论是MDM平台还是其他业务系统，部署架构都相对复杂，如果文件比较大（10+M或100+M），可能在传输过程中会出现文件限制的问题。

文件服务器的方式由于传递的是文件的访问地址，所以基本不会涉及文件的处理；二进制转换的问题一般是在同步、分发接口中通过代码进行处理，只要保证上下游系统的处理方式一致就可以；文件大小由于不同系统的产品架构、部署架构不一致，可能会出现多个环节的限制。这次以MDM为例，分析一下文件传输可能存在的关键点。

1.数据链路

以主数据的同步为例，主数据通过源头系统推送，经由ESB的接口写入MDM平台，其中文件数据作为主数据的属性，以二进制的方式进行传输，并且以二进制的方式存储到MySQL数据。根据MDM的部署架构，分析文件数据的传输过程。

1.以源头发起推送开始，源头系统调用ESB对外发布的同步接口推送数据，首先会访问ESB、MDM的统一访问入口Nginx代理，Nginx代理存在对报文大小的限制；

2.讲过Nginx代理后，nginx会将访问信息转向内部，由于MDM和ESB都是采用k8s容器化的部署方式，所以访问信息会转向到k8s内部的代理ingress-nginx（类似Nginx，不过是通过k8s容器管理的），也会存在报文大小的限制；

3.Ingress-nginx会将访问转向到ESB的同步接口，而ESB产品的server也存在报文的限制；

4.在ESB的同步接口中会调用MDM的接收接口推送主数据报文，同样MDM的server也存在报文的限制；

5.MDM接收后会进行数据的转换处理，之后再写入MySQL数据库，而MySQL数据库也存在数据量的限制。

整体链路如下图：

2.Nginx代理

Nginx作为代理服务器，是外部系统访问MDM和ESB的第一层入口，而在Nginx的配置中，主要是client_max_body_size，限制报文大小的关键参数；其次client_body_buffer_size，可以适当调大，以平衡性能和内存，作为内存缓冲区控制，当报文超过client_body_buffer_size限制时，会自动写入临时文件（由 client_body_temp_path 指定）。

3.Ingress容器

Ingress是k8s内部的代理容器，作为和Nginx类似，但是是部署在k8s内部容器中的。由于MDM和ESB部署架构中使用的是ingress-nginx的实现，这也是基于Nginx实现的Ingress，所以配置和Nginx类似，主要是通过proxy-body-size参数限制报文大小，相当于nginx的client_max_body_size，该参数默认值为50MB。

4.应用服务器

MDM和ESB的应用服务器主要是基于tomcat的配置，限制参数主要是server.xml文件中maxPostSize参数，该参数一般都是默认值是2MB（即2097152 字节）。

5.数据库存储

MySQL数据库存在两个限制，一个是字段长度，一个是单次写入数据量。

1.字段长度：MySQL在存储二进制数据时，有两种字段类型，一是blob，而是text，不同在于text是以文本的形式存储二进制数据，支持字符集和排序规则。二者的大小均有限制，都是65535字节（大约64KB），另外还有mediumblob、mediumtext、longblob、longtext等，最大可支持到大约4GB；

2.单次写入数据量：主要是MySQL数据库服务器的限制，通过MySQL配置限制单次事务写入的数据量大小，从而优化MySQL性能。MySQL单次事务允许的数据包大小受max_allowed_packet限制（8.0版本以下默认4MB，8.0默认64MB）；同时InnoDB存储引擎写入blob/text时受innodb 重做日志（redo log）的影响，单次事务写入blob/text时不能超过innodb_log_file_size的10%。

根据以上的分析结果，如果需要传输大文件或报文数据，对应调整以上相关配置和参数即可，根据传输和存储方式的不同，分别调整对应的参数，如果传输二进制报文，主要调整Nginx、Ingress以及应用服务器配置，如果要把二进制存储进数据库，还需要调整数据库配置。

1.Nginx配置

调整外部Nginx的client_max_body_size，可以根据报文大小，将client_max_body_size调整到合适的值。Nginx调整有两种方式，一是直接修改服务器的Nginx配置，二是通过UMC的接入配置调整（Nginx是通过UMC部署的）。

2.Ingress配置

k8s集群的部署和管理主要通过UMC平台进行的，Ingress的配置也是直接在UMC中进行调整，由于ingress的请求是通过外部的Nginx转发的，所以Ingress的proxy-body-size和Nginx的client_max_body_size保持一致即可。

3.应用配置

4.数据库配置

主要调整MySQL的配置文件my.cnf，调整max_allowed_packet、innodb_log_file_size参数，同时考虑增加日志缓存区innodb_log_buffer_size。

注意：

1.innodb_log_file_size为静态参数，修改后必须重启MySQL才能生效，按照官方文档建议：停止MySQL修改配置删除日志文件（ib_logfile0、ib_logfile1）启动MySQL（在部分情况下，不删除日志文件也可以成功启动）；

2.max_allowed_packet可以通过“SET GLOBAL max_allowed_packet”临时设置，或者修改my.cnf后重启MySQL永久生效；

3.innodb_log_buffer_size可以通过“SET GLOBAL innodb_log_buffer_size”保证新连接立即生效，但重启时会从my.cnf重新读取，通过修改my.cnf永久生效。

MDM平台专注于主数据治理的基础平台，主要满足主数据的全生命周期管理，建立主数据治理体系，而在统一的过程中，和上下游系统的交互是主数据非常重要的能力，面对各种不同的业务场景，MDM需要具备灵活的处理方案。

1.问题总结

文件传输是在实际项目中经常遇到的集成场景，在主数据项目中传输文件一般而言还是比较少的，主数据主要解决异构系统基础资料的信息准确性与一致性，更多还是以结构化数据进行交互的。在文件传输的过程中，由于文件的不确定性，很容易出现文件大小受限的问题。在实际项目中需要结合实际情况进行调整，根据不同的存储策略调整相关参数，要注意不要为了方便就把参数调到最大，这样很容易影响整体性能和服务器稳定性。

2.功能总结

对于文件管理而言，采用文件服务器是最合理、有效的方式，通过文件服务器可以实现全部文件的集中化管理，并且有效实现文件的共享，满足各个业务系统使用的需求，并且通过文件服务器，也能保证各个系统使用的文件的统一性。但文件服务器的成本较高，除了需要采购或搭建服务器，还需要维护相关用户、权限的信息。

3.说在最后

MDM主数据管理平台具备灵活性、标准化、集成化的核心特性。通过元数据驱动的模式，以数据建模、功能建模、流程建模为载体，适配不同类型主数据的数据管理需求；通过标准的管理方式和流程，保证主数据在管理过程中的一致性与规范性；MDM结合ESB总线实现异构系统主数据的无缝对接，打破数据孤岛。

对企业而言，通过MDM平台实现主数据治理，提升主数据质量与管理能力，降低IT管理成本，为企业决策、运营优化、数字化转型提供坚实数据基础，助力企业提升核心竞争力，实现可持续发展。

本文由@数通畅联原创，欢迎转发，仅供学习交流使用，引用请注明出处！谢谢~

来源：数通畅联