简介这份PDF白皮书面向企业数据管理者、数据平台建设者与数字化转型从业者围绕“数据如何从资源变成资产”这一核心问题展开。内容从数据分类与数据资产定义讲起梳理主数据、业务数据、分析数据的“树干—枝叶—果实”关系进而说明数据治理解决的是找不到、看不懂、信不过、管不住四类现实困境并系统介绍网易数据治理2.0的开发治理一体化、数据中台架构、湖内湖外统一治理、数据治理360、基于ROI的资产精细化管理、持续闭环与DataOps开发底座。资源共1个PDF文件约10.09MB目录完整、层级清晰便于按章节检索末章还给出证券、电信运营商、物流三个行业的落地实践可帮助读者对照自身场景理解治理框架的搭建顺序与落地要点。目前已有721人学习适合需要建立数据治理整体认知或为内部立项寻找参考的读者。1. 数据治理到底在治什么它管的不是数据是人和数据的关系“数据治理”这四个字第一次听见的人多半会理解成“把数据洗干净”或者“建一个大库统一存起来”。真在企业里干过这活的人会告诉你清洗和建库只是动作治理真正要对付的是两件事人和数据之间怎么互相认识人和人之间怎么把同一份数据用到同一个口径上。一份企业级的数据治理白皮书把这件事拆得很细先把企业数据分成主数据、业务数据和分析数据再看数据用不起来时到底卡在哪四个地方最后把治理动作塞回数据开发的流水线上。这条路子值得搞懂因为大多数公司踩的坑几乎一模一样——数据越攒越多能用的反而越来越少。2. 企业的数据到底长什么样树干、树叶和果实的分类法企业里几乎每个人每天都在和数据打交道管理者看报表基层员工填单据运营盯着转化率。可用不好数据的原因往往不在“有没有数据”而在“根本不知道手上这堆东西各是什么、各管什么用”。分类是所有后续动作的前提分不清类型就谈不上治理更谈不上把数据当资产来经营。2.1 主数据、业务数据、分析数据一棵树就能记住主数据是有关业务实体的数据比如雇员、客户、产品、地点。它回答的是“这个对象是谁”为业务交易和分析提供语境信息。一家公司如果客户主数据没管住同一个客户在三个系统里就是三个人后续所有按客户汇总的数字都会出问题。业务数据描述企业的经营活动产品出入库、财务应收、采购、销售都算。它回答的是“发生了什么”是分析数据的原料。业务数据的质量直接决定后面能不能算出可信的结果上游一笔单据录错下游十个报表跟着歪。分析数据来自业务数据的加工反映企业业绩比如销售收入增长、投资回报率。它回答的是“结果如何”是决策的依据也是数据价值真正体现出来的那一层。三类数据不是并列关系而是承载和供养关系。主数据是树干业务数据是枝叶分析数据是枝头的果实叶子离了树干活不了果实靠叶子光合作用供养。脱离主数据谈业务数据和分析数据就像拿着摘下来的叶子讨论它还能不能结果。类型回答的问题典型例子类比缺失时会怎样主数据这个对象是谁客户、产品、地点、雇员树干同一客户在不同系统变成多条记录业务数据发生了什么出入库、应收、采购、销售树叶分析没有原料只能拍脑袋分析数据结果如何收入增长、投资回报率果实决策失去依据价值无法兑现2.2 数据为什么不等于数据资产业内一份被广泛引用的数据资产管理白皮书把数据资产定义为由组织合法拥有或控制的数据资源以电子或其他方式记录例如文本、图像、语音、视频、网页、数据库、传感信号等结构化或非结构化数据可进行计量或交易能直接或间接带来经济效益和社会效益。这个定义里有三根柱子。第一根是主体数据必须有归属归属于某个组织而不是飘在空中的字节。第二根是资源形态数据可以是结构化的表也可以是非结构化的语音和图像判断标准不是长什么样而是能不能被记录和被使用。第三根是价值能直接或间接带来经济效益和社会效益这一条才是“数据”和“资产”之间的分水岭。关键在于这三根柱子不会自动立起来。数据的生成、汇聚、存储、分析、共享每个环节都可能因为管理不当、治理手段缺失而产出低质量数据。低质量数据不但没有价值还会制造错误决策它的破坏力和一条错误的财务报表是同一量级。用树的比喻接着说不健康的树干会影响叶子生长不健康的叶子无法提供足够养分去孕育果实不健康的果实也吃不得。所以企业里数据量和资产量从来不是一回事只有对企业有价值的那部分数据才够格叫资产。这个判断听起来简单落到几十万张表上就变成一道实打实的筛选题。2.3 数据治理是那把钥匙原料、加工线、成品如果把数据比作企业信息化的原料数据治理就是信息化的基石数据资产则是在治理过的数据上挖出来的价值。三者是一条流水线原料进厂、加工线运转、成品出厂跳掉中间那段原料永远只是原料。这条加工线处理的事情说白了是人与人、人与数据之间的关系。一份字段该叫什么名字、由谁定义、口径变了通知谁、谁有权看、看完出问题找谁这些不是技术问题是责任和流程问题。也正因为如此数据治理常常被误当成 IT 部门的私活。实际上它一端连着业务定义一端连着技术实现中间还夹着组织授权。只让技术团队做标准定得再漂亮也落不下去只让业务团队做讨论三个月也产不出一张能用的表。搞清这一点后面的所有问题才有解释的余地。3. 治理要解决的四个字找不到、看不懂、信不过、管不住很多公司都是在某一两年突然集体喊起治理。原因往往不是领导忽然重视了而是业务规模扩张到某个临界点原来靠人肉维持的小数仓撑不住了数据量涨上去问题密度也跟着涨某天一次事故直接把成本算清楚治理就被提上日程。把这些问题归个类基本能收进四个词找不到、看不懂、信不过、管不住。这四个词对应的不是四个工具而是数据从被发现到被使用的完整链条。3.1 找不到几万张表里的大海捞针先看规模。某电商业务线约有 8 万张表某内容业务线约有 4 万张表。越靠近应用层大宽表越多一张表上百个字段非常正常。对一个分析师来说从几万张表里找到自己需要的那一张效率上跟大海捞针差不多。更值得琢磨的是数据地图的使用数据90% 以上的使用者是 IT 人员本来作为目标用户的业务人员几乎不用。这不是工具做得不好而是索引对象错了。地图回答的是“表在哪儿”业务问的是“我要的那个数在哪儿”。业务人员脑子里想的是“上月新客复购率”地图给他的是 dwd_trade_order_detail_v3中间那层翻译工作没人做。找不到的直接后果是重复开发。反正搜不到索性自己建一张建完又没人知道下一波需求再建一张。表的数量于是继续膨胀形成自我加速的循环。3.2 看不懂78% 的表存在元数据缺失即便业务人员找到了表也常常看不懂。有统计显示高达 78% 的表存在元数据缺失缺的主要是管理元数据和业务元数据而这两类恰恰是业务人员判断“这张表能不能用”的关键信息。元数据缺失有明显的结构性原因。技术元数据完整度通常最高因为它能靠系统自动采集表结构、存储位置、分区、任务依赖扫一遍就有。管理元数据和业务元数据与业务强相关必须由业务方配合补充谁负责、什么含义、口径怎么算、什么密级这些系统猜不出来。凡是需要人手工补的缺失率一定高。字段名于是变成了黑匣子。一个叫 amt_pay 的字段可能是实付金额可能是应付金额也可能含税不含税光看名字谁也说不准。开发人员不敢改业务人员不敢用这张表就在那里躺着占着存储等着某天被当成历史包袱清理掉。提示元数据采集工具解决得了“有没有”解决不了“准不准”。业务含义这部分只能靠责任到人靠工具替代不了。3.3 信不过一条上游逻辑改动几十万真金白银质量是数据的生命线。没有质量保障的数据不仅没有价值还会产生错误决策这一点在涉及钱的场景里尤其刺眼。某次电商活动中开发修改了一个上游任务的计算逻辑影响了下游一张涉及资损的表红包超发几十万的损失当场发生。这类教训反复出现指向的其实是同一件事业务方对数据的信任是一次次事故磨掉的。再看日常。对内部工作群的反馈做过统计平均每周有 10 个数据质量问题被反馈“数据违反常识”是听到最多的一句吐槽。更难受的是其中 90% 的问题由数据使用方先于开发方发现数据团队非常被动经常是业务找上门才知道自己出了问题。根子在于质量规则没有跟着开发走。实际开发过程中质量稽核规则的覆盖率只有 10%相同数据项上有 70% 的情况稽核规则不一致阈值设置也不一致。同一张表在不同人手里守护它的规则完全不同甚至有些表根本没规则守着。-- 订单金额稽核金额为负或明显超过 单价×数量都判为异常 -- 1.05 表示允许 5% 的优惠浮动这个数值必须由业务口径确认后写进标准而不是让开发各自拍板 SELECT order_id, pay_amount, unit_price * quantity AS expected_amount -- 理论金额用于人工复核时对照 FROM dwd_order_detail WHERE dt ${bizdate} -- 按天分区跑只稽核当天增量 AND (pay_amount 0 OR pay_amount unit_price * quantity * 1.05);这段 SQL 的逻辑很朴素把明显不可能的值捞出来。真正的关键不在语句本身而在三个参数的来源。dt 决定稽核的时间范围pay_amount 的字段类型、精度、是否允许为负应当来自数据标准而不是临时约定1.05 这个阈值更典型一个人拍 1.05另一个人拍 1.2规则就打架了这正是前面那 70% 不一致的来源。规则一旦挂到数据元上阈值随标准走才谈得上统一。注意稽核规则如果由每个开发自行手写同一张表在不同人手里会得到完全不同的判定结果覆盖率低只是表象判定标准漂移才是根本问题。还有一组数字值得留意经由数据开发任务变更导致的生产环境数据问题占比达到 65%。也就是说大部分事故不是数据天生有问题而是改动引入的。传统治理方式在开发完成之后才介入天然接不住这类事故。3.4 管不住成本黑洞和流于形式的权限数据成本是成本里最容易被忽略的一项因为它不像人力、采购那样有明确账单。但真去盘一遍库存数字往往很扎眼某事业部 78.39% 的表只占了 21.63% 的存储空间而这些表在 30 天内无人访问。报表也一样62% 的报表在 30 天内无人使用平均每张报表每个月还要花掉约 3 万元的成本。资源的滥用还会直接带来稳定性问题。内部记录显示每个月都有 5 次以上事故与资源不合理使用有关比如一个五层嵌套的大 SQL 瞬间把集群压垮殃及所有在同一集群上跑的任务。安全这一侧的矛盾更微妙。企业既希望员工多用数据又要确保不同密级的数据只被对的人看到。权限分配不合理轻则数据误删重则数据泄密权限流程太复杂使用效率又掉下来。一个真实的场景是业务运营想用一张表得先找到表的负责人再联系对方授权整个流程常常耗掉一天。而在授权方那头负责人往往也不清楚该不该给最后权限流于形式只要能找到人就能拿到访问权。四个问题摆在一起看会发现它们不共享同一个工具却共享同一个根源治理动作发生在数据生产出来之后既没有被量化也没有形成闭环。这就是下一章要展开的部分。4. 治理为什么总在事后救火六处断点与把治理前置的思路传统数据治理的流程看起来相当完整定标准、落标准、查质量三步走完似乎就该见效。可真落地之后效果往往打折甚至出现“治理项目做完第二年问题照旧”的尴尬局面。原因不复杂这套流程是围绕存量数据设计的而企业的数据资产每天都在增量。4.1 三大件与定标、落标、稽核老流程是怎么转的传统数据治理包括三大件数据标准、元数据管理、数据质量。流程从制定数据标准开始简称定标接着通过元数据的采集、注册、扫描、发布把数据标准与数据模型连接起来这个过程叫落标最后用数据标准关联的质量稽核规则对数据模型进行稽查发现问题、形成质量报告、推动业务部门整改提升数据质量。这条链路本身是成立的问题是它的作用方向。它更强调对业务系统存量数据的治理对长效机制建设重视不够于是企业只能靠一个又一个治理项目维持效果。项目一停新产生的数据继续脏几个月后又是一轮。更麻烦的是它的成本结构。传统治理是一个反向治理的过程并不融入数据生产的整个过程与数据开发、建模、运维、安全等环节都存在脱节。要做治理就得改造现有系统和流程改造成本高到让很多企业望而却步。4.2 六处断点治理为什么总在事后救火第一处断点在质量与开发之间。质量稽核本是用来确认开发结果符合业务逻辑的但规则覆盖率只有 10%规则设置还各不相同。开发人员对业务的理解深度参差很多人没法从开发结果上判断数据是否满足业务要求问题只好留到使用方那里暴露。久而久之业务方对开发团队的数据不再信任。第二处断点在标准与建模之间。数据标准通常包括标准规划、标准制定、标准发布、标准执行、标准检查五项内容企业也会结合行业情况制定自己的标准。但标准定完之后怎么让开发人员贯彻是另一回事。标准与建模脱节结果就是表的命名不统一、字段命名各行其是数据的理解成本和管理成本一起上升。第三处断点在元数据与开发之间。数据开发时任务之间是有依赖的下游要等上游实例产出。现网环境中任务数量动辄上千甚至上万靠手工配置依赖关系极其考验熟练度也极易出错。一旦漏配任务空跑下游数据就是错的。要自动推荐上游任务靠的正是元数据里的血缘关系而元数据没打通时这件事就只能靠人肉。第四处断点在元数据与运维之间。大量任务同时异常时值班人员需要知道处理先后顺序让重要任务优先恢复也需要知道故障源头在哪因为很多故障是上游异常传导下来的。这两件事都离不开元数据脱节之后运维只能凭经验猜。第五处断点在标准与安全之间。数据权限怎么设、密级怎么定、哪些数据要脱敏、哪些人可以被赋权依据都来自数据标准。标准与安全脱节企业对数据安全的管理就失去了抓手变成盲目审批。第六处断点更宏观是治理与增量之间的断点。前面五处都指向同一个现象治理动作发生在数据已经生产出来之后。数据生产是持续的治理是阵发的两头节奏对不上治理永远在追赶。4.3 烟囱式开发与平台割裂断在架构上的那一半断点不只在流程里也长在架构上。早期数仓建设多由各业务部门自行维护没有上升到组织架构层面规划各部门内部都有零散的数据开发和分析人员服务本团队需求。结果就是一堆分裂的小数仓。这种烟囱式开发的典型症状有三个。一是指标口径不一致缺少统一的规范建模标准各部门存在大量名称相同但口径不同的指标业务人员看数据像猜谜。二是重复开发超过 40% 的表没有分层开发人员接到新需求时无法高效复用已有的表超过 50% 的任务直接读取原始数据每次需求都从头再来。三是资源浪费系统里沉淀了大量长期无人访问的重复数据。平台层面的割裂再补一刀。大型企业的 IT 架构里常有关系型数据库、分析型数据库、数据湖等多套系统各自从后端到前端相互独立、紧耦合开发系统臃肿、建设效率低、响应业务慢。要建统一的大数据开发与治理平台就得面对历史数据和历史任务的迁移成本还得承担迁移过程中的数据遗失风险以及重新培训人员的成本。这些顾虑堆在一起足以让企业对平台化望而却步。4.4 把治理前置开发治理一体化的四个阶段既然断点都在“事后”解法就是把治理动作往前挪。开发治理一体化的核心思想是把数据治理的过程融入数据开发的全生命周期遵循“先设计、后开发先标准、后建模”的原则追求“规范即设计、设计即开发、开发即治理”。整个流程分四个阶段。需求阶段先做业务调研和数据调研。表级调研包括表范围、存储位置、中英文名、来源系统、优先级、更新方式、业务场景、数据条数和增量条数目的是据此制定接入计划确认哪些数据要实时接入、哪些走离线。字段级调研包括表结构、字段类型格式、样例数据、有值行、有值率、是否需要制定标准、是否已挂载标准、值域分布这些信息直接决定后续标准化的效率。同时把指标、模型分层、主题做初步梳理为设计铺路。设计阶段是最重的一块包含标准设计和指标设计。标准规划可以收集现行标准也可以结合自身业务梳理规划时的优先顺序应围绕业务协同、监管合规、数据共享开放、数据分析应用来排非交互、非公开的数据标准化优先级可以放低。标准制定的三件套是词根、标准字典、数据元词根是企业维护的标准词库确保含义相同的中文词翻译成相同的英文名制定过程是拆解、去重、定义最终确定中文全称、英文全称和英文简称标准字典维护枚举字段的标准代码集比如物料类型代码中 5 代表采购物料、10 代表制造物料各业务系统枚举范围不同需要在中台层统一数据元是用一组属性描述定义、标识、表示和允许值的数据单元需要定义中文名称、英文名称、数据类型、数据格式、值域。三者制定完成后整包发布审核通过即可在全系统使用。指标设计要把业务指标拆成原子指标、派生指标和复合指标同时明确数据域、业务过程、修饰词、时间周期。举个具体例子“最近 1 天 PC 端支付金额”拆开就是业务过程为支付修饰词为 PC 端时间周期为最近 1 天原子指标为支付金额指标域归到订单域。指标要经过新建、注册、确权、治理、发布几个环节使用中发现问题可提治理工单业务口径问题派给业务部门技术口径问题派给开发部门修完重新发布并生成新版本。模型设计阶段定义维表、事实表和模型关系把标准落进去导入标准后系统自动填写字段名称、字段描述、数据元、数据字典建表时还能用标准化标签把字段绑定到既定的维度和指标上保证指标和维度不会被各建各的。开发阶段把设计好的模型做物理实现与技术元数据血缘、质量、调度任务信息和标准规范结合。字段类型这块有个容易被忽略的细节不同行业对精度要求不同金融行业对小数点后保留位数和制造业的要求就不一样因此需要一份可自定义的字段类型标准映射规范保证入湖后字段类型统一也减少开发手动调整类型带来的失误。安全也在这一层落地。数据标准里包含业务敏感数据的对象和属性把敏感类型、安全等级、脱敏规则、脱敏算法以及脱敏配置同数据元关联就能快速生成字段级的加密或脱敏规则。模型设计引用了某个数据元数据传输环节就按该数据元的规则做静态脱敏离线开发环节按规则做动态脱敏还能针对不同用户下发不同策略表本身也根据关联数据元的密级获得分类分级依据走对应的资源申请流程。交付阶段把加工好的数据以可视化配置的方式开发成服务数据消费方在 API 集市查看调用说明并申请使用权权限、熔断、限流这些机制在这里兜住交付质量与安全。平台还会统计 API 调用情况结合治理模块盘点 API 资产把闲置 API 和异常 API 挖出来通知负责人整顿。模型质量也需要可量化的标尺。跨层引用是烟囱式开发的典型征兆直接绕过公共层去引用原始层短期省事长期把分层结构彻底冲垮。用跨层引用率这类指标盯着它才能知道治理是不是真的在生效。-- 跨层引用率统计直接引用 ods 层、跳过 dwd/dim 层的下游表数量 -- 数值越接近 0 说明分层建模执行得越好持续上升说明又有人绕过公共层抄近道了 SELECT COUNT(DISTINCT downstream_table) AS cross_layer_table_cnt, -- p a hrefhttps://download.csdn.net/download/hedongsu/87740974 stylecolor:#ec7500;font-size:14px; 本文还有配套的精品资源点击获取 /a img altmenu-r.4af5f7ec.gif srchttps://csdnimg.cn/release/wenkucmsfe/public/img/menu-r.4af5f7ec.gif stylewidth:16px;margin-left:4px;vertical-align:text-bottom;cursor:text; /p 企业数据治理：从数据分类到开发治理一体化
简介这份PDF白皮书面向企业数据管理者、数据平台建设者与数字化转型从业者围绕“数据如何从资源变成资产”这一核心问题展开。内容从数据分类与数据资产定义讲起梳理主数据、业务数据、分析数据的“树干—枝叶—果实”关系进而说明数据治理解决的是找不到、看不懂、信不过、管不住四类现实困境并系统介绍网易数据治理2.0的开发治理一体化、数据中台架构、湖内湖外统一治理、数据治理360、基于ROI的资产精细化管理、持续闭环与DataOps开发底座。资源共1个PDF文件约10.09MB目录完整、层级清晰便于按章节检索末章还给出证券、电信运营商、物流三个行业的落地实践可帮助读者对照自身场景理解治理框架的搭建顺序与落地要点。目前已有721人学习适合需要建立数据治理整体认知或为内部立项寻找参考的读者。1. 数据治理到底在治什么它管的不是数据是人和数据的关系“数据治理”这四个字第一次听见的人多半会理解成“把数据洗干净”或者“建一个大库统一存起来”。真在企业里干过这活的人会告诉你清洗和建库只是动作治理真正要对付的是两件事人和数据之间怎么互相认识人和人之间怎么把同一份数据用到同一个口径上。一份企业级的数据治理白皮书把这件事拆得很细先把企业数据分成主数据、业务数据和分析数据再看数据用不起来时到底卡在哪四个地方最后把治理动作塞回数据开发的流水线上。这条路子值得搞懂因为大多数公司踩的坑几乎一模一样——数据越攒越多能用的反而越来越少。2. 企业的数据到底长什么样树干、树叶和果实的分类法企业里几乎每个人每天都在和数据打交道管理者看报表基层员工填单据运营盯着转化率。可用不好数据的原因往往不在“有没有数据”而在“根本不知道手上这堆东西各是什么、各管什么用”。分类是所有后续动作的前提分不清类型就谈不上治理更谈不上把数据当资产来经营。2.1 主数据、业务数据、分析数据一棵树就能记住主数据是有关业务实体的数据比如雇员、客户、产品、地点。它回答的是“这个对象是谁”为业务交易和分析提供语境信息。一家公司如果客户主数据没管住同一个客户在三个系统里就是三个人后续所有按客户汇总的数字都会出问题。业务数据描述企业的经营活动产品出入库、财务应收、采购、销售都算。它回答的是“发生了什么”是分析数据的原料。业务数据的质量直接决定后面能不能算出可信的结果上游一笔单据录错下游十个报表跟着歪。分析数据来自业务数据的加工反映企业业绩比如销售收入增长、投资回报率。它回答的是“结果如何”是决策的依据也是数据价值真正体现出来的那一层。三类数据不是并列关系而是承载和供养关系。主数据是树干业务数据是枝叶分析数据是枝头的果实叶子离了树干活不了果实靠叶子光合作用供养。脱离主数据谈业务数据和分析数据就像拿着摘下来的叶子讨论它还能不能结果。类型回答的问题典型例子类比缺失时会怎样主数据这个对象是谁客户、产品、地点、雇员树干同一客户在不同系统变成多条记录业务数据发生了什么出入库、应收、采购、销售树叶分析没有原料只能拍脑袋分析数据结果如何收入增长、投资回报率果实决策失去依据价值无法兑现2.2 数据为什么不等于数据资产业内一份被广泛引用的数据资产管理白皮书把数据资产定义为由组织合法拥有或控制的数据资源以电子或其他方式记录例如文本、图像、语音、视频、网页、数据库、传感信号等结构化或非结构化数据可进行计量或交易能直接或间接带来经济效益和社会效益。这个定义里有三根柱子。第一根是主体数据必须有归属归属于某个组织而不是飘在空中的字节。第二根是资源形态数据可以是结构化的表也可以是非结构化的语音和图像判断标准不是长什么样而是能不能被记录和被使用。第三根是价值能直接或间接带来经济效益和社会效益这一条才是“数据”和“资产”之间的分水岭。关键在于这三根柱子不会自动立起来。数据的生成、汇聚、存储、分析、共享每个环节都可能因为管理不当、治理手段缺失而产出低质量数据。低质量数据不但没有价值还会制造错误决策它的破坏力和一条错误的财务报表是同一量级。用树的比喻接着说不健康的树干会影响叶子生长不健康的叶子无法提供足够养分去孕育果实不健康的果实也吃不得。所以企业里数据量和资产量从来不是一回事只有对企业有价值的那部分数据才够格叫资产。这个判断听起来简单落到几十万张表上就变成一道实打实的筛选题。2.3 数据治理是那把钥匙原料、加工线、成品如果把数据比作企业信息化的原料数据治理就是信息化的基石数据资产则是在治理过的数据上挖出来的价值。三者是一条流水线原料进厂、加工线运转、成品出厂跳掉中间那段原料永远只是原料。这条加工线处理的事情说白了是人与人、人与数据之间的关系。一份字段该叫什么名字、由谁定义、口径变了通知谁、谁有权看、看完出问题找谁这些不是技术问题是责任和流程问题。也正因为如此数据治理常常被误当成 IT 部门的私活。实际上它一端连着业务定义一端连着技术实现中间还夹着组织授权。只让技术团队做标准定得再漂亮也落不下去只让业务团队做讨论三个月也产不出一张能用的表。搞清这一点后面的所有问题才有解释的余地。3. 治理要解决的四个字找不到、看不懂、信不过、管不住很多公司都是在某一两年突然集体喊起治理。原因往往不是领导忽然重视了而是业务规模扩张到某个临界点原来靠人肉维持的小数仓撑不住了数据量涨上去问题密度也跟着涨某天一次事故直接把成本算清楚治理就被提上日程。把这些问题归个类基本能收进四个词找不到、看不懂、信不过、管不住。这四个词对应的不是四个工具而是数据从被发现到被使用的完整链条。3.1 找不到几万张表里的大海捞针先看规模。某电商业务线约有 8 万张表某内容业务线约有 4 万张表。越靠近应用层大宽表越多一张表上百个字段非常正常。对一个分析师来说从几万张表里找到自己需要的那一张效率上跟大海捞针差不多。更值得琢磨的是数据地图的使用数据90% 以上的使用者是 IT 人员本来作为目标用户的业务人员几乎不用。这不是工具做得不好而是索引对象错了。地图回答的是“表在哪儿”业务问的是“我要的那个数在哪儿”。业务人员脑子里想的是“上月新客复购率”地图给他的是 dwd_trade_order_detail_v3中间那层翻译工作没人做。找不到的直接后果是重复开发。反正搜不到索性自己建一张建完又没人知道下一波需求再建一张。表的数量于是继续膨胀形成自我加速的循环。3.2 看不懂78% 的表存在元数据缺失即便业务人员找到了表也常常看不懂。有统计显示高达 78% 的表存在元数据缺失缺的主要是管理元数据和业务元数据而这两类恰恰是业务人员判断“这张表能不能用”的关键信息。元数据缺失有明显的结构性原因。技术元数据完整度通常最高因为它能靠系统自动采集表结构、存储位置、分区、任务依赖扫一遍就有。管理元数据和业务元数据与业务强相关必须由业务方配合补充谁负责、什么含义、口径怎么算、什么密级这些系统猜不出来。凡是需要人手工补的缺失率一定高。字段名于是变成了黑匣子。一个叫 amt_pay 的字段可能是实付金额可能是应付金额也可能含税不含税光看名字谁也说不准。开发人员不敢改业务人员不敢用这张表就在那里躺着占着存储等着某天被当成历史包袱清理掉。提示元数据采集工具解决得了“有没有”解决不了“准不准”。业务含义这部分只能靠责任到人靠工具替代不了。3.3 信不过一条上游逻辑改动几十万真金白银质量是数据的生命线。没有质量保障的数据不仅没有价值还会产生错误决策这一点在涉及钱的场景里尤其刺眼。某次电商活动中开发修改了一个上游任务的计算逻辑影响了下游一张涉及资损的表红包超发几十万的损失当场发生。这类教训反复出现指向的其实是同一件事业务方对数据的信任是一次次事故磨掉的。再看日常。对内部工作群的反馈做过统计平均每周有 10 个数据质量问题被反馈“数据违反常识”是听到最多的一句吐槽。更难受的是其中 90% 的问题由数据使用方先于开发方发现数据团队非常被动经常是业务找上门才知道自己出了问题。根子在于质量规则没有跟着开发走。实际开发过程中质量稽核规则的覆盖率只有 10%相同数据项上有 70% 的情况稽核规则不一致阈值设置也不一致。同一张表在不同人手里守护它的规则完全不同甚至有些表根本没规则守着。-- 订单金额稽核金额为负或明显超过 单价×数量都判为异常 -- 1.05 表示允许 5% 的优惠浮动这个数值必须由业务口径确认后写进标准而不是让开发各自拍板 SELECT order_id, pay_amount, unit_price * quantity AS expected_amount -- 理论金额用于人工复核时对照 FROM dwd_order_detail WHERE dt ${bizdate} -- 按天分区跑只稽核当天增量 AND (pay_amount 0 OR pay_amount unit_price * quantity * 1.05);这段 SQL 的逻辑很朴素把明显不可能的值捞出来。真正的关键不在语句本身而在三个参数的来源。dt 决定稽核的时间范围pay_amount 的字段类型、精度、是否允许为负应当来自数据标准而不是临时约定1.05 这个阈值更典型一个人拍 1.05另一个人拍 1.2规则就打架了这正是前面那 70% 不一致的来源。规则一旦挂到数据元上阈值随标准走才谈得上统一。注意稽核规则如果由每个开发自行手写同一张表在不同人手里会得到完全不同的判定结果覆盖率低只是表象判定标准漂移才是根本问题。还有一组数字值得留意经由数据开发任务变更导致的生产环境数据问题占比达到 65%。也就是说大部分事故不是数据天生有问题而是改动引入的。传统治理方式在开发完成之后才介入天然接不住这类事故。3.4 管不住成本黑洞和流于形式的权限数据成本是成本里最容易被忽略的一项因为它不像人力、采购那样有明确账单。但真去盘一遍库存数字往往很扎眼某事业部 78.39% 的表只占了 21.63% 的存储空间而这些表在 30 天内无人访问。报表也一样62% 的报表在 30 天内无人使用平均每张报表每个月还要花掉约 3 万元的成本。资源的滥用还会直接带来稳定性问题。内部记录显示每个月都有 5 次以上事故与资源不合理使用有关比如一个五层嵌套的大 SQL 瞬间把集群压垮殃及所有在同一集群上跑的任务。安全这一侧的矛盾更微妙。企业既希望员工多用数据又要确保不同密级的数据只被对的人看到。权限分配不合理轻则数据误删重则数据泄密权限流程太复杂使用效率又掉下来。一个真实的场景是业务运营想用一张表得先找到表的负责人再联系对方授权整个流程常常耗掉一天。而在授权方那头负责人往往也不清楚该不该给最后权限流于形式只要能找到人就能拿到访问权。四个问题摆在一起看会发现它们不共享同一个工具却共享同一个根源治理动作发生在数据生产出来之后既没有被量化也没有形成闭环。这就是下一章要展开的部分。4. 治理为什么总在事后救火六处断点与把治理前置的思路传统数据治理的流程看起来相当完整定标准、落标准、查质量三步走完似乎就该见效。可真落地之后效果往往打折甚至出现“治理项目做完第二年问题照旧”的尴尬局面。原因不复杂这套流程是围绕存量数据设计的而企业的数据资产每天都在增量。4.1 三大件与定标、落标、稽核老流程是怎么转的传统数据治理包括三大件数据标准、元数据管理、数据质量。流程从制定数据标准开始简称定标接着通过元数据的采集、注册、扫描、发布把数据标准与数据模型连接起来这个过程叫落标最后用数据标准关联的质量稽核规则对数据模型进行稽查发现问题、形成质量报告、推动业务部门整改提升数据质量。这条链路本身是成立的问题是它的作用方向。它更强调对业务系统存量数据的治理对长效机制建设重视不够于是企业只能靠一个又一个治理项目维持效果。项目一停新产生的数据继续脏几个月后又是一轮。更麻烦的是它的成本结构。传统治理是一个反向治理的过程并不融入数据生产的整个过程与数据开发、建模、运维、安全等环节都存在脱节。要做治理就得改造现有系统和流程改造成本高到让很多企业望而却步。4.2 六处断点治理为什么总在事后救火第一处断点在质量与开发之间。质量稽核本是用来确认开发结果符合业务逻辑的但规则覆盖率只有 10%规则设置还各不相同。开发人员对业务的理解深度参差很多人没法从开发结果上判断数据是否满足业务要求问题只好留到使用方那里暴露。久而久之业务方对开发团队的数据不再信任。第二处断点在标准与建模之间。数据标准通常包括标准规划、标准制定、标准发布、标准执行、标准检查五项内容企业也会结合行业情况制定自己的标准。但标准定完之后怎么让开发人员贯彻是另一回事。标准与建模脱节结果就是表的命名不统一、字段命名各行其是数据的理解成本和管理成本一起上升。第三处断点在元数据与开发之间。数据开发时任务之间是有依赖的下游要等上游实例产出。现网环境中任务数量动辄上千甚至上万靠手工配置依赖关系极其考验熟练度也极易出错。一旦漏配任务空跑下游数据就是错的。要自动推荐上游任务靠的正是元数据里的血缘关系而元数据没打通时这件事就只能靠人肉。第四处断点在元数据与运维之间。大量任务同时异常时值班人员需要知道处理先后顺序让重要任务优先恢复也需要知道故障源头在哪因为很多故障是上游异常传导下来的。这两件事都离不开元数据脱节之后运维只能凭经验猜。第五处断点在标准与安全之间。数据权限怎么设、密级怎么定、哪些数据要脱敏、哪些人可以被赋权依据都来自数据标准。标准与安全脱节企业对数据安全的管理就失去了抓手变成盲目审批。第六处断点更宏观是治理与增量之间的断点。前面五处都指向同一个现象治理动作发生在数据已经生产出来之后。数据生产是持续的治理是阵发的两头节奏对不上治理永远在追赶。4.3 烟囱式开发与平台割裂断在架构上的那一半断点不只在流程里也长在架构上。早期数仓建设多由各业务部门自行维护没有上升到组织架构层面规划各部门内部都有零散的数据开发和分析人员服务本团队需求。结果就是一堆分裂的小数仓。这种烟囱式开发的典型症状有三个。一是指标口径不一致缺少统一的规范建模标准各部门存在大量名称相同但口径不同的指标业务人员看数据像猜谜。二是重复开发超过 40% 的表没有分层开发人员接到新需求时无法高效复用已有的表超过 50% 的任务直接读取原始数据每次需求都从头再来。三是资源浪费系统里沉淀了大量长期无人访问的重复数据。平台层面的割裂再补一刀。大型企业的 IT 架构里常有关系型数据库、分析型数据库、数据湖等多套系统各自从后端到前端相互独立、紧耦合开发系统臃肿、建设效率低、响应业务慢。要建统一的大数据开发与治理平台就得面对历史数据和历史任务的迁移成本还得承担迁移过程中的数据遗失风险以及重新培训人员的成本。这些顾虑堆在一起足以让企业对平台化望而却步。4.4 把治理前置开发治理一体化的四个阶段既然断点都在“事后”解法就是把治理动作往前挪。开发治理一体化的核心思想是把数据治理的过程融入数据开发的全生命周期遵循“先设计、后开发先标准、后建模”的原则追求“规范即设计、设计即开发、开发即治理”。整个流程分四个阶段。需求阶段先做业务调研和数据调研。表级调研包括表范围、存储位置、中英文名、来源系统、优先级、更新方式、业务场景、数据条数和增量条数目的是据此制定接入计划确认哪些数据要实时接入、哪些走离线。字段级调研包括表结构、字段类型格式、样例数据、有值行、有值率、是否需要制定标准、是否已挂载标准、值域分布这些信息直接决定后续标准化的效率。同时把指标、模型分层、主题做初步梳理为设计铺路。设计阶段是最重的一块包含标准设计和指标设计。标准规划可以收集现行标准也可以结合自身业务梳理规划时的优先顺序应围绕业务协同、监管合规、数据共享开放、数据分析应用来排非交互、非公开的数据标准化优先级可以放低。标准制定的三件套是词根、标准字典、数据元词根是企业维护的标准词库确保含义相同的中文词翻译成相同的英文名制定过程是拆解、去重、定义最终确定中文全称、英文全称和英文简称标准字典维护枚举字段的标准代码集比如物料类型代码中 5 代表采购物料、10 代表制造物料各业务系统枚举范围不同需要在中台层统一数据元是用一组属性描述定义、标识、表示和允许值的数据单元需要定义中文名称、英文名称、数据类型、数据格式、值域。三者制定完成后整包发布审核通过即可在全系统使用。指标设计要把业务指标拆成原子指标、派生指标和复合指标同时明确数据域、业务过程、修饰词、时间周期。举个具体例子“最近 1 天 PC 端支付金额”拆开就是业务过程为支付修饰词为 PC 端时间周期为最近 1 天原子指标为支付金额指标域归到订单域。指标要经过新建、注册、确权、治理、发布几个环节使用中发现问题可提治理工单业务口径问题派给业务部门技术口径问题派给开发部门修完重新发布并生成新版本。模型设计阶段定义维表、事实表和模型关系把标准落进去导入标准后系统自动填写字段名称、字段描述、数据元、数据字典建表时还能用标准化标签把字段绑定到既定的维度和指标上保证指标和维度不会被各建各的。开发阶段把设计好的模型做物理实现与技术元数据血缘、质量、调度任务信息和标准规范结合。字段类型这块有个容易被忽略的细节不同行业对精度要求不同金融行业对小数点后保留位数和制造业的要求就不一样因此需要一份可自定义的字段类型标准映射规范保证入湖后字段类型统一也减少开发手动调整类型带来的失误。安全也在这一层落地。数据标准里包含业务敏感数据的对象和属性把敏感类型、安全等级、脱敏规则、脱敏算法以及脱敏配置同数据元关联就能快速生成字段级的加密或脱敏规则。模型设计引用了某个数据元数据传输环节就按该数据元的规则做静态脱敏离线开发环节按规则做动态脱敏还能针对不同用户下发不同策略表本身也根据关联数据元的密级获得分类分级依据走对应的资源申请流程。交付阶段把加工好的数据以可视化配置的方式开发成服务数据消费方在 API 集市查看调用说明并申请使用权权限、熔断、限流这些机制在这里兜住交付质量与安全。平台还会统计 API 调用情况结合治理模块盘点 API 资产把闲置 API 和异常 API 挖出来通知负责人整顿。模型质量也需要可量化的标尺。跨层引用是烟囱式开发的典型征兆直接绕过公共层去引用原始层短期省事长期把分层结构彻底冲垮。用跨层引用率这类指标盯着它才能知道治理是不是真的在生效。-- 跨层引用率统计直接引用 ods 层、跳过 dwd/dim 层的下游表数量 -- 数值越接近 0 说明分层建模执行得越好持续上升说明又有人绕过公共层抄近道了 SELECT COUNT(DISTINCT downstream_table) AS cross_layer_table_cnt, -- p a hrefhttps://download.csdn.net/download/hedongsu/87740974 stylecolor:#ec7500;font-size:14px; 本文还有配套的精品资源点击获取 /a img altmenu-r.4af5f7ec.gif srchttps://csdnimg.cn/release/wenkucmsfe/public/img/menu-r.4af5f7ec.gif stylewidth:16px;margin-left:4px;vertical-align:text-bottom;cursor:text; /p