数据治理体系化思考与实践
The following article is from 美团技术团队 Author 王磊 有为 尉斌
傅一平评语:
这篇文章最有价值的内容是数字化实践中的元数据仓库章节,我从中获得了三个启示:
1、人类总是喜欢研究外部世界,但后来发现连自己还没研究明白,同样的道理,我们数据从业者一天到晚想着用数据(比如业务的数仓建模)去驱动别人的业务,但却忘了如何用数据驱动自己的业务(比如让自己的数据运营效率更高),我们要对自己好一点
2、基于技术元数据构建分主题的数仓模型体系让数据组织对于自己的业务流程(需求提出、任务开发、数据表产出、数据应用、需求交付等等)有了更清晰的理解,这是提升数据运营的关键,正如我们对业务做的一样
3、这篇文章的元数据仓库主题、元数据仓库分层、元数据仓库建设成果及由此建设的指标体系,都具有借鉴意义。
正文开始
一、序言
二、背景介绍
三、治理体系化思考
3.1 什么是数据治理体系化?
3.2 数据治理体系化如何解决目前治理存在的问题?
3.3 业务数据管治体系框架如何建设?
3.4 体系框架如何落地实施?
四、治理体系化实践
4.1 标准化
4.2 数字化
4.3 系统化
五、业务数据治理实施流程
六、总结与展望
一、序言
二、背景介绍
认知不一致,思路不统一:治理缺乏通用的体系指引,不同的治理人对于数据治理的认知深度、问题拆解的方式、治理的思路步骤、采取的方法及其效果追踪等方面,都存在较大的差异。 重复治理、信息不通:治理不彻底、治理经验缺乏沉淀,同样的治理,不同的人反复实行。 范围交叉、边界不清、效果难评估:不同的人针对不同的问题成立不同的专项进行治理,问题的底层逻辑有交叉。有的治理没做什么动作,反而收到了较好的结果,有的治理对于结果说不清。
流程规范缺失:对于每个方向、每类问题的治理缺少理论指导,治理的方法、动作、流程、步骤依赖治理人的经验和判断。 问题难度量追踪:治理的问题缺少衡量标准,更多靠人为来进行判断,治理效果缺少评估体系。 解决方案难落地:解决方案存在于文档中,需要治理人查找理解,缺少工具支撑,成本较高。
治理线上化程度低:治理依赖的资产信息、治理动作都分散于多个系统中,信息碎片化,执行效率低。 过程无法标准化,结果无保障:治理过程需要治理人来“人为保障”,存在理解偏差和执行偏差。
缺乏整体顶层治理方案设计:业务及数据中心对于数据治理的要求,需要治理更全面、更精细、更有效,需要治理的体系化,需要从宏观角度进行思考,层层拆解,需要从整体、从顶层来做方案设计。 问题越来越复杂,单点难解决:过往更多的是从表象去解决问题,从表面来看衡量指标有改善,实际是“头痛医头、脚痛医脚”,并没有从根本上解决问题。或者多个问题具有共性,根本问题是一致的。比如查询资源紧张的根本,可能是分析主题模型建设不足或运营不够。 不同问题的优先级无法确定:不同问题的优先级缺乏衡量标准和方法,主要靠人为判断。 治理不符合MECE原则:每个治理方向由哪些问题组成,哪些最重要,哪些的ROI最高,哪些问题和治理动作可以合并,同一问题在数仓不同主题、不同分层的衡量标准和治理方法应该有哪些差异,都需要在体系化治理中进行考虑。
三、治理体系化思考
3.1 什么是数据治理体系化?
3.2 数据治理体系化如何解决目前治理存在的问题?
方式方法上:先做顶层治理框架设计,从团队整体视角定义和规划好治理的范围、人员、职责、目标、方法、工具等必须部分,再进行落地。更关注整体策略的普适性及有效性,而非深陷某个具体问题解决方案开始治理。 技术手段上:以完善的技术研发规范为基础,以元数据及指标体系为核心,对业务数仓和数据应用进行全面评价和监控,同时配套治理系统工具,帮助治理同学落地治理策略和解决数据开发同学治理效率低问题。 运营策略上:通过对待治理问题进行影响范围、收益情况进行评估,确定待治理问题的重要度,从管理者视角以及问题责任人视角2个途径推动不同重要程度的治理问题解决。
3.3 业务数据管治体系框架如何建设?
管理层:立法,制定相关的组织保障流程规范、职责设计、奖惩措施,指导和保障数据治理顺利进行,这是数据治理能够成功启动运转的关键因素。 标准层:设标准,制定各类研发标准规范、解决方案标准SOP等数据治理过程中需要的各类技术规范和解决方案,这是所有技术问题正确与否的重要依据,也是治理中事前解决方案必不可少的一部分。完善的标准规范和良好的落地效果,可很好地降低数据故障问题的发生量。 能力层:完善能力,主要是基于元数据的问题度量的数字化能力,以及问题工具化检测和解决的系统化能力。数字化和系统化能力是数据治理实施的科学性、实施的质量及效率的重要保障。 执行层:设定动作,结合要达成的具体目标,对各治理域问题,按照事前约束、事中监控、事后治理的思路进行解决。目标的达成,需要拆分到7大治理域相关的具体问题中去落地。因此,一个治理目标的达成,很依赖治理域对问题描述的全面性及深度。 评价层:给出评价,基于指标的问题监控,健康度评价体系,专项评估报告,评价治理收益及效果,这是实施治理推进过程监控,结果检验的重要抓手。 愿景:长期治理目标,指导数据管治有方向地不断朝着最终目标前进。
3.4 体系框架如何落地实施?
四、治理体系化实践
4.1 标准化
流程规范缺失:各个环节缺少标准和约束来指导规范化操作,无法有效杜绝问题的发生、解决。 落地条件差:规范标准、SOP等不具备落地条件,靠主观意愿,无法有效落地,效果差。 建设方法不合理:规范建设Case by Case,缺少体系化建设思路导致“一直建、一直缺”。
4.1.1 规范建设
数据治理管理规范:明确数据治理组织职责以及人员构成,确定数据治理实施流程及治理问题运维流程,以保障数据治理过程顺利进行。 数据研发规范:明确数据开发各个环节需要遵守的规范要求,从问题产生的源头,通过建设完善的研发规范,指导研发工作按标准进行,一定程度上可减少问题发生。 数据标准化治理SOP:明确各个治理问题治理动作,确保治理动作是标准且可实施。 数据健康度评估规范:明确治理效果的评价标准,对数据体系做到长期,稳定及指标化的衡量。
4.1.2 工具保障
标准规范可视化-知识中心
规范找不着:重要规范文档散落在各个Wiki空间,导致使用时无法快速查找,效率低下。 规范质量差:文档没有统一进行维护,无法持续进行迭代和完善,不能随着业务及技术的发展更新。 规范没权限:文档散落在各个成员的私人空间内部,未对所有人开通权限,优质内容无法及时共享。
测试规范工具化-八卦炉
治理提效保质工具-SOP自动化工具
治理效率低:需要根据SOP中治理经验,去各个平台分别执行相应治理动作,对于一些步骤较为复杂的SOP,需要跳转多个平台操作,治理效率较低。 治理过程无法约束:治理经验浮于文字,无法约束数据工程师的执行动作,导致部分问题治理不彻底。
4.1.3 标准化收益及建设经验
实现了数据开发、数据治理的标准化,解决了团队内各小组之间在开发、管理、运维方面流程方法标准不一致的问题。 通过测试工具对标准化测试规范进行落地,在事前阻塞问题发生,提升数据质量,减少故障发生。 通过SOP自动化工具,有效保障治理过程的标准化,解决了治理效果差的问题。
标准规范如何落地,需成为标准流程规范建设的一部分,最好有交付物。 标准规范的制定,除常规内容外,需要综合考虑组织目标、组织特点、已有工具、历史情况、用户反馈等因素,否则会给人“不接地气”的感觉。 标准规范的制定要优先考虑利用和适配已有工具能力,借助工具落地,而非让工具适配流程规范。
4.2 数字化
4.2.1 数字化架构设计方案
4.2.2 元数据仓库建设
数据业务化:即将数据工程师日常数据开发工作业务化描述,抽象多个业务过程,如需求提出、任务开发、数据表产出、数据应用、需求交付。 业务数字化:用建设业务数仓的思路和方法,对数据业务化之后的各个业务过程及主题,搭建元数据数仓及指标衡量体系,并通过元数据场景化应用提升易用性及丰富度。 数字应用化:在元数据仓库基础上开发数据产品,驱动数据管治实施。
业务元数据:基于具体业务逻辑元数据,常见业务元数据包括业务定义、业务术语、业务规则、业务指标等。 技术元数据:描述了与数据仓库开发、管理和维护相关数据,包括数据源信息、数据仓库模型、数据清洗与更新规则、数据映射和访问权限等,主要为开发和管理数据仓库的工程师使用。 管理元数据:描述管理领域相关概念、关系和规则的数据,主要包括管理流程、人员组织、角色职责等信息。
4.2.2 指标体系建设
生命周期视角:从数据本身出发,衡量数据从生产到销毁的各个过程,包括定义、接入、处理、存储、使用、销毁等等。 团队管理目标视角:根据团队管理核心要达成的目标分类,包括质量、效率、成本、安全、易用性、价值等等。 问题对象视角:根据治理问题核心关注的对象分类,包括安全、资源、服务、架构、效率、价值、质量等等。
技术类指标:覆盖成本、质量、安全、价值及易用性5个方面共57个指标。 需求类指标:覆盖新增、响应、开发、上线及验收等7个方面共36个指标。 故障类指标:覆盖故障发现、原因定位及处理环节共19个指标。
团队管理:帮助团队管理者快速了解团队情况,提升管理效率。 数据治理:利用元数据及指标体系驱动数据治理,为数据治理提供可量化的抓手。 项目评估:帮助项目成员准确评估项目的问题、进展及收益。
指标体系既要解决管理者对日常工作无抓手的问题,也要成为具体问题处理人员的治理抓手,兼顾管理者和开发者。 指标体系是展示偏整体层面的内容,还需通过指标解决实际问题,形成指标体系和数据治理工具闭环,实现发现问题、治理问题、衡量结果持续循环。 优先确定团队总体发展目标,从目标拆分设定指标,指标尽量覆盖不同业务线不同发展阶段。 业务需要明确自己所处阶段,针对不同阶段,制定考核目标,衡量阀值,既统一了衡量标准,又中和了大家考核标准。 指标需注意分层建设,避免“胡子眉毛一把抓”,便于适配目前的组织结构,也便于划分责任与定位。 基础指标体系建设完成后,可作为平时管理和工作的抓手,作为项目发起的依据,作为项目结果评估的手段。
4.2.3 资产等级建设
只能评经验判断哪些是核心资产,遇到问题无法评估解决的优先级。 核心链路的保障,比如SLA及DQC的配置范围缺少科学的评估手段。 管理者对团队核心资产缺乏准确的判断,无法准确有效的做出管理动作。
资产等级建设(数据表)
1)确定影响因子及权重评估
下游类型:决定下游资产重要程度,下游资产类型一般有ETL任务和数据产品两类,ETL任务及数据产品又根据重要度分为普通型及VIP型。 下游数量:决定是否是关键节点,对下游生产的影响范围,下游数量越多表明影响范围越大。 使用热度:决定是否有用,影响查询用户的范围,热度越高表明影响的用户范围越广。 链路深度及分层:决定问题的修复时间,链路越深,问题修复的时间可能就越长。
2)计算资产等级得分
3)资产等级映射
资产等级应用场景(数据表)
4.3 系统化
4.3.1 数据百品-管治中心
数据资产无法统计和描述,管理者及数据工程师不知道有什么,缺乏资产的可视化。 管理者缺少抓手发现团队的问题,且问题难以追踪。 治理线上化程度低,需要跳转多个工具,治理效率低,治理过程无法标准化,导致结果无法保障。
资产全景
资产大盘:从业务线管理者视角出发,展示了业务线内各类资产概览,帮助管理者一站式快速了解组内数据资产,无需跳转多个平台。 资产目录:展示团队数据各资产类型及明细,为数据RD数据使用提供信息支撑,提升RD数据探查效率。 个人资产:从归属人视角,展示数据RD个人及小组名下数据资产数量和资产类型及数据明细,详细描述个人资产信息。
管理中心
管理手段多依赖经验判断,当团队需求承接增加、团队人数增加时会带来管理难度的提升,管理者缺少抓手快速看到团队的整体情况。 管理动作天级别。管理者发现团队某核心指标异常(例如:故障数),需要找对应的责任人询问,无法从系统上快速进行异常追踪,原因获取。
管理者大盘:向管理者提供团队核心指标总览、问题趋势分析、异常明细追踪、异常原因标记等功能,方便管理者快速了解团队情况,及时做出管理动作。 需求管理:提供详细的人效分析大盘以及需求管理功能,服务于人效管理及提效。 故障管理:提供详细的故障分析大盘以及故障复盘管理能力,提升故障管理效率。 团队运营:团队周月报,值班,满意度问卷等团队运营需要的能力,提升运营效率。
治理中心
不了解分配给自己的待治理问题背景、目标和重要程度。治理工作成为盲目去完成分配的任务,即使完成了治理动作,可能依然无法保证是否真正达到治理目标,尤其是面对同时需要处理多类治理问题时,效果差。 数据治理解决问题时通常要使用各类工具互相辅助才能解决,问题多了之后,治理问题变成了重复使用不同的工具,严重影响治理效率和效果。
治理概览:治理中心首页,介绍了团队数据治理体系框架及标准化治理成果,让使用者在认知上与治理中心的治理理念一致,并提供数据治理优秀解决方案。 分析评估:对七大类治理问题进行量化评估,提供治理优先级及问题排名,让用户了解应该先做什么。 问题治理:提供丰富治理指标,全面衡量治理问题,问题分配及时通知,并利用SOP自动化工具,实现对解决问题过程的标准化,保障治理效果,提高治理效率。 进度监控:提供问题治理进度看板及问题分配进度监控,便于管理者宏观把控问题治理进度,合理规划分配节奏。
4.3.2 SOP自动化工具
SOP一般以Wiki形式存在,实际执行过程无法跟踪约束。 SOP动作的执行需要跳转多个平台系统,执行效率低下。
建设方案
基础组建层:SOP最小粒度模块,包括展示类组件(富文本、表格、IFrame),逻辑控制类组件(单选、多选),用户可根据SOP内容选择多个基础组件组合。 配置层:配置SOP中使用参数信息及执行步骤。 应用层:SOP最终效果展示,通过URL接口对外提供服务,比如治理中心可调用SOP工具接口实现一站式治理能力。
应用场景
4.3.3 经验总结
系统化是将解决问题的方法从线下到线上,从散点动作到连贯动作的一种有效解决方案。 没有完美的系统,也不必追求完美,考虑投入产出比,快速解决主要矛盾,应用到具体问题解决中。 产品定位设计,产品长远规划的能力设计尤为重要,否则容易出现“做着做着不知道做什么,不知道往什么方向发展”的情况。
五、业务数据治理实施流程
STEP 1:发现问题和制定目标,发现问题要从业务数据开发团队的视角出发,围绕服务好业务、遵守数据研发规范、收集好用户反馈,尽可能全地发现和收集相关需要解决的问题。同时,制定的目标要具备可实现性。 STEP 2:针对问题进行拆解,设计可衡量的指标,并通过元数据的采集建设进行实现,用做对目标的进一步量化,并作为实施过程监控及治理抓手。 STEP 3:对衡量出来的具体问题,制定相关的解决SOP,并且检查相应的研发标准规范是否完善,通过问题发生的事前、事中、事后几个阶段,建设或完善相应的工具化解决问题的能力。 STEP 4:推广运营,以拿结果为核心目标,针对不同角色运用不同策略,重点关注问题解决过程是否会与用户利益发生冲突,控制好节奏,根据问题的重要程度有规划地进行解决。 STEP 5:总结沉淀方法论,迭代认知,持续探索问题的最优解,优化治理方案和能力。
六、总结与展望
DAMA、DCMM等数据管理框架各个能力域的划分是否合理?有内在逻辑吗?by 傅一平
点击左下角“阅读原文”查看更多精彩文章,公众号推送规则变了,如果您想及时收到推送,麻烦右下角点个在看或者把本号置顶!