3. 其他数仓/BI架构解析

  目前，经过长时间的演进，各种数仓架构之间的区别变得越来越小，且不论哪种数仓架构，都会涉及维度建模。下面是几种常见的数仓架构。

1. 独立数据集市架构

  如图，独立数据集市以部门为单位来构建，不需要考虑企业级别的信息共享和继承。数据的建模也只需要考虑本部门的业务规则和标识，独立的开展工作。部门间的数据是隔离的，数据的维度、标识等也是不一致的。
  独立数据集市的架构是我们极力反对的一种数仓架构，但它也是大型组织中比较常见的数仓架构。它反映了目前许多组织构建其IT架构时，缺乏长远规划，追求低成本和快速开发，不考虑跨部门数据共享的问题。这种架构将导致组织中不同的部门拥有不同的解决方案，它们互不兼容，最终造成数据的不可信和协调成本的无限增加。

2. 辐射状企业信息工厂Inmon架构

  上图的辐射状企业信息工厂（CIF）方法是由Inmon提出的，故也称其为Imon架构。
  两者最主要的区别是“采用范式建模（即实体-关系模型）的企业数据仓库（EDW）”和“采用维度建模的企业数据仓库总线”。

范式建模

  范式建模从数据流向上看是自上而下的，即从分散异构的数据源 -> 企业数据仓库 -> 数据集市。即先整体观察所有不同源、不同结构、不同业务属性的数据，并且，再将所有源数据划归不同的业务主题，然后在EDW中依据实体-关系（ER）模型为每一个业务主题构建出一套统一的、能存储所有本业务数据的表结构，最后在EDW基础上实现基于维度模型的数据集市（但是由于缺乏“企业数据仓库总线结构”，不同数据集市间的维度模型会各不相同）。
  该方法的优点是能够结合业务系统的数据模型，较方便的实现数据仓库的模型；同一份数据只存放在一个地方，没有数据冗余，保证了数据一致性；数据解耦，方便维护。但同时也带来了缺点：表的数量多；查询时关联表较多使得查询性能降低。
  注意：一般认为，纯CIF架构最极端的形式是不能实现数据仓库的功能的，因其将原子数据固定位难以查询的规范化结构（实体-关系结构）。

维度建模

  维度建模恰恰相反，它是自下而上的，即从数据集市 -> 数据仓库 -> 分散异构的数据源。维度建模是以最终任务（也就是业务功能点）为导向，将任务中要度量的数据作为事实，要查询的条件作为维度，构建基于维度模型的表结构，数据源经 ETL 转化导入数据仓库。
  维度建模的优点是模型结构简单，面向分析，查询性能好，反规范化的设计，开发周期短，能够快速迭代。缺点是存在数据冗余（但由于维度表通常不会太大，数据冗余一般可以接受），预处理阶段开销大，后期维护麻烦。

3. 混合辐射状架构与Kimball架构

  如上图，最后一种需要讨论的架构是Kimball与Inmon的结合。如果组织已经建立了满足范式模型的EDW，但尚不能按照用户的期望更灵活的实现报表和分析，那么这种混合的架构将十分适合。它将EDW作为统一的数据源，通过离线ETL的方式加载到展现区，且维度模型要与“企业数据仓库总线结构”规定的保持一致。

4. 其他大数据平台架构Lambda、Kappa、SMACK

  随着技术的不断更新发展，随着大数据时代的到来，人们对数据仓库的要求越来越高，比如实时处理等，Lambda、Kappa等大数据平台架构便应运而生。而实际上，这些架构本质上也都是从数仓架构演变而来，架构的设计理念大同小异，区别只是架构实现所用的技术组件各有不同，在此不再详细讨论，有兴趣可以自行搜索查阅。