第 1 章：数据仓库概述
1.1 数据仓库概念
数据仓库是一个为数据分析而设计的企业级数据管理系统。数据仓库可集中、整合多个信息源的大量数据，凭借数据仓库的分析能力，企业可从数据中获得宝贵的信息进而改进决策。同时，随着时间的退役，数据仓库中积累的大量历史数据对于数据科学家和业务分析师也是非常宝贵的。
1.2 数据仓库核心架构
业务系统（左侧蓝色部分）：
数据通过DataX和Maxwell工具从业务系统中抽取。 另一个数据来源是通过Flume，可能是用于抽取日志数据等。 数据仓库（中间绿色部分，标记为Hive）：
ODS（操作数据存储）：原始数据层，用于存储经过初步清洗的数据。 DWD（数据仓库明细表）：细节数据层，可能是对ODS层数据做进一步的加工和整合。 DIM（维度表）：用于存储维度数据，这些是分析过程中用于分组、过滤等操作的属性数据。 DWS（数据仓库汇总表）：汇总数据层，这里的数据经过了进一步的聚合和汇总，用于高效的分析查询。 ADS（应用数据存储）：应用层数据，为了服务最终用户的查询和报表，数据可能被进一步加工成更易于理解和查询的形式。 报表（右侧黄色部分）：
数据在经过处理和转换后，最终被用于生成报表，这可能包括图形化的数据展示，如饼图、柱状图等，用于辅助决策支持。 此外，图中还提到了“Dolphin Scheduler”，它是一个分布式可视化的工作流任务调度系统，用于自动化的调度和监控数据处理流程。通过这个工具，可以定期地从业务系统中抽取数据，经过Hive数据仓库处理后，输出到报表系统供用户分析和查看。
2.1 数据仓库建模的意义
如果把数据看作图书馆的书，我们希望看到它们在书架上分门别类的放置
2.2 数据仓库建模方法论
2.2.1 er模型
1、实体关系模型 实体关系模型将复杂的数据抽象为两个概念-实体和关系。实体表示一个对象，例如学生、班级，关系是指两个实体之间的关系，例如学生和班级之间的从属关系。 2、数据库规范化 减少数据冗余，增加数据的一致性。遵循的范式级别越高，数据冗余性越低 3、三范式 1）函数依赖 （1）完全函数依赖 比如（学号，课程）推出学分，但是单独用学号推断不出分数，可以说：分数完全依赖于（学号，课程） （2）部分函数依赖 比如（学号，课程）推出姓名，因为其实可以直接通过，学号推出姓名，所以：姓名部分依赖于（学号，课程） （3）传递函数依赖 学号推出系名，系名推出系主任，但是，系主任推不出学号，系主任主要依赖于系名。可以说：系主任传递依赖于学号 2）第一范式 属性不可用分割
3）第二范式 不存在部分函数依赖
4）第三范式 不能存在传递函数依赖
这种建模方法的出发点是整合数据，其目的是将整个企业的数据进行组合和合并，并进行规范化处理，减少数据冗余性，保证数据的一致性。这种模型并不适合直接用于分析统计。
2.2.2 维度模型
维度模型将复杂的业务通过事实和维度两个概念进行呈现。事实通常对应业务过程，而维度通常对应业务过程发生时所处的环境。 注意：业务过程可以概括为一个个不可拆分的行为事件，例如电商交易中的下单，取消订单，付款，推单等，都是业务过程。 下图为一个典型的维度模型，其中位于中心的salesorder为事实表，其中保存的是下单这个业务过程的所有记录。位于周围每张表都是维度表，包括data，customer，product，location等，这些维度表就组成了每个订单发生时所处的环境，即何人、何时、在何地下单了何种产品。从图中可以看出，模型相对清晰，简洁。
维度建模以数据分析作为出发点，为数据分析服务，因此它关注的重点的是用户如何更快的完成需求分析以及如何实现较大的大规模复杂查询的响应性能。
第 3 章：维度建模理论之事实表
3.1 事实表概述
事实表作为数据仓库维度建模的核心，紧紧围绕着业务过程来设计。其包含与该业务过程有关的维度引用（维度表外键）以及该业务过程的度量（通常是可累加的数据类型字段）
3.1.1 事实表特点
事实表通常比较“细长”，即列较少，但行较多，且行的增速快
3.1.2 事实表分类
事实表有三种类型：分别是事务事实表、周期快照事实表和累计快照事实表，每种事实表都具有不同的特点和使用场景。
3.2 事务型事实表
3.2.1 概述
事务事实表用来记录各业务过程，它保存的是各业务过程的原子操作事件，即最细粒度的操作事件。粒度是指事实表中一行数据所表达的业务细节程度。
3.2.2 设计流程
选择业务过程-》声明粒度-》确定维度-》确认事实 1、选择业务过程 在业务系统中，挑选我们感兴趣的业务过程，业务过程可以概括为一个个不可拆分的行为事件，例如电商交易的下单，取消订单，付款，退单等，都是业务过程。通常情况下，一个业务过程对应一张事务型事实表。 2、声明粒度 业务过程确定后，需要为每个业务过程声明粒度。即精确定义每张事务型事实表的每行数据表示什么，应该尽可能选择最细粒度，以此来应对各种细节程度的需求。 典型的粒度声明如下： 订单事实表中一行数据表示的是一个订单中的一个商品项。 3、确定维度 确定维度具体是指，确定与每张事务型事实表相关的维度有哪些。 确定维度时应尽量多的选择与业务过程相关的环境信息。因为维度的丰富程度就决定了维度模型能够支持的指标丰富程度 4、确定事实 此处的事实一词，指的是每个业务过程的度量值（通常是可累加的数字类型的值，例如：次数、个数、件数、金额等） 经过上述四个步骤，事务型事实表就基本设计完成了。第一步选择业务过程可以确定有哪些事务型事实表，第二步可以确定每张事务型事实表的每行数据是什么。第三步可以确定每张是无线事实表的维度外键，第四步可以确定每张事务型事实表的度量值字段。
3.2.3 不足
事务型事实表可以保存所有业务过程的最细粒度的操作事件，故理论上其可以支撑与各业务过程相关的各种统计粒度的需求。但对于某个特定类型的需求，其逻辑可能会比较复杂，或者效率会比较底下。例如： 1、存量型指标 例如商品库存，账户余额等。此处以电商中的虚拟货币为例，虚拟货币业务包含的业务过程主要包括获取货币和使用货币，两个业务过程各自对应一张事务型事实表，一张存储所有的获取货币的原子操作事件，另一张存储所有使用货币的原子操作事件。 假定现有一个需求，要求统计截至当日的各用户虚拟货币金额。由于获取货币和使用货币均会影响到余额，故需要对两张事务型事实表进行聚合，且需要区分两者对余额的影响（加或减），另外需要对两张表的全表数据聚合才会得到统计结果。 可以看到，不论是从逻辑上还是效率上考虑，这都不是一个好的方案 2、多事务关联统计 例如，现需要统计最近30天，用户下单到支付的时间间隔的平均值。统计思路应该是找到下单事务事实表和支付事务事实表，过滤出最近30天的记录，然后按照订单id对两张事实表进行关联，之后用支付时间减少下单时间，然后再求平均值。 逻辑上虽然并不复杂，但是其效率较低，应为下单事务事实表和支付事务事实表均为大表，大表join大表的操作应尽量避免。 可以看到，在上述两种场景下事务型事实表的表现并不离线。下面要介绍的另外两种类型的事实表就是为例弥补是无线事实表的不足的。
3.3 周期性快照事实表
3.3.1 概述
周期快照事实表以其规律性的、可预见性的时间间隔来记录事实，主要用于分析一些存量型（例如商品库存，账户余额）或者状态型（空气温度，行驶速度）指标。 对于商品库存、账户余额这些存量型指标，业务系统中通常会计算并保存最新结果，所以定期同步一份全量数据到数据仓库，构建周期性快照事实表，就能轻松应对此类统计需求，而无需再对事务型事实表中大量的历史记录进行汇和了。 对于空气温度、行驶速度这些状态型指标，由于它们的值往往是连续的，我们无法捕获其变动的原子事务操作，所以无法使用事务型事实表统计此类需求。而只能定期对其进行采样，构建周期型快照事实表。
3.3.2 设计流程
1、确定粒度 周期型快照事实表的粒度可由采样周期和维度描述，故确定采样周期和维度后即可确定粒度。 采样周期通常选择每日。 维度可根据统计指标决定，例如指标为统计每个仓库中每种商品的库存，则可确定维度为仓库和商品。 确定完采样周期和维度后，即可确定该表粒度为每日-仓库-商品。 2、确认事实 事实也可根据统计指标决定，例如指标为统计每个仓库中每种商品的库存，则事实为商品库存。
3.3.3 事实类型
此处的事实类型是指度量值的类型，而非事实表的类型。事实（度量值）供分为三类，分别是可加事实，半可加事实和不可加事实。 1、可加事实 可以按照与事实表相关的所有维度进行累加，例如事务型事实表中的事实。 2、半可加事实 半可加事实是指按照与事实表相关的一部分维度进行累加，例如周期型快照事实表中的事实。以上述各仓库中各商品的库存每天快照事实表为例，这张表的库存事实可以按照库存或者商品维度进行累加，但是不能按照时间维度进行累加，因为将每天的库存累加起来是没有任何意义的。 3、不可加事实 完全不具备可加性，例如比率型事实。不可加事实通常转化为可加事实，例如比率可转化为分子和分母
3.4 累计型快照事实表
3.4.1 概述
累计快照事实表是基于一个业务流程中的多个关键业务过程联合处理而构建的事实表，如交易流程中的下单、支付、发货、确认收货业务过程。 累积型快照事实表通常具有多个日期字段，每个日期对于业务流程中的一个关键业务过程。
累积性快照事实表主要用于分析业务过程之间的时间间隔等需求。例如前文提到的用户下单到支付的平均时间间隔，使用累积型快照事实表进行统计，就能避免两个事务事实表的关联操作，从而变得十分简单高效。
3.4.2 设计流程
累积性快照事实表的设计流程同事务型事实表类似，也可采用以下四个步骤，下面重点描述与事务型事实表的不同之处。 选择业务过程-》声明粒度-》确认粒度-》确认事实 1、选择业务过程 选择一个业务流程中需要关联分析的多个关键业务过程，多个业务过程对应一张累计型快照事实表。 2、声明粒度 精确定义每行数据表示的是什么，尽量选择最小粒度。 3、确认维度 选择与各业务过程相关的维度，需要注意的是，各业务过程均需要一个日期维度 4、确认事实 选择各业务过程的度量值
第 4 章：维度建模理论之维度表
4.1 维度表概述
维度表是维度建模的基础和灵魂。前文提到，事实表紧紧围绕业务过程进行设计，而维度表则围绕业务过程所处的环境进行设计。维度表主要包含一个主键和各种维度字段，维度字段称为维度属性。
4.2 维度表设计步骤
1、确定维度（表） 在设计事实表时，已经确定了与每个事实表相关的维度，理论上每个相关维度均需对应一张维度表。需要注意，可能存在多个事实表与同一个维度都相关的情况，这种情况需保证维度的唯一性，即只创建一张维度表。另外，如果某些维度表的维度属性很少，例如只有一个**名称，则可不创建该维度表，而把该表的维度属性直接增加到与之相关的事实表中，这个操作称为维度退化。 2、确定主维表和相关维表 此处的主维表和相关维表均指业务系统中与某维度相关的表。例如业务系统中与商品相关的表有sku_info,spu_info,base_trademark,base_category3,base_category2,base_category1等，其中sku_info就称为商品维度的主维表，其余表称为商品维度的相关维表。维度表的粒度通常与主维表相同。 3、确定维度属性 确定维度属性即确定维度表字段。维度属性主要来自于业务系统中与该维度对应的主维表和相关维表。维度属性可直接从主维表或相关维表中选择，也可通过进一步加工得到。 确定维度属性时，需要遵循以下要求： 1）尽可能生成丰富的维度属性 维度属性是后续做分析统计时的查询约束条件、分组字段的基本来源，是数据易用性的关键。维度属性的丰富程度直接影响到数据模型能够支持的指标的丰富程度。 2）尽量不使用编码，而使用明确的文字说明，一般可以编码和文字共存 3）尽量沉淀出通用的维度属性 有些维度属性的获取需要进行比较复杂的逻辑处理，例如需要通过多个字段拼接得到。为避免后续每次使用时的重复处理，可将这些维度属性沉淀到维度表中。
4.3 维度设计要点
4.3.1 规范化与反规范化
规范化是指使用一系列范式设计数据库的过程，其目的是减少数据冗余，增强数据的一致性。通常情况下，规范化之后，一张表的字段会拆分到多张表。 反规范化是指将多张表的数据冗余到一张表，其目的是减少join操作，提高查询性能。在设计维度表时，如果对其进行规范化，得到的维度模型称为雪花模型，如果对其进行反规范化，得到的模型称为星型模型。
4.3.2
保存维度数据的历史状态，通常由以下两种做法，分别是全量快照表和拉链表。 1、全量快照表 2、拉链表 1）什么是拉链比奥 记录每条信息的生命周期，一旦一条记录的生命周期结束，就重新开始一条新的记录，并把当前日期放入生效开始日期。如果当前信息至今有效，在生效结束日期中填入一个极大值（如9999-12-31） 2）为什么做拉链表 适用于数据会发生变化，但是变法频率不是很高的维度。比如用户信息。
4.3.3 多值维度
如果事实表中一条记录在某个维度表中有多条记录与之对应，称为多值维度。例如，下单事实表中的一条记录为一个订单，一个订单可能包含多个商品，所以商品维度表中就可能有多条数据与之对应。 针对这种情况： 第一种：降低事实表的粒度，例如将订单事实表的粒度由一个订单降低为一个订单中的商品项。 第二种：在事实表中采用多字段保存多个维度值，每个字段保存一个维度id。这种方案知识和多值维度个数固定的情况。 建议使用第一种。
4.3.4 多值属性
维度表中的某个属性同时有多个值，称之为“多值属性”，例如商品维度的平台属性和销售属性，每个商品均有多个属性值。 第一种：将多值属性放到一个字段，该字段内容为：key1：value1，kay2：value2的形式。 第二种：将多值属性放到多个字段，每个字段对应一个属性。这种方案适合多值属性个数固定的情况。
第 6 章：数据仓库环境住呢比
6.1 数据仓库运行环境
6.1.1 hive环境搭建
1、hive引擎介绍 hive引擎包括：默认mr、tez、spark hive on spark：hive既作为存储元数据又负责sql的解析优化，语法是hql语法，执行引擎变成了spark，spark负责采用rdd执行。 spark on hive：hive只作为存储元数据，spark负责sql解析优化，语法是spark sql语法，spark负责采用rdd执行。 2、hive on spark配置 在hive所有节点部署spark。 hive任务最终由spark来执行，spark任务资源分配由yarn来调度，该任务有可能被分配到集群的任何一个节点。所以需要将spark的依赖上传到hdfs集群路径，这样集群中任何一个节点都能获取到。
6.1.2 yarn环境配置
增加applicationmaster资源比例。 容器调度器对每个资源队列中同时运行的application master占用的资源进行了限制，该限制通过yarn.~percent参数实现，其默认值是0.1。表示每个资源队列上application master最多可使用的资源占该队列总资源的10%，目的是防止大部分资源都被application master占用，而导致map/reduce task无法执行。 生产环境该参数可使用默认值。
6.2 数据仓库开发环境
数仓开发工具可选用dbeaver或者datagrip。两者都需要用到jdbc协议连接到hive，故需要启动hiveserver2。 1、启动hiveserver2 2、配置datagrip连接 1）创建连接 2）配置连接属性 所有属性配置，和hive的beeline客户端配置一致即可。初次使用，配置过程会提示缺少jdbc驱动，按照提示下载即可。 3、测试使用 创建数据库gmall，并观察是否创建成功 1）创建数据库 2）查看数据库 3）修改连接，指定连接数据库 4）选择当前数据库为gmall
6.3 模拟数据准备
通常企业在开始搭建数仓时，业务系统中会存在历史数据，一般是业务数据库存在历史数据，而用户行为日志无历史数据。假定数仓上线的日期为2020-06-14，为模拟真实场景，需准备以下数据。 1、用户行为日志 页面浏览记录：用户访问的页面，包括访问时间、停留时间和离开的页面。 点击流数据：用户在应用程序或网站上的点击路径，包括点击的按钮、链接或其他界面元素。 搜索查询：用户在内置搜索引擎中输入的搜索词汇，以及相应的搜索结果。 交易活动：用户完成的购买、订单详情、支付方式和交易金额。 登录日志：用户的登录次数、登录时间、使用的设备和地理位置信息。 内容互动：用户对内容的点赞、评论、分享或收藏行为。 2、业务数据 财务报表：收入、支出、利润、损失和其他财务指标的详细记录。 销售记录：销售额、销售量、客户购买记录和销售趋势分析。 客户信息：客户的基本信息、购买历史、偏好和反馈。 库存数据：产品库存量、补货率、库存周转率和库存成本。 市场分析：市场趋势、竞争对手分析、目标客户群和市场需求研究。 员工信息：员工的个人信息、岗位、绩效评估和薪酬记录。
文章来源
发表评论