一、数据治理是什么？

1.1、说在前头的话

其实在网上也看了很多数据治理相关的文章，说的也很条理，可能那些作者站的高度很高，他们视角也会很广，感觉读他们的文章会感觉大而广泛，对于开阔自己的视野非常有帮助，笔者想根据自己的工作经验，对数据治理相关的事项，结合自己的经验，以实际例子来描述一下数据如何治理。当然，本文也会涉及一部分技术相关的描述，所以能够对数据基础平台，数据仓库，数据应用等有所了解，会更加好理解笔者想表达的意思。

1.2、数据治理的定义

其实数据治理是一个很广的事情，抽象来讲可以包含数据标准管理，数据质量管理，元数据管理。数据治理的目的是为了让数据变得更加可靠，易用，支持高速迭代。这三点，是目前笔者感触最深的，后续也会一一详细说明。可以试想一下，"不健康"的数据往往比没有数据给企业带来的伤害更大，因为每个企业成立数据部门，希望数据能够带来价值变现，用数据进行赋能，如果数据本身就是不准确的，那么由数据产出的加工品，自然也就变得不那么可信了。

二、数据标准

1.1、说在前头的话

为什么要把数据标准放在最前头，其实整个数据治理过程，是各个环节相互辅助迭代的一个过程。把数据标准放在最前头，是因为笔者觉得数据标准如房屋根基，根基不稳，会导致后续一系列问题。大部分企业，都是业务起来了，才会开始逐步重视数据，这样会面临一个问题，因为业务发展非常快，导致数据方面的建设都是跟着业务跑，缺乏体系化，标准化的建设，举个小例子，在缺乏体系化建设的情况下，想要计算一个指标，直接从明细层去取数，关于数据建模这一块，可以参考一下笔者的一文了解数据库和数据仓库，这样慢慢的就会导致，指标计算越来越复杂，越来越难维护，计算口径很难统一，数据质量也堪忧。那么如何标准呢，笔者分为以下几点：

1.2、数据接入标准

目前企业主要的数据分布在流量日志，关系型数据/非关系型数据库，第三方的一些数据，例如爬虫。

• 流量日志：首先已经要制定埋点规范，如果有埋点系统来约束整个埋点生命周期当然最好，如果没有至少了做到有文档维护，规范制定了还需要强制执行，埋点完成以后，要进行埋点正确性校验，最好能做到各个环节有负责人签字确认。埋点往往是很多企业的痛点，不规范的埋点，会导致后期修改起来很麻烦，不好统一维护，并且会给模型层兼容带来很大的挑战，并且从问题的根因出发，发现埋点问题不应该模型层来兼容，而是应该推动埋点去改正。埋点其实是一个很复杂的工程，本文不做详细描述。

• 关系型数据/非关系型数据库：企业会建立许多独立，但是之间又有联系的业务系统，就拿电商来说，有交易，物流，售后，供应链，商家，会员，品牌等诸多的业务系统，当一个公司发展到一定程度，甚至会出现多个领域业务的拓展。那么这一类数据如何接入到大数据里面呢，一般来讲现在大数据仓库都是使用hive搭建，当然底层还是用HDFS来进行存储。其实有许多接入数据的工具，类似于sqoop，dataX，或者公司自己自研的工具。不管用什么工具，都要做到接入数据的规范。比如说：统一工具，统一明细层命名，统一多少数据量是全量，多少是增量等，一般在数据接入层，在数据模型设计当中会单独设立一层stage（缓冲层），再上层才是ods层，stage层主要作用可以用于修复ods层数据，增量stage合并ods层数据成为全量数据等作用。可以根据自己的业务特点，制定适用的标准。

• 第三方数据：一般多为一些非结构化数据，处理方法也有很多种，暂不详述。

1.3、数据开发标准

