数据治理的核心工作： 在企业的数据建设进程中，保障企业的数据资产得到正确有效地管理。最大化保障企业数据的采集、存储、计算和使用过程的可控和可追溯。

2.什么是数据治理以及价值？

数据治理是一种数据管理的概念，确保组织能在数据的全生命周期中具有高质量的数据质量能力，并且实现对数据的完全管理，以支持业务的目标。

所以数据治理的目标主要由以下几点构成：

• 第一，最大化数据价值；
• 第二，管理数据的风险；
• 第三，降低数据的成本

数据治理的价值主要有哪些？

     核心就是提高数据质量，降本增效，具体可以拆解如下：

1. 降低业务运营成本
2. 提升业务处理效率
3. 改善数据质量
4. 控制数据风险
5. 增强数据安全
6. 赋能管理决策

数据治理的优先级

数据治理的难度和痛点在哪？

数据治理成效进展缓慢，数据问题依旧严重，缺少系统化的工具平台支撑治理落地和成效展现是关键原因

企业通用数据治理维度

主要包含就是元数据管理，数据质量管理，数据安全管理，数据全生命周期管理，数据标准化管理

企业数据治理的步骤

1：确定数据治理的目标任务
2：数据治理需求分析
3：数据治理技术路径设计
4：确定数据治理的建设顺序、建设重点和时间节点
5：做好实施保障即可开工

数据模型的3种类型

1.概念模型:

概念模型也叫业务模型，是对业务实体、业务操作、操作规则的整体描述

2.逻辑模型：

逻辑模型是对概念模型的具体化，它根据概念模型，设计数据实体和数据属性，着重于系统的逻辑实现，不考虑物理属性

3.物理模型：

物理模型描述数据库中数据模型的具体实现，其中包括逻辑模型中各种实体表的具体化，如表的数据结构类型、索引、数据存放位置和数据存储资源分配等。

数据模型开发规范治理

数据模型管理系统

数据仓库的命名及使用

按数仓分层架构设计，共有ods、dwd、dws、dm层及dim维表管理模块组成，库的规范化使用，遵循如下规范：

• 数仓ods贴源层，库名ods_{xx}, xx表示源系统缩写。
• 数仓dwd层，不同数据领域使用不同的dwd库管理对应的表，库名定义为dwd_{xx},xx表示业务域简称缩写。
• 数仓dws层，不同数据领域使用不同的dws库管理对应的表，库名定义为dws_{xx},xx表示业务域简称缩写。
• 数仓dim维度管理，不同数据领域使用统一的dim库管理维表，数据库使用dim库。
• 数仓dm层，根据各数据领域需求为每个业务线创建单独集市层数据库，库名定义为dm_{xx},xx表示业务域简称缩写。

数据域、主题域、分区策略、表类型缩写

数仓架构：事业部BU/业务线/业务域–>数据域/主题域–>业务过程–>维度指标

数据域简称说明

主题域简称说明

表的分区策略：表后缀

表类型：

数仓各层级表的命名规范

1.ods表命名规范
表的命名规则：{源系统表名}
举例： ods_cx.complain

2.dwd表命名规范
表的命名规则：{层级}_{数据域英文缩写名}_{业务内容}_{分区类型}
举例：dwd.dwd_pd_waybill_info_di 收派运单信息表

3.dws表命名规范
表的命名规则：{层级}_{主题域英文缩写名}_{业务内容}_[时间粒度]_{分区类型}
举例： dws.dws_pd_emp_eff_7d_di 收派效能汇总表

4.dim维表命名规范
表的命名规则：{层级}_{维度内容}_{分区类型}_{表类型}（快照/拉链）
注：拉链英文缩写chain,快照类型表名可省略表类型
举例：dim.dim_prod_info_df 产品维表、dim.dim_prod_info_df_chain 产品维度拉链表

5.tmp临时表命名规范
表的命名规则：{目标表名}_tmp{数字编码}
举例：tmp_dwd.dwd_pd_waybill_info_di_tmp01

6.中间表的命名规范
表的命名规则：{目标表名}_{表类型}_{数字编码}
举例： dwd.dwd_pd_waybill_info_di_mid01 收派运单中间表01

数仓表的字段名称规范

1.字段词根规范

普通词根：描述事物的最小单元体，如：运单-waybill,金额-amount。
专有词根：具备约定成俗或行业专属的描述体，如：美元-USD。

如何确保数仓严格遵守了词根规范？

1：首先要保证定义了明确的词根规范
2：建立数据字典
3：内部培训与宣贯
4：代码审查或自定化检查
5：监控和改进

企业模型治理

企业模型会出现哪些问题？

模型命名不规范；
公共层过度设计；
ADS重复建设；
ADS跨集市依赖；
ADS共性未下沉；
ADS穿透依赖ODS
临时表过多，只增不减，污染数据体系，影响数据治理；

出现这些问题的原因分析

模型治理策略

核心治理策略为以下三点：
1：盘点存量
2：规范增量，考虑到数据的生命周期，历史数据可以先不管。
3：日常治理

 模型评分考核机制

核心公共层的建设是自顶向下还是自底向上？

两者相结合的方式。以需求为驱动。
在应用层有复用之后再下沉到公共层，这是自顶向下的。 
在公共层设计阶段是面向业务过程的，这这时是自底向上的。

怎么判断指标需要下沉到公共层？

是否需要下沉到公共层核心是看是否需要复用

关于表、字段的命名规范，是否需要先定义好词根再开发？

对于公共部分要先定义好再开发。
对于指标特别是派生指标，不建议先定义再开发。
核心判断依据是复用率和效率。

如何解决口径一致命名不一致，或者口径不一致但命名一致的场景？

梳理核心指标，对其进行规范统一。

跨集市依赖下沉到公共层的必要性？

短期来看，是没影响的，新增效率高。
长期来会给数据的运维、治理带来很多影响，在数据下线、变更、治理过程中不得不考虑到下游依赖，会影响全流程的开发效率。

多BU公共层是否需要统一规范？怎么去做？怎么量化价值？

需要，从建模规范、开发流程规范方面着手，其价值体现在降低运维成本和提高开发效率。

企业元数据管理

企业需要知道它们拥有什么数据，数据在哪里、由谁负责，数据中的值意味着什么，数据的生命周期是什么，哪些数据安全性和隐私性需要保护，以及谁便用了数据，用于什么业务目的，数据的质量怎么样，等等。这些问题都需要通过元数据管理解决问题。

元数据的类型与作用

1：业务元数据
     业务定义、业务术语解释等；
     业务指标名称、计算口径、衍生指标等；
     业务规则引擎的规则、数据质量检测规则、数据挖掘算法等；
     数据的安全或敏感级别等。

2：技术元数据
     物理数据库表名称、列名称、字段长度、字段类型、约束信息、数据依赖关系等；
     数据存储类型、位置、数据存储文件格式或数据压缩类型等；
     字段级血缘关系、SQL 脚本信息、ETL 抽取加载转换信息、接口程序等；
     调度依赖关系、进度和数据更新频率等。

