数仓建模
OLAP
OLTP：概念全称OnLine Transaction Processing，中文名：联机事务处理系统，主要是执行基本日常的事务处理，比如数据库记录的增删查改,例如mysql、oracle
OLAP：全称OnLine Analytical Processing，中文名：联机分析处理系统，支持复杂的分析操作，侧重决策支持，并且提供直观易懂的查询结果,例如、ClickHouse、Doris、Kylin
MOLAP ：MOLAP将OLAP分析所用到的多维数据物理上存储的形式，形成"立方体"的结构(cube)，更注重预计算
Kylin：
优点：支持离线数据规模大、支持标准sql，性能高，查询速度快
缺点：不够灵活，无二级索引、需要cube与计算，后期维护成本大
Druid：
优点：支持大规模数据、高性能，列存压缩，预聚合
缺点：维度之间不能随意组合，不能自由查询、不支持join，sql支持很弱
ROLAP ：ROLAP无需预计算，直接在构成多维数据模型的事实表和维度表上进行计算
优点：列式存储，通过数据引擎使得数据存储本地化来提高性能，具有单机版超高性能
缺点：易用性较弱，SQL语法不标准，join的支持不好，维护成本高
ClickHouse
优点：支持的计算数据规模大(非存储引擎)、灵活性高，随意查询数据、
易用性强，支持标准SQL以及多表join和窗口函数、处理方式简单，无需预处理，全部后处理，没有冗余数据
缺点：当查询复杂度高且数据量大时，可能分钟级别的响应。同时其不是存储引擎，因此没有本地存储。
Spark/lmpala/Presto
优点：支持的计算数据规模大(非存储引擎)、灵活性高，随意查询数据、
易用性强，支持标准SQL以及多表join和窗口函数、处理方式简单，无需预处理，全部后处理，没有冗余数据
缺点：当查询复杂度高且数据量大时，可能分钟级别的响应。同时其不是存储引擎，因此没有本地存储。
HOLAP ：由于MOLAP和ROLAP有着各自的优点和缺点，为此一个新的OLAP结构------混合型OLAP(HOLAP)被提出，它能把MOLAP和ROLAP两种结构的优点结合起来
Doris
优点：支持高并发场景、秒级/毫秒级查询、支持标准化sql，支持大款表和多表join
缺点：发展不够成熟，稳定度待提升
数仓分层
数仓为什么分层：
清晰数据结构：数仓每一层都有对应的作用，方便在使用时更好定位与了解
数据血缘追踪：清晰知道表/任务上下游，方便排查问题，知道下游哪个模块在使用，提升开发效率及后期管理维护
减少重复开发：完善数仓好中间层，减少后期不必要的开发，从而减少资源消耗，保障口径、数据统一
把复杂问题简单化：将复杂任务拆解成多个步骤来完成，每一层处理单一步骤，当数据问题出现时候，只需从问题起点开始修复
如何分层：
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建模（(维度维度)，由于多层建设导致冗余高数据精度低
模型建设具体流程
模型设计基本原则
维度建模设计大图
模型建设过程
总线矩阵：指以一致性维度为列，以业务过程为行，构建业务的数据矩阵，通过标记表示该维度与业务过程的相关性
数据域：对当前业务场景或业务sop进行拆分完成建设
事实表设计：围绕着业务过程来设计，通过获取描述业务过程的度量来表达业务过程，包含了引用的维度和与业务过程有关的度量。
维度：对当前场景描述及补充
颗粒度：数据域下场景用户再进行细致拆分(例如用户可拆分为买家或卖家)，颗粒度必须拆分为不可拆分的状态（例如用户拆分为买家，买家不可拆分)
度量值：对场景下数值类型的数据记录
模型数据域
概念：指面向业务分析，将业务过程或者维度进行抽象的集合。其中业务过程指企业活动中的事件，例如下单、退款、加购等，维度即度量的环境，例如下单事件中的买家。
跨数据域：背景:例妆DWS、ADS出现跨数据域（例如该模型既用于风控又用于用户画像）情况，需要根据跨的数据域再重新定数据/主题域
事实表设计
事实表
围绕着业务过程来设计，通过获取描述业务过程的度量来表达业务过程，包含了引用的维度和与业务过程有关的度量。
事务性事实表(更多应用于DWD层)：对于单事务事实表，一个业务过程建立一个事实表，只反映一个业务过程的事实对于多事务事实表，在同一个事实表中反映多个业务过程。
累计快照事实表（更多应用于DWD层)：累计快照事实表对于类似于研究事件之间时间间隔的需求,采用累计快照事实表可以很好地解决，如在统计买家下单到支付的时长、买家支付到卖家发货的时长等。
周期快照事实表（更多应用于DWS层)：在确定的时间间隔内对实体的度量进行抽样，用于研究一段时间内实体的度量值（例如近3O天pv、uv)。
事实表设计过程：识别业务过程->选择事实表类型->声明颗粒度及维度->补充主题域下度量值->维度退化
拉链表
记录历史数据，记录一个事物从开始一直到当前状态的所有变化的信息
拉链表应用场景：数据量大、表中部分内容会更新、每天保留一份全量数据、维度表的缓慢变化等
拉链表设计：
加行：为明细表添加两个字段一个字段为拉链的开始日期(默认为用户数据出现的日期)，另一个字段为拉链的结束日期(默认为9999-99-99)，当一个客户a信息变更则添加一条新数据，新数据的拉链日期为更新日期，结束日期为9999-99-99,而原来的结束日期为当天更新日期
加列：为明细表添加四个字段一个字段为拉链的开始日期(默认为用户数据出现的日期)，一个为拉链结束日期，一个为第二个段拉链开始日期(默认9999-99-99)，一个为第二个段拉链结束日期(默认9999-99-99)，当原数据更新时候，原第一个拉链日期不变，第一个拉链结束日期为数据变更日期，第二个日期开始时间为数据更新时间，第二个结束日期不变
数据模型规范
表命名(采用阿里one-data设计)
ODS层(接入层)：
全量: ods__业务数据库名}_{业务数据表名}
增量:ods {业务数据库名}{业务数据表名}_delta
DWD层(明细层)：
dwd_{(事业部名(适用大厂多事业部情况)上数据域)钛二级数据域)Af业务过程（不清楚或没有写detail)L_df/di(df为全显数据， di为增量数据
全量数据(对源数据全部覆盖)
增星数据(对源数据进行分区式覆盖，例如昨天存储10O0条订单数据，今天存储100条订单数据)
DWS层(汇总层)：
dws (事业部名(适盱大厂多事业部情况)上(数据域)二级数据域)〉乂(颗粒度}（例如买家/卖家)(业务过程)X周期粒度)(例如近30天写30d、90天写m)
ADS层(应用层)：
ads_{应用类别}(例如风控叫risk)_{应用主题/应用场景) {颗粒度}（例伽如买家/卖家)业务过程) (调度周期)（例如\天调度一次写
ld)
dim表(维度表)：
dim_{事业部名（适用于大厂多事业部情况)}_(维度定义}(例如日期写date)
tmp表(临时表)：
tmp_{表名}{临时表编号}
view(视图)：
表名}_view ### 字段命名(采用阿里one-data设计) 是否xxxxx用户，类型字段命名规范 ： is_{内容} 枚举值类型字段命名规范 ： xxxx_type 时间戳类型字段命名规范 ：xxx_date,xxx_time 周期指标命名 ：{内容)时间描述}(如最近一次last1，最近两次last2，历史his，最近第二次last2nd)_date、最近180天6m 百分比命名 ：{内容}_rate 数值类型(整型)命名 ：{内容}*cnt* {周期(周期看情况加) 数值类型(小数)金额命名 ：{内容}*amt* {周期(周期看情况加) 两个时间段之间统计命名 ：xxx(时间段1内行为)_xxx(时间段2内操作)_dur ### 数据模型标注规范 owner 表中文名+使用说明 每个开发字段中文名(中文名需要包含该字段内容，例如是否为xxxx用户，需要写出包含内容(VN) 每个模型的颗粒度 每个模型的主键(联合主键) ## 数据模型发展周期   作为数据产品/平台该如何思考本次讲的内容 可以从图中这几处想到能做的平台内容，例如数仓建设标准功能，对应的数据域内容，表中每个宁段具体信息等