数据仓库体系内容梳理

一、图解分层

二、数据仓库体系

2.1 数仓建模方法

2.1.1 范式建模(Normal form modeling)

解决：范式建模初衷即为解决插入异常，更新异常，删除异常

2.1.1.1 第一范式(1NF)

定义：符合1NF的关系中的每一个属性都不可再拆分

案例：

[表1]

[表2]

表1，进货项和销售项还可以进行拆分为数量和单价，不符合1NF属性。表2符合1NF。在1NF要求下，还需要保证每列不可有重复数值

3种问题解决：以下面一个案例说明

1.插入异常。如果学校建了新系，但还没有招生，这个系就不能被插入数据表里

2.更新异常。如果Akon转系了，那在上表中需要更改两行：院系&课程记录

3.删除异常。如果所有学生记录被删除，院系记录和课程也就不复存在了

2.1.1.2 第二范式(2NF)

定义：属性完全依赖主键，无论有多少个主键，非主键属性都完全依赖全部主键。

案例：表A中有主键a1，a2，非主键属性b1，b2，b3，b4等，非主键属性b1～bn完全依赖于a1和a2，类似这样的就符合2NF，反之则不符合。

3种异常解决：

【学号+课程号】 一起可以确定任何一条分数或是学号或是教师，所以 【学号+课程号】 就是本表的候选键。 一张表可以有多个键（key），一般我们会选择其中一个作为主键。 这个时候我们可以看到，教师这一属性其实只由课程号决定，而课程号只是 候选键 的一部分，因此这时我们就说，教师属性存在部分函数依赖。

那么我们要怎样移除部分函数依赖呢。 答案是拆表。 拆表的步骤如下

1.先找出所有的非主属性（不是主键也不是候选键包含部分的属性），在这个例子里，键为【学号+课程号】，那么他俩为主属性，剩下的都是非主属性

2.检查这些非主属性是否存在部分函数依赖。【姓名】只依赖于【学号】，存在；【分数】非得要【学号+课程号】一起才能确定，不存在；【教师】只依赖于【课程】号，存在

将这些存在部分函数依赖的属性分出去建立满足2NF的新表，切分方法并不唯一， 在这里可以这么分

分数表去掉 【姓名】 和 【教师】 属性：

为 姓名 建立学生表：

为 教师 建立 课程表：

这个时候我们再回头检查一下上面提到的三种异常。

1.插入异常。招新生的话，学生信息可以单独插入，有改进。

2.更新异常。如果L1号课换老师了，只用修改一次，有改进。

3.删除异常。如果删除所有的学生信息，教师信息还在，分数信息也还在；但是如果我从教师表里删掉课程L1的记录，教师Mr.x以及CS院系信息就不复存在了，这是个大问题。

4.数据冗余变少了么？少了。

我们会发现仍然有些问题存在，尤其是删除异常。

2.1.1.3 第三范式（3NF）

定义：第三范式在2NF的基础上，要求不存在任何传递依赖（Transitive dependency）

什么事传递依赖：以上2NF表说明：如果删除教师表里课程L1的信息，教师Mr.x以及CS院系信息就不复存在了，同时，如果一名新来的教师还没有被分配到任何课，他就不能被加入到教师表里。 这是因为，在教师表里： 1.课程号可以决定教师. A → B 2.教师不能决定课程号，因为一个教师可以教多门课. B not→ A 3.教师决定院系，因为一个教师只能属于一个院系. B → C 非主属性 【院系】，也依赖于另一个非主属性 【教师】，这种情况就叫做传递依赖。

3NF：就是要去除这种传递依赖。 解决方法有多种，这里可以将院系信息分表。

课程表只有课程号和教师信息：

而教师表 只有教师和院系信息：

这样我们再检查上面的问题， 删除L1课程信息，Mr.X老师的信息仍然保存的很好，有改进。 新老师Mr.Z可以被插入教师表，哪怕他还没有被分配任何课程。

2.1.1.4 Boyce-Codd范式（BCNF）

