数据治理领域中，也有一些概念、名词术语，常常让人感到头痛：“水果蛋糕”和“水果味蛋糕”傻傻分不清！

下面谈一谈我的一些理解。

01数据治理、数据管理、数据管控

数据治理、数据管理、数据管控这三个名词在一定程度上的确是有所重叠的，容易混为一谈，所以就造成了在实际使用中，经常将这三个词语“混着用”、“随机用”的现象。有关数据治理、数据管理区别的讨论有很多，有人认为数据治理是包含在数据管理中的，数据管理的范围要更广，例如：在DAMA-DMBOK中就明确提出数据管理包含数据治理；也有人认为数据治理要高于数据管理，是企业顶层上的策略。

笔者认为以上两个观点都没有错，如果要用一个模型来描述数据治理、数据管理、数据管控这三个名词，那应该是一个“金字塔”模型。

最顶层的应该是数据治理。与“治理”相关，我们还会经常看到、听到国家治理、公司治理的概念，从某种意义上讲，治理是一种自顶向下的策略或活动。如果我们将国家治理说成国家管理，把公司治理说成公司管控是不是有点怪怪的？

因此，数据治理应该是企业顶层设计、战略规划方面的内容，是数据管理活动的总纲和指导，指明数据管理过程中哪些决策要被制定，以及由“谁”来负责，更强调组织模式、职责分工和标准规范。

数据管理是为实现数据和信息资产价值的获取、控制、保护、交付以及提升，对政策、实践和项目所做的计划、执行和监督。这个是DAMA-DMBOK中关于数据管理的定义。笔者理解数据管理是实现数据治理提出的决策并给予反馈，强调管理流程和制度，涵盖不同的管理领域，诸如：元数据管理、主数据管理、数据标准管理、数据质量管理、数据安全管理、数据认责管理、数据服务管理等。

数据管控更多的是执行层面，是具体的如何落地执行所涉及的各种措施，例如：数据建模、数据抽取、数据处理、数据加工、数据分析等，数据管控是确保数据被管理和监控，从而让数据得到更好的利用。

因此，数据治理强调顶层的策略，管理是侧重于流程和机制，管控是具体的措施和手段，三者应该是相辅相成的。而如今我们听到的更多的“数据治理”这个词，似乎只要涉及数据管理的，都在说自己在搞数据治理。出现这个问题，主要是企业越来越意识到传统IT驱动或者说技术驱动的专项数据管理项目，在实施过程中很难推进、困难重重，并且很难解决业务和管理上的用数难的问题。而从战略、组织入手的数据治理顶层设计，更有利于推动数据管理目标的实现。

02元数据、数据元、数据源、源数据

元数据、数据元、数据源、源数据，这几意思毫不相干却都带着一个“yuan”词语，让多初学者抓狂。

先说数据元，数据元用一组属性描述定义、标识、表示和允许值的数据单元，由三部分组成：对象、特性、表示。它是组成实体数据的最小单元，或称原子数据、数据元素，例如，客户联系人方式中的联系人姓名就是就可以理解为一个数据元素，姓名为数据元的对象，“张三”为数据元的值。

元数据（MateData），官方定义是描述数据的数据，让数据更容易理解、查找、管理和使用。从分类上，元数据分为了业务元数据、技术元数据、管理元数据。业务元数据，例如：数据的定义、业务规则、质量规则等；技术元数据：数据表、字段长度，字段编码、字段类型等；管理元数据：数据的存储位置、管理人员、更新时间、更新频率等。

元数据是业界公认的数据管理中的基础，元数据管理提供的功能诸如数据地图、血缘分析、影响分析、全链路分析、热度分析等，让用户更容易的对数据进行检索、定位、管理、评估。用哲学的思维理解元数据的话，元数据其实解决的是：我是谁，我在哪里，我从哪里来，我要到哪里去的问题。

数据源（Data Source），顾名思义就是数据的来源，是提供某种所需要数据的器件或原始媒体。在数据源中存储了所有建立数据库连接的信息，通过提供正确的数据源名称，可以找到相应的数据库连接。

10年前我们讲数据源，更多的是说一种数据连接的技术，比如：JDBC、ODBC，或者是指数据库的类型，比如：结构化数据库、非结构化数据库。而大数据时代，数据呈多样化发展，数据来源的多样化是时代的一个特征。我们现在提到的数据源，除了上述的含义之外，还涉及到图数据源、时序数据源、键值数据源、内存数据源、文档数据源等。每一种数据源不同，其数据的存储、传输、处理和应用的模式、场景、技术和工具也不相同。

