关于数据治理的一些梳理

2023-03-27 22:50 浏览量:2080

01

背景

 
 
 

 

任何一个系统,为了保证其良好地运行下去,一定是需要持续的维护和治理,数仓也不例外。本文主要分享下从规范、计存、质量、安全几块入手对现有数据资产进行的一些治理的思路和方案。而且数据治理是一个权级非常高,规范性,持续性要求高,涉及治理项非常繁多的活,需要成立专门的数据治理委员会,部门负责人、业务负责人进行牵头、实施和推进,需要和公司多着部门进行沟通协调、制定要求和规范、梳理出具体的治理项才能有序的落实和推进...

数据治理之前,需要先盘点一下当前的资产和具备的能力,设计出合理并规划出每一个周期需要达成的成果,梳理出各方的治理项,以及需要付出的人力成本、时间成本、资源成本和需要的支持。

从平台侧和业务侧来说已具备的能力有:
 

数据地图:由数据平台组及数据资产中心提供,大部分数据沉淀在产品,未入仓;
数据起源:由数据资产中心管理,数据仓库和其他业务系统,需要访问数仓里的表,需要注册到起源系统并开发权限,才可进行操作。

数据交换:由数据平台和数据仓库团队进行管理。

数据质量(DQC):由数据平台和数据仓库团队进行管理和使用。

元数据管理:由数据资产中心、数据平台和数据仓库团队进行管理和使用
 

数据血缘:由数据平台和数据仓库团队进行管理。

数据仓库建模:数据仓库团队进行管理。

影响评估能力:主要由数据资产中心提供,结合血缘和数据分级能力得出影响程度。

01

数据治理常见预览项
 

 
 
 

  

常见的数据治理项:
 

 

数据治理的成效评估标准:
 

01

规范思路

 
 
 

 

 整体思路上我们分4步走。

 

(1)规范制定

数据建模规范,即数据开发在设计模型阶段需要遵循的规范,比如dwd不能加工指标等。

数据开发SOP,为了系统能帮我们自动做一些规范校验和补全,我们可能制定一些流程上的规范,比如建表必须走模型设计中心,dw层全部先评审后开发等。

 

(2)能力建设

即我们数据治理过程中需要用到的系统能力补全,包含元数据建设,数据平台的迭代及治理工具的开发。

(3)治理实施

从治理目标上来说,我们围绕降本、提效、质量3个点去规划治理方案;

从实施方案上来说,主要落实在规范、计算存储、数据质量、数据安全4个方面。

 

(4)结果衡量

治理结果目标制定;

治理过程指标衡量。

01

实施

 
 
 

 

 

 

有了规范定义,那我们首先需要的就是看下当前数仓的规范程度,这里我们基于元数据ETL加工得到我们的监测指标,并基于有数BI进行的可视化呈现。

 

1:库表、字段命名规范、词根规范、度量标准统一
2:上下线规范、任务调度规范、流程变更规范
3:指标命名规范、管理规范、口径统一
4:数据资产盘点、收录、归档规范
5:数仓模型评估标准规范
6:治理效果评估标准规范

(1)跨层依赖——巡检及待办分发

DWS依赖ODS

DM依赖ODS

(2)反向依赖——巡检及待办分发

DWD依赖DM

DWD依赖DWS

DWS依赖DM

(3)单一事实建模——运动式治理

一张DWD只依赖一张ODS

 

 

 

图片

这个事情大的背景是目前数仓关于数据加密脱敏,数据权限管理等工作基本靠共识,比如大家都知道用户手机号是敏感数据,有人要这份数据时也会多走个流程审批一下。但是到底哪些表里面有存用户手机号,这些手机号有没有被妥善地加密或脱敏,表授权时有没有去判断里面是否有敏感数据,这些我们都是不知道的。所以我们考虑基于实体识别的方法,把数据资产的敏感程度给分级打标出来。

1:数据服务脱敏、加密
2:合规字段加密、脱敏
3:是否安全分类、分级
4:高密级授权定义
5:高密级数据定期审计
6:数据隐私处理记录(以人追数,以数追人)

