数据治理与数据质量

人工智能与数据
├── 数据工程侧
│   ├── 大数据开发工程师
│   ├── 数据治理与数据质量 ← 本篇
│   └── 商业智能（BI）与数据可视化
├── 数据洞察侧（数据分析师）
└── 模型与策略侧（算法／MLOps／AI 应用／推荐搜索）

定位一句话：数据治理岗位是数据世界的"市政管理"——定标准、修管道、清垃圾、立规矩，让别人能放心地用数据，而不是每次用之前先怀疑它准不准。

为什么它是一条横向职能线：数据从产生到被使用，会经过业务系统、数据管道、仓库、报表与模型，任何一段出问题，最终都表现为"数据不对"。但没有任何一个开发团队会为"跨系统的口径一致性"负责——这是治理岗存在的理由：它不解数据问题本身，而是建立让问题不再反复发生的规则与机制。

一句话定义：数据治理与数据质量岗位负责企业数据资产的规范建设与质量保障，包括数据标准与指标口径的制定、数据资产目录与血缘关系的维护、数据质量规则的建立与监控、数据权限与安全合规策略的落地，以及推动各业务与研发团队按规则整改。

职责边界（五类日常）

一、标准与口径治理

制定字段命名、编码与指标计算标准，处理同一指标多套算法的历史问题，维护数据字典与变更审批流程。

• 核心难题是"同一个指标多个数"：不同团队各自实现一遍，算法细节差一点，结果就对不上。收敛方法通常是先盘点所有在用口径、找出差异来源（时间窗口、过滤条件、去重规则、归属口径），再确定唯一权威口径，其余明确标注为派生或废弃。
• 命名与编码标准：字段命名要能自解释，编码值要统一（性别、状态、渠道等），否则下游每次用数据都要重新问一遍含义。
• 变更审批：字段含义变更必须登记并通知使用方——改动一个字段的定义，可能悄悄改掉几十张报表的口径，这是最容易被忽视的连锁风险。

二、资产与血缘管理

梳理核心数据资产（表、指标、标签、报表）的归属与依赖关系，明确每个数据的责任方与使用者。

• 目标：消灭"无人负责的野生数据"——不知道谁建、谁在用、能不能删的表，是治理的顽疾。
• 血缘的价值：知道一张表的上游与下游，才能在变更前评估影响面（改这里会打坏哪些报表），也才能在出问题时快速定位污染来源。
• 落点通常是数据目录：一份能让非技术同学也查得到"公司有哪些数据、口径是什么、找谁问"的清单。

三、质量规则与监控

定义质量规则，部署自动化校验与告警，跟踪异常数据的修复与复发情况。常用的质量维度包括：

• 规则怎么定：不是越多越好，优先覆盖被业务真正依赖的关键数据；阈值要能区分正常波动与真实异常，否则告警会迅速被无视。
• 修复与复发：记录每次异常的根因与修复方式，定期看"哪些问题反复出现"——复发类型说明流程有缺口，不是操作失误。

四、权限与合规

设计数据分级分类与访问授权机制，落实脱敏与审计留痕要求，配合个人信息保护与行业监管的检查。

• 分级分类：按数据敏感程度与业务属性划分等级，不同等级对应不同的访问、导出与外发规则。这是所有权限设计的起点。
• 授权：最小必要、按需申请、有到期时间；高敏数据的访问要留痕可审计。
• 脱敏：用于分析、测试、外部合作的场景，需要在保留数据可用性的同时去除可识别信息。
• 合规配合：材料与实现对得上是最基本的要求——"说的、做的、留下的痕迹"三者一致，否则检查时很难解释。

五、推广与协同

把治理要求嵌进研发与业务流程（建模评审、上线检查、需求受理），组织培训与宣贯，处理"治理被当成额外负担"的现实阻力。

• 最有效的落地方式不是发制度，而是嵌流程：让新建表必须登记、上线前必须过质量检查，规则才会被真的执行。
• 阻力是常态：业务团队的本能是"先上线再说"。治理岗需要用具体事故的代价说话（哪次因为口径不一致导致决策错误、哪次因为字段变更打坏了报表），而不是用原则说话。

一个典型难题的处理路径：同名指标对不上

"同一个指标三个团队给出三个数"是数据治理最常被问到的问题，处理路径大致是：

1. 收集全部口径——把每个团队的实现方式（计算逻辑、数据来源、时间窗口、过滤条件）列出来；
2. 逐项找差异——多数差异来自四类原因：时间口径（自然日与账期）、去重口径（按人还是按次）、归属口径（算给谁）、过滤口径（是否剔除测试与异常）；
3. 确认唯一权威口径——由指标的业务归属方拍板，治理岗提供差异分析与影响面；
4. 改造下游——把统一口径落到指标平台或统一视图，其余实现逐步下线；
5. 加规则防复发——对该指标设置一致性校验，出现分叉立即告警。

