数据仓库

数据建模

Inomn(三范式)一般用于OLTP系统中优点：规范化处理，降低数据冗余及解决数据一致性问题缺点：查询时需要许多表关联得出结果，降低查询性能          能力要求比较高，实施周期比较长

第一范式属性不可分割

第二范式不存在部分依赖【例如：A+B可以得出CB也可以得出C.那么存在部分依赖】

第三范式不存在传递依赖【例如：通过A可以得出B，然后通过B得出C】

星型模型

雪花模型

雪花较于星型更规范化处理

数仓优化

调度优化

耗时长的任务调度开始时间提前

业务比较关注的数据调度时间提前

调度任务剥离，不同项目的调度任务拆分

减少任务的依赖层级

模型优化

利用中间临时表，拆分复杂逻辑为多个块

整合表：重叠的表，将调度任务和数据合并

分区表：合理设计分区，部分大表增加二级子分区

索引：合理增加索引

中间表：数据量大、计算逻辑复杂

拆表：个别字段产出极慢的情况，可以将字段拆分为单独的表

合表：随着数仓的发展，针对业务重叠或重复的表，可以进行任务和数据合并

计算资源优化

查询时避免使用*，列出需要的字段

合理使用分区

注意数据倾斜

Hive

表分类

内部表(管理表)删除内部表会将元数据及存储的数据清空

外部表可以指定数据存储的位置；删除表只会将元数据删除，不会删除hdfs目录上的数据

分区查看表的所有分区：show partitions table

静态分区插入数据时需要指定具体的分区目录

动态分区

SET hive.exec.dynamic.partition=true;开启动态分区功能

hive.exec.dynamic.partition.mode=nonstrict;动态分区的模式；默认strictstrict模式表示必须指定至少一个分区为静态分区nonstrict模式表示允许所有的分区字段都可以使用动态分区

文件格式

TEXTFIEL数据不做压缩，磁盘开销大，数据解析开销大

RCFILE是一种行列存储相结合的存储方式。首先，其将数据按行分块，保证同一个record在一个块上，避免读一个记录需要读取多个block。其次，块数据列式存储，有利于数据压缩和快速的列存取

ORC(列式存储)是RCFILE的升级版，具有很高的压缩比节约HDFS的存储资源，提升查询性能

排序

全局排序Order By：只有一个Reducer

局部排序Sort By：对于同一个Reducer内部排序

分区排序Distribute By：结合Sort By使用；对Distribute By字段进行Hash之后的值分区，然后按Sort By字段排序

Cluster By如果Distribute By和Sort By字段一致是，可以直接使用Cluster By

优化

模型层面

分区优化

参数层面

列裁剪hive.optimize.cp=true

分区裁剪hive.optimize.pruner=true

合并小文件Map端文件输出合并：hive.merge.mapfiles=trueReduce 端文件输出合并：hive.merge.mapredfiles=true

合理控制 Map和Reduce的数量如果处理的文件很小，不比设置过多的任务。处理文件很小时，过多的任务数量的初始化时 \t间可能会比处理数据的时间长很多。另外，过多的任务数量会造成过多的小文件

语法层面

GroupBy优化

CountDistinct优化

Join优化

大表关联大表（注意热点值）

数据倾斜

关联表KEY值分布过于集中

大表关联空字段空值过多

GroupBy某值数量过多

CountDistinct

执行计划

数据仓库

需求梳理、调研

数据调研/业务背景调研

1、和不同的业务部门沟通了解业务情况，以及关注的重点

需求分析

1、和数据分析人员、业务人员沟通获知真实的数据需求，获取关注的指标信息2、分析梳理现有的报表系统，整理指标需求

指标梳理体系

1、原子指标=业务过程+度量【例如：放款金额】2、派生指标=原子指标+过滤条件【例如：北京市累计放款金额】3、衍生指标=原子指标+计算逻辑【例如：最近一周累计放款金额】

梳理每个业务过程涉及的维度，指标。确定命名规范维度，确定观察这个业务的角度；指标，衡量这个业务过程好坏的结果

---------1.原子指标---------SELECT SUM(A) FROM Z GROUP BY C;SELECT SUM(B) FROM Z GROUP BY C;---------2.派生指标---------SELECT SUM(A) AS SUM_A FROM Z WHERE D = 'X' GROUP BY C;SELECT SUM(B) AS SUM_B FROM Z WHERE D = 'X' AND E = 'Y' GROUP BY C;---------3.衍生指标---------SELECT SUM_A/SUM_B FROM TEMP;

数据探查发现

根据已梳理好指标体系梳理数据来源沟通确认指标业务口径、技术口径

确定不同指标涉及到的数据表输出mapping文档

确定每个表数据量大小，每天增量大小确定源表数据是否存在物理删除确定是否有增量时间戳

构建总线矩阵

梳理每个业务过程（注册、授信、申请、放款、回款、回购...）涉及的维度、涉及的源系统表及每个业务过程能产出哪些指标

设计阶段

模型设计性能、成本、存储、效率 综合考虑有效组织和存储统一算法口径避免重复计算取用方便

数仓分层

STG

缓冲层保存源系统抽取增量/全量数据

ODS

操作层与源系统结构保持一致，增加审计字段【数据加载时间，装载的数据日期】；保留历史数据，方便问题排查、历史数据回溯分析

DWD

明细层（基于业务过程建模），构建最细粒度的事实表，适当冗余维度属性字段（退化维度）对数据进行清洗（过滤异常数据）、整合（尽量将相关业务过程数据整合在一起，避免数据多次扫描）代码统一、字段命名统一、格式统一，将数据标准化，给后续处理提供干净、统一、标准的数据

DWS

汇总数据层（以具体分析需求建模，建设公共可复用的指标）；聚焦站在维度看事实表的度量值基于上层的应用及产品的指标需求，构建汇总指标表。宽表化处理（退化维度） 单主题建模

DM

应用集市层

DIM

维表层构建一致性维表，星型模型

开发规范

表命名规范

索引命名规范

分区命名规范

存储过程命名规范

调度任务/作业命名规范

文档规范

脚本开发规范

流程规范(需求准入准出机制)

指标命名规范

调度系统

Azkaban

介绍

DolphinScheduler

设计文档、模型、方案评审

开发及测试验收

开发及遇到问题风险跟进处理

SIT

UAT

CodeReview包括代码、文档、规范、上线内容评审...

效果跟进与问题复盘

出具数据流图

数据质量及元数据管理

数据质量

准确性

完整性

一致性

及时性

元数据

由于目前缺乏元数据管理系统。借助于Excel、PowerDesigner等工具辅助管理

数据质量保证三步走：事前：与各方(业务、IT等沟通确认指标数据口径)事中：做好SIT、UAT及CodeReview事后：从数据接入到数据消费，全链路配置校验规则

数仓框架

离线

实时

Lambda 架构数据做Merge，流/批一体

Kappa 架构

从性能、成本、效率、质量中平衡三范式建模：规范化建模，有效减少数据冗余，                    查询数据时需要关联的表比较多维度建模：便于开发，有一定的数据冗余，查询性能相对较高

1、风险监控及跟进管理2、测试验收文档输出3、QC问题跟进处理5、总结经验