分级打标的依据是集团下发的《分类分级管理制度》,根据这个文件,我们手工把数仓的各项涉敏数据项给盘点出来,整理成结构化的数据。再用一个Spark Job的形式去批量对所有数仓表进行采样和字段打标。大致实现如下:
 

得到分级结果后,我们就可以拿这份数据去重新盘点和治理我们的数据加密和权限管理情况了。

 

 

质量这块儿我们分事前、事中、事后三块去实施。

(1)事前

事前我们主要是规范数据需求流程,明确各个参与方职责,进行风险评估和保障定义:

业务:需求提出

BI/PM:1、需求拆解 2、确定口径

数据开发:需求评审

数据系分评审、链路评估

验证方案、回滚方案

链路风险巡检/治理

SLA 定义、保障方式定义

 

QA:测试评审

测试测分及评审

自测标准、验收标准

测试报告、验收反馈

事故报告、事故复盘

 

(2)事中

事中我们遵循数据开发->研发自测->QA自测->数据发布->产品发布->用户验收的流程,保证研发过程的质量合格。

(3)事后

事后指的是需求交付后的运维保障及应急恢复,这里的策略包括:基线值班、DQC、变更感知、大促时的压测和发生故障后的复盘。


 

基线值班会有数据基线该怎么挂的问题,任务A到底要保障到7点产出还是9点产出,值班的资源是有限的,都保障就意味着保障力度都降低,同理DQC的配置也是。这里我们的做法是,先从数据的使用场景出发,看看线上服务和有数报表的重要性分级是什么样的。再根据血缘往上追踪,对整个上游链路的数据任务挨个打标,高优覆盖低优,以此来确认任务的保障等级。

获得任务分级后,我们把P0,P1的任务挂载到了7:30/9:30两条基线,P2任务挂载到了10:00基线,由数据值班来保障他们的按时产出,并对破线及任务失败进行记录和复盘,便于确认后续优化方向。同时,P0、P1的任务也强制要求大家配上了基本的数据稽核。

然后是变更感知这块儿,包含数据源变更感知和ETL变更感知。数仓不生产数据,我们在只是数据的搬运工,所以感知数据源的变更和“搬运程序”的变更对数据质量的保障特别重要。

这里我们的做法是,收集数据源的变更工单日志以及数仓表和任务的修改记录,通过一个周期调度的spark sql任务去识别出风险变更以及影响范围,并推送消息给到对应的数据开发评估。


 

最终沉淀为针对数据生产过程的质量稳定性全流程保障方案,从平台、规范、组织三方面完成了相应建设和沉淀,根据实际的业务流程和数据流程完成。
1.质量治理策略:建立线上数据质量问题管理处置机制
2.质量问题监控:建立全流程数据质量问题的监控和预防体系
3.质量协同处理:建立上下游协同的工作流程
4.质量度量评估:建立可复用的数据标准和统一的质量评估体系

 
1:数据质量治理
        基线破线率23.76%->0%
        DQC配置率10%->100%
        表字段异常/表任务失败占比
2:指标治理
        指标计算出错率
        指标依赖层级表
        指标使用率
        指标波动异常监控
3:元数据治理
        表、字段的引用情况
        元数据异常发现

 

 

要持续提升重点报告的稳定性和性能,定期的治理和优化必不可少,因为报告访问量、表的数据量、表结构、表产出时间都存在一些不确定的变化。报告治理主要分为首访缓存命中率治理、报告查询错误率治理、慢查询治理三大块。
 
要提升重点报告首访缓存命中率,核心是要提高重点报告缓存预加载的完成比例,可以从以下三个方面优化:
(1)优化重点报告的表产出时间,重点报告依赖的表产出时间提前,才有更多的时间buffer去做缓存预加载,这个需要数据开发和分析师同学一起从数据产出链路上去优化。
(2)提升重点报告缓存预加载的优先级,这个可以提升重点报告相较于普通报告缓存预加载的先后顺序,从而提升重点报告缓存预加载完成率,同时重点报告也会根据最近访问量等指标再去细分优先级。
(3)对于一些缓存预加载超时或出错次数比较多的报告可以降低优先级。
 
