怎样的架构设计才是真正的数据仓库架构（转载）

这是2006年发生在ttnn上的一段有趣的交流...也许有助于我们对ODS的了解
innovate511
查看个人资料
（1 个用户） 更多选项 2006年2月22日, 下午2时25分
发件人："innovate511" <[e-mail]>
日期：Tue, 21 Feb 2006 22:25:13 -0800
当地时间：2006年2月22日(星期三) 下午2时25分
主题：怎样的架构设计才是真正的数据仓库架构（原创）
答复作者 | 转发 | 打印 | 单个帖子 | 显示原始邮件 | 报告此帖 | 查找此作者的帖子
在各个网站和论坛，一说到数据仓库，基本都想到了"ETL※DW※OLAP"，一说到数据仓库设计，就是按照行业规范和客户需求调研，设计主题，然后设计对应的事实表、维表。但是，这就是真正的数据仓库总体设计么？

关于上面说的主题设计，以及前端展现，这是给客户的最终用户看的，他们只关心你能给他们带来什么，是否满足他们的报表、查询和分析需求。但是对于厂商自己来说，需要清楚自己实施项目时要干什么，就像复杂的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
查看个人资料
更多选项 2006年2月23日, 上午10时40分
发件人：huhaifei <[e-mail]>
日期：Thu, 23 Feb 2006 10:40:26 +0800
当地时间：2006年2月23日(星期四) 上午10时40分
主题：Re: 怎样的架构设计才是真正的数据仓库架构（原创）
答复作者 | 转发 | 打印 | 单个帖子 | 显示原始邮件 | 报告此帖 | 查找此作者的帖子

按照对业务和数据的理解后，如何去进行架构设计呢，一个好的合格的架构设计包括哪几方面内容呢？大家按照各自经验给些意见和指导。。。

2006/2/22, innovate511 <[e-mail]>:

> 在各个网站和论坛，一说到数据仓库，基本都想到了"ETL※DW※OLAP"，一说到数据仓库设计，就是按照行业规范和客户需求调研，设计主题，然后设计对应的事实表、维表。但是，这就是真正的数据仓库总体设计么？

--
胡海飞
DW & BI,EAI,IRP
MSN：[e-mail]
QQ:6184771


刘庆
查看个人资料
（1 个用户） 更多选项 2006年2月23日, 下午1时03分
发件人："刘庆" <[e-mail]>
日期：Thu, 23 Feb 2006 13:03:19 +0800
当地时间：2006年2月23日(星期四) 下午1时03分
主题：Re: 怎样的架构设计才是真正的数据仓库架构（原创）
答复作者 | 转发 | 打印 | 单个帖子 | 显示原始邮件 | 报告此帖 | 查找此作者的帖子

架构设计究竟怎么进行，包括什么内容。前两天一个朋友熬夜要完成这份文档，因为第二天就要提交，看，这本身是有问题的吧。架构设计怎么如此仓促？它的设计对以后整个项目的体系都是影响重大。所以，我想如果仅仅是写一份客户需要的《总体设计文档》，ctrlc，ctrlv也就够了。然而如果是要实在考虑如何架构一个BI系统，有必要琢磨一下。

首先看看架构设计中包括那些内容，再来反过来看看它为什么人服务。

架构中重点是描述系统的结构，以及他们之间的关联、交互接口。BI系统可以划分成业务模型、元数据、数据质量、接口平台、报表集市、指标库等。可以看到，这里命名这些模块都是静态的名词，而不是动词，例如业务建模、数据质量管理等，之所以如此，是因为这是在描述系统的结构而非功能。

业务模型是存放业务数据的结构，可以再细分，成ODS、DW（还可以细分）、DM等，它是支撑业务分析需求的，例如报表、仪表盘、OLAP、专题应用等。而元数据是为整个系统数据的形态和数据流动的过程起到支撑作用，也就是说数据从源头开始，到最终的用户眼前，其来龙去脉，每个环节的状态都需要掌握。而数据质量模块是为衡量数据源质量、ETL过程处理质量提供支撑。接口平台是处于源系统和数据仓库系统之间的，方便明确界定双方职责的模块。报表集市为报表应用提供支持，指标库为绩效管理需求提供支持，后两者其实还可以归入业务模型一类，因为它们都是服务于分析需求的。

之所以分成若干模块，是为了让架构清晰，降低这些模块之间的耦合，如此的构成是否合理呢？还得看看这个架构面临的需求到底是什么，将系统的用户分为两大类角色：
1、 系统运营角色，他们对系统的正常运行、维护负责；
2、 业务分析角色，他们需要从这个系统得到数据分析的功能；