3：管理元数据
     数据所有者、使用者等；
     数据的访问方式、访问时间、访问限制等；
     数据访问权限、组和角色等； 
     数据处理作业的结果、系统执行日志等；
     数据备份、归档人、归档时间等。

为什么企业需要元数据管理？

元数据的管理本质是为了更加有效地利用企业数据资产，企业降本增效同时可以更大化地利用数据的价值。

数据管理的发展阶段？

手动元数据管理阶段（比如用excel管理，数据变化快，数据链路复杂，规模越来越大时，维护成本高，）
元数据中央存储/仓库阶段（平台化维护元数据，元数据打通）
智能化元数据管理阶段：实现元数据的自动化采集，整合，元数据维护；

元数据管理需要达到什么样的目标？

1.建立元数据指标解释体系（元数据管理平台）：实现用户对业务数据的透明化，比如有哪些数据，归属谁，谁在用，生命周期，数据存储等。
2.提高数据的溯源能力（元数据分析平台）：比如这张表从哪里，做过哪些操作，血缘分析，链路分析，影响分析，指标加工口径等。
3.元数据的数据质量稽核体系（元数据应用）：保障数据的及时性，完整性，一致性等，让业务对结果有保障，透明，比如今天为啥数据增加了10%？

元数据在数据治理中的作用？

元数据管理是数据治理的基础它用于定义和描述数据、数据之间的关系，以及数据如何管理、如何使用。元数据在数据治理中的主要应用如下:

定义和描述业务域、业务主题和数据实体;
描述数据结构和数据关系;
描述源系统、目标系统、表、视图、存储过程和字段属性;
定义和描述数据资产目录;
定义和描述主数据模型的属性;
管理数据标准:
描述数据质量规则和数据质量检核结果;
识别和定义数据集中的敏感数据、敏感属性;
血缘分析和影响分析;
描述数据流向，数据来自哪里、流向哪里;
描述数据管理，谁负责管理数据、在哪里管理;
描述数据的使用，谁有权使用数据、在哪里使用。

元数据在数据仓库中的应用如下

描述数据源的库表结构、数据关系以及每个数据项的定义：
描述数据源中每个数据项的值域范围和更新频率;
描述数据源与数据仓库之间的数据映射关系:
描述数据仓库中有哪些数据以及它们来自哪里
描述数据在数据仓库各层中的加工处理过程;
元数据管理工具为数据管理者和使用者提供了理解和查询数据的一致语言;
利用元数据管理工具的元数据变更和版本管理功能，管理数据仓库的数据模型，支持将元数据恢复到某一版本:
利用元数据管理工具的血缘分析、影响分析等功能，对数据仓库中的数据问题快速定位、快速查找;
利用元数据管理工具的开放式元数据交换标准，实现数据仓库中数据的交换和共享。

元数据管理平台架构

元数据的管理与应用平台功能模块

元数据提供的应用：血缘分析、影响分析、全链分析、关联度分析，数据地图，质量核检等。

• 血缘分析：告诉你数据来自哪里，都经过了哪些加工。
• 影响分析：告诉你数据都去了哪里，经过了哪些加工。
• 全链分析：告诉你一个应用侧的数据整个生产链路。
• 冷热度分析：告诉你哪些数据是企业常用数据，哪些数据属于僵死数据。
• 关联度分析：告诉你数据和其他数据的关系以及它们的关系是怎样建立的。
• 数据地图：告诉你有哪些数据，在哪里可以找到这些数据，能用这些数据干什么。
• 质量核检：提供基础的填充率，一致性检查等。

元数据管理平台技术架构

企业数据全链路流程管理

对数据进行抽象成表和任务进行统一管理，完成了从业务到业务的闭环，数据全链路实现了：

1. 数据类型全
2. 任务类型全
3. 平台类型全
4. 元数据类型全
5. 血缘类型全

元数据管理之血缘管理

为什么数仓需要血缘分析系统？

1.日益庞大的数据开发导致表间关系混乱，管理成本与使用成本激增
2.数据价值评估，数据质量难以推进
3.表|任务的的数据治理，变更等操作参考依据（确定影响范围）
4.ETL任务的调度管理，异常归因分析、影响分析、恢复参考依据（追踪溯源）
5.数据安全审计难以开展

血缘衡量指标

1:血缘准确率
假设一个任务实际的输入和产出与血缘中该任务的上游和下游相符，既不缺失也不多余，则认为这个任务的血缘是准确的，血缘准确的任务占全量任务的比例即为血缘准确率

2:血缘覆盖率
当至少有一条血缘链路与资产相关时，称为资产被血缘覆盖到了。被血缘覆盖到的资产占关注资产的比例即为血缘覆盖率。

3:血缘时效性
从任务发生修改，到最终反应到血缘存储系统的端到端延时。

数据标准治理

通过规范设计和开发来预防问题的发生。通过制定各类数据实体（元素、码表、模型分层、模型等）的设计约束，规范每类业务实体包含的属性、该属性是否必选、该属性内容约束等规则，统一公共层来减少重复建设和维度事实的一致性。

代码评审参考维度

测试完成后输出交付测试报告，详情请参见<交付测试报告>。数据测试测试期间需重点关注以下事项：
1. 代码规范性：命名规范、编码类型是否符合要求。
2. 数据规范性：命名规范、表结构规范、精度要求、空值处理方式、时间类型格式等是否符合要求。
3. 数据基础：主键唯一性，空值、重复值、无效值占比是否符合要求。
4. 业务正确性：各业务点是否被正确实现，可以通过划分边界值、等价类等样本数据进行验证。
5. 代码性能：验证代码是否可在业务要求产出的时间成功运行完成。

企业数仓层级规范：

禁止逆向调用
避免同层调用
优先使用公共层
避免跨层调用
稳定业务按照标准的数据流向进行开发，即ODS → DWD → DWB → DWS → ADS
非稳定业务或探索性需求可以遵循ODS → DWD → ADS 或者 ODS → DWD → DWB → ADS 两个模型数据流

可以用于同层级数据引用，禁止出现反向依赖，一般正常业务流ODS->DWD->DWS->DM或者ODS->DWD->DM,如下图：

数仓可能存在哪些问题？

1：跨层调用
2：逆向调用
3：大量同层调用

如何排查这些问题？

1：确定任务依赖关系
2：任务依赖图
3：数据血缘分析
4：元数据管理工具
5：检查任务代码
6：数据流跟踪
7：代码审查和代码版本管理

如何治理这些问题？

1：解决跨层调用
   解决ODS穿透问题：找出跨层引用ODS层数据的应用层报表，直接切换对应的CDM层模型，或者重新构建相应的CDM层，并在上线新的DWD/DWS数据表后完成引用切换

2：解决逆向调用
   直接建立对应层级的模型表，比如DWD,DWB层等，斩断调用，切换到新的模型。

3：解决同层调用
   严格按照数仓层级设计，尽量避免同级调用

数据模型的标准化治理主要从4个方面

1：数据模型规范化
2：数据模型标准化
3：数据模型一致性
4：数据模型可读性

DWD层模型设计方法论

步骤一：梳理核心业务环节及核心数据实体

步骤二：数据域分类及架构设计

步骤三：单数据域下逻辑ER图构建