要降低重点报告查询错误率,要对图表查询错误做分类治理:
(1)查询超时的图表要做慢查询优化治理(见图表慢查询优化部分)。
(2)图表查询高峰错误需要诊断出可疑的报告/图表进行优化。
(3)系统错误要通过系统优化来解决,比如元数据错误可以增加元数据刷新重试,服务重启错误可以增加查询重试等等。
(4)业务错误要推进报告作者治理,比如原表被删除、原表变更导致某些字段不存在、数据源连接不上等等。
 
图表慢查询治理方面,统一的治理有以下几类:
(1)耗时耗资源图表治理:top耗资源、top耗时图表往往严重影响集群整体性能和稳定性,多个慢图表并发查询时更容易出现查询高峰,所以这部分治理是重中之重。当然这个治理也要结合图表的访问量去看的,访问量大的图表影响也越大。
(2)小文件治理:小文件过多会导致元数据比较大,增加元数据同步压力,而且也会影响HDFS的性能。
(3)定时刷新治理:耗时耗资源的图表定时刷新频率过快,也会显著增加集群负载,可以降低频率或者关闭定时刷新。

具体到单个慢图表,常见的性能优化思路有:
(1)模型强制分区筛选:大表全表扫描对性能影响较大,百万以上大表建议使用分区表,同时在模型上设置强制分区筛选,减少数据扫描范围,也从源头控制全表扫描的可能。
(2)抽取到MPP:自定义SQL如果有筛选或聚合使得结果集减少可以抽取到MPP,通过MPP去查询,减少复杂SQL实时计算;后续产品上也支持抽取宽表模型到MPP,这在CK引擎上会有比较大的性能提升。
(3)物化模型:模型中关联的表过多导致性能差,可以使用数据任务预计算或者使用网易impala物化视图物化模型。
(4)列表筛选器使用独立维表:列表筛选器的数据需要从模型宽表明细对应列上去重计算得到,数据量大时性能较慢。如果列表筛选器成员比较固定的情况,可以列表筛选器走独立维表,通过跨模型关联筛选图表。
(5)刷新表统计信息:Impala是基于代价模型进行执行计划优化,表统计信息缺失会对执行计划的优劣产生重要影响,可以提前刷新表统计信息。
(6)时间/日期转换:将“字符串”类型的字段转换为“日期、日期时间”类型时,使用原始类型(即字符串类型)进行比较则不需要在SQL中进行字段类型转换,可提高查询性能。
(7)表存储格式治理:text存储格式数据过滤能力差,建议尽量使用高性能列式存储格式Parquet。

 

 

1:集群资源治理

建立可观测性监控系统,对于重点任务,优先级较高的任务,排队中/处理中任务的状态进行监控,占用集群资源多少等...
全链路压测
集群任务/进程占用资源topN
冷表下线10W+张,累计下降存储2.8PB,净下降1.9PB(8.49-6.59)
资源费用 12k/day->2k/day
内存memory seconds 下降33%
高耗资源任务运行时间 下降90%
高耗资源任务成本消耗 下降69%

2:高消耗任务调优

这里存在2个难点:优化效果不可控、高消耗任务调整到何种程度算合适,针对这个这个难点我们取所有核心数据资产任务均值,保障单个任务消耗小于平均消耗,同时我们针对当前高消耗任务列举出如下可优化的方式:

关联表过多,需拆分

关联时一对多,数据膨胀

资源配置过多,运行时资源严重浪费,需要将配置调小(包括Driver内存、Executor个数、Executor内存)

代码结尾添加Distribute By Rand(),用来控制Map输出结果的分发

查询中列和行未裁剪、分区未限定、Where条件未限定

SQL中Distinct切换为Group by(Distinct会被hive翻译成一个全局唯一Reduce任务来做去重操作,Group by则会被hive翻译成分组聚合运算,会有多个Reduce任务并行处理,每个Reduce对收到的一部分数据组,进行每组聚合(去重))

关联后计算切换为子查询计算好后再关联