定义： 一个满足BCNF的关系模式的条件: 1.所有非主属性对每一个主码都是完全函数依赖。 2.所有的主属性对每一个不包含它的码,也是完全函数依赖。 3.没有任何属性完全函数依赖于非码的任何一组属性。

案例： 数据库中有如下一张表（其中主键为 仓库名 和 物品名 的组合，同时 管理员 和 物品名 的组合是候选键 ）

上表： 管理员的名字可以决定仓库名，那么这个候选键中的主属性就影响到主键中的属性了。 主键中的主属性对于候选键是部分依赖关系，这可能导致插入、删除和更新数据时产生异常。 因此，应该把这张表拆分成如下两张表： 所以需要改成两种表： 第一张：仓库名，管理员

第二张：仓库名，物品名，数量

2.1.1.5 第四范式（4NF）

定义： 限制关系模式的属性之间不允许有非平凡且非函数依赖的多值依赖。

理解： 显然一个关系模式是4NF，则必为BCNF。也就是说，当一个表中的非主属性互相独立时（3NF），这些非主属性不应该有多值，若有多值就违反了4NF。

2.1.1.6 第五范式（5NF）

第五范式有以下要求：

（1）必须满足第四范式；

（2）表必须可以分解为较小的表，除非那些表在逻辑上拥有与原始表相同的主键。

第五范式是在第四范式的基础上做的进一步规范化。第四范式处理的是相互独立的多值情况，而第五范式则处理相互依赖的多值情况。

2.1.1.7 反范式化建模

理解：反范式是一种对范式化设计的数据库的性能优化策略，通过在表中增加冗余或重复的数据来提供数据库的读取性能。

例举：数据库中有如下一张表（它们的主键分别为 员工ID 和 部门ID）

员工 表

部门 表

如果在实际需求中要频繁地查询某个员工所在的部门的名称，比如调用如下 SQL 语句：

select employee_id,department_name
from employees e 
join departments d 
on e.department_id = d.department_id;

那么每次都需要进行两个表的连接操作，会浪费大量时间资源和计算资源。

因此，可以在员工表中增加一个冗余的字段 部门名称 ，这样每次的查询就可以直接获取所需信息，而不用进行连接操作了。

员工 表

2.1.2 纬度建模（Dimensional Modeling）

2.1.2.1 多维数据模型各种类型

2.1.2.1.1 星型模型

星型模式核心一个大的事实表，周围小的维度,形状如星星。 星型模式通过使用一个包含主题的事实表和多个包含事实的非正规化描述的维度表来支持各种决策查询。 采用星型模式设计的数据仓库的优点是由于数据的组织已经过预处理，主要数据都在庞大的事实表中，所以只要扫描事实表就可以进行查询，而不必把多个庞大的表联接起来，查询访问效率较高，同时由于维表一般都很小，甚至可以放在高速缓存中，与事实表进行连接时其速度较快，便于用户理解；对于非计算机专业的用户而言，星型模式比较直观，通过分析星型模式，很容易组合出各种查询。 总之星型模型使用在于提高查询的效率和简单易于理解。

星型模型是最简单最常用的模型。星型模型本质是一张大表，相比于其他数据模型更合适于大数据处理。其他模型可以通过一定的转换，变为星型模型。

星型模型的缺点是存在一定程度的数据冗余。因为其维表只有一个层级，有些信息被存储了多次。比如一张包含国家、省份、地市三列的维表，国家列会有很多重复的信息。

2.1.2.1.2 雪花模型

雪花模式是星型模式的进一步延伸，延伸/下钻成更小的维度表（颗粒度），像是雪花一样蔓延。 雪花模型是对星型模型的扩展，他的维度表可以向外连接多个详细的子维度类别表。

其优点是通过最大限度地减少数据存储量以及联合较小的维表来改善查询性能，避免了数据冗余。其缺点是增加了主键-外键关联的几率，导致查询效率低于星型模型，并且不利于开发。

2.1.2.1.3 星座模式