源数据（Source Data），注意：这个词与数据源（Data Source）只是词语换了一个顺序，但是它们代表的含义却是大相径庭了。数据源本质是讲存储或处理数据的媒介，而源数据本质是在讲“数据”本身，强调数据状态是“创建”之后的“原始状态”，也就是没有被加工处理的数据。在数据管理的过程中，源数据一般是指直接来自源文件（业务系统数据库、线下文件、IoT等）的数据，或者直接拷贝源文件的“副本数据”。

“问渠哪得清如许，为有源头活水来”！数据治理的核心还是要从数据源抓起，以确保源数据的标准、准确、完整、真实。这是笔者对于数据治理一直坚持和提倡的观点。

03主数据、基础数据、静态数据

关于主数据以及主数据治理所涉及的概念、方法、体系、技术在我的系列文章中已经讲了很多了，需要系统的看主数据相关文章的话，可以在【谈数据】公众号的历史文章中查找。为了方便与基础数据、静态数据比较，我还是对其概念的理解重新说下。

主数据是企业中需要在多个部门或系统之间共享的，核心的、高价值且相对静态的数据。主数据是企业信息系统建设和大数据分析的基础，被认为是企业数字化转型的基石和企业中的黄金数据。有关主数据的三大特性（即高价值性、高共享性、相对稳定性）和四个超越（即超越业务，超越部门、超越系统、超越技术）的详细解读，请参考《主数据的3个特点、4个超越和3个二八原则》。

基础数据，业界还没有一个标准的定义。但在很多信息化项目中，基础数据这个概念都会被提及和使用。同时，常常会有客户对基础数据和主数据概念混淆。我理解的基础数据是信息系统运行的基础，用来支撑信息系统运行的各种数据和参数，以及业务交易所依赖的基础信息。而主数据是被多个系统共享的基础数据。因此，我理解的主数据可以是基础数据的一部分，但基础数据绝对不等于主数据。

静态数据也是一个使用比较广泛的词语并且是经常与基础数据“随机”来用的。静态数据是指在运行过程中主要作为控制或参考用的数据,它们在很长的一段时间内不会变化，一般不随运行而变。例如：客户的名称、员工的姓名、系统的参数。动态数据是常常变化，直接反映事务过程的数据，比如，网站访问量、在线人数、日销售额等等。因此，笔者认为将静态数据作为基础数据，将动态数据作为业务数据（交易数据）用是没有问题的。只要是使用的人之间达成共同的认知即可。

04数据标准、数据规范

提到“数据标准”，可能大多数人第一时间想到的是一系列的标准化文档，例如：产品设计标准、生产标准、质量检验标准、库房管理标准、安全环保标准、物流配送标准等。事实上，数据标准不应该只是停留在文件层面的内容，更多的是要为业务的运行和管理决策提供基础保障。

在信通院发布的《2019数据标准管理实践白皮书》中对数据标准给出了如下定义：“数据标准（Data Standards）是指保障数据的内外部使用和交换的一致性和准确性的规范性约束”。这么讲，可能比较难以理解。

笔者理解数据标准是注重结果而数据规范是定义过程。数据标准是数据明确的定义，明确的数据分类、确定的存储格式和既定规则的转换、编码等。数据标准侧重于强调对数据本身的标准化，诸如：数据的定义、结构、存储等，注重的是结果。而数据规范是指在操作层面采取的措施、循序的规则和执行的流程，侧重于强调流程和操作——如何实现数据标准化，更注重过程。

在实际工作中，我们经常会说建设“数据标准规范体系”，大多数人认为这是一个事情，但严格来讲，这是两件事：一是建设数据标准，二是要规范数据标准的落地的流程以及流程所涉及到的人员、组织、权限等问题。

05数据目录、数据分类、数据标签

数据资源目录，最早是政务领域提出的概念，是为了“数据需求方使用数据而提供的检索支持”。数据资源目录的原始驱动力是“政务数据资源共享”，是面向数据使用者的。工程实践落地，是从2005年国家政务数据交换、目录体系、四大库试点开始的，并在2007年正式发布国标：《GB/T 21063-2007 政务信息资源目录体系》。

政务数据资源目录是通过对政务信息资源依据规范的元数据描述，按照一定的分类方法进行排序和编码的一组信息,用以描述各个政务信息资源的特征，以便于对政务信息资源的检索、定位与获取。2007年的国标给出的标准定义，站在现在政务数据治理的高度来看，原来的“目录体系”建设，仅仅是个工具而已，已经很单薄了，当前的“数据资源目录”，实际上可以和“数据资产管理”和“数据服务”结合在一起，才能有更好的发展前景。