显然，第二种角色的分析数据来源都都将来自业务模型模块。而第一种角色将从剩下的模块中满足自己的需要，可以说，他们绝对不直接和业务模型这个模块打交道。在架构设计中，重点应该放在如何满足系统管理用户的需求上面，当然是"重点"，而非舍弃业务分析角色，毕竟在业务模型模块中，根据业务的特点、数据量的特点、分析应用的特点，来进一步细化。

这里有个自己的理解要说明一下，架构设计应该是于具体业务关系不大的，这种架构应该是半通用的。之所以是半通用，在系统功能上面，BI项目大同小异，而在业务需求上面，架构中只需要对客户的业务、分析需求分成几个大类，例如按行业分业务模型，按OLAP、报表来为分析应用分类，不要太过细节。

来看看这系统运营角色的需求罢，还可以对这类角色细分成：
1、 开发设计者。之所以将开发者作为系统的用户，是因为数据仓库项目应该看作一个过程，而不是产品，因此在开发阶段，其实其架构最重要的用户就是开发者，当然要为之提供便利。
2、 系统管理员。系统交付之后，如何监控系统运行、发现数据质量问题、应付新的分析需求等。

那么对于开发实施人员，他需要进行系统部署、ETL的开发调试、质量的稽核；设计人员，需要进行模型的变更、系统调优、作系统一致性分析等；而系统管理员则需要监控ETL过程、监控系统运行、响应系统警报、接口数据管理等。这些都可以看作是用例。

面对这些用例，它们是架构设计的"需求"，如何满足他们，并且保持良好的体系和清晰的结构。能够易于维护，且能够满足日后肯定会增加的业务需求。

说了这么多，主要要表述的观点是：
1、架构设计主要面向系统用户为主；
2、架构设计的内容主要包括：系统功能需求、分析需求分类；支持这两者的后台结构，结构的粗略划分，以让其内部能够保持简单的交互方式。
3、架构设计和详细设计究竟如何界定的？在架构设计中，不要出现诸如"欠费账龄"、"信用等级"这样的业务术语。


goldenfish3
查看个人资料
更多选项 2006年2月23日, 下午3时34分
发件人：goldenfish3 <[e-mail]>
日期：Thu, 23 Feb 2006 15:34:12 +0800
当地时间：2006年2月23日(星期四) 下午3时34分
主题：Re: Re: 怎样的架构设计才是真正的数据仓库架构（原创）
答复作者 | 转发 | 打印 | 单个帖子 | 显示原始邮件 | 报告此帖 | 查找此作者的帖子

与架构设计相关联的是仓库的容量规划。包括用什么样的硬件、软件、多大的存储，满足什么样的性能，在未来1年、至若干年如何扩充以适应需求增长。数据仓库的容量规划也可以是个单独的话题，但在我们的实施中，它属于架构设计部分，而且是个难点。


happy
查看个人资料
更多选项 2006年2月23日, 下午4时53分
发件人："happy" <[e-mail]>
日期：Thu, 23 Feb 2006 16:53:1 +0800
当地时间：2006年2月23日(星期四) 下午4时53分
主题：Re: 怎样的架构设计才是真正的数据仓库架构（原创）
答复作者 | 转发 | 打印 | 单个帖子 | 显示原始邮件 | 报告此帖 | 查找此作者的帖子
想请教一个问题，增加分表指的是什么意思？
是指由于转换规则太复杂，把原来的一次转换分成多次转换，把转换的中间数据放在临时表中呢？
还是由于表中记录数很大，所以按照业务需求、以及今后查询的特点进行的分区处理呢？
还是在刚开始设计事实表时，根据业务的不同进行分类，把不同业务数据分别放在不同的表中呢？

谢谢

happy

- 隐藏被引用文字 -
- 显示引用的文字 -
-----Original Message-----

>在各个网站和论坛，一说到数据仓库，基本都想到了"ETL※DW※OLAP"，一说到数据仓库设计，就是按照行业规范和客户需求调研，设计主题，然后设计对应的事实表、维表。但是，这就是真正的数据仓库总体设计么？

>关于上面说的主题设计，以及前端展现，这是给客户的最终用户看的，他们只关心你能给他们带来什么，是否满足他们的报表、查询和分析需求。但是对于厂商自己来说，需要清楚自己实施项目时要干什么，就像复杂的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"只是些表面的东西，作为设计者，应该需要知道内部更多，更深入的东西。

--------------------------

thanks！

　　　　　　　　happy
　　　　　　　　[e-mail]
　　　　　　　　　　2006-02-23