多个星型构成一个星座，分离的事实表，共用维度表，像是宇宙星辰 一个复杂的商业智能应用往往会在数据仓库中存放多个事实表，这时就会出现多个事实表共享某一个或多个维表的情况，这就是事实星座，也称为星系模式（galaxy schema）。

2.1.2.1.4 交叉连接

从一张表到另一张表有多条筛选路径彼此相连接，属于交叉连接模式

2.1.2.2 多维数据各种模型对比

三种数据模型特点对比如下：

2.2 数据仓库核心理论

2.2.1 数据域和主题域

2.2.1.1 数据域

数据域是面向业务分析，将业务过程或维度进行抽象的集合。他是以业务系统的角度，对业务过程进行归纳，抽象出的数据域。

数据域是数据驱动业务，是对数据的分类，更好的数据赋能业务。

2.2.1.2 主题域

面向主题、集成的、相对稳定的、反映历史变化的数据集合，用于支持管理决策。

主题域是针对数据集市提出的概念，数据集市是面向主题，从业务驱动进行分析场景的建设。

2.2.1.3 数据域和主题域的区别

数据域是自下而上，以业务数据视角来划分数据，一般进行完业务系统数据调研之后就可以进行数据域的划分。

主题域则自上而下，以业务分析视角来划分数据，一般进行完业务需求调研之后才可以进行主题域的划分。

例如，商品数据域是面向数据的，对数据的分类，数据驱动业务，更好地赋能业务；商品主题域是面向主题的，根据业务需求分析，从业务驱动进行分析场景的建设。

有一个更形象的例子：

建设数仓就像饭店做菜一样，

数仓在面向业务系统数据根据其特点划分出数据域，如同厨房根据采购的食材特点将它们摆放在不同货架区，如肉禽区、果蔬区、调味区等。

而数仓在面向业务分析根据其需求划分出主题域，如同饭店根据不同食客群体的口味需求将食材做成了不同菜系，如江浙菜、鲁菜、川菜等。

总结

数据域是对数据的分类，主题域和业务域是对业务的分类。 主题域和数据域最终都是对数据的分类，只是一个是数据视角，一个是业务视角。 根本的目的是：统一规则，方便管理，容易理解，有利于开发效率，有利于快速服务业务场景就可以了。

Tips 在 DWD 层可以按照数据域进行分类，DWS 层可以按照主题域划分，ADS 层可以按照分析主题域（业务场景）划分。 数据域划分几点需要注意的地方

1. 不重不漏，确保每个表都在一个域里，且只在一个域里（精确定位）

2. 每个域下都可以根据需要再分子域，不限定层级（最自由方便）

3. 如果分子域就不能放表，表只放在最底层的域中（树状目录管理时更方便）

4. 最好保证每个域下的子域数量或表数量在20个左右（太多了不方便记忆管理，太少了没必要划分）

5. 【其他】很好用，不好划分的都放里面（减少域层级数量有理由理解记忆）

6. 数据团队分域可以作为分工的标准（数据不重、分工明确、界限清晰）

7. 数据团队分域后，可以决定域内表的中间命名（看到表名时可以理解更多信息）

2.2.2 数据模型

2.2.2.1 明细粒度事实层（DWD）^{@ 数据来源 阿里巴巴-云原生大数据计算服务 MaxCompute}

明细粒度事实层DWD（Data Warehouse Detail）以业务过程驱动建模，基于每个具体的业务过程特点，构建最细粒度的明细层事实表。可以结合企业的数据使用特点，将明细事实表的某些重要维度属性字段做适当冗余，即宽表化处理。

公共汇总粒度事实层（DWS）和明细粒度事实层（DWD）的事实表作为数据仓库维度建模的核心，需紧绕业务过程来设计。通过获取描述业务过程的度量来描述业务过程，包括引用的维度和与业务过程有关的度量。度量通常为数值型数据，作为事实逻辑表的依据。事实逻辑表的描述信息是事实属性，事实属性中的外键字段通过对应维度进行关联。

