| 编辑推荐: |
本文主要介绍
在数据源头加强企业数据的治理，让常态化治理成为日常业务，才能从根本上彻底解决企业数据质量的各种问题，希望对您的学习有所帮助。
本文来自于
数澜社区
，由Alice编辑、推荐。 |
|
一、数据仓库
数据仓库概念
英文名称为Data Warehouse，可简写为DW或DWH。数据仓库的目的是构建面向分析的集成化数据环境，为企业提供决策支持（Decision Support）。它出于分析性报告和决策支持目的而创建。
数据仓库本身并不“生产”任何数据，同时自身也不需要“消费”任何的数据，数据来源于外部，并且开放给外部应用，这也是为什么叫“仓库”，而不叫“工厂”的原因。
基本特征
数据仓库是面向主题的、集成的、非易失的和时变的数据集合，用以支持管理决策。
面向主题:
传统数据库中，最大的特点是面向应用进行数据的组织，各个业务系统可能是相互分离的。而数据仓库则是面向主题的。主题是一个抽象的概念，是较高层次上企业信息系统中的数据综合、归类并进行分析利用的抽象。在逻辑意义上，它是对应企业中某一宏观分析领域所涉及的分析对象。
集成性:
通过对分散、独立、异构的数据库数据进行抽取、清理、转换和汇总便得到了数据仓库的数据，这样保证了数据仓库内的数据关于整个企业的一致性。
数据仓库中的综合数据不能从原有的数据库系统直接得到。因此在数据进入数据仓库之前，必然要经过统一与综合，这一步是数据仓库建设中最关键、最复杂的一步，所要完成的工作有：
要统一源数据中所有矛盾之处，如字段的同名异义、异名同义、单位不统一、字长不一致，等等。
进行数据综合和计算。数据仓库中的数据综合工作可以在从原有数据库抽取数据时生成，但许多是在数据仓库内部生成的，即进入数据仓库以后进行综合生成的。
下图说明一个保险公司综合数据的简单处理过程，其中数据仓库中与“保险” 主题有关的数据来自于多个不同的操作型系统。这些系统内部数据的命名可能不同，数据格式也可能不同。把不同来源的数据存储到数据仓库之前，需要去除这些不一致。
非易失性（不可更新性）
数据仓库的数据反映的是一段相当长的时间内历史数据的内容，是不同时点的数据库快照的集合，以及基于这些快照进行统计、综合和重组的导出数据。
数据非易失性主要是针对应用而言。数据仓库的用户对数据的操作大多是数据查询或比较复杂的挖掘，一旦数据进入数据仓库以后，一般情况下被较长时间保留。数据仓库中一般有大量的查询操作，但修改和删除操作很少。因此，数据经加工和集成进入数据仓库后是极少更新的，通常只需要定期的加载和更新。
时变性
数据仓库包含各种粒度的历史数据。数据仓库中的数据可能与某个特定日期、星期、月份、季度或者年份有关。数据仓库的目的是通过分析企业过去一段时间业务的经营状况，挖掘其中隐藏的模式。虽然数据仓库的用户不能修改数据，但并不是说数据仓库的数据是永远不变的。分析的结果只能反映过去的情况，当业务变化后，挖掘出的模式会失去时效性。因此数据仓库的数据需要更新，以适应决策的需要。从这个角度讲，数据仓库建设是一个项目，更是一个过程。数据仓库的数据随时间的变化表现在以下几个方面：
（1） 数据仓库的数据时限一般要远远长于操作型数据的数据时限。
（2） 操作型系统存储的是当前数据，而数据仓库中的数据是历史数据。
（3） 数据仓库中的数据是按照时间顺序追加的，它们都带有时间属性。
数据仓库与数据库的区别
数据库与数据仓库的区别实际讲的是 OLTP 与 OLAP 的区别。
操作型处理，叫联机事务处理 OLTP（On-Line Transaction Processing，），也可以称面向交易的处理系统，它是针对具体业务在数据库联机的日常操作，通常对少数记录进行查询、修改。 用户较为关心操作的响应时间、数据的安全性、完整性和并发支持的用户数等问题。 传统的数据库系统作为数据管理的主要手段，主要用于操作型处理，像Mysql，Oracle等关系型数据库一般属于OLTP。
分析型处理，叫联机分析处理 OLAP（On-Line Analytical Processing）一般针对某些主题的历史数据进行分析，支持管理决策。
首先要明白，数据仓库的出现，并不是要取代数据库。数据库是面向事务的设计，数据仓库是面向主题设计的。数据库一般存储业务数据，数据仓库存储的一般是历史数据。
数据库设计是尽量避免冗余，一般针对某一业务应用进行设计，比如一张简单的User表，记录用户名、密码等简单数据即可，符合业务应用，但是不符合分析。 数据仓库在设计是有意引入冗余，依照分析需求，分析维度、分析指标进行设计。
数据库是为捕获数据而设计，数据仓库是为分析数据而设计。
以银行业务为例。数据库是事务系统的数据平台，客户在银行做的每笔交易都会写入数据库，被记录下来，这里，可以简单地理解为用数据库记账。数据仓库是分析系统的数据平台，它从事务系统获取数据，并做汇总、加工，为决策者提供决策的依据。比如，某银行某分行一个月发生多少交易，该分行当前存款余额是多少。如果存款又多，消费交易又多，那么该地区就有必要设立ATM了。
显然，银行的交易量是巨大的，通常以百万甚至千万次来计算。事务系统是实时的，这就要求时效性，客户存一笔钱需要几十秒是无法忍受的，这就要求数据库只能存储很短一段时间的数据。而分析系统是事后的，它要提供关注时间段内所有的有效数据。这些数据是海量的，汇总计算起来也要慢一些，但是，只要能够提供有效的分析数据就达到目的了。
数据仓库，是在数据库已经大量存在的情况下，为了进一步挖掘数据资源、为了决策需要而产生的，它决不是所谓的“大型数据库”。
数据仓库分层架构
按照数据流入流出的过程，数据仓库架构可分为： 源数据、数据仓库、数据应用
数据仓库
数据仓库的数据来源于不同的源数据，并提供多样的数据应用，数据自下而上流入数据仓库后向上层开放应用，而数据仓库只是中间集成化数据管理的一个平台。
源数据 ：此层数据无任何更改，直接沿用外围系统数据结构和数据，不对外开放；为临时存储层，是接口数据的临时存储区域，为后一步的数据处理做准备。
数据仓库 ：也称为细节层，DW层的数据应该是一致的、准确的、干净的数据，即对源系统数据进行了清洗（去除了杂质）后的数据。
数据应用 ：前端应用直接读取的数据源；根据报表、专题分析需求而计算生成的数据。
数据仓库从各数据源获取数据及在数据仓库内的数据转换和流动都可以认为是ETL （抽取Extra, 转化Transfer, 装载Load） 的过程，ETL是数据仓库的流水线，也可以认为是数据仓库的血液，它维系着数据仓库中数据的新陈代谢，而数据仓库日常的管理和维护工作的大部分精力就是保持ETL的正常和稳定。
那么为什么要数据仓库进行分层呢?
用空间换时间，通过大量的预处理来提升应用系统的用户体验（效率），因此数据仓库会存在大量冗余的数据；不分层的话，如果源业务系统的业务规则发生变化将会影响整个数据清洗过程，工作量巨大。
通过数据分层管理可以简化数据清洗的过程，因为把原来一步的工作分到了多个步骤去完成，相当于把一个复杂的工作拆成了多个简单的工作，把一个大的黑盒变成了一个白盒，每一层的处理逻辑都相对简单和容易理解，这样我们比较容易保证每一个步骤的正确性，当数据发生错误的时候，往往我们只需要局部调整某个步骤即可。
数据仓库元数据的管理
元数据（Meta Date），主要记录数据仓库中模型的定义、各层级间的映射关系、监控数据仓库的数据状态及ETL的任务运行状态。 一般会通过元数据资料库（Metadata Repository）来统一地存储和管理元数据，其主要目的是使数据仓库的设计、部署、操作和管理能达成协同和一致。
元数据是数据仓库管理系统的重要组成部分，元数据管理是企业级数据仓库中的关键组件，贯穿数据仓库构建的整个过程，直接影响着数据仓库的构建、使用和维护。
构建数据仓库的主要步骤之一是ETL。这时元数据将发挥重要的作用，它定义了源数据系统到数据仓库的映射、数据转换的规则、数据仓库的逻辑结构、数据更新的规则、数据导入历史记录以及装载周期等相关内容。数据抽取和转换的专家以及数据仓库管理员正是通过元数据高效地构建数据仓库。
用户在使用数据仓库时，通过元数据访问数据，明确数据项的含义以及定制报表。
数据仓库的规模及其复杂性离不开正确的元数据管理，包括增加或移除外部数据源，改变数据清洗方法，控制出错的查询以及安排备份等。
元数据可分为技术元数据和业务元数据。 技术元数据 为开发和管理数据仓库的IT 人员使用，它描述了与数据仓库开发、管理和维护相关的数据，包括数据源信息、数据转换描述、数据仓库模型、数据清洗与更新规则、数据映射和访问权限等。而 业务元数据 为管理层和业务分析人员服务，从业务角度描述数据，包括商务术语、数据仓库中有什么数据、数据的位置和数据的可用性等，帮助业务人员更好地理解数据仓库中哪些数据是可用的以及如何使用。
由上可见，元数据不仅定义了数据仓库中数据的模式、来源、抽取和转换规则等，而且是整个数据仓库系统运行的基础，元数据把数据仓库系统中各个松散的组件联系起来，组成了一个有机的整体。
数仓建模方法
数据仓库的建模方法有很多种，每一种建模方法代表了哲学上的一个观点，代表了一种归纳、概括世界的一种方法。常见的有 范式建模法、维度建模法、实体建模法 等，每种方法从本质上将是从不同的角度看待业务中的问题。
1. 范式建模法（Third Normal Form，3NF）
范式建模法其实是我们在构建数据模型常用的一个方法，该方法的主要由 Inmon 所提倡，主要解决关系型数据库的数据存储，利用的一种技术层面上的方法。目前，我们在关系型数据库中的建模方法，大部分采用的是三范式建模法。
范式 是符合某一种级别的关系模式的集合。构造数据库必须遵循一定的规则，而在关系型数据库中这种规则就是范式，这一过程也被称为规范化。目前关系数据库有六种范式：第一范式（1NF）、第二范式（2NF）、第三范式（3NF）、Boyce-Codd范式（BCNF）、第四范式（4NF）和第五范式（5NF）。
在数据仓库的模型设计中，一般采用第三范式。一个符合第三范式的关系必须具有以下三个条件 :
每个属性值唯一，不具有多义性 ;
每个非主属性必须完全依赖于整个主键，而非主键的一部分 ;
每个非主属性不能依赖于其他关系中的属性，因为这样的话，这种属性应该归到其他关系中去。
范式建模
根据 Inmon 的观点，数据仓库模型的建设方法和业务系统的企业数据模型类似。在业务系统中，企业数据模型决定了数据的来源，而企业数据模型也分为两个层次，即主题域模型和逻辑模型。同样，主题域模型可以看成是业务模型的概念模型，而逻辑模型则是域模型在关系型数据库上的实例化。
2. 维度建模法（Dimensional Modeling）
维度模型是数据仓库领域另一位大师Ralph Kimall所倡导，他的《数据仓库工具箱》是数据仓库工程领域最流行的数仓建模经典。维度建模以分析决策的需求出发构建模型，构建的数据模型为分析需求服务，因此它重点解决用户如何更快速完成分析需求，同时还有较好的大规模复杂查询的响应性能。
维度建模
典型的代表是我们比较熟知的星形模型（Star-schema），以及在一些特殊场景下适用的雪花模型（Snow-schema）。
维度建模中比较重要的概念就是 事实表（Fact table）和维度表（Dimension table）。其最简单的描述就是，按照事实表、维度表来构建数据仓库、数据集市。
目前在互联网公司最常用的建模方法就是维度建模，稍后将重点讲解
3. 实体建模法（Entity Modeling）
实体建模法并不是数据仓库建模中常见的一个方法，它来源于哲学的一个流派。从哲学的意义上说，客观世界应该是可以细分的，客观世界应该可以分成由一个个实体，以及实体与实体之间的关系组成。那么我们在数据仓库的建模过程中完全可以引入这个抽象的方法，将整个业务也可以划分成一个个的实体，而每个实体之间的关系，以及针对这些关系的说明就是我们数据建模需要做的工作。
虽然实体法粗看起来好像有一些抽象，其实理解起来很容易。即我们可以将任何一个业务过程划分成 3 个部分， 实体，事件，说明 ，如下图所示：
实体建模
上图表述的是一个抽象的含义，如果我们描述一个简单的事实：“小明开车去学校上学”。以这个业务事实为例，我们可以把“小明”，“学校”看成是一个实体，“上学”描述的是一个业务过程，我们在这里可以抽象为一个具体“事件”，而“开车去”则可以看成是事件“上学”的一个说明。
维度建模
维度建模是专门应用于分析型数据库、数据仓库、数据集市建模的方法。数据集市可以理解为是一种"小型数据仓库"。
1. 维度建模中表的类型
事实表发生在现实世界中的操作型事件，其所产生的可度量数值，存储在事实表中。从最低的粒度级别来看，事实表行对应一个度量事件，反之亦然。
事实表表示对分析主题的度量 。比如一次购买行为我们就可以理解为是一个事实。
事实与维度
图中的订单表就是一个事实表，你可以理解他就是在现实中发生的一次操作型事件，我们每完成一个订单，就会在订单中增加一条记录。事实表的特征：表里没有存放实际的内容，他是一堆主键的集合，这些ID分别能对应到维度表中的一条记录。事实表包含了与各维度表相关联的外键，可与维度表关联。事实表的度量通常是数值类型，且记录数会不断增加，表数据规模迅速增长。
明细表（宽表） ：
事实表的数据中，有些属性共同组成了一个字段（糅合在一起），比如年月日时分秒构成了时间,当需要根据某一属性进行分组统计的时候，需要截取拼接之类的操作，效率极低。如：
为了分析方便，可以事实表中的一个字段切割提取多个属性出来构成新的字段，因为字段变多了，所以称为宽表，原来的成为窄表。
将上述的local_time字段扩展为如下6个字段：
又因为宽表的信息更加清晰明细，所以也可以称之为明细表。
2．维度表
每个维度表都包含单一的主键列。维度表的主键可以作为与之关联的任何事实表的外键，当然，维度表行的描述环境应与事实表行完全对应。维度表通常比较宽，是扁平型非规范表，包含大量的低粒度的文本属性。
维度表示你要对数据进行分析时所用的一个量，比如你要分析产品销售情况， 你可以选择按类别来进行分析，或按区域来分析。每个类别就构成一个维度。上图中的用户表、商家表、时间表这些都属于维度表，这些表都有一个唯一的主键，然后在表中存放了详细的数据信息。
总的说来，在数据仓库中不需要严格遵守规范化设计原则。因为数据仓库的主导功能就是面向分析，以查询为主，不涉及数据更新操作。 事实表的设计是以能够正确记录历史信息为准则，维度表的设计是以能够以合适的角度来聚合主题内容为准则。
2. 维度建模三种模式
星型模式
星形模式(Star Schema)是最常用的维度建模方式。星型模式是以事实表为中心，所有的维度表直接连接在事实表上，像星星一样。星形模式的维度建模
由一个事实表和一组维表成，且具有以下特点：a. 维表只和事实表关联，维表之间没有关联；b. 每个维表主键为单列，且该主键放置在事实表中，作为两边连接的外键；c. 以事实表为核心，维表围绕核心呈星形分布；
2.雪花模式
雪花模式(Snowflake Schema)是对星形模式的扩展。雪花模式的维度表可以拥有其他维度表的，虽然这种模型相比星型更规范一些，但是由于这种模型不太容易理解，维护成本比较高，而且性能方面需要关联多层维表，性能也比星型模型要低。所以一般不是很常用。
 