使用Map Join(Map Join会把小表全部读入内存中,在Map阶段直接拿另外一个表的数据和内存中表数据做匹配,由于在Map是进行了Join操作,省去了Reduce运行的效率也会高很多)可用参数代替

 

3:大部分任务切换至Spark3计算引擎&补充任务调优参数

补充Spark调优参数(参数见下图),任务统一使用Spark3引擎加速,并充分利用Spark3的AQE特性及Z-Order排序算法特性。

AQE解释:Spark 社区在 DAG Scheduler 中,新增了一个 API 在支持提交单个 Map 阶段,以及在运行时修改 shuffle 分区数等等,而这些就是 AQE,在 Spark 运行时,每当一个 Shuffle、Map 阶段进行完毕,AQE 就会统计这个阶段的信息,并且基于规则进行动态调整并修正还未执行的任务逻辑计算与物理计划(在条件运行的情况下),使得 Spark 程序在接下来的运行过程中得到优化。

Z-Order解释:Z-Order 是一种可以将多维数据压缩到一维的技术,在时空索引以及图像方面使用较广,比如我们常用order by a,b,c 会面临索引覆盖的问题,Z-Order by a,b,c 效果对每个字段是对等的

参数内容

参数并不是设置越多任务性能越好,根据数据量、消耗、运行时间进行调整达到合理效果。

Hive:
(1)set hive.auto.convert.join = true; (是否自动转化成Map Join)
(2)set hive.map.aggr=true; (用于控制负载均衡,顶层的聚合操作放在Map阶段执行,从而减轻清洗阶段数据传输和Reduce阶段的执行时间,提升总体性能,该设置会消耗更多的内存)
(3)set hive.groupby.skewindata=true; (用于控制负载均衡,当数据出现倾斜时,如果该变量设置为true,那么Hive会自动进行负载均衡)
(4)set hive.merge.mapfiles=true;  (用于hive引擎合并小文件使用)
(5)set mapreduce.map.memory.mb=4096;      (设置Map内存大小,解决Memory占用过大/小)
(6)set mapreduce.reduce.memory.mb=4096;(设置Reduce内存大小,解决Memory占用过大/小)
(7)set hive.exec.dynamic.partition.mode=nonstrict;(动态分区开启)



Spark:
(1)set spark.sql.legacy.parquet.datetimeRebaseModeInRead=LEGACY;(用于spark3中字段类型不匹配(例如datetime无法转换成date),消除sql中时间歧义,将Spark .sql. LEGACY . timeparserpolicy设置为LEGACY来恢复Spark 3.0之前的状态来转化)
(2)set spark.sql.adaptive.enabled=true;(是否开启调整Partition功能,如果开启,spark.sql.shuffle.partitions设置的Partition可能会被合并到一个Reducer里运行。平台默认开启,同时强烈建议开启。理由:更好利用单个Executor的性能,还能缓解小文件问题)
(3)set spark.sql.hive.convertInsertingPartitionedTable=false;(解决数据无法同步Impala问题,使用Spark3引擎必填)
(4)set spark.sql.finalStage.adaptive.advisoryPartitionSizeInBytes=2048M;(Spark小文件合并)

4:集群稳定性治理

起夜率
指在日常工作中,数仓值班同学需要起来处理问题的天数占比全年天数,如果一个晚上无事发生,数仓同学不需要起夜,我们也引用了游戏中的一个概念,称为平安夜,起夜率相对越低越好。

基线破线率
基线是DataWorks独创的理念,在基线上我们可以为任务设置最晚产出时间。例如当天营收数据,最晚产生时间设置为凌晨2:00,如果这个任务最终产出超过2:00,那么这条基线就破线了,基线破线率同样也是越低越好。

5:任务调度合理优化

对于调度优化一开始会无从下手,统计凌晨2-5点区间下大概600+任务难梳理,同时存在任务依赖,修改起来可能会对下游整体有大的影响,因此我们选择循序渐进先梳理再改善。

找到所有表的输出输入点即启始ODS与末尾ADS

划分其中核心表/非核心表,及对应任务开始时间与结束时间

