第十四章：数据治理之数据源：数据源的数据接入、业务属性梳理及监控

本章开始，将进入9大模块的介绍。第一个模块我们先介绍：数据源。数据源是整个数据中台数据的来源，是一个起点。更好的管理好数据源这个起点，是数据治理的一个好的开始。

在【数据：业务生数据，数据生“万物”】中提到，“数据的产生来源于业务”。而数据源就是“业务”和“数据”中间的一个连接点。如果连接点的左边是“业务”，那么连接点的右边就是“数据”，通过中间一个小小的连接点，将无限的数据资源释放出来。

在传统的数据源管理中，数据源模块主要提供数据接入的能力，并没有业务属性梳理以及监控的能力。

数据源的数据接入能力，仅仅可以满足数据开发的需求。数据源的业务属性梳理和监控能力，才能满足数据治理的需求。

1、数据源的数据接入

在所有的数据开发平台、数据集成等等产品中，数据源管理一定是一个必备的模块。在这个模块中能够创建各种不同类型的数据源，可以是传统的MySQL、Oracle等，也可以是大数据的HIVE，MPP等。在创建不同类型的数据源时，除了通用的IP、端口、用户名、密码，还根据数据源类型的不同，设置不同的个性化项，目标就是能够对各种类型的数据源进行稳定的连通，成功将数据接入到数据中台中。（暂时不考虑数据导出去的情况。）

保证数据源稳定的连通，仅仅技术属性就足够了，不需要业务属性。

但是缺少了业务属性信息，就会丢失掉这个数据源属于什么业务系统？属于什么领域？这个业务系统是不是核心系统？这个业务系统的联系人是谁，报错了联系谁？对应的数据中台的联系人是谁？

同时，也没有办法回答更加宏观的统计数据。如：公司一共有多少的业务系统已经接入数据中台？接入的表的比例是多少？核心系统是不是都已经入湖了？等等。

所以，在数据源中不仅仅需要技术属性来保证连通性，满足数据接入的需求，还需要对数据源的业务属性进行梳理。

2、数据源的业务属性梳理

业务属性的梳理，可以分层两个方面，一方面是各种业务信息的梳理，一方面是来源准确性的梳理。

业务信息梳理

数据源的业务信息梳理，就是尽可能多的将与数据源相关的业务信息梳理出来。数据源是“业务”和“数据”中间的一个连接点，通过对数据源的“业务”信息梳理，能够让“数据”在“出生”时就更加清楚的知道出身。

这些业务信息包括：属于什么领域？属于什么系统？系统运行状态？是否核心系统？系统业务负责人？系统IT负责人？等等。这些业务系统信息，如果内部有业务系统清单的话，可以抽取已有的业务系统清单，在清单的基础上进行信息维护。如果没有业务系统清单，那么这些信息梳理清楚，其实就是一个公司内部的业务系统清单了。

除了上面的业务信息，还有一些数据源的业务信息：数据源权限负责人、数据源连接状态（能够周期性的监测）、数据源入湖状态、数据源表入湖比例、schema更新状态、连接信息统一搜索信息等等。这些信息的来源又和后面的数据源的监控有关。

通过这些信息的维护，就有效的补全了数据源的业务属性，也就能够回答上面提到的问题了。
来源准确性梳理

前文也提到，数据源是整个数据中台数据的来源。如果确定不了这个数据来源的准确性，那数据的准确性就更无从谈起了，这是保证数据质量的一个关键起点，后续在数据质量模块的时候也会提到，数据质量不仅仅和数据质量模块有关，会和数据治理的方方面面都有关联。

在保证来源准确性时，需要遵循一个原则“数据第一次产生原则”。同一份数据可能会在不同业务系统内流转多次，存在不同业务的数据源中，我们只以数据第一次产生的业务系统为准。

数据从哪里第一次产生，我们就从哪里取。当然，后续对应的业务系统也会对相应的数据负责。这也是“谁产生的数据，谁负责”。

数据源业务属性的梳理，可以让数据源在数据接入的基础能力上，增加更多的业务信息梳理的功能。但是不能保证接入进来的数据源就一直稳定，一直不变。业务在不断的发展，数据源也会不断在变化，所以我们就需要数据源的第三个部分“数据源的监控”。

3、数据源的监控

对数据源的监控，又可以分成主动监控和被动监控（入湖数据信息查询）。

这里的主动和被动，均以数据中台（数据治理实施方）为视角。数据中台能够发起的就是主动监控，由非数据中台的其他方发起的就是被动监控。

主动监控

主动监控，是说数据中台能够对数据源的连通性，数据表、字段的变化等进行主动的监控。如果发生了变化，能够在监控的周期粒度下通知相关人员。

一般连通性监控，会是一个周期性的监控，比如说设置一个定时调度，多长时间进行一次联通性测试，如果不通，则进行告警。数据表、字段的监控会是实时的监控，主要是监听业务数据库的日志信息，发现相应的变化，则进行实时告警。

主动的监控，有一个很大的问题，就是滞后性。我们监控的都是业务系统的生产环境，当通过监控发现连通性异常，或者数据表、字段的变化时，对于数据中台来说，其实已经晚了。因为业务系统生产环境的上线时间点一般会放在晚上，这种时候监控到变化，即使收到了通知，也没有时间进行数据中台任务调整。能做的，只有提前于数据消费者知道数据可能出现异常，进行提前告知。

