关注数据仓库，关注数据分析，关注BI领域
分类： 数据库开发技术
2011-09-24 23:13:34
关于上面说的主题设计，以及前端展现，这是给客户的最终用户看的，他们只关心你能给他们带来什么，是否满足他们的报表、查询和分析需求。但是对于厂商自己来说，需要清楚自己实施项目时要干什么，就像复杂的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"只是些表面的东西，作为设计者，应该需要知道内部更多，更深入的东西
架构设计究竟怎么进行，包括什么内容。前两天一个朋友熬夜要完成这份文档，因为第二天就要提交，看，这本身是有问题的吧。架构设计怎么如此仓促？它的设计对以后整个项目的体系都是影响重大。所以，我想如果仅仅是写一份客户需要的《总体设计文档》，ctrlc，ctrlv也就够了。然而如果是要实在考虑如何架构一个BI系统，有必要琢磨一下。
首先看看架构设计中包括那些内容，再来反过来看看它为什么人服务。
架构中重点是描述系统的结构，以及他们之间的关联、交互接口。BI系统可以划分成业务模型、元数据、数据质量、接口平台、报表集市、指标库等。可以看到，这里命名这些模块都是静态的名词，而不是动词，例如业务建模、数据质量管理等，之所以如此，是因为这是在描述系统的结构而非功能。
业务模型是存放业务数据的结构，可以再细分，成ODS、DW（还可以细分）、DM等，它是支撑业务分析需求的，例如报表、仪表盘、OLAP、专题应用等。而元数据是为整个系统数据的形态和数据流动的过程起到支撑作用，也就是说数据从源头开始，到最终的用户眼前，其来龙去脉，每个环节的状态都需要掌握。而数据质量模块是为衡量数据源质量、ETL过程处理质量提供支撑。接口平台是处于源系统和数据仓库系统之间的，方便明确界定双方职责的模块。报表集市为报表应用提供支持，指标库为绩效管理需求提供支持，后两者其实还可以归入业务模型一类，因为它们都是服务于分析需求的。
之所以分成若干模块，是为了让架构清晰，降低这些模块之间的耦合，如此的构成是否合理呢？还得看看这个架构面临的需求到底是什么，将系统的用户分为两大类角色：
1、 系统运营角色，他们对系统的正常运行、维护负责；
2、 业务分析角色，他们需要从这个系统得到数据分析的功能；
显然，第二种角色的分析数据来源都都将来自业务模型模块。而第一种角色将从剩下的模块中满足自己的需要，可以说，他们绝对不直接和业务模型这个模块打交道。在架构设计中，重点应该放在如何满足系统管理用户的需求上面，当然是"重点"，而非舍弃业务分析角色，毕竟在业务模型模块中，根据业务的特点、数据量的特点、分析应用的特点，来进一步细化。
这里有个自己的理解要说明一下，架构设计应该是于具体业务关系不大的，这种架构应该是半通用的。之所以是半通用，在系统功能上面，BI项目大同小异，而在业务需求上面，架构中只需要对客户的业务、分析需求分成几个大类，例如按行业分业务模型，按OLAP、报表来为分析应用分类，不要太过细节。
来看看这系统运营角色的需求罢，还可以对这类角色细分成：
1、 开发设计者。之所以将开发者作为系统的用户，是因为数据仓库项目应该看作一个过程，而不是产品，因此在开发阶段，其实其架构最重要的用户就是开发者，当然要为之提供便利。
2、 系统管理员。系统交付之后，如何监控系统运行、发现数据质量问题、应付新的分析需求等。
那么对于开发实施人员，他需要进行系统部署、ETL的开发调试、质量的稽核；设计人员，需要进行模型的变更、系统调优、作系统一致性分析等；而系统管理员则需要监控ETL过程、监控系统运行、响应系统警报、接口数据管理等。这些都可以看作是用例。
面对这些用例，它们是架构设计的"需求"，如何满足他们，并且保持良好的体系和清晰的结构。能够易于维护，且能够满足日后肯定会增加的业务需求。
说了这么多，主要要表述的观点是：
1、架构设计主要面向系统用户为主；
2、架构设计的内容主要包括：系统功能需求、分析需求分类；支持这两者的后台结构，结构的粗略划分，以让其内部能够保持简单的交互方式。
3、架构设计和详细设计究竟如何界定的？在架构设计中，不要出现诸如"欠费账龄"、"信用等级"这样的业务术语
对于过渡分表，很多国内公司使用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年客户应该就很满足了，但是如果项目才开始实施几个月就发现不对，那预测了什么
在项目（不仅仅是dw）中，架构设计师能够根据自身的技能和经验对于今后要面对的性能、数据质量、可扩展性等要求给出相应的应对方法是一个基本要求，问题是好的数据仓库架构是什么样的，针对不同的系统状况和业务需要，哪些是作为标准组件必需引入的，哪些是可以根据具体情况进行裁剪或合并的，我想这也是胡海飞希望大家能够深入探讨的，当然inmon和kimball以及其它各位老大早就给出了他们的答案，在这里我们对具体细节讨论一下，比如分表、confirm
fact table、ods等等。
在这里说说我对ods的理解，和innovate511
略有不同，作为可选组件，ods是dw的一个补充，对于用户明确的查询和统计需求，为了减轻源系统的压力，引入ods，在其中针对确定的需求进行聚合，提供给前端操作型业务人员进行查询，dw在一定程度上能够满足这样的需求，但是分析型业务人员和操作性型业务人员的目的完全不同，虽然前者偶尔会访问到操作型人员经常访问的数据。
源系统
/ \
明确的查询需求 分析需求
/ \
Ods dw or dm
/ \
操作型业务人员 分析人员
对于无批量查询需求的项目来说，ods就没有必要，也不能成为某一个层次，更不能承上启下。
至于分表命名为tmp_***，我认为只要它是在设计阶段就明确了应用在哪个方法上，它就没有问题，只能说命名方法不好，如果在设计阶段未定义，这样搞才是一个"修补型项目"。
对于dw项目，架构设计对于项目的影响相对其他项目来说要大一些，除了已经讨论的，大家是否有其他的应对，或者我们可以提炼一下，形成一个当前的最佳实践应用到后续项目中。即使没有结果也是很好的交流。
之所以最佳的办法是在DM这一层供客户查询，就是考虑到了客户复杂的，批量的查询需求。在ODS查询的话，客户需要一个复杂的查询，难道你需要关联好多大表，如果实在太难，你就对客户说，不好意思，逻辑太复杂，实现不了？客户肯定就会纳闷，既然你能实现复杂的报表和OLAP分析，为啥我复杂的查询不行呢？
还有，ODS层在绝大多数项目中，是供DW的数据源，不知道你把ODS作为查询数据源后，DW是否通过直接通过各个数据源直接装载呢，还是ODS也担当这个功能呢？
至于如何保证装载和转换的性能，在设计中，设计者总体思路是估量项目的数据量和业务量，然后就可以定论如何分层，分表如何分。kimball他们在书中只是写了大概要有staging
area,
conform层等，其实现实的大型项目中，还可以多加一些过渡层，以保证效率。因为不同项目选择ETL方式不同，有的选择使用工具，有的选择自己开发。如果自己开发的话，所有转换都在存储过程中进行，对于海量数据来说不是最好的办法，因为占用数据库的资源太大。建议把数据拿到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的技术复杂原因所在
