数据治理精华版本

数据管理协会知识体系 – DAMA-DMBOK2 (十大职能域)

DCMM：数据管理能力成熟度评估（2018）

数据资产管理实践白皮书（信通院）

理论支撑

数据治理是对数据资产管理行使权力和控制的活动集合（规划、监控和执行）。

概念

需求层次

数据质量、标准规范、成本控制、数据安全、研发及管理效率

数据治理需要治理哪些问题

数据治理概念

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

数据治理咨询成果落地不足

业务人员使用数据更多需要数据和技术人员的贴身服务，按照IT建设的模式提出数据加工需求或者取数需求，以被动支持的方式满足业务需求，没有形成数据资产目录，数据服务目录

自动化服务程度不高

缺少量化方式来评估数据治理成熟度水平，数据治理工作的推动成效无法体现，变成了纯手动的脏活累活，严重影响数据治理工作的开展推进

数据治理成效可视度低

缺少灵活友好的数据治理在线管理工具，来支持数据治理全流程工作数据治理与数据原仓之间没有打通，“数据的描述”和“数据的记录”两张皮

数据治理在线管理能力不足

痛点

标准化规范缺失：数据⽣产、存储和应⽤各环节的流程，规范⽆统⼀标准

数据质量问题多：数据冗余多，数据烟囱式建设，指标⼝径乱，⽆法保证数据⼀致性

数据安全控制弱：数据⽣产和查询权限⽆统⼀规则，数据密级⽆统⼀管理

数据管理和运维效率低：数据使⽤问题的咨询多，数据RD需要花费⼤量时间解答业务同学的问题

问题

数据治理痛点和问题

核心目标：数据资产化、数据价值释放

自上而下：从公司治理角度入手来解决数据的管理问题，提供足够的授权和支持

自下而上：以平台技术支撑和完善的运营体系促进治理的切实落地

总述

固定的专业组织、充分赋权，负责数据治理实施的整体推进。制规范 定目标 促落地 保健康

从实践中总结制定一系列的管理办法、流程和规范，并及时演进迭代

数据资产治理规范：1管理办法；2管理流程3技术规范及模板

制度保障

组织体系（组织建设、制度保障）

数据运营思想贯穿数据建设全过程

数据资产治理方法论（产出及时、质量可靠、易找易用、安全可控、生产经济）

健康分：存储健康分、计算健康分

成本账单：每周发送详细的、成本账单给具体、资源使用人

专项行动：针对成本治理的“雷 霆行动”;构建BU治理排行榜

构建量化的数据治理评价体系，日常治理运营和专项整治相结合，促进治理工作持续落地改进

运营 

平台工具支撑&运营

理论

数据治理策略

从传统架构思维向DT架构思维转变，围绕数据资产化、数据价值释放的核心目标开展工作

以IT流程驱动，以IT支撑位中心，以数据为基础

以传统4V为基础构为基础

授之以网（打鱼的工具）

需求和数据为导向

传统架构思维

以商业问题和业务场景为驱动，以数据资产为核心

以问题、数据、生产、创新\"四维\"度为基础

授之以渔（提供打鱼的方法及工具）

问题和数据价值为导向

DT架构思维

变思维：转变传统思维定式，IT思维向DT思维转型变模式：工具和技术是生产工具，数据才是核心，IT流程不是核心变定位：摆脱成本中心泥潭，通过运营数据资产，探索如何成为利润中心

企业数据治理新模式

解决数据产出及时性和准确性

1.数据稳定性与质量治理

解决数据口径一致性问题

2.数据规范治理

解决数据权限控制与数据共享交换问题

3.数据安全治理

解决数据计算和存储成本高昂问题

4.数据成本治理

数据治理实施的阶段

千万级任务的调度情况下，调度依赖关系复杂程度远超过人工处理程度，独有智能基线监控机制确保高优先任务高保障产出。

监控数量:监控所有任务是不现实的配置难度:为每个任务配置监控规则极为繁琐告警时间:每个任务所需告警的时间都不同

监控告警的痛点

智能识别关键路径，合理设定告警阈值任务异常产生事件，自动评估事件影响范围，通知相应人员灵活告警方式配置，支持钉钉群机器人、电话

智能监控核心功能 

监控预警图

数据稳定性

数仓规范性差、数据⼀致性问题多、数据应⽤⽆法把控、多个产品中指标逻辑不同

数据质量体现主要问题

通过完整性、有效性、准确性、唯一性、一致性、合理性的全面评估，产出可信的、高价值密度的数据资产

质量评估

模板规则：表主键唯一、字段空值检查、字段枚举值检查 以及自定义规则

•质量监控与调度挂钩，第一时间发现问题； 40+规则&自定义规则，精细化质量控制； 无需设定阈值，算法自动判断异常值•故障快速恢复

质量治理图

核心公共层数据资产：1）做规范管控，架构评审，发布管控2）评估建设水平3）发现短板，持续改进

一条门槛线 1）确定标准、流程及规范 2）筛选核心公共层监控范围并持续更新

核心公共层数据 

