数据仓库到底能用来干什么

Happy 20060815

在很多场合总有人把数据仓库比作一个报表系统，我最近一直也有类似的困惑，我们建数据仓库最终能给客户提供什么？

最近公司在上一个数据挖掘的项目，我也有幸参与了一下，虽然不敢说数据挖掘入门了，但是随着对于数据挖掘知识的逐渐理解和加深，我慢慢的产生了上面的问题：客户¬能从数据仓库中得到什么？记得我在数据仓库方案中总是向客户这样的阐述：数据仓库可以提供查询、报表、统计分析的功能，数据挖掘提供预测的功能。而现在的理解是¬：预测是数据挖掘最高的应用，而对数据进行分析，得出各种统计分析的结果也是数据挖掘能够提供的。因为我们在进行挖掘（建模）的过程中，需要先对数据进行分析，¬而分析的过程都是基于对业务的充分理解上实现的。分析的过程就是发现问题的过程，问题一定要从业务上能够合理解释才可以。

不过我现在越来越迷惑了，我感觉建立数据仓库只是一个过程，数据仓库并不能给我们（客户）带来什么，客户从数据仓库平台提供的报表、统计分析、靠上钻下钻、同比¬、环比中得不出什么对于改进业务有用的东西。好比现在的新浪门户网站，网站建成以后，真正需要的是编辑人员，需要编辑人员来确定各个频道、栏目的内容。那么数据¬仓库项目也应该需要的是业务分析人员和数据挖掘人员。

真不知道基于数据仓库的查询、统计怎么才能对客户真正有用?请各位发表高见。

Byehill 20060815

以自身来说，我们的经营分析系统现在起步不过4年的时间....期间由于待遇等方面原因造成了不小的人才流失。据说国外一套成熟的经营分析系统真正成长起来至少¬需要五年时间！因为培养一批技术及业务都相当出色的成熟人才，至少要五年。

如HAPPY所说，我们不知道我们的统计查询对客户有什么作用？其实这恰恰是目前经分存在的最大问题－－－我们与市场部门脱节了！

当市场部门提上来需求要最报表，olap的时候，我们会机械的从数据库中拿出一些我们再熟悉不过的数据拼凑起来发给他们，但是这些数据究竟对市场部门有什么作用¬，他们会如何利用这些数据对营销策略及市场导向进行分析，我们也不清楚。

说白了，我们统计的数据可能对客户是很有作用的，但是只是我们不知道用在了什么地方。

市场部门对基础业务等业务层的东东了如指掌，而且有自己一套成熟的分析思路。而我们却熟悉数据仓库技术以及我们数据库的模型。但是我们恰恰是两个部门！

如果经营分析部门能够出现一批业务和技术同样优秀的人才，那经营分析的价值也就充分体现出来了。

可以想象未来成熟的经分－－－－不仅仅是提供大量的数据展现，而且伴随这些数据还会每天，每周，每月....向市场部门提供大量有参考及指导价值的分析报告。真¬真正正扮演一个分析的角色！

如同网站建成后，我们要做有技术实力的编辑人员！
innovate511 20060816

什么学科都是有了良好的基础后, 然后在基础之上做应用。

而在DW/BI项目里，DW就承担起基础的作用，一切BI功能都建立在之上，也许将来还会有新技术在上面应用，而DW本身也还在继续发展。

yang_zxf 20060816

正如以前在dwway上CMCC宁宇所言，未来的运营商必须培养自己的业务分析人员，来利用数据仓库进行相应的探察分析，而在移动的经分1.5期的规范中这方面¬体现的十分的明显，给出了数据仓库系统相关的用户角色和职责，这样对于提高系统的应用效果肯定有很强的促进作用。

作为数据仓库平台承建的集成商，我们也十分的希望能够在对业务的深入分析上有所突破，而这更多的应该是运营商事情，当然集成商中也需要相应的业务专家，尽可能的¬能够做到引导客户，但是从目前在国内来看，这种情况还做的不是很好。

Zhu Sizheng 20060816

*如innovate511*兄*所言,*DW/BI项目里,DW就起承担基础的作用.一切BI功能都建立在之上也许将来还会有新技术在上面应用，而DW本身也还在继续发展。

但就在建立dw的时候,我们有多少人有多少分析是建立在一个整体的框架角度进行思考的.我们总说up-bottom好,但真正站在制高点从架构从业务从技术上来思考的人有几何?

我拜读过innovate511兄几篇的文章,感觉*innovate511兄*思路很清晰,无论对技术还是对业务.

*innovate511*也在说,dw本身也在发展,同时我们也看到了业务的需求也在发展,技术也在发展,技术人员也在不断的成长成熟,可能诚如一位佛僧所说¬:

唯一不变的就是变化本身.所以对于byehill兄所说的

"说白了，我们统计的数据可能对客户是很有作用的，但是只是我们不知道用在了什么地方。"我们只能说,一切再往好的方向发展,

这可能只是一个必须经历的阵痛与迷惘阶段.可是,如何发展呢?

不谈那些假大空的话,就从技术人员本身,我们能走的道路有哪些?业务专家?架构设计?

