目录
yfd数仓建设
1，主题设计
2，yfd数仓构建流程
2.1 数据调研，需求分析
2.2 主题划分，抽象业务过程
2.3 规范开发，模型评审
2.4 落地物理模型，文档，推广
3，交易主题有哪些事实表与维度表
4，yfd数仓分层
5，yfd规范
6，yfd数据质量怎么做的
7，yfd数据治理做了哪些
8，yfd指标一致性/指标平台
8.1 指标分类标准
8.2 维度分类
8.3 指标口径由数仓人员收口，与模型相辅相成。
9，yfd业务过程
模型设计原则
保证数仓指标建设一致性
怎么评断一个模型的设计好坏？
业务过程/主题交叉怎么区分主题域？
新增一个业务过程怎么划分主题？
数仓为什么要分层？
建模方式有哪些？
ER建模
维度建模
Data Vault模型
Anchor 模型
星型模型域雪花模型区别，优缺点？
事实表分类以及在工作中的使用？
缓慢变化维的设计
为什么做为度退化？
为什么搭建指标体系？
指标体系搭建的难点
宽表的优缺点
为什么做模型评审
怎么衡量项目收益？
Hive问题：
yfd数仓建设
1，主题设计
| 业务域 | 主题域 | 主题 | 主题说明 |
| 斑马 | 当事人 | 用户 | 主要是学生 |
| 设备 | |||
| 员工 | |||
| 流量 | frog | 客户端流量 | |
| request | 用户服务端流量 | ||
| 课程 | 课程 | 课程开班,学习 | |
| 作业 | 书写作业，交作业，老师批改作业，作业点评 | ||
| 内容 | 文章 | ||
| 问卷 | |||
| 交易 | 订单 | 下单、支付、退款等业务过程 | |
| 营销 | 发放虚拟货币、兑换抵用券等业务过程 | ||
| 仓储 | 物料（商品）进出仓库的业务过程 | ||
| 物流 | 打包、运输、配送等业务过程；（物流信息主要来自第三方） | ||
| 辅导 | |||
| 工具 |
2，yfd数仓构建流程
2.1 数据调研，需求分析
无论是从业务需求还是从数仓模型重构方向都是要先与业务、分析师沟通业务过程、核心指标、维度再与研发了解业务系统流转与mysql数据源
业务角度：需求文档，包含指标，维度等
数仓角度：全面了解主题业务过程，构建主题业务过程的总线矩阵，绘制主题概念模型图，如下图（订单）
2.2 主题划分，抽象业务过程
明确业务过程拆分事实表、维度表，确定粒度，规划逻辑模型图（有哪些字段）
构建指标维度矩阵/主题域与一致性维度矩阵
2.3 规范开发，模型评审
模型评审依据：文档 + 伪代码
模型评审内容：
1，介绍模型/业务背景、设计思想、解决哪些需求
2，规范：
表名：数据层级/库名 + 业务域 + 主题 + 业务过程/表描述 + 更新周期
字段命名：（词根、词缀、标准）
name/type这种要加上描述对象如user_name,class_name
有枚举值的字段要加_cd 。。。。
数据类型：主要保证公司级数仓针对同一字段数据类型相同，避免不同类型关联
导致数据异常
3，逻辑字段要加上描述，枚举值字段补充枚举值描述
4，其他人帮忙确认是否还需补充其他主题所需的一些信息
2.4 落地物理模型，文档，推广
3，交易主题有哪些事实表与维度表
订单主题概况图
4，yfd数仓分层
大佬定制如下：
| 数据分层 | 分层定位 | |
| T3-应用数据层 | ADS-应用数据层 | 主要用于各产品或各业务条线个性化的数据加工，承载更多更加灵活的业务需求，提供数据能力给各类数据产品与业务系统的数据集市 |
| T2-公共模型层 | TOPIC-主题宽表层 | 主要是以构建核心业务对象（含核心分析维度，如用户ID，日期，城市等）为粒度的业务宽表；以及核心业务过程为主，扩展整个相关业务过程的较明细粒度的业务宽表；实现跨主题域，交叉业务过程，多分析维度与汇总数据为预关联建设一站式业务分析宽表。不建议做任务调度依赖，不提供SLA保障。 |
| DWS-聚合数据层 | 汇总数据层按照主题对共性维度指标数据进行轻度、高度聚合，减少从明细数据产出公共与常用口径数据的概率，增加复用性； | |
| DIM-维度数据层 | 业务过程的业务对象，环境信息等抽象集合，对维度进行统一标准化定义，实现维度信息共享，包含基本维度属性与常用聚集维度属性 | |
| DWD-明细数据层 | 以主题域的方式对公司的业务过程和业务维度进行抽象和划分；基于业务过程驱动建模，在这一层对业务过程明细进行整合，负责各业务场景垂直与水平数据整合、常用公共维度冗余加工，以及明细业务标签信息加工。为了提高明细数据的易用性会采取一些维度退化手法，冗余更多的维度属性 | |
| T1-原始数据层 | ODS-操作数据层 | 操作数据层定位于业务明细数据保留区，在业务系统与数仓之间形成一个隔离层，负责保留数据接入时点后历史变更数据，数据原则上全量保留。模型设计依据业务表数据变更特性采取拉链、流水表两种形式。 |
| ORI-数据接入层 | 也叫数据准备区，定位是缓存来自 DB 抽取、消息、日志解析落地的临时数据，结构与业务系统保持一致；负责对垃圾数据、不规范数据进行清洗转换；该层只为 ODS 层服务； | |
自己简单想：
| 数据层级 | 主要作用 |
| ori | 数据源层，还原mysql业务数据 同步方式：sqoop全量，binlog日增量，日志同步（小时分区） |
| ods | 数据操作层，将ori增量与前天ods全量合并成一份最新分区下全量数据，规范字段命名（下划线），脱敏 |
| dwd | 明细数据层，针对业务过程进行抽象整合，更多采用维度退化手法将维度退化至事实表中减少后面事实表和维度表的关联，提高明细数据的易用性 |
| dim | 公共维度层，统一标准化定义公共维度，实现维度共享 |
| dws | 轻度汇总层，抽取共有逻辑，保证口径一致算法统一的统计指标。提高数据的复用性 |
| ads | 应用层，包括报表指标与业务特有逻辑 |
5，yfd规范
DDL建表规范：
统一外部表
出手工维护的表用textfile外，其他统一 orc + snappy
必须有comment
表名规范：
层级 + 业务域 + 主题 + 表描述 + 变更频率 ：dwd_eng_order_mall_da
ori+mysql库表+da/di ：
DML逻辑规范：
逗号在前，注释在后
when 单起一行
配置压缩
hql头部注释写清业务过程背景与变更记录
字段命名与数据类型规范：
同一字段命名类型要统一
禁止拼音加数字
修饰前缀不要忘：name ->user_name,class_name
是 1 0 否不能混
id命名留string
枚举类型加cd
数量类型加num。。。
6，yfd数据质量怎么做的
时效性：配置SLA（核心/重要），监控运行完成时间，超时报警
具体时间怎么设置：根据业务所需指标产出反推要求几点执行；梳理核心重点表统计周
期内平均时间再加点buff
完整性：（记录信息完整，数据不缺失）
保证数据抽取数据量完整（工具配置，比较count）；
表核心字段不缺失，如订单中user_id不能为空（工具配置，count1 与count user_id比较）；
数据按主键不重复（工具配置，count count distinct 数据量相同）
一致性：（数仓体系中，同一对象描述一致）
枚举值，mapping映射保持一致（例如男女）,指标口径一致性，字段命名类型一致
准确性：（记录信息准确）
校验数据字段值是否有异常，如支付金额大于等于0，user_id 大于0，没有默认值（工具配置，检查数据）
任务上线，一定要执行测试阶段，并且需要搭档进行代码review 保证命名规范，逻辑正确。
7，yfd数据治理做了哪些
1，hive表生命周期监控：
（1）对长期没有访问的数据表报警下线（30天、60天、90天）
（2）若ori被除了ods的引用，说明该ori所属模型没有简历完备或者业务梳理规划欠缺
2，冷热数据分离：将1个月前的数据放到廉价机器上
3，设置不可删除目录，避免误删目录（发生过，删除了warehouse根目录下的内部表）
4，数据地图根据任务的依赖关系，抽象出了数据血缘
5，模型迭代，梳理业务，规范建模开发，提高数据复用性，统一收口逻辑口径
6，推出指标平台，统一了业务口径
小文件处理：还没看
8，yfd指标一致性/指标平台
8.1 指标分类标准
业务线 ---> 业务部门 --->业务部门下指标分类（订单，课程）
8.2 维度分类
业务线 ---> 具体分类
先公共分类（包括：时间相关，地理位置相关）
特殊部门（独有逻辑不呗其他所引用，如转介绍，客服）
再按主题域细分（如，课程，渠道，流量，订单，商品）
因是否这种标签比较多，就要看具体描述的对象是什么
8.3 指标口径由数仓人员收口，与模型相辅相成。
通过总线矩阵保证数仓各主题之间使用的维度相同，避免口径数据不统一
每月进行模型表宣讲推广，针对分析师反馈的老表数据问题，一般修改老表同时会建议使用新表，针对一些固化报表，自己进行替换，逐渐下线老模型。面对不同口径，尽可能说服业务统一，如有特殊在指标命名上加以修饰。
9，yfd业务过程
家长注册 ---> 购买体验/导流课 ---> 完课 ---> 购买正价课/续报
导流课：1周
体验课：2周
长期半年课：24周
长期年课：48周
续报周期：导流/体验课完课2周内（假期加一周，即3周）购买正价课
10，yfd数据同步到数据消费过程同步
1，sqoop全量同步mysql数据源（数据比较小）
2，binlog增量同步mysql数据源（表数据多，日更新操作频繁）。
昨天的全量数据 = （前天全量 + 昨日insert + 昨日update）取最新提条数据后去掉
昨日delete数据
3，日志打点数据每日小时分区同步
数据分层建设
消费产出主要输出pipe （mysql）或者 指标平台（doris）
模型设计原则
1，高内聚低耦合
将业务相关、相近、粒度相同的数据设计为一个逻辑或者物理模型
低概率同时访问的数据分开存储
2，公共逻辑下沉
抽象的出的公共逻辑设计越下层越好，提高复用性，与统一口径
3，适当维度退化，数据冗余
空间换时间，提高查询效率
4，命名规范，含义统一
相同含义字段命名要统一
保证数仓指标建设一致性
总线矩阵：设计数仓主题域分层时构建维度一致性总线矩阵，保证维度表有且只有一个
怎么评断一个模型的设计好坏？
1，指标的覆盖程度：相关的指标需要从多张表里关联取出，耗时费力也容易造成指标不统一
2，模型的易用性与复用性：其他层级或者逻辑都没有引用该模型表，或者该表在被引用时还
需要重复或复杂的处理，说明抽象公共逻辑做的不好
3，ori被除了ods层以外的其他层级所引用，说明该ori描述的业务过程设计的不完善，建设过
程中丢失业务环节
4，是否规范开发，是否保证一致性
业务过程/主题交叉怎么区分主题域？
首先要看关心的核心业务过程或产出指标是什么，其次产生交叉的业务过程是否有被当成维度来分析数据指标，如看完课后是否再次下订单续报，这种下订单就属于维度分析角度。
新增一个业务过程怎么划分主题？
其实在数仓前期建设规划时，就已经明确每个主题包括哪些业务过程了，新增业务过程可以将其归纳到相近相似的业务过程所属主题。如，作业老师评判后，学生在次打开回顾错题，这也属于课程主题域下的作业主题。
数仓为什么要分层？
1，将复杂的逻辑简单化
2，抽象公共层，提高数据复用性，用空间换时间提高数据查询执行效率
3，逻辑解耦，当业务变动时不需要修所有业务相关数据表，只需要修改某一层相关的数据表
建模方式有哪些？
ER建模
用实体关系模型描述企业业务，在范式理论上符合3NF。数仓3NF是站在企业角度面向主题的抽象，而不是针对某一具体流程的实体关系的抽象。
缺点：查询效率不高，使用不灵活，因满足3NF在使用时就需要关联更多的表
维度建模
从分析决策的需求出发构建模型，为分析需求服务。重点关注用户如何更快速的完成需求分析，需要大量的数据预处理与数据冗余。常用模型有，星型模型、雪花模型、星座模型。
事实表：企业真实发生的业务过程即现实发生的事件，大多有度量
维度表：分析数据所处环境，补充描述性数据
Data Vault模型
ER模型的衍生，基于主题范式建模
组成：
Hub：业务实体，只记录key键、时间、数据源
link：代表与Hub之间的关系，也只记录key键、时间、数据源
· Satellite：Hub的详细数据内容
Anchor 模型
无
星型模型与雪花模型区别，优缺点？
星型模型：以事实表为中心，四周发散关联维度表，维度表之间没有关系（如，一张城市维表，里面记录了城市、省市、国家）
雪花模型：以事实表为中心，四周发散关联维度表，但有的维度表不是直接关联到事实表上，而是通过维度表关联的。（如，地域维表拆分出城市、省份、国家维度表）
星座模型：多张事实表之间共享维度信息
| 模型 | 优势 | 缺点 |
| 星型 | 空间换时间，有数据冗余在使用时就不再需要关联更过的表，提高了执行效率 | 维度表数据冗余 |
| 雪花 | 去除了数据冗余 | 使用降低执行效率 |
事实表分类以及在工作中的使用？
| 分类 | 描述 | 使用 |
| 事务事实表 | 描述业务过程 | dwd层基本都是事务事实表，针对主题业务过程进行抽象 |
| 周期快照事实表 | 一段时间内有规律的事实 | 月度财报 |
| 累计快照事实表 | 有明确开始和结束时间的业务过程 | 订单履约，物流信息 |
缓慢变化维的设计
新数据直接覆盖
老数据那行打上删除标签，新增一行新数据并打上可用标签
增加新列，区分新老数据
拉链
为什么做维度退化？
通过数据冗余，为下游聚合或查询操作做数据预处理，利用空间换时间提高查询效率。
为什么搭建指标体系？
从业务角度来讲：
统一口径，统一业务目标，避免多业务方的数据分歧
衡量业务发展质量：通过指标反映业务发展
支持分析决策
数仓角度：
释放数仓能力，告知他人我们数仓有哪些数据
指导数仓建设，查缺补漏，补全缺少的业务过程建设
指标体系搭建的难点
面试时忘记白话啥了，还得重新想，待补充
宽表的优缺点
空间换时间，数据预处理，下游使用减少表关联提高查询效率，方便使用。
逻辑修改或业务变更减少修改成本，快速响应。
为什么做模型评审
1，消灭信息孤岛。各个主题的同事之间可以相互了解其他主题下的业务过程与数据流转情况
2，规范开发，口径、数据类型全局保持一致。其他人帮忙审核模型是否有不规范的地方
3，补全数据信息。为做主题数据交叉做准备
怎么衡量项目收益？
1，效率、人力方向：数据开发节省了多少人力，提高多少效率
2，成本方向：节省多少开支，带来更多的增长
3，是否能达到项目预期，解决哪些问题
Hive问题：
优化
倾斜
函数
MR
