《 “[collect]数据治理相关知识整理学习” 》 有 5 条评论

1. 数据治理项目失败，90%都是被这样搞垮的！
   https://mp.weixin.qq.com/s?__biz=MzI1NzYwNTMzNw==&mid=2247492789&idx=1&sn=680d13226e56b4636004660fd9bfe4c7
   `
   — 01 — 缺乏明确的目标
   — 02 — 分工混乱、权责不明
   — 03 — 高层管理者关注不足
   — 04 — 缺乏数据治理专家
   — 05 — 不透明规则和系统
   — 06 — 被动式数据治理
   — 07 — 项目型数据治理
   — 08 — 孤立式数据治理
   — 09 — 唯工具论

   # 写在最后的话
   数据治理关注的是“如何管好数据”的问题，他涉及一系列的策略，例如：战略、文化、制度、流程、标准等，是数据管理最核心的内容。每个数据治理策略的制定和执行过程，都有很多影响的因素，会导致数据治理的失败。

   这篇文章，我们分享了数据治理项目失败的各种原因，虽然有的条目有些夸张的成分，但在实际项目中确实有过相似的、甚至真实的案例，单个的因素或许不能分分钟将数据治理项目搞垮，但某些因素一旦组合就会注定项目的失败。
   `

   回复

2. 快手徐波：元数据的建设与分析是数据治理未来的不可或缺的一环
   https://mp.weixin.qq.com/s/pzeH6Wkily7WEqfiYWsokA
   `
   InfoQ：首先是关于数据质量问题，主要有哪些挑战？
   徐波：数据从生产到消费链路比较长，涉及的系统和角色众多，而这些系统和角色又分散在各个组织，协作复杂度很高。
   数据质量长效保障流程相对较重与短期效率容易产生矛盾，难以长期坚持。所以数据质量在各大公司都是个普遍问题。这里的挑战主要有以下几方面：
   * 与协作团队目标未对齐。比如业务系统和客户端团队的目标是保障业务功能质量，容易忽略与数据团队联动，引起一些数据质量问题；
   * 缺乏统一指标命名、管理规范与信息同步机制，局部各自定义，全局指标膨胀，五花八门；
   * 缺乏合理的指标生命周期管理流程与角色设计，指标质量无人长期负责；
   * 缺乏指标管理平台，定义散落在文档。阶段性对齐， 难以长期保障口径准确清晰；
   * 核心数据多出生产，各自对外服务，容易产生不一致；
   * 缺乏全局监控手段，容易受到业务系统变更，局部数据变更等因素引起数据故障。

   InfoQ：快手是如何保障这些数据质量问题的？
   徐波：快手的质量保障主要通过：组织、流程、规范，系统这四个方向来实现数据质量的持续收敛。
   1. 组织上分两层。对外，我们与协作团队（客户端，业务系统，质量保障，分析师）共识数据质量的重要性，并且与他们共识质量目标与各自的职责，以定期复盘和通晒的方式来持续加强大家的质量意识和一定的资源投入；对内，明确每个业务线以及公司级的指标管理员，对指标口径和生命周期负责，做到口径变化有人审批，版本变化可追溯。

   2. 在规范上，建设了指标定义规范与数据监控规范。首先是指标定义规范，明确基础，衍生，符合指标原则，对指标进行了极大的收敛。使用词根叠加命名方式来替代人工命名让指标更加规整；其次是数据监控规范：明确核心指标上线必须要加上 DQC，对常见的监控项予以覆盖，额外还加了一些补充规则，如：
   * 多表间相同指标维度一致性监控，且覆盖历史半年数据，保障仓内的数据一致性；
   * 指标之间的业务规则监控（比如有效订单 = 提交订单 – 取消订单，分渠道有效订单汇总 = 总有效订单）；
   * 历史数据分区的变更监控，防止历史数据局部刷新引起的不一致；
   * 业务系统核心维表变更监控，防止业务系统分类变化带来的数据波动不可解释；

   3. 流程机制上建设了：
   * 指标生命周期管理流程，明确各角色职责和指标变更审批与信息同步公示机制；
   * 监控值班机制，这点最为关键，也最难以坚持。数据问题往往不是没有被监控发现，而是告警了没人看，没人跟进。我们要求每天必须看，当天问题当天解决，各业务的数据 Leader 负责监督。

   4. 在系统上，建设了指标管理系统和全链路监控系统，让流程规范能在系统中高效的运作起来。

   InfoQ：关于数据质量保障，业界是否还存在比较好的方案？
   徐波：质量保障，除了上面说的一些方法外，了解到美团和阿里都有数据建模工具，打通了数据指标管理与数据生产链路，并将一些建设规范集成到数据建模工具上，从源头上让数据生产更加规范，这是一种很好的事前规避的方法。相比于事后监控发现，这种方法效率更高。
   `

   回复

