浅谈数据仓库（DW & BI）（三）

回顾一下之前的内容：

#42 浅谈数据仓库（DW &BI）（一）：数据仓库发展起源及概述

#43 浅谈数据仓库（DW &BI）（二）：粒度、存储、3NF、星型模型、雪花模型

数据仓库相关内容，现在我还没有形成一个逻辑清晰的叙述思路，所以这几篇（包括未来一段时间），可能都是想到什么表达什么，可能会很跳脱，也会随时对前期的内容做一定补充。

今天，主要聊企业级数据仓库一些常见的架构和数据集市。

前面两篇的内容，可能讲述的是数据仓库（DW, Data Warehouse），但是看上去好像格局有点小，实际上，也可称之为（EDW, Enterprise Data Warehouse），是一个企业级的实现数据价值的信息系统，由于各个公司业务（产品）条线，数据资源和其他信息系统的问题，不同公司会采取不同的DW/BI架构，Inmon提供架构是非常规范化的。

另外，在一些业务线比较特殊，可能会采取这种独立模式：

维度建模（后续再聊，一个新的数据仓库模式设计模式）架构，由Kimball提出：

还有，混合多种架构：

这几个架构中都有”数据集市（DM, Data Mart）”的概念，数据集市是为了满足特定部门、用户、主题、需求而产生的，一般交由使用部门进行后续数据处理等工作。一般分为两类，一类是如Inmon架构中从数据主仓库中一个或多个子集，从属型数据集市，所有数据直接来源于主仓库，存储的数据一般不是详细数据，是轻度或高度汇总数据；另一类，独立型数据集市，这类不直接参与主仓库，数据由操作型系统直接抽取（etl）过来，直接在数据库做后续所有数据处理、分析工作。

独立性数据集市不需要通过主仓库较为漫长的数据流处理过程，反应速度快，非常适合互联网行业产品快速迭代这样的业务，数据分析与挖掘、跟踪效果。理论上数据集市随着数据的增长，是可以逐渐升级到完整的数据仓库的，但是我认为这个还是比较困难的，尤其是源系统抽取到不同部门数据集市，对数据理解、处理的差异将导致各个部门最终数据难以解释。且当某一个源系统发生改造时，所有涉及到的数据集市都要进行改造，不太好应对这类问题，无论如何，数据仓库人员与操作型系统人员的沟通成本将上升。

从属型数据集市除了效率可能会被有所诟病外，理论上对数据质量的问题可以比较好的应对，将一定程度汇总的数据，分别提供给不同部门，不会出现数据差异，但是不同部门的差异性需求，难以应付。

P.S.我司目前的数据集市是从属型，通过前台web页面的方式，做用户鉴权、不同部门数据管理、数据安全，有一定的好处，但是效率有所降低，我认为今后应该逐渐摒弃前台页面（减少成本），用户直接访问后台数据库，业务部门同事应该具备SQL使用能力，将提升工作效率。另外，对于电子渠道，尤其是一些短期活动的分析和运营，持续时间较短，可以考虑建设一个小型独立型数据集市，甚至这部分数据可以由电商中心自己承载。

数据仓库建设的意义在于使用，发挥数据的价值，做产品的运营、风险的管控等等，数据集市是一个极好的子系统，直接面向用户，提供了业务部门同事们快速获取数据这样的一个渠道，简直是整个仓库的精华。

       好好建设，很有用！

---

沉默是金 话唠是银

长按识别二维码关注

或搜索ID "im-wudi" 添加关注