按照梳理内容把非核心的任务穿插在当前集群资源非高峰时期(2点前与5点后),同时把核心任务调度提前,保障CDM层任务及时产出

对实践后内容再度调优,达到资源最大利用

烟囱任务下沉&无用任务下线

 

6:库表治理

梳理库的使用情况,无用的库表走申请下线流程。
临时表治理
生命周期管理的推进
巨型表的治理
abtest专项治理
表的访问占比


 

7:计算资源治理

数据开发治理平台openAPI获取yarn资源消耗明细
内存空闲时间分布聚类取前20%阈值
RAM实际申请大于1TB
利用率小于10%
任务失败数
sla延迟数

优化方法:谓词下推/小文件合并/join优化/data skew优化/提高任务并行度/Spark AQE 参数调整

首先我们起个数据开发治理平台的任务,按照触发条件去巡检,筛选出待治理列表。然后发现这部分任务有着明显的长尾分布特性,极少数任务占用了大部分资源。所以我们针对top100的任务由专人挨个进行的by case的优化,剩余的任务则通过待办分发的形式推送给任务的负责人进行优化跟进。同时,我们做了全局的和个人的计算资源监控大盘,通过消息通知的形式,每天进行监控和公示。


 

8:存储资源治理

未管理数据表:未设置生命周期的分区表进行识别,当同时满足以下条件,数据表是分区表,没有设置生命周期,且近30天没有访问时,就命中该治理项,并判定该表为未管理的数据表。治理小组也根据提供对应的处理操作建议,优先建议用户进行生命周期的快速设置。针对一些需要长期保留的数据,也可通过设置白名单或设置长生命周期的方式来处理。

无访问数据表:该治理项则是针对进行了初步管理,但是实际是无用数据进行识别。占用了大量存储但是无下游访问的数据表,通常情况下是僵尸数据或者冷数据,需要用户进行处理识别,进行合理生命周期设置,或者进行删除操作。

30天打开次数+近30天引用次数+近30天访问次数+近30天写入次数 = 0

近30天打开次数+近30天引用次数+近30天访问次数 = 0

相关治理手段:
 

1.重点开始攻坚「计算」维度,定义计算侧重点关注的治理项,进行落地推动,如增加对「数据倾斜」、「暴力扫描」的计算任务识别,逐步分析完成每阶段的成本优化工作的推进,以及最终成本节省效果的统计;

2.深化「存储」维度,增加对「空表」「90天内无读取使用表」等治理项,供下阶段治理计划识别,减少该类无效数据对于数据成本、数据使用的影响;

3.基于数据全流程链路,平台工具化治理能力,并针对于不同的治理项,提供不同的直接可用的治理手段,并且为了预防,提供基于各个过程的提前检查项。做到从根本上进行提前规约。


 

9:小文件治理
 

在这里我们使用内部数据治理平台-数据治理360对存在小文件较多表提供内容展示(本质采集HDFS对应路径下文件数的日志去显示)

当前小文件处理:

对于分区较多使用Spark3进行动态分区刷新,(Spark3具备小文件自动合并功能,如未使用Spark3可配置Spark3/Hive小文件合并参数刷新,参数详见文末),代码如下:


set hive.exec.dynamic.partition.mode=nonstrict;
insert overwrite table xxx.xxx partition (ds)
select column
,ds
from xxx.xxx

对于分区较少或未分区的表采用重建表,补数据方法回刷。
 

小文件预防:
 

使用Spark3引擎,自动合并小文件

减少Reduce的数量(可以使用参数进行控制)

用Distribute By Rand控制分区中数据量

添加合并小文件参数 

将数据源抽取后的表做一个任务(本质也是回刷分区合并小文件任务)去处理小文件保障从数据源开始小文件不向下游流去

 

 

 

来源:大数据启示录

上一篇:数据仓库详细介绍(九.数据质量)流程与工具

下一篇:万字详解数据治理自动化体系化实践

  • 分享:
龙石数据
咨询电话: 0512-87811036,18013092598
联系我们
商务联系微信

商务联系微信

0512-87811036,

18013092598

咨询电话