数据仓库体系
2022-11-13 00:36:19 3 举报AI智能生成
数据仓库建模
作者其他创作
大纲/内容
用户画像
数据分析平台
自主取数平台
推荐系统
个性化推送
ABtest
精细化运营
其他
数据应用
开发规范
设计原则
模型设计
试运行后上线
模型新增
评估对下游任务的影响
模型迭代
模型新增&迭代
sql调优
事实表维表拆分整合
模型优化
设置优先级
合理评估优先级
模型优先级
模型层面
调度系统调度不起来任务
运行成功的状态一直不改变，下游无法运行
调度系统
没有配置依赖
任务互相依赖
任务调度配置
调度层面
计算
存储
资源
组件故障
大数据运维层面
数据量
唯一性
指标波动
数据质量监控
晚点时间设置
人工介入
任务延迟未产生出监控
监控层面
人员安排
告警机制
问题处理机制
责任划分
延迟故障等级报告
值班层面
数仓任务及时输出
实时数仓
面向主题
集成性
稳定性
特点
建立公司同一数据中心
为数据BP，运营人员提供数据支持
为领导提供决策支持
意义
事物
数据库
主题
分析
数据仓库
面向内容
当前最新数据
历史数据
数据存储
三范式
星型模型
模型建设
与数据库对比
数据仓库特点
容易出现数据不一致情况，且无法水平对比
早期数据集市
基于搭建好的企业级数据仓库，从属数据集市
数据集市
inmon架构的数据仓库存储的是最细粒度的数据
inmon架构的数据仓库是符合三范式的
inmon架构的数据只能从数据集市获取，不能跨过数据集市直接从企业级数据仓库中获取
inmon架构--三范式建模
事物事实表保留的是最原始的数据，所以其实也叫原子事实表
定义
比如下单，支付，发货等这些业务过程构建的一类事实表，由于是最细粒度的数据，所以我们可以根据这些数据做各种各样的分析。
举例
多种方式表达粒度
当天发生才会有数据
稀疏
事实完全可加
插入
可以每日分区保留当天数据或全量快照表
特性
事物事实表
周期快照事实表的粒度和事物事实表不太一样，一般以维度属性进行声明，然后结合时间间隔
比如历史到现在的订单量，昨天的好评数等，昨天浙江的支付总金额等，时间间隔不是固定不变的，可以是每天，每月，每周，近7天，近15天等。
维度+周期声明粒度
当天未发生，但是历史至今发生过，也会记录
粘稠（重要特性）
比如近7天的销售额不能相加，但是可以算一下平均值
至少一个半可加事实
每日分区保留当天统计的该周期内的数据，之后不再修改，除非口径变动
周期快照事实表
累积快照事实表，讲需要分析的各个业务过程的事实放到一个表中进行分析
比如：下单，支付，发货，签收等，我们会把这四个业务过程的事实放入到事实表中（包括每个过程发生的时间）
多种表达粒度
数据探查，数据分析
维度退化
插入与更新
每天保留全量数据-全量快照表
累积快照实时表
分类
子主题
事实表
指的是，我们的事实表需要关联哪些维度，比如健身房的私教课事实表，我们可能需要确定教练维度
选择维度
选择了教练维度，我们就要确认教练维度的主维表了，这种情况一般是业务库抽过来的教练基本信息表。
确定主维度
这个也不一定有，有的话就需要关联一下，比如教练的课时安排等
确定关联维表
这个就比较重要了，涉及到我们最终的维表的属性值，这个不需要自己进行权衡，可能需要与业务方，需求方进行沟通，防止近期可预见的属性值缺失，到时候后期在进行迭代。
确定维度属性
维表设计步骤
1、尽可能多给出一些维度属性，避免后期频繁迭代
2、尽量描述的文字也给出，比如商品id，商品名称等
3、区分数字类型的属性，如单价
4、沉淀出通用的维度属性，一般指不能直接获取，需要我们后期加工的属性，减少在使用过程中的重复开发或者维度不一致的情况，比如当前是否vip
维度设计的建议
代理键
自然键
主键设计
啥也不用改，就用历史的维度属性值这种方案一般情况下都不会用吧，目前我还没想到那种场景用得上。
事实表：你的LOL每局比赛维表：你的账户基本信息表，里面包含段位，金币等
你3-7月份是白银，8月份升了黄金，但是你的维表属性没有改，还是使用的白银，你会乐意吗？
属性值不变
只能反映最新情况，无法保留维度属性的历史值，对于历史变化，这种方案是无法实现的。
你3-7月份是白银，8月份升了黄金，但是你的维表属性直接改成了黄金，我们会发现，如果我们想在白银阶段打了多少把，哦吼，好像统计不了
重写维度属性值
熟悉拉链表的同学应该都知道，拉链表是目前最合适的方案之一，不论是历史熟悉还是最新属性，都给你安排的明明白白的
拉链表
这种方式的弊端就是不能把不同时间的事实归为历史属性或者最新属性，业务场景有限，只能历史的归历史，新的关联新的
你3-7月份是白银，8月份升了黄金，在账户维表里面新增一列新的行，存储新的属性值，我们历史数据可以和之前的行匹配，新数据可以和新的行匹配，但是你想把所有的LOL比赛全部归属到黄金段位，不好意思，办不到
增加维度行
不常用，也不知道到底增加多少列，简直是个无底洞，会伤及无辜
你3-7月份是白银，8月份升了黄金，加一个属性字段9月份升了铂金，又加一个字段？
10月份升了钻石，又加一个字段？
增加新属性
啥也不用改，每天保留一份全量快照表，想怎么使用都行，这种方式最简单最容易理解了，唯一缺点就是存储成本比较高。
你3-7月份是白银，8月份升了黄金，不管你怎么变化，我每天存的全量快照表，用当天的事实匹配当天的维表属性。
全量快照
缓慢变化维SCD
选择一个主维度表，把其他相关的维度表属性关联上去，可以丰富主维表的维度属性，方便使用，减少关联
垂直整合
把具有相同维度属性的相关表可以整合到一张表中，发那个吧管理使用
水平整合
整合
为什么需要垂直拆分呢，由于维度各属性的产出时间，热度，访问频率不一样，也有维度经常变化，有些基本不会变动，所以在这种情况下，为了使维表最优化，我们应该做一些垂直拆分的工作。
1、不常用属性1，不常用属性2访问频率非常低，一年难得访问一次2、当前是否会员属性，来自于爬虫属性，爬虫每天上午7点才产出数据，该维表整体产出时间需要到8点30分，所有核心报表延迟3、当天是否活跃属性变化频率非常高
场景再现
垂直拆分
为什么需要水平拆分呢，可能由于历史原因，把不同产品下的相同维度强制性合并到同一张表里面了，但是后来发现这张表并不太好用，业务相关性也并不大，而且由于某个产品的维度经常性改变，导致该表频繁迭代，稳定性很差，直接影响了其他业务
水平拆分
拆分
维表的拆分与整合
维度表
表区分
虚拟数据集市，无实际存储
按照主题域划分
事实表周围都是一级维表
星型模型不需要多次join，减少查询时间，提升查询性能
星型模型存储数据有冗余，浪费存储，不过也是可以空间换时间的表现
事实表周围存在一级与二级维表
雪花模型
事实表与事实表以维表相关联
星座模型
架构
存储的数据有粗粒度的，也有细粒度的
数据仓库可以直接对外提供数据
不存在真是数据集市，存在虚拟数据集市，按主题域进行划分
以需求为导向，自下而上进行开发建设
Kimball架构--维度建模
混合架构
架构选项
明确口径，评估排期，需求正规流程提交
需求分析调研
了解数据表字段能不能满足需求，看看字段有没有少，如果发现少了或者提供的数据源没法满足需求，需要及时找对应的人员沟通，可别自己瞎搞或者跑路了
数据字段能否满足需求
看下表的数据结构，有没有json数据或者其他比较复杂的数据，便于数仓处理
表的数据结构
看下数据内容，看看有些字段是不是毫无意义，不需要存储在数仓，或者看下是不是有很多空值的情况，脏数据情况，其实就是探查一下业务库的数据质量，通过这些我们可以大概判断在数仓有多少的清洗机制
表的数据内容（数据质量）
看一下数据量，方便我们抽取的时候选择增量抽取或者全量抽取，甚至可以问一下业务方业务增长情况，更能准确的决定数据抽取策略
表数据量
数据探查
完善指标命名规范，指标同名同义，指标与业务强相关，明确指标构成要素
指标管理
完善开发流程规范，标准化业务调研，知识库文档集中管理，建立模型评审机制
ODS->DWD->DWS->ADS
etl开发
制定数据测试标准
数据验证
规范化调度参数配置
任务调度
线上管理
开发大体流程
比如额度单位统一为 元/美元/分/美分
单位
如 平台id，统一为int或者String，避免出现两个不同的表定义不同的类型product_id，统一定义为string，不要出现a表定义为string，b表定义为bigint
字段类型
对没有注释的字段，需要及时补全新建表的时候，一定要带上注释
注释
时间格式
A表 1:男 2:女B表 0:男 1:女统一为: 1:男 2:女
枚举值
比如身份证号，手机号，邮箱等需要用加密函数进行脱敏
数据脱敏
-99
string
0
int/bigint/double/decimal
1700-01-01
date
1700-01-01 00:00:00
datetime
空值替换
清洗规范
多chanal，适用于所谓数据平台组件
datax
分布式
sqoop
工具
主键唯一
存在更新时间字段
不存在物理删除情况
基本条件
参考目前的数据量
考虑之后的业务发展情况
参考方向
最基本的应该是要设定阈值，如50w
阈值设定
增量同步
数据量小且业务量增长缓慢的表
一般小维表
全量同步
同步策略
t+1
canal+kafka
flink cdc
实时
业务数据
flume
logstash
对于业务数据，不太注重数据质量，当然能保证的我们尽量也保证一下
数据质量保证
日志数据
Python
爬虫数据
数据同步
贴源层，与业务保持一致，不做任何处理
ods
贴源层
清洗、建模、输出主题宽表
dwd
已分析的主题对象作为建模驱动，基于上层的应用和产品指标需求，构建公共粒度的汇总指标事实表，以宽表化手段物理化模型。构建命名规范，口径一致的统计指标，为上层提供公共指标，建立汇总宽表，明细事实表
dws
基于维度建模理念思想，建立企业一致性维度。降低数据计算口径和算法不统一风险。公共维度层的表通常也被称为逻辑维度表，维度和维度逻辑表通常一一对应。
dim
公共层
数据应用层ADS（Application Data Service）:面向业务需求定制开发，存放数据产品个性化的统计指标数据
ads
应用层
分层规范
每一个数据分层都有他的数据域，这样我们在使用表的时候能更方便的定位和理解。
清晰的数据结构
简单来讲可以这样理解，我们最终给业务呈现的是一张能直接使用的业务表，但是他来源有很多，如果有一张来源表出问题了，我们希望能快速准确地定位到问题，并清楚他的危害范围。
数据血缘追踪
规范数据分层，开发一些通用的中间层数据，能够减少极大的重复计算
减少重复开发
讲一个复杂的任务分解成多个步骤来完成，每一层只处理单一的步骤，比较简单和容易理解。而且便于维护数据的准确性，当数据出现问题后，可以不用修复所有的数据，只需要从有问题的步骤开始修复。
把复杂问题简单化
分层好处
尽量避免出现dws宽表中使用ODS又使用（该ODS所归属主题域）DWD的表。
同一主题域内对于DWD生成DWD的表，原则上尽量避免，否则会影响ETL的效率。
DWS和ADS中禁止直接使用ODS的表，ODS的表只能被DWD引用
禁止出现反向依赖，例如DWD的表依赖DWS的表
数据流向
数仓分层
主题域
数据域
主题域/数据域划分规范
数据分析师协作
业务方协作
行业术语（一般指翻译不太准的）
是否必要
是否存在
词根评审
id
英文词根
中文词根
使用频率
责任人
评审日期
词根维护
词根规范
数据模型的维度设计主要以维度建模理论为基础，基于维度数据模型总线架构，构建一致性维度和事实。参考阿里onedata建模
指导理论
参考数仓分层
建模层次
选择已经确定业务进行梳理，了解业务流程（参考产品数据文档）
ER关系：输出ER关系图，了解实体关系，验证数据是否一致 PDM
现有数据流梳理：输出流程图 PDM
结合提数模型，指标，产品需求文档等，优化目前模型：基于上一步PDM输出优化模型，记录优化点：（数据流跟数据模型结合）
基于以上文档进行评审，不通过进行迭代
评审通过后进行开发，上线：开发在目前系统上实施，优先级降低，任务时间错开
实施步骤
建模评审规范
支持重跑
数据生命周期合理
任务迭代不会严重影响任务产出时间
开发原则
表命名
任务命名
命名规范
多表连接时，使用表的别名来引用例。如t1.user_id t2.user_name
表明前需要加上项目名，一个是比较清晰，另一个是如果需要把该任务整段代码移到其他项目去跑的时候（比如分析查询项目），需要手动加上项目名，否则会报错
不要出现select * from 这样的操作
sql编写规范
开发详细流程及规范文档
数据仓库建设
完整性
一致性
关联性
及时性
真实性
准确性
评估难度
梳理表字段
制定资产等级
制定检验规则
事前
数据量稽核
非空性稽核
唯一性稽核
指标波动稽核
异常告警
事中
全量稽核
数据质量模型设计
表评分算法
数据质量管理系统报表查询
订阅
事后
实施流程
数据质量管理
减少企业成本
成本治理缘由
机器利用率低
存储周期长，存储资源增长过快
成本没有量化标准
降本意识薄弱
任务优化空间非常大，尤其是离线计算
目前存在的问题
延迟启动
任务下线
任务调优
修改执行周期
账单排名，促进优化
解决方案
总览
按照责任人
按照业务线
明细分析
治理效果分析
数据成本治理
数据权限控制
程序检查
流程化操作
敏感SQL实时查询及操作日志分析
部门重视数据安全
数据安全
存储元数据
运行元数据
调度元数据
技术元数据
维度及属性
业务过程
指标
业务元数据
元数据分类
Excel
自研
商用，dataworks
开源组件，如Atlats
元数据平台建设
数据地图
数据血缘
数据开发规范
成本治理
元数据应用
元数据管理
主数据管理
数据规范
数据治理
基于业务的理解，对各种数据进行整合和关联
增强数据可用性，可读性，让使用方可快速获取有价值的信息
增强模型一般使用星型模型构建
增强模型就是按照一定规则设计的表
什么是数据模型
进行全面业务梳理，改进业务流程
构建全方位的数据视角，消灭信息孤岛和数据差异
解决业务的变动和数据仓库的灵活性
帮助数据仓库系统本身的建设
为什么要数据模型
powderDessigner
draw.io
建模工具
高内聚和低耦合
核心模型和扩建模型分离
公共处理逻辑下沉及单一
成本与性能平衡
数据可回滚
命名清洗、可理解
数据建模规则
生成业务模型，主要解决业务层面的分解和程序化
业务模型
生成领域模型，主要对业务模型进行抽象处理，生成领域概念模型
领域模型
生成逻辑模型，主要是将领域模型的概念实体以及实体之间的关系进行数据库增次的逻辑化
逻辑模型
生成物理模型，主要解决，逻辑模型针对不同关系型数据库的物理化以及性能等一些具体的技术问题
物理模型
建模阶段划分
1、选择要进行分析决策的业务过程 比如下单
2、选择粒度，选择粒度，在事件分析中，我们要预判所有分析需要分析的粒度，从而决定选择的粒度，用于分析时分组和筛选
3、识别维表，选择好粒度之后，就需要基于此粒度设计维表，包括维度属性，用于分析时就行分组和筛选
4、选择实时，确定分析需要衡量的指标
建模步骤
新增加的模型是否和老的模型有冲突
扩展性
能否保证日常的sla（时效保障）
时效性
输出的指标数据质量能够保证
存储成本
计算成本
低成本
业务快速更新迭代的情况下不会太影响底层模型
健壮性
主题域归属
任务命名规范
规范度
模型引用系数：模型被读取并产出下游模型的平均数量
dw、dws下游直接产出的表的数量
复用度
汇总数据能直接满足多少查询需求，即应用层访问汇总层数据的查询比例
跨层引用率：ods层直接被dws、ads、DM层引用的表，占所有ods层表的比例（仅统计活跃表）
同层level>2的占比等量化指标
快速响应业务方的需求
比较很好的模型，使用方是可以直接从该模型获取所有想要的数据的，如果dws、ads、dm层直接应用ods层表的比例太高，则该模型不是最优，可以继续优化
完善度
模型评判标准&模型优化策略
数据建模
数据仓库体系
0 条评论
下一页
为你推荐
查看更多
