离线数仓的核心构建

1，了解什么是数仓？以及数仓的特点是什么？

这两个问题放在一起去聊了，因为一般面我们在理解一个工具出现的时候，本身就是要知道他是什么，特点是什么，以及它有什么用？从而根据工具自身的特点用在一些特殊的场景中。

• 1，什么是数仓？
  • (1)，数据仓库是用于出具报告和数据分析的系统，被认为是商业智能核心组件。
  • (2)，数据仓库是由多个不同的数据源所集成的，将现在和历史的数据存储在一起。
  • (3)，数据仓库在有了大量的数据之后，而它的价值也就会在出具一些分析报告和支持决策中而被体现。
• 2，数仓的特点？
  • 数据仓库之父 Bill Inmon 将数据仓库描述为一个面向主题的、集成的、随时间变化的、非易失的 ==数据集合==，用于支持管理者的决策过程。

2，数仓架构的设计方案

当然这里只是业界的一种解决方案，主要是讲明白基础的架构设计点，即便是有其他的变动也不会太大。

数仓架构的参考设计方案（网图，如侵权请联系我立刻删除）

(1)，数据建模

维度建模

1)，架构设计

一般会有两种常见的架构设计方法，为了方便记忆，就直接用架构01和架构02来表示，一般中小公司或者业务模式没有那么固定的时候，通常都会采用第二种方式进行构建，即从各种指标到各种数据的采集。
架构01：Inmon 自上而下的架构

Inmon适合开发进度慢，对设计科学性和规范性高的企业，在业务模式较为固定的行业引用比较好，比如金融和电信行业。

• ODS层：数据贴源层
• DW层：
  • DWD层：明细数据层
  • DWS层：服务数据层
• App层：数据应用层

架构02：Kimball 自下而上的架构

Kimball模式适合快速迭代，实施成本低，能够快速交付任务。这种模式更适合互联网的高速发展，也适合中下型企业。

• App层：数据应用层，也称之为 数据集市，包含如下几个示例：
  • 报表系统
  • 业务系统
  • 运营系统
• DW层
  • DWD层：明细数据层
  • DWS层：服务数据层
• ODS层：数据贴源层

2)，维度建模的三种模型

维度模型的选择会根据业务常见的简单与否进行选择，同时建立数据仓库在构建的时候就会去冗余存储，故对星型模型会更加友好；而雪花模型会存在很多的join操作，所以对于常见的关系型数据库中存储又会比较合适。

• 星型模型：基于一个事实表，像一颗星星一样四处扩散，并且扩散深度只会有一层；
  • 这里的星星就是业务中的一个“事实”；
    事实：我在2022年7月，取得了北京大学的本科学历。
  • 四处扩散指的多个不同的维度。
  • 以优秀毕业生事实表作为示例：
    • 事实表：含有毕业时间、毕业地点、人员信息。
    • 维度表01-时间维度：年、月、日、季度。
    • 维度表02-地点维度：国家、身份、城市、大学。
    • 维度表03-人员维度：姓名、性别、年龄、国籍。
• 雪花模型：同样也是基于一个事实表，但是其扩散的维度会有多层，即存在维度的递归情况出现。
  • 维度递归：也就意味这会根据其中的一个维度再去拆分，然后再去拆分维度。
  • 以优秀毕业生事实表作为示例：
    • 事实表：含有毕业时间、毕业地点、人员信息。
    • 维度02-地点维度-递归：国家主键、国家名称、国家简称。
    • 维度02-地点维度-递归：省份主键、省份名称、省份简称。
• 星座模型：基于多个事实表进行构建的，维度表是公用的，可是被多个事实表所共享。
  • 主要区别就在于多个不同的事实表。

三范式建模

• 第一范式(1NF)：属性都是原子性的，即数据表中每一列都是一个不可分割额的原子数据项。
• 第二范式(2NF)：实体的属性完全依赖与主键，不能存在以仅依赖主键的一部分属性，即不存在部分依赖。
• 第三范式(3NF)：任何非主键属性不依赖与其他非主属性，也就是不存在传递依赖。

实体建模

在数据系统中，将数据抽象为“实体”、“属性”、“关系”来表示数据关联和事务描述，这种数据的抽象建模通常被称之为实体关系模型。