事实表中一条记录所表达的业务细节程度被称为粒度。通常粒度可以通过两种方式来表述：一种是维度属性组合所表示的细节程度，一种是所表示的具体业务含义。

作为度量业务过程的事实，通常为整型或浮点型的十进制数值，有可加性、半可加性和不可加性三种类型：

• 可加性事实是指可以按照与事实表关联的任意维度进行汇总。

• 半可加性事实只能按照特定维度汇总，不能对所有维度汇总。例如库存可以按照地点和商品进行汇总，而按时间维度把一年中每个月的库存累加则毫无意义。

• 完全不可加性，例如比率型事实。对于不可加性的事实，可分解为可加的组件来实现聚集。

事实表相对维表通常更加细长，行增加速度也更快。维度属性可以存储到事实表中，这种存储到事实表中的维度列称为维度退化，可加快查询速度。与其他存储在维表中的维度一样，维度退化可以用来进行事实表的过滤查询、实现聚合操作等。

明细粒度事实层（DWD）通常分为三种：事务事实表、周期快照事实表和累积快照事实表，

• 事务事实表用来描述业务过程，跟踪空间或时间上某点的度量事件，保存的是最原子的数据，也称为原子事实表。

• 周期快照事实表以具有规律性的、可预见的时间间隔记录事实。

• 累积快照事实表用来表述过程开始和结束之间的关键步骤事件，覆盖过程的整个生命周期，通常具有多个日期字段来记录关键时间点。当累积快照事实表随着生命周期不断变化时，记录也会随着过程的变化而被修改。

明细粒度事实表设计原则如下所示：

• 通常，一个明细粒度事实表仅和一个维度关联。

• 尽可能包含所有与业务过程相关的事实 。

• 只选择与业务过程相关的事实。

• 分解不可加性事实为可加的组件。

• 在选择维度和事实之前必须先声明粒度。

• 在同一个事实表中不能有多种不同粒度的事实。

• 事实的单位要保持一致。

• 谨慎处理Null值。

• 使用退化维度提高事实表的易用性。

2.2.3 缓慢变化维与拉链表^{@数据源 csdn 怪鱼校尉 @数据源 csdn 大数据梦想家}

2.2.3.1 缓慢变化维

缓慢变化维SCD（Slowly Changing Dimensions），是指维度表数据不是静态不变的，而是随时间缓慢变化。

缓慢变化维的几种解决方法：

1. 保留原始值：属性值不会发生变化，始终以原始数据为准；

2. 改写属性值：用新数据覆盖旧数据，只保留最新属性值。此方法易于处理，但无法分析历史数据变化；

3. 增加维度新行：数仓的目标之一就是保存历史数据，为达到这样的目的，既要保留历史记录，又要增加新的记录，此方法典型代表就是拉链表；

4. 增加维度新列：在表中增加一个新字段，用来保存变化后的当前值；

5. 使用历史表：另外建一个表保存历史数据，维度表只保存最新数据，将历史数据和当前数据完全分开。

在实际使用中，常使用拉链来解决数据的缓慢变化维：既可以保存历史数据，又可以防止数据的冗余。

拉链表存储历史快照代码实现

操作步骤：

1. 在原有dw层表上，添加额外的两列

   生效日期（dw_start_date） 失效日期（dw_end_date）

2. 只同步当天修改的数据到ods层

3. 拉链表算法实现

   编写SQL处理当天最新的数据（新添加的数据和修改过的数据）

   编写SQL处理dw层历史数据，重新计算之前的dw_end_date

4. 拉链表的数据为：当天最新的数据 UNION ALL 历史数据

2.2.3.2 拉链表

拉链表是针对数据仓库设计中表存储数据的方式而定义，顾名思义，所谓拉链，就是记录历史。记录一个事物从开始，一直到当前状态的所有变化的信息。

适用场景：

• 有一些表的数据量很大，比如一张用户表，大约10亿条记录，50个字段，这种表，即使使用ORC压缩，单张表的存储也会超过100G，在HDFS使用双备份或者三备份的话就更大一些。