前端报表开发项目管理人员?
ETL工程师 -----> 元数据管理? -----> 架构设计专家?
数据仓库管理员 数据挖掘工程师?
........?
.............

这中间的哪一步不搀杂对业务的理解?单单就技术条线本身就覆盖了这么多的领域,这还不包括对软件工程,项目管理,网络配置与管理,数据库开发等知识的储备...¬.....也不谈人际交往能力,现实生活压力........那么再要成为一名业务专家,.....
不过借用人家有一句话:"别说面对困难,我们克服困难要上;就是没有困难,我们制造困难也要上",技术与业务结合的悲哀啊........
跑题了.........各位,sorry................
goldenfish3 20060816

按照我的经验，多维模型的设计一定要用户参与，达到确认每一个维度、指标的程度。这样，作出来的模型才能适合业务需求。业务人员对于经常从什么维度进行分析应该¬提供足够的信息，一些维度不能从数据出发简单的强加到业务人员那里，因为可能这些维度上的数据他们根本不关心，或者维成员的层次、分类不合理，或者该维度上的数¬据质量太差不可用。我也见过很多数据驱动的模型设计结果，大量的维度看起来模型足够复杂，但这样造成占用更多的系统资源（存储、计算），最后的结果业务部门还不¬认可。

Qing 20060816

数据仓库到底干什么用？不好说，这里发表一些低见，先说一些一些假大空的东西。

一般大家都说，数据仓库能够让企业有一个统一的、完整的数据视图，为数据标准化打下基础。可通常数据仓库本身，会让整个数据环境变得更加复杂，统一、完整、标准¬，还是遥远的理想。

我现在有个感触，数据仓库是业务系统代替不了的地方——它能查到历史数据。这点够强了，譬如对于下面的分析人员，他们从生产系统中往往只能查询当前的、个体的数¬据，如果要作统计分析，提交需求给IT部门，写出复杂的sql来得到数据，可生产系统中并非以记录历史为主（可能在日志表中保存有历史，那种结构是比较难以查询¬；或者，是保存了粗粒度的历史数据）。因此，那些对历史数据的查询统计，诸如近六个月在各个时段发生呼叫的趋势情况。让数据仓库做这样的事情，得心应手。

本来，保存历史数据是数据仓库定义中，是四个特征中的一个。其他三个，集成、稳定、面向主题，我到没有感觉有多大特点，当它们肯定都是数据仓库的特点，只是没有¬感触那么深吧。

上面说得是数据仓库最基本的服务，统计和查询历史数据。而作分析、作数据挖掘，当然得要历史数据。这更加是数据仓库应该提供的服务。

并且请注意，这里说的仅仅是数据仓库的作用，并没有说分析应用的作用。看byebill、yang等都已经在说技术和业务如何结合的问题，这可以算是另一个话题¬吧。

而数据仓库最核心的服务，就是数据访问服务，能够方便地、快捷地访问高质量历史数据。

要做好这点，当然还是跟那四个特征挂上构。我想对于数据仓库这个系统来说，做到这几点也就够了。当然，如何衡量它达到这个"够了"的水平？现在并没有什么量化的¬方法，大家只能通过它支持的应用来看结果。例如报表做的怎么样了？挖掘做的怎么样了？这种衡量方法当然也有道理，但还是不科学。数据仓库就是数据仓库，应用就是¬应用，干吗要将他们两个搅在一起看待呢？

周剑 20060816

这里是否存在着一个循环的问题呢?

现实中,业务人员能对一些分析层面的东西讲得头头是道的,恐怕不会在多数吧.这跟BI在各行业的深入程度有关,跟具体的企业有关,跟地理位置有关——一般几个三¬角及沿海企业比内地企业这方面素质要高些，也跟业务人员的位置有关系。如果客户提不出个东西来，那是否还是得依据我们的认知和理解去引导？这对去引导客户的人，¬在业务上，技术上，就又是有了一定高度的要求。

happ问，数据仓库究竟带来什么？我也说上一两句。

从目前看来，可以使用户发现一些问题，譬如关键指标告警之类，依据发现的问题，依据一定的规则，引导用户进行对问题的分析，上钻下钻等可以是其手段，至于到解决¬问题、或是作出决策的那一层面，确实是没做太多贡献。

总而言之，不指望能做出一些靠用户或者是业务人员完全无法完成的东西，或是本身在业务上现在不存在或是不知道其规则的东西。

BI化以后，信息的准确性、及时性是可以大比业务人员去完成大加强的，同时，一些应用，可以将以前的某些事后的考核、分析，现在在事中就开始进行预警，反馈，控¬制。

goldenfish3 20060816

确实。对多维分析来说，业务人员能够有效参与，往往需要在日常工作中已经有使用excel的透视表的经验，甚至常常面对（在多维看来只是维度组合出来的）数十张¬、上百张静态报表，希望有办法能改变这种状况。这样的情形下，多维分析能有针对性的解决他们的问题。

数据仓库带来的是数据抽取的及时性、数据集成的一致性、运算的高效性等。这一点，无论在BI层面怎么展现，哪怕是静态报表，已经相对以往的处理是飞跃了。

innovate511 20060817