• 实体：通常为参与到过程中主体，客观存在的。
• 属性：对主体的描述，修饰即为属性。
• 关系：现实的物理事件是依附于实体的。
  • 一对一
  • 一对多
  • 多对多

(2)，数据分层

ODS-贴源层

存放原始数据，直接加载原始全量数据，保持数据的原貌不做处理；一般是保留7天的分区

DW-中间层

主要是的事实表、维表、公共指标汇总表等集合。

• DWD层：数据明细层 结构和粒度与原始数据表保持一致，但是此时会ODS层的数据进行清洗(去除空值、脏数据、超过极限范围的数据，其实就是ETL的过程(数据的抽取、转换、加载))；建设不同业务领域之间的宽表明细。
• DWS层：数据汇总层 以DWD为基础，进行轻度汇总(包含维度退化，join等)，建立更多的宽表，提升公共指标的复用性。

APP-数据展示层

主要是数据的展示层，存放数据产品个性化的指标数据，比如供应于各种报表、多维查询、数据挖掘等等。

(3)，指标建设

指标建设的特点

• 从运营的角度来看：
  • 业务层面要有价值
  • 可衡量业务真是情况
  • 简单可执行
• 从技术层面来看：
  • 容易收集、快速衡量
  • 准确度高
  • 可被多维度分解
  • 单一数据来源

指标建设的目标

为了更好的发现用户的问题，并且去解决。

指标建设的方法

1)，指标的分级

• 一级指标：指的是公司战略层面指标
  用于衡量公司目标达成情况的，通常是 5~8 个指标；这类指事与业务紧密结合的，按照行业标准制定，有可参考的行业指标，且这类指标针对全公司的员工均有指导意义。
• 二级指标：业务策略层面指标
  为了实现一级指标，一企业会指定一些策略，二级指标通常会与这些策略是有一定的关联的。
• 三级指标：业务执行层面指标
  三级指标数通常是指导一线人员开展工作的指标内容。

2)，OSM模型

• OSM模型简介：

  • O：业务目标(Objective)
    用户使用产品的目标是什么？
    产品满足了用户的什么需求？
  • S：业务策略(Strategy)
    为了达成上述目标我们采取的策略是什么？
  • M: 业务测量(Measurement)
    这些策略随之带来的数据指标变化有哪些？
    • 过程目标：
      用户在做某个动作的时候所产生的目标，可定义通过某些运行策略来影响这个过程指标，从而影响最终的结果。
    • 结果指标：
      用户衡量用户在发生某个动作之后所产生的结果，通常是延后知道的，很难进行干预。
      过程指标与结果指标简单理解：
    • 结果性指标：更多的是监控数据异常，或者是监控某个场景下的用户需求是否被满足；
    • 过程性指标：则更加关注用户的需求为什么被满足。

• 使用OSM模型建议
  通常我们在制定指标的过程中使用OSM模型，去针对不同场景下产生的动作，以及动作可能带来的结果，用户在这个动作中会出现什么样的数据变化。之后在结合这个数据，针对性去调整我们的运营侧路或者是产品功能。

数仓指标建设.xmind

详细的思维导图待公布~

• 什么是指标体系？
• 为什要建立指标体系？
• 如何搭建指标体系？
• 怎么管理指标体系？
• 指标体系的产品化？

(4)，指标分类的案例

1)，游戏数仓为例

• 基础指标：指表达业务实体原子量化属性的且不可再分的概念集合，如交易笔数、交易金额、交易用户数等。
• 复合指标：指建立在基础指标之上，通过一定运算规则形成的计算指标集合，如平均用户交易额、资产负债率、用户复购率、用户流失率等。
• 派生指标：指基础指标或复合指标与维度成员、统计属性、管理属性等相结合产生的指标，如交易金额的完成值、计划值，累计值、同比、环比、占比等。
• 标准信息：经过标准化处理的实体非量化属性信息，或分段统计信息，省份（北京、广州等）、缴费方式（缴费、充值）渠道（网厅、直充、专区）、消费金额（30元、50元、100元等）。

2)，数字人才云数仓为例

• 基础指标：毕业生的类型、毕业生的年龄等。
• 复合指标：不同类型毕业生的占比，不同省份毕业生流失率。
• 派生指标：累计吸引人才的的同比值、环比值。
• 标准信息：省份、毕业年限。

