主数据数据中台

2021-04-07 11:56阅读：

http://blog.sina.cn/dpool/blog/u/2557213547

元数据、主数据也都是数据治理的核心中的核心
记录类数据
什么是事务数据？
事务是数据库的处理数据的一个单元，可以理解为一次数据库CRUD的操作。事务数据就是记录下数据库操作的系统日志数据，以及特定业务场景中，专门记录的业务操作事务记录的数据，比如用于安全审计的系统登录日志。
什么是业务数据？
业务数据就是为了完成业务流程而存储的业务操作类数据。就是业务系统的绝大多数表和数据。
什么是日志数据？
早期的日志数据是属于事务数据中的。现在大数据时代，用户访问数据变得越来越重要，所以单独分离出来。
什么是元数据
元数据（Meta-data）是描述数据的数据。
与业务规则、流程相关的描述性数据，我们称之为业务元数据；
与存储、访问等技术底层的描述性数据，我们称之为技术元数据；
与数据操作相关的描述性数据，我们称之为操作元数据；
与数据管理相关的描述性数据，我们称之为管理元数据。

元数据解决什么核心问题？
如上所述，元数据就是为了准确的描述我们拥有的所有数据。其核心的目的是降低人与数据之间的沟通成本。描述的越准确，我们使用数据的成本就越低。
什么是主数据
主数据（Master Data）就是关于业务实体的数据。主数据是关键业务实体的最权威、最准确、价值最大的数据，用于建立交易闭环。其实Master Data翻译成“核心数据”可能会更合适，因此主数据也被成为“黄金数据”。这么说吧，其实阿里的One ID就是主数据理念的结果。

所以我们总结一下，主数据一共有以下种类：
与人相关的：用户、客户、公民、病人、供应商、学生等；
与物相关的：实体产品、虚拟产品（理财产品）、生产资料（BOM表）等；
与场相关的：地址库、楼盘字典、POI信息等；
与规则相关的：财务的账套等。
什么是参考数据？参考数据就是码表。
因为主数据压根就不是一个一次性的活，它是持续进行的事情，有点像会计记账，得不停的完善。一旦停下不管，就会乱掉。
主数据是关于业务实体的数据，这些实体为业务交易提供关联环境。
我发现这些概念都有一个共同点，就是都不说人话。其实主数据理解起来非常简单，比如你家记账，谁，在那个店里，买了什么东西，一共多少钱。这句话里所有非数值的，都是主数据，买东西的人、卖东西的店、产生交易的商品等等都是主数据。所以主数据就是ER图里的那个实体对应的数据。

主数据建设路径

所有ERP项目建设都要建立主数据。所以建设主数据的第一步，跟你刚看到“主数据”三个字时的感觉一样，是你得知道啥是我们需要管理的主数据，也就是识别主数据了。不同业务的主数据是不一样的，电商的主数据是用户、商家、商品等；ERP的主数据是供应商、物料、客户等。
第二步是规划与设计了。各个主数据怎么来、怎么管、采用哪个标准等等，都得定义好。一般的逻辑是按照国际标准、国家标准、行业标准、地方标准、团体标准、企业标准这个顺序。
之后就是第三步，开始进行主数据建模了。表、字段、约束规则、编码规则、与其他事实的关系等等。这些定好了，主数据的大致模样就有了。前三步都还是准备工作，解决的是“主数据是个啥”的问题，所以可以合并到一个大阶段中。
接下来就得开始整理主数据了。整理的过程又可以分为两小步：数据采集和数据清洗整理（质量控制）。
所以第四步数据采集就是按照规划设计里整理好的数据从哪来的信息，从不同的系统甚至是手填的记录中通过各种手段采集过来。采集的时候必须要注明各种原始信息和填报人，因为这些数据质量堪忧，有任何问题得随时找他们确定清楚。比如贝壳的“楼盘字典”，是专门组件了一个团队去扫楼，然后把扫楼的信息填到系统里的。
第五步数据清洗就是把上面质量堪忧的数据给弄干净，然后按照统一的编码规则给每个唯一的主数据编上合法的代码。这个工作是最恶心的，也是最耗费时间的，我干这种肉眼雷达的事情可是干了不少了。
第四五步解决的是主数据怎么来的问题，第六步就是解决主数据怎么用了。一般来说就是放在主数据管理系统里就行了，其他系统直接对接就OK了。不过像政府等行政单位，也会进行数据公开或者半公开的发布。比如国家标准地址代码库，我就建议各位去国家民政局官网获取，每个月都更新，最细到街道，而且还有增量和全量两种模式，对数据团队非常友好，必须点赞

