谈谈数据治理（什么是数据治理）
转载至https://zhuanlan.zhihu.com/p/651814557数据治理是一个对企业数字化转型至关重要的一个环节，关乎着企业核心数据是否能被规范化管理、数据的价值是否能被充分发挥等等。说白了能给企业实现降本增效、业务精细化运营、重要决策制定、产品优化迭代等多方面的收益。
说到数据治理，我们得清晰认识到以下几点。
- 什么是数据治理？
- 为什么需要数据治理，痛点？
- 什么时候进行数据治理？
- 数据治理涉及的人员职责是怎么划分的？
- 数据治理能给企业带来什么？
一、什么是数据质量和数据治理的定义
1 什么是数据治理？
数据治理是对数据资产管理行使权力和控制的活动集合（规划、监控和执行），数据治理职能指导其他数据管理职能如何执行，最终保证数据的可用性、数据质量和数据安全。
2 为什么需要数据治理？痛点
往往企业向数据化转型的途中，使用数据的同时会涉及到很多痛点，这些痛点可能来源于业务、技术、运维、产品等不同的和数据相关的成员，具体的痛点大致可以分为以下几类(包含且不局限于此)，且附上对应的解决方案。
3 什么时候进行数据治理？
- 数字化转型的初期
- 从规范、流程标准化等方面进行管控
- 数字化转型的中期
- 针对数据使用遇到的痛点，阶段性的进行改造，通常每个治理的方向可以立一个里程碑，通常可以多方并行治理
- 产品设计治理对应的功能，如指标维度管理系统、元数据管理系统、数据地图、数据资产线上化、指标集市、运维视图、任务血缘、表字段血缘等
- 平台研发功能并上线
- 数据开发与治理人员按照治理的要求实施对应的治理策略，如制定数据质量校验规则，配置关键节点监控告警、数据清理、数据运营盘点等
4 数据治理涉及的人员职责是怎么划分的？
数据治理是一项非常抽象且庞大的内容，单靠一个人或者单个团队很难达成理想化的效果，所以在数据治理的过程中需要根据企业的体量、业务的复杂度等角度对数据治理的组织架构进行专业的划分。
上图是比较详细的数据治理委员会的组织架构。
5 数据治理能给企业带来什么？
二、 首先认识一些名词
在学习数据治理知识之前，首先要明白治理的对象都有哪些，什么才是数据？是1，2，3，4这种纯数字类型的才算数据吗？还是所有的文本数据都是数据？
请往下看。
1.1 元数据、数据元、数据源、源数据
元数据、数据元、数据源、源数据，这几意思毫不相干却都带着一个“yuan”词语，让多初学者抓狂。
数据元，标准定义：[GB/T 18391.1－2002，定义3.14] ，用一组属性描述定义、标识、表示和允许值的数据单元，数据元由三部分组成：对象、特性、表示。
数据元用一组属性描述定义、标识、表示和允许值的数据单元，由三部分组成：对象、特性、表示。它是组成实体数据的最小单元，或称原子数据、数据元素，例如，客户联系人方式中的联系人姓名就是就可以理解为一个数据元素，姓名为数据元的对象，“张三”为数据元的值。再例如，客户联系方式中的手机号码，手机号为数据元，135****为数据元的值。
元数据（MateData），官方定义是描述数据的数据，让数据更容易理解、查找、管理和使用。
从分类上，元数据分为了业务元数据、技术元数据、管理元数据。业务元数据，例如：数据的定义、业务规则、质量规则等；技术元数据：数据表、字段长度，字段编码、字段类型等；管理元数据：数据的存储位置、管理人员、更新时间、更新频率等。
元数据是业界公认的数据管理中的基础，元数据管理提供的功能诸如数据地图、血缘分析、影响分析、全链路分析、热度分析等，让用户更容易的对数据进行检索、定位、管理、评估。用哲学的思维理解元数据的话，元数据其实解决的是：我是谁，我在哪里，我从哪里来，我要到哪里去的问题。
数据是物料，而元数据是仓库里的物料卡片；
数据是文件夹，而元数据是夹子上的标签；
数据是书，元数据是图书馆中的图书卡。
用一张图可以形象地表明：
数据源（Data Source），顾名思义就是数据的来源，是提供某种所需要数据的器件或原始媒体。在数据源中存储了所有建立数据库连接的信息，通过提供正确的数据源名称，可以找到相应的数据库连接。
10年前我们讲数据源，更多的是说一种数据连接的技术，比如：JDBC、ODBC，或者是指数据库的类型，比如：结构化数据库、非结构化数据库。而大数据时代，数据呈多样化发展，数据来源的多样化是时代的一个特征。我们现在提到的数据源，除了上述的含义之外，还涉及到图数据源、时序数据源、键值数据源、内存数据源、文档数据源等。每一种数据源不同，其数据的存储、传输、处理和应用的模式、场景、技术和工具也不相同。
源数据（Source Data），注意：这个词与数据源（Data Source）只是词语换了一个顺序，但是它们代表的含义却是大相径庭了。数据源本质是讲存储或处理数据的媒介，而源数据本质是在讲“数据”本身，强调数据状态是“创建”之后的“原始状态”，也就是没有被加工处理的数据。在数据管理的过程中，源数据一般是指直接来自源文件（业务系统数据库、线下文件、IoT等）的数据，或者直接拷贝源文件的“副本数据”。
“问渠哪得清如许，为有源头活水来”！数据治理的核心还是要从数据源抓起，以确保源数据的标准、准确、完整、真实。
1.2 主数据、基础数据、静态数据
主数据是企业中需要在多个部门或系统之间共享的，核心的、高价值且相对静态的数据。主数据是企业信息系统建设和大数据分析的基础，被认为是企业数字化转型的基石和企业中的黄金数据。
主数据具备3个主要特征
①高价值：主数据是所有业务处理都离不开的实体数据，与大数据相比价值密度非常高。
②高共享：主数据是跨部门、跨系统高度共享的数据。
③相对稳定：与交易数据相比主数据是相对稳定的，变化频率较低。变化频率较低并不意味着一成不变，例如：客商更名会引起客商主数据的变动、人员调动会引起人员主数据的变动等等。
主数据的4个超越：即超越业务，超越部门、超越系统、超越技术。
①超越业务，主数据是跨越了业务界限，在多个业务领域中被广泛使用的数据，其核心属性也是来自业务。例如：物料主数据，它有自身的自然属性，如：规格、材质，也有业务赋予的核心属性，如：设计参数、工艺参数、采购、库存要求、计量要求、财务要求等。同时，主数据也要服务于业务，可谓是———从业务中来到业务中去。
②超越部门，主数据是组织范围内共享的、跨部门的数据，不归属某一特定的部门，是企业的核心数据资产。
③超越系统，主数据是多个系统之间的共享数据，是应用系统建设的基础，同时也是数据分析系统重要的分析对象。
④超越技术，主数据是要解决不同异构系统之间的核心数据共享问题，从来不会局限于一种特定的技术。在不同环境、不同场景下，主数据的技术是可以灵活应对的。主数据的集成架构是多样的，如：总线型结构、星型结构、端到端结构；集成技术也是多样的，如：webservice、REST、ETL、MQ、kafka等；不论是架构还是技术，没有最好的只有更合适的。企业在做技术选型的时候，要充分考虑企业的核心业务需求和未来的发展要求去构建自身的主数据技术体系。
基础数据，业界还没有一个标准的定义。但在很多信息化项目中，基础数据这个概念都会被提及和使用。同时，常常会有客户对基础数据和主数据概念混淆。我理解的基础数据是信息系统运行的基础，用来支撑信息系统运行的各种数据和参数，以及业务交易所依赖的基础信息。而主数据是被多个系统共享的基础数据。因此，我理解的主数据可以是基础数据的一部分，但基础数据绝对不等于主数据。
静态数据也是一个使用比较广泛的词语并且是经常与基础数据“随机”来用的。静态数据是指在运行过程中主要作为控制或参考用的数据,它们在很长的一段时间内不会变化，一般不随运行而变。例如：客户的名称、员工的姓名、系统的参数。动态数据是常常变化，直接反映事务过程的数据，比如，网站访问量、在线人数、日销售额等等。因此，将静态数据作为基础数据，将动态数据作为业务数据（交易数据）用是没有问题的。只要是使用的人之间达成共同的认知即可。
1.3 数据模型、数据结构、数据字典
数据（Data）是描述事物的符号记录，模型（Model）是现实世界的抽象，数据模型（Data Model）是数据特征的抽象和描述。
专业的术语总是抽象的，我们举个例子，假如你去买房子，就会看到两个模型，一个是楼盘模型，另一个是户型模型（户型图）。楼盘模型描述了楼盘规划、小区位置、小区绿化、交通条件、周边的配套设施（幼儿园、学校、医院等）、未来楼盘发展等等。户型模型描述了房子有几室几厅、几个阳台，哪里是门，哪里是墙，哪里是窗户，每个房间的平米数是多少，甚至是屋子里的布局全部都用各种符号表示得清清楚楚。
就如楼盘模型描述楼盘，户型模型描述房子一样，数据模型是用来描述数据的一组简单易懂便于计算机实现的符号的集合。
再说数据结构，数据结构是指相互之间存在一种或多种特定关系的数据元素的集合。一般认为数据结构是构成数据模型的三个要素之一。数据模型一般会分为概念模型、逻辑模型、物理模型，而数据的逻辑结构、物理结构是与逻辑模型、物理模型对应的。逻辑结构反映数据元素之间的数据关系，包含数据元素的层次关系、关联关系，不包含数据在计算机中的存储位置；数据的物理结构是指数据的逻辑结构在计算机存储空间的存放形式。如果还拿房子举例的话，我认为说户型模型或者户型结构都是没有问题的。
数据字典是指对数据的数据项、数据结构、数据流、数据存储、处理逻辑、外部实体等进行定义和描述，这个是数据字典的标准定义。但是，目前的实际使用中对数据字典有两种不同的说法或用法。
一种说法是：在软件工程中，数据字典是作为分析阶段的工具，供人查询对不了解的条目的解释，例如：描述某个数据表中都包含了哪些数据项，某个数据项的业务含义是什么等。
另外一个说法是：对基础数据参照的管理，我们还拿房子举例，一个房子的数据字典，包括，房屋的朝向：东，南，西，北，东西，南北等；房屋的户型：两室一厅，三室一厅，两室二厅，三室两厅等；房屋的性质：经济适用房，房改房，商品房等。
如果按第一种说法理解数据字典，其实本质上和数据模型没有什么区别，只是叫法不同而已。如果按第二种说法理解，似乎叫参照数据管理也没什么不妥。到底该怎么理解？这可能就“仁者见仁智者见智”了。
1.4 数据指标、数据维度、数据度量
数据治理的目标是让数据更好的使用，而数据的应用和分析的过程就不得不理一下：数据指标、数据维度、数据度量这几个概念了。
数据指标是用数据表示，用来衡量对象目标的参数或预期中打算达到的指数、规格、标准，是具有（业务）意义的指向和标杆。数据指标分为基础指标和衍生指标，基础指标是指表达业务实体原子量化属性的且不可再分的指标，如交易笔数、交易金额、在线用户数等；衍生指标是在基础指标的基础上，通过添加一个或多个统计维度形成新的指标、或通过不同指标进行运算而形成新的指标，如平均购买金额、生产计划完成值，累计问题数、同比、环比、占比等。
关于“数据维度”网上很多人给出的定义是这样的：“维度可指定不同值的对象的描述性属性或特征”。不知道大家能不能看懂，如果只看这段文字，我是一脸懵逼的。我理解的维度就是观察和分析事物或指标不同角度，例如：销售额这个指标，可以按时间周期（当日、周、月、季度、年度）进行分析，也可以按照产品类型（A产品销售额、B产品销售额…）分析，也可以按地理位置（北京销售额、上海销售额…）分析，还可以按销售主体（a部门销售额、b部门销售额）分析等等。
最后说下数据度量。数据度量是被聚合（观察）的统计值，也就是聚合运算的结果，维度其实可以理解成一种分类的方式，或者叫做标签，而度量往往是一个计算出来的数值。度量可以是指标的度量衡也可以是针对指标的某个维度的度量，例如上边例子中，销售额的度量是金额，当月销售金额也是度量。
度量、维度、指标不是固定的，在一定的应用场下度量可以转化为维度，维度也可以转化为指标。
1.5 数据治理、数据管理、数据管控
数据治理、数据管理、数据管控这三个名词在一定程度上的确是有所重叠的，容易混为一谈，所以就造成了在实际使用中，经常将这三个词语“混着用”、“随机用”的现象。有关数据治理、数据管理区别的讨论有很多，有人认为数据治理是包含在数据管理中的，数据管理的范围要更广，例如：在《DAMA-DMBOK数据管理知识体系指南》中就明确提出数据管理包含数据治理；也有人认为数据治理要高于数据管理，是企业顶层上的策略。
以上两个观点都没有错，如果要用一个模型来描述数据治理、数据管理、数据管控这三个名词，那应该是一个“金字塔”模型。
最顶层的应该是数据治理。与“治理”相关，我们还会经常看到、听到国家治理、公司治理的概念，从某种意义上讲，治理是一种自顶向下的策略或活动。如果我们将国家治理说成国家管理，把公司治理说成公司管控是不是有点怪怪的？
因此，数据治理应该是企业顶层设计、战略规划方面的内容，是数据管理活动的总纲和指导，指明数据管理过程中哪些决策要被制定，以及由“谁”来负责，更强调组织模式、职责分工和标准规范。
数据管理是为实现数据和信息资产价值的获取、控制、保护、交付以及提升，对政策、实践和项目所做的计划、执行和监督。这个是《DAMA-DMBOK》中关于数据管理的定义。笔者理解数据管理是实现数据治理提出的决策并给予反馈，强调管理流程和制度，涵盖不同的管理领域，诸如：元数据管理、主数据管理、数据标准管理、数据质量管理、数据安全管理、数据认责管理、数据服务管理等。
数据管控更多的是执行层面，是具体的如何落地执行所涉及的各种措施，例如：数据建模、数据抽取、数据处理、数据加工、数据分析等，数据管控是确保数据被管理和监控，从而让数据得到更好的利用。
因此，数据治理强调顶层的策略，管理是侧重于流程和机制，管控是具体的措施和手段，三者应该是相辅相成的。而如今我们听到的更多的“数据治理”这个词，似乎只要涉及数据管理的，都在说自己在搞数据治理。出现这个问题，主要是企业越来越意识到传统IT驱动或者说技术驱动的专项数据管理项目，在实施过程中很难推进、困难重重，并且很难解决业务和管理上的用数难的问题。而从战略、组织入手的数据治理顶层设计，更有利于推动数据管理目标的实现。
二、数据治理框架
2.1 为何要做数据治理
在我国，各行业的信息化发展和建设水平并不均衡，甚至有的行业是刚刚起步。但是，不论是金融行业、通讯行业、地产行业、传统制造业以及农业，其信息化的发展基本都遵循了“诺兰模型”。企业信息化大致经历了初期的烟囱式系统建设、中期的集成式系统建设和后期的数据管理式系统建设三个大的阶段，可以说是一个先建设后治理的过程。
1、数据质量层次不齐
当今时代，“数据资产化”的概念已经被大多数人理解和接受。不论是企业、政府还是其他组织机构，对于的数据资产的管理越来越重视。然而，数据并不等于资产，也就是说不是所有数据都是数据资产，数据中也有垃圾数据。我们需要治理的是能够为企业创造价值的数据资产，而不是全部数据。
2、数据交换和共享困难
企业信息化建设初期缺乏整体的信息化规划，系统建设大多都是以业务部门驱动的单体架构系统或套装软件，数据分散在这些架构不统一、开发语言不一致、数据库多样化的系统中，甚至还有大量的数据存放在员工的个人电脑中，导致在企业内部形成了一个个的“信息孤岛”。这些“孤岛”之间缺乏有效的连接通道，数据不能互联互通，不能按照用户的指令进行有意义的交流，数据的价值不能充分发挥。只有联通数据，消除这些“信息孤岛”，才能实现数据驱动业务、数据驱动管理，才能真正释放数据价值。
3、缺乏有效的管理机制
目前，许多企业都认识到了数据的重要性，并尝试通过生产系统的业务流来控制数据流，但由于缺乏有效的管理机制和某些人为的因素，在数据流转过程中，存在数据维护错误、数据重复、数据不一致、数据不完整的情况，导致了产生了大量的垃圾数据。数据产权不明确，管理职责混乱，管理和使用流程不清晰，是造成数据质量问题的重要因素。
4、存在数据安全隐患
2018年3月份的Facebook 5000万用户信息被泄露和滥用的事件，受该事件影响，Facebook股价当日大跌7%，市值缩水360多亿美元，而盗用数据的剑桥分析这家公司也于同年5月停止运营，并申请破产。这种数据安全事件，在我国发生频率更多，2011年，黑客在网上公开了CSDN的用户数据库，高达600多万个明文的注册邮箱账号和密码遭到曝光和外泄；2016年，顺丰员工应盗取大量客户信息被送上法庭；2017年，京东员工盗取用户个人信息50亿条，并通过各种方式在网络黑市贩卖。2021年，滴滴因泄漏用户信息被公开调查，阿里云泄漏用户注册数据。随着大数据的发展，诸如此类的数据安全事件多不胜数。数据资产管理上，正在由传统分散式的人工管理向计算机集中化管理方向发展，数据的安全问题愈来愈受到人们的关注。
2.3 分类
DMBOK将数据管理分为以下10个职能域：
注：DAMA 是数据管理协会的简称，是一个全球性数据管理和业务专业志愿人士组成的非营利协会，致力于数据管理的研究和实践。
数据控制：在数据管理和使用层面之上进行规划、监督和控制。
数据架构管理：定义数据资产管理蓝图。
数据开发：数据的分析、设计、实施、测试、部署、维护等工作。
数据操作管理：提供从数据获取到清除的技术支持。
数据安全管理：确保隐私、保密性和适当的访问权限等。
数据质量管理：定义、监测和提高数据质量。
参考数据和主数据管理：管理数据的黄金版本和副本。
数据仓库和商务智能管理：实现报告和分析。
文件和内容管理：管理数据库以外的数据
元数据管理：元数据的整合、控制以及提供元数据。
数据治理是长期、复杂的工程，涉及到组织体系、标准体系、流程体系、技术体系和评价体系五方面的工作领域，包含了数据标准、数据质量、主数据、元数据、数据安全等多个方面内容。由于企业性质、业务特点、管理模式的不同，有必要建立符合企业现状和企业需求的数据治理框架，指导企业数据治理工作的开展。
2.4 数据治理的阶段
目前我国的企业可以简单分为下面三类。
第一类企业：经济实力雄厚，信息化起步较早，信息化程度比较高，如：XX银行、国家电网，他们已形成了系统性的数据治理体系。
第二类企业：有一定的经济实力、信息化程度相对较好，但是早期的信息化盲目建议，买了一堆的套装软件，建了一堆的系统，虽然系统或多或少都有使用，但效果不佳，谈起数据治理，客户自己都觉得头痛：企业到底都有哪些数据？这些数据都是分布在哪里？数据治理该如何入手？
第三类企业：经济实力相对薄弱，也有信息化刚刚起步的企业，这些企业多数的业务还是靠纸质或线下模式，部分企业使用了财务软件或ERP系统，数据存放个人电脑或生产系统中，基本没有数据治理。我国的一些中小民型营制造企业多数处于这个水平。
企业数据治理的时机该如何选择？是先有了数据再进行治理，还是先建设好数据治理体系再进行应用系统建设？针对上述不同类型的企业，其数据治理选择的时机和体系建设的设计绝对不能一概而论。
对于第一类企业，已经有了相对完善的数据治理体系，更需要的是加强数据安全、数据应用、数据创新，稳固提升数据管理、数据应用和数据变现的能力；
对于第二类企业单体架构的系统多，信息孤岛严重，一定存在数据多源、重复、不一致等问题，其数据治理已是迫在眉睫；
对于第三类企业，在数字化的浪潮下，信息化虽然薄弱，但如果打好数据基础，未免不是企业改革创新，实现“弯道超车”的最佳时机。
2.5 数据治理的内容
数据治理是长期、复杂的工程，涉及到组织体系、标准体系、流程体系、技术体系和评价体系五方面的工作领域，包含了数据标准、数据质量、主数据、元数据、数据安全等多个方面内容。由于企业性质、业务特点、管理模式的不同，有必要建立符合企业现状和企业需求的数据治理框架，指导企业数据治理工作的开展。
组织体系：数据治理项目的实施绝非是一个部门的事情，不能在企业的单一部门得到解决。需要从整个组织考虑，建立专业的数据治理组织体系，进行数据资产的确权，明确相应的治理制度和标准，培养整个组织的数据治理意识。这需要 IT 与业务部门进行协作，而且必须始终如一地进行协作，以改善数据的可靠性和质量，从而为关键业务和管理决策提供支持，并确保遵守法规。
标准体系：数据治理的标准体系是多个层面的，包括：国际标准、国家标准、行业标准、企业标准等。企业数据标准体系内容应涵盖：元数据标准、主数据标准、参照数据标准、数据指标标准等。数据治理的成效，很大程度上取决与数据标准的合理性和统一实施的程度。企业数据标准体系的建设应既满足当前的实际需求，又能着眼未来与国家及国际的标准接轨。
流程体系：数据治理流程体系，为数据治理的开展提供有据可依的管理办法、规定数据治理的业务流程、数据治理的认责体系、人员角色和岗位职责、数据治理的支持环境和颁布数据治理的规章制度、流程等。建立数据的生产、流转、使用、归档、消除的整个生命周期管理的过程。企业应围绕数据治理的对象：数据质量、数据标准、主数据、元数据、数据安全等内容建立相应的制度和流程。
评价体系：建立数据评价与考核体系是企业实施和贯彻数据治理相关标准、制度和流程的根本。建立明确的考核制度，实际操作中可根据不同企业的具体情况和企业未来发展要求建立数据的认责体系，设置考核指标和考核办法，并与个人绩效挂钩。考核指标包括两个方面内容，一方面是对数据的生产、管理和应用等过程的评估和考核指标，另一方面是数据质量的评测指标。
技术体系：数据治理包括数据治理的工具和技术，总体应包括元数据管理、主数据管理、数据标准管理、数据质量管理和数据安全管理。
元数据管理：元数据管理是对企业涉及的业务元数据、技术元数据、管理元数据进行盘点、集成和管理，按照科学、有效的机制对元数据进行管理，并面向开发人员、最终用户提供元数据服务，以满足用户的业务需求，对企业业务系统和数据分析平台的开发、维护过程提供支持。借助变更报告、影响分析等应用，控制数据质量、减少业务术语歧义和建立业务和技术之间的良好沟通渠道，进一步提高各种数据的可信性、可维护性、适应性和可集成性。
数据标准管理：数据标准适用于业务数据描述、信息管理及应用系统开发，可以作为经营管理中所涉及数据的规范化定义和统一解释，也可作为信息管理的基础，同时也是作为应用系统开发时进行数据定义的依据。涉及国家标准、行业标准、企业标准和地方标准，在定义元数据实体或元素时进行关联。数据标准需要不断的补充完善、更新优化和积累，以便更好的支撑业务的开发和系统的集成。
主数据管理：主数据管理是通过运用相关的流程、技术和解决方案，对企业核心数据的有效管理过程。主数据管理涉及主数据的所有参与方，如用户、应用程序、业务流程等，创建并维护企业核心数据一致性、完整性、关联性和正确性。主数据是企业内外被广泛应用和共享的数据，被誉为是企业数据资产中的“黄金数据”，主数据管理是撬动企业数字化转型的支点，是企业数据治理最核心的部分。
数据质量管理：建立数据质量管理体系，明确数据质量管理目标、控制对象和指标、定义数据质量检验规则、执行数据质量检核，生产数据质量报告。通过数据质量问题处理流程及相关功能实现数据质量问题从发现到处理的闭环管理，从而促进数据质量的不断提升。
数据安全管理：目前多数人都知道数据安全问题十分重要，但在现实中，数据安全却常常被忽视，只有出现了数据安全问题甚至事故时，人们才认识到要为数据安全做点什么了。数据安全应贯穿数据治理全过程，应保证管理和技术两条腿走路。从管理上，建立数据安全管理制度、设定数据安全标准、培养起全员的数据安全意识。从技术上，数据安全包括：数据的存储安全、传输安全和接口安全等。当然，安全与效率始终是一个矛盾体，数据安全管控越严格，数据的应用就可能越受限。企业需要在安全、效率之间找到平衡点。
三、元数据管理
有关元数据的定义，在上文中已经有过解释了。
3.1 元数据的分类
根据数据的性质特点，业内一般将元数据划分为三类：业务元数据、技术元数据和管理元数据。
业务元数据是描述数据的业务含义、业务规则等。通过明确业务元数据让人们更容易理解和使用业务元数据，元数据消除了数据二义性，让人们对数据有一致的认证，避免“各说自话”，进而为数据分析和应用提供支撑。常见的业务元数据包括：业务定义、业务术语、业务规则、业务指标等。
技术元数据是对数据的结构化，方便计算机或数据库之间对数据进行识别、存储、传输和交换。技术元数据可以服务于开发人员，让开发人员对数据的存储、结构更明确，从而为应用的开发和系统的集成奠定基础。技术元数据也可服务于业务人员，通过元数据理清数据关系，让业务人员能够更快速的找到想要的数据，进而对数据的来源去向进行分析，支持数据血缘追溯和影响分析。常见的技术元数据包括：存储位置、数据模型、数据库表、字段长度、字段类型、ETL脚本、SQL脚本、接口程序、数据关系等。
管理元数据描述了数据的管理属性，包括管理部门、管理责任人等，通过明确管理属性，有利于数据管理责任到部门和个人，是数据安全管理的基础。常见的管理元数据包括：数据所有者、数据质量定责、数据安全等级等。
3.2 元数据管理成熟度
在实施元数据管理的过程中，可以参照元数据管理的成熟度模型确定企业当前元数据管理所在层次，并根据业务需要制定路线图实现元数据管理水平的提升。下图是元数据管理成熟度模型：
3.3 元数据管理成熟度评估模型
L0: 初始状态
元数据分散于日常的业务和职能管理中，由某个人或某一组人员在局部产生或获取，并在局部使用。在局部环境工作数月或数年后，人们使这些元数据以及对它的理解内在化，使对这种信息有习惯性的理解。这些元数据会永远保存在某个人那儿，一旦这个人调离，这些元数据将永远消失。
L1: 从属于业务系统
在这个阶段，随着各个业务系统自动化构建完成，相应的元数据也随着需求整理、设计、开发、实施和维护等过程被各个业务系统孤立的全部或部分管理起来。业务元数据可能分散在各种业务规章、流程规定、需求、需求分析和概要设计等文档以及业务系统中，技术元数据可能分散在详细设计、模型设计和部署方案等各种文档和各种中间件以及业务系统中。由于各个业务系统处于一个个竖井之中，元数据之间互通互联困难，如果需要获取其他系统的元数据，除了调阅各种文档外，对分散在各种中间件和业务系统中的技术元数据需要一定的集成方式实现互通互联。
L2：元数据统一存储
元数据依然在局部产生和获取，但会集中到中央存储库进行存储，业务元数据会手工录入到中央存储库中，技术元数据分散在文档中的部分也通过手工录入到中央存储库中，而散落在各个中间件和业务系统中的技术元数据则通过数据集成的方式被读取到中央存储库中。业务元数据和技术元数据之间全部或部分通过手工方式做了关联。中央存储库的构建，使得元数据在整个企业层面可被感知和搜索，极大地方便了企业获取和查找元数据。缺点是，元数据仍然在各业务系统上维护，然后更新到中央存储库，各业务竖井之间仍然使用不同的命名法，经常会造成相同的名字代表不同意义的事情，而同一件事情则使用了多个不同的名字，有些没有纳入业务系统管理的元数据则容易缺失。元数据没有有效的权限管理，局部元数据更改后也不自动通知其他人。
L3: 元数据集中管理
在 L2 的基础上做了改进，增强了元数据的集中控制，局部业务单元或开发小组如不事先通知其他人，将无法对元数据进行修改。局部元数据的修改完成后将被广播给其他人。和其他中间件和应用系统的交互，仍然通过桥集成的方式进行，中央存储库中的业务元数据和技术元数据之间还是通过手工方式进行映射。
L4：元模型驱动管理
在 L3 的基础上，通过构建元模型以及元元模型，优化各业务单元之间的各种冲突和各种副本，创建、管理和共享业务词汇表和分类系统（基于主题领域的层次结构）。业务词汇表（业务元数据）包含与企业相关的词汇、词汇业务含义以及词汇与信息资产（技术元数据）的关系，可以有效帮助企业用户了解其业务元数据和技术元数据对应的业务含义。分类是基于主题领域的层次结构，用以对业务术语归类。和其他中间件和应用系统的交换，通过基于 CWM 的适配器方式进行连接。
L5: 元数据管理自动化
在 L5 元数据管理是高度自动化的，当逻辑层次元数据变更时，会被传播到物理层次，同样物理层次变更时逻辑层次将被更新。元数据中的任何变化将触发业务工作流，以便其他业务系统进行相应的修改。由于各个业务系统遵照相同的业务词汇表和分类系统（元模型），他们之间的关系可以通过知识本体进行推断，因此各个应用系统之间的数据格式的映射自动产生。
3.4 元数据管理平台架构
元数据管理平台从应用层面，可以分类：元数据采集服务，应用开发支持服务，元数据访问服务、元数据管理服务和元数据分析服务。
元数据采集服务
在数据治理项目中，通常涉及到的元数据还包括：数据源的元数据，数据加工处理过程的元数据，数据仓库或数据主题库的元数据，数据应用层的元数据，数据接口服务的元数据等等。元数据采集服务提供各类适配器满足以上各类元数据的采集，并将元数据整合处理后统一存储于中央元数据仓库，实现元数据的统一管理。这个过程中，数据采集适配器十分重要，元数据采集要能够适配各种DB、各类ETL、各类DW和Report产品，同时还需要适配各类结构化或半结构化数据源。目前市场上的主流元数据产品还没有哪一家能做到“万能适配”，都需要在实际应用过程中做或多或少的定制化开发。
元模型驱动的设计与开发
通过元数据管理平台实现对应用的逻辑模型、物理模型、UI模型等各类元模型管理，支撑应用的设计和开发。应用开发的元模型有三个状态，分别是：设计态的元数据模型，通常由ERWin、PowerDesigner的等设计工具产生。测试态的元数据模型，通常是关系型数据：Oracle、DB2、Mysql、Teradata等，或非关系型数据库：MongDB、HBase、Hive、Hadoop等。生产态的元模型，本质上与测试态元数据差异不大。通过元数据平台对应用开发三种状态的统一管理和对比分析，能够有效降低元数据变更带来的风险，为下游ODS、DW的数据应用提供支撑。另外，基于元数据的MDD（代码生成服务），可以通过模型（元数据）完成业务对象元数据到UI元数据的关联和转换，自动生成相关代码，表单界面，减少了开发人员的设计和编码量，提升应用和服务的开发效率。
3.5 元数据分析服务
血缘分析：是告诉你数据来自哪里，都经过了哪些加工。其价值在于当发现数据问题时可以通过数据的血缘关系，追根溯源，快速地定位到问题数据的来源和加工过程，减少数据问题排查分析的时间和难度。这个功能常用于数据分析发现数据问题时，快速定位和找到数据问题的原因。
影响分析：是告诉你数据都去了哪里，经过了哪些加工。其价值在于当发现数据问题时可以通过数据的关联关系，向下追踪，快速找到都哪些应用或数据库使用了这个数据，从而避免或降低数据问题带来的更大的影响。这个功能常用于数据源的元数据变更对下游ETL、ODS、DW等应用应用的影响分析。
冷热度分析：是告诉你哪些数据是企业常用数据，哪些数据属于“僵死数据”。其价值在于让数据活跃程度可视化，让企业中的业务人员、管理人员都能够清晰的看到数据的活跃程度，以便更好的驾驭数据，激活或处置“僵死数据”，从而为实现数据的自助式分析提供支撑。
关联度分析：是告诉你数据和其他数据的关系以及它们的关系是怎样建立的。关联度分析是从某一实体关联的其它实体和其参与的处理过程两个角度来查看具体数据的使用情况，形成一张实体和所参与处理过程的网络，从而进一步了解该实体的重要程度，如：表与ETL 程序、表与分析应用、表与其他表的关联情况等。本功能可以用来支撑需求变更的影响评估。
数据资产地图：是告诉你有哪些数据，在哪里可以找到这些数据，能用这些数据干什么。通过元数据可以对企业数据进行完整的梳理、采集和整合，从而形成企业完整的数据资产地图。数据资产地图支持以拓扑图的形式进行可视化展示各类元数据和数据处理过程，通过不同层次的图形展现粒度控制，满足业务上不同应用场景的数据查询和辅助分析需要。
3.6 元数据管理价值
一图在手，天下我有
通过元数据以企业全局视角对企业各业务域的数据资产进行盘点，实现企业数据资源的统一梳理和盘查，有助于发现分布在不同系统、位置或个人电脑的数据，让隐匿的数据显性化。数据地图包括了数据资源的基本信息，存储位置信息、数据结构信息、各数据之间关系信息，数据和人之间的关系信息，数据使用情况信息等，使数据资源信息详细、统一、透明，降低“找数据”的沟通成本，为数据的使用和大数据挖掘提供支撑。
追根溯源，发现数据问题本质
企业在做数据分析的时候，数据分析结果不正确，原因可能是数据分析过程出现数据问题，也可能是数据源本身就有问题，还可能是数据在加工处理过程中出现了数据问题……。通过元数据血缘分析，能够快速定位数据来源和加工处理过程，能够帮助数据分析人员快速定位数据问题。另外，通过元数据血缘关系分析，可以理解不同数据指标间的关系，分析产生指标的数据源头波动情况带来的影响。
四、数据标准管理
数据标准是一套由管理制度、管控流程、技术工具共同组成的体系，是通过这套体系的推广，应用统一的数据定义、数据分类、记录格式和转换、编码等实现数据的标准化。
首先，对企业业务域进行定义，并对每个业务域中的业务活动进行梳理，同时需要收集各类业务单据、用户视图，梳理每个单据和用户视图的数据对象。
其次，针对数据对象的进行分析，明确每个数据实体所包含的数据项，同时，梳理并确定出该业务域中所涉及的数据指标和指标项。分析并定义每个数据实体或指标的数据项标准，包括：数据项的名称、编码、类型、长度、业务含义、数据来源、质量规则、安全级别、域值范围、管理部门等。
第三，梳理和明确所有数据实体、数据指标的关联关系，并对数据之间的关系进行标准化定义。数据关系也是数据标准管理的内容。
第四，通过以上梳理、分析和定义，确定出主数据标准管理的范围。
数据标准梳理和建设的方法并不难掌握，关键是建设过程中需要收集并整理大量的业务规范、制度章程、法律法规、监管规定、国家标准，并将这些规定具象到数据标准定义的信息项中。对于一个从未做过数据标准的实施团队而言，这将意味着巨大的工作量。
数据标准管理组织
数据标准管理是企业数据治理的一部分，数据标准管理是一个涉及范围广、业务复杂、数据繁杂的工程。数据标准管理的实施绝非是一个部门的事情，不能在企业的单一部门得到解决。需要从整个组织考虑，建立专业的数据治理组织体系，制定企业数据战略和实施路线图，明确各阶段数据标准工作的目标和内容，并监督及考核数据标准的贯彻与执行。
数据标准管理组织或数据治理组织从职能划分上可以分为三层，如下图所示：
1、数据标准管理委员会，即数据治理的决策层，主要负责制定企业数据战略、把控数据治理的总体策略，审查数据标准的贯彻执行情况。
2、数据标准管理办公室，是数据治理的经营管理层，主要负责企业数据标准的制定、审查数据质量，贯彻数据标准落地。
3、数据标准执行层或业务操作层，主要负责数据标准的贯彻执行，并为数据标准的编制和优化提供数据和意见。
数据标准设计流程
数据标准的设计从需求发起到落地执行，一般需要经过标准编制、标准审查、标准发布、标准贯彻四个阶段：
1. 数据标准编制：数据标准管理办公室根据数据需求开展数据标准的编制工作，确定数据数据项，数据标准管理执行组根据所需数据项提供数据属性信息，例如：数据项的名称、编码、类型、长度、业务含义、数据来源、质量规则、安全级别、域值范围等。数据标准管理办公室参照国际、国家或行业标准对这些数据项进行标准化定义并提交审核。注：如没有参考标准，则数据标准管理办公室可根据企业情况制定相应的企业级数据标准。
2. 数据标准审查：数据标准管理委员会对数据标准初稿进行审查，判断数据标准是否符合企业的应用和管理需求，是否符合企业数据战略要求。如数据标准审查不通过，则有数据标准管理办公室进行修订，直到满足企业数据标准的发布要求。
3. 数据标准发布：数据标准审查通过后，由数据标准管理办公室面向全公司进行数据标准的发布。该过程数据标准管理执行组需要配合进行数据标准发布对现有应用系统、数据模型的影响评估，并做好相应的应对策略。
4. 数据标准贯彻：把已定义的数据标准与业务系统、应用和服务进行映射，标明标准和现状的关系以及可能影响到的应用。该过程中，对于企业新建的系统应当直接应用定义好的数据标准，对于旧系统应对一般建议建了相应的数据映射关系，进行数据转换，逐步进行数据标准的落地。
企业进行数据标准化时，除了对数据本身标准化规则构建外，相当大一部分需要考虑标准化流程的管理。而在管理过程中必然会涉及到新旧系统、不同部门、不同业务的冲突，这些冲突如果解决不好将会直接导致标准化的失败。所以，数据标准落地过程要充分做好影响评估和各干系方的沟通。
数据标准管理价值总结：
一个数据一般有业务属性、技术属性和管理属性组成，例如：数据项的业务定义、业务规则、质量规则为该数据的业务属性；数据项的名称、编码、类型、长度等为该数据的技术属性；数据的存储位置、管理部门、管理人员为该数据的管理属性。而数据标准管理的过程就是对数据以及数据的属性信息的标准化定义和应用的过程。
数据标准目标是为业务、技术和管理提供服务和支持。
业务方面：通过对实体数据的标准化定义，解决数据不一致、不完整、不准确等问题，消除数据的二义性，使得数据在企业有一个全局的定义，减少了各部门、各系统的沟通成本，提升企业业务处理的效率；标准统一的数据指标体系，让业务人员也能够轻松获取数据，并能够自助式的进行数据分析，为基于数据的业务创新提供可能。
技术方面：统一、标准的数据及数据结构是企业信息共享的基础；标准的数据模型和标准数据元为新建系统提供支撑，提升应用系统的开发实施效率；数据标准化清晰定义数据质量规则、数据的来源和去向、校验规则，提升数据质量。
管理方面：通过数据的标准化定义，明确数据的责任主体，为数据安全、数据质量提供保障；统一、标准的数据指标体系为各主题的数据分析提供支持，提升数据处理和分析效率，提供业务指标的事前提示、事中预警、事后提醒，实现数据驱动管理，让领导能够第一时间获取决策信息。
数据标准与主数据、元数据、数据质量的关系
数据治理项目的根本诉求在于提升数据质量
数据标准与主数据的关系
从范围上看，数据标准包括数据模型标准、主数据标准、参照数据标准、数据指标标准和其他数据元标准，主数据是数据标准的一个子集；从数据梳理和识别、能力成熟度评估、数据标准编制、数据管理和应用、管理体系建设、实施涉及的业务面等方面，数据标准和主数据都是基本相同的。企业在数据治理项目中，有整体建设的，包含了：元数据、主数据、数据标准等领域；也有分开建设的，例如：主数据项目单独立项，数据标准管理和数据仓库放在一起实施；企业应根据自身的实际情况和需求，明确实施范围和内容，制定适合企业发展需要的数据治理路线图。
数据标准与元数据的关系
元数据是数据标准的基础，企业在制定数据标准的时候最先需要明确的就是数据业务属性、技术属性和管理属性，而这三类属性就是我们所说的业务元数据、技术元数据和管理元数据。基于元数据的数据标准管理，为业务实体的定义、关系和业务规则到IT实现之间提供清晰、标准的语义转换，提高业务和IT之间的一致性，保障IT系统能够真实反映业务事实。并为数据标准系统与其他业务系统的集成，提供有关数据标准、数据映射关系和数据规则的描述，为业务系统的集成提供支撑。
数据标准与数据质量的关系
没有标准化就没有信息化，那就更谈不上数据质量了。通过对数据标准的统一定义，明确数据的归口部门和责任主体，为企业的数据质量和数据安全提供了一个基础的保障。通过对数据实体、数据关系以及数据处理阶段，定义统一的标准、数据映射关系和数据质量规则，使得数据的质量校验有据可依，有法可循，为企业数据质量的提升和优化提供支持。
五、主数据管理实施四部曲
我们知道主数据项目的建设是一个循序渐进、持续优化的过程，不可一蹴而就。个人认为主数据管理项目从咨询规划到落地实施再到初步见效需要经历四个阶段，而每个阶段都是必经阶段，每个阶段均可独立成章，所以这里是四部曲，不是四步曲。
主数据项目建设从方法上，分为以下四部，简单归结为12个字：“摸家底、建体系、接数据、抓运营”！
5.1 摸家底
摸家底需要全面调研和了解企业的数据管理现状，以便做出客观切实的数据管理评估！
1、数据资源普查
数据资源普查的方法常用的有两种，一种是自顶向下的梳理和调研，另一种是自底向上的梳理和调研。
自顶向下的调研一般会用到IRP（信息资源规划）和BPM（业务流程管理）两个方法。这里重点介绍一下IRP，信息资源规划（Information Resource Planning ,简称IRP），是指对所在单位信息的采集、处理、传输和使用的全面规划。其核心是运用先进的信息工程和数据管理理论及方法，通过总体数据规划，奠定资源管理的基础，促进实现集成化的应用开发，构建信息资源网。
IRP是信息工程方法论、总体数据规划和信息资源管理标准的结合体，其实现方法可概括为：IRP = 两个阶段 + 两条主线 + 三个模型 + 一套标准，如下图所示：
采用IRP方法进行数据梳理需要对职能域、业务域进行定义，并对每个职能域和业务域中的业务流程进行梳理，同时需要收集各类业务单据、用户视图，并对每个单据和用户视图进行梳理和数据元素分析。
该方法优点让企业能够对现有数据资源有个全面、系统的认识。特别是通过对职能域之间交叉信息的梳理，使我们更加清晰地了解到企业信息的来龙去脉，有助于我们把握各类信息的源头，有效地消除“信息孤岛”和数据冗余、控制数据的唯一性和准确性，确保获取信息的有效性。缺点是需要消耗较大的成本和周期。这种方法适用于包含咨询的主数据项目建设。
由底向上的主数据梳理和调研，一般先确定主数据主题域或数据范围。在范围确定的前提下，从企业信息系统入手，对已建系统、在建系统、待建系统的数据视图进行梳理、分析，识别出主数据在信息系统的分布情况，理清数据来源去向，标准情况、质量情况。另外，还需要对系统未管理的数据（即，我们常说的线下数据）进行整理分析。
在这个过程中，需要在既定的数据范围内，摸透企业主数据的管理情况、数据标准情况、数据质量情况、数据共享情况……。该方法的优点在于针对性强，快速实施、快速见效，缺点是梳理的数据不够全面和系统。一般是有了明确的项目目标和范围的情况下采用该方法最佳。
企业的数据名目繁多，千变万化，我们不可能一次性完成对所有数据资源的梳理和分析。所以，不论使用哪种方法进行需求梳理，企业都要选择好业务重点，优先实施，不能胡子眉毛一把抓。
2、主数据识别
主数据的识别一般分为四个步骤：
第一步，确定主数据识别指标。
第二步，基于主数据识别识别，构建评分体系，确定指标权重。
第三步，根据业务调研和数据普查结果，确定主数据参评范围。
第四步，依据评分标准，识别出企业主数据。
主数据识别指标，主要从主数据的特征考量：
- 业务价值。主数据具备充足的业务价值。主数据描述企业最核心的数据，是企业最有价值的数据资产。
- 数据共享性。主数据一般是不同业务部门之间、不同业务系统之间高度共享的数据，如果数据只在一个系统使用，并且未来也不会共享给其他系统，一般不作为主数据管理。
- 实体独立性。主数据是不可拆分的数据实体，如产品、客户，是所有业务行为和交易的基础。
- 识别唯一性。在组织范围内同一主数据要求具有唯一的识别标志，如物料、客户都必须有唯一的编码。
- 相对稳定性。与交易数据相比主数据是相对稳定的，变化频率较低。变化频率较低并不意味着一成不变，例如：客商更名会引起客商主数据的变动、人员调动会引起人员主数据的变动等等。
- 长期有效性。主数据一般具有较长的生命周期，需要长期保存。
5.2 建体系
我国大多数企业的主数据现状普遍都是先污染、后治理的过程，主数据管理必然带来新的标准、体系的确立，和旧系统的改造。整个主数据建设过程是一个有破有立、无破不立的过程。这一过程设计大量的跨部门、跨条线、跨系统的沟通协调，同时也涉及不小的投资。为了不使投入的人力物力付之东流，在项目实施前期就应该规划好各项规章制度和组织架构。
1. 组织体系
有效的组织机构是项目成功的有力保证，为了达到项目预期目标，在项目开始之前对于组织及其责任分工做出规划是非常必要的。
主数据涉及的范围很广，牵涉到不同的业务部门和技术部门，是企业的全局大事，如何成立和成立什么样的组织应该依据企业本身的发展战略和目标来确定。
建立主数据管理组织目标是：统筹规划企业的数据战略；建立主数据标准规范体系、数据管理制主度和流程体系、数据运营和维护体系；依托主数据管理平台，实施主数据标准化落地、推广和运营。
在明确了组织机构的同时，还要明确主数据管理岗位，比如：主数据系统管理员、主数据填报员、主数据审核员、数据质量管理员、集成技术支持员等。主数据管理岗位可以兼职，也可以全职，根据企业实际情况而定。
2.标准体系
主数据分类和编码标准化。没有标准化就没有信息化，主数据分类和编码标准是主数据标准中的最基础的标准。
数据分类就是根据信息内容的属性或特征，将信息按一定的原则和方法进行区分和归类，并建立起一定的分类系统和排列顺序，以便管理和使用信息。
主数据编码就是在信息分类的基础上，将信息对象赋于有一定规律性的、易于计算机和人识别与处理的符号。
主数据模型标准化，根据前期的调研、梳理和评估，定义出每个主数据的元模型。明确主数据的属性组成、字段类型、长度、是否唯一，是否必填以及校验规则……。主数据元模型的设计不能贪大求全，要切合实际。推荐方法：抽取多系统、部门间的共性属性和核心属性，剔除掉单一业务属性。
主数据标准体系的建设要适合企业的业务，适应企业的发展。标准的建设不能“先入为主”更不能“直接照搬”。
3. 制度与流程体系
制度章程是确保对主数据管理进行有效实施的认责制度。建立主数据管理制度和流程体系是需要明确主数据的归口部门和岗位，明确岗位职责，明确每个主数据的申请、审批、变更、共享的流程。
数据从创建到流转要严格执行企业主数据标准和填报规范。
同时，做好数据运营工作，定期检查数据质量，进行数据的清洗和整合。实现企业数据质量的不断优化和提升。
制度和流程体系的建设是主数据成功实施的重要保障。
4.技术体系
主数据管理技术体系的建设应从应用层面和技术层面两个方面考虑。
应用层面主数据管理平台需具备元数据（数据模型管理）、数据管理、数据清洗、数据质量、数据集成、权限控制、数据关联分析，以及数据的映射（mapping）/转换（Transforming）/装载（loading）的能力。技术层面，重点考虑系统架构、接口规范、技术标准。
业内流行主数据平台更多定位的是数据管理和集成平台，一般采用SOA架构，提供服务总线（data service bus）功能。国内外90%以上的产品采用的是这种技术架构。
互联网行业的主数据则侧重于主数据的微服务，每个主数据都可以发布多个微服务，例如：会员主数据，提供的微服务包括注册、登录、注销、锁定等服务。
5. 安全体系
主数据安全体系建设包括几个方面：
网络安全。尤其是混合云下的数据安全是当前客户最关注的问题。这里建议基于混合云部署的主数据系统采用单向数据流控制，即只允许公有云数据向内流入，不允许私有云数据向外流出。
接口安全。即接口数据的传输安全。由于主数据解决的是异构系统的数据一致性问题，需要保证主数据在给异构系统同步数据的过程的数据安全。主数据平台须具备接口的访问控制和加密传输的能力。
应用安全。主数据平台的身份认证、访问控制、分级授权、安全审计功能是保障系统应用安全的重要功能。
数据安全。主数据平台提供的数据加密存储、加密传输、脱敏脱密功能，是保证主数据安全的重要措施。
5.3 接数据
接数据包括主数据的接入和接出。
主数据接入是将主数据从数据源系统汇集到主数据平台的过程。该过程需要对接入的数据进行清洗、转换、映射、去重、合并、加载……，通过一系列的数据加工和处理形成标准统一的主数据。
常用的数据的汇集方式：
ETL抽取，采用ETL工具的方式从数据源系统将数据采集到主数据库中。
文件传输，采用文件传输方式将文件中的数据导入到主数据库中。
消息推送，采用消息的方式从数据源系统将数据采集到主数据库中，一般需要借助ESB（企业服务总线）。
接口推送，采用接口方式从数据源系统将主数据采集到主数据库中，一般需要借助ESB（企业服务总线）。
内容爬虫，一般用于互联网的数据爬取，适用于社会化主数据的汇集。
主数据的接出，是将标准化的主数据分发共享给下游业务系统使用的过程。在主数据接出的过程中使用的技术与数据汇集技术基本一致。在企业实施主数据过程中，需要根据不同场景选择不同的集成方式。
定期数据共享，一般采用ETL或接口方式定期将主数据抽取到业务系统指定的数据表中。
实时数据共享，一般采用消息订阅的方式，通过数据接口将主数据推送给业务系统。
5.4 抓运营
主数据运营管理，包括：主数据管理，主数据推广、主数据质量、主数据变现等。
1、主数据管理
数据标准和管理规范的常态化贯彻。主数据管理主要是对主数据的新增、变更、使用等过程的规范，需要配合企业主数据管理的相关制度和流程，做到定岗定责、责任到人，从源头上控制好数据的质量，保证数据的唯一数据源和统一数据视图。
2、主数据推广
主数据推广是逐步将主数据推广到企业的各个业务中，包括线上、线下的业务。主数据的应用不仅需要推广各个相关的业务中，保证各业务系统的主数据一致性。对于线下的业务也应当与主数据保持一致。主数据推广对于单组织企业比较容易，对于集团型企业尤其是多业态集团是有一定难度的，企业应做好相应的推广策略和计划表。
3、主数据质量
主数据作为“黄金数据”是企业的核心数据资产，主数据质量的好坏决定了数据价值的高低。整个主数据运营过程，最核心的目标就是持续提升数据质量。主数据质量管理包括：主数据质量指标定义，主数据质量模型/算法，主数据质量核查，主数据质量整改，主数据质量报告，主数据质量考评等。
4、主数据变现
上文我们提到：主数据是企业的“黄金数据”，是企业的核心数据资产。既然是“资产”就一定有其变现的能力，主数据变现主要有以下几个方面：
① 整合协同、降本增效。
各系统主数据的标准统一，解决数据重复、不一致、不正确、不准确、不完整的问题，打通企业的采购、生产、制造、营销、财务管理等各个环节，大大提升业务之间协作的效率，减低由于数据不一致引起的沟通成本。
② 增加收入、提升盈利。
建立360°客户主数据视图，建立客户关系模型，支撑企业精准营销，提升盈利水平、增加销售收入。
③ 数据驱动、智能决策。
相比基于本能,假设,或认知偏见而做出的决策,基于证据的决策更可靠。通过数据驱动的方法,你将能够判断趋势,从而展开有效行动,帮助自己发现问题,推动创新或解决方案出现。
④ 数据 即服务 即资产。
一方面，可以通过主数据优化内部运营管理和客户服务水平；另一方面，通过对主数据进行匿名化和整合，结合各种不同的用户场景提供给客户或供应商，从而实现整个产业链的打通。
六、数据安全治理
数据安全治理可以分为数据资产梳理与敏感数据识别，数据安全认责，数据分类分级，数据安全授权。
1、数据梳理与识别。通过数据梳理，理清企业数据资产分布，同时要明确保密和敏感数据的分布情况，确定敏感数据的U/C矩阵。关于数据资源梳理，主要有：自顶向下的梳理IRP（信息资源规划）和BPM（业务流程管理）和需求驱动的自底向上梳理等方法。请参考《数据治理系列4：主数据管理实施四部曲概论》。
2、数据安全认责。推荐采用“谁生产、谁管理、谁负责”的数据认责原则进行数据归属权确认。我们往往会将数据安全主体部门认为是信息化部门，但事实上信息化部门只是信息化系统的实施者和维护者，数据安全治理要从源头抓起，数据的生产部门和使用部门有责任对数据的安全管理负责。
3、数据分类和分级。依据数据的来源、内容和用途对数据资产进行分类，根据已分类的数据资产由业务部门根据数据的价值、敏感程度、影响范围进行敏感分级，将分类的数据资产划分公开、内部、敏感等不同的敏感级别；对不同等级的数据分配给相应的用户角色，建立敏感分级数据与用户角色的访问控制矩阵。
4、数据的访问授权。根据业务场景，设计数据使用流程和安全防护策略，控制数据访问权限。例如：对于销售人员只需要拿到客户清单和给相应客户推荐的产品清单，对于客户身份证号等敏感就不需要看到了；对于物流人员只需要知道客户的名称、收货地址、联系方式，其他信息就不需要看到了；对于计划和生产人员只需要知道哪款产品卖得好，具体卖给了谁就无需知道了；对于数据分析人员可能需要知道的数据信息要多一些，但是对于一些敏感的、对数据分析无太大关联的数据也是不需要看的，例如客户的身份证号。在设计数据访问权限时，要结合数据安全等级并且要切合业务实际，将数据安全治理回归到业务中去，以达到数据使用的安全合规。
5、数据安全的全生命周期管理。确认了数据安全的责任主体之后是数据安全管理流程和制度的设计。数据的安全治理应贯穿于数据的整个生命周期，在数据的规划、设计、创建、存储、使用、销毁的各个阶段应设置相应的管控点和管理流程。
数据的规划和设计阶段，应对涉密、敏感数据进行识别、分类和分级，并定义数据安全保密控制的规则。数据创建阶段采用流程化控制机制进行审批审核，保障数据的安全生产。数据存储阶段可根据数据的安全等级不同进行分库、分表存储，对关键涉密或敏感进行加密存储。数据使用阶段要有相应的数据使用安全防护措施，例如：加密传输、脱密脱敏处理等。整个管理过程需要充分调动业务部门，通过业务流程把敏感信息的处理要求落到具体的业务环节中去。
数据安全治理的技术手段
不同的行业对于数据安全防控要求不同，安全防护的技术使用深度也不同。以下是根据笔者对数据安全管理技术的相关认知，给出的相应安全防护策略，欢迎数据安全方面的专家一起来讨论。
上图是一张系统安全架构。从图中我们看到数据安全涵盖了操作系统安全、网络安全、数据库安全、软件应用安全等。对于数据的安全治理，侧重点是对于数据使用过程的控制，使得数据安全合法的进行使用，所以管控的重点是在应用上。所以对于操作系统安全、网络安全和数据库安全，我们本次暂时不表。下面我们重点盘点下数据安全治理用到一些技术：
1、身份认证与访问控制
身份认证是在计算机及计算机网络系统中确认操作者身份的过程，从而确定该用户是否具有对某种资源的访问和使用权限，进而使计算机和网络系统的访问策略能够可靠、有效地执行，防止攻击者假冒合法用户获得资源的访问权限，保证系统和数据的安全，以及授权访问者的合法利益。
常用身份认证的技术包括：电子签名（CA）、USB-key（智能卡）、静态口令，动态口令、短信密码、人脸识别、指纹识别、虹膜识别、声音识别等。身份认证是为访问控制提供支撑，访问控制提供了不同身份用户访问不同信息资源提供了相应的安全策略。
2、数据申请及审核
对于企业关键信息的创建和变更需要符合企业相关的数据管理流程，建立数据申请、审批制度，对新增的数据或变更的数据进行合法性审批。与主数据管理不同的是，主数据的审批强调主数据的正确性、完整性，数据安全治理的数据审批重点强调关键数据的安全性。两个审批流程并不冲突，也可以在一个流程中完成以上这两个数据治理的审批目标。
3、数据的分级与授权
数据的分类、分级、授权是对敏感信息安全保护的重要手段。首先依据数据的来源、内容和用途对数据资产进行分类；其次，根据已分类的数据资产由业务部门根据数据的价值、敏感程度、影响范围进行敏感分级，将分类的数据资产划分公开、内部、敏感等不同的敏感级别；最后，对不同等级的数据分配给相应的用户角色，建立敏感分级数据与用户角色的访问控制矩阵。
4、数据脱敏技术
数据脱敏技术是解决数据模糊化的关键技术，简单的数据脱敏技术就是给数据打个“马赛克”，脱敏的过程数据的含义保持不变、数据类型不变、数据的关系不变。例如：如身份证、地址、姓名脱敏后依然需要是身份证、地址、姓名。
数据逆向脱敏，在 BI 分析或数据开放环境下， 用户信息等敏感性信息需要被脱敏；但对于重点关注的用户， 需要回到生产环境下时， 可以还原为真实的用户信息。
数据动态脱敏，在一些环境下，需要保持数据共享的及时性，但又要避免数据的泄露；因此需要对在不将数据重新生成一份脱敏副本的情况下提供给第三方。需要针对不同的用户，根据数据的共享和安全需要，对不同的数据集进行脱敏。
5、数据加密技术
数据加密技术是数据防窃取的一种安全防治技术，指将一个信息经过加密钥匙及加密函数转换，变成无意义的密文，而接收方则将此密文经过解密函数、解密钥匙还原成明文。按照网络分层，数据加密技术重点作用于网络层和存储层，所以数据加密又可以分为数据传输加密和数据存储加密。数据的发送方和接收方使用不同的密钥进行数据加解密。常用加密算法有：专用密钥、公开密钥、对称密钥、非对称密钥等。
6、数据安全审计
数据安全审计是通过记录用户对数据的所有访问和操作记录日志，并通过日志的分类统计和分析，提供数据访问报表，支持对数据的检索和分析，支持对用户的违规访问和危险操作进行告警。常见的数据安全审计内容包括：用户登录审计、用户访问审计、用户操作审计、数据交换审计……
五步实现成功的数据治理
总结来说，数据治理就是在下面这些方面做好管理。
公司架构可以参考这张图
1. 建立一个数据治理组织。数据治理研究所推荐建立一个数据治理委员会，负责评估各个数据用户的输入信息，建立覆盖全公司的数据管理策略，满足内部用户、外部用户甚至法律方面的各种需求。该委员会的成员应该囊括各个业务领域的利益相关者，确保各方需求都得到满足，所有类型的数据所有权均得到体现。安全专家也应成为委员会的一员。了解数据治理委员会的目标是什么，这一点很重要，因此，应该思考企业需要数据治理策略的原因，并清楚地加以说明。
2. 制定一个框架，将林林总总的数据需求容纳其中。这个框架必须确保各个部分被融合成一个整体，满足收集、存储、检索和安全要求。为此，企业必须清楚说明其端到端数据策略，以便设计一个覆盖所有要求和必要操作的框架。必须有计划地把各个部分结合起来，彼此支持，这有很多好处，比如在高度安全的环境中执行检索要求。合规性也需要专门的设计，成为框架的一部分，这样就可以追踪和报告监管问题。这个框架还包括日常记录和其他安全措施，能够对攻击发出早期预警。在使用数据前，对其进行验证，这也是框架的一部分。数据治理委员会应该了解框架的每个部分，明确其用途，以及它如何在数据的整个生命周期中发挥作用。
3. 试点数据策略。通常来说，一个策略应该先在小范围内推行，以便发现计划、框架和基础设施的缺陷，然后才在整个公司实行。
4. 拥有一个与时俱进的数据治理组织。数据治理委员会应该与时俱进，因为随着数据治理策略延伸到新的业务领域，肯定需要对策略进行调整。而且，随着技术的发展，数据策略也应该发展，与安全形势、数据分析方法以及数据管理工具等保持同步。
5. 知道什么是成功的数据策略。确立成功标准，以便衡量进展。制定数据管理目标，有助于确定成功的重要指标，进而确保数据治理策略朝着你希望和需要的方向前进。
标签：业务,标准,谈谈,数据管理,治理,数据,数据安全 From： https://www.cnblogs.com/East-fence/p/18135272