数据治理
数据治理是一个通过一系列信息相关的过程来实现决策权和职责分工的系统，这些过程按照达成共识的模型来执行，该模型描述了谁（Who）能根据什么信息，在什么时间（When）和情况（Where）下，用什么方法（How），采取什么行动（What）。
数据治理的最终目标
提升数据的价值，数据治理非常必要，是企业实现数字战略的基础，它是一个管理体系，包括组织、制度、流程、工具。
数据治理的本质
解决组织、制度、流程关于数据的问题，解决数据认责，数据可信，数据一致的问题，提供平台、工具、方法
数据治理范围的确定
- 数据治理的蓝图规划及其目标
- 确定主题域及主题域边界（此处需要业务调研）
- 成立相应的组织、制度、流程
- 对数据平台进行调研选型
❝❞
- 六大领域（数据架构、数据标准、数据质量、数据安全、主数据、元数据）
- 四大保障（管理组织、管理制度、管理流程、管理文化）
- 一大平台
数据成熟度评估、数据质量报告
输出物：蓝图以及目标，政策（数据模型管理政策、数据质量管理政策、元数据管理正常、主数据管理政策、数据服务管理政策）、流程（数据标准管控流程、是数据质量管理流程、数据需求流程、数据资产下架流程、主数据管控流程）、数据 owner 的发布，组织以及流程制度的成立与发布；
数据资产的盘点
- 明确数据资产盘点的粒度
主题域分组、主题域、业务对象、逻辑 s 实体、属性
- 业务调研、系统调研
调研企业所有系统情况，收集所有系统名称，建设目标，系统类型划分，使用者，用户来源和规模。
- 业务流程的梳理
梳理业务与业务之间的流程关系，业务流程涉及的关键主体与动作，输入输出情况；
- 业务流程的分解
识别各业务环节涉及的人、事、物， 输入、输出、组件和数据；输出业务流程图；根据梳理好的业务流程图，转换成对应的数据流图；
5.数据标准的梳理
对于数据按照主数据、参考数据、交易数据、分析数据进行分类，并梳理出数据的技术标准和业务标准；补充和整理完整的数据字典；
- 落地范围：哪些标准需要落地 涉及到哪些 IT 系统
- 差异分析：与现有数据的差异 差异有多大
- 影响分析：对哪些系统产生影响 产生什么样的影响 影响是否可控
- 落地方案：组织架构 人员分工 考核制度 监管方案
- 落地执行：发布标准 标准映射 常态化
- 效果评估：跟踪评估落地的效果 哪些事做对了 哪些事需要改进
- 数据的分级分类 数据分类分级，根据行业标准和特点对于数据资产进行分类，将数据资产划分为公开、内部、敏感等不同的敏感等级；
- 输出物：数据资产目录，数据 CRUD 矩阵，数据标准，数据治理策略
数据治理实施方法论
数据治理的目的：一般是为了提高数据质量，以便于数据可以更好地服务于业务，对业务进行赋能 数据质量常见的问题：完整性、一致性、准确性、及时性、有效性 数据质量的根源：业务系统的变更、开发运维人员的参差不齐、手工录入。
数据治理的方法论
- 主数据治理：
指企业内一致并共享的业务主体。特点：准确性、一致性、集成性、共享性/可重用性和高价值。主数据治理一般会作为单独的项目来做，MDM 系统。一般是从源端进行管控治理
- 主数据的主要问题：
关键信息孤岛，数据分布在多个孤岛，不能跨组织传播 组织内不能就一个主数据源达成一致 数据质量问题引发的业务流程和交易的失败 不正确或丢失数据造成合规性和绩效管理的问题 决策者做出基于错误数据的错误决定
- 主数据解决方案：
- 数据转换映射
- 由应用系统承担主数据管理功能
- 集中管控
- 交易数据治理
交易数据一般可以先在数据平台先行治理，之后再在源端进行管控治理
- 参考数据治理
参考数据一般可以先在数据平台先行治理，之后再在源端进行管控治理
- 分析数据治理
分析数据一般可以在数据平台进行治理
- 数据模型、数据标准的治理
数据模型、数据标准一般可以先在数据平台先行治理，之后再在源端进行管控治理
- 元数据治理
是企业数据资产管理的基础，是关于“数据的数据”，例如数据类型、数据定义、数据关系等，相当于数据表格中的表头信息，是一个相对客观的概念。元数据一般可以先在数据中台先行治理，之后再在源端进行管控治理
- 数据资产成本的治理
- 资产上线容易下线难
- 低价值的数据资产
- 资产的烟囱式开发
- 数据的倾斜
- 资产的生命周期
- 调度周期的合理性
- 任务参数的合理性
「如何优化」
- 数据资产的全链路血缘
- 针对未使用的资产，进行下架处理
- 针对低价值，使用频率低的资产，按照应用粒度评估应用是否还有存在的必要，可进行下架策略，以及优化模型
- 针对高价值的，评估计算资源与存储资源，以及优化模型
- 数据资产安全合规
- 数据资产进行分级分类
- 数据资产进行加密
- 数据资产进行权限管控
- 数据使用进行流程申请
- 对关键数据制定跟踪制度
- 遵从相关法律法规
输出物：数据平台的搭建；数据门户的建立；
「一般来说第一阶段不建议全面落标，强调按需建设，"以用促治，以用促建"」
群里前几天也有关于数据治理的讨论，我感觉说的非常好，现摘录出来，与君共勉。在这里特别感谢苏奕嘉，南知唔知，李奇峰，幻枫~~~
❝从以下三个角度出发,xdm 先思考思考：
❞
- 数据治理分为哪些方面？
- 数据治理上下游关系和界限如何明确？
- 数据治理的具体技术落地方向？
- 假如上游未遵守治理规则，下游要做哪些防范措施和技术手段以尽可能保证自己数据治理？
「技术层面-李奇峰总结」
- 数据分类：首先是针对各数据进行归类，根据业务需求划分成不同的类别，然后将数据表依次归类。
- 时间字段治理：在所有数据中添加统一名称的时间字段，依次记录数据发生时间、最后更新时间、插入时间等。
- 数据过滤：在入库时如果碰到无法解析的错误数据，或者关键字段缺失的数据，则直接丢弃。
- 数据去重：如果在入库时发现库中存在相同的数据，则会将新数据直接覆盖旧数据。
- 数据抽取与合并：将各个类别的数据的指定字段抽取到一个正式库中，统一格式，去除多样字段，标注来源信息。同时在抽取过程中，将属于同一事件的多个日志进行合并，保存至合并库中。
- 数据关联：数据入库后，各个数据之间关联性较弱，在开发过程中需要重复调用数据接口进行数据获取。于是在数据入库时或入库后，根据主外键 ID、相同含义字段进行关联，将关联字段更新至源数据中。
「业务层面-苏奕嘉总结」
我觉得从框架而言，我个人认为需要几部分：
- 字段规则治理：主要是和业务方对齐原子指标的含义，如有多条线，需要一起对齐口径，只有业务方都承认和了解接受了原子指标口径，数仓才好进一步处理，举例：净收益到底是【营销额-成本（包含各种费用）】还是【营销额-成本（只包含成品本身的成本）】，不同的业务线可能有不同的定义，如供应链和营销链注重的就不一样
- 数据源治理：数据源即上游数据，上游数据多而繁杂，可细分为不同数据类型进行划域治理，类似主题建模和数据域的概念，比如订单、客户、供应链、财务等等，不同的域有不同的强规则体系，这个体系可形成一套完备的探查系统，比如数据源探查体系：订单{null 值:是否有 null 值,长度:订单号是否满足规则,金额:是否有营销额无净销额……}，客户{OneID:是否标识,手机号:是否为空,收货地址:是否满足规则……}。不同的数据域有着不同的字段定义标准和探查规则标准，如果没有探查阶段，那么数据治理就是睁眼瞎
- 数据质量反馈体系：很多时候，上游数据有了问题，下游沟通其实是一个很难的事情，比如上游为了满足自己业务需求，私自改了数值/字段名/表名等等，下游会发生依赖错误/数据值错误等情况，如果要求上游怎样做，其实很不靠谱，别人不太会听你的，那么就需要从更高一个维度解决，一是成立 PMO 组织，由更高级别的 Leader 组织，内部有数据部门，业务部门和测试部门，数据部门发现问题，交由测试部门进行总结反馈，定期给出质量报告，由测试部门监督业务部门完成整改，可用作计入绩效考核等方式进行管控，没有裁判的赛道是虚假的、不完整的。
- 数据灾备规则和系统：没有人管控的了别人的做法和想法，那么就要做好数据部门本身的灾备规则和系统，比如从小处讲，ODS 接入后在 DW 清洗时要注意 NULL 值处理，不管这个字段以前有没有 NULL 值，从大处讲，就是完善数据部门自己的代码书写规范，每次发版需要严格 CodeReview，如果从系统角度出发，比如第三方，就做一个第三方统一接入系统，从源头规范化数据格式，比如业务线，就采取业务中台模式，数据所有数据统一处理统一管理，当然，这些扯开都是很大的话题，以后再讲
「业务层面-幻枫总结」
- 指标体系的建立，加上纬度属性的集成，构成数据字典，
- 数据源有公约规则约束的情况下建立明细数据的的数据监控，数据远没有公约规则的，按照基础的数据标准和业务过程进行数据探查，然后按照数据展现情况进行数据监控，
- 就是数据治理的组织架构，要由上层牵头下游处理，且要有管理体系，比如约束规范更改要有特定的流程，
- 就是数仓内部根据下游的需求，制定清晰转换规则，要有相应的操作留档
「思想层面-南知总结」
数据权限（安全），元数据管理（技术 or 业务，资产），数据质量（上下游延迟，故障快速感知和修复） 治理是很大的概念，从我经历过或做过的，可以下手的点就是质量、安全、资产数仓是数仓，治理是治理。要明确的分开，凡涉及到口径、数据源、ETL processing 的，应该算数仓方法论或数仓规范或落地平台化的方式方法
数据治理与其说是一个技术活，其实更是一个业务活，建议不要 it 部门主导，最好是营销或者财务部门主导，it 部门提供技术支持和解决方案，这里几点原因，供君参考
优势一、首先不要让别人有什么数据问题都是 it 的事（这点很重要），
优势二、数据有问题，财务核算会很难，他会是直接受益者，或者说是痛点单位
优势三、数据治理，会牵扯到很多业务的改造，it 话语权一般不足
优势四、财务负责 更容易体现价值 而不是 it 闭门造车
问题与思考
- 数据治理属于一个数据基础性工作，但是又需要业务部门的深度参与，如何体现对业务部门的价值？
- 数据治理需要业务的深度参与，业务部门具体需要做哪些工作？
- 数据治理本质上是对业务源头进行一个限制，那数据认责这块，是如何进行划分的？
