业务数据治理体系化思考与实践
发布时间：2022-05-12编辑：admin阅读（3960）
总第508篇
2022年 第025篇
一、序言
二、背景介绍
三、治理体系化思考
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：总结沉淀方法论，迭代认知，持续探索问题的最优解，优化治理方案和能力。
六、总结与展望
七、作者简介
阅读更多
标签：
