EII的难处

就当我们在为数据仓库的架构争论时，其他的技术也悄悄地进村。企业信息整合，EII，这玩意儿怎么看怎么虚。但这一两个月，在业界有了一些小动作。BO、IBM、MicroStrategy等，都通过并购充实自己的EII产品。想到这两个厂家在BI方面的野心都不小，也不得不怀疑不久的将来，他们就要大力忽悠这个玩意儿了。BO买了Medience，一个法国的小EII产品，五月份的事情。IBM买了什么产品忘了，只是印象当中有这么回事，似乎也是四五月份的事情。
 
通俗一点地将EII称呼一下，可以是分布式查询、透明查询、虚拟数据仓库等等，这些称呼形象的多。反正我是没有领会为什么叫做"信息"整合，无非就是和EAI、ETL区别一下而已。
 
用类比的手法形容一下吧，可以通过企业供应链来。
 
以往的采购，讲究库存。现在不是有零库存的说法吗？一位亲戚说去参观涂料厂，在这个厂周围全部是其他的原料生产厂，因此他家的管道直接伸到原料厂的仓库里面。有了订单，就提取原料生产。当时我想，他们的IT系统必须得能够整合的起来吧，不然一边说用了一吨原料，一边说用了两吨，岂不是扯皮。
 
EII也就像这种零库存的供应方式。而ETL，就是传统的有库存方式，数据就是原料，是货物。将这些东西采集到仓库里面放着，然后再加工，再提取到集市上去卖。
 
在国内，基本上没有见过的EII的案例，但有这样的需求。例如曾经有客户就提出"透明查询"这个名词，其实是跟EII道理一样的。"不管从那个数据库取数据，反正写一条SQL语句就能够得到数据"。若干年前，和朋友头脑风暴的时候，也想到类似这样的东东，"能不能设计一个同时从Oracle、DB2、SQLServer取数据的小工具？"，那时根本就没听说过EII的概念。去年，接触了一位研发产品的朋友，他设计出一个叫做SQLHub的东西，也是如此。基于异构的、分布的数据源，写简单的SQL就可以查询。
 
考虑怎么实现，思路也有。用元数据来描述各种数据源，什么库，哪些表，哪些主键等等；设计分布式查询，对sql语句进行解析，针对不同数据库的部分形成新的sql语句提交到具体数据库中；建立临时数据区域，放置查询中间结果；对这些中间结果进行关联，得到最终结果集，返回。哈，小菜一碟。
 
做一个小工具，不是太难的事情。可以假设一些条件，例如不同数据源的编码是统一的，或者说数据是一致的。可实际情况往往有不是这样，不同来源的数据千差万别，总是出乎人的意料。比如上面举出来的实现步骤中，用元数据来描述数据源结构吧。设计一个结构不难，可当数据源的结构发生变更了怎么办？因为不同开发商，或者缺乏变更管理的原因，变更根本反应不到元数据中。最终，恐怕只有原来可以正常运行的透明查询突然不行了，去查原因，几番电话之后，才发现，某月某日，表的名称改了。
 
如此看来，将数据提取出来，放到一个仓库里面放着，这是比较明智的做法，至少目前是如此。

微信扫一扫实时了解行业动态

微信扫一扫分享本文给好友