步骤四：物理模型设计

 dwd层数据域逻辑建模过程

1：梳理业务域相关的实体

如运单域：核心实体运单、引用关联实体产品、网点、客户、渠道、托寄物等实体。

2）确定数据域相关实体关系，如下图

2 dwd层数据域物理维度建模过程

1.确定业务过程
业务过程即业务活动中所有的事件，通常为不可拆分的事件。确认业务过程，是为了从顶层视角，规范业务中的事务内容的类型及唯一性。

例如：以运单基表为例，它描述了全网（大网、快运、冷运、医药）运单的收派环节相关基础信息，以及运单托寄物、产品、费用、客户相关信息。
例如: 以顺丰券基表为例，它描述了全网顺丰券的发放及使用情况，以及客户是通过哪些渠道获得并且消费的。

2.确定粒度
定义业务流程中的数据粒度。

例如：以运单基表为例，它的粒度为运单号
例如: 以顺丰券基表为例，它的粒度为虚拟券号

3.确定维度
确定用于事实表表行的维度。

例如: 以运单基表为例，以揽收员工号、揽收网点编码、派送员工号、派送网点编码、运费月结卡号、产品代码、派送aoi_id等维度。
例如: 以顺丰券基表为例，它的维度为网点、会员、员工工号等。

4.确定事实
确定用于形成每个事实表的数字型事实。

例如: 以运单基表为例，运单号、寄件时间、签收时间、寄件电话、收件电话、运费、总费用、保价费、声明价值、体积、总长、总宽、总高等。
例如：以顺丰券基表为例，事实为券号、券使用状态、券使用时间、抵扣金额等。

5.冗余字段
冗余相关的维度属性字段，已满足使用的扩展性

例如：运单基础模型中关于产品维度信息，扩展产品板块、产品系列方便多场景的分析使用。

6.输出事实维度关系图

DWS层建模方法论

步骤一：识别关键业务场景并明确主题域

DWS各主题域是面向各业务分析场景的整合数据，为DM层提供公共汇总数据，并提高全链路计算效率，减少Job运行时间

主题域构建核心逻辑：
基于核心业务环节，识别关键业务分析场景
相对独立分析的细分场景单独成为一个主题域
需要经常关联分析的细分场景合并成为一个主题域

步骤二：单主题域下梳理商业分析逻辑并明确数据实体

明确各主题域下核心数据实体

步骤三：单主题域下构建逻辑ER图

根据不同主题域的内容、实体、关联关系、事件，构建各域下的逻辑ER图，终端主题域逻辑模型示例如下：

步骤四：物理模型设计

明确DWS主题域与DWD数据域关联关系