这里的难点通常不在技术，而在要让三个团队都同意改。治理岗的价值很大一部分体现在"能不能推动改动落地"上。

治理成效怎么说明

治理工作最容易吃的亏是"做了很多但说不清价值"。可用的说明方式有三种：

• 看事故与返工——统计因口径不一致、数据错误导致的返工与决策修正次数，看它是否在下降；
• 看信任与使用——报表被质疑的次数、数据问题的求助量、核心指标的复用度；
• 看响应速度——从发现异常到定位根因所需的时间（血缘与规则建设完善后通常明显缩短）。

三种里，事故类证据最有说服力，也最符合管理层"关心问题"的注意力习惯；只讲"建了多少条规则"通常换不来认可。

相邻岗位辨析

三组最容易混的场景：

• 治理 vs 数据开发：数据产出错了，是规则问题还是实现问题？分界是"定规则还是实现规则"——治理岗定标准与校验规则，数据开发负责按规则产出。糊掉的典型后果是治理岗天天替业务修数据，规则建设永远没时间做。
• 治理 vs 数据产品：都要"让数据好用"，但治理侧重规则与资产（口径对不对、归属清不清），数据产品侧重体验与工具（查得到、看得懂、点得动）。两者在建数据目录与指标平台时最容易职责重叠，需提前约定谁主导。
• 治理 vs 合规／内控：都管数据安全，但合规从制度与外部要求出发，治理负责把要求变成技术可实现的分级、授权、脱敏与审计机制。只提要求不落地的合规检查，最终都会压到治理侧。

判断口诀：定标准口径、查数据质量、管权限 → 数据治理；建管道跑任务 → 数据工程；设计数据工具 → 数据产品；用数据回答业务问题 → 分析师。

不同企业类型下的差异

• 金融类机构：监管要求最细，数据治理与数据安全高度绑定，岗位设置最稳定，工作重心在分级、审计与报送口径的一致。
• 医药与医疗相关：数据敏感度高，合规与留痕要求严格，治理岗常与质量、法规部门紧密协作。
• 大型集团型企业：多业务线并存，主数据与统一口径是长期主线，跨组织协调占很大比重。
• 互联网与科技企业：数据体量大、变化快，重心在质量监控自动化与数据目录工具化，节奏明显更快。
• 中小企业：通常没有专职治理岗，相关职责由数据开发或数据分析兼任，治理动作更偏向"解决眼前最痛的一个口径问题"。

入行与转出（公开口径）

• 背景：信息管理、计算机、统计、图书情报类专业均可见；实际来源集中在数据开发、数据分析、数据产品与业务系统实施几类岗位。
• 前置知识：SQL 与数据建模基础（必备）＋ 元数据与血缘工具的理解 ＋ 主数据与指标体系常识 ＋ 数据安全与个人信息保护的基本法规认知；跨部门推动能力比技术深度更影响绩效。
• 面试通常怎么考察：多围绕实际案例——"你遇到过什么数据质量问题、怎么定位和解决的""指标口径冲突怎么收口""怎么让业务方愿意配合"。也会考基础的建模与 SQL 能力，但权重通常低于推动与结构化表达能力。
• 常见入口：① 数据开发或数据分析转治理方向；② 企业数据中台、数据仓库团队内的治理专岗；③ 咨询或系统实施方的数据治理顾问转甲方；④ 大型集团的信息化部门设治理岗。
• 适配画像：既讲规则又讲人情——治理岗天然要给人增加约束，能推动别人配合比技术方案更关键；耐心、有条理、对细节敏感到近乎强迫；善于写文档与制度。
• 三个常见认知误区：① 以为治理就是写文档、发规范——不嵌进流程的规范几乎不会被执行；② 以为要一次把所有标准做全——现实做法是从最痛的一两个指标切入，做出效果再扩面；③ 以为技术深度决定一切——沟通与推动才是这条线的主要难点。
• 职业特点：数据治理是典型的"短期无感、长期缺了会出事"的职能，因此岗位设置高度依赖企业数据成熟度与监管压力——金融、医药、大型集团的治理岗最稳定；风险在于改善成果难被量化、容易被当成"支持部门"，用质量问题引发的事故事件说明价值是最有效的方式。
• 转出方向：转数据资产与中台管理、转合规与数据安全方向、转数据产品与数据平台规划、转数据治理咨询。