。
最后一步就是维护了。因为主数据这玩意，实际上是就是一个缓慢变化维。刚才说的国家行政区划代码库，不就是这样么？对于某个地区来说，名称或者代码发生变化是及其偶然的事情，但是对于整个国家来说，发生变化就是必然的。而主数据发生变化，会导致后续一系列的影响，所以得有一个流程去管控这些主数据的变化。

七步建设流程

其实就是上面建设思路的总结。四大步，七小步，四大步分别是：

设计与建模阶段，解答“啥是主数据？”

数据处理阶段，解答“主数据从哪来？”

数据应用分发阶段，解答“怎么用的？”

数据维护阶段，解答“怎么保证一直能用？”

七小步分别是：

主数据识别，圈定并明确当前业务所有主数据；

规划与设计，规划管理标准、流程等内容；

主数据建模，设计表、字段、编码规则、约束规则等内容；

数据采集，通过各种手段采集主数据的数据；

数据清洗，通过各种手段把数据变干净，并赋上合法编码；

主数据应用，通过各种手段让所有业务都应用上这份主数据；

主数据维护，不断的维护，确保主数据的干净和可用性。
主数据的建设工具
其实就是上面几大步骤所用到的excel、word模板了。下载下来照着抄就行。主数据的活不难做，难的就是处理数据，太恶心了！
哦对了，主数据这玩意，在数据中台领域改了个高大上的名字，叫做“OneID”，
内卷化，亦称过密化，当一种文化模式进入到最终的固定状态时，便逐渐局限于自身内部不断进行复杂化的转变，从而再也无法转化为新的文化形态。

2、开源时代
现在的程序员写代码变得比原来的程序员强，因为他们有强大的基础库。
现在MR计算框架和Spark轻松帮你搞定PB级别的数据，更可怕的是你只需要会写SQL就行！刚毕业的学生一个月可能就掌握了基本的海量数据查询功能。
1、Stay Hungry, Stay Foolish
。不管是后端的springboot，前端vue，还是现在的各种大数据计算引擎，作为一线开发者的我们都要时刻保持学习的态度，走出自己的舒适区。
2、工程能力
所谓工程能力，我把它分为这几部分：架构、规范、管理、排错这几个能力。
架构
架构不仅仅是指技术架构，对业务的深度了解也是重要的一部分，要知道整个平台是怎么运转起来的，数据流转的全流程是怎样的，客户的需求是怎样的。
规范
程序员是最讨厌写文档、定规范的，都喜欢自由。但是，很多次生产环境的意外宕机都是缺乏规范引起的，
管理
学会管理同事，让同事更高效的配合自己完成工作，也许某一天你就会成为你旁边同事们的管理者。
排错
程序中日志记录要成为每个工程师的习惯。你多年的工作经验也许并不在于你代码写的快，而是在于你比别人更快的定位问题、解决问题。
3、学会思考

