很多企业做数据建设时会同时提到两个词数据集成、数据治理。但真正开始做项目以后经常会走向两个极端。一种是先做治理。先定义数据标准、指标口径、数据目录、质量规则开了很多会也整理了大量Excel和制度文件。等真正准备落地时才发现数据还散落在ERP、CRM、MES、WMS、财务系统和各种业务数据库里。另一种则刚好相反。先把所有数据接进来。系统接一个任务建一个表同步一张算一张。几年以后平台里已经有几千张表、几千条任务却没人说得清这些数据到底谁负责、哪个口径才对、哪张表还在用。这就是很多企业一直搞反的地方。数据集成和数据治理从来都不是两个割裂的项目更不是简单的“先集成再治理”。正式展开之前我整理了一套《数据仓库建设解决方案》里面涉及数据集成、数仓建设、数据治理等内容。正在做数据平台、数仓或者数据治理项目的可以结合本文一起看。需要自取https://s.fanruan.com/7igmg复制到浏览器一、数据集成解决的本质上是“数据怎么流”先把两个概念彻底拆开。数据集成首先解决的是企业的数据怎么从不同系统进入统一的数据环境。一家制造企业可能同时存在ERP里的订单、采购和财务数据CRM里的客户和销售机会MES里的生产过程数据WMS里的库存数据OA里的人员和组织数据设备平台里的实时运行数据。这些系统使用的数据库不同数据结构不同更新频率也不同。有的数据每天凌晨更新一次有的数据每分钟变化有的数据来自数据库有的数据来自API、Excel、日志或者消息队列。所以数据集成并不是简单的“把表复制过去”。它至少要回答四个问题从哪里取取哪些多久取一次取到哪里进一步还会涉及全量同步、增量抽取、CDC、实时同步、批量同步、任务调度、失败重跑、断点恢复、数据转换和分发。因此数据集成真正解决的是数据流动和数据连接。真正落到项目里往往也不会让所有数据走同一种同步方式。比如组织、地区编码这类低频变化的数据可以定时全量更新交易表只抽取新增和变更数据订单、库存等对时效要求高的数据再考虑CDC或者实时管道。这类场景放到FineDataLink 5.0中本质上也是先按照数据变化方式拆链路数据库、API、文件等来源先统一接入再分别配置全量、增量、定时任务或实时管道。这样后续讨论治理时面对的是一条条真实运行的数据链路而不是只在文档里描述“某系统应该把数据提供给某平台”。但问题也恰恰出在这里数据流过来了不代表数据已经可用。二、数据治理解决的是“流过来的数据能不能相信”假设ERP、CRM、WMS的数据已经全部进入数仓。新的问题马上就会出现。CRM里的客户名称是北京XX科技有限公司ERP里可能叫北京XX科技销售Excel里又写成XX科技如果直接汇总系统甚至可能认为这是三个客户。指标也是一样。“销售额”看起来非常简单。销售部门可能按照订单创建时间统计运营按照付款时间统计财务按照收入确认时间统计。三个部门都没有算错。但经营会上会出现三个不同的销售额。这就是典型的数据治理问题。所以治理关心的已经不是数据有没有进来。而是进来的数据叫什么、是什么意思、以谁为准、谁可以使用、出了问题找谁。因此数据治理才会继续拆成数据标准、数据质量、主数据、元数据、数据目录、数据血缘、指标口径、数据安全、权限管理、数据资产。简单来说数据集成解决“数据怎么流”。数据治理解决“流动的数据按照什么规则使用”。但真正重要的是这两件事不能分开做。因为没有真实的数据链路治理规则很容易停留在纸面没有治理规则集成规模越大产生的数据混乱反而越严重。三、为什么很多数据治理项目最后变成了“文档治理”很多企业做治理项目时第一件事就是定制度。定义客户标准、产品标准、部门标准、字段标准、指标标准再制定一套数据质量规范。最后可能产出几十份Excel、几百页制度。看起来体系非常完整。但半年以后问三个问题哪些系统违反了标准没人知道。今天哪些数据质量规则失败了没人知道。某个指标最终来自哪些源表还是没人知道。原因很简单治理规则没有进入真实的数据运行过程。比如企业规定“客户编码不能为空。”写进标准只需要一句话。真正落地却至少要回答数据进入平台时谁检查发现空值以后任务继续还是停止错误数据放在哪里谁负责修复修复以后是否重新同步已经进入下游的数据需不需要重算所以一条真正可以运行的治理规则应该经历标准定义 → 规则配置 → 数据检测 → 异常发现 → 责任分配 → 数据修复 → 结果验证。这也是为什么数据血缘不能只靠人工画图。当数据链路每天都在变化时今天画好的血缘一个月以后就可能失效。在FineDataLink 5.0里数据同步、转换、实时管道和数据服务本身已经形成实际执行关系这些任务关系还能继续用于查看上下游血缘。当某张源表字段调整、某个任务变化时至少可以沿着链路继续看它影响了哪些表、任务和使用端。治理到了这一步才真正从“我们规定数据应该怎样。”走向“我们知道数据实际上怎样流。”这两个状态之间差的就是治理能不能进入执行层。四、只有数据集成没有治理链路越多反而越危险还有一类企业正好相反。数据集成做得非常快。业务系统来了一个就接一个业务部门要一张表就同步一张要实时数据再加一条CDC链路。刚开始效率很高。但当任务从几十条增长到几千条以后问题会集中爆发。比如同一张客户表被不同项目重复同步了五遍同一个销售指标在不同团队手里存在七套逻辑某个源系统已经下线对应同步任务却还每天运行有些任务失败三个月都没人发现因为下游早就没人使用一张核心表增加字段以后下游几十条任务陆续报错。这说明数据集成规模越大越需要治理。因为10条任务可以靠开发人员记住。1000条任务以后就必须开始管理任务归属、数据责任人、更新频率、上下游依赖、质量状态、生命周期和异常处理。这里的治理已经非常接近“运行治理”。例如实际维护FineDataLink 5.0中的同步任务和实时管道时关注点不会只剩下“任务今天是不是成功了”还需要继续看任务调度、运行日志、异常状态以及实时链路有没有积压、断点恢复后是否继续消费。因为真正危险的情况往往并不是任务直接失败。而是任务仍然显示运行但数据已经延迟、缺失或者与源端产生偏差。所以成熟的数据治理还必须增加一个维度不仅治理数据结果也要治理产生这些数据的过程。五、真正合理的关系治理定规则集成把规则带进数据链路如果简单画一张企业数据架构图很多人会画成业务系统 → 数据集成 → 数据仓库 → 数据治理 → BI这张图其实很容易产生误导。因为它会让人以为数据先集成完再统一治理。但真实情况应该是治理贯穿数据整个生命周期。数据接入之前先确认哪个系统是权威源比如客户基本信息到底以CRM还是ERP为准。数据同步过程中需要确认有没有重复、缺失、延迟和异常。数据加工过程中要继续约束字段标准、编码规则、业务口径、主数据映射。数据提供出去以后还要管理谁能看、谁能调用、敏感数据是否需要控制、哪些数据可以对外服务。所以治理不是数仓之后再增加的一层。它应该渗透到接入、同步、加工、存储、服务和使用。到了FineDataLink 5.0这一层产品的角色也会继续发生变化。前面讨论的是怎么把数据接进来到了数据治理阶段数据连接、任务、实时管道和数据服务本身都需要进入权限和使用范围的管理。例如不同人员对数据连接可以有不同的使用和管理权限处理后的数据再通过数据服务向其他系统提供。这样一来“谁能取得这份数据、谁能修改链路、数据最终提供给谁”都开始进入同一条数据生命周期里。这也是数据集成和数据治理真正交叉的位置治理负责定义边界集成负责让这些边界进入实际的数据流转过程。六、企业到底应该先做数据集成还是先做数据治理很多企业最后都会问这个问题。其实答案不是先集成还是先治理。真正合理的方法是小范围集成小范围治理再不断扩张。第一步先选核心业务对象。不要一上来治理全公司几万张表。先抓客户、产品、订单、库存、供应商、组织、财务。第二步把核心数据链路接起来。先弄清楚数据从哪里产生经过哪里最终到哪里。第三步治理规则同步进入。比如客户数据接进来以后就开始统一客户编码、客户名称、责任部门、权威来源和质量规则。第四步把问题重新反馈给集成链路。发现源系统编码混乱就增加转换规则发现任务重复就合并链路发现更新不及时就调整同步策略发现敏感字段使用范围过大就修改权限。于是整个体系会形成一个循环数据接入 → 发现问题 → 制定规则 → 调整链路 → 验证结果 → 持续优化。这才是真正可以运行的数据治理。结语所以数据集成和数据治理的关系可以用一句话概括数据集成让数据流起来数据治理决定这些数据能不能被可信地使用。只有治理没有集成最后容易变成制度很多真正的数据却没有被管住。只有集成没有治理则会变成数据越来越多链路越来越复杂但没人知道什么数据还能相信。真正成熟的数据建设最终应该能够连续回答几个问题数据从哪里来为什么要同步按照什么规则处理经过哪些任务出了问题谁负责哪些下游会受到影响最终谁可以使用当这些问题可以沿着一条真实的数据链路被回答清楚时企业才算真正把数据集成、数据治理、数据使用连成了一套完整的数据体系。