严选质量数仓建设（三）—— 数仓开发实例

在前两篇文章中，我们了解了一些数据仓库的基本概念以及质量数仓建设过程和使用到的产品。 本文以Bug数据开发设计为例，通过实战了解质量数仓建设过程。

严选质量数仓建设系列文章：

《严选质量数仓建设（一）—— 数据仓库基本概念》

《严选质量数仓建设（二）—— 质量数仓项目建设及管理》

0. 序言

在前两篇文章中，我们了解了一些数据仓库的基本概念以及质量数仓建设过程和使用到的产品。本文以Bug数据开发设计为例，通过实战了解质量数仓建设过程。

1. 数据分层

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

• ODS层

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

• DWD层

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

• DWS层

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

• DM层

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

• DIM层

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

2. 质量数 仓开发实例

2.1 选 择业务过程

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

• 业务过程通常用行为动词表示，因为他们通常表示业务执行的活动；

• 业务过程通常由某个操作型系统支撑；

• 业务过程建立或获取关键性能度量；

• 业务过程通常由输入激活，产生输出度量。

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

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

2.2 声明粒度

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

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

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

2.3 确定维度

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

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

2.4 确定事实

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

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

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

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

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

2.5 数据入仓

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

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

2.6 数据清洗

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

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

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

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

2.7 数据加工

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

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

作者简介

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

本文由作者授权严选技术团队发布