目录
本文仅在大数据平台角度对数据存储、cpu、内存角度进行数据治理，不包括业务角度。
数据治理的目的：随着业务的发展，诸如存储、cpu、内存等资源的使用均会增加，大多数资源使用是业务增长带来的，而其中一部分是使用过程中带来的无意义增长，对这一部分资源的增长需要管控起来。
1、对表的元数据信息有较好的维护，如hive表，在mysql上存储一份和hive底层强一致的元数据，方便后续管理。若没有维护一份跟hive底层强一致的元数据信息，可能会出现一些“失联”表，即有些表实际已经没在用了，但未删除，从而导致存储的浪费。
2、对表的数量、存储大小进行监控，做成诸如柱状图之类的图表对表存储的增量情况进行统计展示，可以是月为维度。通过这个监控，不仅可以监控到当前表的存储情况，也可以对后续表的增量情况进行预估，可以根据这个预估后续需要增加存储的情况。
3、表增加生命周期，每张表都设置生命周期，到期后需要申请续期，若不续期超过到期时间表自动删除。
4、基于表的访问时间和访问次数，可判断冷热数据，对冷数据进行存储压缩等，降低hdfs的存储。
5、平台用户代码实现不合理，常常会生成大量的小文件，导致Metastore压力变大，平台需要监控小文件进行合并。
1、对hdfs上文件存储路径进行管控，要想对存储进行管控需要规范存储目录，平台指定固定根目录，所有平台用户在根目录下创建文件。
2、基于1的规范，用户在集群上增加存储，基于子目录（部门，或者个人），可以监控到部门或者个人使用存储的情况，进行资产统计。
3、监控文件变更时间以判断该文件是否是冷数据或者脏数据，对用户进行告警以提醒用户对冷数据进行压缩、脏数据进行删除等
1、监控任务内存、cpu使用情况，是否存在内存、cpu设置不合理的情况，导致集群资源使用紧张。另外，也可以根据用户内存、cpu平均使用情况，对任务设置一个默认的比较合理的值。
2、监控运行时间过长的任务，判断任务执行时间过长是真实如此，还是代码实现不合理等情况导致，若是代码实现不合理，则需要提醒用户优化，降低集群资源使用紧张的情况
3、分析任务失败原因，根据日志判断是平台原因还是用户原因。
1、增加整个hdfs进群存储增量的监控，如周或者月维度增量以折线图的形式展示监控情况，可预判集群接下来一段时间整体的一个增量情况