没有思考，我们就会一直工作，一直加班，循环往复。学会思考，我们才能找到高效工作的方法，避免“恶性加班”，才能提高自己的编程能力，而不是提高编程的“熟练度”。
主数据是为解决多系统集成时共享数据的规范标准和一致性等相关问题的，所以出现的较早
直观的看，MDM与数据中台有若干相似的功能，比如数据标准管理、数据模型管理、数据映射管理、数据质量管理、数据推送订阅管理、数据集成管理、数据清洗管理等，如果把主数据做为一类数据纳入数据中台管理，逻辑上看是可以的，不过可能还需要做进一步的探讨。
1. MDM往往是刚需，数据中台不是
信息化建设中系统数量超过3个做集成应用时，就需要考虑对主数据做管理了，而系统数量再多的话，则必须要对主数据管理到位。哪怕是规模不是足够大的企业，应用系统可能也是轻量化的，但只要多系统集成，那么就需要使用MDM或类似功能的系统，这是刚需。而数据中台则适合规模化的应用场景，中台主要是应对业务复杂、多变、交易量大、资源多、整合要求高等问题的，于是抽象出中间的一层，连接灵活的前台和稳定后台，提供更好的随需而动。
特别是数据中台这种较重的系统，需要业务和数据具有一定的规模才能发挥其效能，所以如果企业只是一般的规模和常规信息化需求，中台不一定是刚需，那么主数据管理也就不具备放在数据中台管理的前提了，此时如果打包在数据中台中的主数据功能，因为中台很重（贵），也不容易被一般企业所采用。
2. 分层或有不同
按中台体系的概念，比如ToC的电商系统、各种移动应用等直接面向用户提供服务和价值的系统一般被归为前台，诸如ERP系统、WMS系统、TMS系统等支撑企业核心内在能力运转和管理的系统通常被归为后台，而MDM系统则主要直接服务于ERP等后台系统，所以常规来看，MDM至少是后台系统，而非中台，甚至现在基本上会把MDM再降一层，与企业服务总线ESB等系统一起归为应用信息系统的基础设施。此时，数据中台如果提供MDM的功能，相当于成为了后台甚至再基础一层的系统了，这样或与数据中台定位中间一层的应用分层不相符，感觉有点用乱了。
3. 数据的输入和整合
MDM通常会作为主数据的输入系统或控制系统，比如MDM中有针对物料主数据录入特点的、更聚焦的一系列录入、校验等功能，再比如或许在采购管理系统中录入物料主数据，但物料主数据会在MDM的规则控制下传入到MDM中并分发给相关系统，总得来说MDM是一个常见的面向一线用户的数据输入系统。
而数据中台，通常更强调对多个异构系统数据的高级整合，即从很多个异构系统中获得各种各样的数据（比如在数据中台受控下数据传入数据湖中），然后按需求做各种深度处理（按算法做计算、汇总等），并把结果以服务的形式提供给前台系统。并非是数据中台不能录入数据，但把录入数据的职能放在数据中台系统上，特别还是主数据这种通常较大数量的数据，感觉与整合这个数据中台的核心功能之一或有不一致。况且，一旦让大量一线业务用户录入数据了，那么系统就变成了前台系统，也与数据中台定位为中间一层的分层不太相符。
4. 现阶段针对主数据的应用需求，MDM实用性更好
数据中台的建设，往往也不是信息化（数字化转型）前几个阶段的内容，一般是建设到一定阶段，或者系统按中台概念重构时才有的，而MDM则基本是与早期的、常规的ERP等系统建设同一阶段做的。
我个人认为，现阶段把主数据管理纳入到数据中台或许存在一些可商榷的问题，并且因为目前我注意到的数据中台产品也没有主数据管理功能落地（或许是我了解不充分），所以在没有看到数据中台中主数据应用的案例前，常规情况下我还是比较倾向于MDM与数据中台分为不同的系统进行建设，

针对传统行业数字化转型做了很多高举高打的规划，但亲身经历之后才觉得：转型还得靠真正能理解传统行业的人，而非互联网圈儿的“天外飞仙、降维打击”

