数据仓库知识点笔记总结分享
2022-10-27 21:52:05 1 举报AI智能生成
数据仓库知识点笔记总结分享
作者其他创作
大纲/内容
数据建模
Inomn(三范式)一般用于OLTP系统中优点：规范化处理，降低数据冗余及解决数据一致性问题缺点：查询时需要许多表关联得出结果，降低查询性能 能力要求比较高，实施周期比较长
第一范式属性不可分割
第二范式不存在部分依赖【例如：A+B可以得出CB也可以得出C.那么存在部分依赖】
第三范式不存在传递依赖【例如：通过A可以得出B，然后通过B得出C】
Kimball(维度建模)实施流程: 选择业务过程 --gt;选择粒度--gt;确认维度--gt;选择事实一般用于OLAP系统中优点：反规范化处理,存在一定程度的数据冗余（退化维度），提高查询性能
星型模型
雪花模型
数仓优化
调度优化
耗时长的任务调度开始时间提前
业务比较关注的数据调度时间提前
调度任务剥离，不同项目的调度任务拆分
减少任务的依赖层级
模型优化
利用中间临时表，拆分复杂逻辑为多个块
整合表：重叠的表，将调度任务和数据合并
分区表：合理设计分区，部分大表增加二级子分区
中间表：数据量大、计算逻辑复杂
拆表：个别字段产出极慢的情况，可以将字段拆分为单独的表
合表：随着数仓的发展，针对业务重叠或重复的表，可以进行任务和数据合并
计算资源优化
查询时避免使用*，列出需要的字段
合理使用分区
注意数据倾斜
Hivelt;brgt;
表分类
内部表(管理表)删除内部表会将元数据及存储的数据清空
外部表可以指定数据存储的位置；删除表只会将元数据删除，不会删除hdfs目录上的数据
分区查看表的所有分区：show partitions table
静态分区插入数据时需要指定具体的分区目录
动态分区
SET hive.exec.dynamic.partition=true;开启动态分区功能
hive.exec.dynamic.partition.mode=nonstrict;动态分区的模式；默认strictstrict模式表示必须指定至少一个分区为静态分区nonstrict模式表示允许所有的分区字段都可以使用动态分区
文件格式
TEXTFIEL数据不做压缩，磁盘开销大，数据解析开销大
SequenceFile是一种二进制文件。其具有使用方便、可分割、可压缩的特点SequenceFile支持三种压缩选择：NONE, RECORD, BLOCK。 Record压缩率低，一般建议使用BLOCK压缩
RCFILE是一种行列存储相结合的存储方式。首先，其将数据按行分块，保证同一个record在一个块上，避免读一个记录需要读取多个block。其次，块数据列式存储，有利于数据压缩和快速的列存取
ORC(列式存储)是RCFILE的升级版，具有很高的压缩比节约HDFS的存储资源，提升查询性能
排序
全局排序Order By：只有一个Reducer
局部排序lt;span style=quot;font-size: inherit;quot;gt;Sort By：对于同一个Reducer内部排序lt;/spangt;
分区排序Distribute By：结合Sort By使用；对Distribute By字段进行Hash之后的值分区，然后按Sort By字段排序
Cluster By如果Distribute By和Sort By字段一致是，可以直接使用Cluster By
优化
模型层面
分区优化
桶表优化CLUSTERED BY(ID) SORTED BY(CREATE_TIME) INTO 10 BUCKETS一张表对ID进行分桶，分为10个桶。如果hash之后得到1，那么取余之后1%10=1,那么这条数据就会存储在000001_0这个文件中。以此类推。
参数层面
列裁剪hive.optimize.cp=true
分区裁剪hive.optimize.pruner=true
合并小文件Map端文件输出合并：hive.merge.mapfiles=trueReduce 端文件输出合并：hive.merge.mapredfiles=true
语法层面
GroupBy优化
CountDistinct优化
Join优化
合理控制 Map和Reduce的数量如果处理的文件很小，不比设置过多的任务。处理文件很小时，过多的任务数量的初始化时 间可能会比处理数据的时间长很多。另外，过多的任务数量会造成过多的小文件
小表关联大表（小表放左原则,MAPJOIN）Reduce阶段左边的表会被加载至内存中减少发生OOM错误的几率
大表关联大表（注意热点值）
数据倾斜
关联表KEY值分布过于集中
大表关联空字段空值过多
GroupBy某值数量过多
CountDistinct
执行计划
需求梳理、调研
数据调研/业务背景调研
1、和不同的业务部门沟通了解业务情况，以及关注的重点
需求分析
1、和数据分析人员、业务人员沟通获知真实的数据需求，获取关注的指标信息2、分析梳理现有的报表系统，整理指标需求
指标梳理体系
1、原子指标=业务过程+度量【例如：放款金额】2、派生指标=原子指标+过滤条件【例如：北京市累计放款金额】3、衍生指标=原子指标+计算逻辑【例如：最近一周累计放款金额】
梳理每个业务过程涉及的维度，指标。确定命名规范维度，确定观察这个业务的角度；指标，衡量这个业务过程好坏的结果
数据探查发现
根据已梳理好指标体系梳理数据来源沟通确认指标业务口径、技术口径
确定不同指标涉及到的数据表输出mapping文档
确定每个表数据量大小，每天增量大小确定源表数据是否存在物理删除确定是否有增量时间戳
构建总线矩阵
梳理每个业务过程（注册、授信、申请、放款、回款、回购...）涉及的维度、涉及的源系统表及每个业务过程能产出哪些指标
设计阶段
数仓分层
STG
缓冲层保存源系统抽取增量/全量数据
ODS
操作层与源系统结构保持一致，增加审计字段【数据加载时间，装载的数据日期】；保留历史数据，方便问题排查、历史数据回溯分析
DWD
明细层（基于业务过程建模），构建最细粒度的事实表，适当冗余维度属性字段（退化维度）对数据进行清洗（过滤异常数据）、整合（尽量将相关业务过程数据整合在一起，避免数据多次扫描）代码统一、字段命名统一、格式统一，将数据标准化，给后续处理提供干净、统一、标准的数据
DWS
汇总数据层（以具体分析需求建模，建设公共可复用的指标）；聚焦站在维度看事实表的度量值基于上层的应用及产品的指标需求，构建汇总指标表。宽表化处理（退化维度） 单主题建模
DM
应用集市层
DIM
维表层构建一致性维表，星型模型
开发规范
表命名规范
索引命名规范
分区命名规范
存储过程命名规范
调度任务/作业命名规范
文档规范
脚本开发规范
流程规范(需求准入准出机制)
指标命名规范
调度系统
Azkaban
DolphinScheduler
设计文档、模型、方案评审
开发及测试验收
开发及遇到问题风险跟进处理
SIT
UAT
CodeReview包括代码、文档、规范、上线内容评审...
效果跟进与问题复盘
出具数据流图
数据质量及元数据管理
数据质量
准确性
完整性
一致性
及时性
元数据
由于目前缺乏元数据管理系统。借助于Excel、PowerDesigner等工具辅助管理
数仓框架
离线
实时
Lambda 架构数据做Merge，流/批一体
Kappa 架构
0 条评论
下一页
为你推荐
查看更多
