数据仓库体系思维导图模板_ProcessOn思维导图、流程图

数据应用

用户画像

数据分析平台

自主取数平台

推荐系统

个性化推送

ABtest

精细化运营

其他

数仓任务及时输出

模型层面

模型设计

开发规范

设计原则

模型新增&迭代

模型新增

试运行后上线

模型迭代

试运行后上线

评估对下游任务的影响

模型优化

sql调优

事实表维表拆分整合

模型优先级

设置优先级

合理评估优先级

调度层面

调度系统

调度系统调度不起来任务

运行成功的状态一直不改变，下游无法运行

任务调度配置

没有配置依赖

任务互相依赖

大数据运维层面

资源

计算

存储

组件故障

监控层面

数据质量监控

数据量

唯一性

指标波动

任务延迟未产生出监控

晚点时间设置

人工介入

值班层面

人员安排

告警机制

问题处理机制

责任划分

延迟故障等级报告

实时数仓

数据仓库特点

特点

面向主题

集成性

稳定性

意义

建立公司同一数据中心

为数据BP，运营人员提供数据支持

为领导提供决策支持

与数据库对比

面向内容

数据库

事物

数据仓库

主题

分析

数据存储

数据库

当前最新数据

数据仓库

历史数据

模型建设

数据库

三范式

数据仓库

星型模型

数据仓库建设

架构选项

数据集市

早期数据集市

容易出现数据不一致情况，且无法水平对比

基于搭建好的企业级数据仓库，从属数据集市

inmon架构--三范式建模

inmon架构的数据仓库存储的是最细粒度的数据

inmon架构的数据仓库是符合三范式的

inmon架构的数据只能从数据集市获取，不能跨过数据集市直接从企业级数据仓库中获取

Kimball架构--维度建模

表区分

事实表

分类

事物事实表

定义

事物事实表保留的是最原始的数据，所以其实也叫原子事实表

举例

比如下单，支付，发货等这些业务过程构建的一类事实表，由于是最细粒度的数据，所以我们可以根据这些数据做各种各样的分析。

特性

多种方式表达粒度

稀疏

当天发生才会有数据

事实完全可加

插入

可以每日分区保留当天数据或全量快照表

周期快照事实表

定义

周期快照事实表的粒度和事物事实表不太一样，一般以维度属性进行声明，然后结合时间间隔

举例

比如历史到现在的订单量，昨天的好评数等，昨天浙江的支付总金额等，时间间隔不是固定不变的，可以是每天，每月，每周，近7天，近15天等。

特性

维度+周期声明粒度

粘稠（重要特性）

当天未发生，但是历史至今发生过，也会记录

至少一个半可加事实

比如近7天的销售额不能相加，但是可以算一下平均值

插入

每日分区保留当天统计的该周期内的数据，之后不再修改，除非口径变动

累积快照实时表

定义

累积快照事实表，讲需要分析的各个业务过程的事实放到一个表中进行分析

举例

比如：下单，支付，发货，签收等，我们会把这四个业务过程的事实放入到事实表中（包括每个过程发生的时间）

特性

多种表达粒度

事实完全可加

维度退化

数据探查，数据分析

插入与更新

每天保留全量数据-全量快照表

子主题

维度表

维表设计步骤

选择维度

指的是，我们的事实表需要关联哪些维度，比如健身房的私教课事实表，我们可能需要确定教练维度

确定主维度

选择了教练维度，我们就要确认教练维度的主维表了，这种情况一般是业务库抽过来的教练基本信息表。

确定关联维表

这个也不一定有，有的话就需要关联一下，比如教练的课时安排等

确定维度属性

这个就比较重要了，涉及到我们最终的维表的属性值，这个不需要自己进行权衡，可能需要与业务方，需求方进行沟通，防止近期可预见的属性值缺失，到时候后期在进行迭代。

维度设计的建议

1、尽可能多给出一些维度属性，避免后期频繁迭代

2、尽量描述的文字也给出，比如商品id，商品名称等

3、区分数字类型的属性，如单价

4、沉淀出通用的维度属性，一般指不能直接获取，需要我们后期加工的属性，减少在使用过程中的重复开发或者维度不一致的情况，比如当前是否vip

主键设计

代理键

自然键

缓慢变化维SCD

属性值不变

啥也不用改，就用历史的维度属性值
这种方案一般情况下都不会用吧，目前我还没想到那种场景用得上。

举例

事实表：你的LOL每局比赛
维表：你的账户基本信息表，里面包含段位，金币等

你3-7月份是白银，8月份升了黄金，但是你的维表属性没有改，还是使用的白银，你会乐意吗？

重写维度属性值

只能反映最新情况，无法保留维度属性的历史值，对于历史变化，这种方案是无法实现的。

举例

事实表：你的LOL每局比赛
维表：你的账户基本信息表，里面包含段位，金币等

你3-7月份是白银，8月份升了黄金，但是你的维表属性直接改成了黄金，我们会发现，如果我们想在白银阶段打了多少把，哦吼，好像统计不了

拉链表