“数字化转型仅仅是把过去线下的事务都搬到线上么？”线上化是帮助我们更好更全的获取信息，但绝对不是简单粗暴的扼杀原本信息量丰富且高价值的线下场景。有很多行业，撮合交易的重点就是靠个性化、专业化的线下服务，比如保险、房屋买卖、婚恋介绍，它们的共性就是产品的复杂性和非标准化。我们更应该琢磨如何通过科技手段，提升原有线下场景的效率，而非一味的干掉它们

“阻碍传统行业公司数字化转型的关键到底是什么？”是强迫一线代理人上报数据？还是提供一个工具、在帮助他们解决问题的同时顺带收集数据？

是强调总部的中枢定位，一切决策都必须自上而下的发自总部？还是适当的下方权利和责任，激活机构分公司的创新力，改善信息的流动方向？

现在可以引入主数据这个概念了，在应用层面讲，主数据（ Master Data ）是在多系统集成应用的背景下，被多个信息系统（或功能模块）共用的基础性标准化的数据，常见的主数据包括：供应商、客户、物料、人员、部门、项目等。
主数据管理系统（Master Data Management，即MDM）这类软
对常规的终端用户而言，MDM的核心功能主要有三个方面：

保障主数据的规范性和唯一性。
主数据的集中管理。
主数据的自动分发。

除去以上功能外，MDM其实还有很多相关的专业性功能，比如：元数据、接口适配、数据交互监控、界面和流程定义、数据清洗等。这些都是系统建设和运维人员的工作内容。
因为MDM很重要并且很常用，相关的产品就比较多。
总的来说，MDM产品的可配置性越强越好，尽量减少代码开发，减少每个MDM项目的个性化，这样的MDM相对更稳定、更通用，上线时间更短，更易运维和扩展。同时，因为主数据的数据量往往很大，那么MDM对数据的处理性能也很关键，要能满足大规模数据量的处理要求。此外，MDM系统中内置的标准编码也是一个很大的价值点，比如已内置某行业的物料分类编码表（可能数万条数据），那么在实施该行业的主数据项目时就会更有力。
而关于MDM系统建设项目，需要格外说明一下，项目中系统建设本身只是一个部分，而且技术方面较为常规。更为重要的是对主数据分类、各种规则等内容的梳理和设计，这一点往往才是MDM项目最有挑战的地方，需要投入大量的财力、人力和时间，需引起高度重视。
刚才讲的是常规主数据的范畴（即系统与系统之间的），而比如SAP ERP系统内部，也有主数据的概念，首先这种主数据的重要特征也是被多个地方共用，只是这里突出的是在ERP系统内部被多个模块的共用（也可以通过MDM被外部共用）。而类似于SAP ERP内部的主数据，除了唯一性、共用性等特性之外，这种主数据往往是承载了某类业务的关键内容，以主数据为工作对象，相关业务要通过对主数据的操作完成处理。典型的，会计科目就是财务总账模块的主数据，科目主数据除了常规的科目编码和名称外，还有很多个属性，比如是资产或是负债还是损益类科目，比如科目货币是什么，比如是否允许手工过账，等等。这些属性将决定会计科目在相关业务下过账的行为（比如体现对应收应付的不同要求）和记账结果（比如按本位币还是外币更新余额表）。
再比如SAP ERP中的物料主数据，因为物料将被采购、库存、生产、销售等多个模块共用，并且各个模块之间还有业务逻辑关系，所以物料主数据承载的操作内容很多，使得相关属性也多，在维护物料主数据时需要填写的内容就显得比较多了。

