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

Innovate
20060222

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

关于上面说的主题设计，以及前端展现，这是给客户的最终用户看的，他们只关心你能给他们带来什么，是否满足他们的报表、查询和分析需求。但是对于厂商自己来说，需要清楚自己实施项目时要干什么，就像复杂的ETL开发需要元数据去规范和指引一样，项目的数据流逻辑，是否有设计规范。

对于一个大型数据仓库项目来说，如果粗犷地设计为ODS，DW,DM三大层次，那么在具体实施的时候，可能会因为数据量大，需要过渡层，于是随手在DW层增加些分表，到DM后，前端应用觉得查询太慢，于是也增加一些分表，再汇总。这样就陷入了无休止的维护和盲目地修改中。据我所知，能知道增加分表作为过渡层，已经算是不错的，有的项目看着ETL太慢，只是找寻数据库和ETL代码的原因，于是经常有工程师到处问，几亿的数据量如何增加效率呢，数据库还需要什么优化呢？其实即便你除了2亿纪录的那个表，那么随着客户信息的增加，以后3亿、4亿纪录你能按时ETL完成？

我看到很多朋友，包括比较资深的朋友，一提到那种架构就摇头，太空矿了，没法入手，也没法讨论。其实很多项目开发的时候，分了一些事实表分表，我看有的电信行业架构设计还把主题分为经营分析和大客户两个业务层，这不也是一种设计的进步么？

国外大项目之所以把Architecture工作和datamodel的工作分开，就是因为两者完全可以独立，一个优秀的架构设计，可以应用在不同行业，而不是做一个行业的项目，设计一个架构。可能有人要问，不同客户的数据量和业务复杂程度都不一样，你如何规范？那么一个合格的架构设计，应该是分层的，比如，首先分出ODS,DW,DM，标出ODS接受哪些数据源，ODS如何把数据流向DW，DW如何流向DM，具体点可以把一些逻辑上的数据库标上，就像元数据管理图一样。第二层就是各个逻辑层内部设计，ODS一个或者数个数据库，对应到哪些DW对应的逻辑数据库，DW在处理ETL过程中，需要几个过渡层，如果数据量不大的话，只需要一个confirm层ETL到confirmfacttable足够，如果数据量大，看来还需要一个过渡层才能流向DM层。DM层是面向各个前端应用的逻辑层，大型项目一般都是DW的一个事实表对应多个DM层的事实表。第三层设计是把业务逻辑融入架构中，说明各个逻辑层中业务逻辑的变化。

由此可见，数据仓库项目并不是完全是纯粹的业务驱动，也不是完全的数据驱动，应该是两者同时驱动的MATRIX架构。一个合格的数据仓库架构设计，不但要清除业务流程，还应该清楚数据流程，光有元数据驱动ETL开发也不能让数据仓库更有条理。当然一个项目要实施很合格，光靠架构也不够，具体的开发和测试这样的具体工作也很关键，不在此次讨论范围。

在这只是抛砖引玉，只是提醒下，数据仓库架构设计，并不是空旷，虚无的东西，也不只是业务的驱动和主题的划分。"ETL※DW※OLAP"只是些表面的东西，作为设计者，应该需要知道内部更多，更深入的东西。

刘庆
20060223

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

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

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

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

之所以分成若干模块，是为了让架构清晰，降低这些模块之间的耦合，如此的构成是否合理呢？还得看看这个架构面临的需求到底是什么，将系统的用户分为两大类角色：

1、 系统运营角色，他们对系统的正常运行、维护负责；

2、 业务分析角色，他们需要从这个系统得到数据分析的功能；

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

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

来看看这系统运营角色的需求罢，还可以对这类角色细分成：

1、 开发设计者。之所以将开发者作为系统的用户，是因为数据仓库项目应该看作一个过程，而不是产品，因此在开发阶段，其实其架构最重要的用户就是开发者，当然要为之提供便利。

2、 系统管理员。系统交付之后，如何监控系统运行、发现数据质量问题、应付新的分析需求等。

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

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

说了这么多，主要要表述的观点是：

1、架构设计主要面向系统用户为主；

2、架构设计的内容主要包括：系统功能需求、分析需求分类；支持这两者的后台结构，结构的粗略划分，以让其内部能够保持简单的交互方式。

3、架构设计和详细设计究竟如何界定的？在架构设计中，不要出现诸如"欠费账龄"、"信用等级"这样的业务术语。

Goldenfish
20060223

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

丁西宁
20060223

想请教一个问题，增加分表指的是什么意思？

是指由于转换规则太复杂，把原来的一次转换分成多次转换，把转换的中间数据放在临时表中呢？

还是由于表中记录数很大，所以按照业务需求、以及今后查询的特点进行的分区处理呢？
还是在刚开始设计事实表时，根据业务的不同进行分类，把不同业务数据分别放在不同的表中呢？

Innovate
20060223

我也比较了解国内的实际情况，往往是给客户的设计资料比较详细，而内部的设计会粗一些，甚至的有的干脆省略了。而客户只关心大概的东西，看你能不能满足他们的分析需求，或者你能给他们带来什么分析，具体的事情他们不需要管太多。

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

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

Innovate
20060223

分表目前在很多项目中已经使用，只是还是比较随意，没有在总体架构设计中作为一个层出现。

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

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

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

