耗时n年，38页《数据仓库知识体系，32岁的程序员被裁

原子数据集市保存着最低粒度的细节数据，数据以星型结构来进行数据存储。聚集数据集市的粒度通常比原子数据集市要高，和原子数据集市一样，聚集数据集市也是以星型结构来进行数据存储。前台还包括像查询管理、活动监控等为了提供数据仓库的性能和质量的服务。在多维体系结构中，所有的这些基于星型机构来建立的数据集市可以在物理上存在于一个数据库实例中，也可以分散在不同的机器上，而所有这些数据集市的集合组成的分布式的数据仓库。

2、一致性维度

在多维体系结构中，没有物理上的数据仓库，由物理上的数据集市组合成逻辑上的数据仓库。而且数据集市的建立是可以逐步完成的，最终组合在一起，成为一个数据仓库。如果分步建立数据集市的过程出现了问题，数据集市就会变成孤立的集市，不能组合成数据仓库，而一致性维度的提出正式为了解决这个问题。

一致性维度的范围是总线架构中的维度，即可能会在多个数据集市中都存在的维度，这个范围的选取需要架构师来决定。一致性维度的内容和普通维度并没有本质上区别，都是经过数据清洗和整合后的结果。 一致性维度建立的地点是多维体系结构的后台（Back Room），即数据准备区。

在多维体系结构的数据仓库项目组内需要有专门的维度设计师，他的职责就是建立维度和维护维度的一致性。在后台建立好的维度同步复制到各个数据集市。这样所有数据集市的这部分维度都是完全相同的。建立新的数据集市时，需要在后台进行一致性维度处理，根据情况来决定是否新增和修改一致性维度，然后同步复制到各个数据集市。这是不同数据集市维度保持一致的要点。

在同一个集市内，一致性维度的意思是两个维度如果有关系，要么就是完全一样的，要么就是一个维度在数学意义上是另一个维度的子集。

例如，如果建立月维度话，月维度的各种描述必须与日期维度中的完全一致，最常用的做法就是在日期维度上建立视图生成月维度。这样月维度就可以是日期维度的子集，在后续钻取等操作时可以保持一致。如果维度表中的数据量较大，出于效率的考虑，应该建立物化视图或者实际的物理表。这样，维度保持一致后，事实就可以保存在各个数据集市中。虽然在物理上是独立的，但在逻辑上由一致性维度使所有的数据集市是联系在一起，随时可以进行交叉探察等操作，也就组成了数据仓库。

3、一致性事实

在建立多个数据集市时，完成一致性维度的工作就已经完成了一致性的80%－90%的工作量。余下的工作就是建立一致性事实。一致性事实和一致性维度有些不同，一致性维度是由专人维护在后台（Back Room），发生修改时同步复制到每个数据集市，而事实表一般不会在多个数据集市间复制。需要查询多个数据集市中的事实时，一般通过交叉探查（drill across）来实现。

为了能在多个数据集市间进行交叉探查，一致性事实主要需要保证两点：**第一个是KPI的定义及计算方法要一致，第二个是事实的单位要一致性。**如果业务要求或事实上就不能保持一致的话，建议不同单位的事实分开建立字段保存。

这样，一致性维度将多个数据集市结合在一起，一致性事实保证不同数据集市间的事实数据可以交叉探查，一个分布式的数据仓库就建成了。

小遍有话

• 总线矩阵：业务过程和维度的交点；

• 一致性维度：同一集市的维度表，内容相同或包含；

• 一致性事实：不同集市的同一事实，需保证口径一致，单位统一。

追求一致性必然会增加开发工作量，但长期来说，使用方便、运维简单；一致性和性能之间，需要平衡。

五、数据仓库规范设计

1、为什么要进行规范设计

无规矩、不方圆。规范设计是在具体开发工作之前制定的，过程中不断进行完善。目的在于约束 N 个人对齐认知，按照一个标准或流程进行开发，以保证数据一致性，流程清晰且稳定。

一个良好的规范设计，应当起到以下作用：提高开发效率，提升质量，降低沟通对齐成本，降低运维成本等。

下面西红柿🍅将带领大家盘一盘数据仓库有哪些规范，从中挑选几个重点细说：

• 设计规范

逻辑架构、技术架构、分层设计、主题划分、方法论

• 命名规范

各层级命名、任务命名、表命名、字段命名、指标命名等

• 模型规范

建模方法、建模工具、血缘关系、维度退化、一致性维度、元数据管理

