并非概念，个人看法

数据仓库-数据的仓库

顾名思义，所有的数据存储管理得地方，就是数据仓库。收集全部的数据，对外提供处理后的数据并保证数据一致性与稳定性。提供一站式的数据服务。

意义

每个产品，都是由多个功能组成，功能又都是独立开发的，每个团队有自己的日志习惯，这就造成了各处的数据会有差异，格式不同，命名规范不同，相同的字段叫不同的名字等等。
当有统计需求的时候，需要从所有团队拿到各自的数据再计算。从多处获取数据到数据解析再到计算，比较复杂繁琐。当部分系统数据逻辑有修改的时候(比如维度有处理，指标计算逻辑更改)，由于信息同步不及时等原因，多个团队计算相同的指标，会出现较大的差异，这样会给决策者带来困惑"有的部门说升高了，有的说降低了，我应该听哪个？"。不正确的数据计算不仅不能给项目帮助，还会带来直接间接的损失。
这个时候，就需要有一个地方，所有人把数据产出到这里，统一处理，获取数据。直销固然流程少，但是有中间商也很重要。

举个例子，真实经历，但是换一种产品来表述，外卖这个场景，现在可以指定送货时间，假设有一部分用户当天选第二天送到，或者第三天送到(比如鲜花蛋糕这种)。我在统计订单完成率的时候，没有考虑跨天完成订单的情况，导致订单完成率只有不到30%，项目同学加班一周，又是活动，又是发代金券优惠券，结果订单完成率就是上不来，愁的头发都快揪没了，在这个时候我想起这个问题，重新计算订单完成率把跨天的订单也计算上，订单的完成率达到90%+，我告诉项目同学事情的原因的时候，他感动的哭了。

数据仓库的特点

标准的定义来说:数据仓库是一个面向主题的、集成的、非易失的且随时间变化的数据集合，用来支持管理人员的决策。

面向主题
主题是一个抽象的概念，指的是某一个方向一系列关联比较密切的数据的集合。公司里一部分人关注，其他人不是那么关注。或者关注一部分的时候，不太关注另一部分。
比如客户/商家/物品/订单等主题。
集成
由于数据是由多个系统产生的，在没有统一规范之前，每个系统的开发人员有自己的规范，相同的信息会用多种不同的方式来表达，比如性别，有的系统用0/1，有的用f/m，有的用x/y，在数据仓库这里就必须要统一起来，供后续使用。(一般在etl时就处理)
同时，我理解另外有一种行为也可以称之为数据集成：一系列连续的行为从分散到集成到一起。比如网购，从下单/付费/收获/评价。这些行为可由订单id这个唯一key关联起来，整合到一起，以便分析使用。
需要注意的是行为的延后性，比如下单/付费是同一天，收获/评价是同一天，但是这四个行为很可能不是一天，需要考虑这种情况下的数据建设。
非易失
进入数据仓库中的数据，无法修改，长时间保留。

有修改的需求怎么办呢？无法对局部数据修改，只能整个分区重新计算。

随时间变化
与业务数据库中的状态数据不同，数据仓库中的数据有着时间属性，如果添加了新的字段，在那个时间点之前的数据中，该字段没有意义。

数据仓库的发展

数据仓库是随着需求增多而产生的。

无数仓:简单报表
单纯的统计pvuv等由单一数据可产出的指标。针对该份日志写程序处理既可。
局部数仓:部门级需求
随着产品发展，统计不单是为了出简单的报表，还可以对功能进行优化，比如说登陆位置对登陆率的影响。通过对其监控，可以得知此次改版是否达到预期。总之是满足单个产品的分析需求。
全局数仓:公司级需求
打通公司全部产品的数据，构建全局数仓，让决策者可以很容易的了解公司产品的情况，以便做战略上的调整。

数据仓库建设步骤

数据接入/清洗
1. 数据接入(暂未上传)
  数据接入是整个数据流程的起点。及时，完整的数据是分析挖掘的保障。过程数据/结果数据都有自己的价值，分别接入进来统一存储，以便后续使用。
2. 数据规范化-ETL(暂未上传)
  数据从不可用到可用重要的一步，通过ETL，把数据规范化，清理脏数据，数据统一化。让多个数据源的数据可一起使用。
吐个槽，数据的规范化，是一个技术难度不高，但是需要耐心以及细心的漫长的事。所以我对网上很多高级的ETL职位表示不理解，甚至还有"ETL总监"。嗯，也好，至少给人一条晋升的路线。
数据集成
同一流程中的数据根据唯一键整合到一起。比如在电商中，用户浏览商品，是非线性的，随意浏览。但是一旦加入购物车，那之后的行为:确认订单，付款，收货，评价，则是一个线性的流程。可以通过key(订单id)来串起来，这个时候，需要把这些数据从不同数据源集成到一起，无论是简单的统计，还是做分析，都更简便，减少后续使用的难度。
仓库建设
较细粒度的聚合，包含所有的维度，维度很多，但是对比明细数据，可以有效的降低数据量级，后续的计算速度更快。对于指标，把计算逻辑下沉到这里，让指标变得简单易用，达到指标逻辑的统一，保证数据的一致性。
主题抽取
依据不同的情况，建立不同的主题。依据主体不同，分为用户/产品/订单等。依据关注人群，可以有"机场订单""加班订单"等主题建设。总之，由于逻辑已经统一在仓库层，主题建设比较灵活，可以根据自己需求进行建设。
对外提供数据
包含基础的统计报表，多维度分析，策略效果评估，挖掘算法数准备，都可以从仓库/主题中得到想要的。

