洋码头数据仓库实践

Posted 2021-04-24 洋码头技术

作者介绍

孔永兵, 洋码头高级数据仓库工程师
长期从事数据仓库相关工作，有丰富的数据库开发、设计、性能调优及仓库架构经验，目前负责洋码头数据仓库架构设计及BI事务。

---

随着洋码头公司业务的快速发展，需要分析和处理的数据更加多元化和复杂化，原有传统关系型数据架构已很难满足公司各业务方面的需求。数据仓库的建立将洋码头业务按不同的主题进行维度建模，实现数据快速读取、及时响应，同时也为产品、运营及数据分析人员提供了更加方便快捷的数据提取平台。本文对洋码头数据仓库从无到有的过程做个大体介绍。

本文约2400字，可参阅下面的大纲阅读。

• 1. 洋码头数据仓库的三个阶段

• 2. 洋码头数据仓库技术架构

• 2.1 架构

• 2.2 维度建模

• 3. 遇到过的问题

• 3.1 代理键的使用

• 3.2 迟到维度的处理

• 3.3 缓慢变化维的处理

• 4. 参考书籍

1. 洋码头数据仓库的三个阶段

洋码头数据仓库的发展经历了从简单报表阶段、数据集市阶段再到数据仓库阶段的过程。

• 简单报表阶段 在此阶段，系统的主要目标是解决一些业务运营人员的日常报表展现，以及生成一些简单的能够帮助领导进行决策所需要的汇总数据，灵活性差，性能低。

• 数据集市阶段 在数据仓库建立之前，根据特定部门业务人员的需要，进行指标整理、清洗、转换，进行多维报表的展现，为特定业务提供数据支持及决策。

• 数据仓库阶段 按照业务主题进行划分，使用kimball经典的维度建模方法，经过指标清洗、转换，构建成一致性维度及事实表，提供跨部门的，完全一致的业务报表数据。数据仓库建好以后，数据提取效率有了质的提升，与前端报表工具整合更加容易。

 

2. 洋码头数据仓库技术架构

2.1 架构

图1 -  架构图

如上图所示，洋码头数据仓库由数据源, 数据整合, 数据存储, 数据展现&分析,及ETL调度等几个模块构成。

2.1.1 数据源

洋码头的业务数据来源于SQL Server、mysql、MongoDB，包含了用户、买手、商品、优惠券、活动、订单、物流等码头核心业务数据。

用户行为数据来源于前端埋点生成的各种访问、点击事件，通过用户行为数据来分析app页面模块的粘性、活跃程度及产出情况。

2.1.2 数据整合

数据整合层将数据源中数据通过ETL框架平台经清洗，整合及转换后存储到数据存储层，在数据抽取转换过程中，根据不同的业务采取不同的调度频度。

2.1.3 数据存储

数据存储层又可分为ODS层、DW层及DataMart层。

• ODS层用于存储自源系统抽取过来并经过清洗后的数据，由于该层是准实时的数据，大部分准实时的报表数据都来源于ODS层。

• DW层是采用kimball的总线式数据仓库架构，针对各主题进行维度建模后构建的一致性维度及事实表，DW层的粒度是原子的，即存放各主题域的最细粒度数据。洋码头目前分布的几个重要的主题有用户、买手、商品、优惠券、活动、订单、物流。

• DataMart层存放经由DW层数据经过一定的加工、汇总聚合而成的宽表，如用户画像、买手经营能力指标、买手DSR指标、商品动销数据、物流监控等。

2.1.4 数据展现

报表展现及数据指标监控，为运营人员提供运营效果展现及运营决策支持，为管理层提供决策依据。数据分析及数据挖掘，为特定主题中主体进行价值分层，如用户价值分层。

2.1.5 ETL调度

在ETL调度中，根据不同的业务需求配置不同调度，如从数据源到ODS的并行抽取调度，及DW中根据各主题域按顺序依赖进行调度。在调度中详细记录每个任务的开始、结束时间，状态，新增记录数，更新记录数，错误日记及遇到错误是及时报警。

图2 - ETL日记

 

2.2 维度建模

2.2.1 模型选择：星型vs雪花型

在维度建模过程中，根据事实表和维度表的关系，可将常见的模型分为星型模型和雪花型模型。在设计逻辑数据模型的时候，应考虑数据是按照星型模型还是雪花型模型进行组织。

