谈谈数据仓库架构的发展和分类

Jerome 20061210

最近大家对数据仓库架构的讨论又多了起来，我在这里对一些架构进行一下简单的整理。目的是给大家树立一个靶子，大家可以在这篇文章后尽情的批判和补充。

我把我听说过的架构都归整在一起，分了六类，其中和很多说明是我个人的理解，不见得正确，大家多多指导。

1．独立的数据集市架构（Independent data mart architecture）
独立的数据集市架构有时也称为独立的数据仓库架构，应该是出现最早的架构方式，也是很常见的方式。特别是对于中小企业、中小开发公司，出于成本和见效快的考虑都会采用这种架构方式。大家对这种架构方式一定也很熟。

这种架构方式的缺点也很明显，不是企业内一致的数据，产生信息孤岛。当然我企业就是很小，就一个系统，不用整合，一个数据集市足以的情况下采用这种方式也没什么。先期小投资，让企业看看效果，以后发展大了再考虑重新建立数据仓库。

2．联邦式数据仓库架构（Federated data warehouse architecture）
这种架构方式我之前写过一点简单介绍，当然，我对这种方式也不熟，介绍的也是乱七八糟。我想它的出现应该是由于，企业发展的初期建立了几个独立的数据集市架构，后来发现这样不行，数据没整合，要解决信息孤岛得想办法。推倒重建当然好，不过投入太大，以前的数据集市还想用，怎么办。于是，想出另一种办法，在各个独立的数据集市间建立一些对照表，在不推倒它们的基础上能进行一下数据交换。后来，慢慢发现，早想好整合策略，直接这样建数据仓库也可以，于是，地域联邦、功能联邦的概念也就都提出来了。

联邦架构的缺点也很明显，除非建立之初就采用类似总线架构的方法实现数据一致，否则很容易出现数据不一致，导致整合的不彻底。如果之初就考虑好的话，和总线架构的差别就不大了。当然，对于临时解决企业原有独立数据集市的数据交换问题，联邦架构还是有一定作用的。

3．集中式架构（Centralized architecture）
集中式架构方式的出现，标识着数据仓库架构已经进入比较成熟的时期。他的架构方式是建立物理的EDW，即中心数据仓库，数据都集中的EDW中，应用和分析程序都在EDW中进行访问，数据是全企业内一致的。随着ROLAP的发展，在这种集中式架构中建立ROLAP开始比较流行，常见的MicroStrategy公司的解决方案就是在EDW中建立ROLAP。ROLAP单独建表保存元数据，只保存维度模型的关系，不保存维度模型的数据，由MicroStrategy的应用去解析，加上应用服务器作为缓存，速度还可以。

这种方式也有一些缺点，如扩展能力差，对EDW所在的RDBMS要求太高，随着数据量和分析的逐步增长，就不得不再把数据进行分离。如果在EDW的基础上进行数据分离，为不同的应用单独建立数据集市或者挖掘仓库，集中式结构也就演变成Hub and Spoke架构方式。

4．集线器和车轮辐条架构（Hub and spoke architecture）
其实我更想直接称之为企业信息工厂架构（Corporate information factory architecture），集线器和车轮辐条架构听起来比较别扭，叫起来也不响亮。而企业信息工厂应该是这种架构方式的最出色的代表。从名称我们也能大概猜个差不多，中心数据仓库EDW从各个源系统收集数据，将数据提供给各个数据集市和挖掘仓库，功能和集线器很相似，所以称为Hub。如果大家把图画出来，可能会更形象一些，EDW和各个源数据库及数据集市、挖掘仓库之间都连一条线，看起来就向一个车轮，这些连线就像车轮辐条，所以称为Spoke。而这种采用中心数据仓库EDW集成数据，再分散到各个数据集市使用数据的方式就形象的称为Hub and spoke architecture。

这种架构方式当然也有缺点，虽然是在集成的中心数据仓库EDW上建立数据集市，但是这些数据集市之间还是不能进行数据交换的，大家建立的方法和ETL程序都会不同，各个数据集市之间的数据不见得的是一致的。而且这种架构方式开始变得复杂。

5．总线架构（Bus architecture）
总线架构和Hub and spoke architecture的最大区别，应该是维度建模的原子层和一致性维度的建立。正因为预先建立的总线架构和一致性维度，所以这种架构可以保证在逐步建立数据集市的过程中还能保证企业数据的一致性。总线架构是数据仓库架构方式从复杂走向简单的一步，将维度建模的数据仓库原子层和数据集市合而为一，一层就把数据仓库建立好的，还能支持各种数据集市分析应用。

