数字化转型网数据专题将关注数据治理、数据质量管理、数据架构、主数据管理、数据仓库、元数据管理、数据备份、数据挖掘、数据分析、数据安全、大数据、数据合规、等数据相关全产业链相关环节。
数据治理是一个什么话题呢？
就是上面那些玩意之前开发的时候有历史遗留问题，要把它“治理”成规范的
数据治理总体上分成合规治理和资源治理
合规治理主要是规范上的问题，比如：模型设计规范、元数据定义规范、数据质量方面的保障规范等
资源治理分为存储和计算
比如说存在大量重复数据、无用数据的存储导致我 HDFS 存储不足，那我就需要进行存储资源治理
存在某些任务会消耗大量资源，导致链路中其他任务跑不起来，那这个时候我就需要进行计算资源治理
由于数据仓库在建设过程当中，可能由于急于交付需求就没有考虑过多合规方面的问题，导致遗留下很多隐性的问题
同时每个时期所关注的问题是不一样的，所以需要按照不同的阶段进行精确的治理
数据安全合规治理
城市里有银行金库、有政府机密档案、有市民的个人隐私
如果这些重要的信息随随便便就能被人看到、被人拿走，那这个城市就毫无安全可言，会出大乱子
权限管控
核心原则： 按需分配，最小权限，不是谁都能看所有数据
管控粒度： 细化到 字段、表、库 级别。例如，你可以看用户表，但手机号字段对你不可见
授权方式： 通常基于 角色/用户组 进行授权，数据负责人拥有审批权。表的敏感等级也会影响审批层级，高级别数据需要更高级别审批
多层级审批： 下载数据需经业务负责人等审批
数据模型分级
数据分级就像给文件盖上“绝密”、“机密”的戳，不同级别的戳对应不同的查阅和审批手续
通过区分数据的敏感程度，实施差异化安全策略
将表、Topic、字段按照不同级别进行划分
数据脱敏
这块给敏感信息打上马赛克，既能满足业务需要，又能有效防止隐私泄露
比如对敏感数据（如手机号、身份证号）进行部分遮盖（如138****1234），保护隐私
大部分在ODS、DWD、DIM层实现，ADS层也可按需进行二次脱敏
数据展示
这块可以根据登录用户的身份，自动过滤和调整其能看到的数据范围和细节
权限控制在最终呈现环节的体现
同一报表，不同用户看到的内容不同
定期扫描
确保安全策略得到持续执行，及时发现和修补漏洞
新上线的表需在短时间内（如3天内）完成安全等级打标
系统自动提醒数据负责人为未打标或打标不明的表/字段进行确认和标记
存储资源治理
为什么存储会紧张？
这里主要是因为历史数据的不合理存储以及大量无用数据在占用资源，所以治理也主要是在围绕着这两个问题在进行操作
整体思路肯定是优先进行那种可以用最低的成本来达到显著效果的操作
可以从这几点优先入手：下线无用数据表节省存储->存储格式及压缩格式配置->分区生命周期优化->根据业务情景实现节省存储即数据模型优化
这里可以通过元数据进行梳理，每个模型的引用情况、生命周期的配置、存储格式等
下线无用表，可以根据表的被引用情况以及被使用情况(读取次数、引用次数)来判断表是否是无用表
存储、压缩格式
存储格式一般是 orc 或者 Parquet
使用 Parquet 作为存储格式的时候，Spark 的效率会更高
压缩格式方面，snappy 的解压速度最快，适用于低延迟场景
gzip 压缩率高但是速度慢，可以作为冷存储使用便于节省存储空间
zstd 算是这俩的一个折中，压缩率高于 snappy 接近于 gzip；速度比 gzip 快 比 snappy 略慢
hadoop 3.x开始支持 zstd，会逐渐成为一个兼顾存储和性能的折中方案
生命周期
这里需要区分表是全量还是增量的
全量表
ODS:小时全量(3天)、天级全量(7-90天)
DWD:小时全量(7-15天)、天级全量(7 – 30天)
DWS:小时全量(7-30天)、天级全量(7-60天)
ADS:小时全量 (7-30天)、天级全量(7-90天)
DIM:小时全量(3天)、天级全量(90-360天)
增量表
ODS:小时增量(30-180天)、天级增量(90-365天 or 永久)
DWD:小时增量(60-180天)、天级增量(180-365天)
DWS:小时增量(60-365天)、天级增量(180-730天)
ADS:小时增量(90-365天)、天级增量(180-730天)
DIM :默认使用全量表
治理后的维护
可以通过对元数据表配置监控、设定一些规则建设健康分形成一套标准
计算资源治理
遇到集群资源跑满、任务产出延迟等问题，很多人第一反应是“机器不够了，加机器吧！”或者“内存给少了吧，加内存！”
但是很多时候，不是物理资源真的不够用，而是我们的任务写得不够好，或者资源调度不合理，导致计算效率低下，白白浪费了资源
盲目加资源，治标不治本，还会增加成本
动手优化之前，得先想清楚从哪下手，按什么顺序来，不能眉毛胡子一把抓
这里同样需要优先进行最容易快速见效的操作，比如调整一下Spark任务的executor内存、并行度等参数，或者把一些不适合用Hive跑的任务切换到Spark上
然后接下来主要是有以下几个问题：小文件过多、高资源消耗任务、任务调度不合理、重复开发任务以及无用任务
针对小文件进行治理，这块咱具体放在后文
高资源消耗任务优化
这块其实就是 spark 任务相关的调优
Map 阶段
这里主要是读取的数据量级的问题，所以主要的操作就是在减少读取的数据量
比如行列裁剪、条件限制这些是最基础的
还可以将数据表改造成二级分区，这样可以减少每个分区的数据量，这样 map 端就会运行得更快
如果上游数据量过大，可以全量改增量，每次只查询对应的增量数据，走增量分区之后效率会比较高
如果我们要读取的数据量过大，并且读到的数据在任务中被多次使用，这里可以采用临时表的方式来将中间数据进行物理存储，这样可以大幅提高整体任务运行的效率
不过这里建议不要反复在任务中创建和删除临时表，可以创建一次之后，每天把数据插入到临时表中
Reduce 阶段
如果任务发生数据倾斜的话，那么暴雷就是在 reduce 端
因为数据倾斜就是某一个分区数据量相比于其他分区过多，导致任务花在这一个分区的时间过长，reduce 阶段就是在处理这每一个分区的数据
针对这种数据倾斜情况的解决思路是：对倾斜分区进行拆解或者直接不让倾斜分区产生
拆解的话可以依靠 spark 的 AQE 特性，会自动识别大分区，将大分区拆成多个小分区由多个 task 进行计算
不让倾斜分区产生的思路就是让数据分批得均匀一些，比如使用 repartition by + distribute by rand() 来进行优化，对分区进行重组，这样原来集中在一个Reduce Task上的数据，就被分散到多个Reduce Task上并行处理了
给 key 加上随机数进行计算最后再将随机数去除再进行计算得到最终结果，比如，如果Key “A” 数据量特别大，可以把它变成 “A_rand1”, “A_rand2”, …, “A_randN”
再或者直接过滤掉大 key 进行单独处理
对于 row_number 排序导致的过慢可以考虑用聚合函数替代排序来求最值
任务调度不合理
所有任务都集中在同一个时间段跑会到这这个时间区间的 CPU 满载，任务互相抢资源，反而都跑不快
这里需要梳理出高峰时间段的表对应的 ODS 和 ADS，识别出那些最重要的核心链路上的任务（比如直接影响公司核心报表的任务），优先保证它们的资源供给和按时产出。可以给这些核心任务更高的调度优先级
那些优先级没那么高的、或者对产出时间要求不那么苛刻的任务，就尽量安排在集群比较空闲的时候去跑
同时，调度优化也不是一劳永逸的，业务在变，数据量在变，任务也在变
需要定期回顾和调整调度策略，持续优化资源利用率
重复开发任务以及无用任务
对于早期开发的烟囱表，需要将指标下沉到 DWS 来提高复用性，同时对于无用任务也要及时下线，从而减少资源的消耗
治理后的维护
可以通过元数据持续评估任务的资源消耗，针对资源消耗、运行时长来对任务进行打标签，比如：高消耗任务、超长任务等
小文件治理
背景
小文件就好比是停车场里停了一辆玩具车
在HDFS里，文件是按“块”（block）来存储的，一个块的默认大小通常是128MB或256MB
即使你的文件只有1KB，它在HDFS上也会占用一个完整的块的元数据开销（NameNode需要记录这个块的信息），虽然实际数据只占1KB，但它“预定”了一个块的位置
MapReduce 或 Spark 等计算引擎在处理数据时，通常会为每个输入分片启动一个task
如果小文件太多，意味着输入分片也会很多，就需要启动大量的task，每个task的启动和销毁本身就有开销，大量的task启动会消耗大量时间
同时，小文件过多也会导致频繁的 IO，因为读数据的时候因为文件小，所以不会在扫描文件上花费太多时间，会导致磁头频繁寻道，IO效率低下
查询时需要频繁访问 NameNode 获取小文件的元数据信息，也会增加NameNode的压力和查询延迟
所以说这里文件过小会导致上述的问题，文件过大可以解决频繁 IO 的问题，但是会导致在一个文件上花费的时间过大，所以文件的大小需要合理把控
小文件的产生
源头上，可能我们的数据源本身就存在大量的小文件，所以导致小文件过多
处理上，任务的 reduce 数量会直接决定输出文件的数量，每个Reduce Task通常会写一个文件到对应的分区目录
再或者说由于数据倾斜，key分布不均，导致少数几个 Reduce Task 处理了绝大部分数据，而其他很多 Reduce Task 只处理了非常少量的数据，这部分 task 输出的文件也会过小
治理
spark 3 的 AQE 特性也能很好的解决小文件的问题，它可以自动合并分区，如果发现输出分区过小，会自动将这些小分区合并到一起
同时，既然 reduce 的数量可以影响输出文件的数量，我们也可以直接限制 reduce 数，
对于分区数据不均匀导致的小文件的产生，也可以使用 Distribute by rand() 控制分区中数据量，保证每个分区的数据量基本一致，均匀分配，能合并部分的小文件
针对数据源就存在大量小文件的现象，可以在 ODS 任务后再接一个 Spark3 的回刷任务，借助 AQE 特性来减少小文件
治理之后，同样可以通过元数据进行持续化的监控
声明：本文来自建鑫Data，版权归建鑫jx所有。文章内容仅代表作者独立观点，不代表数字化转型网立场，转载目的在于传递更多信息。如有侵权，请联系我们。数字化转型网www.szhzxw.cn
数字化转型网数据专题包含哪些内容
数字化转型网数据专题将关注数据治理、数据质量管理、数据架构、主数据管理、数据仓库、元数据管理、数据备份、数据挖掘、数据分析、数据安全、大数据、数据合规、等数据相关全产业链相关环节。
数字化转型网数据专题包含： 数字化转型网（www.szhzxw.cn）
1、数据相关外脑支持：100+数据相关专家、100+数据实践者、1000+相关资料
2、数据研习社：与全球数据相关专家、实践者共同探讨相关问题，推动产业发展！
3、国际认证培训：目前已引进DAMA国际认证CDMP，其他国内外认证也在逐步引进中
4、典型案例参考：与数字化转型网数据要素X研习社社员一起学习典型案例，共探企业数据落地应用
本文由数字化转型网（www.szhzxw.cn）转载而成，来源于建鑫Data；编辑/翻译：数字化转型网萍水。
