​

 前言

前面和大家分享了，维度建模的理论基础，包括维度表设计的方法论和深入剖析了事实表，今天就理论结合实践，和大家聊聊完整的一个数仓构建的过程！

数据的重要性和战略意义毋庸置疑，目前业界也都在热火朝天地将大数据战略落地和用于实战。

在这个过程中，我们首要的问题就是数据平台的搭建，主要包括物理和逻辑两个方面：

• 物理数据平台的搭建包括 硬件、大数据工具和技术的选型、购买、搭建 等；

• 逻辑数据平台的搭建则包含 数据平台架构设计、数据规范制定、数据开发实施和维护 等。

物理平台的搭建可以购买成熟的独立商业解决方案，也可以 DIY （自己购买服务器、存储等各种硬件平台、并购买商用数据处理软件和工具或者选用开源的数据处理框架，如 Hadoop、Hive、Kettle 等，自己自由组合搭建数据平台）。

但是数据平台已然成为了一个机构和组织的关键基础设施，已经像“水电煤”一样不可或缺了。

既然是“水电煤”，那么还需要自己“发电”和“供水”吗？为什么要自己搭建物理数据平台并负责维护呢？目前技术的发展实际上也给出了否定的答案，未来的数据和数据平台就如同业务系统一样，都会在云端（可能是公有云，也可能是专有云）。随需随用，所以基于云的数据平台解决方案势必会成为主流。

业务背景

我们就假设某虚拟的、全国连锁的大型零售超市 FutureRetailer 为对象（国外的对标公司为沃尔玛、家乐福、乐购等），为其搭建基于 Hadoop 的数据仓库。之所以选择零售业务，是因为大家都非常熟悉其业务，包括全国连锁业务形态、收银台购物流程、商品供应、商品库存管理等。

并且 FutureRetailer 在全国的各个城市内运营着数以千计的超市 ，根据城市的人口规模和大小不同，门店也不同，比如对于一线或者重点二线城市，其门店可能数以十计甚至几十计，在某些三四级城市或者乡镇来说，可能只有一个甚至没有。其每一个门店都包含了完整各类商品包含杂货、日常生活用品、水果生鲜、肉类、蔬菜、冷冻食品、花卉等。

所以，对于 FutureRetailer 来说，数据仓库平台对其至关重要。因为数据平台是其数据化运营的前提和基础，基于数据仓库平台生成的各种销售报表和库存报表是公司管理层和各个城市运营人员以及门店运营人员决策的主要依据。

• 整个公司的整体销售趋势如何？

• 是否应该对某些滞销的商品进行促销？

• 客户是否在流失？

• 某些畅销商品是否应该及时补货 如何择自营商品从而利润最大化？

以上这些我们都需要通过及时、准确和精炼过的数据来支持。

同时对于 FutureRetailer 来说，过去的数据分析只是一个方面，更为重要的是对于未来的预测和分析。比如未来商品销售估计，并据此制订采购计划 。随着新零售的兴起，未来的消费者需要的是更为个性化的服务和产品，如何将这种个性化的商品和服务提供给消费者？

马爸爸也说过：“纯电商时代过去了，未来十年是新零售的时代”。

对 FutureRetailer 来说，未来的购物也许将会是如下情景：

1 ）一位资深 FutureRetailer 会员，其近年来购买商品的种类、型号、时间 、支付方式、会员卡基本信息、住址、联系方式，以及由此生成的会员购买商品档次评级、消费评级、退款评价等都被数据平台详细记录。

2 ）会员步入超市或者开车进入超市停车场， FutureRetailer 车牌识别系统、视频系统或者 WiFi 网络（如果会员通过手机接人）捕获到会员来访，预测会员可能的购买清单，井有针对性地生成促销和优惠信息 。比如，会员上次拿起某件商品仔细查看了商品价格但没有购买，那么 FutureRetailer 此次将推荐另一个高性价比的同款商品给会员。

3 ）会员到收银台结账， FutureRetailer 会预测下次会员的来访时间，并更新采购计划和清单等。

上述所有智能化的、个性化的购买行为必须借助数据平台的支撑。

Hadoop 数据仓库架构设计

首先介绍基于 Hadoop 的数据仓库逻辑架构，在 Hadoop 数据仓库的实际设计中，通常出于可维护性、性能成本以及使用便捷性考虑，会对数据仓库中的表进行分层。