innovate511
查看个人资料
更多选项 2006年2月23日, 下午6时11分
发件人："innovate511" <[e-mail]>
日期：Thu, 23 Feb 2006 02:11:50 -0800
当地时间：2006年2月23日(星期四) 下午6时11分
主题：Re: 怎样的架构设计才是真正的数据仓库架构（原创）
答复作者 | 转发 | 打印 | 单个帖子 | 显示原始邮件 | 报告此帖 | 查找此作者的帖子
我也比较了解国内的实际情况，往往是给客户的设计资料比较详细，而内部的设计会粗一些，甚至的有的干脆省略了。而客户只关心大概的东西，看你能不能满足他们的分析需求，或者你能给他们带来什么分析，具体的事情他们不需要管太多。

从业务角度讲，有两种情况，一是客户比较盲目，没有明确的分析需求，这个时候主要就是从现有的数据源出发，再到前端应用的一种从底到顶的一种设计；二是客户有明确的分析需求，这个时候既要从现有从底到顶的设计，还要看现有数据源是否能满足客户特殊的分析需求，如果不能满足，需要尽早提出，并和客户解决数据源的问题，从这个角度说，又是从顶到底的一种模式。

从数据角度讲，如何把数据源到前端应用的线牵起来，通俗的说是一个大的ETL过程，但是庞大的系统需要考虑ETL后的数据质量、一致性、效率等很多因素，于是这个问题需要厂商自己处理，客户不会非常关心，所以才有很多遗留问题。



[e-mail]
查看个人资料
更多选项 2006年2月23日, 下午6时13分
发件人："[e-mail]" <[e-mail]>
日期：Thu, 23 Feb 2006 02:13:32 -0800
当地时间：2006年2月23日(星期四) 下午6时13分
主题：Re: 怎样的架构设计才是真正的数据仓库架构（原创）
答复作者 | 转发 | 打印 | 单个帖子 | 显示原始邮件 | 报告此帖 | 查找此作者的帖子
我想增加分表是按照业务的区别将数据分为多个事实表存放，这样毫无关联的数据就可以分别存放在不同的事实表中。之前我参与的一个电力决策系统，其中层次就设计分成了5个层次：ODS，临时层，DW，聚合层，DM，这样虽然ETL起来比较麻烦，但是非常灵活，可以方便地根据用户需求而改变；其中事实表也是按照不同的业务分成了多个事实表

- 隐藏被引用文字 -
- 显示引用的文字 -
happy wrote:
> 想请教一个问题，增加分表指的是什么意思？
> 是指由于转换规则太复杂，把原来的一次转换分成多次转换，把转换的中间数据放在临时表中呢？
> 还是由于表中记录数很大，所以按照业务需求、以及今后查询的特点进行的分区处理呢？
> 还是在刚开始设计事实表时，根据业务的不同进行分类，把不同业务数据分别放在不同的表中呢？

> 谢谢

> happy

> -----Original Message-----

> >在各个网站和论坛，一说到数据仓库，基本都想到了"ETL※DW※OLAP"，一说到数据仓库设计，就是按照行业规范和客户需求调研，设计主题，然后设计对应的事实表、维表。但是，这就是真正的数据仓库总体设计么？

> >关于上面说的主题设计，以及前端展现，这是给客户的最终用户看的，他们只关心你能给他们带来什么，是否满足他们的报表、查询和分析需求。但是对于厂商自己来说，需要清楚自己实施项目时要干什么，就像复杂的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"只是些表面的东西，作为设计者，应该需要知道内部更多，更深入的东西。

> --------------------------

> thanks！

> happy
> [e-mail]
> 2006-02-23



innovate511
查看个人资料
更多选项 2006年2月23日, 下午8时03分
发件人："innovate511" <[e-mail]>
日期：Thu, 23 Feb 2006 04:03:10 -0800
当地时间：2006年2月23日(星期四) 下午8时03分
主题：Re: 怎样的架构设计才是真正的数据仓库架构（原创）
答复作者 | 转发 | 打印 | 单个帖子 | 显示原始邮件 | 报告此帖 | 查找此作者的帖子
分表目前在很多项目中已经使用，只是还是比较随意，没有在总体架构设计中作为一个层出现。
而且在实际项目中，分表和你说的中间数据是两回事，而且规范的数据仓库不会把任务流程中的数据放在临时表中，那是非常不规范的，因为如果一旦有问题，中间的数据就断了，数据质量无法保证。

所以分表，就是同一个数据源，本来可以放在一个事实表，但由于数据量太大，或者业务太复杂，一个事实表很难包含所有主题的信息，于是考虑按照某种业务需求分成多个相似主题的事实表。这个没有统一的定论，需要按实际需求设计。比如一个主题分为日报、周报、月报等不同的分析周期，那么可以分为xx_day_fact,xx_wkly_fact,month_wkly_fact；如果用户经常察看的日分析是2个月的数据，那么你的当前事实表只存2个月的数据，其他的放在xx_his_fact中，再久的放到磁带库（比如2年前的）。类似的分类分表的方法很多，就不一一介绍了。