通过规范设计和开发来预防问题的发生。统一公共层来减少重复建设和确保口径一致性。

数据规范设计

高内聚低耦合

公共计算逻辑下沉

实际原则

数据模型设计

数据处理任务设计

数据服务开放

数据规范治理

数据质量治理

方针：1.事前（标准化规范）--》事中（配置化开发）--》事后（规则化验证）2.通过制定码表、元素、模型分层、数据模型等设计规则及字段内容质量约束，保证逻辑数据模型设计的一致性

主题域划分

数仓分层

逻辑命名规则：

表字段命名、类型、词根

公共维度、关联关系

制定各类数据实体（元素、码表、 模型分层、模型等）的设计约束，规范每类业务实体包含的属性、该 属性是否必选、该属性内容约束等规则。

标准编码规范

中英文缩写规范

物理模型规范

模型设计规范

开发流程规范

很多任务会直接读写文件，导致数据血缘缺失。为达到一个完备的数据血缘，新的规范会强制要求所有人要在读写表的基础上进行。任务会有纯SQL，或者是SQL和API结合的方式。为了统一开发规范和流程，降低运维成本，新规范要求公共层模型必须用纯SQL来执行，并且我们定义了一个SQL规范来去执行。多表和多任务可能会合并到一个workflow里面去，导致一个workflow里可能有几十个甚至上百个任务节点，对任务管理造成了比较大的影响，也不利于性能和资源分析，因此我们要求一个workflow只能输出一个正式表，额外的好处是任务的查找也变得更加方便。多workflow间通过数据检查依赖去执行的方式，对运维也造成了一定影响。比如任务出现了失败或者异常如何快速做数据恢复。在新的规范里，我们基于开发平台做跨流任务依赖，以此构建任务血缘，进而有效地进行基线诊断和运维

代码编写

模型开发规范

标准化规范

模型基础信息

数仓主题和分层

ETL代码⽣成

模型开发工具

模型命名标准化

⾃动命名标准化

命名规则⼯具

数仓规范性监测

数据依赖监测

上线规则监测⼯具

配置化开发

数据⾎缘

数仓相似度

数仓规范监控

数仓规范报告

数据冗余报告

规则化验证

数据标准管理

事前预防-权限管控： 数据密级规范、权限审批规范

事中监控-数据安全：数据脱敏 、查询权限控制、 查询风险监控

事后追踪-应⽤审计：查询和下载、日志数据使用审计

方针：事前预防、事中监控、事后追踪

密文处置原则，所有高敏感的数据都要密文传输

最晚解密原则，在应用层产品使用的话，不要在数据仓库层解密

最小范围提取原则，如果只用一万条数据只能对一万条数据解密

最小授权原则，用多少给多少

全程审计原则，从系统流出到使用全过程都是有措施保障

数据使用原则

数据源头层 生成过程加密、数据存储层分层脱敏/加密、数据使用层全程监控审计；通过三层系统控制加五个使用原则实现。从数据产生的源头业务系统里就会将一些非常敏感的用户数据加密，数据仓库层会对各分层的数据进行脱敏和二次加密，第三层专门做一些数据审计，在数据使用全流程中提供信息提示和审计报告。

数据分层管控

数据分类分级与权限控制

敏感数据发现与脱敏：基于元数据，识别需要脱敏的数据，自动脱敏或者给用户筛选需要脱敏的数据列

可信计算环境

数据风险审计

策略

数据安全治理

设定组织成本目标--》培养个人成本意识--》计算存储成本-》成本治理评估与运营

冷数据治理、重复数据治理、数据生命周期管理、存储格式压缩

存储类

无效任务治理、提高资源满用率、资源统一管理

拆解执行过程，降低任务的失败或者延迟恢复的成本。因为某一个节点失败之后，可能我们只需要从这个节点重新进行恢复，不需要重新执行整个任务，因为有时候重新执行整个任务需要好几个小时

避免做过度拆解，因为可能多余的任务启动和IO的过程反而会导致效率的下降

需要缓存的中间结果拆解。要考虑先做子节点的拆解，避免重复计算

尽量避免拆解为串行任务。拆为串行任务并没有优化整个执行过程，反而导致了多余任务启动还有IO过程的问题

依赖产出不稳定的多个部分拆解。比如将上游产出不稳定的部分拆分为多个节点，这样就能够降低上游任务的影响，分散计算资源占用的时间

超长任务优化：

数据任务依赖数据链路一致，DAG

shema的定义，字段相似度高

数据探查，安全组规则扫描，数据抽样比对

相似数据模型治理

计算类

日志下游应用监控、日志上报方式优化、无效埋点优化

日志采集类

成本精细化拆分

整体的方案策略方面做了精细化拆分，比如按租户（每个业务线的用户）来看，租户下有队列，队列有离线、有实时。队列下面有计算、存储、采集，计算之中又分离线、实时，有些配置量、使用量。这样可以非常容易地定位到哪些租户、哪些数仓是有问题的，对应快速治理。这方面也做了很多系统化的事情，比如有一个数据冗余判断的逻辑，每次做完数仓建模之后，会做冗余判断。元数据生成之后进行预处理，根据现有的数据做预判，看是否已存在。通过配置的对比逻辑，如果认为数据重复，会做标记并每周推送到数据治理的看板上，及时将冗余数据治理掉。