数据分类就是把具有某种共同属性或特征的数据归并在一起，通过其类别的属性或特征来对数据进行区别。换句话说，就是相同内容、相同性质的信息以及要求统一管理的信息集合在一起，而把相异的和需要分别管理的信息区分开来，然后确定各个集合之间的关系，形成一个有条理的分类系统。——百度百科

数据标签是对数据实体特征的符号表示，每一个数据标签都是我们认识、观察和描述数据实体的一个角度。商品有标签，例如衣服的标签中包含了衣服的款式、尺码、面料、清洗方式等信息。人也有标签，例如人的性别、年龄、地区、兴趣爱好、产品偏好、购买力、忠诚度等。数据标签也是可以分类的，例如：可以按变化频率可分为动态标签、静态标签；按评估的方式不同，分为定量指标和定性指标；按来源不同，分为基础标签、业务标签、智能标签等。有关数据标签的分类，我的一篇《数据中台：基于标签体系的360°用户画像》文章中，有较为详细的说明，有兴趣可看下。

在实际的数据资产管理中，数据资源目录、数据分类、数据标签是相互配合、相辅相成的。建立良好的数据资源目录的第一步就是明确数据资源的分类，根据数据分类去组织资源、编目，之后是为数据资源打上数据标签，让数据资源更贴近用户、更容易管理，以便充分发挥出数据的价值。

06数据模型、数据结构、数据字典

数据（Data）是描述事物的符号记录，模型（Model）是现实世界的抽象，数据模型（Data Model）是数据特征的抽象和描述。

专业的术语总是抽象的，我们举个例子，假如你去买房子，就会看到两个模型，一个是楼盘模型，另一个是户型模型（户型图）。楼盘模型描述了楼盘规划、小区位置、小区绿化、交通条件、周边的配套设施（幼儿园、学校、医院等）、未来楼盘发展等等。户型模型描述了房子有几室几厅、几个阳台，哪里是门，哪里是墙，哪里是窗户，每个房间的平米数是多少，甚至是屋子里的布局全部都用各种符号表示得清清楚楚。

就如楼盘模型描述楼盘，户型模型描述房子一样，数据模型是用来描述数据的一组简单易懂便于计算机实现的符号的集合。

再说数据结构，数据结构是指相互之间存在一种或多种特定关系的数据元素的集合。一般认为数据结构是构成数据模型的三个要素之一。数据模型一般会分为概念模型、逻辑模型、物理模型，而数据的逻辑结构、物理结构是与逻辑模型、物理模型对应的。逻辑结构反映数据元素之间的数据关系，包含数据元素的层次关系、关联关系，不包含数据在计算机中的存储位置；数据的物理结构是指数据的逻辑结构在计算机存储空间的存放形式。如果还拿房子举例的话，我认为说户型模型或者户型结构都是没有问题的。

数据字典是指对数据的数据项、数据结构、数据流、数据存储、处理逻辑、外部实体等进行定义和描述，这个是数据字典的标准定义。但是，目前的实际使用中对数据字典有两种不同的说法或用法。

一种说法是：在软件工程中，数据字典是作为分析阶段的工具，供人查询对不了解的条目的解释，例如：描述某个数据表中都包含了哪些数据项，某个数据项的业务含义是什么等。

另外一个说法是：对基础数据参照的管理，我们还拿房子举例，一个房子的数据字典，包括，房屋的朝向：东，南，西，北，东西，南北等；房屋的户型：两室一厅，三室一厅，两室二厅，三室两厅等；房屋的性质：经济适用房，房改房，商品房等。

如果按第一种说法理解数据字典，其实本质上和数据模型没有什么区别，只是叫法不同而已。如果按第二种说法理解，似乎叫参照数据管理也没什么不妥。到底该怎么理解？这可能就“仁者见仁智者见智”了。

07数据仓库、数据湖、数据工厂、数据中台

数据仓库（Data Warehouse）是一个面向主题的、集成的、相对稳定的、反映历史变化的数据集合，用于支持管理决策和信息的全局共享。

所谓面向主题，是指根据使用者实际需求，将不同数据源的数据在一个较高的抽象层次上做整合，所有数据都围绕某一主题来组织，例如：采购主题、生产主题、客户主题、销售主题等。