在数据仓库建设中，有Inmon派，主张先仓库后主题，在仓库层把逻辑统一之后，主题建设直接使用，简单不出错无冲突。另一派Kimball，主张先主题。
虽然我是Inmon派的，但是实际使用中，会有一些非长期的主题，没必要一层一层从底建设，浪费时间，并且弃用之后还浪费空间。所以没有恒定的准绳，合适的方法才是最好的方法。

数据仓库层级

关于数据仓库层级的资料有很多。大同小异，基本上分为下面几层

ODS:操作数据层
从数据库直接导入过来的数据，或者日志直接解析获得的数据，是未处理的原始数据，以便进行问题排查使用。
DW:数据仓库
- DWD:明细数据层
  数据清洗/规范化，让数据可用。
- DWB:基础数据层
  数据集成+聚合，计算逻辑下沉到这一层，后续使用简单，一致。
DM:数据主题
抽取相关性高的数据组建主题。可以是大的主题，比如用户，也可能是某个功能团队自己关注的小的数据主题。
APP:报表/分析

数据模型

先说结论:随着存储介质越来越廉价，对项目提供的数据不用考虑什么模型了，都冗余到宽表里就行。这样业务使用的时候更简单方便。
总体来说，模型分为两种。

星形模型
一个事实表多个维表。维表与事实表直接关联。使用简单，维护麻烦。
雪花模型
一个事实表多个维表，维表可能与事实表间接关联。需要多次关联，使用上稍麻烦，但是维护/增加内容简单。

雪花模型更灵活，星型模型更简便。举个例子，快递的数据，里面有"邮编"的字段，邮编对应的省份城市信息，有两种表现形式。星型模型:存在一个表里，key是邮编，另外有两个字段一个是省一个是城市，关联一次就可以获取。雪花模型:存在两个表里，一个存邮编——省份一个存邮编——城市，需要关联两次才能全部获得。
除了使用上的区别，在维护维表的时候也不同。比如如果原来只有省份信息，再添加城市的时候，星型模型就需要对原来的表加字段，要补齐所有邮编对应的城市。而雪花模型，只需要添加一个新的邮编——城市表就可以了。
所以在使用过程中，数据仓库层一般用雪花模型，而主题/应用层用星型模型，虽然有部分冗余，但是使用上更容易。

小结

数据仓库是一个长期/复杂的事情，优秀的数据仓库会对上层屏蔽数据的问题，保证分析挖掘的数据完整，一致，准确，及时。

感想

写了下来，觉得数据仓库也没什么难的，东西一共就这么多，那难点在哪里么？难道是"经验"？可以这么说，因为数据仓库不仅仅需要满足现在的需求，还要考虑将来的需求，做的多了，自然就知道可能下一步需要什么数据，提前处理好，准备着使用。
但是，作为知识，是不能简简单单的用"经验"两个字来表达的，想要做好数据仓库，需要做到以下几点

清楚服务对象。
要明白此刻数据仓库建设重点服务对象。
熟悉业务。
要是自己产品的忠实用户。
了解主题间差异。
项目之内各个模块之间也有差异，了解各自的特点，才能建设好各自的主题。
提供数据
统计报表没有特别的，按照需求提供就可以了。
多维分析用的cube数据，首先不能随意的添加维度，可能只能带来数据膨胀无法带来什么好处。其次在计算的时候不能简简单单的 with cube ，而是要明白数据本身，明白维度之间的对应关系，有层级关系的数据可以通过 grouping sets 来降低计算和存储成本。(使用kylin等工具的时候可以简化设置)
对于挖掘团队提供数据，要懂得做好脏数据离群数据处理，数据降权等操作。减少算法团队对数据的处理压力。
数据规范化
繁琐，需要极大的耐心和细心，如果数据规范化的时候出错，后面的数据仓库啊，主题啊，有什么意义呢？

总之，数据仓库是要紧密贴近业务，与分析师/pm/项目rd，都联系紧密。项目rd打点产生数据，分析师提供分析需求，pm那了解业务。回到"经验"两个字上来，越熟悉，做的越好。

最后吐个小槽，大数据火爆了这么多年，很多公司都有"数据仓库”这个职位，但是很多人根本不知道这个职位应该是干什么的，会说出诸如"我们业务简单，不需要数据仓库”，"什么数据仓库，不就是写sql的么"，"我们数据仓库是平台开发兼职写写sql就做了很简单"，”你们除了提数还会啥"，"为什么你们不重构呢？"这种问题。
确实，在日常工作中，80%的工作用sql来解决，但是这些工作中，sql占的功劳也只有20%。就像当年从意林上看的鸡汤文，一个公司遇到困难，无法解决，出价一万美金找到工程师，工程师在图纸上画了一条线就把问题解决了，公司觉得不公平，你画一条线为什么要一万美金，工程师说"画这条线值1美金，知道在哪里画值9999美金"。数据仓库就是这样，sql有多难？常用的语法有两天就都会了。概念又多深？找几个帖子就把数据仓库的定义，分层什么的都看完了。但是就是这么简单的数据仓库，有的公司不会做，做不好，遇到各种各样的问题没办法解决。
不难，但是不简单，并且重要。

欢迎关注

攻城锤的数据仓库