1. 数据仓库概述

1.1 数据仓库概念

数据仓库是一个为数据分析而设计的企业级数据管理系统。数据仓库可集中、整合多个信息源的大量数据，借助数据仓库的分析能力，企业可从数据中获得宝贵的信息进而改进决策。同时，随着时间的推移，数据仓库中积累的大量历史数据对于数据科学家和业务分析师也是十分宝贵的。

1.2 数据仓库核心架构

2. 数据仓库建模概述

2.1 数据仓库建模的意义

• 如果把数据看作图书馆里的书，我们希望看到它们在书架上分门别类地放置；如果把数据看作城市的建筑，我们希望城市规划布局合理；如果把数据看作电脑文件和文件夹，我们希望按照自己的习惯有很好的文件夹组织方式，而不是糟糕混乱的桌面，经常为找一个文件而不知所措。
• 数据模型就是数据组织和存储方法，它强调从业务、数据存取和使用角度合理存储数据。只有将数据有序的组织和存储起来之后，数据才能得到高性能、低成本、高效率、高质量的使用。
  • 高性能：良好的数据模型能够帮助我们快速查询所需要的数据。
  • 低成本：良好的数据模型能减少重复计算，实现计算结果的复用，降低计算成本。
  • 高效率：良好的数据模型能极大的改善用户使用数据的体验，提高使用数据的效率。
  • 高质量：良好的数据模型能改善数据统计口径的混乱，减少计算错误的可能性。

2.2 数据仓库建模方法论

ER模型

• 数据仓库之父Bill Inmon提出的建模方法是从全企业的高度，用实体关系（Entity Relationship，ER）模型来描述企业业务，并用规范化的方式表示出来，在范式理论上符合3NF。
• 实体关系模型
  实体关系模型将复杂的数据抽象为两个概念——实体和关系。实体表示一个对象，例如学生、班级，关系是指两个实体之间的关系，例如学生和班级之间的从属关系。