当然总线架构也有缺点，中心数据仓库以维度模型保存，对于特殊的非维度型分析应用会有局限性，支持的不好。

6．复合式架构（Composite architecture）
复合式架构是我自己起的一个名字，当然它可能有自己的名字但是我不知道，欢迎大家指导。这种架构方式是综合考虑Hub and spoke architecture和Bus architecture两种架构方式，或者说综合两种方式得出的一种架构方式。这个，innovate511可能更有发言权，CDW架构应该就是这种架构方式的代表。

复合式架构的缺点也是很明显，架构过于复杂，（比CIF还要复杂），企业内数据量大的话，每一次搬动都会非常麻烦。

呵呵，简单的整理的各种架构，也大略谈了一些缺点，至于那种架构好，那种不好，我不想和大家争论，我想它们都有自己的适用范围吧。欢迎大家对我文章中的错误和描述不清的地方进行指导。

土包子 20061210

innovate511 20061211

觉得还是和具体情况有关吧。

有多大规模的项目、企业期望（包括期望的生命周期）、企业投资等都有关系。当然，正如前面分析到的，目前已上项目中，各种架构都尝试过了，优缺点都很明显。

不过复合式架构的缺点，我觉得并非搬动麻烦，而是整体要求很高，无论是EDW数据整合，还是类似HUB的CDW建设，再到数据集市，接口很多，对设计要求高，而对开发和测试的要求也很高，任何一步没走好，都可能导致项目濒临失败。这也是90年代很多想模仿CDW思想的项目失败的重要原因。但是效果也是很明显的，即使数万计的最终用户，各个部门世界各地的分公司的四大BI需求全部能满足，由于所有复杂数据转换问题都在后台已经完成了，BI工具可以更稳定更快速地实现BI。同时由于非常灵活，也能满足更多数据源和业务的加入，实现系统长期使用，避免重复投资带来的资金投入过大、稳定性降低、一致性在重复上项目后不能保证、前期项目维护问题太多导致最终用户不满等缺点。

至于数据搬动问题，我觉得不是大问题，因为没一步也可以看成一个独立的整体，只要按照流程移植，是不存在风险的，包括利用Kimball的思想进行DMR（Data Mart Restructure），数据集市也可以不断扩大或者拆分来满足更复杂BI整体需求，在这些灵活度方面我还是很有信心的。

Qing 20061211

这两天关于数据仓库架构的讨论甚欢，看了jerome、innovate的介绍，有些东西清晰了不少。Jerome提出六种架构，Innovate提出架构面临的四种需求，以及四级架构抽象级别。下面我就充当主持人的角色，再归纳一下这个六、四、四，各位还请继续探讨。

六种架构（Jerome提出）：
1、独立数据集市：如果你对构建一个大型数据仓库没把握，可以从独立的数据集市入手；
2、联邦式：如果你已经有若干数据集市，但又不想建立一个物理集中的数据仓库，可以考虑联邦式的；
3、集中式：针对不同数据源，建立物理集中的数据仓库，任何分析都从中取数；
4、CIF式：如果你有决心要构建一个大大的数据仓库，充分规划好这个信息工厂。建立物理集中数据仓库，并且为专门应用建立数据集市；
5、总线式：如果你想快一点看到效果，又不想向独立数据集市那样，可能浪费投资，采用总线架构；统一规划，尽快实施。
6、复合式：综合CIF，偏向数据的用CIF，偏向应用的用总线架构。

我想，对于电信行业的经营分析系统来说，大部分是比较符合"集中式"的，因为它从不同数据源物理集中了数据，并且没有单独构建数据集市，大多只是在数据仓库架构里面划出一层DM层出来（不知道算不算）。当然，也有可能是使用总线架构的，毕竟这个见效快一点，在目前这个阶段，"快"还是一个优先考虑的因素。

架构四种需求（Innovate提出）：
1、对数据的整合需求；
2、对业务的分解需求；
3、对数据的效率需求；
4、对需求变化的需求；

Innovate对这四种需求并没有多说，为什么分成这4种，是否还有别的类别？看起来业务的分解和需求变化都是指业务需求（可能只是前者是现有业务的功能分解，后者是业务需求的变化吧）。如果要对需求进行分类，还得看看都是什么角色提出这些需求的。处理数据的人，希望架构能够方便自己，使用数据的，希望能够快速、安全地访问......我想这就是需求分类的依据。