主题域：面向业务分析和业务运营的数据集合，一般会有多个核心管理和检测视角，需要关联多个数据域。
数据域：业务流程中的各环节收集的明细数据集合(通过某种联系或者ID拉通聚合，形成描述某个业务流程（或者实体，或者以实体和关系连接事实事件）的数据集合。

ADS层数仓建模规范

数据集市管理公司范围内各个业务领域不同数据应用场景的数据，场景中会以分析主题的方式建立相关的明细表、汇总表及应用类数据表，这些场景的数据会从数仓dwd层或者dws层获取数据。

数据集市的数据应用有多种形式：报表、指标、数据分析、数据挖掘等。模型表的建模规范一般会在数据集市内部采用小三层的设计原则。

1.明细层数据的构建

明细层数据的构建，一般会基于dwd层的明细数据完成分析主题数据的构建。如：

2.汇总层数据的构建

3.应用层数据的构建

应用层的表设计更多依赖业务的需求或者展示形式，灵活性比较高，设计规范不做强制要求。

DIM维度层建模规范

1）维度表主要分为两类：通用维表和专业维表。

通用维表指全域共用的维表，应用于多个业务域的数据分析；
专业维表指维度内容上比较独立，一般仅在某个业务领域单独使用的维表。

2）通用维的特征                    

基于统一的规范来建全域共同需要用的维表                      
维表的优化/修改需要多方共识                  
可以由多团队建设（负责方可以是不同的团队）

3）专业维的特征

不同团队基于统一的规范建设并负责管理。

维表结合使用和存储特性可分为快照型、拉链型。

维度属性值变化率10%以内可以考虑使用拉链表。大部分情况是使用快照维表。

维度统⼀核心在维表如何设计，一般遵循以下原则：

1. 维度属性存在通用维度属性和专业维度属性，建议拆成两个维表，如：月结客户维表和月结客户黑名单维表。
2. 产出时间相差较⼤的维度属性拆分单独的维表，⽐如有些维度属性产出时间在凌晨2点，有些维度属性产出时间在凌晨6点，那2点和6点的就可以拆成两个维表，确保核⼼维表尽早产出。如：供应商维表，可拆分成供应商（采购）维表和供应商（供应链）维表。
3. 出于维表稳定性产出的考虑，你可以将更新频繁的和变化缓慢的进⾏拆分，访问频繁的和访问较少的维表属性进⾏拆分，如：会员维表

维度表设计基本步骤

1.确定主维度
主维度一般是业务系统同步而来，是事实分析过程中描述的最基础，最频繁的维度属性集合。如：网点维表的主维度为网点编码。

2.定义维度关联属性
基于主维度选择维度相关属性。如网点维表主维度是网点编码，关联维度例如：网点类型、网点层级、归属组织等。

3.维护ER关系

4.输出物理表

物理维表策略上主要包含两种：快照表和拉链表，针对无变化维或者剧烈变化维，采用快照方式存储，针对缓慢变化维结合数据量情况，经验值数据量小于10000，采用快照模式，数据量大于10000，采用快照加拉链表模式（具体结合存储成本考虑），就目前场景涉及拉链表的维度表，都会配套对应的快照表（定期清理数据），以满足下游任务的高时效要求。

快照表，结合实际情况，一般日分区（inc_day）
拉链表，处理缓慢变化方式很多，一般采用dw_star_date(生效日期)、dw_end_date(失效日期)，通过更新失效日期的模式更新维度状态

5.完善维度管理

维护维表管理清单，重点注意维度列、维度表名、维表类型、主责方。

企业指标管理

为什么数仓一定要做指标管理？

使用一致的数据指标，避免一些因为信息差导致的沟通工作，保证大家使用数据指标时的简易度和准确性。

1. 统一数据语言
2. 统一数据生产
3. 统一指标使用

如何做好指标管理？

1：业务过程指标化
2：指标管理标准化
3：指标使用运营化

1：业务过程指标化主要包括以下环节：

理解业务场景：理解业务的底层逻辑，了解业务当前的发展阶段以及后续重点策略方向。
转换业务指标：根据业务场景，将原子化的指标进行组合，合理评估业务表现结果。
对齐指标口径：与 BA、业务方充分沟通，共同讨论指标定义和计算口径。
理解指标体系：将业务目标根据策略逐层拆解，保证每一个关键动作都有指标可以评估。

2：指标管理标准化

命名标准化，口径管理标准化，并进行生命周期管理

3：指标使用运营化

如何确保数据源字段枚举值注释改变，通知到数仓及下游应用？

第一：数据治理推动业务系统开发规范，任何系统变更及时通知下有系统
第二：结合数据质量监控角度回答，如通过配置相关数据质量规则实现监控

数据质量治理

数据质量治理的价值

数据质量的重要性在现代企业中变得越发突出。以下是数据质量的几个关键方面，说明其对企业的重要性：

决策基础：数据质量直接影响到企业决策的准确性和可靠性。
客户满意度：数据质量直接关系到企业与客户之间的关系。
业务流程效率：高质量的数据可以提升业务流程的效率和准确性。
成本控制：低质量的数据可能导致额外的成本和资源浪费。
法规合规：许多行业都有严格的数据保护和隐私法规要求。

数据质量出问题的环节？

大数据的建设和管理是一个专业且复杂的工程，涵盖了业务梳理、标准制定、元数据管理、数据模型管理、数据汇聚、清洗加工、中心存储、资源目录编制、共享交换、数据维护、数据失效等等过程。
任何一个环节都有可能引入数据质量问题。

数据质量有可能出哪些问题？

数据缺失：数据缺失是指在数据集中某些字段或记录缺少必要的数据值
数据错误：数据错误指的是数据值与实际情况不符或包含错误信息
数据不一致：数据不一致是指同一类数据在不同数据源或系统中存在差异
数据重复：数据重复指同一数据记录在数据集中出现多次
数据精度问题：数据精度问题包括数据的精确性和精度
数据不完整：数据不完整是指数据集中某些字段或记录缺少部分数据
数据格式问题：数据格式问题指数据的格式与要求不符合，例如日期格式、文本格式等
数据安全和隐私问题：数据安全和隐私问题是指数据在存储、传输和处理过程中受到未经授权的访问、泄露或篡改的风险

数据质量出问题的原因规类总结？

企业大数据的数据质量可以从哪些角度（维度）去保障？

目前为止，最权威的标准是由全国信息技术标准化技术委员会提出的数据质量评价指标（GB/T36344-2018 ICS 35.24.01），它包含以下几个方面：

完整性：指的是按照数据规则要求，数据元素被赋予数值的程度。完整性是指数据的记录和信息是否完整，是否存在缺失的情况。

准确性（可靠性）：准确性也叫可靠性，体现在数据描述是否准确，数据计算是否准确，数据的值是否准确等。

一致性：多源数据的数据模型不一致，例如：命名不一致、数据结构不一致、约束规则不一致。数据实体不一致，例如：数据编码不一致、命名及含义不一致、分类层次不一致、生命周期不一致……。相同的数据有多个副本的情况下的数据不一致、数据内容冲突的问题。

时效性（及时性）：数据的及时性(In-time)是指能否在需要的时候获到数据，数据的及时性与企业的数据处理速度及效率有直接的关系，是影响业务处理和管理效率的关键指标，举个栗子，我要求某个报表每天要在老板上班9点前生产完，结合实际，我要求任务必须要在7点开始触发执行。

可访问性：指的是数据能被访问的程度。

唯一性：描述数据是否存在重复记录（国标归在准确性中），比如主数据治理中的一物多码，多物一码的问题，要确保为每个数据实体赋予唯一的身份ID。

稳定性（波动性）：描述数据的波动是否是稳定的，是否在其有效范围内，这个稳定性在企业中使用的还是比较多，比如我每天正常订单数是1000w，上线浮动20%，超过这个范围就是不正常，那么我可以配置qcj监控，数据波动率+-20%

可信性：描述数据来源的权威性、数据的真实性、数据产生的时间近、鲜活度高

数据质量实施流程

事前管理

1）测试验证
测试验证方法如下：
    总量核对，核对上下两步的数据总条数，没有过滤条件的话应该是一致的。
    多维度统计，复杂的多维度指标拆分成单维度SQL统计，对每个指标分别进行核查。
    多表关联统计，拆分成中间表进行核对每一步骤的指标。
    明细到指标统计，比如随机找一台车的明细和最后统计的指标进行核对。
    新老统计对比，比如有些指标是迁移或者之前业务手工制作，可以开发后的新指标同老指标进行对比。
    测试需要有专门的数据测试人员进行测试，输出测试用例和测试报告。

2）上线审核
需要对上线的SQL代码进行审核，主要从以下几个方面：
    对查询表的where后面的条件、join关联字段、group by分组字段等重点检查逻辑，和需求理解结合审核。
    数据集命名、数据集字段命名、任务名称进行审核，是否按照数据仓库建设规范中的业务域、维度、原子指标、修饰类型、修饰词、时间周期、派生指标等标准进行命名。
    代码注释审核，每一步处理需要有注释该步骤的作用，每个指标也要有注释，where条件等也要添加注释。
    重要任务是否开启短信告警，任务启动时间等审核。
    任务上线的位置是否符合上线标准，比如上线的数据层级与业务层级等。
    上线审核需要审核人员按照以上步骤进行审核，对不合理的地方进行指正，审核人员和开发人员共同保障代码质量。

3）流程规范
    需求上线时候需要在知识库中完成所开发需求逻辑说明
    复杂需求（比如项目指标），需要团队至少两人以上评审需求后开发。
    提交上线申请的同事需要备注上需求逻辑说明。
    审核上线人员为“轮值”，审核上线人员需要review开发人员的代码，需要和开发人员共同承担代码质量

事中监控数据质量

数据质量管理的事中控制是指在数据的维护和使用过程中监控和管理数据质量。通过建立数据质量的流程化控制体系，对数据的建立，变更，采集，清洗，转换，装载，分析等各个环节的数据质量进行控制。

1）校验每天的记录数
确保每天一个表中的新记录数>0

2）NULL和0值校验
每天增量数据中的NULL或0值不能超过新增数据的99%

3）每天新增的记录数波动范围
检查COUNT个新记录是否在7天跟踪平均值的误差范围内。阈值和误差范围可能因公司和产品而异，经验值一般是加减25％

4）重复记录数据校验
不管是电商系统或者是社交系统或者是物联网设备上报的数据，正常情况下都不会出现两条完全一样的记录（包括ID，时间，值都一样）

5）数据时间校验
业务系统的数据都是带有时间戳的，这个时间戳肯定比当前的时间要小
如果公司业务是跨国的，需要考虑时差因素

事后分析和问题跟踪

1.定期质量监控
定期质量监控也叫定期数据测量，是对某些非关键性数据和不适合持续测量的数据定期重新评估，为数据所处状态符合预期提供一定程度的保证
比如：每周定时跑一次程序，对全局数据进行质量稽核控制，如唯一性，非空性等.

2.数据问题补救
再严格的质量控制也无法做到 100%的数据问题防治，甚至过于严格的数据质量控制还会引起其他数据问题。因此，需要不时进行主动的数据清理和补救措施，以纠正现有的数据问题。

(1)清理重复数据
重复数据进行人工或自动处理，处理的方法有删除或合并

(2)清理派生数据
派生数据是由其他数据派生出来的数据，例如:“利润率”就是在“利润”的基础上计算得出的，它就是派生数据。
需要对派生数据进行清理，可以存储其相关算法和公式，而不是结果。

(3)缺失值处理
处理缺失值的策略是对缺失值进行插补修复
有两种方式:
      1:人工插补
      2:自动插补

3.流程和模型优化
根据结果反哺优化数据质量管理成，管理标准等，对数据质量模型进行优化等措施

企业数据质量问题分析与改进流程

数据质量企业实际从哪些角度去做？

1、基于表监控
统计Count或者表实际占用的磁盘空间，PV（加group条件），UV（加group条件去重）可以提供几种默认报警规则根据平均值，上一次的值，或者7天前的值，与本次的值做比较，来设定是否报警

2、基于字段
默认提供重复值校验，字段缺失率（为null或者空字符串的比例）打分，也可以自定义，如果是数值类型可以计算平均值，最大/最小，中位数，四分位数等指标

总结各公司QC质量系统的建设

数据质量平台的功能与设计

1.批处理数据质量平台功能

2.实时数据质量模块的主要功能

数仓各层级数据质量关注重点

对哪些表进行监控？

1. 业务核心表
2. 数据字典或基础数据表
3. 统计汇总表
4. 外部数据接口表
5. 业务流程中涉及的其他关键表

总结起来就是关键数据表强制要求配置数据质量监控，其他非关键表优先级靠后。

数据质量监控关注点：

1. 数据完整性：确保关键字段值不为空，如订单号、用户ID等。
2. 数据准确性：确保数据符合业务规则和约束条件，如价格不能为负数、手机号格式正确等。
3. 数据一致性：确保数据在不同表之间保持一致，如用户表和订单表中的用户信息应保持一致。
4. 数据唯一性：确保某些字段值在表中是唯一的，如订单号、用户ID等。
5. 数据时效性：确保数据及时更新，如统计表应按照预定的时间周期进行更新。
配置好数据质量监控后，还需要定期对监控结果进行分析和异常数据进行处理，以确保数据质量得到持续改进。

企业常用监控规则截选

数据质量体系建设

数据质量体系建设三步走

数据质量流程建设

数据质量体系架构方向建议

1：加强组织建设
2：加强人员培训
3：落实数据标准
4：ETL流程规范保障
      数据提取规范
      数据清洗规范
      数据转换规范
      数据加载规范
      异常处理规范
5.源端系统变更检测
6.模型设计评审
7.代码提交核查
       代码规范类规则。例如，表命名规范、生命周期设置及表注释等。
       代码质量类规则。例如，分母为0提醒、NULL 值参与计算影响结果提醒及插入字段顺序错误等。
       代码性能类规则。例如，分区裁剪失效、扫描大表提醒及重复计算检测等。
8.任务发布变更审查
9 数据质量监控
       强规则：一旦触发报警就会阻断任务的执行（将任务置为失败状态，使下游任务不会被触发执行）。
       弱规则：只报警但不阻断任务的执行。

数据安全管理

什么是数据安全？

宏观的数据安全主要具有三大要素，通常被称为 CIA 三要素，有时还会加上问责制一同构成 CIA+A 四要素。

保密性(Confidentiality)：保护数据的私密性，只有获得相应授权才能访问数据
完整性(Integrity)：确保所存储的数据能满足业务场景需要，并且数据是可靠的
可用性(Availability)：确保具有相应授权的用户能持续访问所需的数据
问责制 (Accountability)：界定并划分数据保护、数据治理相关的相关角色，例如数据管理员

数据安全治理体系建设

数据权限管控原则与规范

1）最小授权原则：数据权限应当遵循最小授权原则，即对于非公开类的数据，只有用户真实业务中需要使用到的，才进行授权，不能大包大揽，如按库授权、批量全选
2）区分数据密级：对于含有机密、绝密数据的表，应当按数据密级进行列级权限的管控
3）数据权限生命周期管理：数据的权限需要有生命周期管理，数据的授权需要限定有效期，最长不能超过半年，此外，在用户岗位变更、组织架构变更、离职时，需要及时调整相关的权限

数据异常监控，变更追踪，审计管理

1）数据内容的访问可审计：用户对数据的每一次访问，都需要明确地记录下来，至少包括谁（工号/系统帐号）、什么时候（时间）、在哪里（访问来源，如调度、ide、后台等）、做了什么（访问内容，如哪个库、哪张表、哪个字段等）
2）数据内容的变更可追溯：每一个表的每一行数据，都应当保障有个创建时间、更新时间；
3）数据任务的变更可追溯：大数据平台需要保障每一个任务的操作记录可被审计，至少包括谁（工号）、什么时候（操作时间）、在哪里（哪个产品或后台哪个IP）、做了什么（操作内容，如重跑任务、变更sql等）

敏感数据加密，数据脱敏

利用加密技术对敏感数据进行加密，防止敏感数据泄露。
数据加密是通过对数据进行编码来保护数据，获取实际值的唯一方法是使用解密密钥解码数据。

数据脱敏(Data Masking)，即屏蔽敏感数据，对某些敏感信息（比如，身份证号、手机号、卡号、客户姓名、客户地址、邮箱地址、银行账号、密码类等等 ）通过脱敏规则进行数据的变形，实现隐私数据的可靠保护。
业界常见的脱敏规则有，替换、重排、加密、截断、掩码，用户也可以根据期望的脱敏算法自定义脱敏规则。

数据加密是可逆的，数据脱敏是不可逆的。

数据分类分级|隐私安全

分类是按照一定的原则和方法对数据进行归类，方便为不同的数据分类制定相应的数据安全策略
分级是按照数据的涉密程度高低对分类后的数据进行定级，从而确保企业数据的安全合规使用
数据隐私 (Data Privacy) 强调企业对于保护用户数据的责任和义务，强调个人如何保护自己的隐私数据不被泄露。

常见的数据隐私保护法规主要有中国的 PIPL、欧盟的 GDPR、美国的 CCPA 等。

数据保护

为避免因用户误操作而删除或污染了线上数据，导致不可恢复，平台需要提供额外的数据保护，以保障数据安全，具体包括：
1）容灾：对于重要数据，需要保障其具有跨机房容灾的能力，在机房宕机时，能够继续提供数据服务。
2）整库删除保护：禁止对非空库进行数据删除，此外，对于数据仓库的重点库，平台需要保障只有在特定的机器、特定的用户才能进行库级别的删除。
3）回收站：线上数据的删除，需要能够在回收站中放置一段时间，一般不超过3天，并在需要时可快速恢复，以备不时之需。
4）路径保护：表的后台使用路径应当对用户透明，表的路径应当由系统自动生成，禁止多表使用相同的路径，避免因数据覆盖而导致数据质量问题。

数据安全传输

传输通道安全：比如网络传输时需要加密传输，比如线下传输时专线传输，专人管理
鉴权认证：确保建立安全连接的双方都经过身份验证。
操作审计：对所有的数据传输操作进行安全审计，比如上传，下载数据，是否敏感，数据量，下载时间用途等。

据治理安全体系参考

数据分级实践参考

企业隐私数据脱敏加密实践

哪些数据是隐私数据需要脱敏？

可以通过人工的方式进行敏感数据的梳理和识别，也可以借助一些自动化程序来识别敏感数据。

银行卡号、证件号、手机号有明确的规则，可以根据正则表达式和算法匹配;
姓名、特殊字段没有明确信息，可能是任意字符串，可以通过配置关键字来进行匹配;
营业执照、地址、图片等没有明确的规则，可以通过自然语言处理技术来识别，使用开源算法库。

具体企业哪些数据进行脱敏首先参考国内的数据安全法规要求，其次结合公司实际情况，一般是有数仓负责人和各个业务线核心负责人统筹梳理确认，最后统一治理。

大数据数据脱敏的方式有哪些？

数据脱敏分为静态数据脱敏和动态数据脱敏。

静态数据脱敏，是数据的“搬移并仿真替换”，是将数据抽取进行脱敏处理后，下发给下游环节，随意取用和读写的，脱敏后数据与生产环境相隔离，满足业务需求的同时保障生产数据库的安全。

动态数据脱敏，在访问敏感数据的同时实时进行脱敏处理，可以为不同角色、不同权限、不同数据类型执行不同的脱敏方案，从而确保返回的数据可用而安全。

1.基于规则的脱敏方法：根据不同的敏感程度，制定相应的脱敏规则。
2.加密脱敏方法：对敏感数据进行加密处理，只有授权的人员可以解密。
3.伪装脱敏方法：将敏感数据替换成其他的数据，以达到保护隐私的目的。
4.数据扰动脱敏方法：将原始数据进行随机化处理，以达到数据保护的目的。
5.数据屏蔽脱敏方法：对于一些敏感数据，可以采取屏蔽措施，避免其被存储、传输或使用。
例如，可以将一些特定的数据列从数据库中删除或屏蔽掉，只有经过授权的人员才能够访问。

对于需要脱敏的数据一般在ods层就直接脱敏处理，因为ods层一般禁止数仓开发人员调用。

数据导入导出与网络安全审批

完善公司数据导入导出审批流程：如果数据要脱离生产环境必须关联提数流程，数据进入生产环境必须关联变更流程。

内部数据安全培训

按照三分技术七分管理的原则，强化人员安全意识教育管理，陆续开展高管的专项培训，全员安全意识教育培训与考试，钓鱼邮件演练等活动，多种方式多措并举，有效提升全体员工的数据安全意识。

主数据治理

百度百科：主数据（Master data）是具有共享性的基础数据，业务数据集，可以在企业内部跨越多个业务部门被重复使用的数据。

数据治理的定义：主数据（Master Data）是指组织中核心、共享和持久的数据实体，用于支持业务流程和决策。主数据通常包括客户数据、产品数据、供应商数据、员工数据等

主数据就像大数定义都是属于宏观的模糊概念，我们可以通过特征去判断

主数据具有以下几个特点（这个特点是不唯一的）：

1. 唯一性：主数据在整个组织中是唯一的，不会存在重复或冲突的情况。
2. 共享性：主数据是多个业务流程和部门共享的数据，可以在组织内部不同系统之间进行共享和集成。
3. 持久性（稳定性）：主数据是长期存储和管理的数据，不会因为特定业务流程的结束而被删除或修改。
4. 核心性（高价值性）：主数据是组织中业务流程的基础数据，对于业务运营和决策具有重要影响。

所谓的主数据管理是集方法，标准，流程，制度，技术与工具为一体的系列化解决方案。

如何进行数据梳理？

企业主数据梳理方法有两种:一种是自顶向下的梳理和调研，另一种是自底向上的梳理和调研。

自顶向下的梳理方法
一般用在主数据咨询项目中，从企业战略分解到业务域划分，再到数据建模，层层递进，分析和梳理企业的主数据。
优势: 让企业对现有数据资源有个全面、系统的认识
有助于企业把握各类信息的源头，有效消除信息孤岛和数据冗余，控制数据的唯一性和准确性，确保获取信息的有效性。
缺点：成本较高，周期较长

自底向上的梳理和调研
一般是在主数据范围已确定的前提下，从企业信息系统人手，对已建系统、在建系统、待建系统的数据视图进行梳理和分析，识别出主数据在信息系统中的分布情况，理清数据的来源和去向、数据的管理现状等。另外，还需要对未在系统中管理的数据(我们常说的线下数据)进行整理和分析。
优点:针对性强，快速实施，成本和周期可控，快速见效。
缺点:梳理的数据不够全面和系统。这种方法适用于项目目标和范围相对明确的主数据管理项目。

主数据管理包含哪些模块？

数仓主数据小文件治理

小文件大小远小于blocksize的文件。具体大小看公司定义。

小文件的产生途径有哪些？

1.流式数据，如flume,kafak,sparkstreaming,storm,flink等，流式增量文件，小窗口文件，如几分钟一次等。
2.MapReduce引擎任务：如果纯map任务，大量的map；如果mapreduce任务，大量的reduce；两者都会造成大量的文件。出现这种情况的原因很多，比如分区表的过度分区，动态分区，输入大量的小文件，参数设置的不合理等，输出没有文件合并等。
3.spark任务过度并行化，Spark 分区越多，写入的文件就越多。
4.文件的压缩与存储格式不合理；一般生产公司很少使用textfile这种低效的文件格式了。使用压缩，降低文件的大小，同时也会降低文件的总块数。注意文件存储格式和压缩不合理只是加剧小文件问题，不是产生小文件的本质。

集群小文件的危害

小文件首先影响着整个集群的存户，不仅对namenode有影响，对datanode也有影响。其次小文件对计算性能浪费较大，同时拖慢任务执行时长。

小文件对namenod的影响

namenode的namespace中主要占存储对象是文件的目录个数，文件（文件名长度）以及文件block数。根据namenode实际使用经验来看，一个存储对象大概占用150字节的空间。HDFS上存储文件占用的namenode内存计算公式如下：

      Memory=150bytes*(1个文件inode+(文件的块数*副本个数))

     如上图1 ，一个文件192Mb，默认blocksize=128Mb，副本个数为3,存储为2个block,需要namenode内存=150*（1+2*3）=1050  Bytes

     同理，图2 一个文件192Mb，默认blocksize=128Mb，副本个数为3,存储为192个block，需要namenode内存=150 x (192 + (192 x 3)) = 115200 Bytes

总结：

同样的一个文件，大小不同形态的存储占用namenode的内存之比相差了109倍之多。所以如果对于单namenode的集群来说，大量的小文件的会占用大量的namenode堆内存空间，给集群的存储造成瓶颈。

当 NameNode 重新启动时(虽然生产上这种情况很少)，它必须将文件系统元数据fsimage从本地磁盘加载到内存中。这意味着如果 namenode 元数据很大，重启会更慢,其次datanode 还通过网络向 NameNode 报告块更改；更多的块意味着要通过网络报告更多的变化，等待时间更长。

同时更多的文件，更多的block,意味着更多的读取请求需要由 NameNode 提供服务,这将增加 RPC 队列和处理延迟，进而导致namenode性能和响应能力下降。官方介绍说接近 40K~50K RPCs/s 人为是极高的负载。实际使用来看比这低时对于namenode来说性能都会打很大的折扣。

小文件对datanode影响

大量的小文件，意味着数据着寻址需要花费很多时间，尤其对于高负载的集群来说，磁盘使用率50%以上的集群，花费在寻址的时间比文件读取写入的时间更多。

小文件对计算的影响

基于HDFS文件系统的计算，blokc块是最小粒度的数据处理单元。块的多少往往影响应用程序的吞吐量。更多的文件，意味着更多的块，以及更多的节点分布。

比如以MapReduce任务为例（hive等），在 MapReduce 中，会为每个读取的块生成一个单独的 Map 任务，如果大量小文件，大量的块，意味着着更多任务调度，任务创建开销，以及更多的任务管理开销（MapReduce 作业的 application master 是一个 Java 应用，它的主类是 MRAppMaster。它通过创建一定数量的bookkeeping object跟踪作业进度来初始化作业，该对象接受任务报告的进度和完成情况）。

虽然可以开启map前文件合并，但是这也需要不停地从不同节点建立连接，数据读取，网络传输，然后进行合并，同样会增加消耗资源和增加计算时间，成本也很高。

同样，如果是spark计算引擎，executor的一次读取和处理一个分区，默认情况下，每个分区是一个 HDFS 块，如果大量的小文件，每个文件都在不同的分区中读取，这将导致大量的任务调度开销，同时每个 CPU 内核的吞吐量降低。

总结：

小文件对于计算的影响就是需要大量节点之间频繁建立联系，数据传输等，浪费资源，消耗时间长。其次小文件相关大量的任务初始化时间甚至比计算时间还长，造成计算资源的使用浪费，降低集群的吞吐量。

Hive存量数据的小文件治理

1.合并小文件：对于日志文件等大量的小文件，可以使用Hadoop自带的合并工具将多个小文件合并为一个大文件。下面是通过hive的重写方式合并小文件，核心参数如下

set hive.input.format = org.apache.hadoop.hive.ql.io.CombineHiveInputFormat;
set hive.merge.mapfiles = true;
set hive.merge.mapredfiles = true;
set hive.merge.smallfiles.avgsize=256000000;
set hive.merge.size.per.task=12800000;
set mapred.max.split.size=256000000;
set mapred.min.split.size=64000000;
set mapred.min.split.size.per.node=64000000;
set mapred.min.split.size.per.rack=64000000;

2.压缩小文件

对于大量的小文件，可以使用压缩工具将多个小文件压缩为一个压缩包，以减少存储空间。例如，使用gzip或bzip2压缩工具压缩文件，在HDFS上存储压缩文件，以减少存储空间和文件数量；

3.删除无用小文件

对于不再需要的小文件，可以使用Hadoop自带的命令hadoop fs -rm命令删除文件，或者使用定时任务脚本定期删除过期文件；

4.spark小文件治理

Spark生成的文件数量直接取决于RDD里partition的数量和表分区数量。注意这里的两个分区概念并不相同，RDD的分区与任务并行度相关，而表分区则是Hive的分区数目。生成的文件数目一般是RDD分区数和表分区的乘积。因此，当任务并行度过高或者分区数目很大时，很容易产生很多的小文件。因此，如果需要从参数调整来减少生成的文件数目，就只能通过减少后一个阶段RDD的分区数来达到了（减少分区数目限制于历史数据和上下游关系，难以修改）
注：spark不支持参数化设置小文件合并。

总结：
    1：spark任务后面跟一个hive任务覆盖重写分区数据，将大量小文件合并成少量大文件
    2：改写spark代码，让spark支持小文件合并的参数化设置 

新增数据的小文件治理

新增小文件的治理技术扎口，对hive，spark等任务通过参数化配置避免小文件的产生。

主数据存储治理

大数据运维可以通过存储使用监控、僵尸文件管理、生命周期管理、存储格式压缩和数据模型调用等监控，全方位对集群的存储进行监控分析告警管理等。

库表层面-库表管理治理

生产库表生命周期管理

通过表生命周期模型，我们可以将表数据划分为几类：
频繁访问的热表、访问频次不是那么高的温数据、几乎不访问的冷表。
对于热数据，我们可以在其产出后，进行缓存预热，来提高查询效率；
对于冷数据，我们可以进行冷备、过期数据进行删除操作来节省存储。

一般要求所有库表都要上生命周期管理，禁止野蛮生长。

临时表的治理

临时表是数据ETL过程中用于提效加速的表，大体可分为三类：

1：相对固定的临时表，因其有多个下游需要用到，为避免重复计算、提升计算稳定性而设立。保存周期一般不超过3天
2：纯粹计算过程中短期使用的临时表，主要是用于数据加工过程中，避免单SQL过于复杂而导致计算不稳定问题而设立的，此类临时表需要在使用完成后立即进行删除
3：临时备份表，主要用于因需要使用自身数据进行自我更新，为实现作业的幂等性而独立备份的临时表，此类表保存周期一般不超过7天

超期未访问的数据治理

数据属主应当根据大数据平台所提供的访问记录，及时优化自己的数据模型、存储结构，具体分为：

1：减字段：低频访问字段可以删除
2：加字段：高频访问字段加入到模型中
3：分级存储：根据分区使用情况，对此表中的数据按热、温、冷三层进行分级存储，如高度压缩、归档等。
4：超期未访问的下线：长时间（连续45天，60,90天，180天，1年等）未被人使用，理应将此表进行下线处理，对于特殊的数据。如：信息安全要求、数据库归档等，用户需要主动在数据资产管理平台中进行数据标识白名单，由平台进行深度压缩归档处理。

大表专项治理

一般存储的与算力的成本按照4:6比例划分（服务器存储与算力的成本比值）

集群存储金额就是120万，算力180万。那么存储的直接成本是120w/200*1024TB=614元/TB/月=20.5元/TB/天。

一般按照二八原则治理。比如大表定义：存储超过30TB表，615元/天的表，这些占比集群总存储的80%。假设总共500张。优先对这些大表进行存储治理。

数据算力优化

对产出冷表的任务进行下线处理，来节省存储计算资源；

对任务进行计算引擎的自动升级，来提升其运行效率等。

无效和空跑任务的治理？

人多任务多会造成调度系统上比如项目都下线了，但是任务没有停止，或者测试任务没有及时下线等，或者人员离职，没有交接任务，无人认领任务，这种就属于典型的资源浪费，可以先停任务，比如停止几个月，然后没问题直接下线任务和库表。

孤老任务和孤儿任务治理？

定时任务生成的output表没有被任何其他任务使用，90天内也没有adhoc使用，或者定时任务使用的input表没有生产任务，且不是维表。
根据血缘关系进行定位排查，对其进行下线操作。

长期失败任务治理？

定时任务30天内失败5次及以上，这种任务大数据运维可以监控任务，比如通过调度系统的运行日志，集群的运行日志。查看日志分析失败原因。
失败的原因可能是数据量资源不足oom，数据倾斜，任务依赖配置冲突等（比如通过时间依赖，而不是节点依赖）

数据倾斜任务治理？

检测到有数据倾斜任务，比如10%的task执行时间超过task平均执行时间一倍以上的任务
治理方式： 代码改造，参数优化等

大任务治理|任务运行时长大于3小时任务？

治理类型：定时调度项目Job 运行耗时超过2/3小时,具体结合实际；
治理方式： 任务代码拆分，落临时表，比如禁止超过5个以上的join。保障调度上单个任务的执行时长小于3小时，或者做一些任务优化等。

读写文件过大任务治理？

治理类型：读写异常任务：读HDFS大于 5T，或者比如写HDFS大于1t,主要确定任务读写数据是否合理，是否需要全表扫描或者分区裁剪是否生效等。

治理方式： 结合实际确认分区裁剪，列裁剪等是否生效，其次任务消耗过多资源，是否可以进行任务链路优化，比如提前过滤，提前聚合等方式。

任务资源参数配置不合理任务治理？

治理类型：任务的每个task申请的资源的内存和cpu利用率过低

主数据链路优化

全链路治理包含哪些方面？

全链路治理最重要的就是对全链路进行监控，监控数据链路中的任务、服务的运行情况，并收集相应的metrics，比如任务的资源使用情况，实时任务的消息延迟、批任务的执行时长、HDFS的整体存储水位、Yarn集群的资源使用情况，模型的质量，模型的评分等

什么是数据链路治理？

数据产生的链路长度，数据的流转，任务层面的治理居多

为啥企业要做数据链路治理？

实际企业中数据从集成到最终被使用的链路非常长，而且中间依赖包括计算/存储/调度等很多服务和组件。

离线数据常见的问题

数据延迟：由于集群故障或者任务执行问题，数据出现延迟，严重的情况下会导致滚雪球现象，前序数据延迟会导致后续节点依次延迟。
数据异常：数据出现缺失或者大的变动导致报表计算不准确
数据不一致：上下游数据不一致，如上游某些数据重跑，未及时通知下游，造成数据不一致的情况
同名不同义问题：如同一个字段，在不同的表里可能有不同的含义，用户使用中会产生歧义。使用指标系统，对所有指标给定唯一定义，相关指标上线修改等需进行审核；
数据源差异：通过统一数仓管理底层数据输出。

实时链路常见问题

断流；
流量突增突降；
处理延迟；
消息堆积。

数据链路治理的目标？

离线链路治理的目标是：
准确性：优先保障数据的准确性和可用性；
时效性：要保证数据在约定的时间之前产出。

实时链路治理的目标是：
时效性：实时数据对时效性的要求更高；
准确性：数据是准确性高的、高可用的。

离线数据链路治理的落地？

数据稳定性：对重要的数据节点，包括ODS层、反作弊层、统一数仓等进行双集群HA处理，保证数据稳定产出；
对核心业务均进行双集群部署，每个集群都会部署独立任务进行处理，在正式产出任务结果之前，会将集群数据写入HA服务（临时表），一般按照哪个集群优先产生结果，另一个集群进行同步的方式进行处理。采用双集群HA部署后，整体数据延迟或数据故障率会大幅降低。

实时数据链路治理?

数据治理成熟度与考核标准

DCMM结构组成

DCMM模型，按照组织、制度、流程、技术对数据管理能力进行了分析、总结，提炼出组织数据管理的八大过程域，即：数据战略、数据治理、数据架构、数据应用、数据安全、数据质量管理、数据标准、数据生命周期。这八个过程域共包含28个过程项，441项评价指标。

关键领域定义

组织数据能力被综合定义为八大一级过程域，其中每个一级过程域又有若干二级过程域来组成， DCMM中通过对每个二级过程域的概念、目标以及功能的定义来标准化组织数据管理的过程。在进行数据 能力评估的过程中，每个一级过程域相互独立，可以独立开展评估，但是，在实际的管理过程中，每个 一级过程域又相互支撑，需要统一全面开展才能完善数据管理体系。

数据战略：数据战略规划、数据战略实施、数据战略评估
数据治理：数据治理组织、数据制度建设、数据治理沟通
数据架构：数据模型、数据分布、数据集成与共享、元数据管理
数据应用：数据分析、数据开放共享、数据服务
数据安全：数据安全策略、数据安全管理、数据安全审计
数据质量：数据质量需求、数据质量检查、数据质量分析、数据质量提升
数据标准：业务数据、参考数据和主数据、数据元、指标数据
数据生存周期：数据需求、数据设计和开放、数据运维、数据退役

数据战略

数据战略是组织中数据工作开展的目标指引，定义组织数据工作的方向、愿景和原则。数据战略包括数据战略规划、数据战略实施、数据战略评估等三个二级域，从组织数据战略的规划、实施和评价等方面对数据战略进行描述。

数据治理

数据治理是数据管理框架的核心职能，是对数据资产管理行使权利和控制的活动集合，数据治理涉及到数据管理的组织，标准规范，流程，架构等多个方面，和数据管理的其他关键过程域都有交互，数据治理是在高层次上制定、执行数据管理的制度。

数据架构

数据架构是用于定义数据需求、指导对数据资产的整合和控制、使数据投资与业务战略相匹配的一套整体构件规范。数据架构包括数据模型、数据分布、数据集成与共享和元数据管理四个二级职能域， 数据模型职能域定义与规范业务经营、管理和决策活动需要的组织数据需求，数据分布职能域确定各类数据资产在组织内部的合理部署，数据集成与共享职能域实现组织的各类数据资产在组织内整合在一起，元数据管理是关于元数据的创建、存储、整合与控制等一整套流程集合。

数据应用

数据应用是指通过对组织数据进行统一的管理、加工和应用，对内支持业务运营、流程优化、营销 推广、风险管理、渠道整合等活动，对外支持数据开放共享、数据服务等活动，从而提升数据在组织运 营管理过程中的支撑辅助作用，同时实现数据价值的变现。

数据安全

数据安全是指组织中的数据受到保护，没有受到破坏、更改、泄露和非法的访问。数据安全主要包 括数据安全策略、数据安全管理和数据安全审计等三个过程域，从制度、管理和审计三个方面来提升组 织数据的安全性。

数据质量

数据质量是指数据的适用性（fitness for use）,描述数据对业务和管理的满足度。数据质量主要是指数据的准确性、及时性、完整性、唯一性、一致性、有效性等六个方面。数据质量管理是通过对数据的分析，监控，评估和改进的过程。

数据标准

数据标准是组织数据中的基准数据，为组织各个信息系统中的数据提供规范化、标准化的依据，是组织数据集成、共享的基础，是组织数据的重要组成部分。依据数据特性的不同，可以把数据标准具体划分为四大类：业务术语标准、参考数据和主数据标准、数据项标准、指标数据标准。

数据生命周期

数据生命周期是指数据从设计、开发、创建、迁移、应用、存档、回收的周期、再次激活以及退出的整个过程，对数据进行贯穿其整个生命的管理需要相应的策略和技术实现手段。数据生命周期管理的目的在于帮助组织在数据生命周期的各个阶段以最低的成本获得最大的价值。

DCMM的能力等级划分

与CMMI类似，DCMM模型将组织的数据能力成熟度划分为初始级、受管理级、稳健级、量化管理级和优化级共5个发展等级，帮助组织进行数据管理能力成熟度的评价。