数据仓库是不是实时的？

刘庆
20060308

忽悠到了广州，住在黑人区，办公在花果山，热多了。晚上都可以穿着短袖漫步在街上，可惜这附近似乎没有什么繁华的地方。

网络也不方便，很多限制，不爽。

上次记得谁表露出对实时数据仓库的反感，这个"实时"也曾困扰我许久，因为它的意义总是在摇摆不定。例如人们说企业应用集成，它比"一体儿"更加实时一点；说操作型商务智能，是指分析嵌入到业务流程里面，例如在客户入网的时候判断其信用度。还有人说，客户有这样的需求，每天要监控的经营活动，对实时性要求很高，譬如观察实时话费的变化。包括对于对于"分析"这个词，也有人在说"实时性分析"，有些模糊。

到底什么是实时的，什么不是实时的。

我想一项分析活动包括两个含义，一是建立模型。当然如此说显得有些学术，无论是从业务经验，还是从数据中观察规则，都管他叫做建模吧。用流行的话说，这是"从信息到知识"的过程，所谓信息就是数据的含义，而知识，则是可以指导决策的规则。譬如这个知识就可以表示为"如果.. 那么..否则"。这个规则的得到是基于历史数据的，并不是实时得到的，一般来说只是周期性的"训练"，训练这个词也是数据挖掘里的术语。俗话说，"三日比省吾身"，也就是说，看看我这三天里面都做了什么，哪些是对的，要发扬，哪些是不对的，应该抛弃。可不能说"吾时时必省吾身"。

分析活动的第二个含义是指导决策，这大多是实时的。判断一个供应商的等级，判断新客户的信用，判断投诉客户的坐席次序。这部工作得依靠前面建立的模型（经验模型或是数据模型）。

如此看来，人们说"实时性分析"这个词，其实指的是"实时性决策"。

而在数据层面，虽然有比较实时一点的"企业应用整合"，也有批量数据处理的"抽取、转换、装载"，数据仓库的目的是整合数据，用于支持分析，此处的分析更加偏向于上面提到的第一个含义——建立模型，它的特点就不是实时的。因此，对于"实时数据仓库"，这本身不是一个非常恰当的称呼。

然而还是有疑惑，因为上面提到的"监控经营活动"的需求，似乎真的就需要比较实时地将数据整合到数据仓库中，也很怀疑，这部分数据是否应该放在数据仓库中，好像数据仓库是一个包罗万象的数据中心一样。

Dumpedjoe

很巧，今天刚打算对实时数据仓库说点什么，上来看见刘庆的帖子早了十分钟。

有人反感我就说的准确些，near real time，也叫做low-latency data store，这样的系统在一天内可能有多次刷新，老大们说“是数据的应用而不是数据决定该类系统的方法是否准确”，因为之前的大多系统是告诉大家what has happened，在这个基础上，越来越多的人想要知道what is happening。

基于此，我们当然不能像刷新业务系统那样刷新数据仓库，这个时候，我想到的还是ODS，老大们又说“好的BI项目往往基于最佳实践的混合应用而不是仅仅拘泥于一个方面”，Kimball推崇的bottom-up和Inmon的Top-down哪个更好？恐怕不是这样评估，而是在具体的情况下哪个更适用。让我们不要把自己限制在书本的概念中，让ODS不再仅仅是临时性的业务数据转储区域。

在建立模型之前必须对数据仓库或者数据集市的应用进行分析，这对应老大们说的“数据应用决定方法”，而不能一上来就定下数据准备区，数据展现层和访问工具，随着在这几个组件中围绕清洗、转换、装载等细节上绞尽脑汁。分析具体的应用，看看哪个部分能够很好的适应需求及需求的变化，不拘泥于框架或者架构，业务系统也是如此，这步做好了，具体的应用模型就出来了，也许有人说这又是发挥了“建设有**特色的BI系统”的概念，无规范的约束将导致最终的混乱，谁说老大们画了一张图，12345表示下来，那么2就只能在345前面而不能存在345之中呢？他们想表达的真的是12345？对此有疑问的可以看看昨天关于staging area的讨论。

goldenfish

实时数据仓库的说法，我认为改为“实时BI”更准确点。我们可以使用EAI类似技术使得ODS部分数据能够实时或者近实时的更新，以满足对于what’s happening类问题的解答；而从ODS到数据仓库使用批更新，在仓库中保留历史、汇总。

Innovate

我觉得“near real time”在现实需求中是肯定存在的，所以对才有这么个概念。但是有多少这样的需求呢，恐怕是很少的。因为大多数分析、查询需求都是客户想看过去某段时间或者某个时间发生的事件，如果需要“near real”，那肯定是很着急分析的，需要马上处理的需求，这样的需求想象一下都不会多，客户最需要马上处理的还是如果生产系统、网络等出了问题，需要马上解决，还有多少事情需要那么着急呢？

正如楼主提到，实时监控可能用上数据仓库分析，这点不错，我以前做Tivoli项目实施的时候，就是看到Tivoli把数据收集到数据仓库里，然后给前端展示，可以通过图形、报表及时看到系统、网络运营情况。这些东西IBM,HP,CA等公司几年前就做好了，而且由于数据源的业务固定，所以数据仓库产品化了，留下给其他人开发的空间非常小。

如果运用到大型数据仓库项目里，很多项目就连每天该完成的都不能跑完，实时就不要指望了。以上是我对实时数据仓库的理解，它供我们发展的空间太小，还是转向研究“普通数据仓库”项目吧。

Dony
20060313

说到实时监控，有很多工具实现，没必要把数据收集到数据仓库里，用MRTG +perl/shell
就可以24*7“通过图形、报表及时看到系统、网络运营情况”。

说到实时数据仓库，我们之前应用不知道算不算？通过oracle RAC机制，在数据一致的前提下，将load低的节点作为数据源，通过ETL，作出实时报表（通过email, 没有展现 ）个人觉得应该也是数据集市。

再说，基于在线系统OLTP的报表, 整/分。明细。除了不能钻取，自己连接等前端展现的特征，应该可以并入实时数据仓库的范畴吧，个人愚见。