• 表中的部分字段会被update更新操作，如用户联系方式，产品的描述信息，订单的状态等等。

• 需要查看某一个时间点或者时间段的历史快照信息，比如，查看某一个订单在历史某一个时间点的状态。

• 表中的记录变化的比例和频率不是很大，比如，总共有10亿的用户，每天新增和发生变化的有200万左右，变化的比例占的很小。

2.2.4 维度退化和维度下沉

2.2.4.1 维度下沉

数据仓库仍然保留维度表，比如商品维度表，业务经常按照类目进行聚合操作，为减少维度的表关联，提升查询效率，需要把商品的类目属性下沉到事实表中方便业务聚合分析；另外商品id也会冗余在事实表里面，作为关联商品维度表的外键存在，它有对应的维度表，所以它不属于退化维度；

2.2.4.2 维度退化

数据仓库不保留维度表，首先数据量太大，没必要用一张维度表来进行存储，其次没有数据仓库需要的任何数据时，因此退化维度的维度表可以被剔除。比如说订单id，券领取记录id, 进行数据查询或者数据过滤的时候又非常需要，就直接退化到事实表中作为一个字段；

特点：

1.没有对应的维度表的维度。

2.存储在实施表中

例子：

维度退化是指对于简单的维度来说，不创建自己的维表，例如，下面的事实表：

对于其中的维度支付方式，假设我们创建了一个维表，这个维表几乎是没有意义的。如果单独增加了这样一个维表，那么可能会导致一定的连接成本。

2.2.5 总线架构或总线矩阵

维度建模的数据仓库中，有一个概念叫Bus Architecture，中文一般翻译为“总线架构”。总线架构是Kimball的多维体系结构（MD）中的三个关键性概念之一，另两个是一致性维度（Conformed Dimension）和一致性事实（Conformed Fact）。

一致性维度就好比企业范围内的一组总线，不同数据集市的事实的就好比插在这组总线上的元件。这也是称之为总线架构的原因。

实际设计过程中，我们通常把总线架构列表成矩阵的形式，其中列为一致性维度，行为不同的业务处理过程，即事实，在交叉点上打上标记表示该业务处理过程与该维度相关。这个矩阵也称为总线矩阵（Bus Matrix）。

数据总矩阵

矩阵的每一行对应都对应机构中的一个业务过程，每一列都和一个业务维度相对应，用叉号填充显示的是和每一行相关的列。业务过程应该先从单个数据源系统开始，然后再进行多数据源的合并。

企业数据仓库总线矩阵是DW/BI系统的一个总体数据架构，提供了一种可用于分解企业数据仓库规划任务的合理方法，开发团队可以独立的，异步的完成矩阵的各个业务过程，迭代地去建立一个集成的企业数据仓库。

一致性维度和事实

企业数据仓库应该建立一个一致性维度和事实，而不是为每个部门建立维度和事实。

一致性维度

具有一致的维度关键字，一致的属性列名称，一致的属性定义和一致的属性值。一致性维度要么是统一的，要么是维度表的一个子集。

一致性事实

指每个度量在整个数据仓库中都是唯一的统计口径，为了避免歧义，一个度量只有唯一的业务术语。

维度模型的设计方法

维度模型设计流程图

三、数据治理体系

数据治理是企业数据建设必不可少的一个环节。

好的数据治理体系可以盘活整条数据链路，最大化保障企业数据的采集、存储、计算和使用过程的可控和可追溯。

3.1 数据治理需要做的事情

整体流程数据治理体系将全程监管。要确认进出系统的数据质量怎么样？是否可转化数据资产？数据血缘是否可追溯、数据安全等问题。

3.2 为什么要做数据治理

有一些企业对这个问题的概念很模糊，认为目前的数据规模很小，人为可控，暂时不需要做数据治理。

但是在实际使用中还是会遇到很多问题：

• 数据监管力度不够，出现脏数据

