做数据治理时有五个词几乎绕不开元数据、数据元、元模型、数据字典、数据模型。它们看起来都在回答“数据是什么”但真正解决的问题并不在同一个层次。有人把数据库里的字段直接称为数据元有人认为做了一份数据字典就等于完成了元数据管理还有人看到“元模型”和“数据模型”只差一个“元”字就把两者当成一回事。如果只是概念考试混淆一下影响不大。但放到企业数据治理项目里问题会立刻变得现实到底治理什么对象标准应该约束谁哪些信息需要自动采集哪些需要业务人员维护最后这些治理成果又应该落到哪里所以理解这五个概念不建议从定义开始死记而要先抓住它们各自解决的问题元数据负责描述数据数据元负责统一业务语义元模型规定这些描述怎么组织数据字典负责把数据说明提供给使用者数据模型负责设计业务数据本身的结构。在正式展开之前我整理了一份适合数据治理、数仓建设场景参考的《数据仓库建设解决方案》里面涉及数据集成、数仓规划、治理和数据应用等内容正在做相关项目的可以参考。需要自取https://s.fanruan.com/ahhl0复制到浏览器一、元数据不是“字段说明”而是数据的上下文元数据最常见的解释是描述数据的数据。例如数据库中有一个字段customer_id里面保存的“100001”“100002”属于真正的业务数据。但围绕这个字段还有另一组信息中文名称客户编号数据类型VARCHAR长度32来源系统CRM来源表customer_info业务定义客户唯一身份标识更新周期每日一次责任部门客户运营部被哪些任务、指标和报表引用。这些信息才属于元数据。为什么企业需要管理它们因为一条没有上下文的数据实际上很难被正确使用。比如看到amt 128000你并不知道它到底是合同金额、订单金额、开票金额还是确认收入也不知道是否含税、单位是什么、什么时候更新。元数据真正做的事情是给数据补上“身份、来源、加工过程和使用关系”。实际治理中元数据通常可以分成三类。技术元数据描述数据在技术系统中的结构和流转例如数据库、表、字段、字段类型、接口、ETL任务、调度依赖和上下游血缘。业务元数据描述数据的业务含义例如指标定义、统计口径、业务术语、业务负责人和归属部门。管理与运行元数据描述数据的管理状态例如权限、质量结果、更新时间、责任人、访问频率和生命周期状态。所以元数据治理真正解决的是数据能不能被理解、查找、追溯和管理。而在实际工作中元数据往往是在排查问题时最有存在感。比如销售主题表突然少了一批数据开发人员通常会往上游一路找源表有没有数据、同步任务是否执行、中间转换逻辑有没有修改再继续确认下游哪些汇总表和指标已经受到影响。这类排查本质上就是在使用元数据和血缘关系。企业的数据同步、加工任务如果集中在FineDataLink中任务、表和字段之间的依赖会伴随日常数据开发逐步形成。于是“这张表从哪里来、经过哪些处理、最终流向哪里”就不再只是项目交付时整理的一份文档而是数据运行过程中持续产生的信息。二、数据元不是某个字段而是字段背后的标准定义数据元和字段是最容易混淆的一组概念。假设三个系统中分别存在CRMcust_typeERPcustomer_category数仓customer_type三个字段名字不同但表达的可能都是同一个业务概念客户类型。如果企业只是把这三个字段登记下来记录它们在哪张表、是什么类型这属于元数据管理。如果进一步规定标准名称客户类型定义用于表示客户所属业务分类数据类型字符型长度2值域01个人、02企业、03其他责任部门客户管理部相关系统统一采用该分类标准。这时候形成的才更接近治理意义上的数据元。因此两者最关键的区别是字段是一个业务概念在某个系统里的具体实现数据元是这个业务概念跨系统使用时的统一标准。比如“客户编号”这个数据元在CRM里可能叫cust_id在ERP里叫customer_code在主数据系统里又叫mdm_customer_no。物理上是三个字段语义上却应该对应同一个标准。所以数据元治理真正要解决的并不是“企业到底有多少字段”而是“这些字段里哪些其实表达的是同一件事情”进一步还要统一名称、数据类型、长度、格式、单位、编码和值域。这也是为什么一些企业做了几十万条“数据元标准”最后仍然很难使用。如果只是把数据库字段批量导出来再给每个字段补一个中文名称本质上做的是字段盘点并没有完成真正的数据元标准化。三、元模型规定的是“治理对象之间怎样建立关系”元模型往往是五个概念中最抽象的一个。理解它可以再往上一层问既然元数据是在描述数据那么谁规定元数据平台里应该管理哪些对象例如企业准备管理系统数据库数据表字段数据任务指标报表。光列出对象还不够还需要规定它们之间的关系系统包含数据库数据库包含数据表数据表包含字段数据任务读取一张表并生成另一张表指标引用字段报表引用指标。除此之外还要规定一张表应该记录哪些属性一个字段应该记录哪些属性指标和字段之间允许建立什么关系这套关于“管理什么对象、对象有哪些属性、对象之间怎样关联”的规则就是元模型。所以元模型负责定义框架元数据负责往框架里填具体内容。例如元模型规定“每张数据表都需要记录所属系统、负责人和上下游关系。”那么具体某张销售订单表属于ERP、负责人是谁、下游进入哪张主题表这些具体内容就是元数据。元模型为什么重要因为很多治理项目推进到一定阶段都会出现同一个问题东西采上来了却很难真正放到一起。数据团队管理表和字段调度平台管理任务BI团队管理指标和报表业务部门又维护自己的业务术语。每一块单独看都有内容真正想串起来时却发现不同团队连“对象是什么”都没有统一。这时候治理工作的重点就会从“继续采更多数据”转向“先把对象和关系理清”。例如FineDataLink中已经存在数据源、同步任务、加工任务和目标表之间的实际数据流转关系在此基础上再把业务定义、标准、负责人等治理信息对应到具体对象技术链路和业务语义才有可能逐步连接起来。元模型决定的本质上就是企业准备按照什么结构来管理这张数据关系网。四、数据字典给数据使用者看的“说明书”数据字典是五个概念里相对容易理解的一个。例如字段中文名称类型业务说明customer_id客户编号VARCHAR客户唯一编号customer_name客户名称VARCHAR客户登记名称customer_type客户类型VARCHAR客户业务分类这就是典型的数据字典。它主要回答这张表有哪些字段这些字段是什么意思使用时应该注意什么但要注意数据字典不等于全部元数据。因为元数据还可能包括数据血缘加工任务权限数据质量结果责任人使用热度指标引用关系生命周期。所以更准确地说元数据是一整套关于数据的描述信息数据字典是从这些信息中整理出来、面向查询和使用的一种呈现方式。这个区别到了分析人员真正找数据时会非常明显。例如要分析销售收入搜索后发现三个字段sales_amountrevenue_amountincome_amt如果三条说明都只写着“销售金额”那这份数据字典实际上并没有解决问题。分析人员真正需要继续确认的是到底按订单还是按出库统计是否含税退款怎么处理数据从哪个系统来什么时候更新公司正式经营分析最终采用的是哪一个口径所以数据字典真正需要承接的不只是字段的中文翻译还要尽可能把定义、来源和加工背景带出来。如果相关字段来自FineDataLink中已经运行的数据任务那么查询字段说明时就可以继续沿着已有的数据来源和加工关系核对它是怎样形成的。此时数据字典回答的就不只是“这个字段叫什么”而开始延伸到“这份数据为什么是这个结果”。真正能被业务和分析人员使用的数据字典核心不是收录了多少字段而是能不能帮助人判断一份数据该不该用、应该怎么用。五、数据模型设计的是业务数据本身的结构最后一个概念是数据模型。数据模型关注的是真实业务应该怎样被组织成数据结构。例如一个零售企业存在客户商品门店订单订单明细。建模时需要考虑一个客户可以有多少订单一个订单包含多少商品商品属于哪个品类订单金额放在哪一层客户、商品和门店怎样与交易事实关联这些都是数据模型解决的问题。通常还会进一步分成三个层次。概念模型站在业务视角识别核心对象以及它们之间的关系。例如客户—订单—商品。这一阶段主要回答业务世界里有哪些关键对象逻辑模型继续定义实体、属性、主键和关联关系。例如订单包含订单编号、客户编号、下单时间、订单金额、订单状态。物理模型最终落实到数据库。包括表名、字段名、数据类型、主键、索引、分区和存储方式等。因此数据模型和元模型虽然只差一个“元”实际解决的问题完全不同数据模型设计业务数据本身元模型设计描述和管理这些数据的规则。数据模型面对的对象可能是客户、商品、订单。元模型面对的对象则可能是系统、表、字段、任务、指标。在真实数仓项目里数据模型画完也并不意味着模型已经落地。例如团队设计了一张客户主题表确定了客户编号、名称、等级、区域等字段进入开发阶段之后真正需要处理的还有CRM和ERP客户编码怎样统一客户等级到底取哪个系统重复客户怎么合并每天采用全量还是增量更新字段变化以后下游怎么同步调整也就是说数据模型回答“最后要形成什么结构”数据开发回答“这些数据究竟怎样形成”。在FineDataLink中搭建同步和加工任务时源系统数据会按照清洗、转换、映射规则进入目标表模型里的字段也就逐渐对应到具体的数据来源和加工步骤。后续某个客户等级出现异常排查就会重新回到这些实际的数据处理环节。这也是数据模型真正落地时必须完成的一步从设计出来的表结构走到真实运行的数据链路。六、把五个概念放到一个场景里就彻底清楚了假设企业准备建设一套“客户主题数据”。首先业务和数据团队要确定企业有哪些客户对象客户和订单是什么关系客户主题需要哪些属性这是在做数据模型。模型最终形成一张客户表其中存在customer_id VARCHAR(32)这个字段叫什么、是什么类型、来自哪个系统、由哪个任务加工、下游被哪些对象引用这些属于元数据。企业进一步规定客户编号必须全集团唯一统一使用32位字符由主数据系统生成。这属于数据元标准。与此同时企业还需要规定系统、表、字段、任务、指标分别是什么治理对象它们分别记录哪些属性对象之间允许建立哪些关系。这套结构属于元模型。最后把数据使用者经常需要查询的表、字段、中文名称、业务定义、统计口径和来源整理成查询入口。这就是数据字典。所以五个概念并不是五套彼此独立的东西而是在不同层次回答不同的问题数据模型负责把业务变成数据结构数据元负责让关键业务概念按照统一标准表达元数据负责记录数据的上下文、来源和运行关系元模型规定这些治理信息应该怎样组织数据字典再把使用者真正需要的信息提供出来。真正成熟的数据治理也不是分别做完五份Excel或者上线五个彼此孤立的模块。而是让它们形成一条完整链路模型里的字段能够对应数据元标准数据开发过程持续产生和更新元数据元数据按照统一的元模型组织最后再通过数据字典被开发、分析和业务人员使用。当这条链路真正建立起来以后企业治理的就不再是一堆孤立的字段、标准和文档而是一套随着数据生产、变化和使用持续运行的数据管理体系。分清这五个概念的真正意义也不是为了记住五个名词而是为了知道每一种数据治理工作究竟在治理什么、解决哪一层问题以及最终应该落到哪个实际工作环节。
做数据治理时有五个词几乎绕不开元数据、数据元、元模型、数据字典、数据模型。它们看起来都在回答“数据是什么”但真正解决的问题并不在同一个层次。有人把数据库里的字段直接称为数据元有人认为做了一份数据字典就等于完成了元数据管理还有人看到“元模型”和“数据模型”只差一个“元”字就把两者当成一回事。如果只是概念考试混淆一下影响不大。但放到企业数据治理项目里问题会立刻变得现实到底治理什么对象标准应该约束谁哪些信息需要自动采集哪些需要业务人员维护最后这些治理成果又应该落到哪里所以理解这五个概念不建议从定义开始死记而要先抓住它们各自解决的问题元数据负责描述数据数据元负责统一业务语义元模型规定这些描述怎么组织数据字典负责把数据说明提供给使用者数据模型负责设计业务数据本身的结构。在正式展开之前我整理了一份适合数据治理、数仓建设场景参考的《数据仓库建设解决方案》里面涉及数据集成、数仓规划、治理和数据应用等内容正在做相关项目的可以参考。需要自取https://s.fanruan.com/ahhl0复制到浏览器一、元数据不是“字段说明”而是数据的上下文元数据最常见的解释是描述数据的数据。例如数据库中有一个字段customer_id里面保存的“100001”“100002”属于真正的业务数据。但围绕这个字段还有另一组信息中文名称客户编号数据类型VARCHAR长度32来源系统CRM来源表customer_info业务定义客户唯一身份标识更新周期每日一次责任部门客户运营部被哪些任务、指标和报表引用。这些信息才属于元数据。为什么企业需要管理它们因为一条没有上下文的数据实际上很难被正确使用。比如看到amt 128000你并不知道它到底是合同金额、订单金额、开票金额还是确认收入也不知道是否含税、单位是什么、什么时候更新。元数据真正做的事情是给数据补上“身份、来源、加工过程和使用关系”。实际治理中元数据通常可以分成三类。技术元数据描述数据在技术系统中的结构和流转例如数据库、表、字段、字段类型、接口、ETL任务、调度依赖和上下游血缘。业务元数据描述数据的业务含义例如指标定义、统计口径、业务术语、业务负责人和归属部门。管理与运行元数据描述数据的管理状态例如权限、质量结果、更新时间、责任人、访问频率和生命周期状态。所以元数据治理真正解决的是数据能不能被理解、查找、追溯和管理。而在实际工作中元数据往往是在排查问题时最有存在感。比如销售主题表突然少了一批数据开发人员通常会往上游一路找源表有没有数据、同步任务是否执行、中间转换逻辑有没有修改再继续确认下游哪些汇总表和指标已经受到影响。这类排查本质上就是在使用元数据和血缘关系。企业的数据同步、加工任务如果集中在FineDataLink中任务、表和字段之间的依赖会伴随日常数据开发逐步形成。于是“这张表从哪里来、经过哪些处理、最终流向哪里”就不再只是项目交付时整理的一份文档而是数据运行过程中持续产生的信息。二、数据元不是某个字段而是字段背后的标准定义数据元和字段是最容易混淆的一组概念。假设三个系统中分别存在CRMcust_typeERPcustomer_category数仓customer_type三个字段名字不同但表达的可能都是同一个业务概念客户类型。如果企业只是把这三个字段登记下来记录它们在哪张表、是什么类型这属于元数据管理。如果进一步规定标准名称客户类型定义用于表示客户所属业务分类数据类型字符型长度2值域01个人、02企业、03其他责任部门客户管理部相关系统统一采用该分类标准。这时候形成的才更接近治理意义上的数据元。因此两者最关键的区别是字段是一个业务概念在某个系统里的具体实现数据元是这个业务概念跨系统使用时的统一标准。比如“客户编号”这个数据元在CRM里可能叫cust_id在ERP里叫customer_code在主数据系统里又叫mdm_customer_no。物理上是三个字段语义上却应该对应同一个标准。所以数据元治理真正要解决的并不是“企业到底有多少字段”而是“这些字段里哪些其实表达的是同一件事情”进一步还要统一名称、数据类型、长度、格式、单位、编码和值域。这也是为什么一些企业做了几十万条“数据元标准”最后仍然很难使用。如果只是把数据库字段批量导出来再给每个字段补一个中文名称本质上做的是字段盘点并没有完成真正的数据元标准化。三、元模型规定的是“治理对象之间怎样建立关系”元模型往往是五个概念中最抽象的一个。理解它可以再往上一层问既然元数据是在描述数据那么谁规定元数据平台里应该管理哪些对象例如企业准备管理系统数据库数据表字段数据任务指标报表。光列出对象还不够还需要规定它们之间的关系系统包含数据库数据库包含数据表数据表包含字段数据任务读取一张表并生成另一张表指标引用字段报表引用指标。除此之外还要规定一张表应该记录哪些属性一个字段应该记录哪些属性指标和字段之间允许建立什么关系这套关于“管理什么对象、对象有哪些属性、对象之间怎样关联”的规则就是元模型。所以元模型负责定义框架元数据负责往框架里填具体内容。例如元模型规定“每张数据表都需要记录所属系统、负责人和上下游关系。”那么具体某张销售订单表属于ERP、负责人是谁、下游进入哪张主题表这些具体内容就是元数据。元模型为什么重要因为很多治理项目推进到一定阶段都会出现同一个问题东西采上来了却很难真正放到一起。数据团队管理表和字段调度平台管理任务BI团队管理指标和报表业务部门又维护自己的业务术语。每一块单独看都有内容真正想串起来时却发现不同团队连“对象是什么”都没有统一。这时候治理工作的重点就会从“继续采更多数据”转向“先把对象和关系理清”。例如FineDataLink中已经存在数据源、同步任务、加工任务和目标表之间的实际数据流转关系在此基础上再把业务定义、标准、负责人等治理信息对应到具体对象技术链路和业务语义才有可能逐步连接起来。元模型决定的本质上就是企业准备按照什么结构来管理这张数据关系网。四、数据字典给数据使用者看的“说明书”数据字典是五个概念里相对容易理解的一个。例如字段中文名称类型业务说明customer_id客户编号VARCHAR客户唯一编号customer_name客户名称VARCHAR客户登记名称customer_type客户类型VARCHAR客户业务分类这就是典型的数据字典。它主要回答这张表有哪些字段这些字段是什么意思使用时应该注意什么但要注意数据字典不等于全部元数据。因为元数据还可能包括数据血缘加工任务权限数据质量结果责任人使用热度指标引用关系生命周期。所以更准确地说元数据是一整套关于数据的描述信息数据字典是从这些信息中整理出来、面向查询和使用的一种呈现方式。这个区别到了分析人员真正找数据时会非常明显。例如要分析销售收入搜索后发现三个字段sales_amountrevenue_amountincome_amt如果三条说明都只写着“销售金额”那这份数据字典实际上并没有解决问题。分析人员真正需要继续确认的是到底按订单还是按出库统计是否含税退款怎么处理数据从哪个系统来什么时候更新公司正式经营分析最终采用的是哪一个口径所以数据字典真正需要承接的不只是字段的中文翻译还要尽可能把定义、来源和加工背景带出来。如果相关字段来自FineDataLink中已经运行的数据任务那么查询字段说明时就可以继续沿着已有的数据来源和加工关系核对它是怎样形成的。此时数据字典回答的就不只是“这个字段叫什么”而开始延伸到“这份数据为什么是这个结果”。真正能被业务和分析人员使用的数据字典核心不是收录了多少字段而是能不能帮助人判断一份数据该不该用、应该怎么用。五、数据模型设计的是业务数据本身的结构最后一个概念是数据模型。数据模型关注的是真实业务应该怎样被组织成数据结构。例如一个零售企业存在客户商品门店订单订单明细。建模时需要考虑一个客户可以有多少订单一个订单包含多少商品商品属于哪个品类订单金额放在哪一层客户、商品和门店怎样与交易事实关联这些都是数据模型解决的问题。通常还会进一步分成三个层次。概念模型站在业务视角识别核心对象以及它们之间的关系。例如客户—订单—商品。这一阶段主要回答业务世界里有哪些关键对象逻辑模型继续定义实体、属性、主键和关联关系。例如订单包含订单编号、客户编号、下单时间、订单金额、订单状态。物理模型最终落实到数据库。包括表名、字段名、数据类型、主键、索引、分区和存储方式等。因此数据模型和元模型虽然只差一个“元”实际解决的问题完全不同数据模型设计业务数据本身元模型设计描述和管理这些数据的规则。数据模型面对的对象可能是客户、商品、订单。元模型面对的对象则可能是系统、表、字段、任务、指标。在真实数仓项目里数据模型画完也并不意味着模型已经落地。例如团队设计了一张客户主题表确定了客户编号、名称、等级、区域等字段进入开发阶段之后真正需要处理的还有CRM和ERP客户编码怎样统一客户等级到底取哪个系统重复客户怎么合并每天采用全量还是增量更新字段变化以后下游怎么同步调整也就是说数据模型回答“最后要形成什么结构”数据开发回答“这些数据究竟怎样形成”。在FineDataLink中搭建同步和加工任务时源系统数据会按照清洗、转换、映射规则进入目标表模型里的字段也就逐渐对应到具体的数据来源和加工步骤。后续某个客户等级出现异常排查就会重新回到这些实际的数据处理环节。这也是数据模型真正落地时必须完成的一步从设计出来的表结构走到真实运行的数据链路。六、把五个概念放到一个场景里就彻底清楚了假设企业准备建设一套“客户主题数据”。首先业务和数据团队要确定企业有哪些客户对象客户和订单是什么关系客户主题需要哪些属性这是在做数据模型。模型最终形成一张客户表其中存在customer_id VARCHAR(32)这个字段叫什么、是什么类型、来自哪个系统、由哪个任务加工、下游被哪些对象引用这些属于元数据。企业进一步规定客户编号必须全集团唯一统一使用32位字符由主数据系统生成。这属于数据元标准。与此同时企业还需要规定系统、表、字段、任务、指标分别是什么治理对象它们分别记录哪些属性对象之间允许建立哪些关系。这套结构属于元模型。最后把数据使用者经常需要查询的表、字段、中文名称、业务定义、统计口径和来源整理成查询入口。这就是数据字典。所以五个概念并不是五套彼此独立的东西而是在不同层次回答不同的问题数据模型负责把业务变成数据结构数据元负责让关键业务概念按照统一标准表达元数据负责记录数据的上下文、来源和运行关系元模型规定这些治理信息应该怎样组织数据字典再把使用者真正需要的信息提供出来。真正成熟的数据治理也不是分别做完五份Excel或者上线五个彼此孤立的模块。而是让它们形成一条完整链路模型里的字段能够对应数据元标准数据开发过程持续产生和更新元数据元数据按照统一的元模型组织最后再通过数据字典被开发、分析和业务人员使用。当这条链路真正建立起来以后企业治理的就不再是一堆孤立的字段、标准和文档而是一套随着数据生产、变化和使用持续运行的数据管理体系。分清这五个概念的真正意义也不是为了记住五个名词而是为了知道每一种数据治理工作究竟在治理什么、解决哪一层问题以及最终应该落到哪个实际工作环节。
