数据治理理论 + 实践
数据治理是什么?为什么要做数据治理?关于数据治理我们需要做什么?
数据治理无论是在数仓建设过程中还是数仓建设完成之后都是及其重要的,是数据部门基础建设的必经之路,是降本提效,形成企业数据资产的关键一环
一 数据质量管理
1.1 数据质量基本概念
-
数据质量管理(Data Quality Management),是指对数据从计划、获取、存储、共享、维护、应用、消亡生命周期的每个阶段里可能引发的各类数据质量问题,进行识别、度量、监控、预警等一系列管理活动,并通过改善和提高组织的管理水平使得数据质量获得进一步提高
-
数据质量管理不是一时的数据治理手段,而是循环的管理过程。其终极目标是通过可靠的数据,提升数据在使用中的价值,并最终为企业赢得经济效益
1.2 影响因素
数据问题的来源可能产生于从数据源头到数据存储介质的各个环节。在数据采集阶段,数据的真实性、准确性、完整性、时效性都会影响数据质量。除此之外,数据的加工、存储过程都有可能涉及对原始数据的修改,从而引发数据的质量问题。所以,技术、流程、管理等多方面的因素都有可能会影响到数据质量。
在企业中,随着企业业务的增长,数据也是一个增量积累的过程。随着数据类型、数据来源的不断丰富以及数据数量的快速增长,企业在数据管理工作和数据流程中面临越来越多的数据质量问题。而且数据质量的管理并没有被企业重视起来,其根本原因还是ROI并没有那么明显。
数据质量管理相对来说成本比较高。因为它涉及到企业数据标准的制定、规范的落地、生命周期的管理等多个环节。从收益上来说,数据质量的效益和结果并不是十分明显,大部分企业不会把数据质量作为KPI。在企业的不同系统中,业务领域的关键指标不一致,数据无法共享导致出现数据孤岛,大量数据无法关联,并且有明显的数据冗余等问题,还有数据的维护需要投入大量的人员、时间、软硬件成本。所以数据的质量管理往往被会边缘化甚至趋向于无。
在此附上数据的生命周期图,包括各环节的数据流转和数据处理。
1.3 评估维度
-
完整性
数据完整性问题包含数据条目不完整,数据属性不完整等
-
一致性多源数据的数据模型不一致,如命名不一致,数据编码不一致,含义不一致,生命周期不一致等
-
准确性准确性也叫可靠性,不可靠的数据可能会导致严重的问题,会造成有缺陷的方法和糟糕的决策
-
唯一性
用于识别和度量重复数据,冗余数据,重复数据是导致业务无法协同, 流程无法追溯的重要因素,也是数据治理需要解 决的最基本的数据问题
-
关联性数据关联性问题是指存在数据关联的数据关系缺失或错误,例如:函数关系、相关系数、主外键关系、索引关系等。存在数据关联性问题,会直接影响数据分析的结果,进而影响管理决策。
-
真实性
数据必须真实准确的反映客观的实体存在或真实的业务,真 实可靠的 原始统 计数据是企业统计工作的灵魂,是一切管理工作的基础,是经 营 者进行正确 经营决策必不可少的第一手 资料。
-
及时性数据的及时性(In-time)是指能否在需要的时候获到数据,数据的及时性与企业的数据处理速度及效率有直接的关系,是影响业务处理和管理效率的关键指标。
-
逻辑检查不同表字段之间可能会有逻辑关联,需要稽核
-
离群值检查部分数据可能会偏离其他数据,比如同一个商品金额大家都是100元,而有一条数据是1W
-
自定义规则由需求方自定义相关规则
-
波动稽核
与上周环比稽核波动情况
-
强弱规则
每个规则的权重应该是不一样的,需要配置优先级,这对后续的告警方 式是有帮助的
我们最终的目的是希望做到页面可配置
1.4 实施流程
1.4.1 事前定义质量规则
-
梳理表,字段等信息
-
确定资产等级
-
制定检验规则
-
数据探查
1.4.2 事中监控数据质量
-
在数据抽取过程中,可以对数据进行数据量稽核及唯一性,非空性稽核
-
etl过程对脏数据进行清洗,保证数据质量
-
指标计算过程中,可以对指标进行波动值稽核,保证指标变化在合理范围内
以上如果有异常都需要邮件短信报警,对应负责人根据优先级判断是不是需要及时处理
1.4.3 事后分析和问题跟踪
每周定时跑一次程序,对全局数据进行质量稽核控制,如唯一性,非空性等
对于程序跑出来的数据:
数据质量概览在数据质量管理系统查询
数据质量明细数据在数据质量管理系统查询
根据异常数据统计出来的各种数据质量报表也可以在数据质量管理系统查询,包括表覆盖率,历史趋势,综合分析,排名分析等(质量报告支持导出为word,pdf,excel)
对异常进行评估、严重程度、影响范围、问题分类等
可以订阅自己比较关心的主题,表或者规则,邮件只会发送订阅内容
对于打分比较低的表或者业务,可以反推业务方进行整改
1.4.4 重大问题告警
1.警告
邮件短信通知
2.数据整改
问题跟踪处理,故障review,一周内处理完成
a.订阅
b.给表及业务进行评分
c.核心字段勾选
以上是在公司规模比较大的情况下,会开发的数据平台,里面会有数据质量管理模块,会有对应的页面进行配置,当然底层其实也是使用的sparksql或者sparkcore实现的。在开发资源比较紧张或者目前不太注重平台这一块的时候,只有自行开发python脚本去监控一些数据质量了,如空值率,波动值,数据量等
飞书群监控消息:
1.5 总结
数据质量管理贯穿数据生命周期的全过程,覆盖质量评估、数据监控、数据探查、数据清洗、数据诊断等方面。数据源在不断增多,数据量在不断加大,新需求推动的新技术也不断诞生,这些都对大数据下的数据质量管理带来了困难和挑战。因此,数据质量管理要形成完善的体系,建立持续改进的流程和良性机制,持续监控各系统数据质量波动情况及数据质量规则分析,适时升级数据质量监控的手段和方法,确保持续掌握系统数据质量状况,最终达到数据质量的平稳状态,为业务系统提供良好的数据保障。
二 数据安全管理
1.数据脱敏(udf函数)
数据脱敏是保证数据安全的最基本的手段,脱敏方法有很多,最常用的就是使用可逆加密算法,对入仓每一个敏感字段都需要加密。比如手机号,邮箱,身份证号,银行卡号等信息
2.数据权限控制
需要开发一套完善的数据权限控制体系,最好是能做到字段级别,有些表无关人员是不需要查询的,所以不需要任何权限,有些表部分人需要查询,除数据工程师外,其他人均需要通过OA流程进行权限审批,需要查看哪些表的哪些字段,为什么需要这个权限等信息都需要审批存档。
3.程序检查
有些字段明显是敏感数据,比如身份证号,手机号等信息,但是业务库并没有加密,而且从字段名来看,也很难看出是敏感信息,所以抽取到数据仓库后需要使用程序去统一检测是否有敏感数据,然后根据检测结果让对应负责人去确认是否真的是敏感字段,是否需要加密等。
4.流程化操作
流程化主要是体现在公司内部取数或者外部项目数据同步,取数的时候如果数据量很大或者包含了敏感信息,是需要提OA 审批流程的,让大家知道谁要取这些数据,取这些数据的意义在哪,出了问题可以回溯,快速定位到责任人。开发外部项目的时候,不同公司之间的数据同步,是需要由甲方出具同意书的,否则的话风险太大。
5.敏感SQL实时审查及操作日志分析
及时发现敏感sql的执行并询问责任人,事后分析操作日志,查出有问题的操作。
6.部门重视数据安全
把数据安全当做一项KPI去考核,让大家积极的参与到数据安全管理当中去。
三 元数据管理及应用
3.1 概述
元数据通常定义为”关于数据的数据”,元数据贯穿了数据仓库的整个生命周期,使用元数据驱动数据仓库的开发,使数据仓库自动化,可视化。元数据打通了源数据、数据仓库、数据应用,记录数据从产生到消费的全过程。
例如我们看一部电影,电影本身就是数据,那么元数据就是用来描述这部电影的数据。如下图所示:
元数据主要记录数据仓库中模型的定义、各层级间的映射关系、监控数据仓库的数据状态及 ETL 的任务运行状态。在数据仓库系统中,元数据可以帮助数据仓库管理员和开发人员非常方便地找到他们所关心的数据,用于指导其进行数据管理和开发工作,可以极大的提升工作的效率。
3.2 元数据定义
将元数据按用途的不同分为两类:
-
技术元数据(Technical Metadata)
-
业务元数据(Business Metadata)
3.2.1 技术元数据
技术元数据是存储关于数据仓库系统技术细节的数据,是用于开发和管理数据仓库使用的数据。常见的技术元数据有:
1.存储元数据:
如表、字段、分区等信息。记录了表的中英文名及表状态。分区信息、责任人信息、对应主题,文件大小、表类型,生命周期,权限信息
记录列的字段中英文名、字段类型、字段备注、是否是分区字段,保密级别及权限信息等信息。
2.运行元数据,
如大数据平台上所有作业运行等信息:类似于 Hive Job 日志,包括作业类型、实例名称、输入输出、 SQL 、运行参数、执行时间,执行引擎等。
3.数据开发平台中数据同步、计算任务、任务调度等信息
包括数据同步的输入输出表和字段,以及同步任务本身的节点信息:计算任务主要有输入输出、任务本身的节点信息 任务调度主要有任务的依赖类型、依赖关系等,以及不同类型调度任务的运行日志等。
4.数据质量和运维相关元数据,如任务监控、运维报警、数据质量、故障等信息,包括任务监控运行日志、告警配置及运行日志、故障信息等。
3.2.2 业务元数据
业务元数据从业务角度描述了数据仓库中的数据,它提供了介于使用者和实际系统之间的语义层,使得不懂计算机技术的业务人员也能够读懂”数据仓库中的数据。
常见的业务元数据有维度及属性(包括维度编码,字段类型,创建人,创建时间,状态等)、业务过程、指标(包含指标名称,指标编码,业务口径,指标类型,责任人,创建时间,状态,sql等),安全等级,计算逻辑等的规范化定义,用于更好地管理和使用数据。数据应用元数据,如数据报表、数据产品等的配置和运行元数据。
3.3 元数据管理
对于元数据管理,目前来说有三种方式可供选择。
3.3.1 Excel手工录入保存
对于规模比较小,并且业务不大的公司,可能会用这种方式,但是这种方式太古老,且容易出错
3.3.2 自研系统
自研元数据管理系统或者在数据平台开发元数据管理模块
很多公司会自研元数据管理系统或者相关模块,直接读取hive元数据或者数据平台配置的任务及调度元数据进行展示,相比较Excel人工导入,会更智能一点,但是相对于Atlas,成本更高且效果不一定有Atlas好,很多时候也需要批量导入和手工录入
3.3.3 Atlas元数据管理(常用)
Atlas 是一个可伸缩且功能丰富的元数据管理系统,深度对接了 Hadoop 大数据组件。
简单理解就是一个跟 Hadoop 关系紧密的,可以用来做各类数据的元数据管理的一个软件系统;
atlas本身从技术上来说,就是一个典型的JAVAWEB系统,其整体结构图如下所示:
核心组件
-
Core
-
Integration
-
Metadata source
-
Applications
核心特性
-
数据分类管理
-
集中审计
-
搜索与血缘管理
ATLAS的使用,包含两个方面:
注入元数据信息到atlas中(本质是:写入元数据到atlas中)
-
注入方式1:通过atlas为数据系统开发好的hook来注入
-
注入方式2:通过atlas自带的WEB-UI来人工填写元数据信息再注入
-
注入方式3:通过在自己的数据系统中调用atlas对外暴露的api,来灵活注入
使用atlas中的元数据信息来为我们服务(本质是:从atlas中读、改元数据)
-
方式1:通过atlas自带的WEB-UI前端系统来查看、修改元数据
-
方式2:通过调用atlas对外暴露的api,来开发自己的管理系统
3.4 元数据应用及价值
1.基于调度元数据的数据模型设计及优化--跨层引用率及复用度
2.基于技术元数据的数据模型设计及优化--主题覆盖率
3.基于技术元数据的成本优化 --生命周期,运行时长,资源消耗(存储,计算)
4. 基于元数据生成的数据地图可以对整个数仓的一些表,任务有一个全面的了解,可以通过数据地图让其快速找到所需要的数据
5. 数据血缘,追踪表血缘甚至字段血缘,可以极大的提高我们排查问题的效率
6. 基于业务元数据,可以了解目前每个业务涉及到的维度及指标,每个指标的业务口径,指标类型,创建人及指标状态等
四 数据成本治理
4.1 为什么要做成本治理
最主要的原因应该是减少企业成本,让企业走提效降本的可持续发展道路。
4.2 目前存在的问题
4.2.1 机器利用率低
比如所有任务都是在晚上跑,白天机器大部分空闲,直接导致资源浪费,利用率非常低
4.2.2 存储周期过长,存储资源增长过快
有的表,大家没有设置生命周期,或者没有定时删除分区,导致分区太多,数据膨胀,存储资源需要补充
4.2.3 成本没有量化标准
用阿里云服务器还好,会有实际的账单,但是如果是自己买的服务器搭建的大数据生态,可能不知道怎么去量化成本,然后做成本治理
4.2.4 降本意识薄弱
数据开发或者需求方,没有成本治理的意识,满足需求后就没有进一步优化
4.2.5 任务优化空间非常大,尤其是离线计算
数据开发的开发水平参差不齐,所以对于任务来说,是有非常大的优化空间的,可以从各方面取调优,比如数据倾斜,小文件,存储,压缩
4.3 问题解决
4.3.1 延迟启动
优先级比较低的任务可以设置执行时间为白天,避免晚上任务运行高峰期抢占资源,做到错峰执行
4.3.2 任务下线
通过数据地图,找出无用数据或者是用频次很低的数据,跟业务方沟通后及时下线
4.3.3 任务调优
数据倾斜,存储压缩,小文件优化等方面调优
4.3.4 修改执行周期
很多时间,我们的任务不但有实时,t+1,甚至还会有小时任务,每小时跑一次,众所周知,这是非常占资源的,我们要和业务方,需求方取沟通,看一下没必要的小时任务是否可以转化为日任务
4.3.5 账单排名,促进优化
我们可以通过每个月的成本账单,按照业务线和开发或者其他维度去做排名,督促相关人员进行优化整改
4.4 治理效果分析
4.4.1 总览
可以看一下总的成本,以及趋势
4.4.2 topn
取出排名靠前的一些业务或者开发的成本账单
4.4.3 各业务线成本
按照业务线取分析成本
4.4.4 成本明细分析
拆分到各个任务取分析成本