最近一直超忙，都没有时间上来写头条。但并没有干什么惊天动地的大事儿，而仅仅是帮助客户研究数据仓库的数据架构，这让我们不得不拿出十几年前的理论知识再次诉说未来。
我的客户是个大型企业客户，他们有着优秀的团队、有着出色的产品、有着全球面向企业和个人的客户，当然，也有着如狼似虎般的饥饿感。但是他们仍然也有短板，在IT系统建设中，平台能力支撑了20多年的企业发展，但近期需要搞财务系统，搞财业融合，说白了就是希望从财务视角看企业业务发展。所以无论多么强大的企业也终将存在不足，需要提升。显然他们聚焦在数据仓库领域，而且是大数据时代的多元技术融合的数据架构。
Inmon 的模型从流程上看是自顶向下的，即从分散异构的数据源 -> 数据仓库 -> 数据集市。
1）操作型系统的数据和体系外数据需要经过ETL过程，加载到企业数据仓库中
2）企业数据仓库是企业信息化工厂的枢纽，是原子数据的集成仓库，其目的是将附加的数据存储用于各类分析型系统；在数据仓库中会对数据进行清洗，并抽取实体-关系。
3）数据集市是针对不同主题的聚集区域
Kimball 的模型是自底向上的，即从数据集市-> 数据仓库 -> 分散异构的数据源。
1）Kimball 的模型的数据源往往是给定的若干个数据库表，数据较为稳定但是数据之间的关联关系比较复杂，需要从这些OLTP中产生的事务型数据结构抽取出分析型数据结构。Kimball 是以最终任务为导向，将数据按照目标拆分出不同的表需求，通过ETL导入数据集市层
2）Kimball模型将分散异构的数据源经ETL转化为事实表和维度表导入数据集市，数据集市由若干个事实表和维度表组成
3）在数据集市将事实表和维度表根据分析主题组合后导入数据仓库中，用于数据分析
Kimball和Inmon是两种主流的数据仓库方法论，分别由 Ralph Kimball 和 Bill Inmon 提出，在实际数据仓库建设中，业界往往会相互借鉴使用两种开发模式。
简单说来，Inmon遵循第三范式，关键词：面向主题的、集成的、与时间相关的、不可修改的数据集合。Inmon理论是自上而下的设计理念，数据可以通过下钻到最细层，或者上卷到汇总层，它是以数据驱动；
通常，Kimball都是以最终任务为导向。
首先，在得到数据后需要先做数据的探索，尝试将数据按照目标先拆分出不同的表需求。
其次，在明确数据依赖后将各个任务再通过ETL由Stage层转化到DM层。这里DM层数据则由若干个事实表和维度表组成。
接着，在完成DM层的事实表维度表拆分后，数据集市一方面可以直接向BI环节输出数据了，另一方面可以先DW层输出数据，方便后续的多维分析
它的优势在于：易于维护，高度集成
它的劣势在于：结构死板，部署周期较长
Kimball 遵循行星模型，关键词：面向业务流程的、强调维度建模（并非是采用ER模型）。Kimball理论是自下而上的设计理念，各业务单元或部门的数据集市要先建立，它是以应用驱动；
它的优势在于：构建迅速，最快的看到投资回报率，敏捷灵活
它的劣势在于：作为企业资源不太好维护，结构复杂
Kimball往往意味着快速交付、敏捷迭代，不会对数据仓库架构做过多复杂的设计，在变换莫测的互联网行业，这种架构方式似乎也正逐渐成为一种主流范式。
正如我们刚才已经看到的，选择哪种数据仓库设计方法取决于组织的业务目标、业务特性、时间、成本、不同组织单元之间的相互依赖级别。Inmon 的方法比较适合稳定的业务，这些业务能花得起时间做设计也能承担相关的成本。随着每次业务条件的改变，设计不用改变;可以将这些变化包括在现有的模型中。然而，如果本地优先级足够高，而且重点是要快速看到效果，那就建议采用Kimball的方法。记住，让一些部门/组织单元来讨论是选用Inmon方法还是Kimball方法。
在设计数据仓库时，首先要先看看业务目标——短期目标和长期目标。看看功能之间哪里有联系，什么是独立的。这两种方式没有对错之分，他们代表了两种不同的数据仓库哲学。在现实当中，大多数企业的数据仓库系统更接近Ralph Kimball的方式。这是因为大多数数据仓库在一开始是企业其中一个部门的工作，因此他们起源于数据集市。只有当许许多多的数据集市被建立起来后，他们才会进化成为一个数据仓库。
分析世界讲方案——偶然早7点，为您带来精彩的一页。
感谢阅读、感谢共鸣。
閱讀更多 分析世界講方案 的文章