如果出现这种情况影响了数据正常产出，大部分时候都会吐槽业务系统上线不通知数据中台，因此才造成了，比如表结构变化情况下，任务运行失败，影响了数据中台的任务运行，影响了数据的稳定性。

但是，说实话这种指责多少有点“找借口”。即使发布一个政策，规定业务系统每次上线都必须通知数据中台，那么没有工具落地的这个政策，个人也认为是走不长远的。

一方面如果所有的业务上线都通知数据中台，数据中台就需要花费大量人力、精力去判断，本次上线是否影响数据中台。这还先不论是否有这个通畅的通知渠道建立了。另一方面，就是数据中台的人在频繁接到通知，但是发现大部分都不会影响之后，紧迫性也相应降低了。

还有就是，数据稳定的第一责任人是数据中台，这种情况的出现应该找办法给解决掉。而不是明知可能有这个问题隐患，还将所有希望寄托在别人的通知上面。

所以，我们需要另一种更加提前的被动监控。
被动监控（入湖数据信息查询）

被动监控，或者叫入湖数据信息查询。这里的被动是对数据中台来说的，主动方是业务系统。业务系统主动的进行入湖数据信息查询，数据中台被动的接受入湖数据信息查询。

实现被动监控，有两个关键点，一个关键点就是数据中台提供一个接口，能够查询出来入湖的业务数据哪些是不能变的，变了就会对数据中台的每日任务运行产生影响。这样就能够让业务系统上线前，通过调用这个接口，知道本次上线如果有表的修改，这些表的修改是否会对数据中台的任务运行产生影响。如果是大的变更，甚至可以提前调用接口，在业务系统开发的过程中，就通过调用接口，从而提醒数据中台进行相应的任务调整。

另一个关键点，就是需要能够在业务系统上线发布流程中，嵌入这个环节，即如果修改的表结构有影响已入湖的表，则触发一个告警，通知数据中台人员，中台人员审批通过之后，才允许审批继续。如果不影响，则自动跳过这个环节，继续业务系统的上线发布。

这样，通过主动监控和被动监控，就可以将业务系统变更对数据中台任务运行的影响降到最低了。甚至，有了被动监控，主动监控中的数据表、字段的变更监控都不需要了。

4、五大维度说明

在5大维度的章节中，也多次说明，5个维度是服务于每一个模块的。通过5个维度让每个模块更好的有计划的、可执行的推进实施。下面说下在数据源上，需要的维度设置。在每个模块章节中，只对维度的个性化部分进行说明，详细了解各个维度，可以看之前的维度介绍章节。

组织组织的设置是相对稳定的，或者说在实现一个阶段目标之前是稳定的。所以，组织维度对各个模块相对通用，不需要针对不同的模块，对组织维度进行调整，均采用以联邦式为基础的三层组织架构即可。（后续模块如果对于组织维度没有特殊要求，不会再单独列举此模块）

重点关注的是，数据源作为一个数据接入的起点，在这个阶段需要确定好组织架构中第三层：执行层，中角色的具体人选，主要就是数据管家（也叫数据BP），和数据合伙人。为不同业务领域和数据源确定好对应的具体人选。

这两个角色也呼应在文章开头我们提到的【数据源就是“业务”和“数据”中间的一个连接点。如果连接点的左边是“业务”，那么连接点的右边就是“数据”，通过中间一个小小的连接点，将无限的数据资源释放出来。】其中的，数据合伙人负责这个连接点左侧，数据管家负责这个连接点右侧。

政策

在三层政策：总则-规范-操作手册中，需要给不同模块分别制定的是“规范-操作手册”这两层。

政策并不一定是越多越好，在不同模块在进行执行过程中依据具体的情况，来决定是否需要制定具体政策，也主要针对跨组织的、有争议的进行政策制定。

在数据源模块中，有两点需要在政策中明确出来。

第一点是，一定需要明确统一入湖的规范要求，将入湖这件事情和不同的业务系统达成共识：如何入湖？怎么配合？核心系统是否必须入湖？需要进行入湖业务信息的统计收集、梳理有多少业务系统？入湖是否有一个入湖标准？针对入湖的奖惩是什么？这一点也主要对应上面第二小节的【数据源的业务属性梳理】。

第二点是，针对数据表和字段的变化，能够整合到现有的系统发布流程中，进行被动的数据源监控。让业务系统进行变更前能够提前通知到数据中台。这个即涉及到跨系统，又涉及到修改现有发布流程。这一点主要对应上面第三小节的【数据源的监控】。
工具关于工具，我们已经在维度部分进行了说明了。工具的重要性，工具尴尬的位置等等。在具体的不同模块中时，我们着重的介绍不同模块中需要准备的工具的特性。一个工具如果要详细说清楚，最好有一个原型，这里仅仅是对不同模块工具进行概况说明。

在数据源模块，工具需要支持第一小节的【数据源的数据接入】的一些常规能力设置，支持不同的类型的数据源的创建、编辑、删除，连通测试，等等。

需要支持第二小节【数据源的业务属性梳理】中的不同的业务属性的记录、保存、查询。这个过程中，需要能够对政策第一点中明确需要的规范进行落地执行，并能够统计有多少不符合政策的业务系统，从而提供奖惩依据。

需要支持第三小节【数据源的监控】中需要的接口能够，供业务系统，或者上线发布流程进行调用。来满足数据源的监控需求。