所谓集成性，是指数据仓库中存储的数据是来源于多个数据源的集成、汇总。由于原始数据来自不同的数据源，存储方式各不相同。要整合成为最终的数据集合，需要从数据源经过一系列抽取、清洗、转换的过程。

所谓相对稳定，是指数据仓库中存储的数据一般为“既成事实”的数据，也可理解为历史数据的一个快照，只做查询分析用，不允许修改。

所谓反映历史变化，是指数据仓库根据不断集成新的主题数据，反应出该主题的数据变化情况，例如：销售业绩完成情况。

数据湖是将来自不同数据源、不同数据类型（结构化、半结构化、非结构化）的数据，以原始格式存储进行存储的系统，它按原样存储数据，而无需事先对数据进行结构化处理。有人认为数据湖是数据仓库的PLUS版，增强了数据存储的能力。而实际上，数据湖不简单是数据仓库一个技术上的升级，更重要的是数据管理思维的升级。数据仓库是需要事先定义好数据结构，然后是报表取数。而大数据的发展，数据形式越发多样化，传统数仓这种定义数据结构、取数、出表的模式，已经很难满足业务上的需求了。因此，数据湖以原始格式存储各种类型数据，以及按需进行数据结构化处理、数据清理、提供数据服务，以更加灵活的方式支持多种应用场景的能力越来越受到人们的欢迎。

再来说说这个数据工厂。前边提到的数据仓库和数据湖，重点侧重于数据的存储，本质上是“原材料”的存储系统，而要让数据发挥价值，就必须将这个“原材料”需要加工成用户需要的“产品”。数据工厂就是根据用户的需求，将原始数据进行加工、处理、清洗、转换、汇总等各种加工工序，生产出能够被用户直接使用的数据产品。数据工厂包含了多种数据处理的工具，以满足不同处理工序的作业需要，例如：数据源连接、数据同步、数据清洗、数据转换、数据工作流、数据目录、数据服务等等。

最后，再说说数据中台，尽管之前的文章已经说过很多次了。其实，如果从功能构件上来讲，我认为：数据中台就是数据湖+数据工厂的一个综合。但不同的是数据中台更注重数据应用，离业务更近，强调一个快速敏捷。

数据中台不仅关注原始数据的存储及处理加工，更侧重将数据处理过程中，常用的逻辑、算法、标签、模型进行沉淀，而形成一系列的“数据半成品”，然后根据前台业务的需要，快速生产出用户需要的“数据产品”。数据中台能力强弱，要看这个“数据半成品”积累的多少了。

在数据生产的整个链条中，对于如何筑湖、如何选址建厂、按什么工序加工、以及如何配送，这是技术部门的事情，而“数据半成品”的沉淀和积累，却不是技术能决定的了。因此，数据中台的建设更强调需求驱动、业务主导。

08数据指标、数据维度、数据度量

数据治理的目标是让数据更好的使用，而数据的应用和分析的过程就不得不理一下：数据指标、数据维度、数据度量这几个概念了。

数据指标是用数据表示，用来衡量对象目标的参数或预期中打算达到的指数、规格、标准，是具有（业务）意义的指向和标杆。数据指标分为基础指标和衍生指标，基础指标是指表达业务实体原子量化属性的且不可再分的指标，如交易笔数、交易金额、在线用户数等；衍生指标是在基础指标的基础上，通过添加一个或多个统计维度形成新的指标、或通过不同指标进行运算而形成新的指标，如平均购买金额、生产计划完成值，累计问题数、同比、环比、占比等。

关于“维度”网上很多人给出的定义是这样的：“维度可指定不同值的对象的描述性属性或特征”。不知道大家能不能看懂，如果只看这段文字，我是一脸懵逼的。我理解的维度就是观察和分析事物或指标不同角度，例如：销售额这个指标，可以按时间周期（当日、周、月、季度、年度）进行分析，也可以按照产品类型（A产品销售额、B产品销售额…）分析，也可以按地理位置（北京销售额、上海销售额…）分析，还可以按销售主体（a部门销售额、b部门销售额）分析等等。

最后说下度量。度量是被聚合（观察）的统计值，也就是聚合运算的结果，维度其实可以理解成一种分类的方式，或者叫做标签，而度量往往是一个计算出来的数值。度量可以是指标的度量衡也可以是针对指标的某个维度的度量，例如上边例子中，销售额的度量是金额，当月销售金额也是度量。

度量、维度、指标不是固定的，在一定的应用场下度量可以转化为维度，维度也可以转化为指标。篇幅问题，有关度量、维度、指标的转化这里就不展开了。