企业信息化中元数据 主数据 企业服务总线的探讨

3年前

元数据、主数据、ESB、DI,企业信息化中有很多的概念,理解这些概念,必须对企业信息化面临的问题讲起,才能够深刻理解。很多概念都是老外创造的,在佩服老外归纳总结能力的同时,我们也必须保证自己不被别人忽悠了。这里,我先把存在的问题,对这些问题的解决方案说清楚,同样不追求准确,而是追求把道理讲清楚。

问题的提出:


元数据、主数据、ESB、DI,企业信息化中有很多的概念,理解这些概念,必须对企业信息化面临的问题讲起,才能够深刻理解。很多概念都是老外创造的,在佩服老外归纳总结能力的同时,我们也必须保证自己不被别人忽悠了。这里,我先把存在的问题,对这些问题的解决方案说清楚,同样不追求准确,而是追求把道理讲清楚。

元数据、主数据、ESB、DI相关的问题,主要是在企业业务集成业务中发生的,主要解决数据分布后带来的数据不一致、不准确问题,我会分为几个主题分别阐述:


为什么企业信息化会采用分布式的数据架构,而分布式必然会造成数据不一致或者不准确?

数据不一致、不准确的主要现象是什么?

解决上述问题的主要方法是什么?

普元产品中应该如何更好的支持上述方法,如何进行项目实施?


一、为什么企业信息化中数据必然是分布式的


在企业信息化中,很多相同的数据经常散布在不同系统中,必须在多个系统间保证一致,例如我们经常遇到的就是组织机构、用户等信息,也就是我们用ABFrame、CoFrame维护的这些信息。大家可以设想:


1、 如果在建设业务系统的时候每个系统都自己用CoFrame实现这个功能,就出现了多份组织机构信息,就可能出现数据不一致、不准确的问题。

2、 为了解决这一问题,简单的做法就是在各个系统之间做数据的同步,包括实时的同步、晚上批量的同步,这种事情,我们在很多客户的实施过程中,都对 ABFrame做过类似的改造或者扩展

3、 既然要做数据同步,一般来说就要以一个中心系统为准,例如在银行中都有统一认证的系统,他的用户信息是从HR系统每晚同步过来,其他系统实时访问统一认证,或者晚上把数据同步过来

4、 大家可能说,如果我在 IT 系统建设开始时,就做了这个统一认证系统,其他系统实时调用,不就避免了数据同步的麻烦吗?想法很好,其实很难实现,为什么呢:


  1. 例如某个系统是外购系统,它本身就已经有这个数据维护的功能,这种情况无法避免
  2. 其次,很多系统为了提高性能,在自身做了数据的缓存,就必须做组织机构数据的同步


这里,我们已经知道了,由于各种原因,企业各系统的数据是分布式的,系统之间进行数据共享有两种方式,实时数据调用和批量数据同步。


二、由于分布式数据引起的数据不一致、不准确问题表象是什么?


在以数据共享为目标的业务集成中,遇到的最大问题就是数据不一致和不准确,这里我举几个例子:


1、 某系统组织机构的机构代码是8位,另一系统的机构代码是16位,在数据同步的时候就会出现无法同步的问题;

2、 如果是同一个机构,某个系统里面编码是 0001,另一个系统里是0002,其实是一个东东。别笑,我们自己的工时系统和我们自己的ERP系统之间,就曾经出现这一问题

3、 一个系统0是男、1是女、2是未知,另一个系统M是男、F是女,这是一个代码不一致问题

4、 更麻烦的是,说好了0、1、2,实际数据交换的时候传来一个5,不知道该如何处理。

5、 在我们公司内部,合同由商务部门整理,导出Excel后发给售后、财务、法务分头根据自己的需要再次加工,一旦商务部门修改,数据就可能不同步,再分头修改成本很高

6、 某企业客户信息在财务、CRM中分别维护,造成数据不一致,例如有名称为“普元”的客户,有名称为“普元软件”的客户,不知道是否是一个客户

7、 一个人的名字叫 焦烈焱vvvvvvvvvvvvvvv,明显是Ctrl-C Ctrl-V 的时候松手了

8、 区域是中国,结果电话号码不是以 86 或者 0 开头

上述问题,给企业信息化带来了极大的挑战,这个挑战主要出现在企业业务集成的时候,大家可以理解一下这个困惑。


三、解决数据不一致、不准确问题的方法是什么?


为了解决这一问题,手段无非是几种:


1、 梳理、建立数据标准


什么是数据标准,给大家看一个数据标准的描述


有了数据标准,就为企业各种主题数据建立了统一描述,理论上,企业中每个系统只要有这样的主题数据就要用这样的方式存储,每一个系统对外提供接口的时候,只要涉及这样的主题数据就要使用这样格式的报文。

有了数据标准,上述问题中各系统之间字段存储格式不一致、各系统之间业务编码不一致的问题就有了依据。


  • 何使用数据标准,进行数据交换(无论实时还是非实时)


