正文
俗话说上线容易下线难，过去我们一直在做加法，并没有一套清晰标准的下线流程，或许从潜意识中对下线这个词就根本不太关注，也导致了数据运维的成本极高，资源浪费的情况严重。
为了能明确数据治理的准确范围，我们需要对已盘点的现状做收敛，明确哪些可下线，哪些可合并。通过现状收敛的梳理，对模型、报表及应用都标注了收敛的类型，分为：可使用、可下线、可合并。
在度假的数据治理开展中，大部分数据域收敛比例为20%-30%，某些数据域可以达到50%以上，当然这也和一些业务线的历史包袱有关。
① 可下线
可下线的标准原则有以下三点：
-
低访问频率：报表及应用近三个月被业务方访问的总频次小于3次；
-
无维护责任人：责任人缺失、离职，并且没有业务方能够描述清楚其背景和口径；
-
报错无下游：长期报错的模型且无人报修，或者已无下游使用，这里说的下游使用包含了依赖关系和即席查询。
②可合并
可合并的标准原则有以下两点：
③ 明确场景
对于很多数仓的同学来说，他们对于业务的理解是存在很大的局限性的，往往习惯于接需求与解决需求，但并没有询问需求背后到底要解决什么，更做不到举一反三。另一方面，我们的归纳也只是一种猜测，是否是真实的需求场景？没有偏差或错误？
此处就是一个大大的问号，明确场景就是要走近业务，探求数据背后的真相与本质。让数据的同学能够更多的了解业务，至少能完整的知道业务使用数据在做些什么，怎么做的，同时让更多的业务场景能够沉淀下来，也是一种对于知识体系的传承。明确场景需要清晰描述以下几点：
-
第一，需求场景的背景是什么，能够解决什么样的问题；
-
第二，需要看什么样的数据，从哪些维度，哪些指标来看；
-
第三，业务是如何利用需求的数据来进行分析和运营的；
-
第四，最终如何落地待解决问题，如何通过数据可衡量。
数据仓库的分层主要解决的是数据的存储与管理，是对数据的横向管理，对于数据权限的控制以及边界的清晰定义也都有着重要的作用。其优势主要体现在以下三点：
-
清晰数据结构：每一个数据分层都有它的作用域和职责，在使用表的时候能更方便地定位和理解数据；
-
减少重复开发：规范数据分层，开发一些通用的中间层数据，能够极大降低重复计算，减少烟囱式开发；
-
统一数据口径：通过数据分层，提供统一的数据出口，统一对外输出的数据口径，避免同一指标不同口径的情况发生。
