关于数据治理的一些梳理

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

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

最终沉淀为针对数据生产过程的质量稳定性全流程保障方案，从平台、规范、组织三方面完成了相应建设和沉淀，根据实际的业务流程和数据流程完成。
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。

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

关联表过多，需拆分

关联时一对多，数据膨胀

资源配置过多，运行时资源严重浪费，需要将配置调小（包括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运行的效率也会高很多）可用参数代替

参数内容

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

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小文件合并）

5：任务调度合理优化

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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控制分区中数据量

添加合并小文件参数 

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