3. 数据治理一体化实践之体系化建模
   https://mp.weixin.qq.com/s/A67_ZrpmB-GjUfAX1MMbnw
   `
   数字经济的快速发展，给企业的经营带来了新的机遇和挑战，如何有效开展数据治理，打破数据孤岛，充分发挥数据的业务价值，保护数据安全，已成为业界的热门话题。本文基于美团配送数据治理的历程，分享了数据定义、模型设计、数据生产三环节统一的配送数据“底座”的建设与实践。

   1 前言
   本文基于美团配送数据治理的历程，重点和大家分享一下配送数据“底座”的建设与实践，如何通过体系化建模建立起数据定义到数据生产的桥梁，达成数据定义、模型设计、数据生产三个环节的统一，消除因数据标准缺失和执行不到位引发的数据信任问题，在高质量地实现数据到信息的转化的同时，为后续的数据便捷消费提供数据和元数据保障。希望能给从事数据治理方向的同学在实现数据到资产的转化过程提供一些参考和借鉴。

   2 什么是体系化建模
   体系化建模是以维度建模为理论基础，以事前治理的理念驱动，让元数据贯穿其中的建模流程，上承指标、维度的定义，下接实际的数据生产。
   首先，通过高层模型设计，将业务指标结构化拆解为原子指标/计算指标+限定条件的组合方式，并将其归属到特定的业务过程和主题下，完成业务指标的计划化定义；
   其次，基于高层模型设计自动生产详细的物理模型设计；
   第三，基于产生的物理模型设计，半自动或自动地生成数据加工逻辑，以确保最终的业务定义和物理实现的统一。

   3 为什么要进行体系化建模
   3.1 体系化建模可以对数据架构进行实质有效的管理，从源头消除“烟囱式”开发
   3.2 体系化建模沉淀的规范元数据，可以有效消除业务在检索和理解数据时的困扰

   4 如何进行体系化建模
   4.1 高层模型设计
   4.2 详细模型设计
   4.3 上线前卡点

   5 总结
   `

   回复

