数据仓库-数据治理小厂实践

一、简介

    数据治理贯穿数仓中数据的整个生命周期，从数据的产生、加载、清洗、计算，再到数据展示、应用，每个阶段都需要对数据进行治理，像有些比较大的企业都是有自己的数据治理平台或者会开发一些便捷的平台，对于没有平台的公司，这里根据自己的亲身实践简单整理一下。

二、治理方向

1、数据的存储

1.1 数据保留周期

    由于数仓的前中期没有对数据的存储进行合理规范的治理，导致大量的历史数据积累，占用一定的磁盘存储开销，造成服务器成本的上升，团队决定对数仓数据的存储进行一定的治理。首先对各个层数据的保留周期进行治理。

    ODS层：原始数据层，存放的数据分为两类：业务数据和埋点日志。对于业务数据不做处理，日志数据又分为未解析的落盘日志和按上报类型解析好的ORC日志，对于未解析直接落盘的原始数据保留三天，按上报类型解析的日志保留7天。

    DWD层：数据明细层，数据分为业务数据和上报日志数据，业务数据不做处理，上报日志数据按需保留7天、30天、45天、90天，例如30日留的计算，需要保留日活主题的数据30天。

    DIM层：量小，不做处理

    DWS层：轻度聚合汇总不做处理

    ADS层：应用层占用较小，不做处理

    **方法：**通过shell脚本每天定时删除HDFS数据，后期由于删除数据量较大，一次删除会造成集群IO打满，造成集群卡顿，后期优化将不同数据分布在不同的时间段进行清理

1.2 集群小文件治理

    数仓前期没有对文件落盘进行控制，造成集群每天会产生大量的小文件，对集群的存储性能、计算都造成了一定的影响(小文件的危害)。

    **方法：**已存在的小文件通过shell脚本循环合并，对于无用的小文件可进行删除

               后续的sql脚本通过 distribute by 来控制文件的落盘数量

1.3 数据量预警

    a. 对于小时任务，监控每小时的数据量，与昨天相比，超过一定规则的进行邮件预警(发送大数据所有人)，避免业务数据量暴增，业务通知不及时，造成集群崩溃

    b.对于离线任务，每天定时对各个业务板块的数据进行监控，计算每个项目的总数据量、总设备数、总用户数、人均数以及同比、环比并通知给各个相关人员，以便他们及时了解业务的情况。

2、任务调度

2.1 任务基线预警

    基于不同的任务流程设置不同的任务基线预警，主要分为离线流程基线、小时任务流程基线、收入成本相关基线等

    离线任务流程：由于PC相关报表数据的缓存是在早晨六点开始，APP相关的在早晨七点开始，所以离线流程应该在基线之前执行完成，避免造成数据错误。

    小时任务流程：小时任务流程比较重要，每个小时都要流程执行，并且都有报表更新，以供业务方进行运营，所以流程必须在指定的基线时间完成，并且在缓存基线之前完成报表的缓存更新，以便不影响下个周期流程的执行以及业务可以及时的看到数据的更新。

    营收相关流程：营收基线内完成相关流程

 **   方法：**1. 每次流程执行完成，发送相关邮件进行通知(当没收到邮件时，进行问题的排查)，离线可使用，小时流程频繁发的话会造成一定的误导。

               2. 当集群卡主时，流程end邮件task不会触发，通过调度的元数据执行记录进行监控，在基线时间没有执行记录，触发预警邮件

2.2 DQC预警

    1. 凌晨监控某些核心表的数据是否为空、数据量的波动，提现金额大小、收入入库比例波动等设置相应的DQC规则，进行邮件预警

    2. 及时清理已经下线的DQC以及长期无预警的规则

    3. 长期对规则进行优化