1、Hadoop数据仓库架构设计

　　　　如上图。

　　　　ODS（Operation Data Store）层：ODS层通常也被称为准备区（Staging area），它们是后续数据仓库层（即基于Kimball维度建模生成的实时表和维度表层，以及基于事实表和明细表

　　　　　　加工的汇总层数据）加工数据的来源，同时ODS层也存储着历史的增量和或全量数据。

　　　　数据仓库层（DW：Data Warehouse）: 是Hadoop数据平台的主体内容。数据仓库层的数据是ODS层数据经过ETL清洗、转换、加载生成的。Hadoop数据仓库的DW层通常都是基于

　　　　　　Kimball的维度建模理论来构建的，并通过维度一致性和和数据总线来保证各个子主题的维度一致性。

　　　　　　DW层的数据一定是清洗过的、干净的、一致的、规范的、准确的数据。数据平台 的下游用户将会直接使用DW层数据，而ODS层数据原则上不允许下游用户直接接触和访问。

　　　　　　此外，出于性能、重复计算和使用便捷性考虑，DW层数据除了保存基于Kimball维度建模的最细粒度的事实表和维度表（DW层的明细层，data warehouse detail 细节数据层），

　　　　　　还会基于它们生成一层汇总数据（即DW层的汇总层，data warehouse service 服务数据层）。汇总层的设计主要出于性能及避免重复计算考虑。实际数据仓库的汇总层如何设计以及主要对

　　　　　　哪些维度进行汇总等，需要根据业务需求及明细层实际汇总频率来确定，原则上，业务使用频繁的的维度需要对这些维度建立汇总层，汇总的指标可以和业务需求共同设计完成。

　　　  应用层：在DW的基础上，各个业务方或部门可以建立自己的数据集市（Data Mart）,此层一般称为应用层。应用层的数据来源于DW层，原则上不允许应用层之间访问ODS层，相比DW层，

　　　　　　应用层只包含部门或业务方自己关心的明细层和汇总层数据。

　　　　采用上述分层架构的好处：

　　　　1、屏蔽源头系统业务变更、系统变更对于下游用户的影响

　　　　　　如果源头系统业务发生变更，相关的变更有DW层来处理，对下游用户透明，无须改动下游用户的代码和逻辑。

　　　　2、屏蔽源头系统的复杂性。

　　　　3、避免重复计算和存储

　　　　　　通过汇总层的引入，避免了下游用户逻辑的重复计算，节省了用户的开发时间和精力，同时也节省了计算和存储。

　　　　4、数据仓库的可维护性

　　　　　　分层的设计使得某一层的问题只在该层得到解决，无须更改下一层的代码和逻辑。

 　　2、Hadoop数据仓库规范设计

　　　　数据仓库的的规范包括很多方面，如数据的命名规范、开发规范、流程规范、安全规范和质量规范等。

　　　　2.1、命名规范

　　　　　　表命名规范

　　　　　　表命名规范是为了让数据所有相关方对于表包含的信息有一个共同的认知。比如属于哪一次（ODS、DW明细层、DW汇总层、应用层）？哪个业务领域（销售、库存、客户服务、催销等）、

　　　　　　哪个维度（商品、买家、卖家、类目等）？哪个时间跨度（天、月、年、实时等）？增量还是全量？

　　　　　　基于此，数据平台建设者应该首先规定数据仓库分层、业务领域、常见维度和时间跨度等的英文缩写，并根据词给出表的命名规范。

　　　　　　对于大型零售超市（FutureRetailer）数据平台，给出如下表命名规范：

　　　　　　第一部分为数据仓库分层：可能取值为ODS(ODS层表)、DWD（DW明细层表）、DWS（DW汇总层表）、ADS（应用层表）等。

　　　　　　第二部分为业务领域：可能取值为sls（销售）、inv（库存）、srv（客户服务）、prmt（促销）等。

　　　　　　第三部分为用户自定义标签：比如商品粒度为itm、买家为byr、卖家为slr。当然用户也可以自己定义自己的业务、项目和产品标签。

　　　　　　第四部分为时间标签：比如d为天、m为月、y为年、di为增量表，df为全量表等。

　　　　　　根据上述设计，一个汇总层、商品粒度的月度销售汇总表的表应该为：dws_sls_itm_m

　　　　字段命名规范

　　　　　　字段命名规范应该有意义而易于理解，最好是能够表达字段含义的英文字母。比如，数量型的字段一般以cnt(count)结尾、数值型的字段以amt（amount）结尾。

　　　　　　实际项目中，数据平台可以提供常用的英文缩写，业务缩写来规范用户的字段命名。

 　　3、流程规范

　　　　流程规范用于开发流程行为，以保证数据交付进度和质量，降低交付风险。

　　　　流程规范主要分为需求流程规范和开发流程规范。

　　　　常见的需求流程规范如下：

　　　　数据开发流程：

　　4、数据仓库构建

　　　　　　维度建模采用有序的四个环节来设计各个业务主题的数据仓库（选择业务过程、定义粒度、确定维度和确定事实），同时维度建模用维度一致性和数据总线架构来保证各个子主题维度数据的一致性。

　　　　首先划分FutureRetailer的业务主题，可以将其主题划分为销售域、库存域、客户服务器域、采购域等。其次是确定每个主题域的事实表和维度表。

　　　　对于每个主题域，比如销售，需要选择最细粒度的数据，很容易确定销售域的最细粒度事实为购物小票的子项。库存域的最细粒度为商品的SKU的库存。客户服务热线的最细粒度为每一次电话呼叫。

　　　　采购域的最细粒度为某个商品的SKU的采购申请等。

　　　　确定粒度之后，相关的维度也基本确定，但是根据Hadoop的反规范和扁平化的设计思路，还需要确定哪些字段需要反规范化和扁平化到相关维度表中。

　　　　　　最后一步就是确定需要是事实表，而且应该明确需要哪种类型是事实表，是事务事实表，还是周期快照事实表以及累计快照事实表？如果维度表反规范化和扁平化设计一样，也要讲使用频率高的维度

　　　　字段反规范化和扁平化到事实表中。

　　　4.1、商品维度表

　　　　将商品维度表命名为dim_fr_item（参照上面的命名方式，fr代表FutureRetailer）

　　　　维度表设计的首要问题是维度表的拆分以及合并问题

　　4.2.、销售事实表

　　　　销售子主题是典型的事务性业务活动，并不涉及业务状态的定期快照，也并非工作流形式的业务活动，因此仅需要事务事实表即可。

　　　　销售事实表将通过商品ID、买家ID、卖家ID等和其它维度表关联。如下图：

　　　　根据Hadoop数据仓库反规范化和扁平化的设计思想，除了度量以及维度外键ID等字段，事实表还需冗余相关常用维度字段到销售事务事实表中。

 　　　　　　参考资料：《离线和实时大数据开发实战》