3．星座模式
星座模式是星型模式延伸而来，星型模式是基于一张事实表的，而星座模式是基于多张事实表的，而且共享维度信息。前面介绍的两种维度建模方法都是多维表对应单事实表，但在很多时候维度空间内的事实表不止一个，而一个维表也可能被多个事实表用到。在业务发展后期，绝大部分维度建模都采用的是星座模式。
3. 维度建模过程
我们知道维度建模的表类型有事实表，维度表；模式有星形模型，雪花模型，星座模型这些概念了，但是实际业务中，给了我们一堆数据，我们怎么拿这些数据进行数仓建设呢，数仓工具箱作者根据自身60多年的实际业务经验，给我们总结了如下四步，请务必记住！
数仓工具箱中的维度建模四步走：
维度建模四步走
请 牢记 以上四步，不管什么业务，就按照这个步骤来，顺序不要搞乱，因为这四步是环环相扣，步步相连。下面详细拆解下每个步骤怎么做
1、选择业务过程
维度建模是紧贴业务的，所以必须以业务为根基进行建模，那么选择业务过程，顾名思义就是在整个业务流程中选取我们需要建模的业务，根据运营提供的需求及日后的易扩展性等进行选择业务。比如商城，整个商城流程分为商家端，用户端，平台端，运营需求是总订单量，订单人数，及用户的购买情况等，我们选择业务过程就选择用户端的数据，商家及平台端暂不考虑。业务选择非常重要，因为后面所有的步骤都是基于此业务数据展开的。
2、声明粒度
先举个例子：对于用户来说，一个用户有一个身份证号，一个户籍地址，多个手机号，多张银行卡，那么与用户粒度相同的粒度属性有身份证粒度，户籍地址粒度，比用户粒度更细的粒度有手机号粒度，银行卡粒度，存在一对一的关系就是相同粒度。为什么要提相同粒度呢，因为维度建模中要求我们，在同一事实表中，必须具有相同的粒度，同一事实表中不要混用多种不同的粒度，不同的粒度数据建立不同的事实表。并且从给定的业务过程获取数据时，强烈建议从关注原子粒度开始设计，也就是从最细粒度开始，因为原子粒度能够承受无法预期的用户查询。但是上卷汇总粒度对查询性能的提升很重要的，所以对于有明确需求的数据，我们建立针对需求的上卷汇总粒度，对需求不明朗的数据我们建立原子粒度。
3、确认维度
维度表是作为业务分析的入口和描述性标识，所以也被称为数据仓库的“灵魂”。在一堆的数据中怎么确认哪些是维度属性呢，如果该列是对具体值的描述，是一个文本或常量，某一约束和行标识的参与者，此时该属性往往是维度属性，数仓工具箱中告诉我们牢牢掌握事实表的粒度，就能将所有可能存在的维度区分开，并且要确保维度表中不能出现重复数据，应使维度主键唯一
4、确认事实
事实表是用来度量的，基本上都以数量值表示，事实表中的每行对应一个度量，每行中的数据是一个特定级别的细节数据，称为粒度。维度建模的核心原则之一是同一事实表中的所有度量必须具有相同的粒度。这样能确保不会出现重复计算度量的问题。有时候往往不能确定该列数据是事实属性还是维度属性。记住最实用的事实就是数值类型和可加类事实。所以可以通过分析该列是否是一种包含多个值并作为计算的参与者的度量，这种情况下该列往往是事实。
实际业务中数仓分层
数仓分层要结合公司业务进行，并且需要清晰明确各层职责，要保证数据层的稳定又要屏蔽对下游影响，一般采用如下分层结构：
数据分层架构
数据层具体实现
使用四张图说明每层的具体实现
数据源层ODS
数据源层
数据源层主要将各个业务数据导入到大数据平台，作为业务数据的快照存储。
数据明细层DW
数据明细层
事实表中的每行对应一个度量，每行中的数据是一个特定级别的细节数据，称为粒度。维度建模的核心原则之一是 同一事实表中的所有度量必须具有相同的粒度 。这样能确保不会出现重复计算度量的问题。
维度表一般都是单一主键，少数是联合主键，注意维度表不要出现重复数据，否则和事实表关联会出现 数据发散 问题。
有时候往往不能确定该列数据是事实属性还是维度属性。 记住最实用的事实就是数值类型和可加类事实 。所以可以通过分析该列是否是一种包含多个值并作为计算的参与者的度量，这种情况下该列往往是事实；如果该列是对具体值的描述，是一个文本或常量，某一约束和行标识的参与者，此时该属性往往是维度属性。但是还是要结合业务进行最终判断是维度还是事实。
数据轻度汇总层DM
数据轻度汇总层
此层命名为轻汇总层，就代表这一层已经开始对数据进行汇总，但是不是完全汇总，只是对相同粒度的数据进行关联汇总，不同粒度但是有关系的数据也可进行汇总，此时需要将粒度通过聚合等操作进行统一。
数据应用层APP
数据应用层
数据应用层的表就是提供给用户使用的，数仓建设到此就接近尾声了，接下来就根据不同的需求进行不同的取数，如直接进行报表展示，或提供给数据分析的同事所需的数据，或其他的业务支撑。
最后
技术是为业务服务的，业务是为公司创造价值的，离开业务的技术是无意义的。所以数仓的建设与业务是息息相关的，公司的业务不同，数仓的建设也是不同的，只有适合的才是最好的。
二、指标体系
指标体系是什么？如何使用OSM模型和AARRR模型搭建指标体系？如何统一流程、规范化、工具化管理指标体系？本文会对建设的方法论结合滴滴数据指标体系建设实践进行解答分析。
什么是指标体系
1. 指标体系定义
指标体系是将零散单点的具有相互联系的指标，系统化的组织起来，通过单点看全局，通过全局解决单点的问题。它主要由指标和体系两部分组成。
指标是指将业务单元细分后量化的度量值，它使得业务目标可描述、可度量、可拆解，它是业务和数据的结合，是统计的基础，也是量化效果的重要依据。
指标主要分为结果型和过程型：
结果型指标：用于衡量用户发生某个动作后所产生的结果，通常是延后知道的，很难进行干预。结果型指标更多的是监控数据异常，或者是监控某个场景下用户需求是否被满足
过程型指标：用户在做某个动作时候所产生的指标，可以通过某些运营策略来影响这个过程指标，从而影响最终的结果，过程型指标更加关注用户的需求为什么被满足或没被满足
体系是由不同的维度组成，而维度是指用户观察、思考与表述某事物的“思维角度”，维度是指标体系的核心，没有维度，单纯说指标是没有任何意义的。
维度主要分为定性维度和定量维度，定性维度，主要是偏文字描述类如城市、性别、职业等;定量维度，主要是数值类描述如收入、年龄等，对定量维度需要做数值分组处理。
2. 指标体系生命周期
生命周期主要包含定义、生产、消费、下线四个阶段。针对整个生命周期要持续做指标运维、质量保障，同时为了提高指标数据复用度，降低用户使用成本需要做对应的数据运营工作。
3. 综合使用场景
指标体系主要是结合用户的业务场景来进行使用，多个不同的指标和维度可以组合起来进行业务的综合分析，用户可通过指标的变化看到整体业务的变化，并能够快速发现问题、定位问题。常用的场景一种是决策分析的场景，通过数据看清业务现状进行战略决策支持；另一种是运营分析场景，无论是做用户运营、产品运营还是活动运营都需要各类指标数据的支撑去看清问题、分析问题和指导解决问题。
为什么搭建指标体系
1. 衡量业务发展质量
指标体系可以反映业务客观事实，看清业务发展现状，通过指标对业务质量进行衡量，把控业务发展情况，针对发现的业务问题聚焦解决，促进业务有序增长
2. 建立指标因果关系
主要明确结果型指标和过程型指标关系，通过结果指标回溯过程指标，找到解决问题的核心原因
3. 指导用户分析工作
目的建立产品评估体系、活动效果评估体系、智能运营分析体系
4. 指导基础数据建设
明确基础数据建设方向，集中资源，避免过程和结果分析指标数据的遗漏或缺失
5. 指导内容产品建设
结合用户的业务场景来进行使用，多个不同的指标和维度可以组合起来进行业务的综合分析，用户可通过指标的变化看到整体业务的变化，并能够快速发现问题、定位问题
6. 统一指标消费口径
企业内统一关键指标业务口径及计算口径，统一企业业务目标，实现自上而下目标驱动
如何搭建指标体系
指标体系建设的常用方法是通过场景化进行指标体系的搭建，以用户的视角场景化思考，自上而下业务驱动指标体系建设，所以要在特定场景下做好指标体系建设，需要先选好指标，然后用科学的方法搭建指标体系。
1. 科学方法选指标
选指标常用方法是指标分级方法和OSM模型。
指标分级主要是指标内容纵向的思考，根据企业战略目标、组织及业务过程进行自上而下的指标分级，对指标进行层层剖析，主要分为三级T1、T2、T3。
T1指标：公司战略层面指标
用于衡量公司整体目标达成情况的指标，主要是决策类指标，T1指标使用通常服务于公司战略决策层
T2指标：业务策略层面指标
为达成T1指标的目标，公司会对目标拆解到业务线或事业群，并有针对性做出一系列运营策略，T2指标通常反映的是策略结果属于支持性指标同时也是业务线或事业群的核心指标。T2指标是T1指标的纵向的路径拆解，便于T1指标的问题定位，T2指标使用通常服务业务线或事业群
T3指标：业务执行层面指标
T3指标是对T2指标的拆解，用于定位T2指标的问题。T3指标通常也是业务过程中最多的指标。根据各职能部门目标的不同，其关注的指标也各有差异。T3指标的使用通常可以指导一线运营或分析人员开展工作，内容偏过程性指标，可以快速引导一线人员做出相应的动作。
例如：成交率的指标分级
OSM模型（Obejective，Strategy，Measurement）是指标体系建设过程中辅助确定核心的重要方法，包含业务目标、业务策略、业务度量，是指标内容横向的思考。
O
用户使用产品的目标是什么？产品满足了用户的什么需求？主要从用户视角和业务视角确定目标，原则是切实可行、易理解、可干预、正向有益
S
为了达成上述目标我采取的策略是什么？
M
这些策略随之带来的数据指标变化有哪些？
以滴滴网约车为例，按照OSM模型，它的指标是什么样的？
O：用户来使用滴滴这个产品，需求和目标是什么？
用户需求及目标是便捷、快速打到车，安全到达目的地
那如何让用户感受到自己的需求被满足了呢？
S：滴滴做的策略是：
便捷方面，提供了独立APP版本、小程序版本，还可以多渠道打到车，例如在高德、微信、支付宝都有打车入口；起始、目的地地图智能精准定位；最优路线选择等
快速方面，针对不同人群不同诉求提供了多品类产品选择，例如快车、优享、拼车、出租车等业务，根据早晚高峰提高热点区域运力，减少用户排队时间
安全方面，司机准入机制，司机合规机制，司机画像
M：我们需要针对这些策略去做指标，在这里面我们的指标分别是结果指标和过程指标：
结果指标：渠道转化完成率、乘客取消率、供需比、司机服务分
过程指标：渠道发单数、渠道完单数、排队乘客数、乘客排队时长、司机好评率、司机接单量、司机取消数等
指标选取之后，下面就是最重要的分析维度选择了，前面指标体系定义里讲过维度是指标体系的核心，没有维度，单纯说指标是没有任何意义的。所以维度选择层面主要通过数据分析视角结合实际分析业务场景来确定。例如城市维度、商圈维度、渠道维度、时间维度、用户标签维度等。
2. 用分析模型搭建指标体系
在《精益数据分析》一书中给出了两套比较常用的指标体系建设方法论，其中一个就是比较有名的海盗指标法，也就是我们经常听到的AARRR海盗模型。海盗模型是用户分析的经典模型，它反映了增长是系统性地贯穿于用户生命周期各个阶段的：用户拉新(Acquisition)、用户激活(Activation)、用户留存(Retention)、商业变现(Revenue)、用户推荐(Referral)。
AARRR模型
A拉新
通过各种推广渠道，以各种方式获取目标用户，并对各种营销渠道的效果评估，不断优化投入策略，降低获客成本。涉及关键指标例如新增注册用户数、激活率、注册转化率、新客留存率、下载量、安装量等
A活跃
活跃用户指真正开始使用了产品提供的价值，我们需要掌握用户的行为数据，监控产品健康程度。这个模块主要反映用户进入产品的行为表现，是产品体验的核心所在。涉及关键指标例如DAU/MAU 、日均使用时长、启动APP时长、启动APP次数等
R留存
衡量用户粘性和质量的指标。涉及关键指标例如留存率、流失率等
R变现
主要用来衡量产品商业价值。涉及关键指标例如生命周期价值(LTV)、客单价、GMV等
R推荐
衡量用户自传播程度和口碑情况。涉及关键指标例如邀请率、裂变系数等
可以根据实际业务场景，结合使用OSM和AARRR模型，来系统性的选择不同阶段所需要的核心数据指标。
3. 场景化搭建指标体系
目前阶段互联网业务比较流行的一种通用抽象场景“人、货、场”，实际就是我们日常所说的用户、产品、场景，在通俗点讲就是谁在什么场景下使用了什么产品，不同的商业模式会有不同的组合模式。以滴滴实际场景为例：哪些场景（此处场景定义为终端，如Native，微信，支付宝）的什么人（乘客）在平台上使用了哪些货（平台业务线，如快车/专车等），进而为评估用户增长的价值和效果。
"人"的视角
从“人”的视角，我们比较关心的是什么乘客在什么时间打的车，排了多长时间，等了多长时间上车，周期内第几次打车，打车花了多少钱，是否有投诉和取消行为，具体到数据指标主要看发单用户数、完单用户数、客单价、周期内完单订单数、取消订单数、评价订单数等。
"货"的视角
从“货”的视角，我们比较关心的就是成交了多少，交易额多少，花了多少，到具体数据指标主要会看GMV、成交率、取消率指标，在进一步会细分到城市、区域，一级品类、二级品类。数据的效果通过目标对比，横向对比、历史比较等方式进行分析确定。
"场"的视角
从“场”的视角，我们比较关心的就是哪个渠道用户点击量大曝光率大，带来了多少新用户，完成多少交易订单，客单价是多少；或者是哪个活动拉新或促活效果怎么样转化率多少，结合场景数据实际情况制定对应策略。
以上分别从“人”、“货”、“场”三个角度进行了数据指标和分析维度的提炼，下面我们把三类指标结合指标分级方法进行分解关联。
怎么管理指标体系
1. 痛点分析
主要从业务、技术、产品三个视角来看：
业务视角
业务分析场景指标、维度不明确；
频繁的需求变更和反复迭代，数据报表臃肿，数据参差不齐；
用户分析具体业务问题找数据、核对确认数据成本较高。
技术视角
指标定义，指标命名混乱，指标不唯一，指标维护口径不一致；
指标生产，重复建设；数据汇算成本较高；
指标消费，数据出口不统一，重复输出，输出口径不一致；
产品视角
缺乏系统产品化支持从生产到消费数据流没有系统产品层面打通；
2. 管理目标
技术目标
统一指标和维度管理，指标命名、计算口径、统计来源唯一， 维度定义规范、维度值一致
业务目标
统一数据出口、场景化覆盖
产品目标
指标体系管理工具产品化落地；指标体系内容产品化落地支持决策、分析、运营例如决策北极星、智能运营分析产品等
3. 模型架构
业务板块定义原则：业务逻辑层面进行抽象、物理组织架构层面进行细分，可根据实际业务情况进行层级分拆细化，层级分级建议进行最多进行三级分拆，一级细分可公司层面统一规范确定，二级及后续拆分可根据业务线实际业务进行拆分。
例如滴滴出行领域业务逻辑层面两轮车和四轮车都属于出行领域可抽象出行业务板块(level一级)，根据物理组织架构层面在进行细分普惠、网约车、出租车、顺风车（level二级），后续根据实际业务需求可在细分,网约车可细分独乘、合乘，普惠可细分单车、企业级。
规范定义
数据域
指面向业务分析，将业务过程或者维度进行抽象的集合。其中，业务过程可以概括为一个个不拆分的行为事件，在业务过程之下，可以定义指标；维度，是度量的环境，如乘客呼单事件，呼单类型是维度。为了保障整个体系的生命力，数据域是需要抽象提炼，并且长期维护更新的，变动需执行变更流程。
业务过程
指公司的业务活动事件，如呼单、支付都是业务过程。其中，业务过程不可拆分。
时间周期
用来明确统计的时间范围或者时间点，如最近30天、自然周、截止当日等。
修饰类型
是对修饰词的一种抽象划分。修饰类型从属于某个业务域，如日志域的访问终端类型涵盖APP端、PC端等修饰词。
修饰词
指的是统计维度以外指标的业务场景限定抽象，修饰词属于一种修饰类型，如在日志域的访问终端类型下，有修饰词APP、PC端等。
度量/原子指标
原子指标和度量含义相同，基于某一业务事件行为下的度量，是业务定义中不可再拆分的指标，具有明确业务含义的名称，如支付金额。
维度
维度是度量的环境，用来反映业务的一类属性，这类属性的集合构成一个维度，也可以称为实体对象。维度属于一个数据域，如地理维度（其中包括国家、地区、省市等）、时间维度（其中包括年、季、月、周、日等级别内容）。
维度属性
维度属性隶属于一个维度，如地理维度里面的国家名称、国家ID、省份名称等都属于维度属性。
指标分类主要分为原子指标、派生指标、衍生指标
原子指标
基于某一业务事件行为下的度量，是业务定义中不可再拆分的指标，具有明确业务含义的名称，如呼单量、交易金额
派生指标
是1个原子指标+多个修饰词（可选）+时间周期，是原子指标业务统计范围的圈定。派生指标又分以下二种类型：
事务型指标
是指对业务过程进行衡量的指标。例如，呼单量、订单支付金额，这类指标需要维护原子指标以及修饰词，在此基础上创建派生指标。
存量型指标
是指对实体对象（如司机、乘客）某些状态的统计，例如注册司机总数、注册乘客总数，这类指标需要维护原子指标以及修饰词，在此基础上创建派生指标，对应的时间周期一般为“历史截止当前某个时间”。
衍生指标
是在事务性指标和存量型指标的基础上复合成的。主要有比率型、比例型、统计型均值。
模型设计
主要采用维度建模方法进行构建，基础业务明细事实表主要存储维度属性集合和度量/原子指标；分析业务汇总事实表按照指标类别(去重指标、非去重指标)分类存储，非去重指标汇总事实表存储统计维度集合、原子指标或派生指标，去重指标汇总事实表只存储分析实体统计标签集合。
指标体系在数仓物理实现层面主要是结合数仓模型分层架构进行指导建设，滴滴的指标数据主要存储在DWM层，作为指标的核心管理层。
指标体系元数据管理
维度管理
包括基础信息和技术信息，由不同角色进行维护管理。
基础信息对应维度的业务信息，由业务管理人员、数据产品或BI分析师维护，主要包括维度名称、业务定义、业务分类。
技术信息对应维度的数据信息，由数据研发维护，主要包括是否有维表（是枚举维度还是有独立的物理维表）、是否是日期维、对应code英文名称和中文名称、对应name英文名称和中文名称。如果维度有维度物理表，则需要和对应的维度物理表绑定，设置code和name对应的字段。如果维度是枚举维，则需要填写对应的code和name。维度的统一管理，有利于以后数据表的标准化，也便于用户的查询使用。
指标管理
包括基础信息、技术信息和衍生信息，由不同角色进行维护管理。
基础信息对应指标的业务信息，由业务管理人员、数据产品或BI分析师维护，主要包括归属信息(业务板块、数据域、业务过程)，基本信息(指标名称、指标英文名称、指标定义、统计算法说明、指标类型(去重、非去重))，业务场景信息(分析维度，场景描述)；
技术信息对应指标的物理模型信息，由数据研发进行维护，主要包括对应物理表及字段信息；
衍生信息对应关联派生或衍生指标信息、关联数据应用和业务场景信息，便于用户查询指标被哪些其它指标和数据应用使用，提供指标血缘分析追查数据来源的能力。
原子指标定义归属信息 + 基本信息 + 业务场景信息派生指标定义时间周期 + 修饰词集合 + 原子指标修饰类型主要包含类型说明、统计算法说明、数据源(可选)
指标体系建设流程
建模流程
建模流程主要是从业务视角指导工程师对需求场景涉及的指标进行主题抽象，归类，统一业务术语，减少沟通成本，同时避免后续的指标重复建设。
分析数据体系是模型架构中汇总事实表的物理集合，业务逻辑层面根据业务分析对象或场景进行指标体系抽象沉淀。滴滴出行主要是根据分析对象进行主题抽象的，例如司机主题、安全主题、体验主题、城市主题等。指标分类主要是根据实际业务过程进行抽象分类，例如司机交易类指标、司机注册类指标、司机增长类指标等。基础数据体系是模型架构中明细事实表和基础维度表的物理集合，业务逻辑层面根据实际业务场景进行抽象例如司机合规、乘客注册等，还原业务核心业务过程。
开发流程
开发流程是从技术视角指导工程师进行指标体系生产、运维及质量管控，也是数据产品或数据分析师和数仓研发沟通协调的桥梁。
指标体系图谱建设
指标体系图谱概述
指标体系图谱也可称为数据分析图谱主要是依据实际业务场景抽象业务分析实体，整合梳理实体涉及的业务分类、分析指标和维度的集合。
建设方法：主要是通过业务思维、用户视角去构建，把业务和数据紧密关联起来，把指标结构化分类组织
建设目的：
对于用户：
便于用户能够快速定位所需指标和维度，同时通过业务场景化沉淀指标体系，能够快速触达用户数据诉求
对于研发：
利于后续指标生产模型设计、数据内容边界化、数据体系建设迭代量化和数据资产的落地
指标体系产品化
指标体系涉及的产品集主要是依据其生命周期进行相应建设，通过产品工具打通数据流，实现指标体系统一化、自动化、规范化、流程化管理。因为指标体系建设本质目标是服务业务，实现数据驱动业务价值，所以建设的核心原则是“轻标准、重场景，从管控式到服务式”。通过工具、产品、技术和组织的融合提高用户使用数据效率，加速业务创新迭代。
其中和指标体系方法论强相关产品就是指标字典工具的落地，其产品的定位及价值：
支撑指标管理规范从方法到落地的工具，自动生成规范指标，解决指标名称混乱、指标不唯一的问题，消除数据的二义性
统一对外提供标准的指标口径和元数据信息
工具设计流程 (方法论->定义->生产->消费)
指标定义
指标生产
这部分整体介绍了指标体系建设方法论和工具产品的建设情况，目前指标字典和开发工具已实现流程打通，与数据消费产品的打通后续会通过DataAPI方式提供数据服务，规划建设中。
三、数据治理
1、数据治理 治的是“数据”吗？
数据是指对客观事件进行记录并可以鉴别的符号，是对客观事物的性质、状态以及相互关系等进行记载的物理符号或这些物理符号的组合。其实在我看来，数据可以分为两个部分，一是数字，二是文字。数字是没有意义的抽象符号，数据是有意义的数字。文字表意，数字表量，当两者结合起来，数据就产生了。
在我们的生活和工作当中，数据无处不在。对企业来讲，有很多数据是无关企业重大利益的数据，是没有治理的必要的。数据治理的对象必须是重要的数据资源，是关乎企业重大商业利益的数据资源，这样的数据资源可以称其为“数据资产”。正如北大教授王汉生先生所说：“数据治理不是对“数据”的治理，而是对“数据资产”的治理，是对数据资产所有相关方利益的协调与规范。”
我们需要分开来理解这句话：
①什么是数据资产？
②数据资产的相关利益方是谁？
③协调与规范什么？
先说一说什么是数据资产。 我们说不是所有数据都是数据资产，那到底什么才是数据资产呢？
《企业会计准则-基本准则》第20条规定：“资产是指企业过去的交易或者事项形成的、由企业拥有或者控制的、预期会给企业带来经济利益的资源。” 如果照猫画虎修改一下，不难获得一个关于数据资产的定义：“数据资产是指企业过去的交易或者事项形成的，由企业拥有或者控制的，预期会给企业带来经济利益的数据资源。”由此可见，数据要成为数据资产，至少要满足3个核心必要条件：
①数据资产应该是企业的交易或者事项形成的；
②企业拥有或者控制；
③预期会给企业带来经济利益。
数据资产的利益相关方是谁？
根据数据资产的定义，数据资产的利益相关方，包括：
①数据的生产者，即通过业务交易或事项产生数据的人或组织。
②数据的拥有或控制者，生产数据的人不一定是拥有数据，就像我们天天上网的各种数据都不归我们自己所有，而是落在了各个互联网公司的数据库中。
③数据价值和经济利益的收益者。数据治理就是对数据生产者、拥有或控制者，数据价值获益者的规范和协调。
都什么是需要协调和规范？
首先是数据的标准化 ，定义统一的数据标准，“写中国字、说普通话”让数据资产的相关利益方在同一个“频道”沟通。数据的标准化包含几个层面：①数据模型标准化。②核心数据实体的标准化（主数据的标准化）。③关键指标的标准化。
其次是数据的确权。 数据一旦成为资产，就一定有拥有方，或者实际控制人，可以把他们统称产权人。与实物不同的是，实物的产权是比较明确的，数据则比较复杂。产品在生产制造过程中，并没有与消费者交易之前，制造商拥有完全产权。产品生产出来后，消费者通过购买支付相应的货币，便拥有了产品的产权。而数据的生产过程就不一样了，我们的各种上网行为每天都会产生大量的数据，例如：网上购物、浏览网页、使用地图、评论/评价……。这些数据到底归谁所有？控制权该如何治理？这是摆在面前的一个难题！我们看到近几年一些不良商家，利用我们的上网数据，导致安全隐私泄密的事件也层出不穷。希望随着技术和商业的进步，尽快能够找到解决方案！
第三是流程的优化。 数据治理的两个目标：一个是提质量，一个是控安全。互联网数据的确权目前已经是一个世界级难题，做好企业业务流程的优化可能会对隐私保护起到一定的作用。通过业务流程优化，规范数据从产生、处理、使用到销毁的整个生命周期，使得数据在各阶段、各流程环节安全可控，合规使用。另外，通过一定的流程优化，通过对相关流程进行监管，按照数据的质量规则进行数据校验，符合“垃圾进、垃圾出”的数据采集、处理、存储原则，提升数据治理，赋能业务应用。
2、数据治理 到底在哪里治？
数据治理到底应该放在中台，还是后台，我个人的理解是： 小数据标准化治理靠人工、大数据预测性分析靠智能，将两者结合起来：“人工+智能”形成了完整的数据治理技术体系。 一个企业的数据治理既离不开小数据的标准化治理，也离不开大数据的预测性分析。
这里的小数据，是在承载事物实体的数据，例如：人、财、物等，是企业所有业务开展的载体。其实说白了就是主数据管理。对于主数据的治理笔者认为是一个后台行为，治理核心是“唯一数据源、统一数据标准”，而要达到这一目标是需要从数据的源头抓起的，并且需要大量的人为干预，比如：数据标准的制定和落实，数据质量的清洗，数据的申请审批，数据的分发和共享等。从这里也能够看出小数据的治理，追求的是标准化、精确化，应该是一个后台行为。
而在大数据时代，得益于大数据技术的突破，大量的结构化、非结构化、异构化的数据能够得到储存、处理、计算和分析，这一方面提升了我们从海量数据中获取知识和洞见的能力。对于大数据，传统的一味追求精确的思维受到了挑战。而对于大数据的治理，允许一定程度上的容错，反而可以在宏观层面拥有更好的知识和洞察力。对于大数据的治理更多的是采用AI技术，例如：知识图谱、语音识别等，对大数据的采集、处理、使用过程加以控制，使其能够合规使用。所以，大数据的治理放在中台似乎更为合适。
3、数据治理 到底应该怎么治？
1、找症状，明确目标
任何企业实施数据治理都不是为了治理数据而治理数据，其背后都是管理和业务目标的驱动。企业中普遍存在的数据质量问题有：数据不一致、数据重复、数据不准确、数据不完整、数据关系混乱、数据不及时等。
由于这些数据问题的存在对业务的开展和业务部门之间的沟通造成了较大的困扰，产生了很大的成本；各异构的系统中数据不一致，导致业务系统之间的应用集成无法开展；数据质量差无法支撑数据分析，分析结果与实际偏差较大。然而要实现数据驱动管理、数据驱动业务的目标，没有高质量的数据支撑是行不通的。
目标：企业实施数据治理的第一步，就是要明确数据治理的目标，理清数据治理的关键点。
技术工具：实地调研、高层访谈、组织架构图。
输入：企业数据战略规划，亟待解决的业务问题，经营发展需求，业务需求等；
输出：数据治理的初步沟通方案，项目任务书，工作计划表；
2、理数据，现状分析
针对企业数据治理所处的内外部环境，从组织、人员、流程、数据四个方面入手，进行数据治理现状的分析。
某企业数据治理痛点分析
组织方面：是否有专业的数据治理组织，是否明确岗位职责和分工。
人员方面：数据人才的资源配置情况，包括数据标准化人员、数据建模人员，数据分析人员，数据开发人员等，以及数据人才的占比情况。
流程方面：数据管理的现状，是否有归口管理部门，是否有数据管理的流程、流程各环节的数据控制情况等；
数据方面：梳理数据质量问题列表，例如：数据不一致问题，数据不完整，数据不准确、数据不真实、数据不及时、数据关系混乱，以及数据的隐私与安全问题等。
目标：分析企业数据管理和数据质量的现状，确定初步数据治理成熟度评估方案。
技术工具：实地访谈、调研表、数据质量问题评议表、关键数据识别方法论（例如：主数据特征识别法）；
输入：需求及现状调研表、访谈记录、数据样本、数据架构、数据管理制度和流程文件；
输出：数据问题列表、数据U/C矩阵、数据治理现状分析报告、数据治理评估方案；
3、数据治理成熟度评估
数据治理成熟度反映了组织进行数据治理所具备的条件和水平，包括元数据管理、数据质量管理、业务流程整合、主数据管理和信息生命周期管理。
CMMI DMM数据管理能力成熟度评估模型
数据治理成熟度评估是利用标准的成熟度评估工具结合行业最佳实践，针对企业的数据治理现状进行的客观评价和打分，找到企业数据治理的短板，以便制定切实可行的行动方案。数据治理成熟度结束后形成初步的行动方案，一般包括数据治理战略，数据治理指标，数据治理规则，数据治理权责。数据治理愿景和使命是数据治理的整体目标；数据治理指标定义了数据治理目标的衡量方法；数据治理规则和定义包括与数据相关的政策、标准、合规要求、业务规则和数据定义等；权利和职责规定了由谁来负责制订数据相关的决策、何时实施、如何实施，以及组织和个人在数据治理策略中该做什么。
目标：结合业界标准的数据治理成熟度模型，根据企业管理和业务需求进行数据治理成熟的评估，形成初步的数据治理策略和行动路线。
技术工具：数据治理评估模型，例如：DCMM，CMMI DMM，IBM数据治理成熟度评估模型等；
输入：第2步的输入以及数据治理评估模型、数据治理评估工具（评估指标、打分表等）；
输出：数据治理评估结果，数据治理策略，初步的行动方案；
4、数据质量问题根因分析
数据治理的目的是解决数据质量问题提升数据质量，从而为数据驱动的数字化企业提供源动力，而提到数据质量问题，做过BI、数仓的同学一定知道，这是一个技术和业务“经常打架”相互推诿的问题。
某企业数据问题根因分析鱼骨图
产生数据质量问题的原因有很多，有业务方面的、有管理方面的、也有技术方面的，按照80/20法则，80%的问题是由20%的原因造成起的。所以，如果能够解决这20%的问题，就能得到80%的改进。
目标：分析并找到数据质量问题产生的根本原因，制定行之有效的解决方案；
技术工具：头脑风暴、5W1H、SWOT、因果（鱼刺）图、帕拉图等；
输入：数据问题列表、数据U/C矩阵、数据治理现状分析报告、数据治理评估结果；
输出：数据质量评估结果、对业务的潜在影响和根本原因。
5、业务影响及实施优先级评估
通过数据治理成熟度评估，从组织、流程、制度、人员、技术等方面找到企业在数据治理的待提升的领域和环节，再通过数据质量根因分析找到数据质量问题发生的根本原因，进一步明确了数据治理的目标和内容。再接下来，就需要确定数据治理策略，定义数据治理的实施优先级。
某企业主数据治理实施优先级评估
不同的数据治理领域解决的是不同的问题，而数据治理的每个领域都有它的实施难点，对企业来说，需要从业务的影响程度，问题的紧急程度、实施的难易程度等多个维度进行分析和权衡，从而找到符合企业需求并满足企业发展的方案。
目标：确定数据治理核心领域和支撑体系的建设/实施优先级；
技术工具：四象限法则（分别从业务影响程度/实施难以程度，问题重要程度/问题紧急程度绘制优先级矩阵）、KANO模型
输入：数据治理成熟度能力评估结果、数据质量问题根因分析结果；
输出：数据治理实施优先级策略
6、制定数据治理行动路线和计划
路线图是使用特定技术方案帮助达到短期或者长期目标的计划，用于新产品、项目或技术领域的开发，是指应用简洁的图形、表格、文字等形式描述技术变化的步骤或技术相关环节之间的逻辑关系。路线图是一种目标计划，就是把未来计划要做的事列出来，直至达到某一个目标，就好像沿着地图路线一步一步找到终点一样，故称路线图。
某企业数据治理实施路线图
企业数据治理的实施路线图的制定是以企业数据战略——愿景和使命为纲领，以急用优先为原则，以分步实施为策略进行了整体设计和规划。实施路线图主要包含的内容：分几个阶段实施，每个阶段的目标、工作内容、时间节点要求、环境条件等。笔者观点：任何一个企业的数据治理都不是一蹴而就，一步到位的，需要循序渐进、持续优化！实施路线图就是基于此产生的，因此说数据治理实施路线图也是说服利益相关者支持的一个重要手段。
目标：确定数据治理的阶段以及每个阶段的目标；
技术工具：路线图法
输入：数据治理成熟度能力评估结果、业务影响及实施优先级评估结果；
输出：数据治理实施路线图或称阶段目标计划
7、制定数据治理详细实施方案
数据治理详细实施方案是用于指导主数据的各项实施工作，一般包括：数据治理核心领域、数据治理支撑体系、数据治理项目管理三个方面。
数据治理总体框架图
数据治理核心领域包括：数据架构、数据服务、元数据管理、数据质量管理、数据标准管理、主数据管理、数据安全管理、数据生命周期管理。
数据治理支撑体系包括：组织（组织架构、组织层次、岗位职责）、制度（管控模式、规章制度、考核机制）、流程（归口部门、管理流程、流程任务等）、技术（数据集成、数据清洗、数据开发、数据应用、数据运营、支撑平台、实施方案等）。
数据治理项目管理方案包括：项目组队、项目计划、质量保证计划、配置管理计划、培训和售后等。
关于数据治理的核心领域，详见笔者之前分享的数据治理框架解读系列文章。
关于数据治理的支撑体系，详见笔者之前分享的数据治理成功关键要素系列文章。
目标：基于数据质量根因分析、业务影响和实施优先级评估结果，制定详细实施方案；
输入：业务影响及实施优先级评估结果，行动路线和计划；
输出：数据治理详细实施方案。
8、数据治理实施过程控制
数据治理实施过程控制是对数据治理项目的范围控制、进度控制、质量控制和成本控制，通过对企业的各项资源的合理协调与利用，而达成的数据治理目标的各种措施。从项目管理的角度来讲也是项目管理的黄金三角：范围、时间、质量、成本。
任何项目的质量和进度是需要良好的项目管理来保证的，数据治理也一样。与传统的软件工程项目不同，数据治理项目有着范围边界模糊、影响范围广、短期难见效、实施周期长等特点：
①范围边界模糊，数据治理涉及到的关键领域如元数据管理、数据质量管理、数据标准管理、主数据管理等很多是存在交叉的，边界很难界定，例如：实施数据质量管理项目，会涉及元数据管理、数据标准管理等，同样一个元数据管理项目也会涉及数据标准和数据质量。
②影响范围广，数据治理的实施不是一个部门能够完成的，是需要从高级管理层、到各业务部门、信息部门通力协作，共同完成的；
③短期难见效，数据治理项目实施完成后，其数据治理的效果被每个业务点滴操作所“稀释”，并不像其他项目，例如BI，那样明显的体现出来，所以主导数据治理的部门会经常遭到质疑。
④实施周期长，在没有清晰的数据治理目标和范围约定的情况下，数据治理是一个“无底洞”。所以，在实施数据治理项目之前制定好实施路线图和详细的实施方案就显得格外重要（第6、7步）。
目标：通过对数据治理项目实施过程的进度控制、质量控制和成本控制以实现数据治理的目标；
技术工具：PP（项目计划）、PMC（项目控制）、IPM（集成项目管理）、RSKM（风险管理）——CMMI过程域；
输入：6-7步的输出：数据治理实施路线图，数据治理详细实施方案；
输出：各项项目控制措施，例如：项目计划、SOW、项目风险列表、项目报告、项目总结等；
9、监控评估数据治理实施效果
随着大数据技术的不断发展，应当从企业的全局数据治理环境的角度，明确数据治理关键技术运用及其标准规范，构建成效评估指标体系，进行治理效果评价；并运用数据治理能力成熟度模型再次评估，界定数据管理层次，从而使得跨系统、跨业务、跨部门的数据治理体系的建设与实施能够通过各方协作顺利进行，实现卓越数据治理，进而通过数据驱动业务、数据驱动管理和运营以实现企业的降本、增效、提质、创新。
某企业数据治理看板（数据已脱敏）
数据治理成效评估指标体系应根据企业及数据治理项目的实际情况制定，一般包括：时间性、数量性、完整性、准确性四个维度。
①时间性即数据的及时性。该维度主要通过源业务系统数据接入的上报及时性、接入及时性等方面进行核对。通过分析月指标、周指标、日指标的数据及时率，得出在规定时间和频度周期内接入系统的比例，以此反映数据接入及时性。
②数量性。该维度是从数据存量，数据增量，数据访问量，数据交换量、数据使用量等指标反映数据的使用情况，可以分为月度指标、周指标、日指标、时分指标等。
③准确性。这个维度主要由各类数据中逻辑的准确性、数据值的准确性、数据频段和字段之间的准确性以及数据的精度等内容组成。该准确率同样包括：月度、每周、每日等准确率指标。
④完整性。此维度主要以单元维度完整性、数据业务维度组合完整性、索引值完整性等不同方面进行核对，是验证数据质量完整性的主要组成部分，包括月度指标、周指标、日指标数据的完整性等内容。
目标：检验各项数据治理指标的落实情况，查漏补缺，夯实数据治理效果；
技术工具：数据治理效果的评价指标体系、各种数据图表工具；
输入：数据治理效果评估指标；
输出：数据治理评估的月报、周报、日报等；
10、数据治理持续改进
数据治理模式应业务化、常态化，不应是一个项目、“一阵风”的模式。
数据治理工作应向企业生产、销售业务一样作为一项重点的业务工作来开展，构建专业的数据治理组织，设置合适的岗位权责，建立相应的管理流程和制度，让数据标准贯彻到每个业务环节，形成一种常态的工作。
在笔者看来，在数据源头加强企业数据的治理，让常态化治理成为日常业务，才能从根本上彻底解决企业数据质量的各种问题，让数据真正转化为企业资产，以实现数据驱动流程优化、数据驱动业务创新、数据驱动管理决策的目标。
|
