数据仓库--些许经验之谈

最近在做数据仓库的一些事情，想着写一篇博客来谈一下我认识的数据仓库，个中错误之处，还请指正。（20170918更新）

先说一下个人项目大概：

　　我做的是一个数据集市，面向分析师和营销部。将底层源数据通过表与表之间关联整合成一个一个主题，各个主题表之间又通过关键字进行关联，满足业务多场景、多维度的分析。

　　关于数仓个人的一些看法：要能深入业务，也能跳出业务。跳出的目的是为了别让业务牵着鼻子走，你要尽可能的预见业务的潜在需求点，避免后期不断地修改维护风险。当然这灵活性很大，仁者见仁的事。关于这个点虽然一开始就知道，但是也没能做好。后期不断接受别人修改和维护。建设数仓的困难再有就是版本控制和展现也很重要。版本控制不多说，你更新了你的数仓，结果别人还在用旧的字典或表那就很尴尬了。至于展现，就像花了好多钱造了个飞机，大家却还在用自行车。我要是老板，就把你开除掉！

 

介绍

　　数据仓库当前有两个牛逼的人，一个是Inmon，另一个是kimball。两个人有着不同的主张，Inmon主张数据集市是数据仓库的子集，先设计底层数据并满足第三范式要求，在此基础之上构建数据集市。这样的好处，就是数据仓库易于维护并高度集成，缺点则是周期长，结构相对死板。Kimball则认为数据仓库是一系列数据集市的集合，底层建设成最低粒度的维度模型，对不同业务条线进行构建数据集市。优点就是：灵活方便，周期短见效快；缺点则是后期维护和数据集成困难。目前大多倾向于kimball方式（扩展阅读：http://qing.blog.sina.com.cn/2740714575/a35bfc4f330042oz.html），同样我们这里也更多的是说kimball的模型。

 

事实表与维度表

　　kimball在描述他的维度模型时，是面向企业数据的。一个主题或一个业务条线虽然更多的从部门角度出发，但从企业角度强调一致性。举个例子来说明一下事实表和维度表。我们去食堂吃饭，有消费事实（点几个数、付款等可加性事实）、也有维度（菜的价格、分量、冷热等文本描述；食堂的地理位置、名称、大小、消费模式等）。当我们创建一个消费主题时，就需要一个事实表和业务关心的维度进行有机结合。具体来说，维度表包含了对业务的文字描述。维度属性是查询的约束条件、分组与报表标签生成的基本来源。不同的维度交叉就会有事实，事实表承载事务数据。事实表根据粒度的角色划分不同，可分为事务事实表、周期快照事实包和累积快照事实表（少见）。对于周期和累积事实表，一般的粒度都比较高依赖满足对应的业务需求。

 

星型模型和雪花模型

　　顾名思义，星型模型是以一个事实表为中心，多个维度表进行关联的模型。而雪花模型在维度表之下还会有一层或多层维度。在Kimball看来，星型模型较雪花模型更具有可取型。雪花模型实现了规范化的存储（3NF）减少数据存储空间，同时以更小的维度表在查询时效率可能会更高。但实际场景下，事实表往往占据存储的90%，对维度表的规范化并不具有显著效果（往往也就是几十M数据的区别）反而将逻辑复杂化，导致后期维护的艰难和使用的繁琐。

 

数据构建逻辑

　　建设数仓时，都是面向企业来做，实现为各个部门和管理层建设数据的提取、分析的数据中心平台。数仓建设90%的工作，其实都在做维度表选择（如何保障多个业务条线能够统一使用同一维度是一个挑战性工作，一般企业都会有：日期维度表、产品维度表、客户维度表。以日期维度表来说，虽然事务级有日期数据，但是日期维度表可实现更多的日期属性，一般都是存留5-10年的数据）。方式为总线结构，以事实-维度矩阵作为概览，指导各个主题进行分别设计。说的很简单，谁做谁知道！

 

关于分层

　　经常被问到数据分层是什么样的。现实工作处理中一般都是3层（显而易见）。第一层：操作性源数据（ODS:operational data system），通过ETL将产线数据加载到你的数据目标位置上。之后建设你的主题形成数据集市，所以第二层：数据集市（DM：data mart）；数据集市建设后，便是提供到业务进行使用，所以第三层就是应用层了（DA:data application），一般是报表数据等高度聚合数据。当然，不同的角度对数据仓库的分层也不一样，有人会增加一些临时层或过度层，比如维度-事实表的处理层；中间加工层等。暂时没有统一的标准。

 

 

 

 

 

转载请注明出处！欢迎邮件沟通：shj8319@sina.com