4. 业务数据治理体系化思考与实践
   https://tech.meituan.com/2022/05/12/business-data-governance.html
   `
   一、序言
   美团住宿数据治理团队通过多年数仓建设及数据治理的经验沉淀，并结合业务发展阶段对于数据治理的诉求，将治理的思路逐步从专项、表象、问题驱动的治理，转变为自动化、体系化的治理，并从标准化、数字化、系统化三个方向进行了落地与实践。

   二、背景介绍
   美团住宿业务从2014年上线之后发展多年，历经探索期、进攻期，发展期，并逐步由发展期向变革期过渡。业务从之前的快速扩张阶段进入相对稳定的发展阶段，运营手段转变为精细化运营，同时对数据的成本、效率、安全、价值等方向的要求也越来越高，这些都对数据治理提出了新的要求。

   另一方面，住宿数据组所属的数据中心内部有住宿、门票度假等多条业务线，各业务线业务模式不同，所处业务生命周期阶段不同，在数据治理上的认知及经验积累也不同。如何能将数据治理经验及能力高效复用，使数据中心各业务线在数据治理的效率和效果上都能稳步提升，避免踩坑，这就需要数据治理更加标准化、体系化、自动化。
   此前，我们在数据治理上已经有了一些积累和沉淀，前一阶段主要从单点、被动的治理转变为主动、专项的治理，治理动作有意识、有规划，也有一定的针对性，且取得了一定的成果（前一阶段的治理经验可参考美团酒旅数据治理实践一文），但总的来说仍以问题驱动治理、凭经验治理为主。面对新的数据治理责任及要求，过往的方式存在着一些问题，主要包括以下几个方面。

   治理认知差异大
   * 认知不一致，思路不统一：治理缺乏通用的体系指引，不同的治理人对于数据治理的认知深度、问题拆解的方式、治理的思路步骤、采取的方法及其效果追踪等方面，都存在较大的差异。
   * 重复治理、信息不通：治理不彻底、治理经验缺乏沉淀，同样的治理，不同的人反复实行。
   * 范围交叉、边界不清、效果难评估：不同的人针对不同的问题成立不同的专项进行治理，问题的底层逻辑有交叉。有的治理没做什么动作，反而收到了较好的结果，有的治理对于结果说不清。

   治理方法不标准
   * 流程规范缺失：对于每个方向、每类问题的治理缺少理论指导，治理的方法、动作、流程、步骤依赖治理人的经验和判断。
   * 问题难度量追踪：治理的问题缺少衡量标准，更多靠人为来进行判断，治理效果缺少评估体系。
   * 解决方案难落地：解决方案存在于文档中，需要治理人查找理解，缺少工具支撑，成本较高。

   治理效率低、效果差
   * 治理线上化程度低：治理依赖的资产信息、治理动作都分散于多个系统中，信息碎片化，执行效率低。
   * 过程无法标准化，结果无保障：治理过程需要治理人来“人为保障”，存在理解偏差和执行偏差。

   数据管治缺乏体系化
   * 缺乏整体顶层治理方案设计：业务及数据中心对于数据治理的要求，需要治理更全面、更精细、更有效，需要治理的体系化，需要从宏观角度进行思考，层层拆解，需要从整体、从顶层来做方案设计。
   * 问题越来越复杂，单点难解决：过往更多的是从表象去解决问题，从表面来看衡量指标有改善，实际是“头痛医头、脚痛医脚”，并没有从根本上解决问题。或者多个问题具有共性，根本问题是一致的。比如查询资源紧张的根本，可能是分析主题模型建设不足或运营不够。
   * 不同问题的优先级无法确定：不同问题的优先级缺乏衡量标准和方法，主要靠人为判断。
   * 治理不符合MECE原则：每个治理方向由哪些问题组成，哪些最重要，哪些的ROI最高，哪些问题和治理动作可以合并，同一问题在数仓不同主题、不同分层的衡量标准和治理方法应该有哪些差异，都需要在体系化治理中进行考虑。

   三、治理体系化思考
   3.1 什么是数据治理体系化？
   3.2 数据治理体系化如何解决目前治理存在的问题？
   3.3 业务数据管治体系框架如何建设？
   3.4 体系框架如何落地实施？

   四、治理体系化实践
   4.1 标准化
   4.2 数字化
   4.3 系统化

   五、业务数据治理实施流程
   数据治理实施流程，是我们依据业务数据治理标准化框架在实施解决具体数据问题时，总结抽象出来的一套适用于大多数治理场景解决问题的通用标准流程。标准流程的好处在于更加规范化数据治理工程师的操作流程，来保证实施的质量。流程一共包含5个步骤：

   STEP 1：发现问题和制定目标，发现问题要从业务数据开发团队的视角出发，围绕服务好业务、遵守数据研发规范、收集好用户反馈，尽可能全地发现和收集相关需要解决的问题。同时，制定的目标要具备可实现性。
   STEP 2：针对问题进行拆解，设计可衡量的指标，并通过元数据的采集建设进行实现，用做对目标的进一步量化，并作为实施过程监控及治理抓手。
   STEP 3：对衡量出来的具体问题，制定相关的解决SOP，并且检查相应的研发标准规范是否完善，通过问题发生的事前、事中、事后几个阶段，建设或完善相应的工具化解决问题的能力。
   STEP 4：推广运营，以拿结果为核心目标，针对不同角色运用不同策略，重点关注问题解决过程是否会与用户利益发生冲突，控制好节奏，根据问题的重要程度有规划地进行解决。
   STEP 5：总结沉淀方法论，迭代认知，持续探索问题的最优解，优化治理方案和能力。

   ==
   通过数据治理系统化的建设，我们总结了以下几点：
   * 系统化是将解决问题的方法从线下到线上，从散点动作到连贯动作的一种有效解决方案。
   * 没有完美的系统，也不必追求完美，考虑投入产出比，快速解决主要矛盾，应用到具体问题解决中。
   * 产品定位设计，产品长远规划的能力设计尤为重要，否则容易出现“做着做着不知道做什么，不知道往什么方向发展”的情况。

   定标准（定框架/定规范） – 建能力（元数仓/建工具） – 做运营（可跟踪/提效率） – 拿结果（可量化/有评价）
   `

   回复