• 开发规范

脚本注释、字段别名、编码规范、脚本格式、数据类型、缩写规范

• 流程规范

需求流程、工程流程、上线流程、调度流、调度和表生命周期管理

2、设计规范 - 指标

• Step1**：面向主题域管理**

为了提高指标管理的效率，你需要按照业务线、主题域和业务过程三级目录方式管理指标。

• Step2**：划分原子指标和派生指标**

原子指标 + 原子指标  = 派生指标

• Step3**：进行指标命名规范**

需要遵循两个原则：易懂与统一

1. 易懂，就是看到指标的名称，就可以基本判断这个指标归属于哪个业务过程；

2. 统一，就是要确保派生指标和它继承的原子指标命名是一致的。

对于原子指标，标名称适合用“动作 + 度量”的命名方式（比如注册用户数、购买用户数）

对于派生指标，应该严格遵循“时间周期 + 统计粒度 + 修饰词 + 原子指标”的命名方式。（比如30天内黑卡会员购买用户数）

• Step4**：分级管理**

指标确实是多，如果一视同仁去管理其实很难，所以可以按照下面的原则进行等级划分：

1. 一级指标：数据中台直接产出，核心指标（提供给公司高层看的）、原子指标以及跨部门的派生指标。

2. 二级指标：基于中台提供的原子指标，业务部门创建的派生指标。

3、命名规范 - 表命名

3.1 常规表

常规表是我们需要固化的表，是正式使用的表，是目前一段时间内需要去维护去完善的表。