架构的四层抽象级别（Innovate提出）：
1、整体IT架构；诸如硬件、网络体系，或SOA等等；
2、数据仓库架构；诸如前面介绍的总线式、CIF架构等；
3、功能架构；如何支撑ETL、OLAP、报表展现、Portal等等功能；
4、应用架构；如何支撑具体的业务，例如对客户通话行为的分析，这是电信行业相关的。

将架构分成不同的抽象级别，这是显而易见的。例如SOA肯定是比J2EE更加抽象的，J2EE也许不适合数据仓库系统的架构，但SOA却能适合。到了第三层架构，至少都是能够适合不同行业的数据仓库项目的，但到了第四层，便只是服务于专门的行业了。

yushano@gmail.com 20061212

请教一个电子政务方面的案例：如何对已经自成体系的垂直系统进行数据整合?

在市区的电子政务中，要对市级的各个部门进行数据整合。因为这些部门多数都是自上而下的系统，是由国家中央、省到地方市区的。比如公安、税务、人民银行都是自成体系的业务系统。再如国家统计局各个专业指标（人口，工业，农业等等）的信息系统也都是自成体系的，从中央推向地方区镇，而要想得到市区一级的综合统计指标（人均纯收入，GDP，社会消费零售额等），就必须对各个专业指标进行整合，它们都是异构的数据库和数据标准（叫数据集市？），而整合形成的数据平台叫数据仓库？是形成一个中间件式统一规划的数据标准还是做接口表呢？如果要想横向协同利用各个局的数据，比如市区政府想利用这些数据，应该采取上述的哪种方案呢？我想虽然我们应用目标的出发点不一样，但是碰到的数据整合问题应该是相通的吧。

goldenfish 20061213

这种情况下数据整合的挑战首先来源于管理模式。市区政府想要利用这些数据，但这些数据的所有权并不直接属于市区政府。以前遇到的情况是，市长办公会请各部门一把手去，专门讨论如何给数据的问题。每个部门都说自己的明细数据机密性很高，搞不好就引起社会问题，不愿意给，能不能只给报表？如果给的话，能不能给去年的数据？或者给的话，只给一次？要想动态实时的拿到这些数据，更是不可能的任务。大的国企也有这个问题，法人层级太多，总部想要下面的数据也是被推三阻四，软磨硬泡的不给。

其次，市区一级的综合统计指标体系如何建立。从一个市区的角度自定义一套综合统计指标体系，有点勉为其难。与国家统计局的统计口径是否保持一致？如果全然一致，为什么不从本市的统计局直接取？当然，统计局可能走的是一套自己的统计方法、例如抽样；自己的频度，例如一季一次；可能只向上级统计机构负责，而不向平级下级负责等等，以至于统计局的数据很难直接使用。统计指标体系的建立要把各主要业务部门的核心指标汇聚到一起，剔除重叠和不一致，有些需对跨部门的数据进行合并。这个指标体系的建立也是很大的挑战。

最后才是技术架构如何建立的问题。没有通用的或绝对正确的技术架构。它是解决具体问题的，随着实际状况的不同而调整。由于上述管理的和安全的原因，从源系统直接取数恐怕是很难实现的，退而求其次，只能要接口表或接口文件。如果不能从源系统的数据直接导出，可能还要定义接口格式，由开发系统的厂商提供。接口表（或接口文件）放置到从接口缓冲区转移到一个集中的场地（服务器）进行数据整合。统一规划的数据标准很难约束到每个部门的业务系统，毕竟都是垂直条线下来的；现实一点，只能约束接口标准。在设计中还要考虑数据如何存储（数据结构）、取数的频度、数据保留多久、整合后数据是否有需要回流到源系统等问题。此外，还要考虑有部分数据很难取到原始明细，要有人工补录的手段。

Qing 20061213

看到这个问题，头脑中首先碰出来的一个想法是——"可以用联邦式数据仓库的架构"。因为对于已经自成体系的系统，将数据整合到一个物理数据仓库是否现实？后来看到goldenfish的回复，提到首要的挑战在于"管理模式"。应该就是这个道理吧。管理的整合比数据整合要难，何不避难从简？

当然，由于对电子政务中的系统不甚了解，不管此处说得是否合理，能够对思路有所开拓就足够了。

