Oracle 数据仓库和数据集市的异同

BI领域始终存在着建设数据仓库还是建设数据集市、自上而下还是自下而上的争论，而在实际建设中，自然不会有人完全按照某种理念去做，比如在电信公司的数据集市建设中，地市公司的特殊情况与总部规范之间的博弈就成了一大难题。 　　

深入探讨数据仓库和数据集市的异同

　　这篇论坛文章（赛迪网技术社区）深入探讨了数据仓库和数据集市的异同之处，更多内容请参考下文： 

BI领域始终存在着建设数据仓库还是建设数据集市、自上而下还是自下而上的争论，而在实际建设中，自然不会有人完全按照某种理念去做，比如在电信公司的数据集市建设中，地市公司的特殊情况与总部规范之间的博弈就成了一大难题。 

自上而下 VS自下而上

刚进入BI领域的时候，感觉到处都在说、都在做“数据仓库”，而现在，很多地方又开始说建设“数据集市”了。只是，如何对数据仓库和数据集市两者做出一个明晰的区分，却始终是个问题。 

从字义上看， “仓库”可以想像成一所大房子，高高的货架，合理的出入路线，是一种集中存储货物的地方，一般顾客是不来参观访问的； 而说到“集市”，就容易联想到空旷的场地，川流不息，大小商户摆出摊子，卖衣物的、卖烧饼及卖艺的，是让顾客来消费的地方。具体来说，数据仓库仅仅是提供存储的，提供一种面向数据管理的服务，不面向最终分析用户；而数据集市是面向分析应用的，面向最终用户。 

　 　如此理解比较简易，但是用这样的比喻来定义数据仓库和数据集市之间的区别却未免过于浅陋。比如数据仓库也可以被直接访问，而数据集市也提供存储，而且这 样区分似乎就表明，数据仓库和集市必须都存在才能为最终用户所用。事实则并非如此。那么，这样看起来，它们的区别似乎仅在于规模大小不同了。但如此一来， 又有问题了，比如多大才算大，多小才算小呢？这也得相对而言，譬如电信公司的数据集市恐怕就比一个玩具厂的数据仓库大出几千倍。 

其实，换个角度来看的话，这两者之间的区别正是自上而下和自下而上辩论的产物，也就是Inmon和Kimball两派在产品应用中的具体体现。 

理想的“自上而下”，即一个企业建立唯一的数据中心，就像一个数据的仓库，其中数据是经过整合、经过清洗、去掉脏数据的、标准的，能够提供统一的视图。 要建立这样的数据仓库，并不从它需要支持那些应用入手，而是要从整个企业的环境入手，分析其中的概念，应该有什么样的数据，达成概念完整性。理想状况下， 数据仓库建成以后，因为数据是标准的，没有太多冗余，数据质量得以保证。因此，报表、OLAP以及其他任何统计分析应用都可以从中获取需要的数据。然而， 这仅仅是理想，多少有点形而上的做法，有些过于追求事物的本质。 

而“自下而上”的做法，则是强调应用决定数据，有什么应用就获取什 么数据。理想状况下，一项分析应用只需要刚刚好的数据。例如人力资源部门的数据集市，就不需要市场推广的数据，那么这些数据将不被纳入该集市中。很明显， 这也是理想化的，因为需求是不断变化的，今天人力资源可能不需要市场推广数据，但是如果哪一天需要分析员工做市场推广的成本收益，恐怕就需要这些数据 了。 

当然，在实际项目的建设过程中，谁都不会傻呵呵地完全按照绝对的自上而下或是自下而上的方法去做。 

就国 外成熟数据仓库厂商的理念而言，大多是以自上而下为主，采用Bill Inmon的方法，先建立一套完美的EDW（企业数据仓库），并且他们通常针对行业 已经设计出抽象程度比较高的概念模型，可以根据实际环境生成逻辑模型和物理模型。在构建完美的数据仓库的时候，设计者会考虑最终有哪些应用，根据应用做取 舍。一般来说，数据仓库是分阶段的，譬如第一阶段主要服务于市场部门作市场分析，那么，建设者就很可能“偷工减料”，像员工信息、财务数据反正也没人用， 便舍弃它们。由此，一套完美的EDW真正落实下来，往往因为受到项目周期、人员经验所限，最终会变得面目全非。 

