如何评价数仓建设的好坏？

吵吵叭火

已于 2024-08-04 22:48:11 修改

阅读量285

点赞数 14

分类专栏： # 公司数仓文章标签：大数据

于 2024-08-04 16:07:20 首次发布

本文链接：https://blog.csdn.net/SHWAITME/article/details/140907337

版权

公司数仓专栏收录该内容

5 篇文章 0 订阅

订阅专栏

近期面试被问到，现总结一下，欢迎交流~

前言

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

一、数据质量

1.1 产生原因

1.1.1 技术

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

1.1.2 业务

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

1.1.3 管理

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

1.2 评估方法

1.2.1 准确性

定义：描述数据和客观实体特征是否相一致。

(1)是否基础dqc覆盖全链路（基础dqc）

表不为空
主键（联合主键）唯一
字段不为空
表行数波动

(2)核心表业务dqc是否配置（业务dqc）

a) 文本类

字段不为空或空串
json中的Key不能为空
字段是否脱敏

b) 数值类

数值在区间范围
字段不能为0

c) 枚举值

枚举值类型是否正常
枚举值波动
枚举值占比

d) 日期

字段不为空
日期小于当天

(3)dqc历史趋势

a0 nnn历史触发情况
强/弱dqc触发次数

1.2.2 及时性

定义：描述业务数据能够被使用的及时程度

   (1)是否有基线SLA (核心业务)配置；
   (2)未按时交付数据次数（被业务方发现投诉）；
   (3)基线SLA 破线次数；
   (4)基线SLA 覆盖度；
   (5)是否具备快恢能力（当数据未产出时候，迅速定位还原）；

1.2.3 一致性

定义：描述同一个信息主体在不同数据集中的数据是否相同.

(1)数据收口

核心指标下沉到核心聚合模型dws，统一收口

(2)指标中心建设

保障指标统一：指标录入，指标口径查询、指标展示，指标复用等有处可循

1.2.4 流程完整性

(1)数据质量长期跟踪监测体系

a)收集问题

问题/缺陷上报平台；
wiki,飞书等文档记录；

b)解决/防止复发问题

解决问题；
对问题进行规则化制定；
对问题长期监控，直到问题彻底解决；

(2)数据质量问题报告

a)数据问题趋势；
b)数据问题分类；
c)本期新增数；
d)本期解决数；
e)重点问题解决数；
f)数据问题贡献榜；

(3)流程制定
a)任务上线流程
b)指标下线/变更流程

1.3 实施流程

1.3.1 事前，预防

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

1.3.2 事后，复盘完善

a)归因->解决方案->方法论、流程；
   b)完善dqc规则；
   c)问题上报监测；
   d)保障数据统一收口，指标统一口径维护标准；
   e)完善数据问题定位步骤；

二、模型建设

2.1 产生原因

2.1.1 技术

无数据标准制定
缺乏模型建设复用/扩展想法

2.1.2 业务

对业务流程，环节理解不够

2.1.3 管理

团队模型建设指导不足
无模型评审机制

2.2 评估方法

2.2.1 规范度

a)是否制定命名规范
b)是否具有建设规范

模型建设5要素

数据域：对当前业务场景进行拆分，完成对应数据建设；
事实表：围绕着业务过程来设计、包含引用的维度和与业务过程有关的度量；
维度：对当前场景描述及补充；
颗粒度：数据的详细程度，颗粒度必须拆分为不可拆分的状态；
度量值：对数值类型的数据记录；

模型分层具体操作内容

ods接入层；
dwd明细表；
dws汇总表；
ads应用层；

c)是否有模型评审流程
d)主题域归属

2.2.2 完善度

具体指代：元数据补充

a)owner清晰；
b)表中文名+使用说明；
c)每个模型的颗粒度；
d)每个模型的主键（联合主键）；
e)字段解释；

2.2.3 复用度

a)模型被下游引用程度，是否是无效模型；

2.2.4 扩展度

a)模型内容划分合理性（基础字段，指标）、冗余低；
b)新增模型与老模型是否出现冲突；

2.2.5 稳定度

a)运行时长；
b)是否数据倾斜；
c)对产出的影响；

2.2.6 合理性

a)分层情况（保障模型引用合理）:跨层引用率、ods穿透率；

2.3 实施流程

2.3.1 事前，预防

a)制定模型开发规范（开发思路，模型合规）；
b)制定数据标准（命名、内容、代码等）；
c)培训指导模型建设开设模型评审会；
d)梳理业务流程；

2.3.2 事后，复盘完善

   a)完善数据标准；
   b)加强模型建设意识；
   c)模型评价打分；

三、数据安全

3.1 产生问题原因

3.1 .1 技术

数据安全意识薄弱；
未设立安全管控；

3.1 .2 业务

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

3.1 .3 管理

未做风险管理

3.2 评估方法

角色权限是否划分
权限管控制定
数据表是否分级
对外数据是否脱敏
可视化展示是否分级展示内容

3.3 实施流程

3.3 .1 事前，预防

a)角色权限分级；
b)数据表权限管控（表/字段）；
c)核心/对外数据脱敏；
d)全数据表分级；

3.3 .2 事后，复盘完善

   a)补充隐藏数据风险；
   b)制定跨bu(业务线/产品线)的业务数据把控范围；
   c)定期对安全权限扫描；

四、成本/性能

4.1 产生原因

4.1.1 技术

运行时间过长；
运行报错；
重复建设；
数据倾斜；

4.1.2 管理

资源成本急剧上升；
维护成本越来越大；
数据模型的复用性低，烟囱式建设；

4.2 评估方法

4.2.1 无用/无效表是否及时下线

无下游任务的表；
x天未被访问的表；

4.2.2 表生命周期是否合理
4.2.3 数据倾斜任务数
4.2.4 运行超过xxx小时的任务总数
4.2.5 小文件过多的数据表

4.3 实施流程

4.3.1 事前，预防

a)代码审核，检查代码是否需要优化；
b)试用完对临时表，无用表及时下线；
c)任务试验跑检查运行时间；
d)前置小文件合并操作；

4.3.2 事后，复盘完善

a)定期扫描无效表；
    b)定期下线空跑任务；
    c)定期扫描模型生命周期；
    d)数据治理前任务/表量化；
    e)每日/周推送top榜（消耗、资源存储top榜）；

五、用户用数体验

5.1 产生问题原因

业务层面：找数难、用数难、查询难、自助分析难

5.2 评估方法

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

5.3 实施流程

5.3.1 事前，预防

a)了解下游对数据使用习惯；
b)了解各业务方缺少那些应用缺陷；

5.3.2 事后，复盘完善

a)补充数据平台建设；

六、数据资产覆盖

6.1 产生原因

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

6.2 评估方法

数据资产支撑：

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

6.3 实施流程

6.3.1 事前，预防

a)前置完成用户画像等常用场景数据资产沉淀；

6.3.2 事后，复盘完善

a)完善全业务场景数据资产补充；

b)补充专项应用数据标签/指标模型；