数据治理实践 | 网易某业务线的计算资源治理
Posted
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了数据治理实践 | 网易某业务线的计算资源治理相关的知识，希望对你有一定的参考价值。
本文从计算资源治理实践出发，带大家清楚认识计算资源治理到底该如何进行，并如何应用到其他项目中。
01前言
由于数据治理层面可以分多个层面且内容繁多（包括模型合规、数据质量、数据安全、计算/存储资源、数据价值等治理内容），因此需要单独拆分为6个模块单独去阐述其中内容。
笔者作为数仓开发经常会收到大量集群资源满载、任务产出延时等消息/邮件，甚至下游数分及其他同学也会询问任务运行慢的情况，在这里很多数仓同学遇到这类问题第一想到的都是加资源解决，但事实真不一定是缺少资源，而是需要优化当前问题任务。所以本期从团队做计算资源治理视角出发，带大家清楚认识计算资源治理到底该如何进行。
02问题出现
在做计算治理之前（2022.12）我们团队盘点了下当前计算资源存在的几个问题：
（1）30+高消耗任务：由于数仓前中期业务扩张，要覆盖大量场景应用，存在大量问题代码运行时数据倾斜，在消耗大量集群计算资源下，产出时间也久；
（2）200w+的小文件：当前任务存在未合并小文件、任务Reduce数量过多、上游数据源接入（尤其是API数据接入）会造成过多小文件出现，小文件过多会开启更多数据读取，执行会浪费大量的资源，严重影响性能；
（3）任务调度安排不合理：多数任务集中在凌晨2-5点执行且该区间CPU满载，导致该时间段资源消耗成了重灾区，所有核心/非核心任务都在争抢资源，部分核心任务不能按时产出一直在等待阶段；
（4）线上无效DQC（数据质量监控）&监控配置资源过小：存在部分历史任务没下线表及DQC场景，每日都在空跑无意义DQC浪费资源，同时DQC资源过少导致DQC需要运行过长时间；
（5）重复开发任务/无用任务：早期协助下游做了较多烟囱数据模型，因为种种原因，部分任务不再被使用，烟囱模型分散加工导致资源复用率降低；
（6）任务缺少调优参数&部分任务仍然使用MapReduce/Spark2计算引擎：任务缺少调优参数导致资源不能适配及动态调整，甚至线上仍有早期配置MapReduce/Spark2计算引擎导致运行效率较低。
03思考与行动
3.1 治理前的思考：
在治理之前我想到一个问题，切入点该从哪里开始最合适？
经过与团队多次脑暴对当前治理优先级/改动成本大小/难度做了一个排序，我们先选择从简单的参数调优&任务引擎切换开始->小文件治理->DQC治理->高消耗任务治理->调度安排->下线无用模型及沉淀指标到其他数据资产，同时在初期我们完成各类元数据接入搭建治理看板以及团队治理产出统计数据模型，并通过网易数帆提供的数据治理平台解决具体细节问题。
数据治理平台截图
3.2 治理行动：
（1）大部分任务切换至Spark3计算引擎&补充任务调优参数
补充Spark调优参数（参数内容详见文末），任务统一使用Spark3引擎加速，并充分利用Spark3的AQE特性及Z-Order排序算法特性。
AQE解释：Spark 社区在 DAG Scheduler 中，新增了一个 API 在支持提交单个 Map 阶段，以及在运行时修改 shuffle 分区数等等，而这些就是 AQE，在 Spark 运行时，每当一个 Shuffle、Map 阶段进行完毕，AQE 就会统计这个阶段的信息，并且基于规则进行动态调整并修正还未执行的任务逻辑计算与物理计划（在条件运行的情况下），使得 Spark 程序在接下来的运行过程中得到优化。
Z-Order解释：Z-Order 是一种可以将多维数据压缩到一维的技术，在时空索引以及图像方面使用较广，比如我们常用order by a,b,c 会面临索引覆盖的问题，Z-Order by a,b,c 效果对每个字段是对等的
（2）小文件治理
在这里我们使用内部数据治理平台-数据治理360对存在小文件较多表提供内容展示（本质采集HDFS对应路径下文件数的日志去显示）
当前小文件处理：
对于分区较多使用Spark3进行动态分区刷新，（Spark3具备小文件自动合并功能，如未使用Spark3可配置Spark3/Hive小文件合并参数刷新，参数详见文末），代码如下：
1 set hive.exec.dynamic.partition.mode=nonstrict;
2 insert overwrite table xxx.xxx partition (ds)
3 select column
4 ,ds
5 from xxx.xxx
对于分区较少或未分区的表采用重建表，补数据方法回刷。
小文件预防：
- 使用Spark3引擎，自动合并小文件
- 减少Reduce的数量(可以使用参数进行控制)
- 用Distribute By Rand控制分区中数据量
- 添加合并小文件参数
- 将数据源抽取后的表做一个任务（本质也是回刷分区合并小文件任务）去处理小文件保障从数据源开始小文件不向下游流去
（3）DQC治理
无效DQC下线：难点在于需要查找所有DQC对应的线上任务，查看该DQC任务是否与线上任务一一匹配，从而找到无效DQC任务下线，内容繁杂耗时较多。
DQC资源：由于之前DQC配置资源为集群默认参数，效率极低导致所有DQC运行时长均超过10min，从而使得整体任务链路运行时长过久，调整Driver内存为2048M，Executor个数为2，Executor内存为4096M
（4）高消耗任务调优
这里存在2个难点：优化效果不可控、高消耗任务调整到何种程度算合适，针对这个这个难点我们取所有核心数据资产任务均值，保障单个任务消耗小于平均消耗，同时我们针对当前高消耗任务列举出如下可优化的方式：
- 关联表过多，需拆分
- 关联时一对多，数据膨胀
- 资源配置过多，运行时资源严重浪费，需要将配置调小（包括Driver内存、Executor个数、Executor内存）
- 代码结尾添加Distribute By Rand（），用来控制Map输出结果的分发
- 查询中列和行未裁剪、分区未限定、Where条件未限定
- SQL中Distinct切换为Group by（Distinct会被hive翻译成一个全局唯一Reduce任务来做去重操作，Group by则会被hive翻译成分组聚合运算，会有多个Reduce任务并行处理，每个Reduce对收到的一部分数据组，进行每组聚合（去重））
- 关联后计算切换为子查询计算好后再关联
- 使用Map Join（Map Join会把小表全部读入内存中，在Map阶段直接拿另外一个表的数据和内存中表数据做匹配，由于在Map是进行了Join操作，省去了Reduce运行的效率也会高很多）可用参数代替
（5）任务调度合理优化
对于调度优化一开始会无从下手，统计凌晨2-5点区间下大概600+任务难梳理，同时存在任务依赖，修改起来可能会对下游整体有大的影响，因此我们选择循序渐进先梳理再改善。
- 找到所有表的输出输入点即启始ODS与末尾ADS
- 划分其中核心表/非核心表，及对应任务开始时间与结束时间
- 按照梳理内容把非核心的任务穿插在当前集群资源非高峰时期（2点前与5点后），同时把核心任务调度提前，保障CDM层任务及时产出
- 对实践后内容再度调优，达到资源最大利用率
（6）烟囱任务下沉&无用任务下线
烟囱表过多，需下沉指标到DWS中提升复用性，对于无用任务也需要及时下线（这里需要拿到元数据血缘最好到报表层级的数据血缘，防止任务下线后导致可视化内容问题产生），减少开发资源消耗。
04治理效果
（1）Hive与Spark2任务升级Spark3.1，总计升级任务137个,升级任务后总体任务执行效率提升43%，cpu资源消耗降低41%，内存资源消耗降低46%
（2）治理小文件数大于10000+以上的数仓表总计30+张，小文件总数由216w下降至67w
（3）下线无效DQC任务总计50+，修改DQC配置资源降低运行时长，由原来10min优化至3min内
（4）完成线上20+个任务优化及10+个任务下线及10+表指标下沉，优化后节省任务耗时146分钟，减少CPU损耗800w+，降低内存消耗2600w+（相当于节省了8个200+字段1亿数据量任务消耗）
（5）调度重新分配后2-5点资源使用率由90+%降低至50+%，保障日用资源趋势图无大突刺波动
05小结
计算资源治理核心在于降本增效，用有限资源去运行更多任务，通过一系列治理操作也让数仓同学积累技术经验同时规范化自身开发标准，让治理反推进组内技术进步。
计算资源治理是一件长久之事，并不能因为资源紧张才去治理，而要将计算治理常态化，可通过周/月资源扫描内容及时推送给每个同学，并为之打分，让每个任务都有源可循，有方法可优化。
参数内容
参数并不是设置越多任务性能越好，根据数据量、消耗、运行时间进行调整达到合理效果。
Hive：
（1）set hive.auto.convert.join = true; （是否自动转化成Map Join）
（2）set hive.map.aggr=true; （用于控制负载均衡，顶层的聚合操作放在Map阶段执行，从而减轻清洗阶段数据传输和Reduce阶段的执行时间，提升总体性能，该设置会消耗更多的内存）
（3）set hive.groupby.skewindata=true; （用于控制负载均衡，当数据出现倾斜时，如果该变量设置为true，那么Hive会自动进行负载均衡）
（4）set hive.merge.mapfiles=true; （用于hive引擎合并小文件使用）
（5）set mapreduce.map.memory.mb=4096; （设置Map内存大小，解决Memory占用过大/小）
（6）set mapreduce.reduce.memory.mb=4096;（设置Reduce内存大小，解决Memory占用过大/小）
（7）set hive.exec.dynamic.partition.mode=nonstrict;（动态分区开启）
Spark：
（1）set spark.sql.legacy.parquet.datetimeRebaseModeInRead=LEGACY;（用于spark3中字段类型不匹配（例如datetime无法转换成date），消除sql中时间歧义，将Spark .sql. LEGACY . timeparserpolicy设置为LEGACY来恢复Spark 3.0之前的状态来转化）
（2）set spark.sql.adaptive.enabled=true;（是否开启调整Partition功能，如果开启，spark.sql.shuffle.partitions设置的Partition可能会被合并到一个Reducer里运行。平台默认开启，同时强烈建议开启。理由：更好利用单个Executor的性能，还能缓解小文件问题）
（3）set spark.sql.hive.convertInsertingPartitionedTable=false;（解决数据无法同步Impala问题，使用Spark3引擎必填）
（4）set spark.sql.finalStage.adaptive.advisoryPartitionSizeInBytes=2048M;（Spark小文件合并）
作者简介： 语兴，网易数据开发工程师。
限时开放，免费试用网易数据治理产品
业务数据治理体系化思考与实践
总第508篇
2022年 第025篇
美团住宿数据治理团队从事数据治理工作多年，从最初的被动、单点治理，发展到后来的主动、专项治理，再发展到现在的体系化、自动化治理。一路走来，他们不断进行积累和沉淀，也在持续思考与实践。目前该团队取得了一些阶段性的成果，并得到美团多个业务线的认可和肯定。过程的经验与教训，希望能和大家分享，也希望能给从事数据治理工作的同学带来一些新思路。
一、序言
二、背景介绍
三、治理体系化思考
3.1 什么是数据治理体系化？
3.2 数据治理体系化如何解决目前治理存在的问题？
3.3 业务数据管治体系框架如何建设？
3.4 体系框架如何落地实施？
四、治理体系化实践
4.1 标准化
4.2 数字化
4.3 系统化
五、业务数据治理实施流程
六、总结与展望
一、序言
美团住宿数据治理团队通过多年数仓建设及数据治理的经验沉淀，并结合业务发展阶段对于数据治理的诉求，将治理的思路逐步从专项、表象、问题驱动的治理，转变为自动化、体系化的治理，并从标准化、数字化、系统化三个方向进行了落地与实践。
二、背景介绍
美团住宿业务从2014年上线之后发展多年，历经探索期、进攻期，发展期，并逐步由发展期向变革期过渡。业务从之前的快速扩张阶段进入相对稳定的发展阶段，运营手段转变为精细化运营，同时对数据的成本、效率、安全、价值等方向的要求也越来越高，这些都对数据治理提出了新的要求。
另一方面，住宿数据组所属的数据中心内部有住宿、门票度假等多条业务线，各业务线业务模式不同，所处业务生命周期阶段不同，在数据治理上的认知及经验积累也不同。如何能将数据治理经验及能力高效复用，使数据中心各业务线在数据治理的效率和效果上都能稳步提升，避免踩坑，这就需要数据治理更加标准化、体系化、自动化。
此前，我们在数据治理上已经有了一些积累和沉淀，前一阶段主要从单点、被动的治理转变为主动、专项的治理，治理动作有意识、有规划，也有一定的针对性，且取得了一定的成果（前一阶段的治理经验可参考《美团酒旅数据治理实践》一文），但总的来说仍以问题驱动治理、凭经验治理为主。面对新的数据治理责任及要求，过往的方式存在着一些问题，主要包括以下几个方面。
治理认知差异大
认知不一致，思路不统一：治理缺乏通用的体系指引，不同的治理人对于数据治理的认知深度、问题拆解的方式、治理的思路步骤、采取的方法及其效果追踪等方面，都存在较大的差异。
重复治理、信息不通：治理不彻底、治理经验缺乏沉淀，同样的治理，不同的人反复实行。
范围交叉、边界不清、效果难评估：不同的人针对不同的问题成立不同的专项进行治理，问题的底层逻辑有交叉。有的治理没做什么动作，反而收到了较好的结果，有的治理对于结果说不清。
治理方法不标准
流程规范缺失：对于每个方向、每类问题的治理缺少理论指导，治理的方法、动作、流程、步骤依赖治理人的经验和判断。
问题难度量追踪：治理的问题缺少衡量标准，更多靠人为来进行判断，治理效果缺少评估体系。
解决方案难落地：解决方案存在于文档中，需要治理人查找理解，缺少工具支撑，成本较高。
治理效率低、效果差
治理线上化程度低：治理依赖的资产信息、治理动作都分散于多个系统中，信息碎片化，执行效率低。
过程无法标准化，结果无保障：治理过程需要治理人来“人为保障”，存在理解偏差和执行偏差。
数据管治缺乏体系化
缺乏整体顶层治理方案设计：业务及数据中心对于数据治理的要求，需要治理更全面、更精细、更有效，需要治理的体系化，需要从宏观角度进行思考，层层拆解，需要从整体、从顶层来做方案设计。
问题越来越复杂，单点难解决：过往更多的是从表象去解决问题，从表面来看衡量指标有改善，实际是“头痛医头、脚痛医脚”，并没有从根本上解决问题。或者多个问题具有共性，根本问题是一致的。比如查询资源紧张的根本，可能是分析主题模型建设不足或运营不够。
不同问题的优先级无法确定：不同问题的优先级缺乏衡量标准和方法，主要靠人为判断。
治理不符合MECE原则：每个治理方向由哪些问题组成，哪些最重要，哪些的ROI最高，哪些问题和治理动作可以合并，同一问题在数仓不同主题、不同分层的衡量标准和治理方法应该有哪些差异，都需要在体系化治理中进行考虑。
三、治理体系化思考
从上述背景中不难看出，我们面临着不同业务生命周期阶段对数据建设和治理不同的要求及挑战，同时过往更多的以被动治理、问题驱动的专项治理方式方法也比较落后，这直接导致技术团队很难满足业务方对于财务、业务支持等方面的要求。
通过不断的汲取教训和总结经验，我们开始意识到数据管治是一个非常复杂的综合性问题，只有构建出一套标准的业务数据管治体系，才能确保数据治理在现状评估、目标制定、流程规范建设、治理监控管理、能力建设、执行效率、效果评价等各环节有效落地。下面介绍一下我们在治理体系化层面的理解和思考。
3.1 什么是数据治理体系化？
针对数据管理和治理，我们期望搭建一套集管理体系、方法体系、评价体系、标准体系、工具体系等核心能力的组合，持续服务于数据管治实施。可以类比一般的电商公司，如果需要运转并服务好顾客，它首先必须搭建起来一套销售体系、产品体系、供给体系、物流体系、人力体系等等，只有这样才可以相互配合，实现服务好用户这一大目标。
3.2 数据治理体系化如何解决目前治理存在的问题？
方式方法上：先做顶层治理框架设计，从团队整体视角定义和规划好治理的范围、人员、职责、目标、方法、工具等必须部分，再进行落地。更关注整体策略的普适性及有效性，而非深陷某个具体问题解决方案开始治理。
技术手段上：以完善的技术研发规范为基础，以元数据及指标体系为核心，对业务数仓和数据应用进行全面评价和监控，同时配套治理系统工具，帮助治理同学落地治理策略和解决数据开发同学治理效率低问题。
运营策略上：通过对待治理问题进行影响范围、收益情况进行评估，确定待治理问题的重要度，从管理者视角以及问题责任人视角2个途径推动不同重要程度的治理问题解决。
3.3 业务数据管治体系框架如何建设？
我们的建设思路是：以团队数据治理目标为核心导向，设计实现目标需要的相关能力组合，并根据组织要求，实施过程的问题反馈，持续不断地迭代完善，最终实现数据治理的愿景。
体系框架主要包含以下内容：
管理层：立法，制定相关的组织保障流程规范、职责设计、奖惩措施，指导和保障数据治理顺利进行，这是数据治理能够成功启动运转的关键因素。
标准层：设标准，制定各类研发标准规范、解决方案标准SOP等数据治理过程中需要的各类技术规范和解决方案，这是所有技术问题正确与否的重要依据，也是治理中事前解决方案必不可少的一部分。完善的标准规范和良好的落地效果，可很好地降低数据故障问题的发生量。
能力层：完善能力，主要是基于元数据的问题度量的数字化能力，以及问题工具化检测和解决的系统化能力。数字化和系统化能力是数据治理实施的科学性、实施的质量及效率的重要保障。
执行层：设定动作，结合要达成的具体目标，对各治理域问题，按照事前约束、事中监控、事后治理的思路进行解决。目标的达成，需要拆分到7大治理域相关的具体问题中去落地。因此，一个治理目标的达成，很依赖治理域对问题描述的全面性及深度。
评价层：给出评价，基于指标的问题监控，健康度评价体系，专项评估报告，评价治理收益及效果，这是实施治理推进过程监控，结果检验的重要抓手。
愿景：长期治理目标，指导数据管治有方向地不断朝着最终目标前进。
体系框架建设成果：业务数据治理体系框架是针对数据治理工作整体做的顶层方案设计，框架定义好了业务线数据治理是什么、怎么做、做什么、用什么工具以及达成什么目标。拉齐各方对业务数据治理的认知，标准化治理路径方法和组成部分，指导数据治理有序、有效地进行。
3.4 体系框架如何落地实施？
参照业务线数据标准化管治体系框架各组成部分特点，我们具体通过标准化、数据化、系统化3大部分能力建设及运营，来实现数据管治体系框架的落地，并应用在数据治理问题的解决中，最终拿到可量化的结果。
四、治理体系化实践
4.1 标准化
数据治理标准化是企业进行数据资产管理的关键突破口和重要手段，一系列政策、法规、规划需要转化为标准和制度才能有效落地。数据治理标准化既有利于建立健全各种数据管理工作机制、完善业务流程，又有利于提升数据质量，保障数据安全合规使用，释放数据价值。但在数据治理标准化建设过程中，我们经常会面临以下三个问题：
流程规范缺失：各个环节缺少标准和约束来指导规范化操作，无法有效杜绝问题的发生、解决。
落地条件差：规范标准、SOP等不具备落地条件，靠主观意愿，无法有效落地，效果差。
建设方法不合理：规范建设Case by Case，缺少体系化建设思路导致“一直建、一直缺”。
针对上述三个问题，我们从解决问题的视角出发，划分数据开发流程，通过事前约束、事中监控、事后分析评估的思路，整理补齐缺失的流程规范，从而实现标准流程规范在数据管治各环节全覆盖，并建设系统化工具来保障标准规范的落地实施。下文将分别从规范建设及工具保障两方面来介绍我们在数据治理标准化过程中是如何解决上述问题的。
4.1.1 规范建设
规范是数据治理建章立制的基础，针对标准规范建设不合理及流程规范缺失的问题，我们用体系化的建设思路从整体架构上对数据开发流程及数据治理流程进行划分，并针对全流程数据管治各个环节建设相应规范：
数据治理管理规范：明确数据治理组织职责以及人员构成，确定数据治理实施流程及治理问题运维流程，以保障数据治理过程顺利进行。
数据研发规范：明确数据开发各个环节需要遵守的规范要求，从问题产生的源头，通过建设完善的研发规范，指导研发工作按标准进行，一定程度上可减少问题发生。
数据标准化治理SOP：明确各个治理问题治理动作，确保治理动作是标准且可实施。
数据健康度评估规范：明确治理效果的评价标准，对数据体系做到长期，稳定及指标化的衡量。
4.1.2 工具保障
标准规范可视化-知识中心
在标准规范的共享方面，以往技术团队在实际规范落地过程中可能存在以下问题：
规范找不着：重要规范文档散落在各个Wiki空间，导致使用时无法快速查找，效率低下。
规范质量差：文档没有统一进行维护，无法持续进行迭代和完善，不能随着业务及技术的发展更新。
规范没权限：文档散落在各个成员的私人空间内部，未对所有人开通权限，优质内容无法及时共享。
针对上述问题，我们重新收集整理已有规范文档并进行分类，补充缺失文档，优化文档内容，并新增知识中心模块，将知识体系框架产品化，在产品层面维护统一的入口及权限管理，同时严格控制发布流程，解决了标准规范在实际落地时“找不着”、“质量差”、“没权限”等问题。
测试规范工具化-八卦炉
在数据测试规范落地方面，以往数据测试规范都是通过Wiki维护，无法约束大家实际执行过程，导致数据质量较差，容易出现数据故障。为减少数据开发过程中由于测试不规范而导致数据故障的情况，提升数据质量及业务满意度，我们利用数据中心与数据平台工具组合作共建的ETL测试工具（美团内部工具-八卦炉）来保障测试规范SOP落地执行，要求大家在不影响测试验数效率情况下充分测试，实现数据治理问题在事前约束，减少事后问题量，保障数据质量，工具建设如下图所示：
治理提效保质工具-SOP自动化工具
在日常数据开发工作中，数据工程师会承担一部分数据治理工作，以往都是通过执行数据治理SOP中每个步骤对问题进行治理，但经常会面临以下几个问题：
治理效率低：需要根据SOP中治理经验，去各个平台分别执行相应治理动作，对于一些步骤较为复杂的SOP，需要跳转多个平台操作，治理效率较低。
治理过程无法约束：治理经验浮于文字，无法约束数据工程师的执行动作，导致部分问题治理不彻底。
基于上述问题，我们开发了治理提效工具-SOP自动化工具，汇总多个平台治理工具，将数据治理标准化SOP的各个执行步骤通过工具落地，实现在一个工具内一站式治理能力，约束工程师的治理动作，确保整个治理过程是标准的，效果是可监控的，从而提升了治理效率及治理质量。
比如无效任务的治理，首先需要调研问题治理经验并沉淀至SOP文档，然后将SOP文档中各个执行步骤依次通过自动化的工具进行配置。数据工程师在治理时只需要在一个界面内即可实现全部的治理动作，下图是无效任务治理SOP及美团的自动化工具：
4.1.3 标准化收益及建设经验
通过数据治理标准化建设，我们解决了团队在数据治理规范方面若干问题，取得了明显效果：
实现了数据开发、数据治理的标准化，解决了团队内各小组之间在开发、管理、运维方面流程方法标准不一致的问题。
通过测试工具对标准化测试规范进行落地，在事前阻塞问题发生，提升数据质量，减少故障发生。
通过SOP自动化工具，有效保障治理过程的标准化，解决了治理效果差的问题。
同时，我们在实际建设的过程中，也总结了一些标准化的建设经验：
标准规范如何落地，需成为标准流程规范建设的一部分，最好有交付物。
标准规范的制定，除常规内容外，需要综合考虑组织目标、组织特点、已有工具、历史情况、用户反馈等因素，否则会给人“不接地气”的感觉。
标准规范的制定要优先考虑利用和适配已有工具能力，借助工具落地，而非让工具适配流程规范。
4.2 数字化
以往大家在开展数据治理工作时主要依赖经验判断，缺乏科学可量化的抓手，对治理问题的严重程度无法准确感知，同时对治理收益的回收也不能准确评估。因此我们开展了数字化的工作，将大家数据开发工作用数据描述，构建整个数据开发工作的准确视图。
4.2.1 数字化架构设计方案
建设思路：通过对数据生命周期各环节进行类比业务数仓建设中抽象和描述业务对象方式，进行元数据对象的抽象和描述，并建设成元数据数仓和治理指标体系，应用在数据管治场景。
框架主要包含元数据仓库、指标体系、数据资产等级以及基于元数仓基础上建立的各个数据应用，利用元数据驱动数据治理及日常团队管理，避免过多依赖经验解决问题，更好地服务业务。下边几个章节将分别介绍数字化框架最核心的数据内容：元数据仓库、指标体系、数据资产等级。
4.2.2 元数据仓库建设
元数据是描述数据的数据，包含数据资产种类、数据存储大小、数据流血缘关系、数据生产过程等信息，存在信息种类多，分布零散，信息不完整的特点。丰富的元数据有助于我们快速了解团队数据资产，让数据资产更加精准，透明。为数据使用和价值释放提供支撑。
我们的建设思路，采取数据业务化、业务数字化、数字应用化的思路来搭建元数据仓库。
数据业务化：即将数据工程师日常数据开发工作业务化描述，抽象多个业务过程，如需求提出、任务开发、数据表产出、数据应用、需求交付。
业务数字化：用建设业务数仓的思路和方法，对数据业务化之后的各个业务过程及主题，搭建元数据数仓及指标衡量体系，并通过元数据场景化应用提升易用性及丰富度。
数字应用化：在元数据仓库基础上开发数据产品，驱动数据管治实施。
通过数据业务化思路，我们抽象业务域、管理域、技术域等3大主题域来描述元数仓对象，并对每个主题域进行细分，划分多个主题：
业务元数据：基于具体业务逻辑元数据，常见业务元数据包括业务定义、业务术语、业务规则、业务指标等。
技术元数据：描述了与数据仓库开发、管理和维护相关数据，包括数据源信息、数据仓库模型、数据清洗与更新规则、数据映射和访问权限等，主要为开发和管理数据仓库的工程师使用。
管理元数据：描述管理领域相关概念、关系和规则的数据，主要包括管理流程、人员组织、角色职责等信息。
在元数仓分层上，我们采用最常见的四层架构分层方式，分别是贴源层、明细层、汇总层、应用层和维度信息。区别于业务数仓分层设计方式，从明细层就按维度建模思路组织数据，避免过度设计，只需要做好主题划分和解耦。在汇总层从分析习惯出发耦合数据，提升易用性。应用层按需创建所需接口支撑应用。
目前，我们已完成元数据仓库技术域、管理域、业务域部分内容的建设，并已支撑指标体系及上层多个数据应用，未来仍将根据大家在实际工作中核心关注的内容对元数仓进一步补充和完善。
4.2.2 指标体系建设
一个问题的衡量需要从多方面进行考虑，只用一个指标无法充分说明问题，这就需要一组有逻辑且相互关联的数据指标来描述问题。在数据开发过程中，需要制定多个指标来监控衡量数据开发团队在质量、安全、效率、成本等方面存在的问题。
此前，住宿数据团队没有一套成熟稳定的指标体系，无法长期准确衡量团队的业务支持能力、技术能力。2020年，我们在元数据仓库基础上搭建了数据治理指标体系，全面衡量了业务数仓建设过程中各类问题，通过指标体系监测工作中的优点与不足，提升了团队的工作能力，进而提高了对业务的支持能力。
建设方案
指标体系的建设目标是监控团队工作状态和变化趋势，需要能够覆盖到工作中的各个方面。因此，在指标体系的建设上，我们通过不同视角对指标体系进行分类，做到不重不漏全覆盖，让指标适用于不同使用场景：
生命周期视角：从数据本身出发，衡量数据从生产到销毁的各个过程，包括定义、接入、处理、存储、使用、销毁等等。
团队管理目标视角：根据团队管理核心要达成的目标分类，包括质量、效率、成本、安全、易用性、价值等等。
问题对象视角：根据治理问题核心关注的对象分类，包括安全、资源、服务、架构、效率、价值、质量等等。
建设成果
目前我们已建设技术、需求及故障三大类指标共计112个，全面覆盖数据开发中的各个环节：
技术类指标：覆盖成本、质量、安全、价值及易用性5个方面共57个指标。
需求类指标：覆盖新增、响应、开发、上线及验收等7个方面共36个指标。
故障类指标：覆盖故障发现、原因定位及处理环节共19个指标。
元数据及指标体系应用：
团队管理：帮助团队管理者快速了解团队情况，提升管理效率。
数据治理：利用元数据及指标体系驱动数据治理，为数据治理提供可量化的抓手。
项目评估：帮助项目成员准确评估项目的问题、进展及收益。
建设思考
在指标建设过程中，我们沉淀了以下几点经验：
指标体系既要解决管理者对日常工作无抓手的问题，也要成为具体问题处理人员的治理抓手，兼顾管理者和开发者。
指标体系是展示偏整体层面的内容，还需通过指标解决实际问题，形成指标体系和数据治理工具闭环，实现发现问题、治理问题、衡量结果持续循环。
优先确定团队总体发展目标，从目标拆分设定指标，指标尽量覆盖不同业务线不同发展阶段。
业务需要明确自己所处阶段，针对不同阶段，制定考核目标，衡量阀值，既统一了衡量标准，又中和了大家考核标准。
指标需注意分层建设，避免“胡子眉毛一把抓”，便于适配目前的组织结构，也便于划分责任与定位。
基础指标体系建设完成后，可作为平时管理和工作的抓手，作为项目发起的依据，作为项目结果评估的手段。
4.2.3 资产等级建设
随着业务快速发展，团队负责的数据资产规模也日益扩大。截止当前，团队共负责离线Hive表3000+，ETL生产任务2000+，人均负责ETL生产任务100+。在面对规模日益扩大的数据资产，团队管理者及数据工程师通常会遇到以下问题：
只能评经验判断哪些是核心资产，遇到问题无法评估解决的优先级。
核心链路的保障，比如SLA及DQC的配置范围缺少科学的评估手段。
管理者对团队核心资产缺乏准确的判断，无法准确有效的做出管理动作。
为丰富元数据之间的关系和内容，挖掘识别更有价值的数据信息，以元数据能力驱动数据研发及运维日常工作，在元数据仓库的基础上我们做了衍生能力即资产等级的建设。资产等级可以对数据的重要性进行科学有效地评估，也可帮助完善数据质量分级监控方案，从而实现对重点任务的重点保障。
下图是数据资产等级通用计算流程，我们首先根据资产类型确认各个影响因子及影响权重值，划分影响因子重要性等级，其次根据各个影响因子数值范围划分得分区间，最后汇总计算得到最终资产等级得分及资产等级结果，并抽样验证结果的准确性。
资产等级建设（数据表）
下图是针对数据表资产等级建设的方法和流程图：
1）确定影响因子及权重评估
影响因子的确定是资产等级计算中最为关键一环，合理评估影响因子对最终资产等级结果的准确性至关重要。根据实际数据开发中经验可知，影响数据表重要程度主要有以下几个关键因素：
下游类型：决定下游资产重要程度，下游资产类型一般有ETL任务和数据产品两类，ETL任务及数据产品又根据重要度分为普通型及VIP型。
下游数量：决定是否是关键节点，对下游生产的影响范围，下游数量越多表明影响范围越大。
使用热度：决定是否有用，影响查询用户的范围，热度越高表明影响的用户范围越广。
链路深度及分层：决定问题的修复时间，链路越深，问题修复的时间可能就越长。
确定好影响因子之后，我们需要判断每个影响因子所占的权重值。我们采用层次分析法来计算权重值（层次分析法主要应用在不确定情况下及具有多数个评估准则的决策问题上，具体计算步骤，大家可查阅相关的资料），其优点是把研究对象作为一个系统，按照分解、比较判断、综合的思维方式进行决策，而且计算过程简洁实用。
2）计算资产等级得分
根据实际情况对每个影响因子划分得分区间，并结合每个影响因子权重值，可以计算得到资产等级最终得分。总得分为各影响因子得分与对应权重乘积加和。
3）资产等级映射
我们将资产等级最终得分划分区间至L1 ~ L5，L5为最高资产等级，L1为最低资产等级。
资产等级应用场景（数据表）
目前，资产等级已运用到日常管治实施，为数据分级管治提供了有力的抓手：
4.3 系统化
4.3.1 数据百品-管治中心
除了标准化和数字化之外，我们数据治理体系落地仍面临诸多问题：
数据资产无法统计和描述，管理者及数据工程师不知道有什么，缺乏资产的可视化。
管理者缺少抓手发现团队的问题，且问题难以追踪。
治理线上化程度低，需要跳转多个工具，治理效率低，治理过程无法标准化，导致结果无法保障。
针对上述问题，我们搭建了数据百品-管治中心治理平台（美团内部产品），实现了集资产管理、问题分析监控、自动化治理、过程追踪、结果评价的一站式、全覆盖数据治理平台，能有效提升治理质量和效率，为数据质量提升做好强有力的支撑。通过“管+治”相结合的理念，分别从管理者及研发人员的视角对数据、人效等问题实现全面监控，并实现了资产全景、管理中心、治理中心三大模块：
资产全景
资产全景从管理者+数据RD视角出发，介绍了当前数据现状即有什么的问题，帮助业务线管理者及数据RD实现数据资产可视化，为管理者提供技术管理的抓手，为数据RD提升数据探查和数据使用效率。包含资产大盘、资产目录、个人资产三个子模块：
资产大盘：从业务线管理者视角出发，展示了业务线内各类资产概览，帮助管理者一站式快速了解组内数据资产，无需跳转多个平台。
资产目录：展示团队数据各资产类型及明细，为数据RD数据使用提供信息支撑，提升RD数据探查效率。
个人资产：从归属人视角，展示数据RD个人及小组名下数据资产数量和资产类型及数据明细，详细描述个人资产信息。
管理中心
数据团队管理者在日常团队管理中时经常会面临两个问题：
管理手段多依赖经验判断，当团队需求承接增加、团队人数增加时会带来管理难度的提升，管理者缺少抓手快速看到团队的整体情况。
管理动作天级别。管理者发现团队某核心指标异常（例如：故障数），需要找对应的责任人询问，无法从系统上快速进行异常追踪，原因获取。
管理中心主要从管理者视角出发，解决了怎么管的问题，通过管理者关注的核心指标，为管理者提供监测团队状态、判断团队问题、辅助管理决策的能力，让管理者从“依赖经验管理”转变为“数据驱动管理”。包含管理者大盘、运维管理、需求管理、团队管理四大模块：
管理者大盘：向管理者提供团队核心指标总览、问题趋势分析、异常明细追踪、异常原因标记等功能，方便管理者快速了解团队情况，及时做出管理动作。
需求管理：提供详细的人效分析大盘以及需求管理功能，服务于人效管理及提效。
故障管理：提供详细的故障分析大盘以及故障复盘管理能力，提升故障管理效率。
团队运营：团队周月报，值班，满意度问卷等团队运营需要的能力，提升运营效率。
治理中心
日常数据治理过程中，问题责任人解决问题主要有以下痛点：
不了解分配给自己的待治理问题背景、目标和重要程度。治理工作成为盲目去完成分配的任务，即使完成了治理动作，可能依然无法保证是否真正达到治理目标，尤其是面对同时需要处理多类治理问题时，效果差。
数据治理解决问题时通常要使用各类工具互相辅助才能解决，问题多了之后，治理问题变成了重复使用不同的工具，严重影响治理效率和效果。
治理中心从问题责任人视角出发，解决了怎么治的问题，为一线治理工程师提供从问题评估分析，到治理，到进度监控的一站式治理能力。将治理工作精细化、常态化运营，提升了数仓治理质量和效率。包含治理概览、分析评估、问题治理、进度监控四大模块。
治理概览：治理中心首页，介绍了团队数据治理体系框架及标准化治理成果，让使用者在认知上与治理中心的治理理念一致，并提供数据治理优秀解决方案。
分析评估：对七大类治理问题进行量化评估，提供治理优先级及问题排名，让用户了解应该先做什么。
问题治理：提供丰富治理指标，全面衡量治理问题，问题分配及时通知，并利用SOP自动化工具，实现对解决问题过程的标准化，保障治理效果，提高治理效率。
进度监控：提供问题治理进度看板及问题分配进度监控，便于管理者宏观把控问题治理进度，合理规划分配节奏。
4.3.2 SOP自动化工具
在日常数据治理过程中，每个团队都会沉淀若干SOP规范文档来指导大家进行问题治理，减少问题发生。但是在SOP的落地上，依然存在很多问题：
SOP一般以Wiki形式存在，实际执行过程无法跟踪约束。
SOP动作的执行需要跳转多个平台系统，执行效率低下。
建设方案
基于上述问题，我们开发了SOP自动化配置工具。SOP自动化工具是一款SOP配置工具，适用于问题治理类SOP，将治理动作通过工具进行配置以提高治理效率，进而保证过程质量和结果质量。目标是解决SOP规范文档在落地过程中遇到的执行效率低、过程无法跟踪监控的问题，实现一站式解决问题的能力。
SOP自动化工具主要包含基础组建层、配置层及应用层，以下是产品架构图及产品界面：
基础组建层：SOP最小粒度模块，包括展示类组件（富文本、表格、IFrame），逻辑控制类组件（单选、多选），用户可根据SOP内容选择多个基础组件组合。
配置层：配置SOP中使用参数信息及执行步骤。
应用层：SOP最终效果展示，通过URL接口对外提供服务，比如治理中心可调用SOP工具接口实现一站式治理能力。
SOP实际操作步骤如下：
用户在创建SOP后可选择性配置需要展示的数据信息，然后按照SOP执行步骤依次拖动各个基础组件，并填写执行操作完成SOP的配置工作，在效果预览完成后即可发布上线并生成外嵌URL。自动化工具主要通过外嵌的形式对外提供服务。
应用场景
通过SOP自动化工具，数据治理已实现了问题解决过程线上化、步骤标准化，很好地保障了治理效果，提升了治理效率。下图是无效存储指标在使用SOP自动化工具前后的流程对比，通过对比，我们可以看到之前工程师需要人工确认若干信息，并跳转多个平台操作，现在只需要在一个界面完成所有动作，极大地减轻了研发人员的工作量。
目前，我们团队已完成7大治理域内30多个指标的治理SOP建设，并均已通过自动化工具落地。后续，我们仍将探索其他专项治理内容，并利用SOP自动化工具辅助开展数据治理的工作。
4.3.3 经验总结
通过数据治理系统化的建设，我们总结了以下几点：
系统化是将解决问题的方法从线下到线上，从散点动作到连贯动作的一种有效解决方案。
没有完美的系统，也不必追求完美，考虑投入产出比，快速解决主要矛盾，应用到具体问题解决中。
产品定位设计，产品长远规划的能力设计尤为重要，否则容易出现“做着做着不知道做什么，不知道往什么方向发展”的情况。
五、业务数据治理实施流程
数据治理实施流程，是我们依据业务数据治理标准化框架在实施解决具体数据问题时，总结抽象出来的一套适用于大多数治理场景解决问题的通用标准流程。标准流程的好处在于更加规范化数据治理工程师的操作流程，来保证实施的质量。流程一共包含5个步骤：
STEP 1：发现问题和制定目标，发现问题要从业务数据开发团队的视角出发，围绕服务好业务、遵守数据研发规范、收集好用户反馈，尽可能全地发现和收集相关需要解决的问题。同时，制定的目标要具备可实现性。
STEP 2：针对问题进行拆解，设计可衡量的指标，并通过元数据的采集建设进行实现，用做对目标的进一步量化，并作为实施过程监控及治理抓手。
STEP 3：对衡量出来的具体问题，制定相关的解决SOP，并且检查相应的研发标准规范是否完善，通过问题发生的事前、事中、事后几个阶段，建设或完善相应的工具化解决问题的能力。
STEP 4：推广运营，以拿结果为核心目标，针对不同角色运用不同策略，重点关注问题解决过程是否会与用户利益发生冲突，控制好节奏，根据问题的重要程度有规划地进行解决。
STEP 5：总结沉淀方法论，迭代认知，持续探索问题的最优解，优化治理方案和能力。
六、总结与展望
经过在数据治理体系化建设上的持续思考与实践，我们的体系化框架基本建立，在数据治理的标准化、数字化和系统化三个方向上取得了较大的进展，并且在业务应用上取得了一定的成绩。更重要的是，我们在数据成本、安全、效率等多个领域都帮助业务解决了实际的问题，尤其是在成本方面，预计每年可以帮助业务可节省数百万的成本，获得了业务方的肯定。
但对比“理想终态”，我们的工作仍任重道远。数据治理体系化框架这个庞大“身躯”中的各个血脉、骨骼、脏腑还需要持续充盈，在流程规范、元数据数仓、指标体系、资产分级等的建设过程中，还有很多需要靠专家经验、人为判断、人工操作串联的场景存在。下一步，我们将在智能化（如智能化元数据服务、智能化数据标准建设等）、自动化（基于治理框架的治理应用场景的线上化建设等）等方面发力。
七、作者简介
王磊、有为、尉斌等，均来自美团数据科学与平台部。
---------- END ----------
也许你还想看
阅读更多
---
以上是关于数据治理实践 | 网易某业务线的计算资源治理的主要内容，如果未能解决你的问题，请参考以下文章