与国外相反，国内集 成商的做法大多是自下而上。其中一部分原因在于周期和人员的原因，老板要求尽快上线，客户要求尽快看到结果，而这个时候恰好就是Kimball方法的用武 之地。建设者会针对应用快速建立数据仓库（注意，这里仍然叫做数据仓库，似乎大家也不愿意叫做数据集市，可能那样显得有些小气吧）。实际上，如果比较采用 两种不同理念完成的第一版本，我们会发现，这两种交付版本竟是如此相像。 

数据集市的建设难题 

从前几年电信行业的经营分析系统建设可以看出来：无论移动或是联通，都不会将经营分析系统称为是数据集市系统。可在一开始，这些系统恐怕都仅仅是服务于少数部门的。 

几年前，中国移动开始在全国少数几个地市开始数据集市的试点，这才算真正有了个“数据集市”项目。之所以有这种项目，是因为经营分析系统不能满足地市公司分析的需要。当然，也不排除厂商、集成商在其中煽风点火的作用。 

其实，这对移动公司来说，几乎可以算是一件很令人恼火的事情了！本来，建了几年的数据仓库，是要将数据集中起来，提供分析功能、辅助决策。可后来却发 现，数据量太大不说，地市公司人员访问也不方便，甚至还绕开数据仓库，直接去生产系统里面取数据。此时，原来忽悠数据仓库的那批厂商集成商又上门，开始忽 悠起数据集市了。三年前，他们说，“数据要集中，提供唯一的数据视图”，三年后，他们又讲，“数据要分布，便于用户的访问”。 

那 么，到底该怎么看这个问题呢？事实上，如果辨证地来看，如此两种看上去截然不同的言论也确实能找出一些“交集”。说集中，三年前有的省分公司已经达到 BOSS系统的集中了；说分布，不是有逻辑和物理数据集市之分吗！所谓逻辑，就是在现有数据仓库中建立一些视图或表，专门给地市使用；而物理，就是将硬 件、软件放到地市，让地市公司自己玩儿。总之，以前好不容易将数据从地市抽上来，如今经营分析系统里转了一圈，再还给他们，移动公司还真得仔细想想这是否 值得。 

从实际建设情况来看，有的地市有钱，就建设独立的数据集市，有独立的硬件、软件；有的地市没钱，那就和其他差不多级别的地市 联合起来，共用一个数据集市，建设所谓联合型数据集市。招都想绝了，以至于差不多都忘了数据集市究竟是干吗的了。而对于地市公司的员工来说，他们本来就不 是对技术很熟悉的人，好容易学会了从BOSS系统里面用SQL统计点数，经营分析系统来了，于是重新学习从经分取数； 如今，数据集市又开始建设了，新一 轮学习当然是少不了的。在具体应用上，如果这个集市能够提取相应的数据当然好了，可就怕和经分一样，想提取数据，告之要等两个星期，那样，数据集市还是没 有作用。 

数据集市的另一重要功用是分析应用。虽然目前已经规划出名目繁多的专题，诸如离网预警、竞争对手等，可要将它们在不同的地 市用起来，问题就大了。专题的应用重在流程，和具体的组织结构要关联起来，但各个地市公司情况并不一样。比如有的地市市场部比较强势，在数据分析中占据领 导地位，而有的地市则是IT支撑比较强势；有的地市会为某个专题设定相应的组织结构，有的则不重视，因为那个专题要解决的问题根本不是自己最关注的，更谈 不上耗费宝贵的人力在它上面。 

不管移动或是联通，都是总部出规范。如今，移动新的经营分析规范、数据集市规范都已出台，这些规范都 是挺大挺全，可并不完全适合所有的省分和地市公司。虽然让省分公司自己去搞经营分析系统、省分公司让地市公司自己做数据集市都存在难以控制的风险，但是， 如果考虑到经营压力和急迫的分析需求，地方公司的意见无疑正在越发得到重视.