怎样的架构设计才是真正的数据仓库架构

如果自¬己开发的话，所有转换都在存储过程中进行，对于海量数据来说不是最好的办法，因为占用数据库的资源太大。建议把数据拿到c/java等程序里转换后，再load¬回去，减少数据库负担。这里说到了部分软件工程的问题了。

CIF有专门的章节描述ODS,ODS有以下特点：

   面向主题的
   集成的
   易变的
   明细的
   反映当前数据值的

ODS是企业数据架构中最为复杂的一种形态，既要满足数据事务操作要求，又要满足数据分析要求,中国电信的CTG-MBOSS规划中对ODS有比较明确的要求，但在CTG-MBOSS规范中，ODS也做了一定的变更处理。在云南电信以及上海电信的ODS系统建设中（云南电信ODS已经初验，上海电信的ODS算是上线了），ODS的定位就比较模糊，其主要功能是给数据仓库提供数据，但大致来讲，ODS有以下四种类型：

   I类ODS，与应用系统的数据延迟为1~2秒，实时或近似实时
   II 类ODS，与应用系统的数据延迟为2~4小时
   III 类ODS，与应用系统的数据延迟为12~24小时
   IV 类ODS，数据仓库中部分决策分析数据回流至ODS中

目前应用的比较多的是IV类ODS，因为一旦将决策分析结果加载到ODS中，重要决策信息的高性能联机支持将成为可能，举例如下：

   客户细分与评价
   银行客户贷款

ODS与数据仓库的重要区别如下：

   ODS只存储明细数据
   ODS中存储的数据一般不超过一个月
   ODS支持事务更新操作

在ODS中存在3种不同的时间窗处理：

OLTP时间段，与应用系统保持同步更新（通常采用消息机制）
批处理时间段，从应用系统中接收批量数据（通常采用ETL的方式）
DSS时间段，从数据仓库中接收决策支持数据

由于ODS需要满足上述不同处理类型的性能要求，导致ODS无法对任何一种类型进行优化，只能进行折衷考虑，这也正是ODS的技术复杂原因所在。

The frequency of _update and degree of integration of an ODS vary based on the specific requirements. Most commonly, an ODS is implemented to deliver operational reporting, especially when neither the legacy nor more modern on-line transaction processing (OLTP) systems provide adequate operational reports. These reports are characterized by a limited set of fixed queries that can be hard-wired in a reporting application.

please reference page 41 for more detail information in <Dimension Modeling - the Data warehouse toolkit> by Ralph Kimball.

Innovate
20060227

所以我对现在很多人对概念的操作深恶痛绝，搞了半天本质的东西还是没变。IV类ODS就是我说的那种形式的DM，非要说成ODS，从结构层次来说，它已经是面向最终客户应用，被最终ETL的，准备好的数据，在传统定义中，应该类似DM的作用。所以无论怎么定义，本质的东西要抓住。正如我说的，DW的数据源来自聚合业务系统数据的ODS，这个ODS的功能就是集合的、比较干净的OLTP系统，而后面有定义个IV类ODS，从架构层次来说，已经变了本质，是经过ETL的，符合客户查询需求的。两者一个在系统架构的前面，一个在系统架构的后面，为何要使用同一概念，标新立异？莫名其妙。

还有比较反感的定义就是什么实时数据仓库，无论你怎么设计数据仓库，始终脱离不了“历史的”特性，何来实时之说，蒙客户呢？现在客户懂得可比以前多了。

I do not have this DOC in my computer now, and it’d been written nearly 10 years, Kimball also said, Source systems are not queried in the broad and unexpected ways.

Since DW has been developed over 20 years, concepts and methods have been prompted too, so for whatever DOC of whoever wrote, we need analyze first, which can solve our problem, which is the best method for our customer.

Dumpedjoe
20050227
innovate511过于激动了，呵呵。

我认为把项目中成熟的东西用概念“封装”一下是走向成熟的标志，不是包装啊，个人观点，就好像kimball把dw分为四个component，几位老大都是做概念封装嘛，有能出书而且易懂顺便搞点小钱。

我想大家早就了解了概念的相对性，例如实时，现在的客户不好蒙哦，但是和他们说实时也不至于让他们如此狂躁，呵呵。

不说了，到此为止，言语如有不敬之处，innovate511休怪，非我本意，就技术问题讨论讨论而已。

刘庆
20060227

对于innovate提到的"第四类ODS就是之前提到的DM，并且是面向最终客户应用的"说法，在下不赞同。
 
而对于dumpedjoe说得"第四类ODS是目前我们项目常见的"，也不是非常认同。
 
