数据治理手稿
ckckck2025年1月10日78 浏览| # 维度 | 分类 | 指标说明 |
|---|---|---|
| 研发域 | 表面名规范 | 表层级、主题、颗粒度、业务过程、存储策略、周期粒度... |
| 词根规范 | / | |
| 字段命名规范 | / | |
| 注释规范性 | 表注释<5字、无字段注释、表更新说明 | |
| 字段类型规范 | / | |
| 表规范化率 | 规范化的CDM（DWDDWSDIM）表数量与所有CDM表数量比值 | |
| 表引用率 | 所有被ADS层引用的CDM（DWDDWSDIM）中，规范化的CDM表数量与所有CDM表数量比值 | |
| 跨层依赖 | 跨层依赖占比：DWS依赖ODS，DM依赖ODS... | |
| 反向依赖占比: DWD依赖DM、DWD依赖DWS、DWS依赖DM | ||
| 单一事实建模：一张DWD只依赖一张ODS | ||
| 链路深度及分层 | 决定问题的修复时间，链路越深，问题修复的时间可能就越长。链路>5 | |
| 核心表查询 | 前20%查询表中，核心表占比>80% | |
| 平均查询时长 | 个人平均查询时长>公司总平均时长 | |
| 不良查询 | 1：大于100s查询次数+查询失败次数>公司平台不良查询数 | |
| 2：定义一个不良查询及格数 | ||
| 手动查询ods大表 | 手动查询ods大表不做限制 | |
| 同源重复导入 | 1day/hour同源数据导入次数>2 | |
| 表名任务不一致 | 表名任务不一致 | |
| 闲置率 | 未被引用的ODS表数量与所有ODS表数量比值 | |
| 穿透率 | 直接消费ODS的ADS表与所有ADS表占比 | |
| 多任务同写一张表 | 多任务同写一张表 | |
| 指标管理规范 | 1：指标命名规范、管理规范、口径统一,指标字典等 | |
| 2：建立指标监控项，异动率，波动范围，指标使用率，指标依赖层级表... | ||
| 3: 指标平台建设 | ||
| 质量域 | 数据完整性、一致性、唯一性、NULL值分布... |
- 表级：主键唯一性、表行数监控、行数波动监控等；
- 字段级：空值判断、枚举值范围监控、数值型分布、最大最小值监控等；
- 规则强弱：支持配置规则命中后，继续执行或终止任务等不同策略。
考量数据项信息是否全面、完整、无缺失 公式：表完整性和字段完整性的平均值
DQC覆盖率 | 考量要监控的数据项是否作用所有的任务上，是否有所遗漏 公式：已见控的作业个数/总的作业个数
DQC达标 | 公式：监控的高价值作业个数/高价值作业总个数（高价值作业是指作业价值分在80分以上的作业）
产出稳定性 | 考量作业的运行稳定性，是否经常报错，导致数据事故 公式：错误作业个数(本周)/作业总个数
回稳稳定性 | 公式：失败后重启成功任务数/总的失败记录（去重）数
DDL稳定性 | 公式：使用到的表发生DDL修改个数/使用到的表数量
告警响应度 | 通过日常管理、应急响应，降低或消除问题影响，避免数据损毁、丢失 公式：已处理告警个数(本周)/告警总个数(本周)
作业准确性 | 考量数据是否符合预设的质量要求，如唯一性约束、记录量校验等 公式：告警作业个数(本周)/监控作业总个数
基线破线率 | 考量数据项信息可被获取和使用的时间是否满足预期要求 公式：超出任务最晚产出时间的作业个数/总的作业个数
作业性能分 | 考量作业的执行效率和健康度，诊断作业是否倾斜等性能问题 公式：危急作业个数(本周)/作业总个数
安全域 | 表安全等级设置 | 超过一个月仍未进行安全分类、分级确认的数据表/总的表数量
字段安全等级设置 | 字段依据业务的重要程度划分安全等级。
敏感字段加密 | 数据脱敏处理 大于2级数据合规字段未处理
数据服务脱敏、加密 | 数据脱敏处理 大于2级数据服务合规字段未处理
审批流程合规性 | 建立审批流程机制
读写权限合规设置 | 不同的层级，不同的业务部门对于不同的库表设置相关的权限控制和隔离
责任人符合规范 | 责任人需要满足职责、业务和权限要求，权限开通需走审批流程
计算域 | 通用指标作业优化 |
任务调度合理优化 | 1：任务优先级划分和梳理，优先保障高优先级别的产出、做好双链路切换
2：任务错峰调度
3：烟囱任务下沉&无用任务下线
4：数据倾斜任务经优化后仍无法解决，拆分任务，分批调度
5：尽量减少任务依赖。（天任务依赖小时任务，小时级别依赖分钟级别等）
6：任务自动分级和降级
集群资源治理 | 1：建立可观测性监控系统，对于重点任务，优先级较高的任务，排队中/处理中任务的状态进行监控，占用集群资源多少等... 全链路压测
2：集群任务/进程占用资源topN
3：冷表下线10W+张，累计下降存储2.8PB，净下降1.9PB（8.49-6.59）
4：资源费用 12k/day->2k/day
5：内存memory seconds 下降33% 6：高耗资源任务运行时间 下降90%
7：高耗资源任务成本消耗 下降69%
高消耗任务调优 | 1：关联表过多，需拆分
2：关联时一对多，数据膨胀 资源配置过多，运行时资源严重浪费，需要将配置调小（包括Driver内存、Executor个数、Executor内存）
3：代码结尾添加Distribute By Rand（），用来控制Map输出结果的分发 查询中列和行未裁剪、分区未限定、Where条件未限定
4：SQL中Distinct切换为Group by（Distinct会被hive翻译成一个全局唯一Reduce任务来做去重操作，Group
by则会被hive翻译成分组聚合运算，会有多个Reduce任务并行处理，每个Reduce对收到的一部分数据组，进行每组聚合（去重））
5：关联后计算切换为子查询计算好后再关联
6：使用Map Join（Map
Join会把小表全部读入内存中，在Map阶段直接拿另外一个表的数据和内存中表数据做匹配，由于在Map是进行了Join操作，省去了Reduce运行的效率也会高很多）可用参数代替
7：减少shuffle，算子、数据集复用
8：合理使用分区、分桶、广播变量等
任务资源分配优化 | 提高任务并行度、分区数 spark、hive资源合理分配 shuffle参数优化
计算引擎选择和切换 | 任务切换至Spark3计算引擎&任务调优参数
- 开启动态资源分配 dynamicAllocation
- cpu/内存配比建议同集群总资源配比，最大化利用集群资源
- 开启broadcastjoin，有数大数据平台环境默认关闭（内存限制），spark官方建议开启，可极大提高join小表性能
- 调节parallelism和repartition参数，提高并行度
- 开启convertMetastoreParquet，充分利用spark读parquet性能
- lateral view explode优化，多次explode前，手动触发shuffle操作，减少单分区处理数据量大小
- 控制输出文件大小，减少小文件数，减轻nn压力
- 充分利用spark3 AQE优化
集群稳定性治理 | 1：起夜率
2：任务压测、削谷填峰
3：高可用HA
4：支持动态扩容和数据处理流程自动漂移
5：做好相关监控、建立起监控预警机制 6：弹性反脆弱
7：自动化运维
8：上游元数据变更抗性
z-order | Z-Order 是一种可以将多维数据压缩到一维的技术，在时空索引以及图像方面使用较广，比如我们常用order by a,b,c 会面临索引覆盖的问题，Z-Order by a,b,c 效果对每个字段是对等的
yarn相关优化 | 1：通过Node label完成资源隔离
2：通过cgroup完成cpu进程的绑定，使其得到充分的利用。
olap计算成本优化 | 1: 选择向量化查询引擎相关MPP数据库 2：bitmap优化
3：cbo优化器
4：query cache
5: 异步物化视图
6：索引+动态分区、分桶
7：Sorted streaming aggregate
8：join优化
9：参数调优
10: tablet治理
存储域 | 日志格式规范管理 |
- 标准：日志打印遵守统一标准格式，保证下游可正常解析，异常日志的存储或特化解析会带来存储空间的浪费、人力维护跟进的投入开销与下游解析作业的性能开销；
- 按需：仅打印下游业务所需的日志，非必要的日志可不打印或不采集到下游链路中；在满足业务分析的前提下，日志打印可遵守最小原则，最大限度减少下游日志传输量；
- 精简：对于频繁在多条日志反复打印的字段，可仅在会话中的第一条日志打印完整信息，后续日志通过会话ID进行关联查询；可通过维表查询替换的字段，在日志打印时可进一步压缩字段的大小。
建立数据共享/数仓共享方案 |
数据表生命周期管理 |
梳理库表的使用情况，无用的库表走申请下线流程。
临时表治理
生命周期管理的推进
巨型表的治理
abtest专项治理
表的访问占比
存储资源治理 | 未管理数据表：未设置生命周期的分区表进行识别，当同时满足以下条件，数据表是分区表，没有设置生命周期，且近30天没有访问时，就命中该治理项，并判定该表为未管理的数据表。治理小组也根据提供对应的处理操作建议，优先建议用户进行生命周期的快速设置。针对一些需要长期保留的数据，也可通过设置白名单或设置长生命周期的方式来处理。
无访问数据表：该治理项则是针对进行了初步管理，但是实际是无用数据进行识别。占用了大量存储但是无下游访问的数据表，通常情况下是僵尸数据或者冷数据，需要用户进行处理识别，进行合理生命周期设置，或者进行删除操作。
30天打开次数+近30天引用次数+近30天访问次数+近30天写入次数 = 0
近30天打开次数+近30天引用次数+近30天访问次数 = 0
数据分级与压缩存储 | 数据分级：
- 第一级：存储在常规Hadoop集群，保证读写性能；
- 第二级：存储在冷备Hadoop集群，可读写，但性能稍差；
- 第三级：存储在冷备S3集群，只读不可写，性能最差。
压缩存储
第一级：格式压缩，基于不同表，压缩为orc/textfile+snappy格式，压缩率在30~48%左右；
第二级：使用纠删码技术，从3副本减少到1.5副本，压缩率在50%左右。
spark与zstd算法的结合，来优化存储资源 Zstd压缩和解压能够达到更高的速度和更高的压缩比，但也可能占用更多的内存和CPU资源。
小文件合并 | （1）使用Spark3引擎，自动合并小文件 （2）减少Reduce的数量(可以使用参数进行控制) （3）用Distribute By Rand控制分区中数据量 （4）添加合并小文件参数 （5）将数据源抽取后的表做一个任务（本质也是回刷分区合并小文件任务）去处理小文件保障从数据源开始小文件不向下游流去 (6) 自定义合并小文件
应用域 | 热度 | 决定是否有用，影响查询用户的范围，热度越高表明影响的用户范围越广。
下游类型 | 决定下游资产重要程度，下游资产类型一般有ETL任务和数据产品两类，ETL任务及数据产品又根据重要度分为普通型及VIP型。
下游依赖数 | 下游依赖数量：决定是否是关键节点，对下游生产的影响范围，下游数量越多表明影响范围越大。
互动推荐值 |
应用贡献度 |
飞书链接：https://j1d30b4chu.feishu.cn/docx/WzNPdhC3GoPe9bxBkGJcEgd2nRc 密码：qfJI
end