熟悉拉链表的同学应该都知道，拉链表是目前最合适的方案之一，不论是历史熟悉还是最新属性，都给你安排的明明白白的

增加维度行

这种方式的弊端就是不能把不同时间的事实归为历史属性或者最新属性，业务场景有限，只能历史的归历史，新的关联新的

举例

事实表：你的LOL每局比赛
维表：你的账户基本信息表，里面包含段位，金币等

你3-7月份是白银，8月份升了黄金，在账户维表里面新增一列新的行，存储新的属性值，我们历史数据可以和之前的行匹配，新数据可以和新的行匹配，但是你想把所有的LOL比赛全部归属到黄金段位，不好意思，办不到

增加新属性

不常用，也不知道到底增加多少列，简直是个无底洞，会伤及无辜

举例

事实表：你的LOL每局比赛
维表：你的账户基本信息表，里面包含段位，金币等

你3-7月份是白银，8月份升了黄金，加一个属性字段
9月份升了铂金，又加一个字段？

10月份升了钻石，又加一个字段？

全量快照

啥也不用改，每天保留一份全量快照表，想怎么使用都行，这种方式最简单最容易理解了，唯一缺点就是存储成本比较高。

举例

事实表：你的LOL每局比赛
维表：你的账户基本信息表，里面包含段位，金币等

你3-7月份是白银，8月份升了黄金，不管你怎么变化，我每天存的全量快照表，用当天的事实匹配当天的维表属性。

维表的拆分与整合

整合

垂直整合

选择一个主维度表，把其他相关的维度表属性关联上去，可以丰富主维表的维度属性，方便使用，减少关联

水平整合

把具有相同维度属性的相关表可以整合到一张表中，发那个吧管理使用

拆分

垂直拆分

定义

为什么需要垂直拆分呢，由于维度各属性的产出时间，热度，访问频率不一样，也有维度经常变化，有些基本不会变动，所以在这种情况下，为了使维表最优化，我们应该做一些垂直拆分的工作。

场景再现

1、不常用属性1，不常用属性2访问频率非常低，一年难得访问一次
2、当前是否会员属性，来自于爬虫属性，爬虫每天上午7点才产出数据，该维表整体产出时间需要到8点30分，所有核心报表延迟
3、当天是否活跃属性变化频率非常高

水平拆分

为什么需要水平拆分呢，可能由于历史原因，把不同产品下的相同维度强制性合并到同一张表里面了，但是后来发现这张表并不太好用，业务相关性也并不大，而且由于某个产品的维度经常性改变，导致该表频繁迭代，稳定性很差，直接影响了其他业务

数据集市

虚拟数据集市，无实际存储

按照主题域划分

架构

星型模型

事实表周围都是一级维表

特点

星型模型不需要多次join，减少查询时间，提升查询性能

星型模型存储数据有冗余，浪费存储，不过也是可以空间换时间的表现

雪花模型

事实表周围存在一级与二级维表

星座模型

事实表与事实表以维表相关联

特点

存储的数据有粗粒度的，也有细粒度的

数据仓库可以直接对外提供数据

不存在真是数据集市，存在虚拟数据集市，按主题域进行划分

以需求为导向，自下而上进行开发建设

混合架构

开发大体流程

需求分析调研

明确口径，评估排期，需求正规流程提交

数据探查

数据字段能否满足需求

了解数据表字段能不能满足需求，看看字段有没有少，如果发现少了或者提供的数据源没法满足需求，需要及时找对应的人员沟通，可别自己瞎搞或者跑路了

表的数据结构

看下表的数据结构，有没有json数据或者其他比较复杂的数据，便于数仓处理

表的数据内容（数据质量）

看下数据内容，看看有些字段是不是毫无意义，不需要存储在数仓，或者看下是不是有很多空值的情况，脏数据情况，其实就是探查一下业务库的数据质量，通过这些我们可以大概判断在数仓有多少的清洗机制

表数据量

看一下数据量，方便我们抽取的时候选择增量抽取或者全量抽取，甚至可以问一下业务方业务增长情况，更能准确的决定数据抽取策略

指标管理

完善指标命名规范，指标同名同义，指标与业务强相关，明确指标构成要素

模型设计

完善开发流程规范，标准化业务调研，知识库文档集中管理，建立模型评审机制

etl开发

ODS->DWD->DWS->ADS

数据验证

制定数据测试标准

任务调度

规范化调度参数配置

线上管理

开发详细流程及规范文档

清洗规范

单位

比如额度单位统一为元/美元/分/美分

字段类型

如平台id，统一为int或者String，避免出现两个不同的表定义不同的类型
product_id，统一定义为string，不要出现a表定义为string，b表定义为bigint

注释

对没有注释的字段，需要及时补全
新建表的时候，一定要带上注释

时间格式

如2020-10-16，2020/10/16,20201016统一格式为20201016

枚举值

A表 1:男 2:女
B表 0:男 1:女
统一为: 1:男 2:女

数据脱敏

比如身份证号，手机号，邮箱等需要用加密函数进行脱敏

空值替换

string

-99

int/bigint/double/decimal

0

date

1700-01-01

