Hadoop 数据仓库开发实战(二)

7.3 Hadoop 数据仓库规范设计

            对于一个公司或者组织来说，使用数据的用户可能成百上千，如何降低大家对于数据使用的沟通成本、如何通过规范大家的行为来降低使用数据的风险，这些问题是必须加以考虑的。
            
            实际实践中，通常用数据仓库的规范来达到此目的。数据仓库的规范包括很多方面，如数据的命名规范、开发规范、流程规范、安全规范和质量规范等，下面将结合 物美的业务介绍常用的命名、开发和流程规范。

7.3.1 命名规范

                命名规范主要分为表命名和字段命名规范等，下面分别介绍。

                1、表命名规范

                表命名规范是为了让数据所有相关方对于表包含的信息有一个共同的认知。比如属于哪一层(ODS、DW明细层、DW汇总层、应用层)？哪个业务领域(销售、库存、客户服务、促销等)？哪个维度(商品、买家、卖家、类目等)？哪个时间跨度(天、月、年、实时)？增量还是全量？
                基于此，数据平台建设者应该首先规定数据仓库分层、业务领域、常见维度和时间跨度等的英文缩写，并据此给出表的命名规范。
                
                对于物美数据平台，本文给出命名规范如下:
                
                第一部分为表数据仓库分层:可能取值为 ODS(ODS层表)、DWD(DW明细层表)、DWS(DW汇总层表)、ADS(应用层表)等。
                
                第二部分分为业务领域:可能取值 sls(销售)、inv(库存)、srv(客户服务)、prmt(促销)等。
                
                第三部分为用户自定义标签:比如商品粒度为 itm，买家为byr，卖家为 slr。当然用户也可以自己定义自己的业务、项目和产品标签。
                
                第四部分为时间标签:比如 d为天、m为月、 y为年、di为增量表、df为全量表的。
                根据上述设计，一个汇总层、商品粒度的月度销售汇总表的表名应该为:
                dws_sls_itm_m。

                2.字段命名规范

                字段命名规范应该是有意义而且易于理解的，最好是都能表达字段含义的英文字母。比如，数量型的字段一般以cnt(COUNT)结尾，数值型的字段以amt(amount)结尾，标签性的字段应该以is 打头。实际项目中，数据平台方可以提供常用的英文缩写、业务缩写等来规范用户的字段命名。
        

    7.3.2 开发规范

                
            开发规范主要用于规范和约束数据开发人员和使用人员的习惯，以最大限度地降低数据的使用风险，并同时保证用户遵守最佳实践。毕竟数据代码并不仅是给自己看的，很多时候需要供他人阅读和参考，尤其是处理问题的时候。
            
            开发规范主要包含一下几个方面
            
            数据任务的分类和存放(即目录结构的划分):公共代码如何存放，个人代码如何存放，项目和产品的代码如何分类存放，实际项目中需要对此进行统筹规划并保证每个人都遵守，以使得用户很容易找到对应项目、产品或者各个层次的代码(ODS、DWD、DWS、ADS)。
            
            代码的编程规范: 比如任务注释的规范必须包含哪些部分、代码的对齐规范、代码的开发约定等。
                
            最佳实践: 在数据仓库的开发实践中，有些最佳实践(比如货币金额都约定用分来表示、灵活运用时间分区、数据类型定义规范等)都需要用开发规范来约束用户的行为，以确保最佳实践得以落地。

7.3.3 流程规范

            流程规范用于规范开发流程行为，以保证数据交付进度和质量，降低交付风险。
            流程规范主要分为需求流程规范和开发流程规范，常见的需求流程规范如图 

             

                        

 7.4 物美数据仓库构建实践

            作为一家全国性的大型零售超市，物美总部的职能部门以及FutureRetailer各个区域、城市对于各自业务领域都有强烈的数据需求。
            维度建模采用有序的四个环节来设计各个业务主题的数据仓库(即选择业务过程、定义粒度、确定维度和确定事实)，同时维度建模用维度一致性和数据总线架构来保证各个子主题维度数据的一致性。
        
            首先划分物美业务的主题，很容易将其主题划分为销售域、库存域、客户服务域、采购域等，其次就是确定每个主题域的事实表和维度表。
            
            对于上述每个主题域，比如销售，需要选择最细粒度的数据，很容易确定销售域的最细粒度事实为购物小票的子项、库存域的最细粒度为商品SKU的库存、客户服务热线的最细粒度事实为一次电话呼叫、采购域的最细粒度为某个商品SKU的采购申请。
            
            确定粒度之后，相关的维度也已经基本确定，但是根据Hadoop反规范和扁平化的设计思想，还需要确定哪些字段需要反规范化和扁平化到相关维度表中。
            
            最后一步就是确定需要的事实表，而且应该明确需要那种类型的事实表，是事务事实表，还是周期快照事实表以及累计快照事实表？如同维度表的反规范化和扁平化设计一样，也要将使用频率高的维度字段反规范化和扁平化到事实表中。
            
            上面描述了构建物美数据仓库的整体过程，下面以商品维度表和销售事实表为例分别介绍构建维度表和事实表的设计，包含示例结果、设计原因等，读着可依次完成其他域的事实表和维度表的设计。