为什么当初的第一反映是"联邦式数据仓库"呢，如此问自己？也许正是余山老师提到了自成体系的系统，这些系统由不同开发商完成，也没有什么统一的标准，系统的设计思想、编码肯定是千奇百怪，而且涉及到安全性的问题。所以我想，可能用一种虚拟的数据仓库更加合适，即实际的数据都还是位于各自的系统当中，而所谓数据整合，是建立一个可以容纳所有这些系统（现实一点，可能是这些系统的交集部分）的框架，框架里面放置的是类似"数据指针"那样的东西，这是虚拟的，当你需要查询什么数据的时候，其实这个框架是将查询定位给具体的系统了。比如要查询某个人的信贷、犯罪、税务情况，好似从一个统一的平台输入了ID号，返回以上若干信息，但数据都还是存放在金融、公安和税务的系统里面的。

由此深入思考，我认为与其说这个案例是"数据的整合"，不如说是"应用的整合"。所以，根本也用不上上面提到的数据仓库架构，也不是什么"联邦式架构"，可能应该在面向服务架构（SOA）中寻找答案。

建立一个数据仓库，不如建立一些标准，可以将每个独立系统想象成为一个服务提供者，它可以提供什么服务，是经过注册的。比如金融系统可以根据一个个人ID给出此人的帐户、贷款、信用等信息，可以根据一个公司的代码，给出公司的信息，或者可以提供年度的统计指标等等。当然，这些信息的提取应该是基于金融系统内部的数据仓库的，总不能从业务系统去取。此处关键的就是如何定义这些"服务提供者"提供的服务，也就是标准。输入什么、输出什么、甚至是输入输出的规格标准化（例如身份ID的要求，输出数据中，性别的编码规则）、权限控制、如何注册这些服务等等。

有这样的标准，具体的实现交给独立系统的实现厂商。而至于基于这些服务能够作甚么用途，那得具体看应用而定。

goldenfish3 20061213

数据整合和应用整合有些区别。通常，应用整合指EAI，现在已经转向以SOA的理念实现EAI。数据整合通常指通过数据整合层或数据集成平台、EDW等进行的数据集成（Integration）/整合（Consolidation）/融合（Mediation）。广义的应用整合包含业务应用间的数据集成，即A的数据送往B，例如保险营业系统中的保单收费送往财务系统入帐。但应用整合更多是指A系统要求B完成一个操作，B完成后返回一个确认，以及这样的多步操作形成一个流程，流程集成是应用整合（集成）的高级应用。数据整合往往是为分析目的完成的。不同系统的数据送往一个集成平台，进行数据清洗和整合，为了实现分析应用。两者结合起来，可以称之为企业整合（EI）。

如上所述，两者是有交叉的。特别是SOA与主数据管理相结合之后，主数据集成通过SOA实现，主数据为业务系统形成统一的视图（在电信里已经有SID的应用）。这种理念的出现体现了SOA对传统业务系统架构的冲击，也是应用整合的一个发展方向。但主数据管理并不能替代数据集成，不能替代数据的清洗整合。两者服务于不同的目的，有不同（尽管可能有所重叠）的范围。倒是EII的出现对传统的数据整合架构有所冲击。EII体现了一种实时数据集成的理念，来自不同源系统的数据不集中存储，而是使用的时候边传输边集成。但显然，目前EII的实现不能隔离对业务系统数据库的访问压力，对于大量数据很难有效处理。

yushano@gmail.com 20061213

感谢诸位赐教。如上所言，管理的整合很难。但正是管理的界限形成了数据统一规划的界限，异构系统就是这样形成的。对于一个企业来说，消除部门的异构数据还可以通过统一规划的方法来达到共享，而对于像市级的各个专业局就是难以实现了。

就我目前调研的情况看，在市区一级的ＯＡ系统，联合审批（所谓阳光政务），还有财政局因为要对其它部门实现统一国库支付（两千以上的采购），这些系统的横向协同比较紧密，好像可以进行统一的数据规划整合。

刘庆最后的应用整合提法令我很开窍，打个比喻，是否如同XML网络消除异构的方法，不是在文字的存储编码上去统一整合，而是在显示界面的语言上统一整合？这样就能与操作系统，数据库，字符数据的储存标准都无关？从而达到统一。

火焰 20061220

个人认为总线机制的发展前景更好些，扩展性比较好，可以在大型的企业中依此建立多级的数据仓库以及BI应用，至于缺点中所说的内容，窃以为不是大问题，每个数据仓库都会有特殊的应用，每个总线上的组件总是会有组件自身的特色，只要这种应用所使用的标准是统一的，或者使用的范围不广，不会对整个总线的架构产生很大的影响。