例如王博士提出的问题,“…在上海移动实施的情况来看,对于服务 接口描述的现状只到每个接口输入、输出、异常的每个字段类型以及业务含义。(接口连调的适 合还是需要问后端业务系统的相关人员填什么参数合适)…但缺少的是每个字段的业务数据字典”,这里的业务数据字典,就是数据标准。有了数据标准,在ESB实施时,对各个接入系统进行梳理就方便了很多,每一个报文项(类似字段)都可以和数据标准对应,就知道了该报文的业务含义、技术特征、效验规则等等。


非实时的数据交换也是可以利用数据标准的,需要说明几个问题:

i. 如果在数据交换实施时,没有企业数据标准,那就需要在项目中自己建立起来,这样可以让项目实施更容易

ii. 一般在项目实施时,都会用 Excel 的方式整理接口,把Excel导入到 Studio,这样更方便,有兴趣可以了解交行卡中心大运营平台和兴业卡中心BDP项目

iii. 如果业务代码不一致(例如上述的性别),数据标准就是一个中间格式,ESB、ETL、DI可以根据中间格式,在不同系统间做报文的转换,让集成代码开发更便利



  • 如何根据数据标准,发现数据质量问题



数据质量很头疼,上述例子中1、4、7、8都有数据质量问题存在(这里插一嘴,大家可能会问,焦烈焱vvvvvvvvvvv 这样的问题,我只要在输入的时候控制一下,不就不会出现了吗?实际上,企业很多数据来自文件导入,例如银行代发工资,就是各企业通过文件报过来数据,很多文件里的数据就有问题,不是系统能控制了的)。


有了数据标准,ESB在进行数据转换的时候,就可以将不符合数据标准的报文记录下来,同样在DI或者ETL过程中,也可以对数据质量问题做记录,也可以对系统做主动检核,记录数据质量问题,数据质量管理系统根据这些记录对各系统数据质量问题进行记录和跟踪,为IT治理提供了一个很好的跟踪手段。注意,数据质量系统象 BUG 系统一样,既不发现问题,业务解决问题,就是一个记录问题的工具,王博士在问题中也提出,ESB、DI、ETL都应该成为全面数据质量管理的手段,这就上升到数据治理的高度了。以前,这个概念做数据类应用讲的比较多,做交易应用或者ESB的人讲的少。普元是国内少数在数据、交易领域都有涉足的公司,我们的体会会更加全面一些。


从上述数据标准解决的问题看,实施数据标准过程中提出了下述要求



  • 管理数据标准


很多银行为了梳理数据标准,都进行了咨询,咨询的结果就是形成了几本厚厚的手册(想了解的可以找王轩),手册的使用很不方便,就做一个系统管理起来。同时,数据标准的维护(增删插改)都是有管理流程的,数据标准的系统也包含了这些管理流程。



  • 在数据存储模型设计、报文定义中使用数据标准


说直白点就是在设计数据库表的时候,每个字段的数据类型定义都来自数据标准,这些字段类型都是有业务含义的,而不是仅仅是技术上的类型。如果数据标准中没有定义,就要补充进去。在做报文定义的时候也是如此,每一个报文项都来自与数据标准


需要特别说明的是,如果没有数据标准,也要按这种模式进行项目实施,只不过自己管理数据标准而已。



  • 利用数据标准,在数据交换时进行数据格式转换


例如上述性别的业务字典码,ESB就需要在接收报文后自动根据不同系统的定义进行转换,DI/ETL 也是同理



  • 利用数据标准,进行数据质量检查


ESB、DI、ETL都可以在数据交换时对报文或者批量数据进行质量检查,不合格的记录下来,由数据质量系统进行统一采集,并通过数据质量系统发起管理流程,进行数据质量问题的催办



  • 在集成类项目中,最好利用 Excel进行需求的分析和整理,再导入到工具中一降低实施的成本



2、 管理企业的元数据


上面讲了数据标准,其实整理出标准很难落地,所以就需要有系统来支撑。实际上,这个系统不仅仅支持、管理数据标准,而是对企业所有软件资产进行管理,例如企业有多少系统、多少接口、多少数据库表、多少数据标准。。。,这个系统就是我们说的元数据。由于过去,交易、数据、ESB等都分开看元数据这件事情,就有SSM、数据资源管理等不同领域的元数据。工行做的比较好,把所有的都统一起来管理。这就是元数据,就是RR,就是企业软件资产管理,大家可以对应一下,目前数据治理平台的元数据、ESB 的SSM、DI的元数据、运维的CMDB,应该都是元数据的一部分,试想我们如果能将这些元数据统一管理,并且能够做到互相之间的关联应用,对企业信息化的IT治理将是一个巨大的提高。


统一的元数据管理是企业信息化的高级阶段,有能力实施的企业少之又少,但是这种思路是我们每一个产品中必须具备的思路,每个产品内部都应该有一个元数据的管理能力,未来这些能力应该考虑快速的实施对接。


