也谈数据治理

也谈数据治理

|0x00 数据治理是什么

数据治理，在不同行业的概念，可能不同。比如在国家标准化管理委员会发布《信息技术服务治理第5部分：数据治理规范》，从非常宏观的角度来制定，侧重于拉通概念和达成共识，像一种“国家标准”；《华为数据之道》是从企业数字化的角度切入下去，侧重数据治理体系和方法论，属于一种“管理方案”；而阿里推出的《大数据之路》一书，则在数据技术层面给出了有价值的指导，算是具体的“实现方案”了。

DAMA（国际数据管理协会）给“数据治理”下的定义是：数据治理是对数据资产管理行使权力和控制的活动集合。DGI（国际数据治理研究所）则认为：数据治理是一个通过一系列信息相关的过程来实现决策权和职责分工的系统，这些过程按照达成共识的模型来执行，该模型描述了谁（Who）能根据什么信息，在什么时间（When）和情况（Where）下，用什么方法（How），采取什么行动（What）。IBM（数据治理委员会）提出的数据治理概念中，将“数据治理”相关的要素划分为了四个层次，分别是：支持规程、核心规程、支持条件和成果。

在主数据领域，也有数据治理的诉求，MDM（Master Data Management）就代表这个事情。可以参考2018年中国信通院牵头编写的《主数据管理实践白皮书》，也给出了相关建议。

以上可以看出，“数据治理”这个主题，大家都看得懂明面意思，但太过于宽泛，以至于很多细节争论颇多，各行各业也都有自己的看法。从笔者自身的经历出发，在互联网的工作中，数据治理更多的是从经营的角度出发，来控制成本（包括人力、机器、技术债务等）增长不超过业务的增长，同时能够支持业务的长期、快速的使用需求。数据治理涉及到的地方，包括了“数据开发、数据质量、数据安全”这几个岗位。

因此，我们大体上明确了这个概念，即“数据治理”（Data Governance）是组织中涉及数据使用的一整套管理行为。由企业数据治理部门发起并推行，关于如何制定和实施针对整个企业内部数据的商业应用和技术管理的一系列政策和流程（以上来源于：百度百科）。

“数据治理”对抗的是三个老大难：“复杂性困局”、“信息不对称（包括数据孤岛与跨部门沟通）”和“惰性心理”。因此，数据治理需要一个系统性的工程来对抗，站在数据从生产到使用的全链路视角，通过技术工具的改进（释放技术红利），来定性定量的分析问题原因，并通过运营手段来最终落地，最终控制数据成本与复杂度有序增长。

刚才这段话看着很“八股”，其实我觉得找不到更简化的语言来描述了，如果能的话，大概就是“统一标准”、“严格规范”，统一标准可以按照“一致性维度”的角度来考虑，“严格规范”则从制度和工具两个方向来改进。

|0x01 基于一致性维度的思考

在Kimball的维度建模理论中，有一个很重要的概念叫Conformed Dimension，中文一般翻译为“一致性维度”。“一致性维度”是构建多维分析体系的三个关键性概念之一，另两个是总线架构（Bus Architecture）和一致性事实（Conformed Fact）。

在《数据仓库工具箱》（第三版）中，也提到了数据治理的问题，是站在一致性维度的角度上来看待。在绝大多数组织中，业务数据相关的规则，包括概念和口径，都是业务团队自己定义的，这样很容易导致数据孤岛问题的出现，因此通常需要比较高阶的领导来推动数据治理的工作。书中提到了这个领导应该具备的素养，包括：

‒ 来自组织内部；
‒ 对企业的业务有非常广泛的了解；
‒ 能够平衡组织诉求与业务发展的需要；
‒ 具备比较高的权威；
‒ 非常强的与人打交道的能力；
‒ 具备谈判技巧，以确保目的的达成。

很明显，能够做到这些事情的人并不多，在大多数行业中，能够对一致性维度下定义的人太少，因此很多人会认为一致性维度非常困难。这种问题便是思维上转变的问题，即业务团队按照自己的诉求来发展，转换到从公司层面上出发，为整个公司的业务来推动数据的共享。例如，财务团队就有比较统一的一致性维度，它有一个为人熟知的名字：“统一会计科目”，这样数据跟业务就有了很好的映射关系。

因此，数据中台的概念被发明，并且迅速普及起来，因为数据确实需要放在一起，才能做好有效的管理。在互联网企业，有两个地方非常看重数据的一致性维度，是数仓团队的公共层，以及业务团队的主数据。

在数仓团队，数据公共层的英文是CDM，Common Data Model，直译过来便是通用数据模型。CDM包括了DIM维表、DWD业务过程与DWS汇总表，是直接基于源系统ODS开发的，主要是面向数据域设计，建立一致性维度、一致性事实。在公共层强一致的基础上，下游ADS便可以根据不同的业务诉求，做相应的业务开发，保障数据的一致性。

在业务团队，主数据的英文是MDM，MD Master Data，主数据管理又可以翻译成Master Data Management，指系统间共享数据（例如，客户、供应商、账户和组织部门相关数据）。与记录业务活动，波动较大的交易数据相比，主数据（也称基准数据）变化缓慢，主数据跟元数据类似，只有避免了碎片化建设，通过标准的数据体系来支持业务数字化转型的数据，才是好的主数据。主数据如何用起来？除了提供标准的数据接口之外，更重要的就是给数据中台提供标准的业务数据，然后数据中台通过标准的数据来积累标准的业务过程数据，这样历史上的信息，才不至于因为系统的调整，失去了统计的意义。某种意义上，领域建模，就是考虑如何把主数据划分好。