客户那个网络环境里, 这里被屏蔽了,
只有深夜来冒几句。

首先，我很赞同甲方应该培养自己的业务分析专家，乘现在EDW还在建设中，可以开始考虑逐步丰富BI的应用了。因为厂商的业务专家针对的是所有行业，并不仅仅针¬对一个客户，那么从业务分析的角度教难为客户做出最好的分析，考虑角度可能有偏差。

从电信行业几个大项目看，基本是采用数据驱动的方案，先建设ODS，然后EDW，最后数据集市和前端应用，可能大家在担心如何利用BI来更好地利用DW的建设成¬果。基本都会赞同，BI的应用，业务专家至关重要。但是我想说一下，在EDW基础上的DM的建设，也至关重要。

我在dwway.com发了个帖子，由于对移动最新情况不了解了，很多都是在猜测之上，还请见量。

http://www.dwway.com/bbs/showthread.php?p=119300#post119300

其主要目的，就是建议在EDW建设基础上，多注意DM对BI的最佳支持的设计。无论你对Kimball那套理论看法如何，他的DM建设是公认的权威，这点我在一¬个项目里深有体会。虽然他以前写了好几本书不乏经典之作，但他的网站里不断更新着对一些细节的讲解，说明对DW/DM的研究，还在不断根据新的BI需求在更新。

可能不少工程师在设计DM时已经根据自己的经验和书上理论，很标准地设计了DM，但仍然会BI应用时感觉吃力。其原因就在于，DM模型里有太多设计限制了BI的¬功能，结果是很多transform的工作交给了BI工具（现在BI工具也强大，啥都能做），而不是后台数据库，而广大客户对BI工具的压力本来就很大直至无法¬使用，导致用户对BI的缺乏信任。这种情况有两个办法解决，如果是数据量的原因造成的，建议DM结构重组；如果是模型设计原因导致BI工具承当过多工作，那只有¬重新设计维度模型了（至少得大修改了）。

Qing 20060818

移动不是正在搞数据集市嘛，仅仅从命名上，也就是DM。但我还是不明白数据集市到底要作些什么，看着别人忽悠地一身劲，我都怀疑他们说得是不是能让自己相信。

为啥要搞这个，我想一个原因是，现在的数据仓库满足不了地市公司的需求，现在的数据仓库似乎大多搞点宏观分析，搞点数据上传总部，或是忙于应付数据质量的问题。¬对于地市的需求，总显得不是那么紧迫。从省公司角度，要统一规划，统一考虑，当然行动有些迟缓。因此，地市市场部需要分析，需要数据，最直接的方法就是找他们的¬IT人员，去boss里面查，当然有的历史数据难以查到。

有个例子，今年年初的时候，去一个地市。据说已经给他们建立了一个数据集市系统（具体情况不是非常了了，当时也是刚到这个项目），但发现地市的IT人员对于那个¬数据集市在哪儿，用的什么系统都全然不知，更别提里面有哪些数据了。当我方人员去宣传，这个集市里面包含如何丰富的数据之后。理所当然地，他们露出崇敬的表情，¬然后用一副有人拯救他们脱离苦海的激动语调，"我们可找到党组织了！"。不过，在五个月后的现在，他们仍然没有用那个数据集市。

这里面的原因当然很多，有技术的，有执行力度的，当然还有政治的。

比如还有个地市，小地市，没有数据集市。平时，市场部搞分析，要数据也挺困难，因为他们的IT部门跟业务部门那条沟还挺深，要一点数据费的周折挺大。上次去忽悠¬了一次，大家吃了顿饭，感情猛增。现在那些提数需求大有找我们帮忙的趋势，因为我们好说话啊，而且还有个不错的数据仓库在后面支撑着。

前段时间，这里发起了几个有关规范的话题，大家基本对规范的作用表示肯定的态度。我不敢确定，也许规范只是一种无奈之举，既然要全国上下一起作同类型的项目，总¬得有个标准。即便，每个地方情况不同，但考虑不了那么多了。反正有钱，经的起烧，作砸了一个项目就当是交学费罢。

innovate511 20060819

是的, 这种系统和ERP一样, 只有上下一致才是成功的前提, 然后才是技术问题。但很久没接触移动的项目了，实在不知道现在做成什么样子。

但是从技术角度看，数据驱动和业务驱动一点矛盾都没有，数据仓库的建设应该是保证数据质量的基础，而数据集市就没必要再追究数据质量问题了，重点是从业务角度去¬考虑，包括统一的维度模型的建设，数据集市和前端接口问题。技术难点一般在模型设计上，因为客户的需求是多变的，数据集市常常会出现难以满足复杂需求的情况，一¬般有两大类情况。第一是数据源不足，这样的问题主要出现在设计者的疏忽，或者客户过于苛刻的要求。第二种情况出现得最多，就是模型存储方式满足不了多变的业务定¬义。于是数据集市常常会出现为了新需求而在维表甚至事实表上加字段的情况，起目的就是为了效率和可靠性，尽量把业务需求在数据集市搞定，不让BI承担太多。

不过我也听说过好多用户对数据集市没咋用，投了那么多资，真是可惜了。