看了一个关于数据集市的定义的回贴, 想说两句

Innovate 20060718

详细信息在: http://www.dmreview.com/article_sub.cfm?articleId=1675 所以更多废话就不多说了.

ITPUB的帖子是http://www.itpub.net/showthread.php?s=5d0243005348075415045839459fcd4c&postid=4861382#post4861382

但是在ITPUB上看到有比较资深的朋友给别人解释DM的时候,居然说数据集市通常是汇总的数据,问题是无论Inmon还是Kimball或者其他DW高人,没这样说过吧?

我回帖中这样帮他们加深理解的:

关于Data mart含的信息, 经典的描述是这样的:The data mart contains only a modicum of historical information and is granular only to the point that it suits the needs of the department.

(数据集市仅含有少量历史信息,而且粒度信息也仅是根据特定部门的需求而保留),也就是说数据集市有少量历史信息,而最低粒度仅仅是部门需求的, 意味着扩展性很差,仅靠数市的项目的生命周期很短的,但如果部门客户要求最低粒度的查询或者报表的话,那么这个数据集市应该保留最低粒度.

以前我们做项目时, 经常所谓的DM仅仅是汇总的,我想那是很不好的习惯,DM已经够局限了,扩展性不强,你全部汇总,那还有扩展性么?而且我们不能仅仅靠一两个项目就给人家的DM重新定义了吧.

虽然这是最最基本的DW概念之一,但是那么多初学从业人员和部分有经验人员概念还很模糊,这样对我们的DW环境可能不太好,因为很多初学者是不会经常学习国外网站的,他们靠资深的人员那里吸收理论和经验,这样就可能一个误导一个, 导致大量失败的DW/DM设计.

建议一是要大家多交流,消除错误的论点(不含正在业界高端争论的),二是无论初学者还是资深人士不能只凭经验和部分书籍,可能多吸收不同观点, 多看不同的书籍,吸收不同的项目经验, 才能更好理解DW/DM.

刘庆 20060718

Innovate真是一个非常严谨的人，佩服佩服！
 
确实有些惭愧，看dmreview上的文章，那都是10年前的争论了，咱现在还不能将数据集市、数据仓库区分得滴水不漏。也不知道哪种说法是正确的，哪种是错误的。
 
对于上文中引述的经典定义，否定了"数据集市通常是汇总数据"的说法。之所以成为经典定义，自然是有其道理所在的。
 
但仅仅有汇总数据不行吗？
 
问了自己一句，但没有答案。去身边的项目看看，很多数据集市确实只是保留汇总数据的，但他们也能照样工作啊。那都是错误的做法吗？其实在这些设计中，必定存在大量的错误。想当然地过度设计、对经典设计的曲解、对需求考虑不充分等等，如果这种做法是错误的，到也不多他一条。设计中的错误，只有当它成为制约的时候，才会被人重视。
 
譬如说，这些项目的数据集市，没有原子数据。当用户需要作一些类似那种名单类的查询时，集市便满足不了。但没有关系，后面还有数据仓库啊，总是能够查到那批数据的。
 
很多集市存在的目的跟当初提出这个概念时的想法不同。最初的集市是为了满足某个部门的数据需求，而如今我们很多的集市，只是在数据仓库的架构中，抽象出来一个分层而已。甚至，有人说，你那个数据仓库其实就是个集市。如此，都在变换一些概念的称呼而已。
 
如果数据集市是指面向具体部门提供数据支撑的东西，其中仅仅包含了这个部门需要的，要预先汇总好的，当然也需要一些原子的。如果集市是那种作为数据仓库和数据查询的一种过渡，其中仅仅包含汇总，也未尝不可。

因此，当有人在说，"数据集市...."，还得问一句，"我们说得是同一个东西吗？"
 
希望这番言论没有混淆视听，说点实际的。
 
现在电信行业不是正在做数据集市嘛，这是一种面向地域的数据集市。本来省公司已经一套数据仓库系统了，现在要下到地市，让地市人员能够用起来。在物理上似乎也是两套方案，一种是物理独立的，硬件、软件放到地市IT部门维护，数据通过接口形式传过去。二是只是逻辑独立，其实只是在省公司数据仓库中，划分出一块空间，数据传输只是通过数据仓库空间挪到物理空间。最后具体怎么干，是采用某种方案，或是两者皆取，不得而知。但这种数据集市的作用，就是能够尽可能地向地市公司提供支撑，他们的眼中只有集市而无仓库，当然不仅仅是汇总数据能够满足的。
 
不过对于这种数据集市能够起多大作用，还是没有搞明白。地市的市场部门站在最前线，分析需求变化多端，集市能够多大程度上满足他们？也许是运营商迫于压力——因为数据仓库得不到更好应用，便想出这一招。然而对于地市的IT部门，新的集市系统能够满足自己，搞不好到头来大部分数据还是要从生产系统里面自己汇总得到，毕竟那也是他们最熟悉的方法。嗯，扯远了。
 
Jerome 20060718

个人还是比较赞同innovate511的观点的。

“数据集市通常是汇总的数据”这种说法应该是数据仓库及数据集市发展史上的过去式了，是曾经的观点。在Inmon早期的著作中有过这样的论述，一般称为轻度概括的数据。现在比较普遍的做法都会在数据集市中保留原子粒度的数据，毕竟硬件上来的，软件也上来了。

如果非要说我的数据集市就只保留汇总数据，也不能说他的做法就是错误的，只是说他功能弱、适应性、扩展性差，不建议。

有关数据仓库概念上的统一问题，一直觉得比较麻烦。正是因为概念的不统一，给大家的交流带来了很多麻烦，也给初学者带来了很多困惑，市面上很多书也是翻译的比较差。毕竟数据仓库是一门实践性非常强的学问，初学者光靠看书效果是很差的，很多概念也比较难理解。

Innovate 20060720

我觉得我们不但做项目,学问上也需要跟上时代吧?

我以前经常也做过类似的"数据集市",那是为了方便更快地做报表项目,但如果按照他们最终讨论的结果:DM is granular only to the point that it suits the needs of the department的话,那也好象是对的,因为部门的需求仅仅是那几张报表嘛.

但是我们要知道，部门客户的需求是变化的，我做移动报表的时候，客户的粒度经常会变低，以前改数据集市改的非常狼狈，这样的数据集市至少不是标准的数据集市，属于“野路子”，是别人20年前摸索阶段的路。

我的意思是,我们不能仅仅因为1、2个小项目就说“数据集市通常是汇总的”，至少这种说法不准确。

我们在回帖子或者写文章的时候，往往不少初学者会跟着学习和模仿，作为稍微较早的从业人员更准确地描述，可能是大家共同提高的最好途径。

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

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