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