7.4.1 商品维度表

            将物美的商品维度表命名为 dim_wm_item(参照签名的命名方式,wm代表物美)，其具体设计和包含的字段以及相应注释如图:
            对 dim_wm_item 维度表的设计详细说明如下。
            
            1）维度表设计的首要问题是维度表的拆分以及合并问题: 物美主要是商超业务，因此本实例设计了一个 dim_wm_item 来存放其所有商品的共有属性，但是这些共有属性可能并不能满足所有商品的业务分析要求，比如也许物美在其收银台或者商超出入口还搭售旅游、度假等产品。显然，旅游、度假产品和普通的日用品有着很大的差异，不管是产品本身还是业务分析等方面，此时可以将共有属性存放在 dim_fr_item，同时再新建一个旅游度假的商品表(如dim_wm_item_trip) 来存放旅游、度假类商品。 dim_wm_item_trip 的字段将包含旅游独家的相关字段(和 dim_wm_item 的共有字段一般处于使用便捷考虑也存放在 dim_wm_item_trip 中)，如果有另一个业务比较独特，也可以做类似处理。但是不管多少个业务、多少个业务自身的商品表，需要保证这些商品总是存放在
            dim_wm_item 中，否则就无法保证维度一致性。
            
            
            
            2) 对于缓慢变化维和微型维度的问题， dim_wm_item 通过快照和分区字段来解决，即 dim_fr_item 将每天存放一份全量数据快照，存放的生命周期由业务需求确定。具体来说，dim_fr_item 将会有一个分区字段 day，day的取值为
            日期(例如 20170101、 20170102 等)，包含当天商品的全量快照。
            
            对于类目等有层级的商品属性，dim_wm_item 进行了扁平化和冗余处理，以便于下游用户使用(否则用户下游还需要自己关联类目表)。
            
            对于属性存在多值的情况，如店铺存在多个联系人，dim_wm_item 采用了扁平化方式而不是桥接表的方式处理。
            
            dim_wm_item 还包含了最近7天、30天等成交数据，这就是所谓的行为维度。
            
            处于属性扩展性考虑。dim_wm_item 将包含 JSON 和 keyvalue的大字段。大字段的引入带来了扩展性，但是相应地增加了使用成本，也使便捷性降低，因为下游用户需要自己解析。当然，维度表的设计开发人员也必须对大字段所包含的字段以及提取方式进行仔细说明。

7.4.2 销售事实表
                

                销售子主题是典型的事务性业务活动，并不涉及业务状态的定期快照，也并非工作流形式的业务活动，因此仅需事务性事实表即可。
                
                销售事实表将通过商品 ID、 卖家ID 、买家ID 等和其他维度表关联。如下图:
                
                根据Hadoop 数仓反规范化和扁平化的设计思想，除了度量以及维度外键 id等字段，事实表还需冗余相关常用维度字段到销售事务事实表中。
                
                * 商品标题、商品类目、商品品牌、供应商等信息等冗余到了此销售事务事实表中。
                * 小票编号、用户开发的发票号等也已作为退化维度保存在此销售事务事实表中。
                * 买家星级、供应商评级、商品评级等新伟维度也冗余在此销售事务事实表中。
                * 商品所属的各级类目等有层级的属性也都扁平化在此销售事务事实表中。其他如行业等级、品牌等级也可类似处置，便于下游使用。
                * 此销售事务事实表包含了订单大字段来包含订单上的各种标签，比如是否参加某次促销活动以及当时订单项商品所包含的各种状态等，这些标签都存放在了订单大字段中，后续使用只需用 key value/ 或 JSON 解析即可(取决于存储方式)。