数据仓库的基本概念
数据仓库概念
英文名称为Data Warehouse，可简写为DW或DWH。数据仓库的目的是构建面向分析的集成化数据环境，为企业提供决策支持（Decision Support）。它出于分析性报告和决策支持目的而创建。
数据仓库本身并不“生产”任何数据，同时自身也不需要“消费”任何的数据，数据来源于外部，并且开放给外部应用，这也是为什么叫“仓库”，而不叫“工厂”的原因。
基本特征:
数据仓库是面向主题的、集成的、非易失的和时变的数据集合，用以支持管理决策。
代码语言：javascript复制面向主题:
传统数据库中，最大的特点是面向应用进行数据的组织，各个业务系统可能是相互分离的。而数据仓库则是面向主题的。主题是一个抽象的概念，是较高层次上企业信息系统中的数据综合、归类并进行分析利用的抽象。在逻辑意义上，它是对应企业中某一宏观分析领域所涉及的分析对象。
集成性:
通过对分散、独立、异构的数据库数据进行抽取、清理、转换和汇总便得到了数据仓库的数据，这样保证了数据仓库内的数据关于整个企业的一致性。
数据仓库中的综合数据不能从原有的数据库系统直接得到。因此在数据进入数据仓库之前，必然要经过统一与综合，这一步是数据仓库建设中最关键、最复杂的一步，所要完成的工作有：
要统一源数据中所有矛盾之处，如字段的同名异义、异名同义、单位不统一、字长不一致，等等。
进行数据综合和计算。数据仓库中的数据综合工作可以在从原有数据库抽取数据时生成，但许多是在数据仓库内部生成的，即进入数据仓库以后进行综合生成的。
下图说明一个保险公司综合数据的简单处理过程，其中数据仓库中与“保险” 主题有关的数据来自于多个不同的操作型系统。这些系统内部数据的命名可能不同，数据格式也可能不同。把不同来源的数据存储到数据仓库之前，需要去除这些不一致。
非易失性（不可更新性）
数据仓库的数据反映的是一段相当长的时间内历史数据的内容，是不同时点的数据库快照的集合，以及基于这些快照进行统计、综合和重组的导出数据。
数据非易失性主要是针对应用而言。数据仓库的用户对数据的操作大多是数据查询或比较复杂的挖掘，一旦数据进入数据仓库以后，一般情况下被较长时间保留。数据仓库中一般有大量的查询操作，但修改和删除操作很少。因此，数据经加工和集成进入数据仓库后是极少更新的，通常只需要定期的加载和更新。
时变性
数据仓库包含各种粒度的历史数据。数据仓库中的数据可能与某个特定日期、星期、月份、季度或者年份有关。数据仓库的目的是通过分析企业过去一段时间业务的经营状况，挖掘其中隐藏的模式。虽然数据仓库的用户不能修改数据，但并不是说数据仓库的数据是永远不变的。分析的结果只能反映过去的情况，当业务变化后，挖掘出的模式会失去时效性。因此数据仓库的数据需要更新，以适应决策的需要。从这个角度讲，数据仓库建设是一个项目，更是一个过程。数据仓库的数据随时间的变化表现在以下几个方面：
（1） 数据仓库的数据时限一般要远远长于操作型数据的数据时限。
（2） 操作型系统存储的是当前数据，而数据仓库中的数据是历史数据。
（3） 数据仓库中的数据是按照时间顺序追加的，它们都带有时间属性。数据仓库与数据库的区别
数据库与数据仓库的区别实际讲的是 OLTP 与 OLAP 的区别。
操作型处理，叫联机事务处理 OLTP（On-Line Transaction Processing，），也可以称面向交易的处理系统，它是针对具体业务在数据库联机的日常操作，通常对少数记录进行查询、修改。用户较为关心操作的响应时间、数据的安全性、完整性和并发支持的用户数等问题。传统的数据库系统作为数据管理的主要手段，主要用于操作型处理，像Mysql，Oracle等关系型数据库一般属于OLTP。
分析型处理，叫联机分析处理 OLAP（On-Line Analytical Processing）一般针对某些主题的历史数据进行分析，支持管理决策。
首先要明白，数据仓库的出现，并不是要取代数据库。数据库是面向事务的设计，数据仓库是面向主题设计的。数据库一般存储业务数据，数据仓库存储的一般是历史数据。
数据库设计是尽量避免冗余，一般针对某一业务应用进行设计，比如一张简单的User表，记录用户名、密码等简单数据即可，符合业务应用，但是不符合分析。数据仓库在设计是有意引入冗余，依照分析需求，分析维度、分析指标进行设计。
数据库是为捕获数据而设计，数据仓库是为分析数据而设计。
代码语言：javascript复制以银行业务为例。数据库是事务系统的数据平台，客户在银行做的每笔交易都会写入数据库，被记录下来，这里，可以简单地理解为用数据库记账。数据仓库是分析系统的数据平台，它从事务系统获取数据，并做汇总、加工，为决策者提供决策的依据。比如，某银行某分行一个月发生多少交易，该分行当前存款余额是多少。如果存款又多，消费交易又多，那么该地区就有必要设立ATM了。
显然，银行的交易量是巨大的，通常以百万甚至千万次来计算。事务系统是实时的，这就要求时效性，客户存一笔钱需要几十秒是无法忍受的，这就要求数据库只能存储很短一段时间的数据。而分析系统是事后的，它要提供关注时间段内所有的有效数据。这些数据是海量的，汇总计算起来也要慢一些，但是，只要能够提供有效的分析数据就达到目的了。数据仓库，是在数据库已经大量存在的情况下，为了进一步挖掘数据资源、为了决策需要而产生的，它决不是所谓的“大型数据库”。
数据仓库分层架构
按照数据流入流出的过程，数据仓库架构可分为：源数据、数据仓库、数据应用
数据仓库
数据仓库的数据来源于不同的源数据，并提供多样的数据应用，数据自下而上流入数据仓库后向上层开放应用，而数据仓库只是中间集成化数据管理的一个平台。
源数据：此层数据无任何更改，直接沿用外围系统数据结构和数据，不对外开放；为临时存储层，是接口数据的临时存储区域，为后一步的数据处理做准备。
数据仓库：也称为细节层，DW层的数据应该是一致的、准确的、干净的数据，即对源系统数据进行了清洗（去除了杂质）后的数据。
数据应用：前端应用直接读取的数据源；根据报表、专题分析需求而计算生成的数据。
数据仓库从各数据源获取数据及在数据仓库内的数据转换和流动都可以认为是ETL（抽取Extra, 转化Transfer, 装载Load）的过程，ETL是数据仓库的流水线，也可以认为是数据仓库的血液，它维系着数据仓库中数据的新陈代谢，而数据仓库日常的管理和维护工作的大部分精力就是保持ETL的正常和稳定。
那么为什么要数据仓库进行分层呢?
代码语言：javascript复制用空间换时间，通过大量的预处理来提升应用系统的用户体验（效率），因此数据仓库会存在大量冗余的数据；不分层的话，如果源业务系统的业务规则发生变化将会影响整个数据清洗过程，工作量巨大。
通过数据分层管理可以简化数据清洗的过程，因为把原来一步的工作分到了多个步骤去完成，相当于把一个复杂的工作拆成了多个简单的工作，把一个大的黑盒变成了一个白盒，每一层的处理逻辑都相对简单和容易理解，这样我们比较容易保证每一个步骤的正确性，当数据发生错误的时候，往往我们只需要局部调整某个步骤即可。数据仓库元数据的管理
元数据（Meta Date），主要记录数据仓库中模型的定义、各层级间的映射关系、监控数据仓库的数据状态及ETL的任务运行状态。一般会通过元数据资料库（Metadata Repository）来统一地存储和管理元数据，其主要目的是使数据仓库的设计、部署、操作和管理能达成协同和一致。
元数据是数据仓库管理系统的重要组成部分，元数据管理是企业级数据仓库中的关键组件，贯穿数据仓库构建的整个过程，直接影响着数据仓库的构建、使用和维护。
代码语言：javascript复制构建数据仓库的主要步骤之一是ETL。这时元数据将发挥重要的作用，它定义了源数据系统到数据仓库的映射、数据转换的规则、数据仓库的逻辑结构、数据更新的规则、数据导入历史记录以及装载周期等相关内容。数据抽取和转换的专家以及数据仓库管理员正是通过元数据高效地构建数据仓库。
用户在使用数据仓库时，通过元数据访问数据，明确数据项的含义以及定制报表。
数据仓库的规模及其复杂性离不开正确的元数据管理，包括增加或移除外部数据源，改变数据清洗方法，控制出错的查询以及安排备份等。元数据可分为技术元数据和业务元数据。技术元数据为开发和管理数据仓库的IT 人员使用，它描述了与数据仓库开发、管理和维护相关的数据，包括数据源信息、数据转换描述、数据仓库模型、数据清洗与更新规则、数据映射和访问权限等。而业务元数据为管理层和业务分析人员服务，从业务角度描述数据，包括商务术语、数据仓库中有什么数据、数据的位置和数据的可用性等，帮助业务人员更好地理解数据仓库中哪些数据是可用的以及如何使用。
由上可见，元数据不仅定义了数据仓库中数据的模式、来源、抽取和转换规则等，而且是整个数据仓库系统运行的基础，元数据把数据仓库系统中各个松散的组件联系起来，组成了一个有机的整体。
数仓建模方法
数据仓库的建模方法有很多种，每一种建模方法代表了哲学上的一个观点，代表了一种归纳、概括世界的一种方法。常见的有范式建模法、维度建模法、实体建模法等，每种方法从本质上将是从不同的角度看待业务中的问题。
1. 范式建模法（Third Normal Form，3NF）
范式建模法其实是我们在构建数据模型常用的一个方法，该方法的主要由 Inmon 所提倡，主要解决关系型数据库的数据存储，利用的一种技术层面上的方法。目前，我们在关系型数据库中的建模方法，大部分采用的是三范式建模法。
范式 是符合某一种级别的关系模式的集合。构造数据库必须遵循一定的规则，而在关系型数据库中这种规则就是范式，这一过程也被称为规范化。目前关系数据库有六种范式：第一范式（1NF）、第二范式（2NF）、第三范式（3NF）、Boyce-Codd范式（BCNF）、第四范式（4NF）和第五范式（5NF）。
在数据仓库的模型设计中，一般采用第三范式。一个符合第三范式的关系必须具有以下三个条件 :
代码语言：javascript复制每个属性值唯一，不具有多义性 ;
每个非主属性必须完全依赖于整个主键，而非主键的一部分 ;
每个非主属性不能依赖于其他关系中的属性，因为这样的话，这种属性应该归到其他关系中去。
范式建模
代码语言：javascript复制根据 Inmon 的观点，数据仓库模型的建设方法和业务系统的企业数据模型类似。在业务系统中，企业数据模型决定了数据的来源，而企业数据模型也分为两个层次，即主题域模型和逻辑模型。同样，主题域模型可以看成是业务模型的概念模型，而逻辑模型则是域模型在关系型数据库上的实例化。2. 维度建模法（Dimensional Modeling）
维度模型是数据仓库领域另一位大师Ralph Kimall所倡导，他的《数据仓库工具箱》是数据仓库工程领域最流行的数仓建模经典。维度建模以分析决策的需求出发构建模型，构建的数据模型为分析需求服务，因此它重点解决用户如何更快速完成分析需求，同时还有较好的大规模复杂查询的响应性能。
维度建模
典型的代表是我们比较熟知的星形模型（Star-schema），以及在一些特殊场景下适用的雪花模型（Snow-schema）。
维度建模中比较重要的概念就是 事实表（Fact table）和维度表（Dimension table）。其最简单的描述就是，按照事实表、维度表来构建数据仓库、数据集市。
目前在互联网公司最常用的建模方法就是维度建模，稍后将重点讲解
3. 实体建模法（Entity Modeling）
实体建模法并不是数据仓库建模中常见的一个方法，它来源于哲学的一个流派。从哲学的意义上说，客观世界应该是可以细分的，客观世界应该可以分成由一个个实体，以及实体与实体之间的关系组成。那么我们在数据仓库的建模过程中完全可以引入这个抽象的方法，将整个业务也可以划分成一个个的实体，而每个实体之间的关系，以及针对这些关系的说明就是我们数据建模需要做的工作。
虽然实体法粗看起来好像有一些抽象，其实理解起来很容易。即我们可以将任何一个业务过程划分成 3 个部分，实体，事件，说明，如下图所示：
实体建模
代码语言：javascript复制上图表述的是一个抽象的含义，如果我们描述一个简单的事实：“小明开车去学校上学”。以这个业务事实为例，我们可以把“小明”，“学校”看成是一个实体，“上学”描述的是一个业务过程，我们在这里可以抽象为一个具体“事件”，而“开车去”则可以看成是事件“上学”的一个说明。维度建模
维度建模是专门应用于分析型数据库、数据仓库、数据集市建模的方法。数据集市可以理解为是一种"小型数据仓库"。
1. 维度建模中表的类型
事实表
事实表表示对分析主题的度量。比如一次购买行为我们就可以理解为是一个事实。
事实与维度
图中的订单表就是一个事实表，你可以理解他就是在现实中发生的一次操作型事件，我们每完成一个订单，就会在订单中增加一条记录。事实表的特征：表里没有存放实际的内容，他是一堆主键的集合，这些ID分别能对应到维度表中的一条记录。事实表包含了与各维度表相关联的外键，可与维度表关联。事实表的度量通常是数值类型，且记录数会不断增加，表数据规模迅速增长。
明细表（宽表）：
代码语言：javascript复制事实表的数据中，有些属性共同组成了一个字段（糅合在一起），比如年月日时分秒构成了时间,当需要根据某一属性进行分组统计的时候，需要截取拼接之类的操作，效率极低。如：
为了分析方便，可以事实表中的一个字段切割提取多个属性出来构成新的字段，因为字段变多了，所以称为宽表，原来的成为窄表。
将上述的local_time字段扩展为如下6个字段：
又因为宽表的信息更加清晰明细，所以也可以称之为明细表。
2．维度表
每个维度表都包含单一的主键列。维度表的主键可以作为与之关联的任何事实表的外键，当然，维度表行的描述环境应与事实表行完全对应。维度表通常比较宽，是扁平型非规范表，包含大量的低粒度的文本属性。
维度表示你要对数据进行分析时所用的一个量，比如你要分析产品销售情况， 你可以选择按类别来进行分析，或按区域来分析。每个类别就构成一个维度。上图中的用户表、商家表、时间表这些都属于维度表，这些表都有一个唯一的主键，然后在表中存放了详细的数据信息。
总的说来，在数据仓库中不需要严格遵守规范化设计原则。因为数据仓库的主导功能就是面向分析，以查询为主，不涉及数据更新操作。事实表的设计是以能够正确记录历史信息为准则，维度表的设计是以能够以合适的角度来聚合主题内容为准则。
2. 维度建模三种模式
星型模式
雪花模式
3．星座模式
代码语言：javascript复制星座模式是星型模式延伸而来，星型模式是基于一张事实表的，而星座模式是基于多张事实表的，而且共享维度信息。前面介绍的两种维度建模方法都是多维表对应单事实表，但在很多时候维度空间内的事实表不止一个，而一个维表也可能被多个事实表用到。在业务发展后期，绝大部分维度建模都采用的是星座模式。
3. 维度建模过程
我们知道维度建模的表类型有事实表，维度表；模式有星形模型，雪花模型，星座模型这些概念了，但是实际业务中，给了我们一堆数据，我们怎么拿这些数据进行数仓建设呢，数仓工具箱作者根据自身60多年的实际业务经验，给我们总结了如下四步，请务必记住！
数仓工具箱中的维度建模四步走：
维度建模四步走
请牢记以上四步，不管什么业务，就按照这个步骤来，顺序不要搞乱，因为这四步是环环相扣，步步相连。下面详细拆解下每个步骤怎么做
1、选择业务过程
代码语言：javascript复制维度建模是紧贴业务的，所以必须以业务为根基进行建模，那么选择业务过程，顾名思义就是在整个业务流程中选取我们需要建模的业务，根据运营提供的需求及日后的易扩展性等进行选择业务。比如商城，整个商城流程分为商家端，用户端，平台端，运营需求是总订单量，订单人数，及用户的购买情况等，我们选择业务过程就选择用户端的数据，商家及平台端暂不考虑。业务选择非常重要，因为后面所有的步骤都是基于此业务数据展开的。2、声明粒度
代码语言：javascript复制先举个例子：对于用户来说，一个用户有一个身份证号，一个户籍地址，多个手机号，多张银行卡，那么与用户粒度相同的粒度属性有身份证粒度，户籍地址粒度，比用户粒度更细的粒度有手机号粒度，银行卡粒度，存在一对一的关系就是相同粒度。为什么要提相同粒度呢，因为维度建模中要求我们，在同一事实表中，必须具有相同的粒度，同一事实表中不要混用多种不同的粒度，不同的粒度数据建立不同的事实表。并且从给定的业务过程获取数据时，强烈建议从关注原子粒度开始设计，也就是从最细粒度开始，因为原子粒度能够承受无法预期的用户查询。但是上卷汇总粒度对查询性能的提升很重要的，所以对于有明确需求的数据，我们建立针对需求的上卷汇总粒度，对需求不明朗的数据我们建立原子粒度。3、确认维度
代码语言：javascript复制维度表是作为业务分析的入口和描述性标识，所以也被称为数据仓库的“灵魂”。在一堆的数据中怎么确认哪些是维度属性呢，如果该列是对具体值的描述，是一个文本或常量，某一约束和行标识的参与者，此时该属性往往是维度属性，数仓工具箱中告诉我们牢牢掌握事实表的粒度，就能将所有可能存在的维度区分开，并且要确保维度表中不能出现重复数据，应使维度主键唯一4、确认事实
代码语言：javascript复制事实表是用来度量的，基本上都以数量值表示，事实表中的每行对应一个度量，每行中的数据是一个特定级别的细节数据，称为粒度。维度建模的核心原则之一是同一事实表中的所有度量必须具有相同的粒度。这样能确保不会出现重复计算度量的问题。有时候往往不能确定该列数据是事实属性还是维度属性。记住最实用的事实就是数值类型和可加类事实。所以可以通过分析该列是否是一种包含多个值并作为计算的参与者的度量，这种情况下该列往往是事实。实际业务中数仓分层
数仓分层要结合公司业务进行，并且需要清晰明确各层职责，要保证数据层的稳定又要屏蔽对下游影响，一般采用如下分层结构：
数据分层架构
数据层具体实现
代码语言：javascript复制使用四张图说明每层的具体实现数据源层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
这些策略随之带来的数据指标变化有哪些？
代码语言：javascript复制以滴滴网约车为例，按照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方式提供数据服务，规划建设中。
数据治理
一、数据治理 治的是“数据”吗？
数据是指对客观事件进行记录并可以鉴别的符号，是对客观事物的性质、状态以及相互关系等进行记载的物理符号或这些物理符号的组合。其实在我看来，数据可以分为两个部分，一是数字，二是文字。数字是没有意义的抽象符号，数据是有意义的数字。文字表意，数字表量，当两者结合起来，数据就产生了。
在我们的生活和工作当中，数据无处不在。对企业来讲，有很多数据是无关企业重大利益的数据，是没有治理的必要的。数据治理的对象必须是重要的数据资源，是关乎企业重大商业利益的数据资源，这样的数据资源可以称其为“数据资产”。正如北大教授王汉生先生所说：“数据治理不是对“数据”的治理，而是对“数据资产”的治理，是对数据资产所有相关方利益的协调与规范。”
我们需要分开来理解这句话：
①什么是数据资产？
②数据资产的相关利益方是谁？
③协调与规范什么？
先说一说什么是数据资产。我们说不是所有数据都是数据资产，那到底什么才是数据资产呢？
《企业会计准则-基本准则》第20条规定：“资产是指企业过去的交易或者事项形成的、由企业拥有或者控制的、预期会给企业带来经济利益的资源。” 如果照猫画虎修改一下，不难获得一个关于数据资产的定义：“数据资产是指企业过去的交易或者事项形成的，由企业拥有或者控制的，预期会给企业带来经济利益的数据资源。”由此可见，数据要成为数据资产，至少要满足3个核心必要条件：
①数据资产应该是企业的交易或者事项形成的；
②企业拥有或者控制；
③预期会给企业带来经济利益。
数据资产的利益相关方是谁？
根据数据资产的定义，数据资产的利益相关方，包括：
①数据的生产者，即通过业务交易或事项产生数据的人或组织。
②数据的拥有或控制者，生产数据的人不一定是拥有数据，就像我们天天上网的各种数据都不归我们自己所有，而是落在了各个互联网公司的数据库中。
③数据价值和经济利益的收益者。数据治理就是对数据生产者、拥有或控制者，数据价值获益者的规范和协调。
都什么是需要协调和规范？
首先是数据的标准化，定义统一的数据标准，“写中国字、说普通话”让数据资产的相关利益方在同一个“频道”沟通。数据的标准化包含几个层面：①数据模型标准化。②核心数据实体的标准化（主数据的标准化）。③关键指标的标准化。
其次是数据的确权。数据一旦成为资产，就一定有拥有方，或者实际控制人，可以把他们统称产权人。与实物不同的是，实物的产权是比较明确的，数据则比较复杂。产品在生产制造过程中，并没有与消费者交易之前，制造商拥有完全产权。产品生产出来后，消费者通过购买支付相应的货币，便拥有了产品的产权。而数据的生产过程就不一样了，我们的各种上网行为每天都会产生大量的数据，例如：网上购物、浏览网页、使用地图、评论/评价……。这些数据到底归谁所有？控制权该如何治理？这是摆在面前的一个难题！我们看到近几年一些不良商家，利用我们的上网数据，导致安全隐私泄密的事件也层出不穷。希望随着技术和商业的进步，尽快能够找到解决方案！
第三是流程的优化。数据治理的两个目标：一个是提质量，一个是控安全。互联网数据的确权目前已经是一个世界级难题，做好企业业务流程的优化可能会对隐私保护起到一定的作用。通过业务流程优化，规范数据从产生、处理、使用到销毁的整个生命周期，使得数据在各阶段、各流程环节安全可控，合规使用。另外，通过一定的流程优化，通过对相关流程进行监管，按照数据的质量规则进行数据校验，符合“垃圾进、垃圾出”的数据采集、处理、存储原则，提升数据治理，赋能业务应用。
二、数据治理 到底在哪里治？
数据治理到底应该放在中台，还是后台，我个人的理解是：小数据标准化治理靠人工、大数据预测性分析靠智能，将两者结合起来：“人工 智能”形成了完整的数据治理技术体系。一个企业的数据治理既离不开小数据的标准化治理，也离不开大数据的预测性分析。
这里的小数据，是在承载事物实体的数据，例如：人、财、物等，是企业所有业务开展的载体。其实说白了就是主数据管理。对于主数据的治理笔者认为是一个后台行为，治理核心是“唯一数据源、统一数据标准”，而要达到这一目标是需要从数据的源头抓起的，并且需要大量的人为干预，比如：数据标准的制定和落实，数据质量的清洗，数据的申请审批，数据的分发和共享等。从这里也能够看出小数据的治理，追求的是标准化、精确化，应该是一个后台行为。
而在大数据时代，得益于大数据技术的突破，大量的结构化、非结构化、异构化的数据能够得到储存、处理、计算和分析，这一方面提升了我们从海量数据中获取知识和洞见的能力。对于大数据，传统的一味追求精确的思维受到了挑战。而对于大数据的治理，允许一定程度上的容错，反而可以在宏观层面拥有更好的知识和洞察力。对于大数据的治理更多的是采用AI技术，例如：知识图谱、语音识别等，对大数据的采集、处理、使用过程加以控制，使其能够合规使用。所以，大数据的治理放在中台似乎更为合适。
三、数据治理 到底应该怎么治？
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、数据治理持续改进
数据治理模式应业务化、常态化，不应是一个项目、“一阵风”的模式。
数据治理工作应向企业生产、销售业务一样作为一项重点的业务工作来开展，构建专业的数据治理组织，设置合适的岗位权责，建立相应的管理流程和制度，让数据标准贯彻到每个业务环节，形成一种常态的工作。在笔者看来，在数据源头加强企业数据的治理，让常态化治理成为日常业务，才能从根本上彻底解决企业数据质量的各种问题，让数据真正转化为企业资产，以实现数据驱动流程优化、数据驱动业务创新、数据驱动管理决策的目标。
目标：数据治理常态化，持续提升数据质量，驱动流程优化和管理创新。
输入：持续的、规范的、标准的各项业务操作；数据治理监控的各项指标和报告；
输出：持续输出的高质量的数据。
四、美团配送数据治理实战
从大的阶段来看，数据治理主要分为存量数据“由乱到治”的阶段，以及增量数据严格按照规章制度实施确保“行不逾矩”的运营阶段。在“由乱到治”的过程中，我们需要沉淀出规章制度、标准规范，以及辅以规章制度标准规范实施的工具和组织。在增量数据的运营阶段，我们主要靠对应的组织确保规章制度的落实，通过审计定期考察实施效果，并在长期的运营中不断完善规章制度。在实现存量数据“由乱到治”的阶段，我们主要采取了“两步走”策略，具体执行策略如下所示。
4.1 定标准，提质量
4.1.1 业务标准
业务标准主要是指标的管理和运营标准，我们主要解决三个问题：指标由谁来定义，指标该如何定义，指标该如何运营。基于这三个问题，我们同时提出了三条原则：
- 业务团队负责指标的定义。
- 产研商分负责给出指标定义标准和辅助工具，辅助业务团队完成指标的规范定义，达成指标认知一致性这一目标。
- 最后由指标管理委员会负责指标的管理与运营，保障指标从创建、审核、上线以及到最后消亡的整个生命周期的运营。
为统一指标的定义，我们将指标分为原子指标、衍生指标和派生指标，原子指标通过限定条件和时间的限定生成衍生指标。衍生指标间的“四则混合运算”构成了派生指标。我们不但制定了指标的标准定义，还对其做了准确的资产归属，一个指标出自一个具体的业务过程，一个业务过程归属于不同的数据域，多个数据域构成了美团配送业务线下的分析场景，如下图所示：
指标定义标准
4.1.2 技术标准
这里所说的技术标准，主要是针对数据RD提出的建模标准和数据生产规范，通过建模标准来明确数仓分层架构，并清晰定义每一层的边界与职责，采用维度建模的设计理念。我们的整个仓库架构分为四层：操作层、基础事实层、中间层和应用层，并在每一层同步制定对应的建模规范，如下图所示：
数仓架构以及建模标准
除了建模标准外，我们还制定了涵盖从生产到运维环节的生产规范以保障模型的质量，主要包括上线前的模型评审、生产过程中的完成元数据配置、DQC、SLA和生命周期设置以及上线后的日常运维机制等等。尤其针对元数据管理和生命周期管理，我们分别制定了仓库每一层元数据维护规范和生命周期管理规范，其中元数据管理规范，是依据数仓各层级中各种类型表的建模标准来制定，需要做到规范命名，明确数据归属，并打通业务元数据和技术元数据之间的关系。而生命周期管理规范，是依据配送业务特点和数仓各层级现状来制定的，如下表所示：
仓库各层元数据管理标准
仓库各层生命周期管理策略
4.1.3 安全标准
围绕数据安全标准，首先要有数据的分级、分类标准，确保数据在上线前有着准确的密级。第二，针对数据使用方，要有明确的角色授权标准，通过分级分类和角色授权，来保障重要数据拿不走。第三，针对敏感数据，要有隐私管理标准，保障敏感数据的安全存储，即使未授权用户绕过权限管理拿到敏感数据，也要确保其看不懂。第四，通过制定审计标准，为后续的审计提供审计依据，确保数据走不脱。
安全标准建设
4.1.4 资源管理标准
在资源管理方面，配送技术工程部已经对资源管理涉及的内容进行了合理抽象和准确定义，抽象出租户、资源和项目组等概念。不管是后续的资源预算还是资源管理，我们都需要基于租户和项目组来进行运营，因此，对于业务团队而言，我们只需要将租户和项目组特定职能划分清楚，然后根据不同的职能归属我们的资产，并分配生产该资产所需要的资源。为了方便后续的运营，我们对每个租户和项目组分配确定了责任人，由责任人对运营结果负责。
对业务部门来说，资源管理的关键是对数据资产做清晰的分类，基于数据的分类划分不同的租户和项目组，将数据和租户、项目组实现一一映射。由于租户和项目组都有特定的责任人对其负责，因此，我们通过这种映射关系，不仅实现了资产的隔离，还实现了资产确权（项目组负责人同时对资产负责和运营）。我们整体将数据分为两大类，一是原始数据，包括流到数据中心的数据和日志中心的数据，针对流入数据中心的数据，根据其产生的方式不同，又进一步分为业务数据和流量数据。二是加工数据，对应着数据团队的仓库建设和其他团队的集市建设。基于上述的描述，针对资源管理，我们做了如下划分和确权：
资源划分与管理
4.2 重实施，保落实
第二步，落实第一步的标准，完成数据治理第一阶段的目标，实现存量数据“由乱到治”，并完成相应组织和工具的建设，为实现第二阶段“行不逾矩”这一目标提供工具和组织能力。在此过程中，主要分成三个方面的治理工作：第一，架构模型“由乱到治”的治理，消除模型冗余、跨层引用和链路过长等问题，在架构上保证模型的稳定性和数据一致性；第二，元数据“由乱到治”的治理，实现指标的标准定义、技术元数据的完整采集并建立指标与表、字段的映射关系，彻底解决指标认知一致性，以及用户在使用数据过程中的“找数难”等问题；第三，围绕着隐私安全和共享安全加强数据的安全管控来实现数据走不脱、拿不走，以及隐私数据看不懂这一目标。
4.2.1 架构治理
总结起来，架构方面的治理主要是解决两个问题：第一，模型的灵活性，避免需求变更和业务迭代对核心模型带来的冲击，让RD深陷无休止的需求迭代中；第二，数据一致性，消除因模型冗余、跨层引用等问题带来的数据一致性问题。
模型灵活性
配送解决的是效率、成本和体验三者之间的平衡问题，即在满足一定用户体验的条件下，如何提升骑手配送效率，服务更多的商家，以及如何管控骑手，降低配送成本。抽象到数据层面，基本上反映为上游包裹来源的变化、配送对外提供服务的变化以及对内业务管控的变化。为屏蔽业务迭代给核心模型带来的冲击，我们通过对外封装包裹属性和对内封装运单属性，抽象出包裹来源、提供服务、业务架构等一致性维度，任何业务迭代在数据层面只涉及维度的调整，大大降低了对核心模型冲击和“烟囱式”数据建设问题（新来一个业务，就拉起一个分支进行建设）。
包裹事实分配到运单明细构造单一运单模型
配送指标体系建设的一个重点就是要输出各组织层级的规模、体验和效率指标，实现对运力的有效管控，运力所属组织的层级关系会随业务的迭代而不断变化。为了适应这种变化，避免仅仅因增加维度带来中间层数据的重复建设，我们将组织层级维表由固定层级建模方式调整为桥接表的方式来自适配组织层级变化，从而实现了中间层模型可以自动适配组织层级的变化，能自动产生新维度的指标。如下图所示：
桥接表自适配组织层级灵活变动
在精细化分析的场景下，业务会有分时段、分距离段以及分价格段的数据分析诉求。我们以分时段为例，有晚高峰、午高峰、下午茶等不同的分时段，不同的业务方对同一个时段的定义口径不同，即不同的业务方会有不同的分时段策略。为解决该场景下的分析诉求，我们在事实表中消除退化维度，将原来封装到事实表的时段逻辑迁移到维度表中，并将事实表中的时间进行按特定的间隔进行刻度化作为维表中的主键，将该主键作为事实表的外键。这样，针对业务不同的时间策略需要，我们就可以在维表中进行配置，避免了重复调整事实表和反复刷数的问题。即通过将时间、价格、距离事实刻度化，实现灵活维度分析。如下图所示：
通过将时间刻度化，实现灵活分析
数据一致性
数据一致性得不到保障的一个根本原因，是在建模的过程中没有实现业务口径标签化，并将业务口径下沉到主题层。很多同学在基于需求进行开发时，为实现方便，将新指标口径通过“Case When”的方式在应用层和中间层进行封装开发，主题层建设不能随着业务的迭代不断完善，RD在开发过程中会直接引用仓库的快照表在中间层或应用层完成需求开发。久而久之，就会造成数据复用性低下，相同指标的口径封装在不同的应用表来满足不同报表的需求，但随着应用的增多，很难保障相同指标在不用应用表封装逻辑的一致性，数据一致性难以得到保障，同时这种方式还带来两个严重后果：第一，跨层引用增多，数据复用性低下，造成计算和存储成本的浪费；第二，一旦指标口径发生变化，将是一个“灾难”，不仅影响评估是一个问题，而且涉及该指标的应用层逻辑调整对RD来说也是一个巨大的挑战。
治理前模型架构
因此，我们在“由乱到治”的治理过程中，以衍生事实的方式实现业务口径标签化，将业务逻辑下沉到主题层，消除跨层引用和模型冗余等问题，从技术层面保障数据一致性是该阶段架构治理的重点。我们在业务上，已经划分了严格的数据域和业务过程，在主题建设层面，将业务划分的数据域作为我们的主题，并基于业务过程进行维度建模，将属于该业务过程的指标口径封装在对应业务过程下的衍生事实中。
治理后模型架构
4.2.2 元数据治理
元数据治理主要解决三个问题：首先，通过建立相应的组织、流程和工具，推动业务标准的落地实施，实现指标的规范定义，消除指标认知的歧义；其次，基于业务现状和未来的演进方式，对业务模型进行抽象，制定清晰的主题、业务过程和分析方向，构建完备的技术元数据，对物理模型进行准确完善的描述，并打通技术元数据与业务元数据的关系，对物理模型进行完备的刻画；第三，通过元数据建设，为使用数据提效，解决“找数、理解数、评估”难题以及“取数、数据可视化”等难题。
首先，为保障业务标准的顺利实施，实现业务对指标认知一致性这一目标。我们协同产研、商分、业务部门推动成立了度量衡委员会，并建立起指标运营机制，通过组织保障来实现指标运营按照规范的标准和流程实施。如下图所示：
指标注册流程
其次，基于配送业务的现状和未来演进方式，我们进行了高度的业务抽象，完成了主题、业务过程和分析方向等元数据内容的建设。配送即物流，通过线上系统和线下运营，我们将用户的配送需求和美团的运力进行有效的资源配置，实现高服务体验、低成本的配送服务。对外，我们将配送服务通过平台化的方式，提供给用户、商户和电商平台，以满足不同用户在不同业务场景下的配送需求。对内，我们通过不同的调度模式将运单池中的运单调度给合适的骑手来完成履约，平衡规模、成本和体验之间的关系。如下图所示：
配送业务模式抽象
基于以上的业务模式，我们划分了运单主题（对履约数据域下的数据进行构建，支撑规模和体验的数据分析需求）、调度主题（调度数据域下产生的数据，用于支撑调度策略的分析）、结算、评价、投诉、取消主题（用于支撑体验、成本数据分析需求）和管控主题（用于支撑运力奖惩、违规和招募分析需求）等各种主题，并在每个主题下划分对应的业务过程，在应用层制定分析方向的分析标签，通过对元数据内容的建设完成对业务的抽象，为物理模型的刻画准备了基础数据。
第三，元数据服务建设，我们打通了元数据从采集到构建再到应用的整条链路，为使用数据提效，解决“找数、理解数、评估”难题以及“取数、数据可视化”难题。在整个建设过程中，我们围绕着元数据采集、元模型构建、元数据服务以及最后的产品应用进行展开，整体架构如下图所示：
元数据建设架构图
元数据采集
元数据采集分为人工录入和自动抽取，通过人工录入的方式实现物理表的准确归属（包括该表属于仓库哪一层、对应的主题、业务过程、星型模型关系等）以及指标的采集，从而完成技术元数据和业务元数据的采集，通过自动抽取的方式完成生产元数据的采集和使用元数据的采集，主要包括：物理模型的依赖关系、存储占用、热度、等信息。
元模型构建
分为以物理表为核心的基础元模型构建，以及以血缘为中心的血缘元模型。基础元模型构建以物理表为中心，打通其与技术元数据（主题、业务过程、Schema）的关系，实现了物理表的清晰归属，打通其与生产元数据的关系，为其加上了物理表查询热度、资源消耗、查询密级等生产使用信息，打通其与指标、维度和应用的对应关系，为上层的取数应用建立了完备的元数据。血缘元模型以血缘为中心，不仅构建了从上游业务表到仓库离线表的物理血缘，而且打通了仓库离线表到下游对应报表的血缘，为后续的影响评估构建了完备的元数据基础。
元数据服务
统一元数据服务（OneService），主要提供两类元数据服务，提供查询表、指标、维度基本信息的基础元数据服务以及查询表级血缘、字段级血缘的血缘服务。
元数据应用
主要孵化出了三个产品，以“找数、理解数、影响评估”为应用场景的数据地图（Wherehows），以“取数、数据可视化”为应用场景的数据可视化（QuickSight），以及以管理审计为目的的管理审计报表。
4.2.3 安全治理
安全治理主要加强了敏感数据的安全治理和数据共享环节的安全治理。通过对隐私数据的安全治理，不仅要保证其在存储环节的不可见性，而且还要保证在其使用环节对用户进行双重鉴权，字段的密级鉴权和解密的密钥鉴权；通过对数据共享环节的安全治理，我们在数据分级分类的基础上，使数据的权限控制从表级权限控制扩展到行级权限控制。
敏感数据安全治理
敏感数据的安全治理，主要是解决敏感数据的存储安全和使用安全。离线场景下，敏感数据存储安全要解决两大挑战：
- 确保仓库侧处理方案既要屏蔽上游业务系统变动带来的影响，又要屏蔽自身策略对下游BI系统的影响。
- 要避免敏感数据在整个加工链路中的扩散。
因此，为解决仓库处理方案与上游业务系统和下游BI系统的解耦问题，我们在上游敏感数据落到ODS环节，确保落到ODS层的敏感数据必须是明文，为保障其安全，对ODS层的所有数据进行文件加密，但是在使用层面，对下游链路透明保障下游链路的正常生产，并限制ODS层数据权限的开放。
ODS层数据只用于安全生产，通过此方案既屏蔽了上游处理方案对仓库的影响，又解决了敏感数据的安全问题。当数据从离开仓库时，在传输环节对敏感数据进行可逆操作，将敏感数据以明文的形式推入BI库，实现与下游BI系统的解耦。为解决敏感数据在整个生产链路的扩散，我们在快照层对敏感数据进行脱敏处理，从快照层开始消除敏感数据，为保障敏感数据的可逆性，将ODS层的敏感数据抽取到安全库中并进行加密存储，实现安全独立管理。具体执行如下图所示：
针对敏感数据的使用安全，我们通过对敏感字段的权限控制和对解密密钥的权限控制，来实现敏感数据使用安全这一目标。针对单独抽取的敏感数据，我们除了针对敏感数据设置其相应的密级确保敏感数据的权限管控外，还基于"暗语"的加密方式为每个项目组分配一个相同的密钥，并且将该密钥存放到与Hadoop集群集成的KMS进行管理（确保支撑离线计算的高并发），确保解密时实现密钥的权限管控。
共享环节安全治理
针对共享环节的安全治理，我们主要是在数据生产环节完成数据的分级分类和数据确权，在数据的使用环节完成数据的表级权限控制和行级权限控制。确保数据在使用环节规范的审批流转，权限开放以后的安全审计，保证数据走不脱。
首先，我们在生产环节B3、B2、B1层数据按照主题或实体C层数据按照应用方向进行逻辑划分，并设定资源的密级和权限负责人。特别地为实现B3层数据在查询环节可按照业务线进行权限管控这一目标（即行级鉴权），针对B3层数据，我们标记该数据需要在查询环节进行行级权限管控，标记使用行级鉴权所需的字段和该字段对应的枚举值。
其次，在使用环节，我们按照资产密级和使用人角色完成数据的审批流转，实现数据的安全共享。
第三，针对B3层数据，审计是否设置了行级权限管控。在数据开放时是否存在越权使用的情况，以及针对即将离职员工加强数据的使用审计，保证数据走不脱。
在数据“由乱到治”的治理过程中，我们不仅实现了存量数据的“由乱到治”，并且在此过程中沉淀出了一系列的建模方法论、工具，并建立了相应的安全小组和指标运营组织。同时，我们为后续增量数据治理确保数据建设“行不逾矩”，提供了强有力的组织保障、稳定的辅助工具和严格的执行标准。在数据治理的第二阶段实现增量数据的“行不逾矩”的过程中，我们主要围绕大数据架构审计、大数据安全与隐私管理审计、大数据质量管理审计和大数据生命周期管理审计这四方面的工作展开，保障治理工作的持续进行，不断提高了组织的治理水平。
5. 工具简介
5.1 数据地图（Wherehows）
数据地图作为元数据应用的一个产品，聚焦于数据使用者的“找数”场景，实现检索数据和理解数据的“找数”诉求。我们通过对离线数据集和在线数据集的元数据刻画，满足了用户找数和理解数的诉求，通过血缘图谱，完成物理表到产品的血缘建设，消除用户人肉评估的痛苦。
离线数据场景
1. 关键字检索和向导查询共同解决了“找数据”的问题：大部分的检索数据场景下，数据使用者都可以通过关键字检索来得到匹配结果。剩下的一小部分场景，例如，对于新人入职后如何了解整个数仓和指标的体系（数仓分几层，每层解决什么问题，都孵化出什么模型；整个指标、维度体系都是怎么分类，有哪些指标和维度），这部分场景可以使用向导查询功能。向导查询相当于分类查询，将表和指标按照业务过程进行分类，用户可以按照分类逐步找到想要的表或指标。
2. 我们打通了业务元数据和技术元数据之间的关系，提高了“找数据”的能力：通过“Wherehows”查找到指标后，不仅不可查看指标的业务定义，还能查看指标的技术实现逻辑，指标在哪些维度或维度组合中已经实现，并且能够在哪张表里找到这些维度，或维度组合的指标数据。反之，也可以知道在某个维度下已经实现了哪些指标，对应的指标在哪些表里。这些功能能让用户更加方便地找到想要的数据。
3. 我们提供了较为完善的数据信息，帮助用户更好理解数据：对于表的信息，“Wherehows”除了提供表和字段的中英文名称、描述信息等基础信息外，为了帮助用户更好地理解表的建设思路，我们还提供了表的星型模型（可以关联的一致性维度及对应的维度表）、表的血缘关系等信息。
4. 我们通过评论问答功能，帮助用户可以快速得到问题反馈：如果用户看了信息后还是感到有问题，“Wherehows”提供评论问答的功能，用户通过这个功能可以进行提问，会有相应的负责人进行回复。对于重复问反复问的问题，用户通过查看其它人的提问和回复就能找到答案。并且负责人还会定期的将问答信息沉淀到对应的元数据里，不断地对元数据进行补充和完善。
业务数据场景
业务数据场景主要想解决的一个问题是，如何知道一个业务表（MySQL表）有没有同步到数仓。如果没有同步，能够找谁进行同步。因为已经打通“业务表 -> 数仓表 -> 产品”三者之间的血缘关系，我们能够轻松解决业务数据场景的问题。
生产评估场景
在日常数据生产工作中，我们经常需要对表进行影响评估、故障排查、链路分析等工作，这些工作如果靠纯人工去做，费时费力。但现在我们已经打通了“业务表/字段 -> 数仓表/字段 -> 产品”三者之间的血缘关系，就能够在10分钟内完成评估工作。对于不同的场景，血缘链路提供了两个便捷的功能：过滤和剪枝。例如，某个表逻辑需要修改，需要看影响哪些下游表或产品？应该要通知哪些RD和PM？这种情况下，血缘工具直观地显示影响了哪些负责人和产品，以及这个表的下游链路。
有些表的链路很长，整个血缘关系图很大，这样会导致用户定位信息或问题。所以血缘工具提供了剪枝的功能，对于没用的、不想看到的分支可以剪掉，从而让整个链路变得更加直观。
5.2 数据可视化（QuickSight）
聚焦于数据使用者“取数”场景，使用QuickSight，用户可以不再关心数据的来源，不再担心数据的一致性，不再依赖RD的排期开发。通过所选即所得的方式，满足了用户对业务核心指标的二次加工、报表和取数诉求。首先，我们通过指标池、数据集等概念对离线生产的指标进行逻辑隔离，针对不同用户开发不同的数据集以达到权限控制的目的，如下图所示：
用户、指标池与数据集间的关系
其次，我们为用户提供一系列的组件，帮助用户基于为其开放的数据集实现指标的二次加工和数据可视化功能，满足其在不同业务场景下的取数和可视化应用。如下图所示：
指标加工组件
6. 总结与展望
经过三个阶段的治理工作，我们在各个方面都取得了较好的效果：
- 在数据标准方面，我们制定了业务标准、技术标准、安全标准、资源管理标准，从而保障了数据生产、管理、使用合规。
- 在数据架构方面，我们通过桥接表、时间刻度化、业务口径下沉等手段提升模型灵活性，并保障数据一致性，消除跨层引用和模型冗余等问题。
- 在数据安全方面，我们加强了对敏感数据和数据共享环节的安全治理，保证数据拿不走、走不脱，隐私数据看不懂。
- 在元数据建设方面，我们打通了从采集到构建再到应用的整条链路，并为数据使用人员提供数据地图、数据可视化等元数据应用产品，帮助他们解决了“找数”、“取数”、“影响评估”等难题。
未来，我们还会继续通过组织、规范、流程等手段持续对数据安全、资源利用、数据质量等各方面进行治理，并在数据易用性上下功夫，持续降低用户的数据使用成本。
- 在数据架构方面，随着数据库技术的飞速进步，现在已经有很多数据库能够支持千万级乃至亿级数据的现算先用，我们也在尝试使用这些数据库帮助提升数据开发效率，改善数仓分层管理和应用支撑效率。
- 在数据产品方面，我们将持续完善数据地图、数据可视化等数据应用产品，帮助用户快速探查、高效分析，真正发挥数据的业务价值。