星型架构是一种非正规化的结构，多维数据集的每一个维度都直接与事实表相连接，不存在渐变维度，所以数据有一定的冗余。 也正因为这种冗余，很多统计查询不需要做外部的连接所以一般情况下效率比雪花型要高。

雪花模型是对星型模型的扩展。它对星型模型的维表进一步层次化，原有的各维表可能被扩展为小的事实表，形成一些局部的 " 层次 " 区域，这些被分解的表都连接到主维度表而不是事实表。

在洋码头数据仓库建设中，两种模型都有用到，但用的最多的是星型模型，这样不只是查询效率更高，对于不甚了解业务的新员工，相对雪花模型，能够快速、较好地操纵模型。

图3 - 星型模型

图4 - 雪花型模型

 

2.2.2 逻辑设计

维度模型的逻辑设计是由四个主要决策所驱动的。

1) 选择业务过程

第一步是选择要建模的业务过程，业务过程是维度数据仓库的基石，每个业务过程至少会产生一个事实表。以订单业务为例，确定订单业务后，首先要对订单数据进行初探，了解该业务中有哪些数据产生及产生该数据时是否关联其他业务。

2) 声明粒度

声明粒度也可以理解为声明主键，选择粒度时既要考虑到用什么来满足业务需求，又要考虑基于源系统收集的数据可以得到什么。数据仓库中建议存放最细粒度的数据，以订单业务为例，订单业务将会产生两个事实表，基于订单号粒度及订单号加商品规格粒度。

3) 确定维度

当确定好粒度后，大多主要维度也就很自然的产生了，以订单为例，粒度确定好了，对应的维度：用户、买手、商品、活动、优惠券等都已确定。

4) 确定事实

确定事实也叫确定度量，大多数面向事务的业务过程只有少量的基础事实，如数量和金额，但是却有很多从这些基础事实导出的组合和计算结果，以订单为例，有订单金额、商品数量、商品单价、商品金额、优惠券金额、实付金额等许多度量值。

图5 - 维度建模

 

3. 遇到过的问题

1) 代理键的使用

是否要使用代理键？这是维度建模过程中经常遇到的问题。

1. 如果数据仓库数据来源于不同的系统，且各系统之间的主体需要合并以达到企业一致性维度时，需要使用代理键。

2. 如果数据仓库维度表涉及到缓慢变化维，需要跟踪到历史数据，需要使用代理键。

3. 如果数据仓库中业务键是字符类型(如Guid)，做关联查询时效率非常低，建议使用代理键。

洋码头数据仓库在维度建模过程中主要针对后两种情况来生成代理键。

2) 迟到维度的处理

数据仓库的重要特点之一就是一致性维度，由于洋码头数据仓库在建设过程中使用了代理建，导致有时候某些维度(如优惠券、商品)可能有比事实记录晚到的情况。此时需要在维度表中建立一条“未知”的维度记录，对于迟到的维度，都将该“未知”维度的代理键做为相关事实表的外键。等迟到的维度到来后，再将建立好的维度的代理键更新到相关的事实表中。

 图6 - 迟到维度处理

3) 缓慢变化维的处理

在洋码头数据仓库维度建模过程中，针对需要根据时间追踪历史数据的维度，使用Type2-添加一个新的维度行的方式来处理，如下例，员工金波2015/4/8前居住在广州，之后搬到上海，按照覆盖原值的方式，金波的现居地为上海，按区域统计数据时他所有的销售数据都会归到上海。现将用户维度做成缓慢变化维，在统计金波2015/4/8之前销售的数据时，归属地为广州，以此达到追踪历史的目的，该方法同样可以用在拉链表的设计上。

图7 - 缓慢变化维处理

 

 

4. 参考书籍

• 数据仓库生命周期工具箱(The Data Warehouse Lifecycle Toolkit) ---  Ralph Kimball

• 数据仓库工具箱：维度建模权威指南(The DataWarehouseToolkit:The Definitive Guide to DimensionalModeling) --- Ralph Kimball

 

全文完

---

历史分享：

• 
  

• 
  

• 
  

• 
  

• 
  

---

近期分享预告：

• 洋码头搜索应用架构

• 洋码头应用监控

• 洋码头异步框架

每周我们都会推送一篇由洋码头一线工程师写的技术分享。关注【洋码头技术】，第一时间获取我们最新的技术分享推送吧。