这种ODS是一种比较理想化的，但至少在我所经历的项目中从来没有过。但奇怪的是，在我们第一个项目中就考虑到了将分析的结果返回到ODS中，比如客户的信用度评分、价值度评分等。然而这还不能起到作用，所以最后摒弃这种做法。这可以和电信经分里面经常提的"闭环反馈"有些关联吧。然而这不是技术的事，还得看最后分析的结果是否融入业务的流程里面，例如客户真的能够用信用度模型来给每个客户评分，显然，现在还不能做到这一步。
 
可以说，BI系统的此类模型被认可的不多。因此，也谈不上将分析结果返回到ODS，那是无用之举。
 
但即便将这些分析结果返回到ODS，并不是说ODS就面向客户应用了。
 
数据仓库是干什么的，保存企业活动历史数据的，这些数据反映了企业的生产、销售、财务、市场活动的一举一动，而数据分析显然也是企业活动的一种，当然也有必要记录它们的历史。因此，从DM中将数据返回给ODS，用"返回"这个词有些不准确，此时，DM已经像是一个数据源了，可以将它和ERP、CRM系统同等看待。这些分析结果，例如用户信用度吧，同样是用来作分析用的，可以它们进行聚类，评定A、B、C等级，作为OLAP的维度等等。
 
看我说的有道理吧，嘿嘿。

Dumpedjoe
20060227

可以再探讨一下，第四类ods是比较实际的，对于国内的客户来说，因为种种原因，一般都不愿意将dm中的分析结果分享（比返回和回流应该要好理解些，但数据流向不直观，呵呵）给使用ods的操作型业务人员，从技术角度来说实现这一点并不难，主要是应用对象的不同导致了很少采用该方案，而在我经历的一些项目中，客户确实倾向采用该方案，因为组织架构的不同，对于客户信用度以及贡献度等等需要进行主题聚合或跨主题聚合的指标，能够提供给操作型业务人员作为客户评估的一个参照是很重要和必要的，这就类似于SE中的PDCA循环。

我想此方案应用的差异和组织结构密切相关，组织结构和该组织在业务领域的成熟度又有关系，这应该是当前国内应用较少的一个原因。

丁西宁
20060227

我还是老老实实的从41页开始重新看了一遍Kimball关于ODS的描述。看了三位关于ODS的讨论，我也结合自己的经验说两句。

我想在项目中我们进行架构设计时，一定会考虑这么几个问题：

a 什么是ODS？

b 针对现在的需求是否需要采用ODS?

c 如果用，ODS将要在架构处于什么角色，要完成什么功能？

第一个问题，大家都已经很了解了，操作型数据存储区，是为了方便数据仓库而存在的。ODS既然是存在于OLTP和DW之间，那么在ODS中的数据就肯定与OLTP和DW的不同。在ODS中是保存一个月的数据，还是二个月、三个月？是只保存原子数据，还是进行一些聚合的处理？这些都应该和你想要ODS完成什么功能有关。

什么功能没有ODS就肯定实现不了？当然没有了！ODS只是为了方便DW的实现而存在的，方便ETL的实现，当然也可以让它实现一些数据的展现的功能了。innovate511肯定是从设计角度考虑，每一个层次都要有明确的功能，如果也让ODS来实现后台实现的数据展现功能，从设计上来看就显得混乱。对吧？并且对于ODS身兼ETL、展现、还要加上数据更新（ODS的特点）三职，是否可以很好处理多个数据源的转换、更新、是否保证数据展现的准确性、以及性能如何控制等方面考虑的。从技术这个角度看，ODS确实有些任务不明确，可能由此会导致数据在ODS层上如何存在的问题。作为DW的数据中转站，为了和多个数据源同步，它一定要保存最明细数据；如果要在ODS上实现数据展现（我想应该是从OLTP中分离出来的查询），那么为了性能一定要进行不同粒度的汇总，汇总的粒度应该也和数据仓库中的粒度不同。是有些乱！但是我倒是不反对这么设计。理由：我认为在ODS中实现的查询，很来应该是存在于OLTP中的，应该与在DM中的数据分析不同。因为这是从业务角度考虑的，在实际业务中，这部分业务需求是很频繁的（相对DM中的），所以把这些相对频繁、简单的查询从复杂的关联查询中分离出来也是一种设计方式。

对于第四类ODS，就是刘庆说的闭环管理需求的实现。但是我有一个不明白的。为什么DM中分析的结果要返回到ODS中呢？为什么不返回到OLTP中呢？我们决策出来的结果，应该是为了影响实际业务的流程的，而不是给ODS操作者看的。不知这样理解对不对？

