Hadoop 数据仓库建设实践（理论结合实践）_hadoop完成数据预处理、建立数据仓库、进行数据分析和数据导出(2)

本文链接：https://blog.csdn.net/2401_84182222/article/details/138046462

先自我介绍一下，小编浙江大学毕业，去过华为、字节跳动等大厂，目前阿里P7

深知大多数程序员，想要提升技能，往往是自己摸索成长，但自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年最新大数据全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上大数据知识点，真正体系化！

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新

如果你需要这些资料，可以添加V获取：vip204888 （备注大数据）

正文

整个公司的整体销售趋势如何？
是否应该对某些滞销的商品进行促销？
客户是否在流失？
某些畅销商品是否应该及时补货如何择自营商品从而利润最大化？

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

同时对于 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 层→应用层”的数据仓库逻辑架构如图所示：

未命名文件.png

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

屏蔽源头系统业务变更、系统变更对于下游用户的影晌：如果源头系统业务发生变更，相关的变更由 DW 层来处理，对下游用户透明，无须改动下游用户的代码和逻辑。
屏蔽源头业务系统的复杂性：源头系统可能极为繁杂，而且表命名、字段命名、字段含义等可能五花八门，通过 DW 层来规范和屏蔽所有这些复杂性，保证下游数据用户使用数据的便捷和规范。
避免重复计算和存储：通过汇总层的引人，避免了下游用户逻辑的重复计算，节省了用户的开发时间和精力，同时也节省了计算和存储。
数据仓库的可维护性：分层的设计使得某一层的问题只在该层得到解决，无须更改下一层的代码和逻辑。

Hadoop 数据仓库规范设计

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

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

命名规范

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

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

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

开发规范

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

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

主数据任务的分类和存放（即目录结构的划分） ：公共代码如何存放，个人代码如何存放，项目和产品的代码如何分类存放，实际项目中需要对此进行统筹规划并保证每个人都遵守，以使得用户很容易找到对应项目、产品或者各个层次的代码（ ODS 、DWD、DWS、ADS）。
代码的编程规范：比如任务注释的规范必须包含哪些部分代码的对齐规范、代码的开发约定等。
最佳实践 ：在数据仓库的开发实践中，有些最佳实践（比如货币金额都约定用分来表示、灵活运用时间分区、数据类型定义规范等）都需要用开发规范来约束用户的行为，以确保最佳实践得以落地。