### 数据治理背景

越来越多的企业建立起自己的数据仓库和分析平台。

随着数据的积累以及加工流程越来越复杂，企业对数据的管理变得越来越无力，容易出现数据孤岛、数据指标混乱等情况。对数据进行治理呼声越来越紧迫。

然而，数据治理是一个新课题，目前尚无明确的概念定义和方向。

这里，我们提出一套自己的数据治理方案，希望能引起一些共鸣和讨论。


### 数据治理步骤：先理后治


### 数据治理交付内容：

1、字段级数据血缘系统

2、表级数据资产地图

3、数据质量监控及预警

4、减少数据指标冗余度

5、代码质量检查改造机制


### 数据治理的第一个步骤：理

想要治理数据，我们首先得把数据的加工流程理清楚。

打个比方：

将数据的加工流程，比作一条条河流，数据就是河流中的水。

当“水”的质量变差时，我们需要找到污染源。

如何找到污染源？

就得梳理出河流的各个支流的分布图，才能沿着相关的支流查找出污染源。

目前，绝大部分企业的数据，都是以结构化的方式进行存储和加工。

用到的数据库产品，主要是关系型数据库（比如：MySQL、Oracle、Greenplum）和大数据平台的Hive等。

用到的ETL产品，有Datastage、Kettle等。

这些数据加工方式，都可以直接或间接的转化成SQL代码。

因此，要理清楚数据的加工流程，就必须对SQL代码进行梳理，

然后生成字段级别的数据血缘关系。

这就是我们要交付的第一个产品：基于SQL图形化数据血缘系统。

有了字段级别的数据血缘系统之后，我们可以进一步梳理出数据资产。

这里需要对数据资产下一个定义。

所谓数据资产，是那些需要长期保持和积累的数据。

对应的数据库中，数据资产对象，就是那些“正式”表。

因此，我们可以通过剔除数据血缘系统中的中间临时表，获得数据资产表。

经过上面的步骤，我们可以交付第二个产品：基于表的层级化数据资产地图。


有了数据资产地图，我们可以：

1、一目了然看清楚一家企业的数据资产数量；

2、直观的看清楚数据资产的层级和依赖关系；

3、轻松的对数据资产进行责任人或部门的划分。


小结：

当建立起“字段级的数据血缘系统”和“表级的数据资产地图”。我们基本上就实现了数据治理中“理”的部分。


### 数据治理的第二个步骤：治

在“理”清楚数据加工的流程之后，接下来便对数据进行“治”。

目前，在“治”的方面，业界并没有统一的方案。

应该根据各企业的实际情况进行。

这里，我们提出“治”的一些思路，可以分为“被动治理”和“主动治理”两部分。

# 被动治理

就是在用户端发现问题，然后通过血缘系统，快速的进行血缘追溯，定位问题，然后解决。

目前数据问题的排查，基本都需要IT人员以查看分析SQL代码的方式进行逻辑追溯，

这种方式十分耗时，而且容易遗漏，尤其是对代码不熟悉的新人。

有了数据血缘系统的辅助之后，任何用户都可以对任意字段的加工流程进行快速的追溯，

极大的提高了数据问题定位的效率。

# 主动治理

即便数据问题的定位和解决效率再高，也不如让问题不要发生。

为了预防问题的出现，就需要采取一些主动治理的手段。

主动治理的方式和目的，就相对多种多样了。


这里我们可以提几个思路：

1、数据质量监控及预警

提高数据质量应该是数据治理的最重要的目的。

数据质量的指标考量角度主要有两种：技术和业务。

从技术角度，可以分析数据的完整性、唯一性和格式等特征。

从业务角度，可以分析具体指标的合理性等特征。

若要对所有数据资产进行质量监控，无疑是极其消耗资源的，也没有必要。

为了有针对性，只需对那些较为重要的表进行监控即可。

什么表才更为重要？

应该是上游或下游依赖较多的“枢纽”表。

用河流来比喻的话，就是那些有着多条支流会合或发散交叉点。

在这些“交叉点”上进行数据监控，既可事半功倍。

利用数据资产地图，我们可以很容易的找到这些“枢纽表”，对其建立数据质量监控机制。

同时，还可以建立预警机制。

当某一节点的数据出现问题时，利用数据资产地图，

快速找到其下游依赖数据节点，通知其数据负责人或部门，

让其采取相应的措施，避免扩大影响。

通过预警机制，便可有效消除各数据负责人或部门的信息不对称性。


2、减少数据指标冗余度

那些拥有较大规模数据资产的企业，都会存在数据指标冗余的情况：

(1)同一个名称的指标会出现在不同的表中，且值不一样

(2)同一个指标含义和值相同，却有着不同的名称

似乎没有人能说清楚，所有这些相似指标的共性和区别。

数据指标冗余，就像人得了肥胖症一样，让数据显得笨重。

造成数据指标冗余的原因可能多种多样，

不过最大的原因，

应该是企业的各个数据开发小组各自为战，

开发前缺乏统一规划造成的。

建立了字段级的数据血缘系统之后，

专门人员即可分析出现有相似指标的共性和区别，

进而对数据加工流程进行优化设计，

指导各层级数据开发小组进行开发或改造，

逐步降低数据指标的冗余度。


3、代码质量检查改造机制

理论上，代码质量检查并不部署于数据治理的内容。

但它和数据治理有一定的关系，因为代码直接体现了数据的加工逻辑。

不同的数据开发人员，水平参差不齐，不能保证每一个开发人员，都能提供高质量的代码。

因此有检查代码质量的必要。

而且，由于历史原因，企业需要对原有的大量老代码进行改造重写。

如何高效的进行代码改造和质量检查？

这里需要建立起另外一套产品：SQL代码结构图。

它可以演变成另外一个版本的基于SQL图形化数据血缘系统。

不同的是，SQL代码结构图重点展示每一段独立SQL代码的结构图，比如子查询的层级关系，表与表之间的关联关系等。

通过直观的查看SQL代码结构图，更容易判断其是否简洁易懂，更容易确定代码改造的方案。


总结：

数据治理应该是一项复杂的、系统性的、长期的工程，没有一劳永逸的方法。

目前企业的数据治理，很多只是停留在各种数据治理标准的定义上，欠缺高效具体的落地方案。

这里，我们提出一套具体的数据治理方案。

虽可能有不完美之处，但贵在实用，可以落地。

此方案落地之后，可以根据具体的要求，逐步完善。

2021-03-30 23:50:34 | 张良 | 技术 & 提问 | 阅读281次

---

回 复 :