来自于源头操作性系统的数据表通常会原封不动地存储一份，这称为 ODS ( Operation Data Store ）层 。ODS 层通常也被称为准备区（ staging area ），它们是后续数据仓库层（即基于 Kimball 维度建模生成的事实表和维度表层，以及基于这些事实表和明细表加工的汇总层数据）加工数据的来源。同时 ODS 层也存储着历史的增量或者全量数据。

数据仓库层（DW 层）是 Hadoop 数据平台的主体内容。

数据仓库层的数据是 ODS 层数据经过 ETL 清洗、转换、加载生成的。 Hadoop 数据仓库的 DW 层通常都是基于 Kimball 的维度建模理论来构建的，并通过 维度一致性 和 数据总线 来保证各个子主题的维度一致性。

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

此外，处于性能、重复计算和使用便捷性考虑， DW 层数据除了保存基于 Kimball 维度建模的最细校度的事实表和维度表（即 DW 层的明细层），还会基于它们生成一层汇总数据（即 DW 的汇总层）。

汇总层的设计 主要是出于性能以及避免重复计算考虑。实际数据仓库的汇总层如何设计以及主要对哪些维度进行汇总等，需要根据业务需求以及明细层实际汇总频率来确定，原则上，业务使用频繁的维度需要对这些维度建立汇总层，汇总的指标可以和业务需求方共同设计完成。

在 DW 层的基础上，各个业务方或者部门可以建立自己的 数据集市（ Data Mart ），此层一般称为 应用层 。应用层的数据来源于 DW 层，原则上不允许应用层直接访问 ODS 层，相比 DW 层，应用层只包含部门或者业务方自己关心的明细层和汇总层数据。

不同于 DW 层字段和指标的通用性，应用层可以包含自己业务或者部门特殊的指标或者字段，但是如果需要横向和其他部门对比， 必须采用公共层公用的指标和字段 。

采用上述“ ODS 层→ DW 层→应用层”的数据仓库逻辑架构如图所示：

项目实际中，采用上述分层架构可以有以下好处：

• 屏蔽源头系统业务变更、系统变更对于下游用户的影晌： 如果源头系统业务发生变更，相关的变更由 DW 层来处理，对下游用户透明，无须改动下游用户的代码和逻辑。

• 屏蔽源头业务系统的复杂性： 源头系统可能极为繁杂，而且表命名、字段命名 、字段含义等可能五花八门，通过 DW 层来规范和屏蔽所有这些复杂性，保证下游数据用户使用数据的便捷和规范。

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

• 数据仓库的可维护性： 分层的设计使得某一层的问题只在该层得到解决，无须更改下一层的代码和逻辑。

Hadoop 数据仓库规范设计

对于一个公司或者组织来说，使用数据的用户可能成百上千，如何降低大家对于数据使用的沟通成本、如何通过规范大家的行为来降低使用数据的风险，这些问题是必须加以考虑的。

我们在实际实践中，通常用数据仓库的规范来达到此目的。数据仓库的规范包括很多方面，如数据的命名规范、开发规范、流程规范、安全规范和质量规范等，下面将结合 FutureRetail 业务介绍常用的命名、开发和流程规范。

命名规范

命名的规范主要分为表命名的规范和字段命名的规范。

其中表命名的规范是为了让数据所有相关方对表包含的信息有一个共同的认知，比如属于哪一层（ODS、DWD、DWS、ADS）？哪个业务领域（销售、库存、促销）等？哪个维度（商品、买家、卖家、类目等）？哪个时间跨度（天、月、年、实时）？增量还是全量？

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

开发规范

开发规范主要用于规范和约束数据开发人员和使用人员的习惯，以最大限度地降低数据的使用风险，并同时保证用户遵守最佳实践 毕竟数据代码并不仅是给自己看的，很多时候也需要供他人阅读和参考， 尤其是处理问题的时候。

开发规范主要包含以下几个方面。

• 主数据任务的分类和存放（即目录结构的划分） ：公共代码如何存放，个人代码如何存放，项目和产品的代码如何分类存放，实际项目中需要对此进行统筹规划并保证每个人都遵守，以使得用户很容易找到对应项目、产品或者各个层次的代码（ ODS 、DWD、DWS、ADS）。

• 代码的编程规范： 比如任务注释的规范必须包含哪些部分 代码的对齐规范、代码的开发约定等。

• 最佳实践 ：在数据仓库的开发实践中，有些最佳实践（比如货币金额都约定用分来表示、灵活运用时间分区、数据类型定义规范等）都需要用开发规范来约束用户的行为，以确保最佳实践得以落地。

流程规范

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

流程规范主要分为需求流程规范和开发流程规范，常见的需求流程规范如图：

​

常见的开发流程规范如图：

FutureRetailer 数据仓库构建实践

作为一家全国性的大型零售超市，FutureRetailer 总部的职能部门以及 FutureRetailer 各个区域、城市对于各自业务领域都有强烈的数据需求。

我们在前面介绍了 Kimball 维度建模理论为基础构建的数据仓库，在维度建模环节我们会采用有序的四个环节来设计各个业务主题的数据仓库（即 选择业务过程、定义粒度、确定维度和确定事实），同时维度建模用 维度一致性 和 数据总线架构 来保证各个子主题维度数据的一致性。

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

对于上述每个主题域，比如销售，需要选择 最细粒度的数据，很容易确定销售数据域的最细粒度事务为购物小票的子项、库存域的最细粒度为商品 SKU 的库存等。

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

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

上面描述了构建 FutureRetailer 的数据仓库的整体过程，后面还会以商品维度表和销售事实表为例，给大家分别介绍构建维度表和事实表的设计，包含示例结果，设计原因等， 其他域的事实表和维度表的设计到时以此为依据即可。

​