而所谓的中间数据，也并不是简单的汇总，以前的一些项目，很多根本没用国外很成熟的概念confirm
fact
table聚合一个涵盖丰富信息的事实表，而直接汇总，是一个很典型的案例。一般标准点的项目会把confirm
tables作为一个层，出现在总体架构设计中，成为前端应用汇总信息的重要通道。




刘庆
查看个人资料
更多选项 2006年2月24日, 下午12时11分
发件人："刘庆" <[e-mail]>
日期：Fri, 24 Feb 2006 12:11:09 +0800
当地时间：2006年2月24日(星期五) 下午12时11分
主题：Re: 怎样的架构设计才是真正的数据仓库架构（原创）
答复作者 | 转发 | 打印 | 单个帖子 | 显示原始邮件 | 报告此帖 | 查找此作者的帖子

这个confirm table，一直没整明白是干啥的。按照Innovate的描述，它是一种"聚合一个涵盖丰富信息的事实表"。如此，我理解的confirm
table，恐怕就是那种主题表，例如用户信息表（一系列），这些表的粒度是其描述的实体决定的，针对这种实体的汇总信息表。常见的实体包括用户、客户、渠道、产品、资源、竞争对手等。
其实业务数据模型设计，区分成ODS、DW和DM，他的*架构*目的有二：
1、为了能够满足用户可能变化的分析需求；
2、要不就是为了查询性能的需求。

confirm
table概念的提出总归是要解决这两个问题或其中一个吧。如果是上面理解的那种，目前很多公司的模型设计已经有这样的分层，直接从事实表（ODS表）建立一个若干维度若干度量的汇总表，那是很早以前的做法了。

至于"分表"这种叫法，觉着是个比较含糊的术语。在项目实施中，存在一种现象。为了满足用户新需求的时候，或提高性能，去修改模型，可能就需要"分表"，但通常会出现诸如tmp_xxx的临时表，甚至是以设计者名字命名的表，将他们当作临时表，但很可能他们并非临时的，会融入到实际的流程当中，导致混乱。这是因为在架构的时候缺乏概念设计的结果。整个系统的架构应该能够形成一个概念体系，底层物理的每个表，每个操作都能够归属到某个逻辑或是概念上。

例如增加一个临时的汇总表，那么就严格规定，此表不能放入常规的ETL流程当中，因为那样会导致概念混乱。如果按照周期分表，同样在上层应该是有"不同周期主题表"的概念。
所谓概念，其实就是给个名份。数据仓库中分那么多层次，ods、dw不都是数据倒来倒去吗，甚至都可以叫它们作"中间表"，可这不是一个清晰的概念，于是就产生了细分。就像你叫一个人，"哎，女人"，这多不尊敬人，如果叫"小丽啊"，人家就爱听了。
On 2/23/06, innovate511 <[e-mail]> wrote:

- 隐藏被引用文字 -
- 显示引用的文字 -
> 分表目前在很多项目中已经使用，只是还是比较随意，没有在总体架构设计中作为一个层出现。

> 而且在实际项目中，分表和你说的中间数据是两回事，而且规范的数据仓库不会把任务流程中的数据放在临时表中，那是非常不规范的，因为如果一旦有问题，中间的数据就断了，数据质量无法保证。

> ...



happy
查看个人资料
更多选项 2006年2月24日, 下午12时54分
发件人："happy" <[e-mail]>
日期：Fri, 24 Feb 2006 12:54:28 +0800
当地时间：2006年2月24日(星期五) 下午12时54分
主题：Re: Re: 怎样的架构设计才是真正的数据仓库架构（原创）
答复作者 | 转发 | 打印 | 单个帖子 | 显示原始邮件 | 报告此帖 | 查找此作者的帖子
谢谢innovate511对我问题的解答，还是有几个问题再请教一下：

>分表和你说的中间数据是两回事，而且规范的数据仓库不会把任务流程中的数据放在临时表中，那是非常不规范的，因为如果一旦有问题，>中间的数据就断了，数据质量无法保证。

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
　　　　　　　　[e-mail]
　　　　　　　　　　2006-02-24


innovate511
查看个人资料
更多选项 2006年2月24日, 下午2时30分
发件人："innovate511" <[e-mail]>
日期：Thu, 23 Feb 2006 22:30:51 -0800
当地时间：2006年2月24日(星期五) 下午2时30分
主题：Re: 怎样的架构设计才是真正的数据仓库架构（原创）
答复作者 | 转发 | 打印 | 单个帖子 | 显示原始邮件 | 报告此帖 | 查找此作者的帖子
我以前就说过，有好多人想在ODS层做所谓的汇总表作为前端查询的做法是非常不明智和不科学的。数据仓库是个工程，你想怎么做都可以一定程度地实现客户的需求，所以才会出现很多厂商想当然地去做，因为他们觉得那样也能满足客户的需求，但是他们没有搞清楚，什么的方式才是最佳的。

