toB企业数据仓库搭建流程记录

一、背景介绍

公司已发展到一定阶段，需要搭建数据中台来整合各条业务线的数据。一方面，当前的报表数据皆是从业务数据库计算得到，OLTP数据库基于业务系统而生，并不适合进行分析计算，常常需要join很多表，效率低下，且影响业务数据库性能。另一方面，公司每条业务线的数据质量参差不齐，命名、更新逻辑杂乱无章，废弃字段繁多，可用性较差。数据中台的作用就是将各业务线有潜在分析价值的数据整合起来，统一存储、分析，既可以支撑公司管理人员的决策，也可以为上层应用提供数据接口。

二、建设大纲

1、数据调研

业务调研

交付物：《业务数据表目录》
最好有各业务表之间的关联关系或者数据模型。该阶段的目的是尽可能搞清楚每张表的业务功能，包括表含义、字段含义、更新逻辑等。大部分情况下这种阶段会持续很久，且是长期的，因为业务表太多了，不可能等我们全部理解完毕再开始搭建数仓。先挑最重要的业务过程相关的表进行调研，之后再进行迭代是比较现实的做法。

需求分析

交付物《业务分析需求文档》
与运营、市场等对报表有需求的部门沟通，归纳总结他们的需求，他们需要哪些数据，怎样的数据，哪些数据会对他们的工作有帮助。

2、数据域划分

分析业务过程

交付物：《业务过程与数据域对应表》
业务过程是为达成业务目标而设定一系列标准化的业务行为事件。换句话说，充分理解公司的业务，从数据分析的角度将整个业务分成一个个不可分割的小部分，每一个小部分就叫做一个业务过程。可以从用户的行为轨迹入手进行划分。例如留资、跟进线索、下单、支付、审核等等。原则上每个业务过程会对应业务数据库一张主事实表。再根据这张主事实表找到与该业务过程相关的所有表。
将业务数据表按照业务过程分类是数仓建设前期非常重要的一步。

划分数据域

交付物：《业务过程与数据域对应表》
公司业务线很长，且涵盖多个部门的时候，可以把业务过程按照部门划分数据域，每个数据域之间数据相对独立。例如营销域、交易域、应用域。每个业务过程唯一对应一个数据域。

定义维度

构建一致性维表

交付物《数仓维度属性文档》
维度是维度建模的灵魂。对于维度的理解决定了最终数仓质量的好坏。维度是业务过程的环境描述。维度是我们分析业务过程的角度。每个维度都是一个类属。维度表中的每行数据是一个个该类属的实体。
**维度的确定往往是在不同里找相同的过程。**不同的订单，卖家可能是一样的，商品可能是一样的，买家也可能是一样的。那么卖家、商品、买家就是维度。标准的维度表和事实表应该是一对多的关系。
维度属性是描述维度的信息。例如卖家的行业、名称、信用度。
在分析过程中，往往维度是group by的字段，维度属性是where的字段。
一致性维度是指不同的业务线中该维度的含义是相同的。例如时间维度，地区维度。用户维度或者租户维度的含义可能相同也可能不同，这也是我们前期需要明确的问题之一。一致性维度保证了不同数据域进行交叉查询时不出现错误数据。

3、构建总线矩阵

交付物《数仓总线矩阵》
形如：

总线矩阵表达的是维度与各业务过程的对应关系。方便将来不同业务过程的交叉查询。

4、明确分析指标

交付物《指标命名规范》《指标定义文档》《数据分析指标口径》
指标的生成需要一套完整的逻辑模型。因为运营人员大概率不懂技术，技术人员对业务的理解也有限，他们想看的数据和我们认知里的这种数据或许并不相同。不统一定义就很容易出现口径不一致的情况。

5、规范定义

交付物：《数仓建设名词口径》《数仓建设命名规范》《数仓生命周期管理规范》
此阶段对以后数仓建设和表开发制定规范。不同的技术架构必然有不同的规范。我们采用阿里云的框架，所以大部分规范都参考了阿里云官方文档。开发过程中一定会遇到很多细节上的问题，所以开发规范是动态完善的。搭建数仓的原则之一就是迭代开发，不要妄想一步到位。

6、明细模型设计

事实表

交付物《事实表数据字典》《各业务过程数据模型》
之前已经将业务数据表按照业务过程分好了类。现在需要设计每个业务过程对应的事实表的表结构。事实表通常由主键、维度、度量组成。维度是外键，度量是有统计价值的数值型维度属性。理想的事实表是没有维度属性的，但现实情况是，经常会有字段无法归入任何一个维度。例如订单事实表中，订单状态、订单类型这类字段，只能归入“订单”维度中。然而订单并没有维度表，我们的做法是抽象出一张“订单杂项维度表”，相当于把订单也当做了一种维度，然后将这张表“维度退化”到订单事实表。杂项维度表只存在于逻辑数据模型，实际上表中的字段就存放在对应的事实表中。
我们从主事实表中挑选可能会分析到的字段，再根据依赖关系（也就是外键）确定涉及到的维度，最后将这些维度中分析频率高的维度属性冗余到事实表中。当然，确认“分析频率高的维度属性”也是只有实际开发中才能做到。也是需要优化迭代的一项。

维度表

交付物《维度表数据字典》
维度表的搭建与事实表大同小异。只是很多公司（包括我们公司）的业务数据库中并没有对应的维度表，需要我们从各种事务记录表中抽取字段作为维度属性。
常常会出现层级维度。例如地区维度，国家、省市区。例如商品，sku，类目。层级维度的处理方法有很多，我们采用了最简单的扁平化处理方案。将父维度的维度属性冗余到子维度中，因为我们的维表数据量很小，冗余也不会占用多少空间，同时还保持了星型模型。

7、汇总模型设计

构建公用汇总模型（DWS）

构建应用汇总模型（ADS）

8、代码开发

9、部署运维

三、技术细节

四、问题记录