1.png

在互联网公司中，由于业务的复杂性，通常还会定义很多其他的标准：如标准的英文简称、数据表的标准命名方法等，这些都很好的规定了数据各个方向的“标准”，是对抗系统“熵增”，控制复杂性增加的有效方法。

但真实的业务总是超出我们想象的复杂，即便按照刚才的规范做过整理，不同业务之间的复杂性依旧是一个很大的挑战。定个“标准”总是容易的，但定个“好标准”却是动态的一个过程，这里面比拼的，就是我们对业务的深度理解和思考能力。

|0x02 “严格规范”：从人到工具的改进

做治理的另一个思路，便是制定严格的规范标准，在大厂，各种规范通常包含在了“安全生产”的大概念下，包括了代码规范、上线规范、运维规范等多个场景。但这些规范通常是按照人的角度来组织的，因此需要成立相应的组织来应对，并嵌入在项目研发流程中，通过一些标准化的看板来监控日常的执行情况。

严格的规范，其实对抗的就是“人性”，当一个人在同一个岗位待久了之后，懈怠的心理是一定会出现的。就像程序员的自嘲：“自己熟悉的业务，很清楚坑在哪里，自己会避免踩到，但因为懒得写到文档里，所以后人接手的时候，就踩上了一个又一个的坑，这时候重构，就是避免踩更多坑的好方法，但本质上还是重复了‘挖坑-跳坑-填坑-挖坑’的模式”。

因此我们就进入了借助工具，来辅助开发的阶段。

工具解决问题的第一个思路，是以产品的方式，来搞定数据的流转问题。例如在数据埋点的场景中，不论是哪一种业务形态，其基础的特点都是数据打点、加密压缩、网络传输、数据校对等共通的能力，通过产品来实现全自动化，相当于让工具代替了人做开发，其规范是可以得到有效保障的。这种方式非常像“SAAS”解决方案。

工具解决问题的第二个思路，是以完备的监控工具，辅助非标准场景做建模。监控工具包括了代码规范检查器、任务运行监控、数据血缘追踪、DQC检查校验，来配合人把检查和运维的压力释放出来，专心用在业务场景的建模与优化上。这种方式非常像“PAAS”解决方案。

工具解决问题的第三个思路，是利用技术的发展，推动根本性问题的解决。比如因为数据库性能的瓶颈，业务要用到的数据库包括了NOSQL、MPP等各种OLAP的、OLTP的数据方案，本身监控就不好做，但如果把OLTP和OLAP数据库能够用一套方案来解决，就可以避免多个地方维度的问题，TiDB就在尝试做类似的事情。另外数据成本的增加，本身也与分布式系统的冗余备份、压缩技术强相关，把系统做的更可靠，本身就能够节约不少的存储成本，也算是一种根本性问题解决的思路。这种方式非常像“IAAS”解决方案。

因此，数据治理很难有标准的解决方案，更多的是根据业务场景的不同，选择合适自己的方法。

|0xFF 治理新思路：用数据来治理数据

这个思路在之前的文章《数据资产治理概要：用数据来治理数据》中提到过，这里想说一些更深入的内容。

用工具解决问题，是工业化时代的思路，而随着时代步入了数字化，信息量的爆炸式增长、复杂性的不断加深，都导致了工具也无法完全解决问题，因为工具的本质是给人提效，而不是机器解决机器自己的问题。用数据来推动数据治理，本质上就是通过数据来洞察数据自己的问题，进一步提升了解决问题的效率，就像运维通过自动化的监控系统，一人管理几千台服务器一样，数据工程师通过自动化的数据监控机制，一个人维护几千张表也就不是什么问题了。什么是维护？不仅仅是保证表不出错，也包括了识别不合理资源消耗、下线旧业务表、动态检查模型复用程度等。

维度建模本质上是一种规则，模型好不好本质上也是一种规则，既然都是规则，那么就可以通过“翻译”的形式，来做成一种工具，来实施监控。当然机器也有做不到的地方，比如：一张表仅有一个下游，对比一张表有一千个下游，哪个价值更高？这个真不好回答，事实上强如机器学习，也需要人工大量参与的地方，所以借鉴打标等改进的方法，可以对监控系统本身做出一些改变。

但治理动作本身，就会对业务有比较强的入侵性，而“数据驱动”的本意，是用数据驱动业务增长，但不是主导业务发展思路。实际的开发过程中，技术都是对业务结果负责的，即便是中后台部门，也面临比较大的前台业务压力，因此治理通常是数据团队自己捣鼓的东西，除了能够更好的应对业务增长外，其余的价值大概也就是降低成本了，因此从公司整体的战略高度来看，数据治理的重要性，显然还提不上日程。换句话说，先有业务打赢了，你才有机会去治理数据。

当然，一些政策主导的地方，比如政府部门，对数据治理的理解，就不是这样了，更倾向于通过军令状的形式，用“行政”而非“技术”方法，来解决数据中存在的问题，如下图所示。

2.png

在“行政”治理的思路下，数据治理的原则就是“要从源头控制，不要先污染后治理”，但在“业务”先行的思路下，数据治理又会变成“危机驱动”的方式来解决。但有一点是共同的，就是数据治理的过程要贯穿到整个业务迭代的过程中，剩下的就是方法的选择了。

数据治理是一件体系化的工程，数字化时代，这是一个新兴的方向，值得做出探索。