怎样的架构设计才是真正的数据仓库架构（原创）
innovate511
关于上面说的主题设计，以及前端展现，这是给客户的最终用户看的，他们只关心你能给他们带来什么，是否满足他们的报表、查询和分析需求。但是对于厂商自己来说，需要清楚自己实施项目时要干什么，就像复杂的ETL开发需要元数据去规范和指引一样，项目的数据流逻辑，是否有设计规范。
对于一个大型数据仓库项目来说，如果粗犷地设计为ODS，DW,DM三大层次，那么在具体实施的时候，可能会因为数据量大，需要过渡层，于是随手在DW层增加些分表，到DM后，前端应用觉得查询太慢，于是也增加一些分表，再汇总。这样就陷入了无休止的维护和盲目地修改中。据我所知，能知道增加分表作为过渡层，已经算是不错的，有的项目看着ETL太慢，只是找寻数据库和ETL代码的原因，于是经常有工程师到处问，几亿的数据量如何增加效率呢，数据库还需要什么优化呢？其实即便你除了2亿纪录的那个表，那么随着客户信息的增加，以后3亿、4亿纪录你能按时ETL完成？
我看到很多朋友，包括比较资深的朋友，一提到那种架构就摇头，太空矿了，没法入手，也没法讨论。其实很多项目开发的时候，分了一些事实表分表，我看有的电信行业架构设计还把主题分为经营分析和大客户两个业务层，这不也是一种设计的进步么？
国外大项目之所以把Architecture工作和data
model的工作分开，就是因为两者完全可以独立，一个优秀的架构设计，可以应用在不同行业，而不是做一个行业的项目，设计一个架构。可能有人要问，不同客户的数据量和业务复杂程度都不一样，你如何规范？那么一个合格的架构设计，应该是分层的，比如，首先分出ODS,DW,DM，标出ODS接受哪些数据源，ODS如何把数据流向DW，DW如何流向DM，具体点可以把一些逻辑上的数据库标上，就像元数据管理图一样。第二层就是各个逻辑层内部设计，ODS一个或者数个数据库，对应到哪些DW对应的逻辑数据库，DW在处理ETL过程中，需要几个过渡层，如果数据量不大的话，只需要一个confirm层ETL到confirm
fact
table足够，如果数据量大，看来还需要一个过渡层才能流向DM层。DM层是面向各个前端应用的逻辑层，大型项目一般都是DW的一个事实表对应多个DM层的事实表。第三层设计是把业务逻辑融入架构中，说明各个逻辑层中业务逻辑的变化。
由此可见，数据仓库项目并不是完全是纯粹的业务驱动，也不是完全的数据驱动，应该是两者同时驱动的MATRIX架构。一个合格的数据仓库架构设计，不但要清除业务流程，还应该清楚数据流程，光有元数据驱动ETL开发也不能让数据仓库更有条理。当然一个项目要实施很合格，光靠架构也不够，具体的开发和测试这样的具体工作也很关键，不在此次讨论范围。
在这只是抛砖引玉，只是提醒下，数据仓库架构设计，并不是空旷，虚无的东西，也不只是业务的驱动和主题的划分。"ETL※DW※OLAP"只是些表面的东西，作为设计者，应该需要知道内部更多，更深入的东西。
huhaifei
在各个网站和论坛，一说到数据仓库，基本都想到了"ETL※DW※OLAP"，一说到数据仓库设计，就是按照行业规范和客户需求调研，设计主题，然后设计对应的事实表、维表。但是，这就是真正的数据仓库总体设计么？
--
胡海飞
DW & BI,EAI,IRP
MSN：flyingfox1979@hotmail.com
QQ:6184771
刘庆
1、 系统运营角色，他们对系统的正常运行、维护负责；
2、 业务分析角色，他们需要从这个系统得到数据分析的功能；
1、 开发设计者。之所以将开发者作为系统的用户，是因为数据仓库项目应该看作一个过程，而不是产品，因此在开发阶段，其实其架构最重要的用户就是开发者，当然要为之提供便利。
2、 系统管理员。系统交付之后，如何监控系统运行、发现数据质量问题、应付新的分析需求等。
goldenfish3
与架构设计相关联的是仓库的容量规划。包括用什么样的硬件、软件、多大的存储，满足什么样的性能，在未来1年、至若干年如何扩充以适应需求增长。数据仓库的容量规划也可以是个单独的话题，但在我们的实施中，它属于架构设计部分，而且是个难点。
happy
是指由于转换规则太复杂，把原来的一次转换分成多次转换，把转换的中间数据放在临时表中呢？
还是由于表中记录数很大，所以按照业务需求、以及今后查询的特点进行的分区处理呢？
还是在刚开始设计事实表时，根据业务的不同进行分类，把不同业务数据分别放在不同的表中呢？
谢谢
happy
-----Original Message-----
>在各个网站和论坛，一说到数据仓库，基本都想到了"ETL※DW※OLAP"，一说到数据仓库设计，就是按照行业规范和客户需求调研，设计主题，然后设计对应的事实表、维表。但是，这就是真正的数据仓库总体设计么？
>
--------------------------
thanks！
happy
xinin...@prient.com
2006-02-23
innovate511
从业务角度讲，有两种情况，一是客户比较盲目，没有明确的分析需求，这个时候主要就是从现有的数据源出发，再到前端应用的一种从底到顶的一种设计；二是客户有明确的分析需求，这个时候既要从现有从底到顶的设计，还要看现有数据源是否能满足客户特殊的分析需求，如果不能满足，需要尽早提出，并和客户解决数据源的问题，从这个角度说，又是从顶到底的一种模式。
从数据角度讲，如何把数据源到前端应用的线牵起来，通俗的说是一个大的ETL过程，但是庞大的系统需要考虑ETL后的数据质量、一致性、效率等很多因素，于是这个问题需要厂商自己处理，客户不会非常关心，所以才有很多遗留问题。
huju...@gmail.com
innovate511
而且在实际项目中，分表和你说的中间数据是两回事，而且规范的数据仓库不会把任务流程中的数据放在临时表中，那是非常不规范的，因为如果一旦有问题，中间的数据就断了，数据质量无法保证。
所以分表，就是同一个数据源，本来可以放在一个事实表，但由于数据量太大，或者业务太复杂，一个事实表很难包含所有主题的信息，于是考虑按照某种业务需求分成多个相似主题的事实表。这个没有统一的定论，需要按实际需求设计。比如一个主题分为日报、周报、月报等不同的分析周期，那么可以分为xx_day_fact,xx_wkly_fact,month_wkly_fact；如果用户经常察看的日分析是2个月的数据，那么你的当前事实表只存2个月的数据，其他的放在xx_his_fact中，再久的放到磁带库（比如2年前的）。类似的分类分表的方法很多，就不一一介绍了。
而所谓的中间数据，也并不是简单的汇总，以前的一些项目，很多根本没用国外很成熟的概念confirm
fact
table聚合一个涵盖丰富信息的事实表，而直接汇总，是一个很典型的案例。一般标准点的项目会把confirm
tables作为一个层，出现在总体架构设计中，成为前端应用汇总信息的重要通道。
刘庆
这个confirm table，一直没整明白是干啥的。按照Innovate的描述，它是一种"聚合一个涵盖丰富信息的事实表"。如此，我理解的confirm table，恐怕就是那种主题表，例如用户信息表（一系列），这些表的粒度是其描述的实体决定的，针对这种实体的汇总信息表。常见的实体包括用户、客户、渠道、产品、资源、竞争对手等。
至于"分表"这种叫法，觉着是个比较含糊的术语。在项目实施中，存在一种现象。为了满足用户新需求的时候，或提高性能，去修改模型，可能就需要"分表"，但通常会出现诸如tmp_xxx的临时表，甚至是以设计者名字命名的表，将他们当作临时表，但很可能他们并非临时的，会融入到实际的流程当中，导致混乱。这是因为在架构的时候缺乏概念设计的结果。整个系统的架构应该能够形成一个概念体系，底层物理的每个表，每个操作都能够归属到某个逻辑或是概念上。
例如增加一个临时的汇总表，那么就严格规定，此表不能放入常规的ETL流程当中，因为那样会导致概念混乱。如果按照周期分表，同样在上层应该是有"不同周期主题表"的概念。
分表目前在很多项目中已经使用，只是还是比较随意，没有在总体架构设计中作为一个层出现。
而且在实际项目中，分表和你说的中间数据是两回事，而且规范的数据仓库不会把任务流程中的数据放在临时表中，那是非常不规范的，因为如果一旦有问题，中间的数据就断了，数据质量无法保证。
...
happy
>分表和你说的中间数据是两回事，而且规范的数据仓库不会把任务流程中的数据放在临时表中，那是非常不规范的，因为如果一旦有问题，>中间的数据就断了，数据质量无法保证。
innovate兄提到如果中间数据按照上面的操作是非常不规范的，因为在ETL过程中断时会产生数据质量的问题。这一点我还不是很明白。因为我在ETL了的过程中，有一些数据质量的控制方法。如果ETL过程中断，我会在日志中记录中断的情况，包括涉及哪些数据，在哪一环节出现错误。这些数据是不会再进入下面的环节的。我会通过对日志的分析来重新对这些数据进行ETL，并修改ETL的结果。我想这样是不是可以解决数据质量的问题呢？
我理解的中间数据不是按照业务来区分的，它只是为了某些原因，比如ETL的性能优化、更好维护等等才采取的方式，不知道这样方式是否确实存在数据不规范的隐患呢？还请innovate兄帮我再分析一下吧。
>而所谓的中间数据，也并不是简单的汇总，以前的一些项目，很多根本没用国外很成熟的概念confirm
>fact
>table聚合一个涵盖丰富信息的事实表，而直接汇总，是一个很典型的案例。一般标准点的项目会把confirm
>tables作为一个层，出现在总体架构设计中，成为前端应用汇总信息的重要通道。
查了一下，没有找到confirm fact table的资料，希望innovate兄再多解释一下。如果在设计数据仓库时做到一个数据仓库的事实表可以和多个数据集市的事实表包含1:n的关系的话，那当然好了。不知如何在实际中满足这样的设计？是否要全面了解企业的需求，对业务理解很深才行啊？我们现在其实很多时候都在根据一堆业务指标来构造数据仓库的事实表，构造完后，如果有新的需求、新的指标，就会在原来的事实表上修改或者新建一个事实表。请问如何避免这样的现象？
谢谢
happy
-----Original Message-----
>分表目前在很多项目中已经使用，只是还是比较随意，没有在总体架构设计中作为一个层出现。
>而且在实际项目中，分表和你说的中间数据是两回事，而且规范的数据仓库不会把任务流程中的数据放在临时表中，那是非常不规范的，因为如果一旦有问题，中间的数据就断了，数据质量无法保证。
>
>所以分表，就是同一个数据源，本来可以放在一个事实表，但由于数据量太大，或者业务太复杂，一个事实表很难包含所有主题的信息，于是考虑按照某种业务需求分成多个相似主题的事实表。这个没有统一的定论，需要按实际需求设计。比如一个主题分为日报、周报、月报等不同的分析周期，那么可以分为xx_day_fact,xx_wkly_fact,month_wkly_fact；如果用户经常察看的日分析是2个月的数据，那么你的当前事实表只存2个月的数据，其他的放在xx_his_fact中，再久的放到磁带库（比如2年前的）。类似的分类分表的方法很多，就不一一介绍了。
>
>而所谓的中间数据，也并不是简单的汇总，以前的一些项目，很多根本没用国外很成熟的概念confirm
>fact
>table聚合一个涵盖丰富信息的事实表，而直接汇总，是一个很典型的案例。一般标准点的项目会把confirm
>tables作为一个层，出现在总体架构设计中，成为前端应用汇总信息的重要通道。
>
--------------------------
thanks！
happy
xinin...@prient.com
2006-02-24
innovate511
大家很多都看过Inmon和Kimball的书，他们都或多或少提到过confirm
table的概念和思路，就像刘庆说的，confirm
table的出现的主要目的就是能够满足用户可能变化的分析需求和查询性能的需求，增加数据仓库的灵活性、稳定性和高效性。至于为啥ODS层用作前端查询不好，我也大概说过，ODS层的作用应是承上（数据源）启下（DW）的作用，如果你非要给个接口给前端查询，还做个类似confirm
table的事实表，那不是功能和DW、DM有重叠了？客户访问要大大增加系统压力，作为数据前沿的接口，系统压力也很大，你如果保证高效？既然ODS到DW还可能经过1到多次的ETL，你怎么能保证客户最终查询和分析的数据一致性？
我不知道“建立一个若干维度若干度量的汇总表”是建立一个汇总表，还是聚集事实表，这是两个不同的概念。confirm
table既聚集事实表是指经过了所有设计好的ETL后，再把相似的事实表聚集在一起，也就是他还是事实表，不是经过sum,count的汇总表。
说到这里，不得不说分表了。前面说到了ETL完成后相关主题的事实表要聚集到一个事实表里，那么意味着前面我们已经做过拆分，这就是所谓的一个大主题的事实表拆分成分表了。我们这里说的分表，和刘庆提到的很多项目，包括大型项目中的tmp表有类似的作用，但是并不是我做到项目做到一半，突然发现数据量太大，得找个分表分散ETL压力，而是在开始设计中设计好的一个步骤，一个层，要不然为啥总体设计要一个有经验有理论的人设计，随便找个做过大型项目ETL的人设计不就完了？
再细说的分表的命名，如果资深的DW人，一看到分表基本都是tmp_xxx命名的话，只能说明这个项目是“修补型项目”，也就是走一步看一步，发现问题，我再改建模，我再改ETL，元数据管理也得修改。之所以后来项目都很重视元数据管理，是啥原因？没有元数据管理，ETL不照做么？因为大家都知道元数据有效的管理，能让你“站得高，看得远”，能把握ETL全局。那么一个“修补型项目”好，还是你前期架构设计好了，按照设计开发就是好呢？一看就明白了，这也是我最近各大论坛和网站提到的架构设计的重要性，我想我不提出来，也有人出来，就像当年很多人提出元数据管理的重要性一样。
innovate511
不好意思，我有个事情没有澄清清楚，分表可以分为业务分表，和过渡分表。你说的那种情况基本属于过渡分表，目的就是为了分散ETL压力，而最后需要汇总成一个事实表。
对于过渡分表，很多国内公司使用tmp_xx，我觉得很遗憾，且不说感觉这是个临时表，就命名来说，项目里其他人可能不知道这个表是干嘛的。最主要的是，过渡分表并不是tmp的，应该属于项目的一个重要环节，它们在完成ETL使命后需要重新回到一起，最后到所谓的confirm
fact table里面。
再说一下业务分表，所谓业务分表，并不是我们想怎么分就怎么分，而是根据实际情况。比如客户有固定的日、周、月、季、年等多个周期，那么周数据完全可以自己有一个事实表、年数据也可以。同样，举个简单例子，大客户的分析维和普通客户的维有很多不同之处，但是分析的指标却有很多共同点，而且如果调研结果是大客户信息全部来自大客户系统的话，难道你不觉得大客户和普通客户的事实表分开，是非常合理的么？领导最后可能需要一个总体客户的分析，这个时候你在完成所有ETL后，可以再汇总到一个confirm的聚集事实表里，这样既方便管理、效率高、数据质量有保障，而且方便安全管理，因为客户很可能不希望某些部门的员工不能看大客户的信息，大客户部门只能看大客户信息，而老总都能看。
至于confirm table的相关定义和资料，Kimball的Data warehouse
life cycle
toolkit里边就有。而且我以前在文章中也举个具体的例子，如何实现分表后又能高效聚集到confirm
fact table中。
刚才我说到的这些设计细节，项目的Architecture或者consultant应该可以通过详细调研后预测这些问题，然后设计出架构来，然后data
modeler根据相关架构设计去建模。而不是上面提到的，项目遇到困难了，于是需要修改相关设计，作出很多临时表来应付。作为设计者最好是很资深的人，或者有更资深的顾问帮助设计，不说预测好几年情况，能预测3-5年客户应该就很满足了，但是如果项目才开始实施几个月就发现不对，那预测了什么呢？
dumpedjoe
fact table、ods等等。
在这里说说我对ods的理解，和innovate511
略有不同，作为可选组件，ods是dw的一个补充，对于用户明确的查询和统计需求，为了减轻源系统的压力，引入ods，在其中针对确定的需求进行聚合，提供给前端操作型业务人员进行查询，dw在一定程度上能够满足这样的需求，但是分析型业务人员和操作性型业务人员的目的完全不同，虽然前者偶尔会访问到操作型人员经常访问的数据。
源系统
/ \
明确的查询需求 分析需求
/ \
Ods dw or dm
/ \
操作型业务人员 分析人员
对于无批量查询需求的项目来说，ods就没有必要，也不能成为某一个层次，更不能承上启下。
至于分表命名为tmp_***，我认为只要它是在设计阶段就明确了应用在哪个方法上，它就没有问题，只能说命名方法不好，如果在设计阶段未定义，这样搞才是一个"修补型项目"。
对于dw项目，架构设计对于项目的影响相对其他项目来说要大一些，除了已经讨论的，大家是否有其他的应对，或者我们可以提炼一下，形成一个当前的最佳实践应用到后续项目中。即使没有结果也是很好的交流。
innovate511
那么我说的情况，都是客户有批量查询、随时对各个主题查询的可能。在大项目中，Operational
Data Store，从定义来讲，结构还是OLTP，所以被认为“The
ODS stage is sometimes skipped if it is a replication of the
operational
databases”，那么如果数据源很复杂，有多个数据源的话，将是必须的。
有一点我要说明的是，如果有的ODS层也有事实表什么的拿给前端查询，就和本身的定义不符，已经是DW的概念，作为前端应用，那是data
mart的责任。所以我的建议是，不要把查询看作是独立的应用，也不要把ODS轻易忽略掉。
我刚才说的重点，并不是他命名，命名只是个表面现象，因为既然项目需要一个中间层来过渡，为啥设计的时候没有考虑到呢，非要临到应用才临时搞个临时表过渡？
DW项目的项目质量保证还有个重点，就是开发和测试，我可以另外开一个话题讨论。至于也是至关重要的客户交流、调研，做个N多项目的人都有经验，我就不另外开话题了。
dumpedjoe
mart来应对不是好的方法，data
mart对于查询应该是集中在分析型业务人员在分析之后，对于分析结果可能产生的查询要求，类似CIF中提到discover（是不是这角色不确定，呵呵），比如某人某天发现怎么某客户的贡献度比上月差很多啊，钻取到原子数据来看看，而ODS应对的是习惯性的查询要求，每天都要做，一做一大批，业务系统和dm能做啊，可是对于正常响应业务或分析操作就有影响。
我很认同查询不是独立的应用，在bi系统中，分析和查询的需求都会有，所以我们才不能一股脑将查询需求丢给dm，ods的必要性也在于此。而且在ods中围绕“明确”的需求在源业务表上作聚合没问题，什么都不干搞它做什么，与数据源的多少无关，它也不是事实表。
大家对海量数据的情况下，使用何种架构能够保证装载和转换的性能聊聊吧，：）。
innovate511
之所以最佳的办法是在DM这一层供客户查询，就是考虑到了客户复杂的，批量的查询需求。在ODS查询的话，客户需要一个复杂的查询，难道你需要关联好多大表，如果实在太难，你就对客户说，不好意思，逻辑太复杂，实现不了？客户肯定就会纳闷，既然你能实现复杂的报表和OLAP分析，为啥我复杂的查询不行呢？
还有，ODS层在绝大多数项目中，是供DW的数据源，不知道你把ODS作为查询数据源后，DW是否通过直接通过各个数据源直接装载呢，还是ODS也担当这个功能呢？
至于如何保证装载和转换的性能，在设计中，设计者总体思路是估量项目的数据量和业务量，然后就可以定论如何分层，分表如何分。kimball他们在书中只是写了大概要有staging
area,
conform层等，其实现实的大型项目中，还可以多加一些过渡层，以保证效率。因为不同项目选择ETL方式不同，有的选择使用工具，有的选择自己开发。如果自己开发的话，所有转换都在存储过程中进行，对于海量数据来说不是最好的办法，因为占用数据库的资源太大。建议把数据拿到c/java等程序里转换后，再load回去，减少数据库负担。这里说到了部分软件工程的问题了。
dumpedjoe
- :-))))
客户复杂的，批量的查询需求。在ODS查询的话，客户需要一个复杂的查询，难道你需要关联好多大表,如果实在太难，你就对客户说，不好意思，逻辑太复杂，实现不了？
- 明确？聚合！
ODS层在绝大多数项目中，是供DW的数据源 - ???
如果自己开发的话，所有转换都在存储过程中进行，对于海量数据来说不是最好的办法，因为占用数据库的资源太大。建议把数据拿到c/java等程序里转换后，再load回去，减少数据库负担。这里说到了部分软件工程的问题了。-
dumpedjoe
面向主题的
集成的
易变的
明细的
反映当前数据值的
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的技术复杂原因所在。
dumpedjoe
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.
innovate511
还有比较反感的定义就是什么实时数据仓库，无论你怎么设计数据仓库，始终脱离不了“历史的”特性，何来实时之说，蒙客户呢？现在客户懂得可比以前多了。
innovate511
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
我认为把项目中成熟的东西用概念“封装”一下是走向成熟的标志，不是包装啊，个人观点，就好像kimball把dw分为四个component，几位老大都是做概念封装嘛，有能出书而且易懂顺便搞点小钱。
我想大家早就了解了概念的相对性，例如实时，现在的客户不好蒙哦，但是和他们说实时也不至于让他们如此狂躁，呵呵。
不说了，到此为止，言语如有不敬之处，innovate511休怪，非我本意，就技术问题讨论讨论而已。
刘庆
所以我对现在很多人对概念的操作深恶痛绝，搞了半天本质的东西还是没变。IV类ODS就是我说的那种形式的DM，非要说成ODS，.....
innovate511
dumpedjoe
我想此方案应用的差异和组织结构密切相关，组织结构和该组织在业务领域的成熟度又有关系，这应该是当前国内应用较少的一个原因。
innovate511
如果项目实际情况是，ODS使用的机器有宽裕的负载，而DM的机器很一般，不能给客户足够的支持，ok,
你可以把这部分工作拿到DOS机器上去完成，只要能准确、按时完成客户的需求，就是好的项目。但是把这个层逻辑上归为ODS层太为牵强，别人很可能不知道你想干什么。
happy
我想在项目中我们进行架构设计时，一定会考虑这么几个问题：
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正如几位所讨论的，在数据仓库架构中是非常重要的，我们这么花精力讨论是很值得的，也希望有更多的话题把我们聚到一起。:)
thanks
致
礼！
happy
2006-02-27
_ _ _ _
/_/_/_/_/\
/_/_/_/_/\/\
/_/_/_/_/\/\/\
\_\_\_\_\/\/\/
\_\_\_\_\/\/
\_\_\_\_\/
丁西宁
数据仓库咨询顾问
蓬天信息系统（北京）有限公司
Prient Corporation
Power Realtime Intelligent ENTerprise
北京市朝阳区东大桥路8号尚都国际中心25层
电话：8610-58700800 ext 843
传真：8610-58700800 ext 808
手机：86-13910959723
E-mail：xinin...@prient.com
MSN:happ...@hotmail.com
BLOG:http://java.mblogger.cn/happyjava
http://www.prient.com
无名
我以为，不同的软件系统有不同的架构描述方法，比如一个纯粹的系统集成项目（比如搭建一个各种硬件构成的网络）架构重点在于描述网络连接、硬件配置、功能原理和性能原理；而一个纯软件项目（比如开发一个基于Windows的视频播放软件）架构重点在于描述后台引擎的参数以及人机界面的设计原则。而一个数据仓库项目，系统架构和数据仓库模型的逻辑设计架构也不是一码事，大家讨论的应该是在数据仓库设计架构这个范畴，而这仅仅是系统架构中的一个组成部分而已，我现在想说的，是系统架构。
我想说的第一个问题，是架构的完整性，原因是所谓架构是对某个东西的完整的描述，通过看架构，能够知道这个东西是干什么用的，由什么东西构成，大致长什么样子。比如我们说一个建筑物的架构，先说这个楼是干什么用的，商用？还是住宅？还是商住两用？之所以要先说明这个，是别人能够有个大致的想象，同时能够根据这个来初步判断架构设计是否能够符合这个用途的要求。对于软件系统来说，说一个字处理软件或者一个播放软件或者一个ERP软件，大家先心里有个谱。就比如说数据仓库吧，大家至少都知道有个ETL、存储、展现等等。
然后说建筑物的话，我们说大概有多少层？大概有多高？软件系统也一样，现在流行分层，我觉得可能是老外吃汉堡的时候得到的灵感，一层一层又一层，每层都夹个什么东西，先说吧，你这个数据仓库系统有几层，每一层干啥？
再说一个建筑物，除了各层之外，还分功能区，比如住宅楼的楼梯、居室、卫生间、厨房等等；数据仓库中对系统每一层的区划也有不同，比如主题域划分、功能域划分等等。
另外一个完整的建筑有很多子系统与整体架构融合在一起，比如：强电系统、弱电系统、网络与通信系统、上下水系统、燃气系统、空调系统、安保系统、消防系统等等，那么对于一个数据仓库来说，也有各种系统在整体架构中融合：元数据管理系统、安全控制系统、数据传输系统、数据存储系统、质量控制系统、备份和容灾系统、接口系统，可以说每个子系统中都包含若干功能块，作为架构设计，也可以详加说明。
再说建筑物的材料部分，各种系统以及整体架构需要用物料来实现，比如钢混结构、钢架结构、木结构等等；那么对于数据仓库系统来说，各个子系统都需要用什么样的材料（软件工具和硬件设备）来实现？
还说一个建筑物假设已经盖好了，需要有一系列的管理规则来保证建筑物的安全和正常使用，比如保洁工、保安员、管理员以及相关的工作制度，以及对住户的一些行为约束等等，那么数据仓库中，是不是也需要说明不同的角色在系统中的职能和工作规范呢？我疑惑的是，这个软性的内容是不是应该属于架构设计范畴？
上面写的东西有点乱，总结一下：架构设计要说明系统的功能设计目标、分层方法、附属子系统功能说明，软硬件部署方案，其实没一块内容都够复杂，都需要根据需求和要求进行“设计”的，而不是剪刀加糨糊能搞定的......东西够多，我只是遗憾通常受关注的只是数据仓库建模的架构，而整体系统架构却少有人讨论。
You received this message because you are subscribed to the Google Groups "ttnn BI
观点(252成员)" group.
To post to this group, send email to tt...@googlegroups.com
To unsubscribe from this group, send email to ttnn-uns...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/ttnn
-~----------~----~----~----~------~----~------~--~---
innovate511
table强，这是很显然的，客户的查询不会简单地按照OLTP系统的逻辑，一个一个得查询，可能是一个复杂的查询，这个时候OLTP要做的事情就是多表关联，而我们的汇总conform
table是经过聚合的表，不需要关联就可以满足客户的各种复杂的查询需求。这是我不明白为啥要在ODS层做数据展现的原因之一。
其次，既然ODS是OLTP系统到DW之间的一个逻辑层，那就没有经过复杂的ETL，对不？举个很简单的例子，某大客户经理要查某区县欠费100元-200元之间的属于某大型单位的年龄在30岁以上客户详细资料已经最近的消费明细，那是否要在ODS中关联好几个表来达到他们频繁的查询目的呢？
我也做过很多国内项目，客户的有的及时性需求是存在的，但是不普遍，没有非要给出个新概念给客户感觉这个新概念肯定ok的必要吧，除非这些客户对数据仓库的了解都比较业余。所谓near
realtime只是针对某个很棘手的分析主题，能快速相应客户信息的变化，这种情况一般为单一主题的情况，完全可以和“传统DW”分开来设计和实施（看具体情况，只是逻辑上至少要分开）。这样的需求一般数据量不会很大，这是能快速相应，接近事实的前提，技术和设计上没有什么需要革新。