Press "Enter" to skip to content

严选质量数仓建设(三)—— 数仓开发实例

本站内容均来自兴趣收集,如不慎侵害的您的相关权益,请留言告知,我们将尽快删除.谢谢.

在之前的两篇文章,我们介绍了数据仓库的基本概念、质量数仓建设过程和使用到的产品。本文将以 Bug 数据开发设计为例,通过实战了解质量数仓建设过程。

 

数据分层

 

数据分层,与应用开发中的 mvc 模式一样,数据分层的目的是更好的管理数据,对数据能有一个更加清晰的掌控。数据分层使的数据具有清晰的数据结构,便于进行数据血缘追踪,能够把复杂问题简单化,减少重复开发,屏蔽原始数据的异常和业务的影响。每个企业或组织由于各自业务、规范、目标不尽相同,分层的策略可能会有一些区分,通用的数据分层结构如下图所示。

 

 

ODS 层

 

数据存储操作层,是最接近数据源中数据的一层,数据源中的数据经过 ETL 之后装入本层,一般来讲,为了追溯数据的问题,因此,本层数据一般不做过多的数据清洗工作,原封不动的接入原始数据即可。

 

DWD 层

 

数据明细层,该层一般保持和 ODS 层一样的数据粒度,并且提供一定的数据质量保证(统一业务过程、基于业务过程清洗数据,完备数据)。同时,为了提高数据明细层的易用性,该层会将一些维度冗余到事实表中,减少事实表和维度的关联,提高查询效率。

 

DWS 层

 

数据服务层,按照业务划分,基于 DWD 层的数据,做一些聚合操作,生成字段比较多的宽表,提升公共指标的复用性,减少重复加工,用于提供后续的业务查询。

 

DM 层

 

数据集市层,基于 DW 层数据,根据业务需求实现数据模型,一般会跨多个主题域,主要提供给数据产品和数据分析使用的数据,一般存储在 ES、Redis、HBase 等存储中,供线上系统使用。

 

DIM 层

 

维表层,维表层就是所有维度表的集合。

 

质量数仓开发实例

 

选择业务过程

 

业务过程是由组织完成的微观活动,包含以下公共特征:

业务过程通常用行为动词表示,因为他们通常表示业务执行的活动;
业务过程通常由某个操作型系统支撑;
业务过程建立或获取关键性能度量;
业务过程通常由输入激活,产生输出度量。

第一个数仓项目应该选择最为关键的、最易实现(包括数据可用性与质量,以及准备工作等)的业务过程。

 

在质量数仓建设中,bug 提报及处理是与质量最直接相关的业务过程,数据质量较高,这份数据使用户能够分析已提报的 bug ,它们是在何时、由谁、在哪个项目中发现的,严重程度如何,处理花费了多长时间等。

 

声明粒度

 

声明粒度意味着精确定义某个事实表的每一行表示什幺。事实度量越详细,就越能获得更确定的事实,原子数据能够提供最佳的分析灵活性,维度模型中的细节数据可与 i 适应用户比较随意的查询请求。设计开发的维度模型应该表示由业务过程获取的最详细的原子信息。

 

也可以定义汇总粒度来表示对原子数据的聚集,但是,较高级别的粒度会限制更细节维度的可能性,无法实现用户下钻细节的需求。

 

在 bug 提报与处理的业务过程中,最细粒度的数据是 JIRA 用户提报的单个 bug。选择最细粒度的原子信息作为粒度,也能够更容易的检查数据质量。

 

确定维度

 

维度要解决的问题是“业务人员如何描述来自业务过程度量事件的数据?”在选择每个维度时,应该列出所有具体的、文本类型的属性以充实每个维度表。

 

详细的粒度说明确定了事实表的主要维度。在 bug 提报与处理的业务过程中,Bug 的提报日期、解决日期、创建人、所属产品、优先级等都是需要包含的维度属性。

 

确定事实

 

设计的最后一步是确认应该将哪些事实放到事实表中。确定事实就是回答 “过程的度量是什幺”,典型事实是可加性数值,明显属于不同粒度的事实必须放在不同的事实表中。

 

