“任务规范性治理，保障平台高效运行。” 在数据管理领域，任务治理至关重要。规范性治理究竟涵盖哪些内容？又如何有效实施？

在本篇开始的时候，提到任务治理可以从两个方面来做，一个是通过端到端的任务血缘链路来了解平台任务，从而进行治理。另一个就是建立一些规范性的任务，来进行主动治理。这里就介绍一下主动的任务治理。

这里的规范性治理治理的内容都是些什么那？这个产品功能仅仅提供一些思路，设计的过程中，也并无觉得特别的通顺。好多地方也感觉并不是特别好的形式，但是有没有思路想出更好的形式。

在主动治理时，治理的对象是：任务、表、数据服务API。可以大概分成四类：存储治理、计算治理、规范性治理、数据服务API治理。

一、存储治理

存储治理的对象主要针对表，通过治理的规则，识别出来可以被下线的表，从而将表的进行下线。来节省存储空间。

在进行治理的时候，主要是通过治理的规则，来对具体的空间，建立治理任务，从而识别出来需要治理的任务。

治理规则有哪些，举例说几个：近180天读取次数为0、近180天无更新表、表创建180天仍为空，等等。这里面的数值都是用户可配置的，通过一个规则模版，来配置自己需要的规则。通过这些规则创建的任务，周期性运行之后来识别出来可以被下线的表，从而实现表的主动治理。

二、计算治理

计算治理的逻辑也是相同的，他的治理对象是任务，通过计算治理规则来创建治理任务，从而识别出来需要被下线的任务，将任务下线。从而实现任务的主动治理。

计算治理的规则都有哪些，这里也举些例子：无下游依赖、近90天无运行、产出目标表为空、近七日资源消耗TOP30、近七日运行耗时TOP30。

通过诸如此类的规则，来创建规则任务，从而实现任务的主动治理。

三、规范治理

规范治理针对的对象仍旧是表，只不过相较于存储治理监控的表里面的内容，这里更多的是对表的建表规范做监控。

举些例子来看一下：

单一事实表建模

建模的时候只使用了一张上游表，这个时候是不是需要考虑建模的合理性。如果多张包的使用同一个单一表上游，是不是这多张下游表数据是重复的。这个规则从模型层面，来进行一个任务治理。

表描述或表中文名缺失、表层级信息缺失、表负责人缺失

这些均是一些表的属性信息缺失，能够明确将信息缺失的表给扫描出来，然后进行治理。从而完全表的描述。

临时表名称、命名不符合规范

这个事从表命名规范上来进行规范治理，确定这些临时表名称位置是否合理，正式的表是不是符合了表的命名规范。

跨层级取数、反向依赖、环状链路

这些主要是从数据流向的角度进行的规范化，当然，这种数据的流向可能并不一定能够这个明显的发现，比如环状链路，几个节点形成环，才算环状。这些在具体实现的时候都需要依据技术的实现程度来进行具体分析了。

四、数据服务API治理

数据服务的规则，相对简单，目前只想到一个，就是通过常时间没有调用的来找到可以下线的数据服务API。

近90天调用次数为0

90天了API仍旧没有人调用，是不是需要统计出来进行下线了。

五、发现待治理任务之后更加复杂

上面说的通过这种类型的规则，来发现待治理或者待规范化的表、任务，这个过程可能不复杂。复杂的是，发现了之后怎么办？

如果某张表下线之后，下游影响了谁，不会造成大范围的问题？谁依赖了将下线的任务，真的下线是否会影响第二天任务运行？

对于虽然识别出来了，但是明确表示仍然被使用，不需要下线的，是否需要有白名单功能，来让下次扫描时，不进行扫描？如果有了白名单如何避免，一加白名单了之的粗暴操作？

是不是需要一个暂时下线能力，如果第二天发现影响其他任务，再立即恢复？

搜描之后为了敦促开发人员进行治理操作，是不是需要有一个报表能力，定期进行排名、打分，推进治理的落地。

所以说，发现了待治理任务之后更加复杂，这一部分如何能够流畅的操作，是需要好好考虑设计下的。

而且，在这个过程中也需要端到端的任务血缘链路，来更好的进行全局的了解。为下线操作提供依据。

六、在什么阶段做

在规则中的90天、30天等等数量都是可配置的，可以根据具体的条件，设置为180天、365天等等。但是不管多少天，都是系统已经运行了一段时间，已经有大量的表、大量的任务，需要进行优化，提升平台资源利用率的时候了。所以这个模块可以在平台运行一段时间之后再进行启动。

七、和数据质量间的关系

似乎提交表的治理，很容易让人想到数据质量，是不是在功能上和数据质量重叠了那。

其实，细分一下来看这里的表的治理是对于表本身的，表的名称、备注，表是不是被使用，加工过程是不是符合数据正向流向。但是数据质量治理是针对的表里面数据内容本身。这样细品起来，是不是就能发现这是两个层面的了。当然，如果真要柔和在一起，也是没问题的。这些产品本身不是目标，能够解决数据问题，是一个目标。而且产品也是分久必合，合久必分的。慢慢进化。

八、总结

主动的任务规范性治理，在一个平台后期阶段是必要的，防止不断膨胀的平台表、任务对于资源的浪费是一方面，另一方面，一个干净清爽的表、任务资产，也是开发能够基于此，进行很好迭代升级的基础。