3)，用户画像示例

• 标签分类：
  • 1，社会属性
    • 年龄
    • 性别
    • 地域
    • 学历
    • 职业
    • 婚姻状况
    • 住房车辆
  • 2，生活习惯
    • 休闲
    • 运动
    • 旅游
    • 饮食起居
    • 购物
    • 游戏
    • 体育
    • 文化
  • 3，消费习惯
    • 消费金额
    • 消费次数
    • 消费时间
    • 消费频次
• 构建用户画像：
  • 1，数据收集
    • 网络行为
      • 登录情况
      • 页面浏览访问
      • 在页面停留时长
      • 社交行为
    • 服务行为
      • 网站内停留时间
      • 访问深度
      • 单个页面的浏览次数等
    • 内容偏好
      • 收藏的内容
      • 喜欢的互动内容
      • 生活状态
      • 喜欢的品牌
    • 交易行为
  • 2，给用户打标签
    • 静态属性，比如：人口基本属性
    • 基础属性
    • 动态属性
    • 行为属性
  • 3，构建画像：其实就是进行数据建模，再就是给标签加上权重；现在比较通用的是 4W（Who-谁， When-什么时候，Where-在哪里，What-做了什么）
    • 定义用户
    • 时间跨度
    • 定义来源
    • 行为结果

(5)，元数据管理

1)，定义

元数据，主要是记录数据仓库中模型的定义、各层级之间的映射关系、监控数据仓库的数据状态以及 ETL人的任务运行状态。

2)，元数据类型：

• 技术元数据
• 业务元数据
• 管理过程元数据

3)，元数据功能

• 血缘分析
• 影响分析
• 同步检查
• 指标一致性分析
• 实体关联查询

4)，元数据应用

• ETL自动化管理
• 数据质量管理
• 数据安全管理
• 数据标标准管理
• 数据接口管理
• 项目文档管理
• 数据语义管理

5)如何实现元数据管理

• 可以自研系统管理元数据；
• 或者使用第三方的 BI系统管理；
• 或者使用开源工具Atlas；

(6)，数仓的缓慢变化维

缓慢变化维就是数仓维度表中，那些随时间变化比较不明显，但是仍然会发生变化的维度。

1)，案例

• 案例01：在员工维度表中，某员工原来在北京分公司工作，后来调往上海分公司，那么“工作地点”就是一个缓慢变化维度；
• 案例02：在采购维度表中，办公电脑原来从戴尔供应商处进货，后来换成了联想，那么“供应商”就是一个缓慢变化维度；

2)，解决方案

核心的解决方案是，保留事实的历史环境，并插入新的维度行，可以使用“拉链表”。

什么是拉链表？

• 所谓拉链表，就是记录历史；记录一个事物从开始，一直到当前状态的所有变化的信息。
• 在数据分析中，有时需要维护一些历史状态，比如订单状态变化、评分变化，为了保存这些状态变化的路径，可以通过拉链边实现。

拉链表的使用场景？

主要是解决数仓中一些缓慢变化维的数据，需要保存历史各个版本。

• 数据量比较大，但业务要求每次需要查询全量历史，每次存储一份全量数据太占存储空间。
• 记录变更不大，比如只有状态和更新时间有变动，其他字段都不变。

拉链表的实现过程？

• 1，通过在记录末尾增加 start_date 和 end_date 字段来实现。
• 2，当同一ID按时间排序之后，如果有较新的记录，则当前记录的 end_date 等于"较新记录的 start_date - 1"；如果没有较新的记录，则当前记录的 end_date 等于一个默认值，比如 9999-12-31。

拉链表案例（网图，如侵权请联系我立刻删除）

图片说明：

• t_start_date：表示当前条记录的生命周期的开始；
• t_end_date：表示该条记录的生命周期的结束；
  t_end_date = "9999-12-31" 表示该条记录目前处于有效状态。
• 如果当前查询所有有效的记录，则使用：
  select * from user where t_end_date = '9999-12-31'
• 如果查询 2017-01-02 的历史快照，则使用：
  select * from user where t_start_date <= '2017-01-02' and t_end_date >= '2017-01-02'