• 数据体系逐渐规模变大，管理混乱

• 数据的血缘丢失，无法回溯旧、老的数据

无论企业的数据规模如何，我认为还是提起做好数据治理的规划。考虑到成本的问题，可以分阶段进行。

为什么要进行数据治理：

1. 你的数据是否真的可用，缺失和异常值怎么办？

2. 数据从哪里来到哪里去，血缘信息是否丢失

3. 数据访问是否安全，明文标识还是加密？

4. 新的数据加工参考什么规范，维度和标签管理是否存在标准？

有剑在手不用和无剑可用是两回事。提前做好数据治理规划，会节省后续的改造成本，避免过程冗余重构或者推倒重来等情况的发生。

数据治理可以有效保障数据建设过程在一个合理高效的监管体系下进行，最终提供高质量、安全、流程可追溯的业务数据。

3.3 数据治理体系

数据治理体系包括数据质量管理、元数据管理、主数据管理、数据资产管理、数据安全及数据标准等内容

3.3.1 数据质量

一般采用业内常用的标准来衡量数据质量的好坏：完整性、准确性、一致性和及时性。

• 完整性：数据的记录和信息是否完整，是否存在缺失情况

• 准确性：数据汇总记录的信息和数据是否准确，是否存在异常或者错误

• 一致性：多个业务数仓间的公共数据，必须在各个数据仓库中保持一致

• 及时性：数据能及时产出和预警

3.3.2 元数据管理

元数据是关于数据的组织、数据域及其关系的信息，通俗理解，元数据就是描述数据的数据。

元数据包含技术元数据和业务元数据。可以帮助数据分析人员清楚了解企业拥有什么数据，它们存储在哪里，如何抽取、清理、维护z这类数据，也即数据血缘。

• 帮助构建业务知识体系，确立数据业务含义可解释性

• 提升数据整合和溯源能力，血缘关系可维护

• 建立数据质量稽核体系，分类管理监控

3.3.3 主数据管理

企业主数据指企业内一致并共享的业务主体，就是各专业公司和业务系统间共享的数据。

常见的主数据比如公司的员工、客户数据、机构信息、供应商信息等。这些数据具有权威性和全局性，可归约至公司的企业资产。

一般主数据管理需要遵循如下几点：

• 管理和监管各组织机构、子公司、部门对主数据的访问，制定访问规范和管理原则

• 定期进行主数据评估，判断既定目标的完善程度

• 组织相关人员和机构，统一完善主数据建设

• 提供技术和业务流程支持，全集团集中统筹

3.3.4 数据资产管理

一般企业在数字化转型时都会考虑数据资产梳理。你的数据有没有被合理利用？如何产生最大价值？这是数据资产管理关心的核心工作。在构建企业资产时一般会考虑不同角度，即业务角度和技术角度，最后进行合并，输出统一的数据资产分析，并向外提供统一的数据资产查询服务。

如何盘活数据，形成数据资产，提供完整的数据资产全景视图，可方便运营者全局、宏观地掌控企业资产动态。

3.3.5 数据安全

数据安全是企业数据建设必不可少的一环，我们的数据都存储在大大小小的磁盘中，对外提供不同程度的查询和计算服务。

需要定时对数据进行核查、敏感字段加密、访问权限控制，确保数据能够被安全地使用。

3.3.6 数据标准

数据标准是保障数据的内外部使用和交换的一致性和准确性的规范性约束，通过统一规范，消除二义性。

3.4 数据治理平台

3.4.1 核心功能

数据治理平台作为数据治理的产品体系，旨在保障数据平台的数据是安全、可靠的、标准的、有价值的。

• 数据资产管理：提供面向用户的场景化搜素，提供全景数据资产地图，方便快速查找资产和资产分析

• 数据标准管理：统一定制数据标准，提高包括字段、码值、数据字典管理，保障业务数据和中台数据的统一标准

• 数据质量监控：提供事前、事中、事后的数据质量体系，支持数据质量监控规则配置、告警管理等功能