5. 数据质量管理方法总结（全）
   https://mp.weixin.qq.com/s/pLXv9l5pICCeb6TEDMQSsw
   `
   一、数据质量保障原则

   如何评估数据质量的好坏，业界有不同的标准，阿里主要从4个方面进行评估：完整性、准确性、一致性、及时性；

   1. 完整性
   数据完整性是数据最基础的保障；
   * 完整性：指数据的记录和信息是否完整，是否存在缺失的情况；
   * 数据缺失：主要包括记录的缺失和记录中某个字段信息的缺失；记录的丢失：如，交易中每天只发订单数都在 100 万笔左右，如果某天支付订单突然下降到 1 万笔，很可能是记录丢失了；记录中字段的丢失：如，订单的商品 ID、卖家 ID 都是必然存在的，这些字段的空值个数肯定是 0，一旦大于 0 就违背了完整性约束；

   2. 准确性
   * 准确性：指数据汇总记录的信息和数据是否准确，是否存在异常或者错误的信息；准确：数据表中记录的信息与业务过程中真实发生的事实要一致；如何判断是否准确：卡点监控 —— 制定相应规则，根据根校验数据，符合规则的数据则认为是准确的；如，一笔订单如果出现确认收货金额为负值，或者下单时间在公司成立之前，或者订单没有买家信息等，这些必然是有问题的；

   3. 一致性
   * 一致性：一般体现在跨度很大的数据仓库体系中，如阿里的数据仓库，内部有很多业务数据仓库分支，对于同一份数据，必须保证一致性；一致：也就是指多个业务数据仓库间的公共数据，必须在各个数据仓库中保持一致；如，用户 ID，从在线业务库加工到数据仓库，再到各个消费节点，必须都是同一种类型，长度也需要保持一致；
   * 所以，在阿里建设数据仓库时，才有了公共层的加工，以确保数据的一致性；

   4. 及时性
   * 及时性：指数据要能及时产出；主要体现在数据应用上，要及时产出给到需求方；
   * 一般决策支持分析师希望当天就能看到前一天的数据，而不是等三五天才能看到某一个数据分析结果；否则就已失去了数据及时性的价值；如，阿里 “双 11” 的交易大屏数据，就要做到秒级；

   二、数据质量方法概述

   1. 消费场景知晓
   * 功能：分析解决消费场景知晓的问题；
   * 方法：通过数据资产等级和基于元数据的应用链路，来分析解决消费场景知晓的问题；确定数据资产等级：根据应用的影响程度，确定数据资产的等级；
   * 过程：根据数据链路血缘，将资产等级上推至各数据生产加工的各个环节，确定链路上所有涉及数据的资产等级，以及在各个加工环节上根据资产等级的不同所采取不同的处理方式；

   2. 数据生产加工各个环节卡点校验
   主要对两部分的数据卡点校验：在线系统和离线系统数据生产加工各个环节的卡点校验；
   * 在线系统：OLTP（On – Line Transaction Processing，联机事务处理）系统；在线系统生产加工各环节卡点校验：1.根据资产等级的不同，当对应的业务系统变更时，决定是否将变更通知下游；2.对于高资产等级的业务，当出现新业务数据时，是否纳入统计中，需要卡掉审批；
   * 离线系统：OLAP（On – Line Analytical Processing，联机分析处理）系统；离线系统生产加工各环节卡点校验：主要包括：代码开发、测试、发布、历史或错误数据回刷等环节的卡点校验；代码开发阶段、发布前的测试阶段针对数据资产等级的不同，对校验的要求有所不同；

   3. 风险点监控
   风险点监控：主要针对在数据运行过程中可能出现的数据质量和时效等问题进行监控；
   主要对两个方面进行风险点监控：
   * 在线数据的风险点监控：主要针对在线系统日常运行产出的数据进行业务规则的校验；主要使用 “实时业务检测平台 BCP（Biz Check Platform）”；
   * 离线数据的风险点监控：主要是针对离线系统日常运行产出的数据，进行数据质量监控和时效性监控；DQC：监控数据质量；摩萨德：监控数据时效性；

   4. 质量衡量
   * 对质量的衡量：事前的衡量：如 DQC 覆盖率；事后的衡量：跟进质量问题，确定质量问题原因、责任人、解决情况等，并用于数据质量的复盘，避免类似事件再次发生；根据质量问题对不同等级资产的影响程度，确定其是属于低影响的事件还是具有较大影响的故障；
   * 质量分：综合事前和事后的衡量数据进行打分；

   5. 质量配套工具
   * 针对数据质量的各个方面，都有相关的工具进行保证，以提高效能；
   `

   回复