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

在之前的两篇文章，我们介绍了数据仓库的基本概念、质量数仓建设过程和使用到的产品。本文将以 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 年加入网易。参与数据产品技术部多个重点产品质量保障工作，建设并完善数据产品部质量保障体系，致力于质量保障工作效能得提升。

相关阅读：

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

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