• 数据安全：提供数据安全脱敏、安全分级和监控

• 数据建模中心：统一建模，提供业务系统建模和模型管理

3.4.2 元数据管理

元数据管理系统作为数据治理平台的前端展示门户，帮助实现对数据资产的快速检索能力，提高数据使用有效性和效率。

通过建立完整且一致的元数据管理策略，提供集中、统一、规范的元数据信息访问、查询和调用功能。

3.4.3 数据质量

• 数据质量监控：支持所有用户进行数据质量监控规则配置

• 规则阻断：配置数据质量监控阻断规则，数据质量出现差异可实时阻断下游作业运行，屏蔽错误结果链路扩散。

• 告警：数据质量出现预设偏差，及时发出预警通知及时修复

3.4.4 数据标准

支持定制统一的数据标准平台，包括字段标准管理，码值标准管理以及字典管理，业务源数据和中台数据统一标准。

3.4.5 数据安全

基于集团数据资产实现数据安全分级管理，自动识别安全信息；提供数据访问安全行为监测，及时识别访问风险。

3.5 数据治理评估

数据治理平台开发完成并运行，需要对整体数据治理体系的效果进行验证和评估。

1）数据是否可以消除"脏、乱、差"的现象 2）数据资产是否最大价值化 3）所有数据的血缘是否完整可追溯

3.5.1 数据资产

通过构建数据资产管理体系，实现资产全覆盖，并支持全局搜索和精准定位目标资产。

• 实现全局搜索，面向用户提供场景化检索服务

• 支持标签、数据地图、表名和字段名等多种检索维度

• 支持进行数据地图，源业务数据字典的结果筛选

• 比如支持PV/UV用户搜索和资产展示，明确服务目标

3.5.2 数据标准

新旧数据标准沉淀，打通了数据建模工具、数据标准库和词根标准库，落地数据标准和词根。

• 实现数据标准库100%拉通

• 智能识别数据标准和引用

• 客户端同步更新数据标准、词根

3.5.3 数据安全

保持事前制度建设、事中技术管控、事后监控审计的原则建立全流程数据安全管控体系。

基于以上数据安全管控体系，支持数据安全定级，构建灵活的数据安全共享流程。

3.5.4 数据质量

通过数据质量雷达图，定期进行数据和任务质量打分，综合考察数据质量效果。

• 数据完整性：查看数据项信息是否全面、完整无缺失

• 告警响应程度：日常管理、应急响应、降低影响；避免数据损毁和丢失

• 监控覆盖程度：确保数据遵循统一的数据标准和规范要求

• 作业稳定性：监控作业稳定性，是否存在作业异常等问题

• 作业时效性：检查任务对应的数据项信息获取是否满足预期要求

3.6 数据治理的几点误区

1）数据治理是否要做得大而全

“这是一个经典问题，一般对于不同阶段和规模的企业，数据治理的实施程度会有所不同。一般建议先根据自身的数据状况分阶段进行，避免盲目铺开规模，过程中可调整。 ”

2）数据治理只是技术考虑的事情

“正如文中所说，数据治理不仅仅是技术团队的事情，而是整个集团一起协作完成。其中就包括各业务线以及其他管理组织，没有一个好的实施方案和协作机制，往往事倍功半。 ”

3）数据治理可以短期见效

“数据治理是个长期过程，会跟随着企业数据的规模和数仓规划的变更同步调整，部分功能可能会在短期内卓有成效，完整体系搭建短期很难实现。 ”

4）必须得有工具平台，才能开展数据治理

“俗话说工欲善其事必先利其器，有好的工具当然是更好，前提是已经有了成熟的数据治理体系规划和策略。工具和技术手段目前市面上很成熟，先把理论给铺垫好。 ”

5）数据治理感觉很模糊？不知道最后的落地结果

“数据治理是一个长期工作，需要相关从业者根据企业的数据现状和管理模式去构建和调整，建议边做实践边总结归纳，小步慢跑是一个很好的方式。 ”