datetime

1700-01-01 00:00:00

数据同步

业务数据

t+1

工具

datax

多chanal，适用于所谓数据平台组件

sqoop

分布式

同步策略

增量同步

基本条件

主键唯一

存在更新时间字段

不存在物理删除情况

参考方向

参考目前的数据量

考虑之后的业务发展情况

阈值设定

最基本的应该是要设定阈值，如50w

全量同步

数据量小且业务量增长缓慢的表

一般小维表

实时

canal+kafka

flink cdc

日志数据

工具

flume

logstash

数据质量保证

对于业务数据，不太注重数据质量，当然能保证的我们尽量也保证一下

爬虫数据

Python

数仓分层

分层规范

贴源层

ods

贴源层，与业务保持一致，不做任何处理

公共层

dwd

清洗、建模、输出主题宽表

dws

已分析的主题对象作为建模驱动，基于上层的应用和产品指标需求，构建公共粒度的汇总指标事实表，以宽表化手段物理化模型。构建命名规范，口径一致的统计指标，为上层提供公共指标，建立汇总宽表，明细事实表

dim

基于维度建模理念思想，建立企业一致性维度。降低数据计算口径和算法不统一风险。公共维度层的表通常也被称为逻辑维度表，维度和维度逻辑表通常一一对应。

应用层

ads

数据应用层ADS（Application Data Service）:面向业务需求定制开发，存放数据产品个性化的统计指标数据

分层好处

清晰的数据结构

每一个数据分层都有他的数据域，这样我们在使用表的时候能更方便的定位和理解。

数据血缘追踪

简单来讲可以这样理解，我们最终给业务呈现的是一张能直接使用的业务表，但是他来源有很多，如果有一张来源表出问题了，我们希望能快速准确地定位到问题，并清楚他的危害范围。

减少重复开发

规范数据分层，开发一些通用的中间层数据，能够减少极大的重复计算

把复杂问题简单化

讲一个复杂的任务分解成多个步骤来完成，每一层只处理单一的步骤，比较简单和容易理解。而且便于维护数据的准确性，当数据出现问题后，可以不用修复所有的数据，只需要从有问题的步骤开始修复。

数据流向

正常流向：ODS->DWD>DWS->ADS,当出现ODS->DWD>DWS->ADS这种关系时，说明主题域未覆盖全，对于使用频率非常低的表允许ODS->DWS

尽量避免出现dws宽表中使用ODS又使用（该ODS所归属主题域）DWD的表。

同一主题域内对于DWD生成DWD的表，原则上尽量避免，否则会影响ETL的效率。

DWS和ADS中禁止直接使用ODS的表，ODS的表只能被DWD引用

禁止出现反向依赖，例如DWD的表依赖DWS的表

主题域/数据域划分规范

主题域

数据域

词根规范

行业术语（一般指翻译不太准的）

数据分析师协作

业务方协作

词根评审

是否必要

是否存在

词根维护

id

英文词根

中文词根

使用频率

责任人

评审日期

建模评审规范

指导理论

数据模型的维度设计主要以维度建模理论为基础，基于维度数据模型总线架构，构建一致性维度和事实。参考阿里onedata建模

建模层次

参考数仓分层

实施步骤

选择已经确定业务进行梳理，了解业务流程（参考产品数据文档）

ER关系：输出ER关系图，了解实体关系，验证数据是否一致 PDM

现有数据流梳理：输出流程图 PDM

结合提数模型，指标，产品需求文档等，优化目前模型：基于上一步PDM输出优化模型，记录优化点：（数据流跟数据模型结合）

基于以上文档进行评审，不通过进行迭代

评审通过后进行开发，上线：开发在目前系统上实施，优先级降低，任务时间错开

开发规范

开发原则

支持重跑

数据生命周期合理

任务迭代不会严重影响任务产出时间

命名规范

表命名

任务命名

sql编写规范

多表连接时，使用表的别名来引用例。如t1.user_id t2.user_name

表明前需要加上项目名，一个是比较清晰，另一个是如果需要把该任务整段代码移到其他项目去跑的时候（比如分析查询项目），需要手动加上项目名，否则会报错

不要出现select * from 这样的操作

数据治理

数据质量管理

评估难度

完整性

一致性

关联性

及时性

真实性

准确性

唯一性

实施流程

事前

数据探查

梳理表字段

制定资产等级

制定检验规则

事中

数据量稽核

非空性稽核

唯一性稽核

指标波动稽核

异常告警

事后

全量稽核

数据质量模型设计

表评分算法

数据质量管理系统报表查询

数据成本治理

成本治理缘由

减少企业成本

目前存在的问题

机器利用率低

存储周期长，存储资源增长过快

成本没有量化标准

降本意识薄弱

任务优化空间非常大，尤其是离线计算

解决方案

延迟启动

任务下线

任务调优

修改执行周期

账单排名，促进优化

治理效果分析

总览

按照责任人

按照业务线

明细分析

数据安全

数据脱敏

数据权限控制

程序检查

流程化操作

敏感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层表的比例太高，则该模型不是最优，可以继续优化