开发标准主要指写ETL的一些规范，比如脚本开头要说明这个脚本所属数据域，负责人，开发时间，以及后面在什么时间修改了什么逻辑，都应该在脚本中体现，这么做可以好追溯一个脚本的修改历史，从而好追溯问题，另外是一些sql的格式，表，字段的命名，一些关键逻辑的注释，脚本当中临时表的使用规范等。当然最重要的是hive参数配置，合理化应用资源，这个要画黑板了。

1.4、数据模型规范

数据仓库建设必须要遵循一套规范，就拿现在较为常用的kimball理论，或者说是阿里的onedata体系，在上面说的数据接入，数据域划分，维度表设计，事实表设计等都有理论可以支持。简单说下分层，离线数据仓库，常见的就有stage（缓冲层），ods（明细层），dwb（原子指标层），dws（衍生指标层），app|rpt等报表接口应用层。

1.5、数据服务规范

一套好的数据仓库建设完以后，除了维护其迭代更新，最重要的当然是使其发挥作用，每个公司的应用情况都不一样，例如电子大屏，风控，报表，线上接口等，只要能用上公共层数据的情况，都属于对数据的应用。那么面对诸多的应用，我们在提供数据服务时，就应该要设立权限，监控，告警等规范，当然这也属于数据质量的内容，从某种意义上来讲，遵循标准体现的意义就是提升质量。

三、数据质量

数据质量的范畴也很广，大概分为以下几点：

• 数据完整性：首先数据应该是完整的，没有缺失的，这一点，在数据接入，以及后续数据加工，都需要关注，在接入时，应该配置监控，如果抽取过来的数据量反常，则应该触犯告警，在后续加工当中，应该慎用join关键词，因为可能会导致join丢失。
• 数据时效性
  如果是实时数据，那么数据的时效性，当然毋庸置疑，当然现在flink，storm，spark都可以用来处理流式数据。这里讲述的时效性不仅仅指这些，离线的数据同样具有时效性，比如早上公司领导要看的重要核心报表，你中午才产出，这明显是不能够接受的，所以这也是我们要建设数据仓库的主要原因，下沉公共逻辑，抽象分层，快速产出报表，详细的就不多讲述了。
• 数据生命周期
  数据应该是有生命周期的，而不应该都是永久存在，比如stage层，这种缓冲层的数据，没必要一直保留，占用空间，比如一些不常用的报表接口，几个月都没人访问了，是否可以考虑下线，以防占用计算资源等。
• 唯一性
  数据表应该是具有唯一性的，比如商品维度表的唯一主键应该是商品id，如果商品id都不唯一，这时候应该要配置监控告警等。
• 依赖一致性
  在onedata体系当中，数据分层很细，每一层之间都有相互依赖，执行任务时，必须要保证上游任务都已经执行完成，所以要保证依赖的一致性。
• 正确性
  在数据产出时，务必要保证数据的正确性，这也是为什么一定要做数据的校验工作，因为你要知道，现在不做校验工作，等到这个数据在下游使用过程中出了问题，在排查起来将耗费更多人力物力。
• 可用性
  针对一些拉链表，快照表，多事务事实表，对于无数据建模经验的人来说，使用起来是有一定难度的，所以要做相关表的解释和使用文档，要做到每个字段的注释齐全，枚举完善。

以上所有都是可以通过监控系统进行配置监控的，因为数据质量的问题大多都是人为造成，也是无法避免的，能做的都是配置监控，提醒人不规范的操作，从而进行修改。

四、元数据管理

元数据是描述数据的数据，大数据集成了多个业务系统的数据，打破了数据孤岛，那么怎么有效的将这些数据进行管理是一个很大的问题，每个公司都应该有一个元数据系统来管理数据。一般都会包含以下几个功能：

• 分数据域，分层，责任人等关键的检索功能
• 库，表，字段，枚举的描述信息
• 每个表的生命周期管理
• 每个表的权限，开放范围
• 每个表和上下游的依赖血缘关系
• 每个表的计算逻辑
• 每个表的分区，产出信息，数据量，数据增量等

有了元数据系统可以更好的帮助我们使用数据。