大家很多都看过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
查看个人资料
更多选项 2006年2月25日, 上午1时43分
发件人："innovate511" <[e-mail]>
日期：Fri, 24 Feb 2006 09:43:13 -0800
当地时间：2006年2月25日(星期六) 上午1时43分
主题：Re: 怎样的架构设计才是真正的数据仓库架构（原创）
答复作者 | 转发 | 打印 | 单个帖子 | 显示原始邮件 | 报告此帖 | 查找此作者的帖子
to happy
不好意思，我有个事情没有澄清清楚，分表可以分为业务分表，和过渡分表。你说的那种情况基本属于过渡分表，目的就是为了分散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
查看个人资料
更多选项 2006年2月25日, 下午1时39分
发件人："dumpedjoe" <[e-mail]>
日期：Sat, 25 Feb 2006 05:39:09 -0000
当地时间：2006年2月25日(星期六) 下午1时39分
主题：Re: 怎样的架构设计才是真正的数据仓库架构（原创）
答复作者 | 转发 | 打印 | 单个帖子 | 显示原始邮件 | 报告此帖 | 查找此作者的帖子
在项目（不仅仅是dw）中，架构设计师能够根据自身的技能和经验对于今后要面对的性能、数据质量、可扩展性等要求给出相应的应对方法是一个基本要求，问题是好的数据仓库架构是什么样的，针对不同的系统状况和业务需要，哪些是作为标准组件必需引入的，哪些是可以根据具体情况进行裁剪或合并的，我想这也是胡海飞希望大家能够深入探讨的，当然inmon和kimball以及其它各位老大早就给出了他们的答案，在这里我们对具体细节讨论一下，比如分表、confirm
fact table、ods等等。
在这里说说我对ods的理解，和innovate511
略有不同，作为可选组件，ods是dw的一个补充，对于用户明确的查询和统计需求，为了减轻源系统的压力，引入ods，在其中针对确定的需求进行聚合，提供给前端操作型业务人员进行查询，dw在一定程度上能够满足这样的需求，但是分析型业务人员和操作性型业务人员的目的完全不同，虽然前者偶尔会访问到操作型人员经常访问的数据。
源系统
/
明确的查询需求 分析需求
/
Ods dw or dm
/
操作型业务人员 分析人员
对于无批量查询需求的项目来说，ods就没有必要，也不能成为某一个层次，更不能承上启下。
至于分表命名为tmp_***，我认为只要它是在设计阶段就明确了应用在哪个方法上，它就没有问题，只能说命名方法不好，如果在设计阶段未定义，这样搞才是一个"修补型项目"。
对于dw项目，架构设计对于项目的影响相对其他项目来说要大一些，除了已经讨论的，大家是否有其他的应对，或者我们可以提炼一下，形成一个当前的最佳实践应用到后续项目中。即使没有结果也是很好的交流。



innovate511
查看个人资料
更多选项 2006年2月25日, 下午2时54分
发件人："innovate511" <[e-mail]>
日期：Fri, 24 Feb 2006 22:54:47 -0800
当地时间：2006年2月25日(星期六) 下午2时54分
主题：Re: 怎样的架构设计才是真正的数据仓库架构（原创）
答复作者 | 转发 | 打印 | 单个帖子 | 显示原始邮件 | 报告此帖 | 查找此作者的帖子
首先，架构设计的重要性，是针对项目越庞大（包括数据量和业务复杂度），越是重要。举个很简单的例子，我做过得最小的项目，就是某地级市电信运营商的竞争对手分析，就那么一个主题，数据量也不大，需要啥架构呢？只要业务明确，你想咋做都可以，前端报表和OLAP都做得不错，客户就能满意。所以我前面的讲的假设，基本是大项目基础上。