规范：分层前缀**[dwd|dws|ads|bi]_业务域_主题域_XXX_更新频率|全量/**增量。

业务域、主题域我们都可以用词根的方式枚举清楚，不断完善，粒度也是同样的，主要的是时间粒度、日、月、年、周等，使用词根定义好简称。

建议格式： dwd_xxx_xxx_da

• di ：每日增量

• da：每日全量

• mi：每月增量

• ma：每月全量

3.2 中间表

中间表一般出现在Job中，是Job中临时存储的中间数据的表，中间表的作用域只限于当前Job执行过程中，Job一旦执行完成，该中间表的使命就完成了，是可以删除的（按照自己公司的场景自由选择，以前公司会保留几天的中间表数据，用来排查问题）。

**建议格式：**mid_table_name_[0~9]

table_name是我们任务中目标表的名字，通常来说一个任务只有一个目标表。这里加上表名，是为了防止自由发挥的时候表名冲突，而末尾大家可以选择自由发挥，起一些有意义的名字，或者简单粗暴，使用数字代替，各有优劣吧，谨慎选择。

3.3 临时表

临时表是临时测试的表，是临时使用一次的表，就是暂时保存下数据看看，后续一般不再使用的表，是可以随时删除的表。

**建议格式：**tmp_xxx

只要加上tmp开头即可，其他名字随意，注意tmp开头的表不要用来实际使用，只是测试验证而已。

3.4 维度表

维度表是基于底层数据，抽象出来的描述类的表。维度表可以自动从底层表抽象出来，也可以手工来维护。

**建议格式：**dim_xxx

维度表，统一以dim开头，后面加上，对该指标的描述，可以自由发挥。

4、开发规范

5、流程规范

根据阿里流程规范，本文将数据仓库研发流程抽象为如下几点：

1. 需求阶段：数据产品经理应如何应对不断变化的业务需求。

2. 设计阶段：数据产品经理、数据开发者应如何综合性能、成本、效率、质量等因素，更好地组织与存储数据。

3. 开发阶段：数据研发者如何高效、规范地进行编码工作。

4. 测试阶段：测试人员应如何准确地暴露代码问题与项目风险，提升产出质量。

5. 发布阶段：如何将具备发布条件的程序平稳地发布到线上稳定产出。

6. 运维阶段：运维人员应如何保障数据产出的时效性和稳定性。

六、元数据管理

1、业务元数据

1. 描述 ”数据”背后的业务含义

2. 主题定义：每段 ETL、表背后的归属业务主题。

3. 业务描述：每段代码实现的具体业务逻辑。

4. 标准指标：类似于 BI 中的语义层、数仓中的一致性事实；将分析中的指标进行规范化。

5. 标准维度：同标准指标，对分析的各维度定义实现规范化、标准化。

6. 不断的进行维护且与业务方进行沟通确认。

2、技术元数据

• 数据源元数据

• 例如：数据源的 IP、端口、数据库类型；数据获取的方式；数据存储的结构；原数据各列的定义及 key 指对应的值。

• ETL 元数据

• 根据 ETL 目的的不同，可以分为两类：数据清洗元数据；数据处理元数据。

• 数据清洗，主要目的是为了解决掉脏数据及规范数据格式；因此此处元数据主要为：各表各列的"正确"数据规则；默认数据类型的"正确"规则。

• 数据处理，例如常见的表输入表输出；非结构化数据结构化；特殊字段的拆分等。源数据到数仓、数据集市层的各类规则。比如内容、清理、数据刷新规则。

• 数据仓库元数据

• 数据仓库结构的描述，包括仓库模式、视图、维、层次结构及数据集市的位置和内容；业务系统、数据仓库和数据集市的体系结构和模式等。

• BI 元数据

• 汇总用的算法、包括各类度量和维度定义算法。数据粒度、主题领域、聚集、汇总、预定义的查询与报告。

3、管理元数据

管理领域相关，包括管理流程、人员组织、角色职责等。

4、小编有话

在日常工作中，元数据的管理主要体现在元数据的采集、存储、查询、应用几个方面。原则上应从规范化，到脚本化，到工具化的方向进行建设。

• 采集：元数据采集时尽可能详细，真实，可通过工具生成或者勾选，避免手动录入带来不规范等问题

• 存储：存储元数据要做到不失真，元数据变更时及时同步

• 查询：通过网页或库表等方式，方便快捷的看到元数据，辅助进行开发

• 应用：数据血缘、优化调度依赖、数据治理等

七、维度表

1、什么是维度表

​维度是维度建模的基础和灵魂。在维度建模中，将度量称为“事实” ， 将环境描述为“维度”。

维度表包含了事实表中指定属性的相关详细信息，最常用的维度表有日期维度、城市维度等。

日期维表：

2、维度表设计原则

维度的作用一般是查询约束、分类汇总以及排序等，我们在进行维度表设计时，应当提前考虑：

（1）维度属性尽量丰富，为数据使用打下基础

比如淘宝商品维度有近百个维度属性，为下游的数据统计、分析、探查提供了良好的基础。

（2）给出详实的、富有意义的文字描述

属性不应该是编码，而应该是真正的文字。在间里巴巴维度建模中， 一般是编码和文字同时存在，比如商品维度中的商品 ID 和商品标题、 类目 ID 和 类目名称等。ID 一 般用于不同表之间的关联，而名称一般用 于报表标签

（3）区分数值型属性和事实

数值型宇段是作为事实还是维度属性，可以参考字段的一般用途。如果通常用于查询约束条件或分组统计，则是作为维度属性;如果通常 用于参与度量的计算， 则是作为事实。比如商品价格，可以用于查询约 束条件或统计价格区间 的商品数量，此时是作为维度属性使用的;也可 以用于统计某类目 下商品的平均价格，此时是作为事实使用的。另外， 如果数值型字段是离散值，则作为维度属性存在的可能性较大;如果数 值型宇段是连续值 ，则作为度量存在的可能性较大，但并不绝对，需要 同时参考宇段的具体用途。

（4）沉淀出通用的维度属性，为建立一致性维度做好铺垫

有些维度属性获取需要进行比较复杂的逻辑处理，有些需要通过多表关联得到，或者通过单表 的不同宇段混合处理得到，或者通过对单表 的某个字段进行解析得到。此时，需要将尽可能多的通用的维度属性进 行沉淀。一方 面，可以提高下游使用的方便性，减少复杂度;另一方面，可以避免下游使用解析时由于各自逻辑不同而导致口径不 一致。

（5）退化维度（Degenerate Dimension）

在维度类型中，有一种重要的维度称作为退化维度。这种维度指的是直接把一些简单的维度放在事实表中。退化维度是维度建模领域中的一个非常重要的概念，它对理解维度建模有着非常重要的作用，退化维度一般在分析中可以用来做分组使用。

（6）缓慢变化维（Slowly Changing Dimensions）

维度的属性并不是始终不变的，它会随着时间的流逝发生缓慢的变化，这种随时间发生变化的维度我们一般称之为缓慢变化维（SCD），缓慢变化维一般使用代理健作为维度表的主健。

推荐阅读**：**缓慢变化维度的10种处理方式****

缓慢变化维的三种常用处理方式：

① TYPE1 直接覆盖原值

适用于：不看历史数据，简单粗暴

② TYPE2 拉链表

需要在维度行再增加三列：有效日期、截止日期、行标识（可选）。

在旧的一行数据增加关链时间（end_date），新的一行数据增加开链时间和**关链时间，**多条数据加起来是一个完整的时间周期。

③ TYPE3 增加属性列

3、维度表设计方法

• 第一步：选择维度或新建维度。作为维度建模的核心，在企业级数 据仓库中必须保证维度的唯一性。以淘宝商品维度为例，有且只允许有 一个维度定义。

• 第二步：确定主维表。此处的主维表一般是 ODS 表，直接与业务 系统同步。以淘宝商品维度为例， s_auction_auctions 是与前台商品中心 系统同步的商品表，此表即是主维表。

• 第三步：确定相关维表。数据仓库是业务源系统的数据整合，不同业务系统或者同 一业务系统中的表之间存在 关联性。根据对业务的梳 理，确定哪些表和主维表存在关联关系，并选择其中的某些表用于生成维度属性。

• 第四步 ：确定维度属性 。本步骤主要 包括两个阶段，其中第 一 个阶 段是从主维表 中选择维度属性或生成新的维度属性;第 二个阶段是从相 关维表中选择维度属性或生成新 的维度属性。以淘宝商品维度为例，从 主维表 (s_auction_auctions)和类目、 SPU、卖家、店铺等相关维表中 选择维度属性或生成新 的维度属性。

八、三范式与反范式

范式是符合某一种级别的关系模式的集合。构造数据库必须遵循一定的规则。在关系数据库中，这种规则就是范式。

关系数据库中的关系必须满足一定的要求，即满足不同的范式。大数据生态中，各类强大的查询引擎层出不穷，相对廉价的磁盘和分布式技术，也让数据冗余变得可接受甚至更加方便。

在创建一个数据库的过程中，范化是将其转化为一些表的过程，这种方法可以使从数据库得到的结果更加明确。这样可能使数据库产生重复数据，从而导致创建多余的表。范化是在识别数据库中的数据元素、关系以及定义所需的表和各表中的项目等这些初始工作之后的一个细化的过程。

1、第一范式

1NF****要求属性具有原子性，即列不可再分解；

表：字段1、 字段2(字段2.1、字段2.2)、字段3 …

如学生（学号，姓名，性别，出生年月日）

有些钢筋可能要问西红柿了，姓名可以拆成姓、名两列， “出生年月日” 也可以拆成年、月、日三个字段。所以就不满足第一范式了！！！这里再强调一下原子性，原子性是根据使用方便来自定义的最小单位。中国人一般姓名一起用，美国就习惯姓名分别存两字段。

2、第二范式

2NF****要求记录有惟一标识，即不存在部分依赖；

简单来说就是拆表，以人为粒度做一张明细表，以课程号为粒度做一张维度表，两表关联使用，消除了数据冗余

表：学号、课程号、姓名、学分;

这个表明显说明了两个事务:学生信息, 课程信息;由于非主键字段必须依赖主键，这里学分依赖课程号，姓名依赖与学号，所以不符合二范式。

可能会存在问题：

• 数据冗余：每条记录都含有相同信息；

• 删除异常：删除所有学生成绩，就把课程信息全删除了；

• 插入异常：学生未选课，无法记录进数据库；

• 更新异常：调整课程学分，所有行都调整。

正确做法**😗*

学生：Student(学号, 姓名)；

课程：Course(课程号, 学分)；

选课关系：StudentCourse(学号, 课程号, 成绩)。

3、第三范式

3NF是对字段的冗余性，要求任何字段不能由其他字段派生出来，它要求字段没有冗余，即不存在传递依赖；

表: 学号, 姓名, 年龄, 学院名称, 学院电话

因为存在依赖传递: (学号) → (学生)→(所在学院) → (学院电话) 。

可能会存在问题：

• 数据冗余:有重复值；

• 更新异常：有重复的冗余信息，修改时需要同时修改多条记录，否则会出现数据不一致的情况 。

正确做法：

学生：(学号, 姓名, 年龄, 所在学院)；

学院：(学院, 电话)。

4、反范式化

一般说来，数据库只需满足第三范式（3NF）就行了。

没有冗余的数据库设计可以做到。但是，没有冗余的数据库未必是最好的数据库，有时为了提高运行效率，就必须降低范式标准，适当保留冗余数据。具体做法是：在概念数据模型设计时遵守第三范式，降低范式标准的工作放到物理数据模型设计时考虑。降低范式就是增加字段，允许冗余，达到以空间换时间的目的。

〖例〗：有一张存放商品的基本表，如表1所示。“金额”这个字段的存在，表明该表的设计不满足第三范式，因为“金额”可以由“单价”乘以“数量”得到，说明“金额”是冗余字段。但是，增加“金额”这个冗余字段，可以提高查询统计的速度，这就是以空间换时间的作法。

在Rose 2002中，规定列有两种类型：数据列和计算列。“金额”这样的列被称为“计算列”，而“单价”和“数量”这样的列被称为“数据列”。

5、范式化设计和反范式化设计的优缺点

5.1 范式化 （时间换空间）

优点：

• 范式化的表减少了数据冗余，数据表更新操作快、占用存储空间少。

缺点：

• 查询时需要对多个表进行关联，查询性能降低。

• 更难进行索引优化

5.2 反范式化（空间换时间）

反范式的过程就是通过冗余数据来提高查询性能，但冗余数据会牺牲数据一致性

优点：

• 可以减少表关联

• 可以更好进行索引优化

缺点：

• 存在大量冗余数据

• 数据维护成本更高（删除异常，插入异常，更新异常）

6、OLAP和OLTP中范式设计

OLAP 一般冗余比较多，以查询分析为主，这种一般都是采用反范式设计，以提高查询效率。更新一般是定时大批量数据插入。

OLTP 则是尽可能消除冗余，以提高变更的效率。因为这种应用无时无刻不在频繁变化。

九、数据仓库架构-Lambda和Kappa

随着数据量的暴增和数据实时性要求越来越高，以及大数据技术的发展驱动企业不断升级迭代，数据仓库架构方面也在不断演进，分别经历了以下过程：早期经典数仓架构 > 离线大数据架构 > Lambda > Kappa > 混合架构。

|

架构

|

组成

|

特点

|

| — | — | — |

|

经典数仓架构

|

关系型数据库（mysql、oracle）为主

|

数据量小，实时性要求低

|

|

离线大数据架构

|

hive，spark为主

|

数据量大，实时性要求低

|

|

Lambda

|

hive，spark负责存量，strom/Flink负责实时计算

|

数据量大，实时性要求高

|

|

Kappa

|

kafka、strom、Flink

|

多业务，多数据源，事件型数据源

|

|

混合架构

| | |

_ps._西红柿的举例若有不当，欢迎指正

1、Lambda架构原理

Lambda架构的核心思想是把大数据系统拆分成三层：Batch Layer，Speed Layer和Serving Layer。其中，Batch Layer负责数据集存储以及全量数据集的预查询。

Speed Layer主要负责对增量数据进行计算，生成Realtime Views。Serving Layer用于响应用户的查询请求，它将Batch Views和Realtime Views的结果进行合并，得到最后的结果，返回给用户，如下图：

2、Lambda架构的缺点

Lambda架构解决了大数据量下实时计算的问题，但架构本身也存在一定缺点。

• 实时与批量计算结果不一致引起的数据口径问题：因为批量和实时计算走的是两个计算框架和计算程序，算出的结果往往不同，经常看到一个数字当天看是一个数据，第二天看昨天的数据反而发生了变化。

• 批量计算在计算窗口内无法完成：在IOT时代，数据量级越来越大，经常发现夜间只有4、5个小时的时间窗口，已经无法完成白天20多个小时累计的数据，保证早上上班前准时出数据已成为每个大数据团队头疼的问题。

• 开发和维护的复杂性问题：Lambda 架构需要在两个不同的 API（application programming interface，应用程序编程接口）中对同样的业务逻辑进行两次编程：一次为批量计算的ETL系统，一次为流式计算的Streaming系统。针对同一个业务问题产生了两个代码库，各有不同的漏洞。这种系统实际上非常难维护

• 服务器存储大：数据仓库的典型设计，会产生大量的中间结果表，造成数据急速膨胀，加大服务器存储压力。

3、Kappa架构原理

Kappa****架构的核心思想包括以下三点：

• 用Kafka或者类似的分布式队列系统保存数据，你需要几天的数据量就保存几天。

• 当需要全量重新计算时，重新起一个流计算实例，从头开始读取数据进行处理，并输出到一个新的结果存储中。

• 当新的实例做完后，停止老的流计算实例，并把老的一些结果删除。

• 

• 在Kappa架构下，只有在有必要的时候才会对历史数据进行重复计算，并且实时计算和批处理过程使用的是同一份代码。

4、Lambda架构和Kappa架构优缺点对比

|

项目

|

Lambda

|

Kappa

|

| — | — | — |

|

数据处理能力

|

可以处理超大规模的历史数据

|

历史数据处理的能力有限

|

|

机器开销

|

批处理和实时计算需一直运行，机器开销大

|

必要时进行全量计算，机器开销相对较小

|

|

存储开销

|

只需要保存一份查询结果，存储开销较小

|

需要存储新老实例结果，存储开销相对较大

|

|

开发、测试难度

|

实现两套代码，开发、测试难度较大

|

只需面对一个框架，开发、测试难度相对较小

|

|

运维成本

|

维护两套系统，运维成本大

|

只需维护一个框架，运维成本小

|

5、数据架构评价标准

• 响应速度：数据架构的主要场景包括：业务开发、数据产品、运营分析三大类，不论是那种场景，数据架构均应该在尽可能短的时间内响应需求；

• 可复用性：只有复用能力上来了，响应速度才能提上来，体现在下游依赖、调用次数、核心字段覆盖率等指标上；

• 稳定性：除了日常任务不出问题以外，一旦发现了问题，能在多短的时间内定位和恢复问题，就非常重要；

• 健壮性：除了电商等已经耕耘多年的领域外，绝大多数业务模型，都会快速的变化，如何适应这种变化，就非常考验架构功底。

6、小编有话

• Lambda 将全量历史数据和实时增量数据合并输出。

• Kappa 两个流协作输出，queries每次使用最新一个流处理结果

目前很多准实时增量批处理方案也能满足实时性需求，从稳定性和运维成本上也表现更佳。

比如kudu（存储）+impala（计算）准实时方案，可以实现千万级数据的增量更新和olap查询，性能优异。

十、数据治理（目的、方法、流程）

1、什么是数据治理

**数据治理（Data Governance）是组织中涉及数据使用的一整套管理行为。**由企业数据治理部门发起并推行，关于如何制定和实施针对整个企业内部数据的商业应用和技术管理的一系列政策和流程。

数据的质量直接影响着数据的价值，并且直接影响着数据分析的结果以及我们以此做出的决策的质量。

我们常说，用数据说话，用数据支撑决策管理，但低质量的数据、甚至存在错误的数据，必然会"说假话"！！！数据治理即提高数据的质量，发挥数据资产价值。

2、数据治理的目的

• 降低风险

• 建立数据使用内部规则

• 实施合规要求

• 改善内部和外部沟通

• 增加数据价值

• 方便数据管理

• 降低成本

• 通过风险管理和优化来帮助确保公司的持续生存

3、数据治理的方法

从技术实施角度看，数据治理包含**“理”“采”“存”“管”“用”**这五个步骤，即业务和数据资源梳理、数据采集清洗、数据库设计和存储、数据管理、数据使用。

数据资源梳理：数据治理的第一个步骤是从业务的视角厘清组织的数据资源环境和数据资源清单，包含组织机构、业务事项、信息系统，以及以数据库、网页、文件和 API 接口形式存在的数据项资源，本步骤的输出物为分门别类的数据资源清单。

数据采集清洗：通过可视化的 ETL 工具（例如阿里的 DataX，Pentaho Data Integration）将数据从来源端经过抽取 (extract)、转换 (transform)、加载 (load) 至目的端的过程，目的是将散落和零乱的数据集中存储起来。

基础库主题库建设：一般情况下，可以将数据分为基础数据、业务主题数据和分析数据。基础数据一般指的是核心实体数据，或称主数据，例如智慧城市中的人口、法人、地理信息、信用、电子证照等数据。主题数据一般指的是某个业务主题数据，例如市场监督管理局的食品监管、质量监督检查、企业综合监管等数据。而分析数据指的是基于业务主题数据综合分析而得的分析结果数据，例如市场监督管理局的企业综合评价、产业区域分布、高危企业分布等。那么基础库和主题库的建设就是在对业务理解的基础上，基于易存储、易管理、易使用的原则抽像数据存储结构，说白了，就是基于一定的原则设计数据库表结构，然后再根据数据资源清单设计数据采集清洗流程，将整洁干净的数据存储到数据库或数据仓库中。

元数据管理：元数据管理是对基础库和主题库中的数据项属性的管理，同时，将数据项的业务含义与数据项进行了关联，便于业务人员也能够理解数据库中的数据字段含义，并且，元数据是后面提到的自动化数据共享、数据交换和商业智能（BI）的基础。需要注意的是，元数据管理一般是对基础库和主题库中（即核心数据资产）的数据项属性的管理，而数据资源清单是对各类数据来源的数据项的管理。

血缘追踪：数据被业务场景使用时，发现数据错误，数据治理团队需要快速定位数据来源，修复数据错误。那么数据治理团队需要知道业务团队的数据来自于哪个核心库，核心库的数据又来自于哪个数据源头。我们的实践是在元数据和数据资源清单之间建立关联关系，且业务团队使用的数据项由元数据组合配置而来，这样，就建立了数据使用场景与数据源头之间的血缘关系。数据资源目录：数据资源目录一般应用于数据共享的场景，例如政府部门之间的数据共享，数据资源目录是基于业务场景和行业规范而创建，同时依托于元数据和基础库主题而实现自动化的数据申请和使用。

质量管理：数据价值的成功发掘必须依托于高质量的数据，唯有准确、完整、一致的数据才有使用价值。因此，需要从多维度来分析数据的质量，例如：偏移量、非空检查、值域检查、规范性检查、重复性检查、关联关系检查、离群值检查、波动检查等等。需要注意的是，优秀的数据质量模型的设计必须依赖于对业务的深刻理解，在技术上也推荐使用大数据相关技术来保障检测性能和降低对业务系统的性能影响，例如 Hadoop，MapReduce，HBase 等。

商业智能（BI）：数据治理的目的是使用，对于一个大型的数据仓库来说，数据使用的场景和需求是多变的，那么可以使用 BI 类的产品快速获取需要的数据，并分析形成报表，比较知名的产品有 Microsoft Power BI，QlikView，Tableau，帆软等。

数据共享交换：数据共享包括组织内部和组织之间的数据共享，共享方式也分为库表、文件和 API 接口三种共享方式，库表共享比较直接粗暴，文件共享方式通过 ETL 工具做一个反向的数据交换也就可以实现。我们比较推荐的是 API 接口共享方式，在这种方式下，能够让中心数据仓库保留数据所有权，把数据使用权通过 API 接口的形式进行了转移。API 接口共享可以使用 API 网关实现，常见的功能是自动化的接口生成、申请审核、限流、限并发、多用户隔离、调用统计、调用审计、黑白名单、调用监控、质量监控等等。

4、数据质量8个衡量标准

• 数据的准确性

数据采集值或者观测值和真实值之间的接近程度，也叫做误差值，误差越大，准确度越低。

• 数据的精确性

指对同一对象的观测数据在重复测量时所得到不同数据间的接近程度。

• 数据的真实性

• 数据的及时性

数据能否在需要的时候得到保证，比如月初的财务对账，能不能在月初就完成

• 数据的即时性

指数据采集时间节点和数据传输的时间节点，一个数据在数据源头采集后立即存储，并立即加工呈现，就是即时数据，而经过一段时间之后再传输到信息系统中，则数据即时性就稍差。

• 数据的完整性

应采集和实际采集到数据之间的比例。

• 数据的全面性

完整性衡量的是应采集和实际采集的差异。而全面性指的是数据采集点的遗漏情况。

• 数据的关联性

指各个数据集之间的关联关系。比如员工工资数据和员工绩效考核数据是通过员工这个资源关联在一起来的。

信息技术智库关注领取技术资料、面试真题、简历模板和PPT模板；一起交流工作难题、面试套路、职场经验、内推直通车公众号

5、数据治理流程

基本流程**：发现数据质量问题** > 定义数据质量规则 > 质量控制 > 质量评估 > 质量优化

十一、ETL

1、什么是ETL

ETL，是英文Extract-Transform-Load的缩写，用来描述将数据从来源端经过抽取（extract）、转换（transform）、加载（load）至目的端的过程，是数据仓库的生命线。

**抽取（Extract）**主要是针对各个业务系统及不同服务器的分散数据，充分理解数据定义后，规划需要的数据源及数据定义，制定可操作的数据源，制定增量抽取和缓慢渐变的规则。

**转换（transform）**主要是针对数据仓库建立的模型，通过一系列的转换来实现将数据从业务模型到分析模型，通过ETL工具可视化拖拽操作可以直接使用标准的内置代码片段功能、自定义脚本、函数、存储过程以及其他的扩展方式，实现了各种复杂的转换，并且支持自动分析日志，清楚的监控数据转换的状态并优化分析模型。

**装载（Load）**主要是将经过转换的数据装载到数据仓库里面，可以通过直连数据库的方式来进行数据装载，可以充分体现高效性。在应用的时候可以随时调整数据抽取工作的运行方式，可以灵活的集成到其他管理系统中。

2、ETL & ELT

伴随着数据仓库的发展（传送门：数据仓库的八个发展阶段），数据量从小到大，数据实时性从T+1到准实时、实时，ETL也在不断演进。

• 在传统数仓中，数据量小，计算逻辑相对简单，我们可以直接用ETL工具实现数据转换（T），转换之后再加载到目标库，即（Extract-Transform-Load）。

• 但在大数据场景下，数据量越大越大，计算逻辑愈发复杂，数据清洗需放在运算能力更强的分布式计算引擎中完成，ETL也就变成了ELT（Extract-Load-Transform）。

**即：**Extract-Transform-Load  >>  Extract-Load-Transform

通常我们所说的ETL，已经泛指数据同步、数据清洗全过程，而不仅限于数据的抽取-转换-加载。

3、常用的ETL工具

下面小编将介绍几类ETL工具（sqoop，DataX，Kettle，canal，StreamSets）。

3.1 sqoop

• 是Apache开源的一款在Hadoop和关系数据库服务器之间传输数据的工具。

• 可以将一个关系型数据库（MySQL ,Oracle等）中的数据导入到Hadoop的HDFS中，也可以将HDFS的数据导出到关系型数据库中。

• sqoop命令的本质是转化为MapReduce程序。

• sqoop分为导入（import）和导出（export），

• 策略分为table和query

• 模式分为增量和全量。

3.2 DataX

最后

🍅 硬核资料：关注即可领取PPT模板、简历模板、行业经典书籍PDF。
🍅 技术互助：技术群大佬指点迷津，你的问题可能不是问题，求资源在群里喊一声。
🍅 面试题库：由技术群里的小伙伴们共同投稿，热乎的大厂面试真题，持续更新中。
🍅 知识体系：含编程语言、算法、大数据生态圈组件（Mysql、Hive、Spark、Flink）、数据仓库、Python、前端等等。

小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。

深知大多数初中级Python工程师，想要提升技能，往往是自己摸索成长或者是报班学习，但自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年Python爬虫全套学习资料》送给大家，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。

由于文件比较大，这里只是将部分目录截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频

如果你觉得这些内容对你有帮助，可以添加下面V无偿领取！（备注：python）

步、数据清洗全过程，而不仅限于数据的抽取-转换-加载。

3、常用的ETL工具

下面小编将介绍几类ETL工具（sqoop，DataX，Kettle，canal，StreamSets）。

3.1 sqoop

• 是Apache开源的一款在Hadoop和关系数据库服务器之间传输数据的工具。

• 可以将一个关系型数据库（MySQL ,Oracle等）中的数据导入到Hadoop的HDFS中，也可以将HDFS的数据导出到关系型数据库中。

• sqoop命令的本质是转化为MapReduce程序。

• sqoop分为导入（import）和导出（export），

• 策略分为table和query

• 模式分为增量和全量。

3.2 DataX

最后

🍅 硬核资料：关注即可领取PPT模板、简历模板、行业经典书籍PDF。
🍅 技术互助：技术群大佬指点迷津，你的问题可能不是问题，求资源在群里喊一声。
🍅 面试题库：由技术群里的小伙伴们共同投稿，热乎的大厂面试真题，持续更新中。
🍅 知识体系：含编程语言、算法、大数据生态圈组件（Mysql、Hive、Spark、Flink）、数据仓库、Python、前端等等。

小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。

深知大多数初中级Python工程师，想要提升技能，往往是自己摸索成长或者是报班学习，但自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年Python爬虫全套学习资料》送给大家，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。

由于文件比较大，这里只是将部分目录截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频

如果你觉得这些内容对你有帮助，可以添加下面V无偿领取！（备注：python）
[外链图片转存中…(img-G21r0dCA-1711025728503)]文章来源地址https://www.toymoban.com/news/detail-844765.html

到了这里，关于耗时n年，38页《数据仓库知识体系，32岁的程序员被裁的文章就介绍完了。如果您还想了解更多内容，请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章，希望大家以后多多支持TOY模板网！