刘庆
20060224

这个confirm table，一直没整明白是干啥的。按照Innovate的描述，它是一种"聚合一个涵盖丰富信息的事实表"。如此，我理解的confirm table，恐怕就是那种主题表，例如用户信息表（一系列），这些表的粒度是其描述的实体决定的，针对这种实体的汇总信息表。常见的实体包括用户、客户、渠道、产品、资源、竞争对手等。

其实业务数据模型设计，区分成ODS、DW和DM，他的架构目的有二：

1、为了能够满足用户可能变化的分析需求；

2、要不就是为了查询性能的需求。

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

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

例如增加一个临时的汇总表，那么就严格规定，此表不能放入常规的ETL流程当中，因为那样会导致概念混乱。如果按照周期分表，同样在上层应该是有"不同周期主题表"的概念。

所谓概念，其实就是给个名份。数据仓库中分那么多层次，ods、dw不都是数据倒来倒去吗，甚至都可以叫它们作"中间表"，可这不是一个清晰的概念，于是就产生了细分。就像你叫一个人，"哎，女人"，这多不尊敬人，如果叫"小丽啊"，人家就爱听了。

丁西宁
20060224

谢谢innovate511对我问题的解答，还是有几个问题再请教一下：

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

innovate兄提到如果中间数据按照上面的操作是非常不规范的，因为在ETL过程中断时会产生数据质量的问题。这一点我还不是很明白。因为我在ETL了的过程中，有一些数据质量的控制方法。如果ETL过程中断，我会在日志中记录中断的情况，包括涉及哪些数据，在哪一环节出现错误。这些数据是不会再进入下面的环节的。我会通过对日志的分析来重新对这些数据进行ETL，并修改ETL的结果。我想这样是不是可以解决数据质量的问题呢？

我理解的中间数据不是按照业务来区分的，它只是为了某些原因，比如ETL的性能优化、更好维护等等才采取的方式，不知道这样方式是否确实存在数据不规范的隐患呢？还请innovate兄帮我再分析一下吧。

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

查了一下，没有找到confirm fact table的资料，希望innovate兄再多解释一下。如果在设计数据仓库时做到一个数据仓库的事实表可以和多个数据集市的事实表包含1:n的关系的话，那当然好了。不知如何在实际中满足这样的设计？是否要全面了解企业的需求，对业务理解很深才行啊？我们现在其实很多时候都在根据一堆业务指标来构造数据仓库的事实表，构造完后，如果有新的需求、新的指标，就会在原来的事实表上修改或者新建一个事实表。请问如何避免这样的现象？

Innovate
20060224

我以前就说过，有好多人想在ODS层做所谓的汇总表作为前端查询的做法是非常不明智和不科学的。数据仓库是个工程，你想怎么做都可以一定程度地实现客户的需求，所以才会出现很多厂商想当然地去做，因为他们觉得那样也能满足客户的需求，但是他们没有搞清楚，什么的方式才是最佳的。

大家很多都看过Inmon和Kimball的书，他们都或多或少提到过confirmtable的概念和思路，就像刘庆说的，confirmtable的出现的主要目的就是能够满足用户可能变化的分析需求和查询性能的需求，增加数据仓库的灵活性、稳定性和高效性。至于为啥ODS层用作前端查询不好，我也大概说过，ODS层的作用应是承上（数据源）启下（DW）的作用，如果你非要给个接口给前端查询，还做个类似confirmtable的事实表，那不是功能和DW、DM有重叠了？客户访问要大大增加系统压力，作为数据前沿的接口，系统压力也很大，你如果保证高效？既然ODS到DW还可能经过1到多次的ETL，你怎么能保证客户最终查询和分析的数据一致性？

我不知道“建立一个¬若干维度若干度量的汇总表”是建立一个汇总表，还是聚集事实表，这是两个不同的概念。confirmtable既聚集事实表是指经过了所有设计好的ETL后，再把相似的事实表聚集在一起，也就是他还是事实表，不是经过sum,count的汇总表。

说到这里，不得不说分表了。前面说到了ETL完成后相关主题的事实表要聚集到一个事实表里，那么意味着前面我们已经做过拆分，这就是所谓的一个大主题的事实表拆分成分表了。我们这里说的分表，和刘庆提到的很多项目，包括大型项目中的tmp表有类似的作用，但是并不是我做到项目做到一半，突然发现数据量太大，得找个分表分散ETL压力，而是在开始设计中设计好的一个步骤，一个层，要不然为啥总体设计要一个有经验有理论的人设计，随便找个做过大型项目ETL的人设计不就完了？

再细说的分表的命名，如果资深的DW人，一看到分表基本都是tmp_xxx命名的话，只能说明这个项目是“修补型项目”，也就是走一步看一步，发现问题，我再改建模，我再改ETL，元数据管理也得修改。之所以后来项目都很重视元数据管理，是啥原因？没有元数据管理，ETL不照做么？因为大家都知道元数据有效的管理，能让你“站得高，看得远”，能把握ETL全局。那么一个“修补型项目”好，还是你前期架构设计好了，按照设计开发就是好呢？一看就明白了，这也是我最近各大论坛和网站提到的架构设计的重要性，我想我不提出来，也有人出来，就像当年很多人提出元数据管理的重要性一样。