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

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