数据成本治理

找不到，不知道数据有没有、在哪里。

看不懂，有很多业务方不是技术研发团队的，看不懂数据到底什么含义、怎么关联查询、来源于哪个业务系统

不会用，如何写SQL或者哪些产品里面能查询到自己想要的数据指标。

面临问题

目标：找得到、看得懂、用得对

构建数据使用指南系统 

根据PDCA原则，将数据治理作为日常运营项目做起来，底层依赖数据指标体系进行监控，之上从发现问题到提出优化方案，然后跟进处理，再到日常监控构成一个循环

措施

数据运营

数据治理实践

数据从⽣产、加⼯到服务整个链路很⻓，任何⼀个环节都可能存在需要治理的问题，如何标准化？

链路⻓，问题多并且分散，⽆法聚焦

问题如何量化？并且治理了⼀段时间，结果怎么衡量？

怎么衡量资产好坏，治理到什么程度算好

治理进⼊深⽔区了怎么办？如何动态调整治理的⽅向？

应该重点解决哪些问题，并且不同阶段的治理侧重不同

怎么提⾼意识并驱动各个团队进⾏治理？

治理动⼒不⾜

数据治理面临挑战

⽬标：问题标准化、治理可量化、过程策略化、运营有抓⼿

策略：

可度量、业务相关、趋势分析阈值设定

衡量指标制定原则

在监控方式上分为日常监控和定期监控（周、月、季度监控），让我们知道整体数据治理是整体向好、平稳还是向坏的

指标监控分周期

基于元数据的衡量指标体系

制定数据衡量指标体系，总体分为五大类：质量类、成本类、安全、易用性和价值，衡量数仓治理的效果

⽆数据可⽤、⼝径不⼀致、分析效率慢

模型问题

模型设计阶段：需求/口径统一管理、模型设计规范、指标定义与管理规范、模型评审

模型生产阶段：模型设计/开发规范检查、数据测试报告、任务发布规范检查、数据监控规范检查

模型服务目标：资产丰富、数据好找、数据好用

解决方案

规范性：定义规范、开发规范、测试规范、发布规范、元数据规范

复⽤性：模型宽度、模型深度

完整性：跨层引⽤率、明细表查询占⽐、汇总表查询占⽐

评估

模型

链路⻓，问题多、意识差，被动发现、

质量问题

数据源质量保障：数据源规范生产；数据源监控；变更同步；影响分析

加工链路质量保障：引擎稳定性保障、模型设计规范检查、代码规范检查、数据测试保障、发布规范检查

线上监控质量保障：基线保障、数据质检、监控完整度检查、监控报警准确率保障

质量问题处理流程：质量问题提报-》质量问题分析-》 跟进/解决/验证-》 故障定级/复盘-》 专项问题改进

不规范Case数(避免发⽣)：埋点规范覆盖率、模型设计规范覆盖率、开发规范覆盖率

监控发现问题占⽐（主动发现）：数据源监控覆盖率、完备监控覆盖率、监控报警准确率

质量故障/问题数（结果指标）：准确性故障/问题数、时效性故障/问题数、基线破线次数、故障/问题⽌损效率

质量

体量大，管理难、缺少成本意识、数据只上不下

⼤数据引擎优化：HDFS EC、数据重分布、冷数据存储、资源调度优化

数据建设过程优化：数据资产分级存储、数据⽣命周期管理、重复建设检测、任务优化、极限存储

成本运营管理：Quota管理、成本账单、治理榜单

⽆效存储量：N天0热度；分区数据重复

⽆效计算量：N天0热度；N天⽆产出；重复模型计算

异常存储量：⽣命周期不合理；未EC；未压缩；待归档冷数据；分区数据相似

异常计算量：任务失败次数过多；申请计算资源过⼤；⼩⽂件过多；Map数过多；不合理⼩时任务

待治理成本资源量

成本

得分策略

资产健康评估

运营机制

治理收益评估

数据治理评估体系

数据治理评估

阶段性治理，没有统筹考虑，主要是基于单个问题的治理，而且治理之后过一段时间可能要做重复治理。这个阶段更多是人治，一个项目成立，协调几个人按照项目制完成，没有体系规划也没有组织保障

被动治理

有长期的统筹规划，能覆盖到数据生命周期的各个链路，在治理过程中把一些手段和经验流程化、标准化、系统化，长期解决一些数据问题，让数据治理长期可控

主动治理

希望长期规划和数据生命周期个环节链路确定好之后，把已经有的经验、流程和标准做成策略。一旦出现问题，自动监控，通过一些系统化的方式解决。自动治理的第一步还是治理方案的落地和策略化，这就非常依赖于元数据，把数据治理各个过程中的一些经验技术都沉淀起来。做完策略沉淀之后做自动化，把策略用工具的方式实现，当系统发现数据有问题时，自动去处理

自动治理（智能治理）

数据治理未来规划

数据治理