设计的最后一步是确认应该将哪些事实放到实施表中。事实必须与粒度相吻合,Jira 系统中收集到的有 bug 数量、bug 修复时长。

 

此外,还有一些通过计算得到的事实,如在时间维度上进行汇总后得到的每月新增的总 bug 数、每月 bug 的平均修复时长等;这些计算得到的事实,也应该存储在数仓系统当中,避免用户自行计算使用时产生错误的可能性。

 

而部分只能通过计算得到的不可加事实,如 P0 级 bug 率,只能通过 P0 级 bug 数量除以所有 bug 数量得到,这种不能从任何维度被汇总的事实,称为非可加事实,只能通过 BI 工具计算获得,一般不存储数仓系统数据库中。

 

上述提到的 bug 数量、bug 修复时长是原子粒度上的事实,属于一个事实表,如下图 1 所示,而计算事实每月新增 bug 数、每月新增 bug 平均修复时长等,则属于在时间周期上的汇总粒度,应属于另一个事实表,除此之外,我们还关心,各个优先级的 bug 占比、修复时长、关闭率等(如下图 2 所示),确定关心的事实及它们所属的事实表,也就完成了我们的事实表设计。

 

 

数据入仓

 

在前面的步骤中,我们已经明确了我们需要分析的数据包含哪些,接下来,我们需要梳理业务数据库,找出所需要的数据在业务库中的存储在哪些表当中,它们之间的关系是怎样的(通常这部分应当由业务库的开发人员提供,而质量数仓中由于对接的大部分业务系统并没有对应的开发,所以需要数据开发同学自行梳理、发现)。

 

在本实例中,我们经过梳理发现 Jira 中相关的表有 issue 记录表、project 记录表、user 记录表,以及 issue 优先级、状态对应关系、版本关联关系表等,通过 datahub 平台的数据同步功能,将 Jira 数据库中对应的表同步到数仓的 RDB 库中就完成了数据入仓的任务。

 

数据清洗

 

接下来要进行数据清洗,数据清洗主要是为了解决数据质量问题,包括数据的完整性、唯一性、权威性、合法性、一致性。

 

在 Bug 数据开发示例中,相关的用户信息中,部分 jira 用户仅有用户的邮箱前缀,缺乏用户姓名、邮箱、所属团队等信息,在入仓后,我们要通过邮箱前缀,在其他已入仓的表中查找到相关的用户信息,补充到 jira 用户表中,这是解决完整性的问题。

 

在 Bug 记录中,每一个 bug 都归属某一个项目,而这个项目与我们的业务域是无法对应的,因此,如果需要将项目与业务域对应起来,则需要将项目对应到我们 cmdb 中的服务,所有质量数仓涉及到业务域的数据,都以 cmdb 的数据为准,如果业务系统中没有,则要在清洗时根据映射关系去对应,这是解决权威性问题(要使用最权威可信的数据)。

 

而数据的唯一性则是指,业务系统中可能存在多条重复记录,在清洗时,需要以主键去重;合法性则是要求字段必须符合一定的规则,如性别必须是“男”、“女”、“保密”中的一种,如出现其他取值,要幺剔除、要幺设置为默认、要幺报警提醒人工处理,避免数据对分析造成影响;一致性则是指同一个指标(或同一个名称),在系统各处应是相同的含义、计算口径。

 

数据加工

 

经过前面的步骤,我们已经得到了可靠的源数据,后面则是根据前期需求分析的结果,根据质量数仓的开发规范,建立对应的维度表、事实表(业务入仓的数据表,位于 ods 库,清洗后的明细数据位于 dwd 库,维度数据位于 dim 库,而轻度汇总的数据位于 dws 库);创建任务加工数据写入对应的表,并设置调度规则。

 

本文的实例,是最简单的一些维度表和事实表的设计,除此之外,数仓建设中还有许多进阶设计方法等待我们一起去发现。

 

作者简介

 

婧雯,网易严选资深测试工程师,2014 年毕业于北京理工大学,2017 年加入网易。参与数据产品技术部多个重点产品质量保障工作,建设并完善数据产品部质量保障体系,致力于质量保障工作效能得提升。

Be First to Comment

发表评论

电子邮件地址不会被公开。 必填项已用*标注