很多企业一开始做数据治理都会碰到同一个问题概念越来越多。元数据、主数据、数据质量、数据集成、数据标准、数据资产、数据血缘……每个词单独拿出来好像都能解释两句。可真正到了项目里很快就会乱客户编码不一致到底是主数据问题还是数据质量问题报表数字错了是源系统的问题还是数据同步的问题做了数据集成是不是数据治理就已经完成一半元数据又为什么总会和数据集成、数据质量扯上关系问题就在于很多人是把这些概念拆开学的。但企业里的数据从来不是拆开运行的。一条订单从业务系统产生到进入数仓、形成指标、最终出现在经营报表里中间一定会同时经历对象识别、字段定义、数据同步、质量检查、加工转换。所以真正理解元数据、主数据、数据质量和数据集成不能只背定义而要把它们放进同一条数据链路里看。正式展开之前我整理了一份《数据仓库建设解决方案》里面涉及数据治理、数据集成、数仓建设等内容。如果你最近也在梳理企业的数据体系可以先存下来需要自取https://s.fanruan.com/7igmg复制到浏览器下面就顺着一条真实的数据链路把这四者一次理顺。一、先别急着分概念先看它们分别解决什么问题可以先记住四句话元数据解决这是什么数据主数据解决这些数据描述的到底是谁数据质量解决这些数据到底可不可信数据集成解决这些数据怎么从一个地方流到另一个地方看起来各管一块但真实项目里它们几乎不可能独立运行。假设集团现在要做“客户收入分析”。CRM里有客户信息ERP里有订单财务系统里有开票、回款售后系统里还有服务记录。第一步就会碰到一个问题CRM里的“A科技”和ERP里的“A科技有限公司”是不是同一家企业这是主数据问题。接着还要确认ERP里的customer_id到底代表什么“销售额”按下单时间、发货时间还是开票时间统计这是元数据问题。再往后还要检查客户编号有没有为空订单有没有重复金额有没有异常系统之间的数据能不能对应这是数据质量问题。最后才是把这些系统中的数据持续汇总起来。这一步才进入数据集成。所以真正的数据治理从来不是四个平台并排摆在那里而是一条连续的数据生产过程。真正落到项目里这些定义最终都要变成可以执行的数据处理规则。不同系统的数据接进来以后哪些字段需要映射、哪些数据要转换、多久更新一次、发生异常以后怎么处理都需要落到具体任务里。FineDataLink 5.0可以把数据库、文件、API等不同来源接到同一套数据开发和同步流程中前面梳理好的规则也就能顺着数据链路持续执行而不是停留在文档和方案里。所以很多数据治理项目真正拉开差距的地方就在这里规则有没有进入日常的数据生产过程。二、元数据解决的不是“有什么字段”而是企业能不能理解自己的数据很多人对元数据的理解还停留在表名、字段名、字段类型。这些当然属于元数据但只是最基础的一层。真正的数据体系里元数据至少要回答四类问题。第一类技术元数据一张表在哪里属于哪个数据库有哪些字段字段类型是什么主键是什么多久更新一次这些信息描述的是数据的技术结构。第二类业务元数据customer_id到底代表客户主体、客户账户还是交易对象“销售收入”到底含不含税“活跃客户”按照30天、90天还是自然月定义很多企业所谓的“指标口径不一致”根源其实并不在报表工具而是业务元数据没有说清楚。同样叫“销售额”A部门按订单金额算B部门按开票金额算C部门又扣掉退款以后计算。名字相同不代表含义相同。第三类管理元数据这张表归哪个部门负责出现数据问题找谁哪些人可以查看哪些字段属于敏感数据保存周期多久这些解决的是数据责任和管理边界。第四类血缘元数据这往往是最容易被忽视的一层。一张利润报表里的“毛利率”到底来自哪张指标表指标表依赖哪些明细数据明细数据又来自哪个业务系统如果上游某个字段被修改会影响多少任务、指标和报表企业数据量小的时候开发人员可能还能凭经验记住这些关系。但当数据源增加到几十个、上百个任务发展到几千个以后再靠微信群、Excel和个人记忆维护基本一定会失控。所以元数据真正成熟以后解决的是企业能不能知道自己有什么数据、数据是什么意思、从哪里来、流向哪里、谁负责。它相当于给企业整个数据体系建立了一份持续更新的说明书 地图 责任清单。三、主数据核心不是建主表而是确定“同一个业务对象”主数据最容易被误解成建一张客户表、商品表、供应商表。其实远远不够。假设同一家供应商采购系统里叫上海华明科技有限公司财务系统里叫上海华明科技合同系统记录的是统一社会信用代码。供应链系统又有自己的一套供应商编号。如果这些数据直接汇总系统很可能把它们识别成多个供应商。后果绝不只是“重复了一条数据”。采购金额可能被拆开应付款和合同无法准确匹配供应商集中度算错集团统一采购也很难分析。所以主数据真正解决的是现实世界里的同一个对象在不同系统里如何被认成同一个。这里至少包含五个问题唯一标识是什么客户到底用客户编码、统一社会信用代码还是其他ID识别哪个系统是权威来源客户名称以CRM为准还是ERP为准不同系统编码怎么映射A系统里的001如何对应B系统里的KH2026001发生冲突以后听谁的同一家供应商两个系统里的地址不同到底哪一份有效新增、修改、合并、停用以后怎么同步注意最后一个问题。很多企业把客户、商品、供应商主数据整理完以后就觉得治理已经完成。但真正的难点恰恰从这里开始。今天客户编码刚刚整理一致明天CRM新增一批客户后天ERP调整组织归属再过几天又有一家新公司上线。如果后续还靠人工导出、匹配、合并、覆盖原来整理好的主数据很快又会失效。所以主数据一定会继续碰到分发和同步。这时候FineDataLink 5.0可以把已经确定的客户映射、组织关系和字段转换规则接进同步任务。源系统发生新增或变更以后对应数据继续按照既定规则向下游更新主数据治理才不会停在“一次性清洗”这一步。这里其实可以把两者的边界记得很清楚主数据负责决定“谁是谁”数据集成负责把这个结果持续送到需要它的地方。四、数据质量真正要管的不是“脏数据”而是错误怎么产生、怎么传播“数据质量”也经常被理解成发现空值补一下发现重复去一下格式错了改一下。这只能算数据清洗。企业数据一旦复杂起来只做事后清洗成本一定会越来越高。因为很多错误并不会停在源系统里。它会沿着整条数据链路持续往后传播。假设ERP里一个客户编码填错了。同步到ODS以后没有发现进入DWD继续加工再进入指标层最后十几张经营报表都引用了这个结果。直到财务发现收入异常才开始往回查。这时候问题已经从一条错误数据变成一串错误任务 一批错误指标 多张错误报表。所以质量治理真正应该关注的至少有六个维度完整性该有的数据有没有缺失订单号、客户编码、金额等关键字段是否为空准确性数据值本身是否正确数量、金额、日期、状态有没有明显异常唯一性同一个客户、订单、商品是不是被重复记录一致性同一个业务对象在不同系统里的状态是否冲突及时性昨天的数据今天下午才进数仓还能不能支持晨会经营分析关联性订单有没有对应客户明细有没有对应主表上下游数据能不能正确关联更重要的一点是必须判断问题发生在哪一层。手机号为空可能是业务录入问题CRM和ERP客户状态不同可能是同步问题客户重复可能涉及主数据源端100万条、目标只有98万条则更接近链路完整性问题。如果所有问题最终都被统一归类成“数据质量不好”根本无法真正整改。所以成熟的数据质量管理一定要往数据生产过程前移。在FineDataLink 5.0里同步、加工之后的数据可以继续进入检测环节对完整性、一致性等规则进行检查如果任务结果出现异常也可以结合具体链路继续定位。这样质量治理就不需要等到业务人员发现报表异常以后再临时拉人排查。真正有效的质量闭环应该是定义规则 → 自动检测 → 发现异常 → 定位来源 → 处理问题 → 验证结果 → 沉淀规则。做到这一步企业治理的才不再只是某一批“脏数据”。真正被治理的是产生错误、传播错误的机制。五、数据集成难点从来不是A搬到B而是变化以后还能不能稳定运行数据集成看起来最好理解。ERP的数据同步到数仓CRM的数据汇总到分析平台接口数据定时拉取MySQL同步到ClickHouse。表面看起来就是A → B。但真正做过项目以后就会发现“把数据搬过去”可能只是最容易的一步。第一层是来源不同。数据库、API、文件、ERP、CRM、MES、WMS、大数据平台本身就是完全不同的技术体系。第二层是数据变化频率不同。组织架构一个月才变化几次订单每天新增几百万条库存一分钟内可能发生几十次变化。自然不应该全部使用同一种同步方式。第三层是变化类型不同。新增数据怎么处理修改数据怎么处理删除数据怎么同步源表增加字段怎么办字段类型发生变化怎么办第四层是任务中断以后怎么办。同步到一半失败是全部重跑还是从断点继续如果重复执行会不会造成重复数据第五层是上下游依赖怎么处理。订单任务没跑完收入模型该不该启动上游数据晚到下游任务要不要等待目标表异常以后报表是不是还继续刷新所以成熟的数据集成体系真正需要考虑的是连接、采集、同步、转换、调度、异常恢复、一致性检查和运维。真正搭这类链路时FineDataLink 5.0里的不同任务方式就会对应不同的数据变化节奏低频数据按周期同步持续变化的数据进入实时链路中间再衔接字段转换、任务依赖和异常处理。企业数据源越来越多以后也不需要每接一个系统就重新维护一套独立脚本。做到后面衡量一条数据链路是否可靠的标准也会发生变化。最开始可能只是看数据有没有过去再往后必须继续看有没有漏有没有重复延迟多少失败以后能不能恢复源系统结构发生变化下游能不能及时发现源端和目标端的数据最终能不能对上从“搬数据”走到这里才真正进入企业级数据集成。六、四者真正的关系可以看成一条治理链把前面的内容放在一起其实可以形成一条非常清楚的逻辑。第一步先确定业务对象客户、商品、供应商、组织、员工……先搞清楚企业最核心的业务对象到底是谁。这是主数据。第二步再描述这些数据字段是什么意思来源在哪里谁负责更新频率是什么上下游有哪些依赖这是元数据。第三步定义什么叫“正确”哪些字段不能为空哪些编码必须唯一不同系统之间怎么保持一致数据应该什么时候到这是数据质量。第四步让数据按照规则持续流动把不同系统接起来根据业务时效要求完成采集、同步、转换和交付。这是数据集成。但现实世界不会停在第四步。业务每天都在变化。新客户出现新商品上线组织架构调整字段增加系统替换指标口径修改。于是原来的治理逻辑又要跟着发生变化元数据更新 → 主数据调整 → 质量规则修改 → 集成任务变化。所以这四者并不是一条做完就结束的直线。它更接近一个循环定义对象↓描述数据↓制定规则↓连接数据↓检查结果↓发现问题↓调整规则↓再次进入数据生产过程这也是为什么真正成熟的数据治理不会把元数据、主数据、数据质量、数据集成完全割裂成四个互不相关的项目。因为企业真正要治理的本来就是数据从产生、变化、流转到最终被使用的整个生命周期。写在最后如果还是觉得这几个概念容易混可以记住一个最简单的比喻。主数据是“身份证”。解决客户、商品、供应商到底是谁。元数据是“说明书 地图”。告诉你数据是什么、在哪里、从哪里来、到哪里去。数据质量是“质检体系”。判断数据是否完整、准确、一致、及时。数据集成是“运输网络”。让不同系统中的数据按照规则持续流动。真正需要警惕的是把这四件事分别做成四座孤岛。只做数据集成可能只是把错误数据搬得更快只做主数据没有持续同步机制统一结果很快又会失效只做质量检查没有元数据和血缘发现问题以后依然难以定位只做元数据盘点却没有真实的数据生产链路最后很容易变成一份没人维护的目录。所以企业建设数据体系时真正应该追问的并不是“元数据、主数据、质量、集成到底应该先买哪个平台”而是一个数据对象从业务系统产生以后能不能被正确识别、准确解释、持续检查并按照统一规则稳定流向真正需要它的地方当这条链路真正跑起来以后元数据、主数据、数据质量和数据集成才不再是四个概念。它们共同构成的才是一套真正能够持续运转的数据体系。
很多企业一开始做数据治理都会碰到同一个问题概念越来越多。元数据、主数据、数据质量、数据集成、数据标准、数据资产、数据血缘……每个词单独拿出来好像都能解释两句。可真正到了项目里很快就会乱客户编码不一致到底是主数据问题还是数据质量问题报表数字错了是源系统的问题还是数据同步的问题做了数据集成是不是数据治理就已经完成一半元数据又为什么总会和数据集成、数据质量扯上关系问题就在于很多人是把这些概念拆开学的。但企业里的数据从来不是拆开运行的。一条订单从业务系统产生到进入数仓、形成指标、最终出现在经营报表里中间一定会同时经历对象识别、字段定义、数据同步、质量检查、加工转换。所以真正理解元数据、主数据、数据质量和数据集成不能只背定义而要把它们放进同一条数据链路里看。正式展开之前我整理了一份《数据仓库建设解决方案》里面涉及数据治理、数据集成、数仓建设等内容。如果你最近也在梳理企业的数据体系可以先存下来需要自取https://s.fanruan.com/7igmg复制到浏览器下面就顺着一条真实的数据链路把这四者一次理顺。一、先别急着分概念先看它们分别解决什么问题可以先记住四句话元数据解决这是什么数据主数据解决这些数据描述的到底是谁数据质量解决这些数据到底可不可信数据集成解决这些数据怎么从一个地方流到另一个地方看起来各管一块但真实项目里它们几乎不可能独立运行。假设集团现在要做“客户收入分析”。CRM里有客户信息ERP里有订单财务系统里有开票、回款售后系统里还有服务记录。第一步就会碰到一个问题CRM里的“A科技”和ERP里的“A科技有限公司”是不是同一家企业这是主数据问题。接着还要确认ERP里的customer_id到底代表什么“销售额”按下单时间、发货时间还是开票时间统计这是元数据问题。再往后还要检查客户编号有没有为空订单有没有重复金额有没有异常系统之间的数据能不能对应这是数据质量问题。最后才是把这些系统中的数据持续汇总起来。这一步才进入数据集成。所以真正的数据治理从来不是四个平台并排摆在那里而是一条连续的数据生产过程。真正落到项目里这些定义最终都要变成可以执行的数据处理规则。不同系统的数据接进来以后哪些字段需要映射、哪些数据要转换、多久更新一次、发生异常以后怎么处理都需要落到具体任务里。FineDataLink 5.0可以把数据库、文件、API等不同来源接到同一套数据开发和同步流程中前面梳理好的规则也就能顺着数据链路持续执行而不是停留在文档和方案里。所以很多数据治理项目真正拉开差距的地方就在这里规则有没有进入日常的数据生产过程。二、元数据解决的不是“有什么字段”而是企业能不能理解自己的数据很多人对元数据的理解还停留在表名、字段名、字段类型。这些当然属于元数据但只是最基础的一层。真正的数据体系里元数据至少要回答四类问题。第一类技术元数据一张表在哪里属于哪个数据库有哪些字段字段类型是什么主键是什么多久更新一次这些信息描述的是数据的技术结构。第二类业务元数据customer_id到底代表客户主体、客户账户还是交易对象“销售收入”到底含不含税“活跃客户”按照30天、90天还是自然月定义很多企业所谓的“指标口径不一致”根源其实并不在报表工具而是业务元数据没有说清楚。同样叫“销售额”A部门按订单金额算B部门按开票金额算C部门又扣掉退款以后计算。名字相同不代表含义相同。第三类管理元数据这张表归哪个部门负责出现数据问题找谁哪些人可以查看哪些字段属于敏感数据保存周期多久这些解决的是数据责任和管理边界。第四类血缘元数据这往往是最容易被忽视的一层。一张利润报表里的“毛利率”到底来自哪张指标表指标表依赖哪些明细数据明细数据又来自哪个业务系统如果上游某个字段被修改会影响多少任务、指标和报表企业数据量小的时候开发人员可能还能凭经验记住这些关系。但当数据源增加到几十个、上百个任务发展到几千个以后再靠微信群、Excel和个人记忆维护基本一定会失控。所以元数据真正成熟以后解决的是企业能不能知道自己有什么数据、数据是什么意思、从哪里来、流向哪里、谁负责。它相当于给企业整个数据体系建立了一份持续更新的说明书 地图 责任清单。三、主数据核心不是建主表而是确定“同一个业务对象”主数据最容易被误解成建一张客户表、商品表、供应商表。其实远远不够。假设同一家供应商采购系统里叫上海华明科技有限公司财务系统里叫上海华明科技合同系统记录的是统一社会信用代码。供应链系统又有自己的一套供应商编号。如果这些数据直接汇总系统很可能把它们识别成多个供应商。后果绝不只是“重复了一条数据”。采购金额可能被拆开应付款和合同无法准确匹配供应商集中度算错集团统一采购也很难分析。所以主数据真正解决的是现实世界里的同一个对象在不同系统里如何被认成同一个。这里至少包含五个问题唯一标识是什么客户到底用客户编码、统一社会信用代码还是其他ID识别哪个系统是权威来源客户名称以CRM为准还是ERP为准不同系统编码怎么映射A系统里的001如何对应B系统里的KH2026001发生冲突以后听谁的同一家供应商两个系统里的地址不同到底哪一份有效新增、修改、合并、停用以后怎么同步注意最后一个问题。很多企业把客户、商品、供应商主数据整理完以后就觉得治理已经完成。但真正的难点恰恰从这里开始。今天客户编码刚刚整理一致明天CRM新增一批客户后天ERP调整组织归属再过几天又有一家新公司上线。如果后续还靠人工导出、匹配、合并、覆盖原来整理好的主数据很快又会失效。所以主数据一定会继续碰到分发和同步。这时候FineDataLink 5.0可以把已经确定的客户映射、组织关系和字段转换规则接进同步任务。源系统发生新增或变更以后对应数据继续按照既定规则向下游更新主数据治理才不会停在“一次性清洗”这一步。这里其实可以把两者的边界记得很清楚主数据负责决定“谁是谁”数据集成负责把这个结果持续送到需要它的地方。四、数据质量真正要管的不是“脏数据”而是错误怎么产生、怎么传播“数据质量”也经常被理解成发现空值补一下发现重复去一下格式错了改一下。这只能算数据清洗。企业数据一旦复杂起来只做事后清洗成本一定会越来越高。因为很多错误并不会停在源系统里。它会沿着整条数据链路持续往后传播。假设ERP里一个客户编码填错了。同步到ODS以后没有发现进入DWD继续加工再进入指标层最后十几张经营报表都引用了这个结果。直到财务发现收入异常才开始往回查。这时候问题已经从一条错误数据变成一串错误任务 一批错误指标 多张错误报表。所以质量治理真正应该关注的至少有六个维度完整性该有的数据有没有缺失订单号、客户编码、金额等关键字段是否为空准确性数据值本身是否正确数量、金额、日期、状态有没有明显异常唯一性同一个客户、订单、商品是不是被重复记录一致性同一个业务对象在不同系统里的状态是否冲突及时性昨天的数据今天下午才进数仓还能不能支持晨会经营分析关联性订单有没有对应客户明细有没有对应主表上下游数据能不能正确关联更重要的一点是必须判断问题发生在哪一层。手机号为空可能是业务录入问题CRM和ERP客户状态不同可能是同步问题客户重复可能涉及主数据源端100万条、目标只有98万条则更接近链路完整性问题。如果所有问题最终都被统一归类成“数据质量不好”根本无法真正整改。所以成熟的数据质量管理一定要往数据生产过程前移。在FineDataLink 5.0里同步、加工之后的数据可以继续进入检测环节对完整性、一致性等规则进行检查如果任务结果出现异常也可以结合具体链路继续定位。这样质量治理就不需要等到业务人员发现报表异常以后再临时拉人排查。真正有效的质量闭环应该是定义规则 → 自动检测 → 发现异常 → 定位来源 → 处理问题 → 验证结果 → 沉淀规则。做到这一步企业治理的才不再只是某一批“脏数据”。真正被治理的是产生错误、传播错误的机制。五、数据集成难点从来不是A搬到B而是变化以后还能不能稳定运行数据集成看起来最好理解。ERP的数据同步到数仓CRM的数据汇总到分析平台接口数据定时拉取MySQL同步到ClickHouse。表面看起来就是A → B。但真正做过项目以后就会发现“把数据搬过去”可能只是最容易的一步。第一层是来源不同。数据库、API、文件、ERP、CRM、MES、WMS、大数据平台本身就是完全不同的技术体系。第二层是数据变化频率不同。组织架构一个月才变化几次订单每天新增几百万条库存一分钟内可能发生几十次变化。自然不应该全部使用同一种同步方式。第三层是变化类型不同。新增数据怎么处理修改数据怎么处理删除数据怎么同步源表增加字段怎么办字段类型发生变化怎么办第四层是任务中断以后怎么办。同步到一半失败是全部重跑还是从断点继续如果重复执行会不会造成重复数据第五层是上下游依赖怎么处理。订单任务没跑完收入模型该不该启动上游数据晚到下游任务要不要等待目标表异常以后报表是不是还继续刷新所以成熟的数据集成体系真正需要考虑的是连接、采集、同步、转换、调度、异常恢复、一致性检查和运维。真正搭这类链路时FineDataLink 5.0里的不同任务方式就会对应不同的数据变化节奏低频数据按周期同步持续变化的数据进入实时链路中间再衔接字段转换、任务依赖和异常处理。企业数据源越来越多以后也不需要每接一个系统就重新维护一套独立脚本。做到后面衡量一条数据链路是否可靠的标准也会发生变化。最开始可能只是看数据有没有过去再往后必须继续看有没有漏有没有重复延迟多少失败以后能不能恢复源系统结构发生变化下游能不能及时发现源端和目标端的数据最终能不能对上从“搬数据”走到这里才真正进入企业级数据集成。六、四者真正的关系可以看成一条治理链把前面的内容放在一起其实可以形成一条非常清楚的逻辑。第一步先确定业务对象客户、商品、供应商、组织、员工……先搞清楚企业最核心的业务对象到底是谁。这是主数据。第二步再描述这些数据字段是什么意思来源在哪里谁负责更新频率是什么上下游有哪些依赖这是元数据。第三步定义什么叫“正确”哪些字段不能为空哪些编码必须唯一不同系统之间怎么保持一致数据应该什么时候到这是数据质量。第四步让数据按照规则持续流动把不同系统接起来根据业务时效要求完成采集、同步、转换和交付。这是数据集成。但现实世界不会停在第四步。业务每天都在变化。新客户出现新商品上线组织架构调整字段增加系统替换指标口径修改。于是原来的治理逻辑又要跟着发生变化元数据更新 → 主数据调整 → 质量规则修改 → 集成任务变化。所以这四者并不是一条做完就结束的直线。它更接近一个循环定义对象↓描述数据↓制定规则↓连接数据↓检查结果↓发现问题↓调整规则↓再次进入数据生产过程这也是为什么真正成熟的数据治理不会把元数据、主数据、数据质量、数据集成完全割裂成四个互不相关的项目。因为企业真正要治理的本来就是数据从产生、变化、流转到最终被使用的整个生命周期。写在最后如果还是觉得这几个概念容易混可以记住一个最简单的比喻。主数据是“身份证”。解决客户、商品、供应商到底是谁。元数据是“说明书 地图”。告诉你数据是什么、在哪里、从哪里来、到哪里去。数据质量是“质检体系”。判断数据是否完整、准确、一致、及时。数据集成是“运输网络”。让不同系统中的数据按照规则持续流动。真正需要警惕的是把这四件事分别做成四座孤岛。只做数据集成可能只是把错误数据搬得更快只做主数据没有持续同步机制统一结果很快又会失效只做质量检查没有元数据和血缘发现问题以后依然难以定位只做元数据盘点却没有真实的数据生产链路最后很容易变成一份没人维护的目录。所以企业建设数据体系时真正应该追问的并不是“元数据、主数据、质量、集成到底应该先买哪个平台”而是一个数据对象从业务系统产生以后能不能被正确识别、准确解释、持续检查并按照统一规则稳定流向真正需要它的地方当这条链路真正跑起来以后元数据、主数据、数据质量和数据集成才不再是四个概念。它们共同构成的才是一套真正能够持续运转的数据体系。