建立企业元数据库(也就是RR),是一个摸家底的行动,从上述要求看,有如下需求:



  • 对企业元数据进行统一管理,能够进行血统分析和影响度分析,当发生变更时通知相关人
  • 既然是摸家底行为,最好能够根据代码自动采集,提高自动化程度;
  • 针对元模型的千差万别,最好有统一、可扩展的存储模型,以便新增一种模型种类,不要在增加存储表也能够灵活支持
  • 在上线之前,最好提供线上情况、测试环境情况、设计要求的对比,以便评估实施的正确性
  • 元数据的变更要有管理流程
  • 每个产品中都应该有元数据定义能力



3、 管理企业的主数据


这里就要说说什么是主数据了,把前面的问题再看一下:


  • 同一个机构,某个系统里面编码是 0001,另一个系统里是0002
  • 某企业客户信息在财务、CRM中分别维护,造成数据不一致,例如有名称为“普元”的客户,有名称为“普元软件”的客户,不知道是否是一个客户


这些都是主数据问题,什么是主数据呢?下面这张图描述的比较清楚。



一般来说,主数据是企业运营的核心数据,和时间的关联性不大,产品、客户、账户、人员、组织/机构、物料编码这些都是主数据,订单、合同、交易这些就不是主数据。当然,每个行业说的主数据都不一样,但遇到的问题是相同的。


一般来说,解决主数据问题比较简单的方式就是以某个系统为准,其他系统与这个系统同步。高级阶段就是建立一个主数据平台,所有系统的主数据以主数据平台为准,支持实时数据访问和批量数据同步。


说起来简单,我给大家举一个复杂的例子,还是以客户信息这个示例,客户信息无疑是个主数据,但是由于历史建设的原因,CRM系统、财务系统都分别进行客户信息维护,其中CRM系统维护的客户信息有20个字段,财务系统维护的客户信息有30个字段,其中有10个是重合的,其他不重复,这个时候怎么做同步?


  • 首先确定客户主数据以 CRM 系统为准,以后再新建系统都以CRM为准;
  • 其次,当CRM、财务系统更新客户信息的时候,都必须向对方进行同步,同步有实时同步和批量同步两种;
  • 最后,实时同步可以在原有系统内加触发器,客户信息修改时将变化移入一个临时表,定时扫描这个临时表,将数据批量同步到其他系统,也可以改造原系统,当修改客户信息成功时发出消息。还有一种做法就是直接定时扫描客户信息表,将变化量同步,这就要求客户信息表有一个类似更新时间这样的字段做标识。


如果某项主数据的维护散布在多个系统,就应该针对这个主数据,建立统一的主数据平台,改点对点到HUB方式,减少维护同步的工作量。


可以看出,不论怎么做,主数据的同步都是脏活累活,我们只能根据经验知道大概有哪些是主数据,主数据有哪些属性,同步主数据有哪些模式,工作量是很大的,另外,主数据的实施需要很多部门配合完成,因此很多企业的主数据实施都是一把手工程。我们产品中能做的,就是将主数据管理中共性的东西抽象出来。


我一个朋友李冬当年写的 Blog ,其中对企业数据的分类,什么是主数据,都有很到位的描述:http://blog.csdn.net/woohooli/article/details/3726040


针对主数据管理的特点,需要提供如下的能力:


  • 无论独立部署主数据服务,还是以某特定系统作为主数据宿主,都需要通过 ESB,将实时主数据服务暴露出来、管理起来
  • 如果能够很方便的将宿主系统的数据,通过配置方式产生主数据服务,对主数据服务的实施帮助很大
  • 主数据除了提供实时服务之外,还要提供批量更新的能力,也就是 DI或者ETL的能力
  • 主数据宿主和其他系统进行数据更新的时候,必然进行数据监听、数据转换等过程,主数据系统必须将这些行为管理起来,让管理人员能够一目了然的看到宿主系统与其他系统之间的关系,集中对监听、事件、转换等行为进行统一管理
  • 建立不同系统主数据之间的映射关系,例如在A系统中0001等于B系统的0002,其他应用可以利用这一映射关系进行数据转换
  • 需要消息系统做事件发布与监听
  • 需要作业调度来管理批量作业,因为很多作业任务是有先后关系的,而且作业会很多
  • 主数据宿主系统中数据存储的模式,多采用拉链表的方式,例如客户信息中有客户地址,客户地址在每个时间段都是不一样的,因此每次对客户资料的更新都必须将原有信息保存下来,注明生效时间、失效时间。这种模式,也是针对不经常变化数据的设计方法。
  • 需要对主数据的增删插改增加审批等管理行为



四、我们的产品应该如何帮助客户解决数据不一致、不准确的问题?


这个问题我想先留给大家思考一下,希望你们在回答这个问题的时候,能够考虑到公司所有相关产品

COMMENTS

需要 后方可回复
如果没有账号可以 一个帐号。