这是2006年发生在ttnn上的一段有趣的交流...也许有助于我们对ODS的了解
innovate511
查看个人资料
（1 个用户） 更多选项 2006年2月22日, 下午2时25分
发件人："innovate511"
日期：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
日期：Thu, 23 Feb 2006 10:40:26 +0800
当地时间：2006年2月23日(星期四) 上午10时40分
主题：Re: 怎样的架构设计才是真正的数据仓库架构（原创）
答复作者 | 转发 | 打印 | 单个帖子 | 显示原始邮件 | 报告此帖 | 查找此作者的帖子
按照对业务和数据的理解后，如何去进行架构设计呢，一个好的合格的架构设计包括哪几方面内容呢？大家按照各自经验给些意见和指导。。。
2006/2/22, innovate511 :
> 在各个网站和论坛，一说到数据仓库，基本都想到了"ETL※DW※OLAP"，一说到数据仓库设计，就是按照行业规范和客户需求调研，设计主题，然后设计对应的事实表、维表。但是，这就是真正的数据仓库总体设计么？
--
胡海飞
DW & BI,EAI,IRP
MSN：flyingfox1...@hotmail.com
QQ:6184771
刘庆
查看个人资料
（1 个用户） 更多选项 2006年2月23日, 下午1时03分
发件人："刘庆"
日期：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
日期：Thu, 23 Feb 2006 15:34:12 +0800
当地时间：2006年2月23日(星期四) 下午3时34分
主题：Re: Re: 怎样的架构设计才是真正的数据仓库架构（原创）
答复作者 | 转发 | 打印 | 单个帖子 | 显示原始邮件 | 报告此帖 | 查找此作者的帖子
与架构设计相关联的是仓库的容量规划。包括用什么样的硬件、软件、多大的存储，满足什么样的性能，在未来1年、至若干年如何扩充以适应需求增长。数据仓库的容量规划也可以是个单独的话题，但在我们的实施中，它属于架构设计部分，而且是个难点。
happy
查看个人资料
更多选项 2006年2月23日, 下午4时53分
发件人："happy"
日期：Thu, 23 Feb 2006 16:53:1 +0800
当地时间：2006年2月23日(星期四) 下午4时53分
主题：Re: 怎样的架构设计才是真正的数据仓库架构（原创）
答复作者 | 转发 | 打印 | 单个帖子 | 显示原始邮件 | 报告此帖 | 查找此作者的帖子
想请教一个问题，增加分表指的是什么意思？
是指由于转换规则太复杂，把原来的一次转换分成多次转换，把转换的中间数据放在临时表中呢？
还是由于表中记录数很大，所以按照业务需求、以及今后查询的特点进行的分区处理呢？
还是在刚开始设计事实表时，根据业务的不同进行分类，把不同业务数据分别放在不同的表中呢？
谢谢
happy
- 隐藏被引用文字 -
- 显示引用的文字 -
-----Original Message-----
innovate511
查看个人资料
（1 个用户） 更多选项 2006年2月22日, 下午2时25分
发件人："innovate511"
日期：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
日期：Thu, 23 Feb 2006 10:40:26 +0800
当地时间：2006年2月23日(星期四) 上午10时40分
主题：Re: 怎样的架构设计才是真正的数据仓库架构（原创）
答复作者 | 转发 | 打印 | 单个帖子 | 显示原始邮件 | 报告此帖 | 查找此作者的帖子
按照对业务和数据的理解后，如何去进行架构设计呢，一个好的合格的架构设计包括哪几方面内容呢？大家按照各自经验给些意见和指导。。。
2006/2/22, innovate511 :
> 在各个网站和论坛，一说到数据仓库，基本都想到了"ETL※DW※OLAP"，一说到数据仓库设计，就是按照行业规范和客户需求调研，设计主题，然后设计对应的事实表、维表。但是，这就是真正的数据仓库总体设计么？
--
胡海飞
DW & BI,EAI,IRP
MSN：flyingfox1...@hotmail.com
QQ:6184771
刘庆
查看个人资料
（1 个用户） 更多选项 2006年2月23日, 下午1时03分
发件人："刘庆"
日期：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
日期：Thu, 23 Feb 2006 15:34:12 +0800
当地时间：2006年2月23日(星期四) 下午3时34分
主题：Re: Re: 怎样的架构设计才是真正的数据仓库架构（原创）
答复作者 | 转发 | 打印 | 单个帖子 | 显示原始邮件 | 报告此帖 | 查找此作者的帖子
与架构设计相关联的是仓库的容量规划。包括用什么样的硬件、软件、多大的存储，满足什么样的性能，在未来1年、至若干年如何扩充以适应需求增长。数据仓库的容量规划也可以是个单独的话题，但在我们的实施中，它属于架构设计部分，而且是个难点。
happy
查看个人资料
更多选项 2006年2月23日, 下午4时53分
发件人："happy"
日期：Thu, 23 Feb 2006 16:53:1 +0800
当地时间：2006年2月23日(星期四) 下午4时53分
主题：Re: 怎样的架构设计才是真正的数据仓库架构（原创）
答复作者 | 转发 | 打印 | 单个帖子 | 显示原始邮件 | 报告此帖 | 查找此作者的帖子
想请教一个问题，增加分表指的是什么意思？
是指由于转换规则太复杂，把原来的一次转换分成多次转换，把转换的中间数据放在临时表中呢？
还是由于表中记录数很大，所以按照业务需求、以及今后查询的特点进行的分区处理呢？
还是在刚开始设计事实表时，根据业务的不同进行分类，把不同业务数据分别放在不同的表中呢？
谢谢
happy
- 隐藏被引用文字 -
- 显示引用的文字 -
-----Original Message-----
来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/7178747/viewspace-161262/，如需转载，请注明出处，否则将追究法律责任。
转载于:http://blog.itpub.net/7178747/viewspace-161262/
66
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