说明：SAP ERP物料主数据在某物料类型下有15个页签，每个页签下又有若干个属性
（还减少了采购ERP系统授权的数量，MDM用户授权的价格通常比ERP的低很多很多）。
如下图，用户只需要填写界面中的内容，而不用在SAP ERP的多个页签中挑选需要填写的内容，一定程度上改善了物料输入的工作体验。
比如人员的国籍、出生地、政治面貌、婚姻状况等这些内容，在人力资源管理中是重要的，而在其他系统中则基本很少用到，但是，职务可以在报销系统中用于做报销额度的判断，部门可以被报销系统用来通过部门主数据来确定人员默认的成本中心，开户行和银行账号信息可以被报销系统赋值到付款指令中进而通过银企直联完成线上支付，……。进一步，报销系统完成报销处理后，需要把财务凭证推送给ERP系统的总账模块，那么ERP系统中的财务数据，使用的也是人员主数据的相关信息，比如人员所属部门对应的成本中心，通过主数据管理，费控系统和ERP系统中使用同样编码的成本中心，此外，如果人力系统直接向ERP系统推送薪酬、保险类财务凭证，使用的也是同样的成本中心编码，即所有系统在成本中心数据上口径是完全一致的。对上述示例总结起来，应用系统希望通过主数据来实现什么呢？我认为主要包括如下三点：
第一点最重要的肯定是多个系统引用数据的唯一性和标准性，比如成本中心，各个系统用的是一套成本中心，比如人员和部门主数据，在报销系统和ERP系统中，以及源头的人力资源系统中，都是一致的，上一篇文章中提到的供应商也是，一个供应商主数据在所有的系统中都是同一个。
第二点是主数据的内容要被用来做条件判断，比如职务，假如司龄也需要作为判断条件，那么司龄或者入司时间也可以作为人员主数据的内容之一。
第三点是主数据的内容要被用来做赋值，比如上例中的人员银行信息，比如统一的供应商编码要被赋值给采购订单、被赋值给记账凭证……，又比如其他系统可以根据人员主数据的内容创建自己系统的用户或者人员表，那工号、姓名、部门等内容肯定都是需要的。
第一个结论，对集成在一起的多个相关应用系统来说，在主数据唯一性和标准性的基础上，主数据功能性的核心价值不在于查询、统计和分析，主数据的核心价值在于帮助应用系统实现关键性的判断或者赋值，即应用系统通过主数据一定要完成一个有实质意义的功能性处理。
第二个结论，主数据基本都是业务实体数据的一个子集（比如上例中部门主数据是由人力资源系统部门数据20个字段中的6个字段构成的），至于业务数据中的哪些内容（字段）要纳入到主数据中？则按第一个结论判断，即只有被多个应用系统用来做判断或者赋值的内容才需要纳入主数据范围管理，无此类功能的内容不需要纳入主数据管理。

参考数据
参考数据是数据（字段）的取值范围及解释，例如：性别（男代码10、女代码20）、国家（中国CN、美国US、厄瓜多尔EC、安哥拉AO、……）、学位（3博士、2硕士、1学士、0无）、等，直观理解的话，参考数据就是很多系统中的数据字典（如图3），只是在企业级应用中，这种数据字典需要被统一标准化，这样多个系统间数据的口径才是一致的。
很多资料
本身这两者的维度是不一样的，参考数据可以理解为针对的是字段，是数据的某字段在企业级应用层面下多系统统一口径下规范的取值范围，参考数据只是数据中某个字段的可选值范围和解释，只是字段的一些值，参考数据（即数据字典）往往只有两列（代码和名称，如图4的代码和学历），有时甚至只有1列，数据量或许比较大，但结构简单；而主数据则是一条完整的数据，并且是业务的实体数据（或者是业务实体数据的一个子集），数据内容较多较复杂（拥有若干个不同类型的字段）。
参考数据相对是静态的，比如国家地区、学历等等，这些数据基本很少有变化，所以可以在各系统上线时一次性的配置到系统中（即数据字典或者编码表），后续也很少需要维护；而主数据通常是业务实体数据的一部分，所以是动态的，随着业务增加或变化，比如人员有入职、离职、升职、调动等，相应的人员主数据就要增加和修改，还有物料、供应商、客户、成本中心等，会越来越多。

举报/Report

我的更多文章

下载客户端阅读体验更佳