还是一个数据质量的问题,这是我们这些做数据处理的人都经常面对的问题。不知道是不是国外的业务系统已经很完善。就目前接触的系统而言,个人感觉有以下几点:
1.业务系统创建初期可能没有想到有一天要做BI这样的事情,或者有先知先觉已经想到了,起初系统设计的很完善,可是中间发生人员转换,业务变更等情况,还是会出现基于对业务理解及编程习惯等原因造成的一些差异性问题。
2.业务系统也要面临一个不断升级的过程,这升级有可能是因为漏洞的原因,当漏洞存在的时候,可能是系统操作人员误操作,也可能是恶意用户故意所为等原因,已经为数据质量埋下了隐患。
3.在所有的数据变更,系统变更等情况发生的时候,没有考虑到将来的整合,缺乏历史记录,导致后期整合困难。
4.多数据源整合,特别是非结构化数据的采集,动辄几万、几十万甚至更多的数据,需要对其结构,重复性,合理性进行判断,这本身就是一个从数据中寻找规律的过程,而且由于当前各种技术及厂商此起彼伏,有时候因为自身信息的缺乏,没有明确的规则。
。。。
等等这些原因。导致数据质量一直是困扰我们的一个问题。处理过程中,数据的差异性问题,客户对数据质量的怀疑导致对最终系统及分析结果的怀疑。当前一直是采取不断去完善的做法。应了那句数据仓库是一个不断完善的过程。可是这里面又有很多是需要手工处理的。麻烦又浪费时间。
看了兄弟你不辞辛劳翻译过来的ORACLE MDM资料之后。有如下疑问:
以资料里的例子为例:
1.在准备用ORACLE的MDM之前,Mary Smith已经更名为Mary Evans,并且当时没有留下变更记录,系统中关于本是一个人的这两个名字各有各的记录,如果统一其属性并合并为一个人。基于文中的3112/Day发生更名活动,如果系统已经运行一年,那么这将是个多么庞大的数据,如何来将这些变更应用到MDM中。
2.假设如果两年前有一家The Gaps临售商通过Old Navy销售VN-Sweater,后来可能因为一些原因,Old Navy更名为Banana Republic,并搬迁了地址修改了电话等其他注册信息,但是在The Gaps内部仍称其为Old Navy。(觉得没有表述清楚啊)。或者说,确定本来是一个客户的那些关键信息如何制定。按照文内的统计,发生公司更名,换址的数据也不是小数。
3.两中毛衣本是同一产品,只是型号不同,可是假如起初是两个录入员录入系统,毛衣属性填写格式有差异,那么这个统一的过程也是很麻烦的吧。
。。。
等等这些。
说起来实际上这个还是一个理想了的东西,如果是从一个刚起步的系统来进行这种整合,并严格按照正确的理论来行进,那自然能很好的实现这些功能,但是我们更多的时候,是后来进入公司,系统已经跑了很久了,或者不是给自己做,而是基于别人的系统做一些事情,那数据质量就更是一个麻烦了。
当然,如果花时间对已有系统进行彻底的整理,一点一点的制定规则也是可以的,但是又面临:
1.这些规则是需要人工制定的。耗时很大。
2.需要对公司整个运维的一个很好的熟悉。
所以,更多时候,我们都还是在亡羊补牢,通过数据稽核,测试等等这些手段来尽量确保数据的高质量。
如果有机会可以听到ORACLE过来的MDM培训,希望可以听听对于上面的问题,是否有什么好的办法。
呵呵,或者,是我们这里还比较落后,大家已经有好的办法了。也不妨给讲讲。兄弟先谢过了!
穿越地震带 纪念汶川地震一周年