资料仓库是所有产品的资料中心，公司体系下的所有产品产生的所有资料最终都流向资料仓库，可以说资料仓库不产生资料，也不消费资料，只是资料的搬运工。
记得很久以前曾有一位前辈和我说过：“进来的资料是垃圾资料，出去也是垃圾资料”。
在实际环境中，往往我们一条业务线会由多个不同的系统支撑组成（例如：很多电商后端业务线都区分为库存系统、售后系统、采购系统、CRM系统等）。这些系统由于本身设计的缺陷或业务流程变更等问题，所产生的资料往往都是有缺失、冗余的，如果直接使用这些资料去进行资料分析，那最后分析出来的结论多半也不正确。
因此需要有个资料产品来对资料进行整合加工，而资料仓库就是这样一款产品。
要想了解怎么搭建资料仓库，首先需要明白资料仓库的作用：
基于以上几点，需要将资料分层次管理，每一层分工合作，对资料进行不同程度的处理，如同工厂里的流水线一般，从而确保资料的生命性、生态性。
大资料体系整体架构
资料仓库并不是独立存在的一个个体，而是与整个大资料体系融为一体的——换句话说，资料仓库就像人的心脏，人只有心脏而没有其他器官是无法单独存活下来的。
大资料体系架构如图所示：
来源系统
资料的来源系统，可以理解为资料的收集系统。
如图所示为基于电商业务下的大资料体系，因此资料大体可分为业务资料和使用者行为资料，其来源系统更多是与电商业务相关的后端订单、库存等业务系统以及前端商城带来的使用者行为资料。
原始资料层
顾名思义，即存放从来源系统过来的原始资料，所谓原始资料——即未经过任何加工处理的资料。
这一层次咋看之下有点多余，但实际上是有所考量的：
1）将资料仓库与业务系统分隔开
资料仓库的资料，实时性要求不高，而准确性、清洁型必须较高，因此清洗的指令码繁多。如果每条资料都实时传送到资料仓库的话，那指令码执行的频率将非常高，所占用的系统资源也随之增加。
2）分担业务系统的报表任务
总所周知，搭建大资料体系架构所使用的硬件资源是相对较高的，而业务系统往往只是支撑业务持续开展，从效能上往往无法支撑大资料量报表的汇出。因此，原始资料层可以承载此项功能，业务系统资料传输的实时性也保证了从原始资料层汇出的资料符合业务人员对报表实时性的需要。
资料仓库
一般来说，资料仓库可区分为三层：基础资料层、主题层、模型层
基础资料层
原始资料层以天为时间周期，将每天的资料传输到资料仓库，资料仓库通过ETL（抽取、转化、载入）的方式，将资料按照设定的资料表格式储存好，形成基础资料层的资料。
何谓ETL呢？
ETL即：Extra、Transfer、Load——简单来说，即资料清洗。先将资料抽取出来，将冗余资料，错误资料，有歧义的资料按照既定的规则进行删减、填充、修改，再填充入已设定好的表结构的数据库表中。
举个栗子：
从订单系统过来的订单资料上，客户名称多种多样，相同一个客户，有大写的名称、小写的名称、有些订单甚至没有客户的相关资讯（这当然是业务系统本身的历史遗留问题导致的）。此时，作为资料产品经理必须要了解这些资料的“坑”，并且和对应业务系统的产品经理共同商讨如何处理这批资料，确定好清洗逻辑（例如：所有名称统一转化为小写，如果客户名称、地址、电话号码都是同一个的，归为同一个客户），程式猿们根据资料产品经理的清洗规则写好指令码进行清洗。
资料清洗就像打扫卫生一样，将不要的东西扔掉，将破旧的东西擦拭干净，但并不代表资料是完整的。
主题层的构建相对复杂，搭建的规则主要是看未来的需要以及产品经理对业务的理解。
举个栗子：
题主所在的公司是一家大型零售分销公司，因此往往有一张订单卖给零售商，零售商再下一张订单给零售店，零售单再下一张订单给终端使用者。此时，每一级订单是断层，且来源于不同的系统的，因此每一级订单的表结构完全不同。
这样导致的结果是：无法从全链条上看到每一个商品在渠道中的流转，也无法实时跟踪到每个商品的具体转化效率。所以，需要把每一级的订单按照主题分门别类（一级订单、二级订单、三级订单），并且建立一种关联关系，使这三者能串联起来，形成一整个渠道流程。
资料来到模型层，也就意味着他们最终要成为“炮弹”，发射到资料分析平台了，因此模型层的最主要作用是：将主题资料组合成资料分析模型。
假设我们需要在资料分析平台上体现出“不同商品在不同区域不同客户的热销情况”，那在模型层就需要以订单表作为最基础的表，关联上区域表、客户表、商品表，关联出一个以区域+商品+客户特征维度划分的明细资料。每个区域每个商品每个客户对应一行销售资料，根据这份资料汇总出一个按区域+商品+客户特征的模型，输出到资料分析平台，展示出不同区域，不同商品的客户特征是怎样的。
需要注意的是：模型层的资料都是呈现出星状结构和高度索引化的。
因为在大资料平台上，资料与资料之间往往是需要存在关联的，运营人员看到商品在不同区域上的销量分布，往往也想进一步看到在不同区域上的商品有什么特征，客户有什么特征，这些都需要和区域强关联起来的。
资料应用层
资料应用层严格意义上不属于大资料架构，因为它除了会涉及各式各样的资料分析平台，还会涉及到业务系统。
资料反哺
上文提到过，业务系统对于资料仓库而言更多是作为资料收集工具，但同时业务系统也存在着资料的需求，我把这样的过程称为资料反哺。
往往支撑公司业务开展下去的业务系统不止一个，很可能是有多个，而各式各样的业务系统之间也需要资料互动。例如：一般电商公司会有一套前端商家平台，也会一套后端的管理平台，这两套平台使用的往往不是同一套SKU，因此需要将后端SKU同步到前端来进行mapping。
那么为什么不能直接让这两套系统直接进行资料互动呢？
因为资料已经不再干净，需要资料仓库进行清洗过后，将冗余的资料去除后方可推送至前端商家平台。
分析模型输出
资料仓库的资料，最终除了会流向业务系统以外，更多的会流向各大资料应用系统，即：资料大屏，大资料分析平台等
此时的资料，已经过层层清洗加工、模型搭建，形成一个个炮弹，通过界面的形式推送至各大资料平台。对于这些资料分析、资料展示平台而言，更多的只需要考虑如何直观展示资料即可。
总结
资料仓库不产生资料，也不消费资料，如果把资料比作是水的话，可以将它理解成矿泉水厂商：负责将水抽取上来->排污->打包->运送。说来容易，做来难，其中辛酸与难度只有资料产品经理能理解。
本文由 @Leo 原创释出于人人都是产品经理。未经许可，禁止转载
题图来自Unsplash，基于CC0协议
