网易有道成人教育数仓建设实践

导读：

随着有道旗下网易云课堂、中国大学mooc产品的迅速发展，对数据的需求日益增多，在提高数据服务质量和数据使用效率、降低数据使用成本、数据赋能业务的背景下，我们从0到1建设成人教育数据仓库。

整体架构

数据仓库建设过程

2.1 业务调研

业务调研需要从自上而下和自上而下两个方向去执行：

自上而下和自上而下双管齐下是为了更全面调研业务系统的数据。避免出现基于少量的业务调研设计的数仓架构和规范不满足后面业务的扩展，影响数仓的稳定性。

2.2 架构设计

平台架构：

平台组件技术选型及架构设计，根据业务调研结果选型包括计算引擎、存储、调度系统等组件。目前有数大数据平台基本满足离线数仓的架构需求。

数仓分层架构：

数仓总线矩阵：

划分数据域，构建业务过程与维度关系矩阵，总线矩阵中行表示业务过程，列表示维度，通过总线矩阵梳理业务过程和维度关系，是模型设计过程的基本工具，以此来保证维度跨多业务过程的一致性，以及防止在事实表设计时遗漏关联维度。

2.3 模型设计

整个数仓是按照kimball的维度建模方式建设，设计步骤如下：

（1）选择业务过程

选择业务活动行为的过程，如：下单、支付、看视频。

（2）声明粒度

粒度即事实表中每行数据代表什么，明细表中应声明业务过程最细的粒度，如：每个课程的订单记录，支付的每一笔钱记录，每次打开视频的观看记录。

（3）确定维度

维度是用来描述业务过程发生的环境实体，如：谁在什么时候什么地方以何种方式下单。

（4）确定事实

确定业务过程中的度量，即原子指标，如：下单金额、支付金额、观看时间。

（5）冗余维度

冗余常用维度信息至事实表中，提高模型使用效率，冗余的过程中应尽量使用已经开发好的维表，保证维度属性的逻辑一致性。

通过上面的步骤我们大概能设计出围绕一个业务过程的星型模型，当多个星型模型通过事实表或者维度表相互连接时，就形成了数仓中常见的事实星座模型。

2.4 模型开发

2.4.1 开发原则

（1）高内聚低耦合

将业务相近或者相关的数据、粒度相同数据设计为一个逻辑或者物理模型；将高概率同时访问的数据放在一起，将低概率同时访问的数据分开存储。

（2）核心模型与扩展模型分离

在设计明细表和维度表的时候，采用垂直切分的方式，将常用字段保留在核心模型，将一些大字段、个性化或者少量应用的字段剥离到扩展模型，常用杂项维度的方式，保证核心模型的简洁

（3）公共处理逻辑下沉以及单一

将业务数据处理逻辑下沉至明细层进行处理，不暴露给应用层，并保证处理逻辑单一存在。

（4）适当冗余

针对常用维度属性冗余在明细层和汇总层，提高开发效率。

（5）数据可回滚

处理逻辑不变，全量处理在不同时间多次运行数据的结果需要确定不变，增量处理根据输入时间变化可回刷历史数据。

2.4.2 开发规范

原则上层次调用关系为ODS>DWD>DWS>ADS,部分需要针对明细层的需求或者不稳定的业务场景可遵循ODS>DWD>ADS。禁止反向依赖。比如DWS依赖ADS，造成任务深度多大，相互依赖等问题；
ODS层不能被应用层直接调用，如不确定数据处理逻辑的可先在明细层建立视图，通过视图访问；
多个计算任务输出至一个表时，需要建立一个依赖这多个任务的虚拟节点进行管理；
DWS层进行粗粒度汇总时，优先调用已经产出DWS较细粒度汇总，可避免直接从明细层计算，提高计算效率；
一个计算任务只能输出至一个表；
一个计算任务中间使用的临时表不得被其他任务使用；
建表必须对字段和表描述进行中文描述；
指标类的字段空值用零填充，维度属性值为空的用-99(未知)填充。