很多企业做数据治理最后都会陷入一种很奇怪的状态标准越来越多数据却没有越来越统一平台越来越全业务找数还是困难质量规则建了几百条月底对账依然经常出问题。原因往往不是企业不重视数据治理而是一开始就把治理理解成了几个独立功能做一套标准、建一个目录、配一些质量规则、画几张血缘图。但真正的数据治理管的是数据从产生到使用的整个生命周期数据应该怎样定义从哪里产生按照什么规则加工出了问题谁负责哪些数据值得长期维护谁可以使用发生变化以后又会影响谁在正式展开之前我整理了一套《数据仓库建设解决方案》里面涉及数据治理体系、数据集成、数据仓库、数据开发等常见场景。无论是准备搭治理框架还是已经在做数据平台、想重新梳理标准、质量和数据链路都可以拿来参考。需要自取https://s.fanruan.com/7igmg复制到浏览器如果把企业数据治理完整拆开大体可以分成八个核心模块数据标准、元数据、数据目录、数据质量、主数据、数据资产、数据血缘、数据安全。真正重要的不是记住这八个名词而是理解它们各自在解决什么问题以及彼此之间怎样形成闭环。一、数据标准不是统一字段名而是统一企业的数据语言很多企业第一次做数据标准会先整理一份Excel字段中文名、英文名、类型、长度、说明。这些当然属于标准但远远不够。真正的数据标准至少应该覆盖四层业务术语标准、数据元标准、代码标准和指标口径标准。比如“有效客户”到底指注册客户、成交客户还是过去12个月发生过交易的客户“华东区域”包含哪些省份ERP里的客户等级A、B、C和CRM里的重点、普通、潜力客户怎么对应毛利究竟是收入减营业成本还是还要进一步扣除履约成本这些问题如果没有提前统一后面的数仓、指标平台和BI做得再完整也只是把不同口径算得更快。数据标准最容易失败的地方恰恰在这里文档里的规则已经统一实际数据生产却还是各走各的。所以标准真正落地要进入数据加工链路。例如集团规定所有地区编码必须采用统一行政区划编码旧系统里却仍然存在“华东”“HD”“East China”等不同写法。实际建设时可以把这类字段映射、格式转换、编码统一等规则沉淀在FineDataLink 5.0的数据开发过程中由同步和加工任务在数据进入数仓时统一处理。这样一来标准不再只是一份要求业务和开发“记住”的规范而是直接成为数据生产规则的一部分。后续有新的系统接入时也不用每个项目重新解释一遍“这个字段应该怎么处理”。更成熟的标准管理还要记录版本、生效时间、责任人、变更原因和影响范围。因为真正的治理不是要求标准永远不变而是保证标准发生变化以后企业知道为什么变、什么时候变以及哪些数据和指标需要一起调整。二、元数据先回答“企业到底有什么数据”第二个核心模块是元数据。简单理解元数据就是描述数据的数据。一张订单表本身是数据而它属于哪个系统、有哪些字段、多久更新一次、谁负责、被哪些任务使用这些就是元数据。真正应该管理的元数据至少有三类技术元数据、业务元数据和运行元数据。技术元数据关注库、表、字段、类型、任务、接口业务元数据关注业务含义、所属主题、指标定义和负责人运行元数据则关注更新时间、任务状态、调用频率、数据量变化。为什么运行信息也要纳入治理因为两张结构完全相同的客户表一张每天稳定更新被几十张经营报表使用另一张已经半年没人维护。只看字段结构很难判断谁才是真正应该使用的数据。所以元数据管理的核心价值不是“扫描出了多少张表”而是给企业数据建立一张持续更新的身份证它是谁、从哪里来、谁负责、现在是否正常、有没有人在使用。没有元数据打底后面的目录、资产和血缘都很容易成为空中楼阁。三、数据目录不是罗列表名而是建立一张企业数据地图盘清元数据之后还会出现另一个非常现实的问题技术人员知道数据在哪里业务人员却根本不知道应该找什么。这就是数据目录存在的意义。如果目录打开以后全是ODS_ORDER_DETAIL、DWD_CUST_INFO、DWS_SALES_DAY……对于业务部门来说几乎等于没有目录。真正的数据目录应该站在业务视角组织数据例如业务域 → 主题域 → 数据对象 → 数据表/指标/数据服务。销售人员想找的是“客户”“订单”“回款”供应链想找的是“库存”“采购”“供应商”而不是某个数据库里的一张物理表。而且目录不能只告诉使用者“这张表在哪”。它还应该回答这是什么、多久更新、口径是什么、谁负责、质量怎么样、如何申请使用。这也是目录建设为什么不能脱离真实的数据开发过程。ERP、CRM、MES、财务系统的数据接入数仓时本身就会形成大量来源、目标、任务和加工关系。像FineDataLink 5.0这类数据开发与集成工具实际承载的就是这些数据流转过程。把正在运行的数据任务与目录中的数据对象对应起来目录反映的才是企业“现在的数据地图”而不是几个月前人工盘点出来的一张静态清单。尤其是系统越来越多以后很多企业并不是没有目录而是目录更新速度赶不上数据变化速度。因此成熟的数据目录必须逐渐从“人工登记”转向“元数据自动采集 业务补充解释”。四、数据质量治理的不是脏数据而是脏数据产生的机制数据质量也是最容易“做了很多看起来却没效果”的模块。很多企业一提质量治理想到的就是空值率、重复率、格式错误。但真实业务中的数据问题远复杂得多。比如销售额突然下降50%可能不是业务真的下降而是某个接口少同步了一天两个系统客户数量不一致可能不是数据算错而是客户定义不同某张订单表今天有1000万条明天突然只有300万条即使每个字段都没有空值依然属于严重的数据质量问题。因此质量至少要从六个维度来看完整性、准确性、一致性、唯一性、及时性、合理性。但真正决定质量治理有没有用的不是企业配置了多少规则而是有没有形成完整闭环规则定义 → 自动检测 → 异常发现 → 原因定位 → 责任分派 → 数据修复 → 再次验证。例如订单进入数仓以后需要检查订单号是否唯一、客户编码是否存在、订单金额是否异常、当天数据量是否出现大幅波动。类似规则可以放进FineDataLink 5.0的数据检测任务中并和日常数据任务衔接起来。这样做的价值在于问题出现以后不必等到月底经营报表已经生成、业务发现数字明显异常以后再倒查整个链路而是在数据进入核心分析层之前就尽量把异常暴露出来。进一步来说质量治理还要有优先级。核心经营指标的数据、财务结算数据和临时分析表不应该配置完全相同的质量要求。更合理的做法是建立数据分级 质量规则 SLA。关键数据要求分钟级甚至实时检测普通数据可以每天检测而长期没人使用的数据甚至应该考虑下线。数据质量真正治理的不是所有错误而是那些会影响业务决策的数据错误。五、主数据解决“同一个对象为什么有五个名字”企业数据治理中最棘手的问题之一就是主数据。客户、供应商、商品、物料、组织、员工都属于典型主数据。例如同一家客户CRM里叫“A科技”ERP里叫“A科技有限公司”合同系统按照统一社会信用代码保存财务系统又有自己的客户编码。如果几套数据直接汇总就很可能出现四个客户。因此主数据治理真正解决的是企业如何识别“同一个业务对象”。通常至少要确定四件事唯一标识是什么、哪个系统是权威源、冲突数据以谁为准、发生变化后如何同步。所以主数据绝不是简单建一张“客户主表”。背后真正需要的是新增、修改、审核、合并、停用、分发的一整套生命周期机制。尤其是大型集团如果没有主数据机制新系统、新公司、新门店不断上线原来已经治理干净的数据很快又会重新变乱。六、数据资产不是企业有多少数据而是多少数据值得长期经营很多企业做到数据资产管理时首先关注一个数字已经盘点多少张表10万张、20万张、50万张。但这个数字其实没有太大意义。因为里面可能存在大量临时表、重复表、历史废弃表以及从来没人访问的数据。数据只有被稳定使用、能够持续支持业务时才真正开始具有资产价值。所以资产管理还应该继续回答谁在用使用频率多高质量是否稳定下游影响多大有没有重复建设维护成本是多少尤其是判断数据价值时不能只看最终报表。长期稳定运行的数据加工链路本身就是很重要的判断依据。例如某张客户主题表每天都有FineDataLink 5.0的任务持续更新同时被多个销售分析、经营分析和客户运营场景消费那么它显然应该进入重点资产范围。相反一张半年没人访问、上游任务已经停止、又没有任何下游依赖的历史表即使还躺在数据库里也应该进入清理候选名单。换句话说资产管理不是给所有数据“发证书”。而是在不断区分核心资产、一般资产、待治理数据和待退出数据。最终追求的也不是资产数量越来越多而是高价值数据不断被复用低价值和重复数据逐步减少。七、数据血缘真正有价值的是排障和影响分析数据血缘通常是治理平台里最容易被展示出来的一项能力。点击一张表立刻出现一张复杂的关系图看起来非常直观。但如果血缘只能“看图”实际价值并不大。真正有价值的血缘要解决两个问题。第一个是出了问题能不能快速找到源头例如经营驾驶舱上的销售额突然少了5000万。排查路径可能是报表 → 指标 → DWS → DWD → ODS → ERP订单表。如果每一步都靠人问开发、翻SQL、查任务问题定位可能需要几个小时甚至几天。血缘的意义就是把这条链提前保存下来。第二个问题更重要准备修改一份数据时能不能提前知道会影响谁例如准备删除订单表里的一个历史字段不能只看这张表本身还要继续判断有没有下游任务引用有没有API正在输出有没有报表依赖有没有其他数据集继续使用到了这种场景FineDataLink 5.0里的血缘分析就不只是用来展示上下游关系了。数据表和数据开发任务、管道任务、API之间的关系能够串起来以后开发人员在调整某张表或者某条任务之前可以先看一遍它到底牵动了哪些下游对象。因此血缘治理真正成熟的标志不是“图画得越来越大。”而是两个非常实际的结果问题出现时排查时间越来越短数据变更前事故越来越少。八、数据安全不是把数据锁起来而是让数据在正确范围内流动治理做到最后一定绕不开数据安全。因为数据越集中风险实际上越高。过去客户信息放在CRM、合同放在合同系统、工资放在人力系统各个系统之间天然存在边界。数据进入统一数仓以后一个分析环境中可能同时存在客户、订单、合同、员工、薪资、财务等多类数据。因此安全治理的第一步通常不是配置权限而是先做数据分类分级。哪些数据可以公开使用哪些属于内部数据哪些属于敏感数据哪些属于高度敏感数据确定等级以后才能继续设计最小权限、字段脱敏、访问审批、操作审计和生命周期控制。而且权限管理不能只做到“这张表能不能看”。例如业务人员可以查看区域工资总额但不能查看每个员工的具体工资可以分析客户数量和地区分布但不一定需要看到完整手机号和身份证号。所以数据安全真正要回答的是谁在什么业务场景下可以看到什么粒度的数据并且使用过程能否被追溯。结语八个模块最终要形成一条治理链路把这八个模块放在一起就能看出一条非常完整的数据治理逻辑数据标准解决“应该怎么定义”元数据解决“企业到底有什么数据”数据目录解决“数据在哪里、怎么找到”数据质量解决“找到的数据能不能相信”主数据解决“不同系统里的业务对象是不是同一个”数据资产解决“哪些数据值得持续维护和复用”数据血缘解决“数据从哪里来、到哪里去、修改会影响谁”数据安全解决“谁可以在什么范围内使用”。真正成熟的数据治理绝不是八个模块各自建设一套平台。它们最终应该串起来。例如企业新建一个“客户复购率”指标首先要明确统一口径登记业务负责人和技术负责人能够在数据目录里被搜索底层客户和订单数据有明确的质量规则通过血缘可以追到底层来源使用客户敏感字段时受到权限控制随着使用频率增加这个指标和相关数据集又可能被识别为核心数据资产。到了这一步数据治理才真正从“治理部门专门治理数据”变成“数据在每天产生、加工和使用的过程中本身就在按照治理规则运行。”所以判断一家企业的数据治理做得好不好真正应该看的不是建了多少标准、盘点了多少资产、配置了多少质量规则。而是当企业每天产生和加工海量数据时面对新系统接入、指标变化、数据异常、人员调整和业务变化这套机制还能不能持续运转。好的数据治理不是把数据管得越来越复杂而是让正确的数据在正确的规则下被正确的人持续使用。