数仓建设学习路线（二）模型建设(1)

OLTP VS OLAP

OLTP

概念

全称OnLine Transaction Processing，中文名联机事务处理系统，主要是执行基本日常的事务处理，比如数据库记录的增删查改,例如mysql、oracle。

OLAP

概念

全称OnLine Analytical Processing，中文名联机分析处理系统，支持复杂的分析操作，侧重决策支持，并且提供直观易懂的查询结果,例如、ClickHouse、Doris、Kylin

种类

MOLAP

MOLAP将OLAP分析所用到的多维数据物理上存储的形式，形成“立方体”的结构（cube），更注重预计算，常见组件如下

• Kylin

不够灵活，无二级索引

需要cube与计算，后期维护成本大

支持离线数据规模大

支持标准sql，性能高，查询速度快

• Druid

维度之间不能随意组合，不能自由查询

不支持join，sql支持很弱

支持大规模数据

高性能，列存压缩，预聚合

ROLAP

ROLAP无需预计算，直接在构成多维数据模型的事实表和维度表上进行计算，常见组件如下

• ClickHouse

易用性较弱，SQL语法不标准，join的支持不好，维护成本高

列式存储，通过数据引擎使得数据存储本地化来提高性能，具有单机版超高性能

• Spark/Impala/Presto

当查询复杂度高且数据量大时，可能分钟级别的响应。同时其不是存储引擎，因此没有本地存储。

支持的计算数据规模大(非存储引擎)

灵活性高，随意查询数据

易用性强，支持标准SQL以及多表join和窗口函数

处理方式简单，无需预处理，全部后处理，没有冗余数据

HOLAP

由于MOLAP和ROLAP有着各自的优点和缺点，为此一个新的OLAP结构——混合型OLAP（HOLAP）被提出，它能把MOLAP和ROLAP两种结构的优点结合起来，常见组件如下

• Doris

发展不够成熟，稳定度待提升

支持高并发场景、秒级/毫秒级查询

支持标准化sql，支持大款表和多表join

OLTP VS OLAP两者对比

数仓分层

为什么要分层？

1. 清晰数据结构：数仓每一层都有对应的作用，方便在使用时更好定位与了解

2. 数据血缘追踪：清晰知道表/任务上下游，方便排查问题，知道下游哪个模块在使用，提升开发效率及后期管理维护

3. 减少重复开发：完善数仓好中间层，减少后期不必要的开发，从而减少资源消耗，保障口径、数据统一

4. 把复杂问题简单化：将复杂任务拆解成多个步骤来完成，每一层处理单一步骤，当数据问题出现时候，只需从问题起点开始修复

分层具体内容

ODS（接入层）

全称Operational Data Store，ODS层是最接近数据源的一层，从数据源（api、数据库等）将数据同步数仓中，中间不做任何处理操作

DWD（明细层）

全称Data Warehouse Detail，是数仓明细数据层，对ODS层的数据进行关联，清洗，维度退化（将维度表中维度数据放入明细表中），转换，主题域建设等操作

DWM（轻度汇总层）

全称Data WareHouse Middle，轻度汇总层数据仓库中DWD层和DWS层之间的一个过渡层次，是对DWD层的生产数据进行轻度综合和汇总统计(可以把复杂指标前置处理），提升公共指标的复用性，减少重复加工

DWS（汇总层）

全称Data WareHouse Servce，按照主题域、颗粒度（例如买家、卖家）划分，按照周期粒度、维度聚合形成指标较多的宽表，用于提供后续的业务查询，数据应用，最重要一点需要在DWS层完成指标口径统一及沉淀

ADS（应用层）

全称Applacation data service，按照应用域，颗粒度划分（例如买家、卖家）划分，按照应用主题将对应数据标签补充至应用层，最终形成用户画像及专项应用

什么是数据模型

数据特征的抽象，通常包括数据结构、数据操作、数据约束。

业务模型

也称企业模型，它为企业提供一个框架结构，以确保企业的应用系统与企业经常改进的业务流程紧密匹配，它是从纯业务角度对企业进行业务建模，特指某业务具体流程环节例如客服业务-客服评价的数据模型。

概念模型

对业务模型进行抽象处理成一个个业务概念实体，最常见的就是E-R模型，与具体数据库系统无关，必须转化为逻辑或者物理数据模型才能在数据库系统中实现，概念模型就像是er图记录整体概览，包括了每一步操作，像是大图展示。

逻辑模型

概念模型中的概念实体以及实体之间的关系在关系型数据库上的逻辑化。

物理模型

面向计算机的，因此与具体的数据库系统、操作系统以及计算机硬件都相关的，是逻辑数据模型在这个物理平台上的物理化,例如存储的元数据信息（表名、字段名、存储信息、路径等等）。

数据模型建设方法

维度建模（新）

按照事实表、维表来构建数据仓库模型的方法，称为维度建模。根据维度表与事实表之间的链接方式，分为星型模型 和 雪花型模型。

星型模型

概念

因为数据的冗余所以很多查询不需要做外部连接，因此一般情况下效率比雪花模型高，设计与实现比较简单

特点

只需要确定主键

不需要在外部进行连接，大大提高性能实现高度并行化

容易理解，只需要看关联条件和血缘关系就能确定模型

雪花模型

概念

由于去除了冗余，有些统计就需要通过表的连接才能产生，所以效率不一定有星型模型高。因此在冗余可以接受的前提下，实际运用中星型模型使用更多，也更有效率

特点

需要主外键来确立管理

雪花模型在维度表、事实表之间的连接很多，因此性能方面会比较低，不能并行化

过多的连接使得开发和后期维护都增大难度

三范式建模（旧）

遵循三范式建模（第一范式：每个属性都不可再分，第二范式：非主字段都完全依赖于主键，第三范式：非主键字段不能依赖于其他非主键字段）

二者区别

考虑角度不同

• 三范式严格遵循每一范式内容，按照范式内容建模

• kimball建模（维度维度），按照多个维度进行分析，更多按照星形模型

出发点不一样

• 3NF建模（三范式建模），考虑自上而下建模（这里的上指的是上游数据源，先拥有dw层再往上进行设计，瀑布模型，不易于后期扩展）

• kimball建模（维度维度），考虑自下而上建模（这里的下指的是数据集市），先拥有数据集市来设计dw层，敏捷模型，易于扩展易于后期维护及使用）

• 模型精度不一样

• 三范式模型由于没有分层概念冗余低数据精度高

• kimball建模（维度维度），由于多层建设导致冗余高数据精度低