说到实时数据仓库（准确的说应该是near realtime），我想应该也是从业务角度出发的一种设想。innovate511老兄肯定做过很多国外的项目，国外企业本身的管理水平应该比我们高。对于如何使用数据仓库、使用决策分析的结果、并且如何应用到企业日常的管理上应该都有很多的经验。我想还要请innovate511老兄多给我们讲一讲。near realtime data warehouse就是想把从历史数据中分析出来的结果与没有进入到数据仓库中的数据结合在一起使用，比如：在税务行业，每月企业报税就是集中在三、四天，在这几天中数据的变化会很剧烈，没准刚才还没有完成任务，下一分钟就完成。税务的领导就是想实时看这些数据。所以我们在给客户实现准实时数据仓库时，采用EAI和DW相结合的方式。

ODS正如几位所讨论的，在数据仓库架构中是非常重要的，我们这么花精力讨论是很值得的，也希望有更多的话题把我们聚到一起。:)

Innovate511
20060227

首先我要说明的是，查询功能方面，OLTP系统架构没有经过DW汇总过后的conform table强，这是很显然的，客户的查询不会简单地按照OLTP系统的逻辑，一个一个得查询，可能是一个复杂的查询，这个时候OLTP要做的事情就是多表关联，而我们的汇总conform table是经过聚合的表，不需要关联就可以满足客户的各种复杂的查询需求。这是我不明白为啥要在ODS层做数据展现的原因之一。

其次，既然ODS是OLTP系统到DW之间的一个逻辑层，那就没有经过复杂的ETL，对不？举个很简单的例子，某大客户经理要查某区县欠费100元-200元之间的属于某大型单位的年龄在30岁以上客户详细资料已经最近的消费明细，那是否要在ODS中关联好几个表来达到他们频繁的查询目的呢？

我也做过很多国内项目，客户的有的及时性需求是存在的，但是不普遍，没有非要给出个新概念给客户感觉这个新概念肯定ok的必要吧，除非这些客户对数据仓库的了解都比较业余。所谓near realtime只是针对某个很棘手的分析主题，能快速相应客户信息的变化，这种情况一般为单一主题的情况，完全可以和“传统DW”分开来设计和实施（看具体情况，只是逻辑上至少要分开）。这样的需求一般数据量不会很大，这是能快速相应，接近事实的前提，技术和设计上没有什么需要革新。

无名
20060227

最近收到不少来自TTNN的关于数据仓库架构的邮件，本着“重在掺和”的原则，和“凑凑热闹”的目的，也来叨叨两句。不过由于不想引起争论，我说的内容和大家所谈的不完全是一码事，开始跑题......

我以为，不同的软件系统有不同的架构描述方法，比如一个纯粹的系统集成项目（比如搭建一个各种硬件构成的网络）架构重点在于描述网络连接、硬件配置、功能原理和性能原理；而一个纯软件项目（比如开发一个基于Windows的视频播放软件）架构重点在于描述后台引擎的参数以及人机界面的设计原则。而一个数据仓库项目，系统架构和数据仓库模型的逻辑设计架构也不是一码事，大家讨论的应该是在数据仓库设计架构这个范畴，而这仅仅是系统架构中的一个组成部分而已，我现在想说的，是系统架构。

我想说的第一个问题，是架构的完整性，原因是所谓架构是对某个东西的完整的描述，通过看架构，能够知道这个东西是干什么用的，由什么东西构成，大致长什么样子。比如我们说一个建筑物的架构，先说这个楼是干什么用的，商用？还是住宅？还是商住两用？之所以要先说明这个，是别人能够有个大致的想象，同时能够根据这个来初步判断架构设计是否能够符合这个用途的要求。对于软件系统来说，说一个字处理软件或者一个播放软件或者一个ERP软件，大家先心里有个谱。就比如说数据仓库吧，大家至少都知道有个ETL、存储、展现等等。
   
然后说建筑物的话，我们说大概有多少层？大概有多高？软件系统也一样，现在流行分层，我觉得可能是老外吃汉堡的时候得到的灵感，一层一层又一层，每层都夹个什么东西，先说吧，你这个数据仓库系统有几层，每一层干啥？

再说一个建筑物，除了各层之外，还分功能区，比如住宅楼的楼梯、居室、卫生间、厨房等等；数据仓库中对系统每一层的区划也有不同，比如主题域划分、功能域划分等等。
 
另外一个完整的建筑有很多子系统与整体架构融合在一起，比如：强电系统、弱电系统、网络与通信系统、上下水系统、燃气系统、空调系统、安保系统、消防系统等等，那么对于一个数据仓库来说，也有各种系统在整体架构中融合：元数据管理系统、安全控制系统、数据传输系统、数据存储系统、质量控制系统、备份和容灾系统、接口系统，可以说每个子系统中都包含若干功能块，作为架构设计，也可以详加说明。
   