那么我说的情况，都是客户有批量查询、随时对各个主题查询的可能。在大项目中，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
查看个人资料
更多选项 2006年2月26日, 下午1时04分
发件人："dumpedjoe" <[e-mail]>
日期：Sun, 26 Feb 2006 05:04:31 -0000
当地时间：2006年2月26日(星期日) 下午1时04分
主题：Re: 怎样的架构设计才是真正的数据仓库架构（原创）
答复作者 | 转发 | 打印 | 单个帖子 | 显示原始邮件 | 报告此帖 | 查找此作者的帖子
主题少，数据量小，业务明确就不要架构我不能认同，好的架构是对后续会发生的常见问题有好的应对，难道等该项目结束后，客户觉得不错，再加个主题，数据量增长了以后我们再引入架构重新搞一次？这个暂且不谈，还是说说ODS，再次强调一下“明确”，如果查询需求明确，用data
mart来应对不是好的方法，data
mart对于查询应该是集中在分析型业务人员在分析之后，对于分析结果可能产生的查询要求，类似CIF中提到discover（是不是这角色不确定，呵呵），比如某人某天发现怎么某客户的贡献度比上月差很多啊，钻取到原子数据来看看，而ODS应对的是习惯性的查询要求，每天都要做，一做一大批，业务系统和dm能做啊，可是对于正常响应业务或分析操作就有影响。
我很认同查询不是独立的应用，在bi系统中，分析和查询的需求都会有，所以我们才不能一股脑将查询需求丢给dm，ods的必要性也在于此。而且在ods中围绕“明确”的需求在源业务表上作聚合没问题，什么都不干搞它做什么，与数据源的多少无关，它也不是事实表。
大家对海量数据的情况下，使用何种架构能够保证装载和转换的性能聊聊吧，：）。



innovate511
查看个人资料
更多选项 2006年2月26日, 下午1时46分
发件人："innovate511" <[e-mail]>
日期：Sat, 25 Feb 2006 21:46:45 -0800
当地时间：2006年2月26日(星期日) 下午1时46分
主题：Re: 怎样的架构设计才是真正的数据仓库架构（原创）
答复作者 | 转发 | 打印 | 单个帖子 | 显示原始邮件 | 报告此帖 | 查找此作者的帖子
楼上有没有想过，dm独立一个逻辑块出来，供前端查询？我前面提到过，DM可以是很丰富的一大块，既可以丰富DW的事实表，也可以丰富出来供前面所有应用使用，再复杂的应用，最好的办法就是分层或者分模块。目前我见过得项目中，这种方式应该是最好的，还有其他疑问么？

之所以最佳的办法是在DM这一层供客户查询，就是考虑到了客户复杂的，批量的查询需求。在ODS查询的话，客户需要一个复杂的查询，难道你需要关联好多大表，如果实在太难，你就对客户说，不好意思，逻辑太复杂，实现不了？客户肯定就会纳闷，既然你能实现复杂的报表和OLAP分析，为啥我复杂的查询不行呢？

还有，ODS层在绝大多数项目中，是供DW的数据源，不知道你把ODS作为查询数据源后，DW是否通过直接通过各个数据源直接装载呢，还是ODS也担当这个功能呢？

至于如何保证装载和转换的性能，在设计中，设计者总体思路是估量项目的数据量和业务量，然后就可以定论如何分层，分表如何分。kimball他们在书中只是写了大概要有staging
area,
conform层等，其实现实的大型项目中，还可以多加一些过渡层，以保证效率。因为不同项目选择ETL方式不同，有的选择使用工具，有的选择自己开发。如果自己开发的话，所有转换都在存储过程中进行，对于海量数据来说不是最好的办法，因为占用数据库的资源太大。建议把数据拿到c/java等程序里转换后，再load回去，减少数据库负担。这里说到了部分软件工程的问题了。



dumpedjoe
查看个人资料
更多选项 2006年2月27日, 上午9时12分
发件人："dumpedjoe" <[e-mail]>
日期：Mon, 27 Feb 2006 01:12:42 -0000
当地时间：2006年2月27日(星期一) 上午9时12分
主题：Re: 怎样的架构设计才是真正的数据仓库架构（原创）
答复作者 | 转发 | 打印 | 单个帖子 | 显示原始邮件 | 报告此帖 | 查找此作者的帖子
目前我见过得项目中，这种方式应该是最好的，还有其他疑问么？
- :-))))
客户复杂的，批量的查询需求。在ODS查询的话，客户需要一个复杂的查询，难道你需要关联好多大表,如­果实在太难，你就对客户说，不好意思，逻辑太复杂，实现不了？
- 明确？聚合！
ODS层在绝大多数项目中，是供DW的数据源 - ???
如果自­己开发的话，所有转换都在存储过程中进行，对于海量数据来说不是最好的办法，因为占用数据库的资源太大。建议把数据拿到c/java等程序里转换后，再load­回去，减少数据库负担。这里说到了部分软件工程的问题了。-




dumpedjoe
查看个人资料
更多选项 2006年2月27日, 上午9时23分
发件人："dumpedjoe" <[e-mail]>
日期：Mon, 27 Feb 2006 01:23:33 -0000
当地时间：2006年2月27日(星期一) 上午9时23分
主题：Re: 怎样的架构设计才是真正的数据仓库架构（原创）
答复作者 | 转发 | 打印 | 单个帖子 | 显示原始邮件 | 报告此帖 | 查找此作者的帖子
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的技术复杂原因所在。




