(笔记)如何评价一个数仓的好坏

本文主要是介绍(笔记)如何评价一个数仓的好坏，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

数仓评价好坏是对数仓全流程机制是否健全的评价，
从技术方面，数据仓库应该具有成本、质量、效率要求，安全方向方面的能力，
从业务方面，数据仓库应该支撑业务建设，覆盖尽可能多的业务场景，需要数据时能够及时取到，能满足业务数据化需求

1数据质量

产生原因

技术
缺少流程制定
数据模型设计存在问题
数据源本身存在问题
数据清洗加工疏忽

业务
业务理解不到位
业务流程变更
数据输入不规范
业务系统烟囱林立

管理
人才缺乏
流程管理不完善
奖惩机制不明确

评估方法

准确性：描述数据和客观实体特征是否一致-DQC
1是否基础DQC覆盖全链路：表不为空，主键（联合主键）唯一，字段不为空，表行数波动。
2核心表业务DQC是否配置：业务DQC： 文本类（字段不为空或空串，json中key不为空，字段是否脱敏），数值（数值在区间范围，字段不能为O），枚举值（枚举值类型是否正常，枚举值波动，枚举值占比），日期（字段不为空，日期小于当天）
3DQC历史趋势：历史触发情况，强弱DQC触发次数。

及时性：描述从业务数据能够被使用的及时程度
是否有基线/sla(核心与较核心业务)配置，
基线/sla破线次数，
未按时交付数据次数(被业务方发现投诉)，
基线sla覆盖度，
是否具备快恢能力（当数据未产出时候，迅速定位还原)。

一致性：描述同一个信息主体在不同数据集中的数据是否相同
数据收口：核心指标沉淀到核心聚合模型，统一收口
指标中心建设：保障指标统一:指标录入、指标复用、指标展示、指标口径查询有处可循

流程完整性：
1数据质量长期跟踪监测体系：
收集问题（问题/缺陷上报平台，文档记录）
解决/防止复发问题（解决问题，对问题进行规则化制定，对问题长期监控，直到问题彻底解决）
2数据质量问题报告：数据问题趋势，数据问题分类，本期解决数，本期新增数，重点问题解决数，数据问题贡献榜
3流程制定：任务上线流程，指标变更/下线流程

流程

事前，预防
制定质量管理机制，开发/变更/上线流程
工具/代码监控
dqc全链路基础配置
核心数据稳定产出
培训值班内容/明确数据问题如何定位

事后，复盘完善
归因->解决方案->方法论、流程
完善dqc规则
问题上报监测
保障数据统一收口，指标统一口径维护标准
完善数据问题定位步骤

2模型建设

产生问题原因

技术：无数据标准制定，缺乏模型建设复用/扩展想法
业务：对业务流程，环节理解不够
管理：团队模型建设指导不足，无模型评审机制

评估方法

规范度：
是否制定命名规范
是否具有建设规范（模型5要素，模型分层具体操作内容）
是否有模型评审流程
主题域归属

完善度-元数据补充：
（owner清晰，表中文名+使用说明，每个模型的颗粒度，每个模型的主键(联合主键)，字段解释）

**复用度：**模型被下游引用程度，是否是无效模型

**稳定性：**运行时长，是香数据倾斜，对产出的影响

**扩展性：**模型内容划分合理性(基础字段，指标)，冗余低

**合理性：**新增模型与老模型是否出现冲突，分层情况（保障模型引用合理)，跨层引用率，ods穿透率

流程

事前，预防：
制定模型开发规范（(开发思路，模型合规)，
制定数据标准（命名、内容、代码等)，
培训指导模型建设开设模型评审会，
梳理业务流程

事后，复盘完善：完善数据标准，加强模型建设意识，模型评价打分

3数据安全

产生问题原因

技术：数据安全意识薄弱，未设立安全管控

业务：各部门/业务对数据安全权限把控度不同

管理：未做风险管理，离职回收，有共担记录

评估方法

角色权限是否划分
权限管控制定：（下载权限，数据使用权限申请，数据使用申请时卡点负责人/组，闲置的权限是否定期回收）
数据表是否分级
对外数据是否脱敏
可视化展示是否分级展示内容

流程

事前，预防：角色权限分级，数据表权限管控(表/字段)，核心/对外数据脱敏，可视化展示内容把控，全数据表分级
事后，复盘完善：补充隐藏数据风险，制定跨bu/业务数据把控范围，定期对安全权限扫描

4成本/性能

产生问题原因

技术：运行时间过长运行报错，重复建设，数据倾斜，数据价值与资源消耗不匹配
管理:资源成本急剧上升，维护成本越来越大，数据之间的关系变得复杂，数据模型的复用性低，烟囱建设

评估方法

无用/无效表是否及时下线：无下游任务的表，无上游任务的表，x天未被访问的表
表生命周期是否合理
数据倾斜任务数
运行超过xxxxh任务数
是否存在空跑任务
小文件过多数据表
是否有数据成本的量化管理

流程

事前，预防：代码审核，检查代码是否需要优化，试用完对临时表，无用表及时下线，任务试验跑检查运行时间，前置小文件合并操作
事后，复盘完善：定期扫描无效表，定期下线空跑任务，数据治理前任务/表量化，定期扫描模型生命周期，每日/周推送top榜（消耗、资源存储top榜)

5 用户用数体验

产生问题原因

业务：找数难，用数难，查询难，自助分析难，无法统一内容

评估方法

数据服务：
是否具备资产门户方便下游找寻业务表，
是否整合one id/one service完成数据输出统一收口，
是否具备策略/指标平台，方便下游了解，保障口径统一，
是否具备标签/画像/指标分析工具，使得下游自助查询，解放数仓资源

流程

事前，了解： 了解下游对数据使用习惯，了解各业务方缺少那些应用缺陷
事后，完善数据服务内容： 补充数据平台建设

6数据资产覆盖

产生问题原因

业务：数据资产无法满足下游应用场景，指标分散

评估方法

数据资产支持：是否完善用户画像/用户360资产，各场景数据资产是否能全面支持，零散指标/标签是否有专题整合

流程

事前，了解： 前置完成用户画像等常用场景数据资产沉淀
事后，完善数据服务内容： 完善全业务场景数据资产补充，补充专项应用数据标签/指标模型

这篇关于(笔记)如何评价一个数仓的好坏的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！

---