再说建筑物的材料部分，各种系统以及整体架构需要用物料来实现，比如钢混结构、钢架结构、木结构等等；那么对于数据仓库系统来说，各个子系统都需要用什么样的材料（软件工具和硬件设备）来实现？
   
还说一个建筑物假设已经盖好了，需要有一系列的管理规则来保证建筑物的安全和正常使用，比如保洁工、保安员、管理员以及相关的工作制度，以及对住户的一些行为约束等等，那么数据仓库中，是不是也需要说明不同的角色在系统中的职能和工作规范呢？我疑惑的是，这个软性的内容是不是应该属于架构设计范畴？
 
   
上面写的东西有点乱，总结一下：架构设计要说明系统的功能设计目标、分层方法、附属子系统功能说明，软硬件部署方案，其实没一块内容都够复杂，都需要根据需求和要求进行“设计”的，而不是剪刀加糨糊能搞定的......东西够多，我只是遗憾通常受关注的只是数据仓库建模的架构，而整体系统架构却少有人讨论。

Goldenfish
20060228

这样的说法很形象。数据仓库的架构由业务（业务需求）、功能（执行＋运维）设计、数据（模型、存储、处理流程）设计、内外部接口设计等部分构成，数据仓库的管理流程（人员、角色职责、流程）融入其中，最后将人员、系统、信息、流程有机组织在一起，构成完整的数据仓库架构设计。

Innovate
20060228

首先要说明的是，现在的很多项目架构设计之所以包含了楼主说的那么多内容，而实际规范的项目不是这样的，而是架构设计、数据建模、业务分析、开发流程、测试流程应该是不同的人去完成各自的职责，也就是说架构设计的人可以不了解这个行业，数据建模的人可以不了解架构，业务分析可以不了解总体设计，开发、测试设计可以不了解其他设计，他们之间的联系就是已经成熟的接口而已。

几乎每一个国外的关于设计的资料都提到过这些。所以暂且不说这样做不行，只能说是中国特色吧，人力资源、客户投资、大环境决定的，不能说应该这样做。

架构的原理

刘庆
20060228

这两天关于架构设计的讨论挺激烈，"人到的不少，我很欣慰"。老高的提醒，自称跑题。回头看看，呵呵，讨论的历程有些意思。
 
刚开始，Innovate提出自己对BI架构的理解，接着几篇确实是围绕老高所遗憾的"系统架构"，从西宁对"分表"的疑惑开始，讨论逐渐转向业务模型的分层方面，这里面有太多的概念模糊。接着，更加细化，到ODS究竟是什么玩意儿，可还没尽兴，老高的题外话又拉回到对架构的讨论。
 
用建筑类比软件，是个传统的比喻，非常形象。软件行业的架构显然比之建筑行业还是嫩点，可以学习。在考虑架构，如果仅仅是知道一份架构文档中包含什么，那可不够。就像很多人在所要一个架构设计模板一样，似乎有了这个东西，自己就有了思路。虽然一份模板能够告诉你先写什么，再写什么。可一些背后基本的原理，还是有必要探讨一下。
 
为什么要架构？为什么分那么多层？为什么要分成若干模块？为什么要描述系统角色？
 
文档是写给人看的，设计是帮助下游的人合理工作的。在探讨架构应该包括哪些部分的时候，不妨自问，读者、工作下游的人需要什么东西。有所需才能体现其用，因此在架构文档中描述系统会有哪些角色，他们需要知道哪些部分是自己做的，哪些不是。这就是为什么要对系统划分模块，明确各模块接口职责的原因。
 
而"分层"是一种传统的设计模式，我想软件设计有个原理—— "隔离变化"，当然这个名称可能另有所指，而常见的"抽象"（动词）也有这个意思。都是从纷繁的变化中将不变的东西提取出来，这些"不变"是相对的，例如商业环境中几乎都有客户、产品、资源，这是相对不变的；一个BI项目需要作数据整合、提供分析应用，这是相对不变的；分析应用包含报表、OLAP或是数据挖掘应用，这也是相对不变的。变化的就是根据具体环境，例如有的领导关注A指标，有的关注B指标，但从这里面也能得出不变，就是"领导关注指标"。
 
分层、模块化的目的都是隔离变化。将相对变化不大的模块沉积下来，可以被复用，这是提高效率的方法。看，当一个新项目开始，为什么总是要重新考虑ETL如何控制流程，元数据如何管理等等问题，这些都已经很多人考虑过的，是可以被复用的。当然，如果仅仅是停留在概念、方法上，这样的复用是通过培训完成。如果是体现在一种实际的框架，那么就可以拿来使用。
 
由此，在作架构设计的时候，编写设计文档，可以如此检查：这段设计在什么情况下会变化呢？将那些东西先踢出去，留下不变的，接着再对被踢出的部分，看这部分又有哪些是相对不变的，如此而已。