数据治理精华版本
2022-11-20 15:05:53 1 举报
数据治理是一种组织和管理企业数据的过程，旨在确保数据的质量和一致性。它包括制定数据管理策略、建立数据管理流程、监控数据质量、保护数据安全等方面。数据治理的目标是提高数据的可用性、可靠性和安全性，为企业决策提供准确、及时的信息支持。通过有效的数据治理，企业可以更好地利用数据资源，提高运营效率，降低成本，增强竞争力。
作者其他创作
大纲/内容
数据管理协会知识体系 – DAMA-DMBOK2 (十大职能域)
DCMM：数据管理能力成熟度评估（2018）
数据资产管理实践白皮书（信通院）
理论支撑
数据治理是对数据资产管理行使权力和控制的活动集合（规划、监控和执行）。
概念
需求层次
数据质量、标准规范、成本控制、数据安全、研发及管理效率
数据治理需要治理哪些问题
数据治理概念
数据治理成效进展缓慢，数据问题依旧严重，缺少系统化的工具平台支撑治理落地和成效展现是关键原因之一
数据治理咨询成果落地不足
业务人员使用数据更多需要数据和技术人员的贴身服务，按照IT建设的模式提出数据加工需求或者取数需求，以被动支持的方式满足业务需求，没有形成数据资产目录，数据服务目录
自动化服务程度不高
缺少量化方式来评估数据治理成熟度水平，数据治理工作的推动成效无法体现，变成了纯手动的脏活累活，严重影响数据治理工作的开展推进
数据治理成效可视度低
缺少灵活友好的数据治理在线管理工具，来支持数据治理全流程工作数据治理与数据原仓之间没有打通，“数据的描述”和“数据的记录”两张皮
数据治理在线管理能力不足
痛点
标准化规范缺失：数据⽣产、存储和应⽤各环节的流程，规范⽆统⼀标准
数据质量问题多：数据冗余多，数据烟囱式建设，指标⼝径乱，⽆法保证数据⼀致性
数据安全控制弱：数据⽣产和查询权限⽆统⼀规则，数据密级⽆统⼀管理
数据管理和运维效率低：数据使⽤问题的咨询多，数据RD需要花费⼤量时间解答业务同学的问题
问题
数据治理痛点和问题
核心目标：数据资产化、数据价值释放
自上而下：从公司治理角度入手来解决数据的管理问题，提供足够的授权和支持
自下而上：以平台技术支撑和完善的运营体系促进治理的切实落地
总述
固定的专业组织、充分赋权，负责数据治理实施的整体推进。制规范 定目标 促落地 保健康
从实践中总结制定一系列的管理办法、流程和规范，并及时演进迭代
数据资产治理规范：1管理办法；2管理流程3技术规范及模板
制度保障
组织体系（组织建设、制度保障）
数据运营思想贯穿数据建设全过程
数据资产治理方法论（产出及时、质量可靠、易找易用、安全可控、生产经济）
健康分：存储健康分、计算健康分
成本账单：每周发送详细的、成本账单给具体、资源使用人
专项行动：针对成本治理的“雷 霆行动”;构建BU治理排行榜
构建量化的数据治理评价体系，日常治理运营和专项整治相结合，促进治理工作持续落地改进
运营
平台工具支撑&运营
理论
数据治理策略
从传统架构思维向DT架构思维转变，围绕数据资产化、数据价值释放的核心目标开展工作
以IT流程驱动，以IT支撑位中心，以数据为基础
以传统4V为基础构为基础
授之以网（打鱼的工具）
需求和数据为导向
传统架构思维
以商业问题和业务场景为驱动，以数据资产为核心
以问题、数据、生产、创新\"四维\"度为基础
授之以渔（提供打鱼的方法及工具）
问题和数据价值为导向
DT架构思维
变思维：转变传统思维定式，IT思维向DT思维转型变模式：工具和技术是生产工具，数据才是核心，IT流程不是核心变定位：摆脱成本中心泥潭，通过运营数据资产，探索如何成为利润中心
企业数据治理新模式
解决数据产出及时性和准确性
1.数据稳定性与质量治理
解决数据口径一致性问题
2.数据规范治理
解决数据权限控制与数据共享交换问题
3.数据安全治理
解决数据计算和存储成本高昂问题
4.数据成本治理
数据治理实施的阶段
千万级任务的调度情况下，调度依赖关系复杂程度远超过人工处理程度，独有智能基线监控机制确保高优先任务高保障产出。
监控数量:监控所有任务是不现实的配置难度:为每个任务配置监控规则极为繁琐告警时间:每个任务所需告警的时间都不同
监控告警的痛点
智能识别关键路径，合理设定告警阈值任务异常产生事件，自动评估事件影响范围，通知相应人员灵活告警方式配置，支持钉钉群机器人、电话
智能监控核心功能
监控预警图
数据稳定性
数仓规范性差、数据⼀致性问题多、数据应⽤⽆法把控、多个产品中指标逻辑不同
数据质量体现主要问题
通过完整性、有效性、准确性、唯一性、一致性、合理性的全面评估，产出可信的、高价值密度的数据资产
质量评估
模板规则：表主键唯一、字段空值检查、字段枚举值检查 以及自定义规则
•质量监控与调度挂钩，第一时间发现问题； 40+规则&自定义规则，精细化质量控制； 无需设定阈值，算法自动判断异常值•故障快速恢复
质量治理图
核心公共层数据资产：1）做规范管控，架构评审，发布管控2）评估建设水平3）发现短板，持续改进
一条门槛线 1）确定标准、流程及规范 2）筛选核心公共层监控范围并持续更新
核心公共层数据
通过规范设计和开发来预防问题的发生。统一公共层来减少重复建设和确保口径一致性。
数据规范设计
高内聚低耦合
公共计算逻辑下沉
实际原则
数据模型设计
数据处理任务设计
数据服务开放
数据规范治理
数据质量治理
方针：1.事前（标准化规范）--》事中（配置化开发）--》事后（规则化验证）2.通过制定码表、元素、模型分层、数据模型等设计规则及字段内容质量约束，保证逻辑数据模型设计的一致性
主题域划分
数仓分层
逻辑命名规则：
表字段命名、类型、词根
公共维度、关联关系
制定各类数据实体（元素、码表、 模型分层、模型等）的设计约束，规范每类业务实体包含的属性、该 属性是否必选、该属性内容约束等规则。
标准编码规范
中英文缩写规范
物理模型规范
模型设计规范
开发流程规范
很多任务会直接读写文件，导致数据血缘缺失。为达到一个完备的数据血缘，新的规范会强制要求所有人要在读写表的基础上进行。任务会有纯SQL，或者是SQL和API结合的方式。为了统一开发规范和流程，降低运维成本，新规范要求公共层模型必须用纯SQL来执行，并且我们定义了一个SQL规范来去执行。多表和多任务可能会合并到一个workflow里面去，导致一个workflow里可能有几十个甚至上百个任务节点，对任务管理造成了比较大的影响，也不利于性能和资源分析，因此我们要求一个workflow只能输出一个正式表，额外的好处是任务的查找也变得更加方便。多workflow间通过数据检查依赖去执行的方式，对运维也造成了一定影响。比如任务出现了失败或者异常如何快速做数据恢复。在新的规范里，我们基于开发平台做跨流任务依赖，以此构建任务血缘，进而有效地进行基线诊断和运维
代码编写
模型开发规范
标准化规范
模型基础信息
数仓主题和分层
ETL代码⽣成
模型开发工具
模型命名标准化
⾃动命名标准化
命名规则⼯具
数仓规范性监测
数据依赖监测
上线规则监测⼯具
配置化开发
数据⾎缘
数仓相似度
数仓规范监控
数仓规范报告
数据冗余报告
规则化验证
数据标准管理
事前预防-权限管控： 数据密级规范、权限审批规范
事中监控-数据安全：数据脱敏 、查询权限控制、 查询风险监控
事后追踪-应⽤审计：查询和下载、日志数据使用审计
方针：事前预防、事中监控、事后追踪
密文处置原则，所有高敏感的数据都要密文传输
最晚解密原则，在应用层产品使用的话，不要在数据仓库层解密
最小范围提取原则，如果只用一万条数据只能对一万条数据解密
最小授权原则，用多少给多少
全程审计原则，从系统流出到使用全过程都是有措施保障
数据使用原则
数据源头层 生成过程加密、数据存储层分层脱敏/加密、数据使用层全程监控审计；通过三层系统控制加五个使用原则实现。从数据产生的源头业务系统里就会将一些非常敏感的用户数据加密，数据仓库层会对各分层的数据进行脱敏和二次加密，第三层专门做一些数据审计，在数据使用全流程中提供信息提示和审计报告。
数据分层管控
数据分类分级与权限控制
敏感数据发现与脱敏：基于元数据，识别需要脱敏的数据，自动脱敏或者给用户筛选需要脱敏的数据列
可信计算环境
数据风险审计
策略
数据安全治理
设定组织成本目标--》培养个人成本意识--》计算存储成本-》成本治理评估与运营
冷数据治理、重复数据治理、数据生命周期管理、存储格式压缩
存储类
无效任务治理、提高资源满用率、资源统一管理
拆解执行过程，降低任务的失败或者延迟恢复的成本。因为某一个节点失败之后，可能我们只需要从这个节点重新进行恢复，不需要重新执行整个任务，因为有时候重新执行整个任务需要好几个小时
避免做过度拆解，因为可能多余的任务启动和IO的过程反而会导致效率的下降
需要缓存的中间结果拆解。要考虑先做子节点的拆解，避免重复计算
尽量避免拆解为串行任务。拆为串行任务并没有优化整个执行过程，反而导致了多余任务启动还有IO过程的问题
依赖产出不稳定的多个部分拆解。比如将上游产出不稳定的部分拆分为多个节点，这样就能够降低上游任务的影响，分散计算资源占用的时间
超长任务优化：
数据任务依赖数据链路一致，DAG
shema的定义，字段相似度高
数据探查，安全组规则扫描，数据抽样比对
相似数据模型治理
计算类
日志下游应用监控、日志上报方式优化、无效埋点优化
日志采集类
成本精细化拆分
整体的方案策略方面做了精细化拆分，比如按租户（每个业务线的用户）来看，租户下有队列，队列有离线、有实时。队列下面有计算、存储、采集，计算之中又分离线、实时，有些配置量、使用量。这样可以非常容易地定位到哪些租户、哪些数仓是有问题的，对应快速治理。这方面也做了很多系统化的事情，比如有一个数据冗余判断的逻辑，每次做完数仓建模之后，会做冗余判断。元数据生成之后进行预处理，根据现有的数据做预判，看是否已存在。通过配置的对比逻辑，如果认为数据重复，会做标记并每周推送到数据治理的看板上，及时将冗余数据治理掉。
数据成本治理
找不到，不知道数据有没有、在哪里。
看不懂，有很多业务方不是技术研发团队的，看不懂数据到底什么含义、怎么关联查询、来源于哪个业务系统
不会用，如何写SQL或者哪些产品里面能查询到自己想要的数据指标。
面临问题
目标：找得到、看得懂、用得对
构建数据使用指南系统
根据PDCA原则，将数据治理作为日常运营项目做起来，底层依赖数据指标体系进行监控，之上从发现问题到提出优化方案，然后跟进处理，再到日常监控构成一个循环
措施
数据运营
数据治理实践
数据从⽣产、加⼯到服务整个链路很⻓，任何⼀个环节都可能存在需要治理的问题，如何标准化？
链路⻓，问题多并且分散，⽆法聚焦
问题如何量化？并且治理了⼀段时间，结果怎么衡量？
怎么衡量资产好坏，治理到什么程度算好
治理进⼊深⽔区了怎么办？如何动态调整治理的⽅向？
应该重点解决哪些问题，并且不同阶段的治理侧重不同
怎么提⾼意识并驱动各个团队进⾏治理？
治理动⼒不⾜
数据治理面临挑战
⽬标：问题标准化、治理可量化、过程策略化、运营有抓⼿
策略：
可度量、业务相关、趋势分析阈值设定
衡量指标制定原则
在监控方式上分为日常监控和定期监控（周、月、季度监控），让我们知道整体数据治理是整体向好、平稳还是向坏的
指标监控分周期
基于元数据的衡量指标体系
制定数据衡量指标体系，总体分为五大类：质量类、成本类、安全、易用性和价值，衡量数仓治理的效果
⽆数据可⽤、⼝径不⼀致、分析效率慢
模型问题
模型设计阶段：需求/口径统一管理、模型设计规范、指标定义与管理规范、模型评审
模型生产阶段：模型设计/开发规范检查、数据测试报告、任务发布规范检查、数据监控规范检查
模型服务目标：资产丰富、数据好找、数据好用
解决方案
规范性：定义规范、开发规范、测试规范、发布规范、元数据规范
复⽤性：模型宽度、模型深度
完整性：跨层引⽤率、明细表查询占⽐、汇总表查询占⽐
评估
模型
链路⻓，问题多、意识差，被动发现、
质量问题
数据源质量保障：数据源规范生产；数据源监控；变更同步；影响分析
加工链路质量保障：引擎稳定性保障、模型设计规范检查、代码规范检查、数据测试保障、发布规范检查
线上监控质量保障：基线保障、数据质检、监控完整度检查、监控报警准确率保障
质量问题处理流程：质量问题提报-》质量问题分析-》 跟进/解决/验证-》 故障定级/复盘-》 专项问题改进
不规范Case数(避免发⽣)：埋点规范覆盖率、模型设计规范覆盖率、开发规范覆盖率
监控发现问题占⽐（主动发现）：数据源监控覆盖率、完备监控覆盖率、监控报警准确率
质量故障/问题数（结果指标）：准确性故障/问题数、时效性故障/问题数、基线破线次数、故障/问题⽌损效率
质量
体量大，管理难、缺少成本意识、数据只上不下
⼤数据引擎优化：HDFS EC、数据重分布、冷数据存储、资源调度优化
数据建设过程优化：数据资产分级存储、数据⽣命周期管理、重复建设检测、任务优化、极限存储
成本运营管理：Quota管理、成本账单、治理榜单
⽆效存储量：N天0热度；分区数据重复
⽆效计算量：N天0热度；N天⽆产出；重复模型计算
异常存储量：⽣命周期不合理；未EC；未压缩；待归档冷数据；分区数据相似
异常计算量：任务失败次数过多；申请计算资源过⼤；⼩⽂件过多；Map数过多；不合理⼩时任务
待治理成本资源量
成本
得分策略
资产健康评估
运营机制
治理收益评估
数据治理评估体系
数据治理评估
阶段性治理，没有统筹考虑，主要是基于单个问题的治理，而且治理之后过一段时间可能要做重复治理。这个阶段更多是人治，一个项目成立，协调几个人按照项目制完成，没有体系规划也没有组织保障
被动治理
有长期的统筹规划，能覆盖到数据生命周期的各个链路，在治理过程中把一些手段和经验流程化、标准化、系统化，长期解决一些数据问题，让数据治理长期可控
主动治理
希望长期规划和数据生命周期个环节链路确定好之后，把已经有的经验、流程和标准做成策略。一旦出现问题，自动监控，通过一些系统化的方式解决。自动治理的第一步还是治理方案的落地和策略化，这就非常依赖于元数据，把数据治理各个过程中的一些经验技术都沉淀起来。做完策略沉淀之后做自动化，把策略用工具的方式实现，当系统发现数据有问题时，自动去处理
自动治理（智能治理）
数据治理未来规划
数据治理
0 条评论
回复 删除
下一页