dumpedjoe
查看个人资料
更多选项 2006年2月27日, 上午9时46分
发件人："dumpedjoe" <[e-mail]>
日期：Mon, 27 Feb 2006 01:46:01 -0000
当地时间：2006年2月27日(星期一) 上午9时46分
主题：Re: 怎样的架构设计才是真正的数据仓库架构（原创）
答复作者 | 转发 | 打印 | 单个帖子 | 显示原始邮件 | 报告此帖 | 查找此作者的帖子
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.



innovate511
查看个人资料
更多选项 2006年2月27日, 上午11时19分
发件人："innovate511" <[e-mail]>
日期：Sun, 26 Feb 2006 19:19:30 -0800
当地时间：2006年2月27日(星期一) 上午11时19分
主题：Re: 怎样的架构设计才是真正的数据仓库架构（原创）
答复作者 | 转发 | 打印 | 单个帖子 | 显示原始邮件 | 报告此帖 | 查找此作者的帖子
所以我对现在很多人对概念的操作深恶痛绝，搞了半天本质的东西还是没变。IV类ODS就是我说的那种形式的DM，非要说成ODS，从结构层次来说，它已经是面向最终客户应用，被最终ETL的，准备好的数据，在传统定义中，应该类似DM的作用。所以无论怎么定义，本质的东西要抓住。正如我说的，DW的数据源来自聚合业务系统数据的ODS，这个ODS的功能就是集合的、比较干净的OLTP系统，而后面有定义个IV类ODS，从架构层次来说，已经变了本质，是经过ETL的，符合客户查询需求的。两者一个在系统架构的前面，一个在系统架构的后面，为何要使用同一概念，标新立异？莫名其妙。

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



innovate511
查看个人资料
更多选项 2006年2月27日, 上午11时56分
发件人："innovate511" <[e-mail]>
日期：Sun, 26 Feb 2006 19:56:02 -0800
当地时间：2006年2月27日(星期一) 上午11时56分
主题：Re: 怎样的架构设计才是真正的数据仓库架构（原创）
答复作者 | 转发 | 打印 | 单个帖子 | 显示原始邮件 | 报告此帖 | 查找此作者的帖子
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
查看个人资料
更多选项 2006年2月27日, 下午12时00分
发件人："dumpedjoe" <[e-mail]>
日期：Mon, 27 Feb 2006 04:00:14 -0000
当地时间：2006年2月27日(星期一) 下午12时00分
主题：Re: 怎样的架构设计才是真正的数据仓库架构（原创）
答复作者 | 转发 | 打印 | 单个帖子 | 显示原始邮件 | 报告此帖 | 查找此作者的帖子
innovate511过于激动了，呵呵。
我认为把项目中成熟的东西用概念“封装”一下是走向成熟的标志，不是包装啊，个人观点，就好像kimball把dw分为四个component，几位老大都是做概念封装嘛，有能出书而且易懂顺便搞点小钱。

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

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




刘庆
查看个人资料
更多选项 2006年2月27日, 下午12时22分
发件人："刘庆" <[e-mail]>
日期：Mon, 27 Feb 2006 12:22:27 +0800
当地时间：2006年2月27日(星期一) 下午12时22分
主题：Re: 怎样的架构设计才是真正的数据仓库架构（原创）
答复作者 | 转发 | 打印 | 单个帖子 | 显示原始邮件 | 报告此帖 | 查找此作者的帖子

对于innovate提到的"第四类ODS就是之前提到的DM，并且是面向最终客户应用的"说法，在下不赞同。

而对于dumpedjoe说得"第四类ODS是目前我们项目常见的"，也不是非常认同。

这种ODS是一种比较理想化的，但至少在我所经历的项目中从来没有过。但奇怪的是，在我们第一个项目中就考虑到了将分析的结果返回到ODS中，比如客户的信用度评分、价值度评分等。然而这还不能起到作用，所以最后摒弃这种做法。这可以和电信经分里面经常提的"闭环反馈"有些关联吧。然而这不是技术的事，还得看最后分析的结果是否融入业务的流程里面，例如客户真的能够用信用度模型来给每个客户评分，显然，现在还不能做到这一步。

可以说，BI系统的此类模型被认可的不多。因此，也谈不上将分析结果返回到ODS，那是无用之举。

但即便将这些分析结果返回到ODS，并不是说ODS就面向客户应用了。

数据仓库是干什么的，保存企业活动历史数据的，这些数据反映了企业的生产、销售、财务、市场活动的一举一动，而数据分析显然也是企业活动的一种，当然也有必要记录它们的历史。因此，从DM中将数据返回给ODS，用"返回"这个词有些不准确，此时，DM已经像是一个数据源了，可以将它和ERP、CRM系统同等看待。这些分析结果，例如用户信用度吧，同样是用来作分析用的，可以它们进行聚类，评定A、B、C等级，作为OLAP的维度等等。

