一、相关技术

1、技术选型

2、系统数据流程设计

二、数仓分层

1、数据仓库分层

2、范式理论

  • 第一范式:属性不可分割性。
  • 第二范式:不能存在“部分函数依赖”
  • 第三范式:不能存在传递函数依赖。

3、关系建模和维度建模

  • 联机事务处理OLTP(on-line transaction processing)

    OLTP是传统的关系型数据库的主要应用,主要是基本的、日常的事务处理,例如银行交易。

  • 联机分析处理OLAP(On-Line Analytical Processing)

    OLAP是数据仓库系统的主要应用,支持复杂的分析操作,侧重决策支持,并且提供直观易懂的查询结果。

    二者对比

    对比属性 OLTP OLAP
    读特性 每次查询只返回少量记录 对大量记录进行汇总
    写特性 随机、低延时写入用户的输入 批量导入
    使用场景 用户,Java EE项目 内部分析师,为决策提供支持
    数据表征 最新数据状态 随时间变化的历史状态
    数据规模 GB TB到PB
3.1 关系建模

关系模型如图所示,严格遵循第三范式(3NF),从图中可以看出,较为松散、零碎,物理表数量多,而数据冗余程度低。由于数据分布于众多的表中,这些数据可以更为灵活地被应用,功能性较强。关系模型主要应用与OLTP系统中,为了保证数据的一致性以及避免冗余,所以大部分业务系统的表都是遵循第三范式的。

3.2维度建模

维度模型如图所示,主要应用于OLAP系统中,通常以某一个事实表为中心进行表的组织,主要面向业务,特征是可能存在数据的冗余,但是能方便的得到数据。

关系模型虽然冗余少,但是在大规模数据,跨表分析统计查询过程中,会造成多表关联,这会大大降低执行效率。所以通常我们采用维度模型建模,把相关各种表整理成两种:事实表和维度表两种。

4、维度表和事实表

4.1维度表

维度表:一般是对事实的描述信息。每一张维表对应现实世界中的一个对象或者概念。 例如:用户、商品、日期、地区等。

  • 维表的范围很宽(具有多个属性、列比较多)
  • 跟事实表相比,行数相对较小:通常< 10万条
  • 内容相对固定:编码表
4.2事实表

事实表中每行数据代表一个业务事件(下单、支付、退款、评价等)。“事实”这个术语表示的是业务事件的度量值(可统计次数、个数、金额等)

  • 非常的大
  • 内容相对的窄:列数较少(主要是外键id和度量值)
  • 经常发生变化,每天会新增加很多。

1)事务型事实表

每个事务或事件为单位,例如一个销售订单记录,一笔支付记录等,作为事实表里的一行数据。一旦事务被提交,事实表数据被插入,数据就不再进行更改,其更新方式为增量更新。

2)周期型快照事实表

周期型快照事实表中不会保留所有数据,只保留固定时间间隔的数据,例如每天或者每月的销售额,或每月的账户余额等。

例如购物车,有加减商品,随时都有可能变化,但是我们更关心每天结束时这里面有多少商品,方便我们后期统计分析。

3)累积型快照事实表

累计快照事实表用于跟踪业务事实的变化。例如,数据仓库中可能需要累积或者存储订单从下订单开始,到订单商品被打包、运输、和签收的各个业务阶段的时间点数据来跟踪订单声明周期的进展情况。当这个业务过程进行时,事实表的记录也要不断更新。

5、维度模型分类

5.1、星型模型

雪花模型与星型模型的区别主要在于维度的层级,标准的星型模型维度只有一层,而雪花模型可能会涉及多级

5.2、雪花模型

5.3、星座模型

星座模型与前两种情况的区别是事实表的数量,星座模型是基于多个事实表的。

6、数据仓库建模

6.1、ODS层
  • 用户行为数据
  • 业务数据
6.2、DWD层

DWD层需要构建维度模型,一般采用星型模型。见上面图

维度建模一般按照以下四个步骤:

选择业务过程→声明粒度→确认维度→确认事实

(1)选择业务过程

在业务系统中,挑选我们感兴趣的业务线,比如下单业务,支付业务,退款业务,物流业务,一条业务线对应一张事实表。

如果是中小公司,尽量把所有业务过程都选择。

如果是大公司(1000多张表),选择和需求相关的业务线。

(2)声明粒度

数据粒度指数据仓库的数据中保存数据的细化程度或综合程度的级别。

声明粒度意味着精确定义事实表中的一行数据表示什么,应该尽可能选择最小粒度,以此来应各种各样的需求。

典型的粒度声明如下:

订单事实表中一行数据表示的是一个订单中的一个商品项。

支付事实表中一行数据表示的是一个支付记录。

(3)确定维度

维度的主要作用是描述业务是事实,主要表示的是“谁,何处,何时”等信息。

确定维度的原则是:后续需求中是否要分析相关维度的指标。例如,需要统计,什么时间下的订单多,哪个地区下的订单多,哪个用户下的订单多。需要确定的维度就包括:时间维度、地区维度、用户维度。

(4)确定事实

此处的“事实”一词,指的是业务中的度量值(次数、个数、件数、金额,可以进行累加),例如订单金额、下单次数等。

在DWD层,以业务过程为建模驱动,基于每个具体业务过程的特点,构建最细粒度的明细层事实表。事实表可做适当的宽表化处理。

6.3 DWS和DWT层

DWS和DWT层的区别:DWS层存放的所有主题对象当天的汇总行为,例如每个地区当天的下单次数,下单金额等,DWT层存放的是所有主题对象的累积行为,例如每个地区最近7天(15天、30天、60天)的下单次数、下单金额等。

6.4 ADS层

三、流批一体架构

1、传统数仓架构(Lambda)

传统的Lambda架构分为:

  • 业务层
  • 存储层
  • 计算层
  • 服务层
  • 应用层

传统的架构很灵活,流和批之间没有相互耦合,但是也会带来的问题

  • 效率层面:流批底层数据模型不一致,导致应用层需要做大量的拼接逻辑(同比、环比、二次加工等),搭建效率低,且容易出错。
  • 成本层面:流批存储系统隔离(面向不同写入场景),提供的数据服务不一致,维护成本高。同时,手工创建数据同步任务,增加了开发成本和存储成本。
  • 质量与资源层面:首先,一个业务逻辑,两个引擎两套代码,SQL 逻辑不能复用,数据一致性和质量难以保障。其次,不同平台和引擎间切换,开发体验割裂,容易出现变更遗漏。并且,批处理&流处理集群无法做到错峰,资源利用率较低。

2、流批一体架构(Kappa+Lambda)

本质上是在流的场景中寻找批场景

  • 流批逻辑层:这是最重要的部分之一。业务层和存储层仍然不变,在此之上构建一个流批逻辑层来进行流存储和批存储的映射。有了这个逻辑层,就可以基于 Flink 引擎面向统一的逻辑层做业务逻辑表达,并且输出是统一的。
  • 计算层:做流批统一处理。首先,一套代码,两种计算模式,逻辑统一,灵活切换,可以实现研发效率大幅提升。其次,流批计算资源混部,资源利用率提升。
  • 服务层:做流批统一存储,无需手工同步,无重复存储。
  • 应用层:进行产品组装,流批存储透明化,查询逻辑完全一致,应用端接入成本大幅降低,点查 / OLAP 分析统一支持。