• 数据库规范化
  • 数据库规范化是使用一系列范式设计数据库（通常是关系型数据库）的过程，其目的是减少数据冗余，增强数据的一致性。
  • 这一系列范式就是指在设计关系型数据库时，需要遵从的不同的规范。关系型数据库的范式一共有六种，分别是第一范式（1NF）、第二范式（2NF）、第三范式（3NF）、巴斯-科德范式（BCNF）、第四范式(4NF）和第五范式（5NF）。遵循的范式级别越高，数据冗余性就越低。
• 三范式
  
  
  
  

下图为一个采用Bill Inmon倡导的建模方法构建的模型，从图中可以看出，较为松散、零碎，物理表数量多。

这种建模方法的出发点是整合数据，其目的是将整个企业的数据进行组合和合并，并进行规范处理，减少数据冗余性，保证数据的一致性。这种模型并不适合直接用于分析统计。

维度模型

• 数据仓库领域的令一位大师——Ralph Kimball倡导的建模方法为维度建模。维度模型将复杂的业务通过事实和维度两个概念进行呈现。事实通常对应业务过程，而维度通常对应业务过程发生时所处的环境。
• 注：业务过程可以概括为一个个不可拆分的行为事件，例如电商交易中的下单，取消订单，付款，退单等，都是业务过程。
• 下图为一个典型的维度模型，其中位于中心的SalesOrder为事实表，其中保存的是下单这个业务过程的所有记录。位于周围每张表都是维度表，包括Date（日期），Customer（顾客），Product（产品），Location（地区）等，这些维度表就组成了每个订单发生时所处的环境，即何人、何时、在何地下单了何种产品。从图中可以看出，模型相对清晰、简洁。
  
  维度建模以数据分析作为出发点，为数据分析服务，因此它关注的重点的用户如何更快的完成需求分析以及如何实现较好的大规模复杂查询的响应性能。

3. 维度建模理论之事实表

3.1 事实表概述

事实表作为数据仓库维度建模的核心，紧紧围绕着业务过程来设计。其包含与该业务过程有关的维度引用（维度表外键）以及该业务过程的度量（通常是可累加的数字类型字段）。

事实表特点

事实表通常比较“细长”，即列较少，但行较多，且行的增速快。

事实表分类

事实表有三种类型：分别是事务事实表、周期快照事实表和累积快照事实表，每种事实表都具有不同的特点和适用场景，下面逐个介绍。

3.2 事务型事实表

概述

• 事务事实表用来记录各业务过程，它保存的是各业务过程的原子操作事件，即最细粒度的操作事件。粒度是指事实表中一行数据所表达的业务细节程度。
• 事务型事实表可用于分析与各业务过程相关的各项统计指标，由于其保存了最细粒度的记录，可以提供最大限度的灵活性，可以支持无法预期的各种细节层次的统计需求。

设计流程

设计事务事实表时一般可遵循以下四个步骤：
== 选择业务过程→声明粒度→确认维度→确认事实==

• 选择业务过程
  在业务系统中，挑选我们感兴趣的业务过程，业务过程可以概括为一个个不可拆分的行为事件，例如电商交易中的下单，取消订单，付款，退单等，都是业务过程。通常情况下，一个业务过程对应一张事务型事实表。

• 声明粒度

  • 业务过程确定后，需要为每个业务过程声明粒度。即精确定义每张事务型事实表的每行数据表示什么，应该尽可能选择最细粒度，以此来应各种细节程度的需求。
  • 典型的粒度声明如下：
  • 订单事实表中一行数据表示的是一个订单中的一个商品项。

• 确定维度

  • 确定维度具体是指，确定与每张事务型事实表相关的维度有哪些。
  • 确定维度时应尽量多的选择与业务过程相关的环境信息。因为维度的丰富程度就决定了维度模型能够支持的指标丰富程度。

• 确定事实

  • 此处的“事实”一词，指的是每个业务过程的度量值（通常是可累加的数字类型的值，例如：次数、个数、件数、金额等）。
  • 经过上述四个步骤，事务型事实表就基本设计完成了。第一步选择业务过程可以确定有哪些事务型事实表，第二步可以确定每张事务型事实表的每行数据是什么，第三步可以确定每张事务型事实表的维度外键，第四步可以确定每张事务型事实表的度量值字段。

不足

• 事务型事实表可以保存所有业务过程的最细粒度的操作事件，故理论上其可以支撑与各业务过程相关的各种统计粒度的需求。但对于某些特定类型的需求，其逻辑可能会比较复杂，或者效率会比较低下。例如：
  • 存量型指标
    • 例如商品库存，账户余额等。此处以电商中的虚拟货币为例，虚拟货币业务包含的业务过程主要包括获取货币和使用货币，两个业务过程各自对应一张事务型事实表，一张存储所有的获取货币的原子操作事件，另一张存储所有使用货币的原子操作事件。
    • 假定现有一个需求，要求统计截至当日的各用户虚拟货币余额。由于获取货币和使用货币均会影响到余额，故需要对两张事务型事实表进行聚合，且需要区分两者对余额的影响（加或减），另外需要对两张表的全表数据聚合才能得到统计结果。
    • 可以看到，不论是从逻辑上还是效率上考虑，这都不是一个好的方案。
  • 多事务关联统计
    • 例如，现需要统计最近30天，用户下单到支付的时间间隔的平均值。统计思路应该是找到下单事务事实表和支付事务事实表，过滤出最近30天的记录，然后按照订单id对两张事实表进行关联，之后用支付时间减去下单时间，然后再求平均值。
    • 逻辑上虽然并不复杂，但是其效率较低，应为下单事务事实表和支付事务事实表均为大表，大表join大表的操作应尽量避免。
    • 可以看到，在上述两种场景下事务型事实表的表现并不理想。下面要介绍的另外两种类型的事实表就是为了弥补事务型事实表的不足的。

3.3 周期型快照事实表

概述

• 周期快照事实表以具有规律性的、可预见的时间间隔来记录事实，主要用于分析一些存量型（例如商品库存，账户余额）或者状态型（空气温度，行驶速度）指标。
• 对于商品库存、账户余额这些存量型指标，业务系统中通常就会计算并保存最新结果，所以定期同步一份全量数据到数据仓库，构建周期型快照事实表，就能轻松应对此类统计需求，而无需再对事务型事实表中大量的历史记录进行聚合了。
• 对于空气温度、行驶速度这些状态型指标，由于它们的值往往是连续的，我们无法捕获其变动的原子事务操作，所以无法使用事务型事实表统计此类需求。而只能定期对其进行采样，构建周期型快照事实表。

设计流程

• 确定粒度
  • 周期型快照事实表的粒度可由采样周期和维度描述，故确定采样周期和维度后即可确定粒度。
  • 采样周期通常选择每日。
  • 维度可根据统计指标决定，例如指标为统计每个仓库中每种商品的库存，则可确定维度为仓库和商品。
  • 确定完采样周期和维度后，即可确定该表粒度为每日-仓库-商品。
• 确认事实
  事实也可根据统计指标决定，例如指标为统计每个仓库中每种商品的库存，则事实为商品库存。

事实类型

此处的事实类型是指度量值的类型，而非事实表的类型。事实（度量值）共分为三类，分别是可加事实，半可加事实和不可加事实。

• 可加事实
  可加事实是指可以按照与事实表相关的所有维度进行累加，例如事务型事实表中的事实。
• 半可加事实
  半可加事实是指只能按照与事实表相关的一部分维度进行累加，例如周期型快照事实表中的事实。以上述各仓库中各商品的库存每天快照事实表为例，这张表中的库存事实可以按照仓库或者商品维度进行累加，但是不能按照时间维度进行累加，因为将每天的库存累加起来是没有任何意义的。
• 不可加事实
  不可加事实是指完全不具备可加性，例如比率型事实。不可加事实通常需要转化为可加事实，例如比率可转化为分子和分母。

3.4 累积型快照事实表

• 累计快照事实表是基于一个业务流程中的多个关键业务过程联合处理而构建的事实表，如交易流程中的下单、支付、发货、确认收货业务过程。
• 累积型快照事实表通常具有多个日期字段，每个日期对应业务流程中的一个关键业务过程（里程碑）。
  
• 累积型快照事实表主要用于分析业务过程（里程碑）之间的时间间隔等需求。例如前文提到的用户下单到支付的平均时间间隔，使用累积型快照事实表进行统计，就能避免两个事务事实表的关联操作，从而变得十分简单高效。

设计流程

累积型快照事实表的设计流程同事务型事实表类似，也可采用以下四个步骤，下面重点描述与事务型事实表的不同之处。
选择业务过程→声明粒度→确认维度→确认事实。

• 选择业务过程
  选择一个业务流程中需要关联分析的多个关键业务过程，多个业务过程对应一张累积型快照事实表。
• 声明粒度
  精确定义每行数据表示的是什么，尽量选择最小粒度。
• 确认维度
  选择与各业务过程相关的维度，需要注意的是，每各业务过程均需要一个日期维度。
• 确认事实
  选择各业务过程的度量值。

4. 维度建模理论之维度表

4.1 维度表概述

维度表是维度建模的基础和灵魂。前文提到，事实表紧紧围绕业务过程进行设计，而维度表则围绕业务过程所处的环境进行设计。维度表主要包含一个主键和各种维度字段，维度字段称为维度属性。

4.2 维度表设计步骤

• 确定维度（表）
  在设计事实表时，已经确定了与每个事实表相关的维度，理论上每个相关维度均需对应一张维度表。需要注意到，可能存在多个事实表与同一个维度都相关的情况，这种情况需保证维度的唯一性，即只创建一张维度表。另外，如果某些维度表的维度属性很少，例如只有一个**名称，则可不创建该维度表，而把该表的维度属性直接增加到与之相关的事实表中，这个操作称为维度退化。
• 确定主维表和相关维表
  此处的主维表和相关维表均指业务系统中与某维度相关的表。例如业务系统中与商品相关的表有sku_info，spu_info，base_trademark，base_category3，base_category2，base_category1等，其中sku_info就称为商品维度的主维表，其余表称为商品维度的相关维表。维度表的粒度通常与主维表相同。
• 确定维度属性
  确定维度属性即确定维度表字段。维度属性主要来自于业务系统中与该维度对应的主维表和相关维表。维度属性可直接从主维表或相关维表中选择，也可通过进一步加工得到。
  确定维度属性时，需要遵循以下要求：
  • 尽可能生成丰富的维度属性
    维度属性是后续做分析统计时的查询约束条件、分组字段的基本来源，是数据易用性的关键。维度属性的丰富程度直接影响到数据模型能够支持的指标的丰富程度。
  • 尽量不使用编码，而使用明确的文字说明，一般可以编码和文字共存。
  • 尽量沉淀出通用的维度属性
• 有些维度属性的获取需要进行比较复杂的逻辑处理，例如需要通过多个字段拼接得到。为避免后续每次使用时的重复处理，可将这些维度属性沉淀到维度表中。

4.3 维度设计要点

规范化与反规范化

• 规范化是指使用一系列范式设计数据库的过程，其目的是减少数据冗余，增强数据的一致性。通常情况下，规范化之后，一张表的字段会拆分到多张表。
• 反规范化是指将多张表的数据冗余到一张表，其目的是减少join操作，提高查询性能。在设计维度表时，如果对其进行规范化，得到的维度模型称为雪花模型，如果对其进行反规范化，得到的模型称为星型模型。
  
  数据仓库系统的主要目的是用于数据分析和统计，所以是否方便用户进行统计分析决定了模型的优劣。采用雪花模型，用户在统计分析的过程中需要大量的关联操作，使用复杂度高，同时查询性能很差，而采用星型模型，则方便、易用且性能好。所以出于易用性和性能的考虑，维度表一般是很不规范化的。

维度变化

• 维度属性通常不是静态的，而是会随时间变化的，数据仓库的一个重要特点就是反映历史的变化，所以如何保存维度的历史状态是维度设计的重要工作之一。保存维度数据的历史状态，通常有以下两种做法，分别是全量快照表和拉链表。
• 全量快照表
  • 离线数据仓库的计算周期通常为每天一次，所以可以每天保存一份全量的维度数据。这种方式的优点和缺点都很明显。
  • 优点是简单而有效，开发和维护成本低，且方便理解和使用。
  • 缺点是浪费存储空间，尤其是当数据的变化比例比较低时。
• 拉链表
  拉链表的意义就在于能够更加高效的保存维度信息的历史状态。

  • 什么是拉链表
    

  • 为什么要做拉链表
    

  • 如何使用拉链表
    

多值维度

• 如果事实表中一条记录在某个维度表中有多条记录与之对应，称为多值维度。例如，下单事实表中的一条记录为一个订单，一个订单可能包含多个商品，所会商品维度表中就可能有多条数据与之对应。
• 针对这种情况，通常采用以下两种方案解决。
  • 第一种：降低事实表的粒度，例如将订单事实表的粒度由一个订单降低为一个订单中的一个商品项。
  • 第二种：在事实表中采用多字段保存多个维度值，每个字段保存一个维度id。这种方案只适用于多值维度个数固定的情况。
• 建议尽量采用第一种方案解决多值维度问题。

多值属性

• 维表中的某个属性同时有多个值，称之为“多值属性”，例如商品维度的平台属性和销售属性，每个商品均有多个属性值。
• 针对这种情况，通常有可以采用以下两种方案。
  • 第一种：将多值属性放到一个字段，该字段内容为key1:value1，key2:value2的形式，例如一个手机商品的平台属性值为“品牌:华为，系统:鸿蒙，CPU:麒麟990”。
  • 第二种：将多值属性放到多个字段，每个字段对应一个属性。这种方案只适用于多值属性个数固定的情况。

5. 数据仓库设计

5.1 数据仓库分层规划

优秀可靠的数仓体系，需要良好的数据分层结构。合理的分层，能够使数据体系更加清晰，使复杂问题得以简化。以下是该项目的分层规划。

5.2 数据仓库构建流程

以下是构建数据仓库的完整流程。

数据调研

数据调研重点要做两项工作，分别是业务调研和需求分析。这两项工作做的是否充分，直接影响着数据仓库的质量。

• 业务调研

  • 业务调研的主要目标是熟悉业务流程、熟悉业务数据。
  • 熟悉业务流程要求做到，明确每个业务的具体流程，需要将该业务所包含的每个业务过程一一列举出来。
  • 熟悉业务数据要求做到，将数据（包括埋点日志和业务数据表）与业务过程对应起来，明确每个业务过程会对哪些表的数据产生影响，以及产生什么影响。产生的影响，需要具体到，是新增一条数据，还是修改一条数据，并且需要明确新增的内容或者是修改的逻辑。
  • 下面业务电商中的交易为例进行演示，交易业务涉及到的业务过程有买家下单、买家支付、卖家发货，买家收货，具体流程如下图。
    

• 需求分析

  • 典型的需求指标如，最近一天各省份手机品类订单总额。
  • 分析需求时，需要明确需求所需的业务过程及维度，例如该需求所需的业务过程就是买家下单，所需的维度有日期，省份，商品品类。

• 总结
  做完业务分析和需求分析之后，要保证每个需求都能找到与之对应的业务过程及维度。若现有数据无法满足需求，则需要和业务方进行沟通，例如某个页面需要新增某个行为的埋点。

明确数据域

• 数据仓库模型设计除横向的分层外，通常也需要根据业务情况进行纵向划分数据域。划分数据域的意义是便于数据的管理和应用。
• 通常可以根据业务过程或者部门进行划分，本项目根据业务过程进行划分，需要注意的是一个业务过程只能属于一个数据域。
• 下面是本数仓项目所需的所有业务过程及数据域划分详情。
  

构建业务总线矩阵

• 业务总线矩阵中包含维度模型所需的所有事实（业务过程）以及维度，以及各业务过程与各维度的关系。矩阵的行是一个个业务过程，矩阵的列是一个个的维度，行列的交点表示业务过程与维度的关系。
  
• 一个业务过程对应维度模型中一张事务型事实表，一个维度则对应维度模型中的一张维度表。所以构建业务总线矩阵的过程就是设计维度模型的过程。但是需要注意的是，总线矩阵中通常只包含事务型事实表，另外两种类型的事实表需单独设计。
• 按照事务型事实表的设计流程，选择业务过程 -> 声明粒度 -> 确认维度 ->确认事实，得到的最终的业务总线矩阵见以下表格。
• 后续的DWD层以及DIM层的搭建需参考业务总线矩阵。

明确统计指标

明确统计指标具体的工作是，深入分析需求，构建指标体系。构建指标体系的主要意义就是指标定义标准化。所有指标的定义，都必须遵循同一套标准，这样能有效的避免指标定义存在歧义，指标定义重复等问题。

• 指标体系相关概念

  • 原子指标

    • 原子指标基于某一业务过程的度量值，是业务定义中不可再拆解的指标，原子指标的核心功能就是对指标的聚合逻辑进行了定义。我们可以得出结论，原子指标包含三要素，分别是业务过程、度量值和聚合逻辑。
    • 例如订单总额就是一个典型的原子指标，其中的业务过程为用户下单、度量值为订单金额，聚合逻辑为sum()求和。需要注意的是原子指标只是用来辅助定义指标一个概念，通常不会对应有实际统计需求与之对应。

  • 派生指标

    • 派生指标基于原子指标，其与原子指标的关系如下图所示。
      
    • 与原子指标不同，派生指标通常会对应实际的统计需求。请从图中的例子中，体会指标定义标准化的含义。

  • 衍生指标

    • 衍生指标是在一个或多个派生指标的基础上，通过各种逻辑运算复合而成的。例如比率、比例等类型的指标。衍生指标也会对应实际的统计需求。
      
• 指标体系对于数仓建模的意义
  • 通过上述两个具体的案例可以看出，绝大多数的统计需求，都可以使用原子指标、派生指标以及衍生指标这套标准去定义。同时能够发现这些统计需求都直接的或间接的对应一个或者是多个派生指标。
  • 当统计需求足够多时，必然会出现部分统计需求对应的派生指标相同的情况。这种情况下，我们就可以考虑将这些公共的派生指标保存下来，这样做的主要目的就是减少重复计算，提高数据的复用性。
  • 这些公共的派生指标统一保存在数据仓库的DWS层。因此DWS层设计，就可以参考我们根据现有的统计需求整理出的派生指标。

维度模型设计

维度模型的设计参照上述得到的业务总线矩阵即可。事实表存储在DWD层，维度表存储在DIM层。

汇总模型设计

汇总模型的设计参考上述整理出的指标体系（主要是派生指标）即可。汇总表与派生指标的对应关系是，一张汇总表通常包含业务过程相同、统计周期相同、统计粒度相同的多个派生指标。请思考：汇总表与事实表的对应关系是？

6. 数据仓库环境准备

6.1 数据仓库运行环境

Hive环境搭建

Hive引擎简介

• Hive引擎包括：默认MR、tez、spark
• Hive on Spark：Hive既作为存储元数据又负责SQL的解析优化，语法是HQL语法，执行引擎变成了Spark，Spark负责采用RDD执行。
• Spark on Hive : Hive只作为存储元数据，Spark负责SQL解析优化，语法是Spark SQL语法，Spark负责采用RDD执行。

Hive on Spark配置

• 兼容性说明
  • 注意：官网下载的Hive3.1.2和Spark3.0.0默认是不兼容的。因为Hive3.1.2支持的Spark版本是2.4.5，所以需要我们重新编译Hive3.1.2版本。
  • 编译步骤：官网下载Hive3.1.2源码，修改pom文件中引用的Spark版本为3.0.0，如果编译通过，直接打包获取jar包。如果报错，就根据提示，修改相关方法，直到不报错，打包获取jar包。
• 在Hive所在节点部署Spark
  • 如果之前已经部署了Spark，则该步骤可以跳过
  • Spark官网下载jar包地址：
    http://spark.apache.org/downloads.html
  • 上传并解压解压spark-3.0.0-bin-hadoop3.2.tgz

[atguigu@hadoop102 software]$ tar -zxvf spark-3.0.0-bin-hadoop3.2.tgz -C /opt/module/
[atguigu@hadoop102 software]$ mv /opt/module/spark-3.0.0-bin-hadoop3.2 /opt/module/spark

• 配置SPARK_HOME环境变量
• 在hive中创建spark配置文件
• 向HDFS上传Spark纯净版jar包
• 修改hive-site.xml文件

Hive on Spark测试

Yarn环境配置

增加ApplicationMaster资源比例

6.2 数据仓库开发环境

数仓开发工具可选用DBeaver或者DataGrip。两者都需要用到JDBC协议连接到Hive，故需要启动HiveServer2。

6.3 模拟数据准备

7. 数仓开发之ODS层

ODS层的设计要点如下：
1）ODS层的表结构设计依托于从业务系统同步过来的数据结构。
2）ODS层要保存全部历史数据，故其压缩格式应选择压缩比较高的，此处选择gzip。
3）ODS层表名的命名规范为：ods_表名_单分区增量全量标识（inc/full）。

7.1 日志表

7.2 业务表

8. 数仓开发之DIM层

DIM层设计要点：
1）DIM层的设计依据是维度建模理论，该层存储维度模型的维度表。
2）DIM层的数据存储格式为orc列式存储+snappy压缩。
3）DIM层表名的命名规范为dim_表名_全量表或者拉链表标识（full/zip）

8.1 商品维度表

8.2 优惠券维度表

8.3 活动维度表

8.4 地区维度表

8.5 日期维度表

8.6 用户维度表

8.7 数据装载脚本

9. 数仓开发之DWD层

DWD层设计要点：
1）DWD层的设计依据是维度建模理论，该层存储维度模型的事实表。
2）DWD层的数据存储格式为orc列式存储+snappy压缩。
3）DWD层表名的命名规范为dwd_数据域_表名_单分区增量全量标识（inc/full）

9.1 交易域加购事务事实表

9.2 交易域下单事务事实表

9.3 交易域取消订单事务事实表

9.4 交易域支付成功事务事实表

9.5 交易域退单事务事实表

9.6 交易域退款成功事务事实表

9.7 交易域购物车周期快照事实表

9.8 工具域优惠券领取事务事实表

9.9 工具域优惠券使用(下单)事务事实表

9.10 工具域优惠券使用(支付)事务事实表

9.11 互动域收藏商品事务事实表

9.12 互动域评价事务事实表

9.13 流量域页面浏览事务事实表

9.14 流量域启动事务事实表

9.15 流量域动作事务事实表

9.16 流量域曝光事务事实表

9.17 流量域错误事务事实表

9.18 用户域用户注册事务事实表

9.19 用户域用户登录事务事实表

9.20 数据装载脚本

10. 数仓开发之DWS层

设计要点：
1）DWS层的设计参考指标体系。
2）DWS层的数据存储格式为orc列式存储+snappy压缩。
3）DWS层表名的命名规范为dws_数据域_统计粒度_业务过程_统计周期（1d/nd/td）
注：1d表示最近1日，nd表示最近n日，td表示历史至今。

10.1 最近1日汇总表

10.2 最近n日汇总表

10.3 历史至今汇总表

11. 数仓开发之ADS层

11.1 流量主题

各渠道流量统计

需求说明如下

路径分析

• 用户路径分析，顾名思义，就是指用户在APP或网站中的访问路径。为了衡量网站优化的效果或营销推广的效果，以及了解用户行为偏好，时常要对访问路径进行分析。
• 用户访问路径的可视化通常使用桑基图。如下图所示，该图可真实还原用户的访问路径，包括页面跳转和页面访问次序。
• 桑基图需要我们提供每种页面跳转的次数，每个跳转由source/target表示，source指跳转起始页面，target表示跳转终到页面。
  

11.2 用户主题

用户变动统计

该需求包括两个指标，分别为流失用户数和回流用户数，以下为对两个指标的解释说明。

用户留存率

• 留存分析一般包含新增留存和活跃留存分析。
• 新增留存分析是分析某天的新增用户中，有多少人有后续的活跃行为。活跃留存分析是分析某天的活跃用户中，有多少人有后续的活跃行为。
• 留存分析是衡量产品对用户价值高低的重要指标。
• 此处要求统计新增留存率，新增留存率具体是指留存用户数与新增用户数的比值，例如2020-06-14新增100个用户，1日之后（2020-06-15）这100人中有80个人活跃了，那2020-06-14的1日留存数则为80，2020-06-14的1日留存率则为80%。

要求统计每天的1至7日留存率，如下图所示。

11.3 商品主题

11.4 交易主题

11.5 优惠券主题

11.6 活动主题

11.7 数据装载脚本

12. 报表数据导出

12.1 MySQL建库建表

12.2 数据导出

13. 数据仓库工作流调度

13.1 调度工具部署

13.2 新数据生成

13.3 工作流调度实操