看我说的有道理吧，嘿嘿。

On 2/27/06, innovate511 <[e-mail]> wrote:

- 隐藏被引用文字 -
- 显示引用的文字 -

> 所以我对现在很多人对概念的操作深恶痛绝，搞了半天本质的东西还是没变。IV类ODS就是我说的那种形式的DM，非要说成ODS，.....
> 还有比较反感的定义就是什么实时数据仓库，无论你怎么设计数据仓库，始终脱离不了"历史的"特性，何来实时之说，蒙客户呢？现在客户懂得可比以前多了。


innovate511
查看个人资料
更多选项 2006年2月27日, 下午12时35分
发件人："innovate511" <[e-mail]>
日期：Sun, 26 Feb 2006 20:35:32 -0800
当地时间：2006年2月27日(星期一) 下午12时35分
主题：Re: 怎样的架构设计才是真正的数据仓库架构（原创）
答复作者 | 转发 | 打印 | 单个帖子 | 显示原始邮件 | 报告此帖 | 查找此作者的帖子
呵呵，我说话不是针对某个人，因为很多地方都在炒概念，我比较反感，我和一个业界朋友一样，赞同用最朴实易懂的方法，有层次有序地给出项目方案，做好项目，这才是客户真正想要的，而不是简单的概念炒作。



dumpedjoe
查看个人资料
更多选项 2006年2月27日, 下午1时39分
发件人："dumpedjoe" <[e-mail]>
日期：Mon, 27 Feb 2006 05:39:21 -0000
当地时间：2006年2月27日(星期一) 下午1时39分
主题：Re: 怎样的架构设计才是真正的数据仓库架构（原创）
答复作者 | 转发 | 打印 | 单个帖子 | 显示原始邮件 | 报告此帖 | 查找此作者的帖子
可以再探讨一下，第四类ods是比较实际的，对于国内的客户来说，因为种种原因，一般都不愿意将dm中的分析结果分享（比返回和回流应该要好理解些，但数据流向不直观，呵呵）给使用ods的操作型业务人员，从技术角度来说实现这一点并不难，主要是应用对象的不同导致了很少采用该方案，而在我经历的一些项目中，客户确实倾向采用该方案，因为组织架构的不同，对于客户信用度以及贡献度等等需要进行主题聚合或跨主题聚合的指标，能够提供给操作型业务人员作为客户评估的一个参照是很重要和必要的，这就类似于SE中的PDCA循环。
我想此方案应用的差异和组织结构密切相关，组织结构和该组织在业务领域的成熟度又有关系，这应该是当前国内应用较少的一个原因。


innovate511
查看个人资料
更多选项 2006年2月27日, 下午4时42分
发件人："innovate511" <[e-mail]>
日期：Mon, 27 Feb 2006 00:42:19 -0800
当地时间：2006年2月27日(星期一) 下午4时42分
主题：Re: 怎样的架构设计才是真正的数据仓库架构（原创）
答复作者 | 转发 | 打印 | 单个帖子 | 显示原始邮件 | 报告此帖 | 查找此作者的帖子
anyway,
如果项目实际情况是，ODS使用的机器有宽裕的负载，而DM的机器很一般，不能给客户足够的支持，ok,
你可以把这部分工作拿到DOS机器上去完成，只要能准确、按时完成客户的需求，就是好的项目。但是把这个层逻辑上归为ODS层太为牵强，别人很可能不知道你想干什么。



happy
查看个人资料
更多选项 2006年2月27日, 下午4时51分
发件人："happy" <[e-mail]>
日期：Mon, 27 Feb 2006 16:51:2 +0800
当地时间：2006年2月27日(星期一) 下午4时51分
主题：Re: 怎样的架构设计才是真正的数据仓库架构（原创）
答复作者 | 转发 | 打印 | 单个帖子 | 显示原始邮件 | 报告此帖 | 查找此作者的帖子
我还是老老实实的从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正如几位所讨论的，在数据仓库架构中是非常重要的，我们这么花精力讨论是很值得的，也希望有更多的话题把我们聚到一起。:)

thanks
　　　　　　　　致
礼！
happy
　　　　　　　　　　2006-02-27

_ _ _ _
/_/_/_/_/
/_/_/_/_//
/_/_/_/_///
\_\_\_\_///
\_\_\_\_//
\_\_\_\_/

丁西宁
数据仓库咨询顾问
蓬天信息系统（北京）有限公司
Prient Corporation
Power Realtime Intelligent ENTerprise

北京市朝阳区