数据开发/数仓工程师上手指南(三)数仓构建流程

前言

此系列的上篇文章通过拆解电商业务数仓系统，通过数仓分层概念对整个业务进行拆解分层，那么本章节将沿着上一篇的数仓概念分层切割电商业务，去具体构建电商业务的数据仓库，我们将按照行业认可标准的流程去构建较为完整的数据仓库。

本系列文章会涉及较多SQL代码以及数据分析处理代码，以及配套的数据中台和数据仓库产品使用，如暂时还没有相对成熟的产品学习，推荐使用阿里巴巴成熟的DataWorks和Maxcompute。

数仓构建流程

一、业务调研

在进行数据仓库构建之前，首先需要确定数仓构建的目标与需求，进行全面的业务调研。需要了解真实的业务需求是什么，以及确定整个业务系统能解决什么问题。

充分的业务调研和需求分析是数据仓库建设的基石，直接决定数据仓库能否建设成功。用户可能分为数据分析、运营、维护部门，各个部门对数仓的需求不同，我们需要对不同部门分别进行调研，梳理出整体的业务数据框架。我们依旧以招标业务为例进行分析，通过访谈和观察，绘制招标业务的流程图。包括招标发布、投标接收、评标、定标、合同签订等主要环节：

关键步骤：

• 招标公告发布：了解发布渠道、内容和频率。
• 投标管理：记录投标的接收、分类和管理过程。
• 评标过程：详细了解评标的标准、流程和参与人员。
• 中标决策：记录中标决策的依据和流程。
• 合同管理：了解合同的签订和管理过程。

数据需求调研

确定数据需求：

• 识别各业务流程中的关键数据元素，如招标项目、投标公司、评标专家、评分标准等。
• 确定需要收集的原始数据和所需的历史数据。

数据字段：

• 招标项目：项目ID、项目名称、预算、发布时间、截止时间等。
• 投标公司：公司ID、公司名称、联系人、联系方式、投标文件等。
• 评标信息：评标专家、评分标准、评分结果等。
• 中标信息：中标公司、中标金额、中标通知等。

数据源识别

识别数据源：

• 确定数据的来源系统，如ERP系统、CRM系统、电子邮件系统、文件存储系统等。

数据获取：

• 确定如何从这些数据源中提取数据，是否需要接口开发、数据导入等。

KPI定义

定义关键绩效指标：

• 与业务用户和管理层讨论，确定需要在数据仓库中跟踪的KPI。

常见KPI：

• 招标项目数：总数、按月分布等。
• 投标公司数：总数、每项目投标公司数等。
• 中标率：按项目、按公司等。
• 平均投标时间：从公告发布到投标截止的时间。
• 评标时间：从投标截止到评标完成的时间。

二、需求分析

单纯根据业务调研建设的数据仓库可用性差。完成业务调研后，需要进一步收集数据使用者的需求，进而对需求进行深度的思考和分析。

需求分析的途径有两种：

• 根据与分析师、业务运营人员的沟通获知需求。
• 对报表系统中现有的报表进行研究分析。

编写需求文档：

• 将调研结果整理成详细的业务需求文档，包含业务流程图、数据需求、KPI、痛点分析等。

文档内容：

• 业务背景和目标
• 业务流程描述
• 数据需求和数据源
• 关键绩效指标
• 现有系统和数据源分析
• 业务痛点和改进需求

比如招标业务的需求可以为：

• 市场评估和供应商交付能力分析。
• 招标项目的品牌成效分析。
• 供应商的分层和财务结算管理。
• 招标流程的监控和优化。

三、分析业务过程

业务过程可以是单个业务事件，例如交易的支付、退款等；也可以是某个事件的状态，例如当前的账户余额等；还可以是一系列相关业务事件组成的业务流程。具体取决于您分析的是某些事件过去发生情况、当前状态，或是事件流转效率。

绘制业务流程图有助于清晰地了解每个环节的具体步骤和数据流动，涉及招标项目的所有阶段，从招标公告发布到合同签订和项目执行。

在明确用户的业务过程之后，可以根据需要进行分析决策的业务划分数据域。

四、划分数据域

通常，需要阅读各源系统的设计文档、数据字典和数据模型设计文档，研究逆向导出的物理数据模型。进而，可以进行跨源的主题域合并，跨源梳理出整个企业的数据域。

数据域是指面向业务分析，将业务过程或者维度进行抽象的集合。为保障整个体系的生命力，数据域需要抽象提炼，并长期维护更新。在划分数据域时，既能涵盖当前所有的业务需求，又能让新业务在进入时可以被包含进已有的数据域或扩展新的数据域。数据域的划分工作可以在业务调研之后进行，需要分析各个业务模块中有哪些业务活动。

根据业务功能和关键数据实体，将数据仓库划分为不同的数据域。每个数据域可以包含多个相关的数据表，这些表之间具有紧密的业务关系。

招标管理数据域

• 数据实体：招标项目、招标公告
• 描述：管理所有与招标过程相关的数据，包括项目定义、预算、时间表和公告发布。
• 示例表：
  • 招标项目表（Project）
  • 招标公告表（Announcement）

投标管理数据域

• 数据实体：投标、投标文件
• 描述：管理所有与投标过程相关的数据，包括投标文件的接收、记录和分类。
• 示例表：
  • 投标表（Bid）
  • 投标文件表（Bid_File）

评标管理数据域

• 数据实体：评标、评分标准、评标专家
• 描述：管理所有与评标过程相关的数据，包括评分标准、评标记录和专家信息。
• 示例表：
  • 评标表（Evaluation）
  • 评分标准表（Scoring_Standard）
  • 评标专家表（Expert）

合同管理数据域

• 数据实体：合同、合同条款
• 描述：管理所有与合同签订和管理相关的数据，包括合同条款和签订记录。
• 示例表：
  • 合同表（Contract）
  • 合同条款表（Contract_Term）

以上等，每个数据域需要设计详细的数据模型，包括事实表和维度表。

招标管理数据域：

• 招标项目表（Project）：
  • Project_ID（主键）
  • Project_Name
  • Budget
  • Start_Date
  • End_Date
• 招标公告表（Announcement）：
  • Announcement_ID（主键）
  • Project_ID（外键）
  • Announcement_Content
  • Publish_Date

五、数据域之间的关系

确定各数据域之间的关系，并设计相应的外键约束。这有助于确保数据的一致性和完整性。例如，“投标管理”数据域中的投标表（Bid）需要与“招标管理”数据域中的招标项目表（Project）相关联：

CREATE TABLE bid(
	bid_id INT PRIMARY KEY,
    project_ID INT,
    supplier_ID INT,
    bid_amount DECIMAL(10,2),
    bid_data DATE,
    FOREING KEY (project_ID) REFERENCES Project(project_ID),
    FOREING KEY (supplier_ID) REFERENCES Supplier(supplier_ID)
);

六、定义维度与构建总线矩阵

定义维度和构建总线矩阵（Bus Matrix）是数据仓库设计中非常重要的步骤，特别是在多个数据域之间保持一致和统一。

1.定义维度

维度是描述业务过程上下文的信息，帮助我们理解和分析事实数据，可以先构建通用维度，再构建详细定义维度。

1.1确定通用维度

首先，确定所有数据域中通用的维度，这些维度将在不同的数据域中被重复使用。例如，在招标业务中，可能的通用维度包括：

• 时间维度（Time）
• 项目维度（Project）
• 供应商维度（Supplier）
• 地理维度（Location）

1.2详细定义维度表

为每个维度定义详细的属性，并创建相应的维度表，比如时间维度表我们可以设计为：

时间维度表(Dim_Time):

CREATE TABLE Dim_Time(
	Time_ID INT PRIMARY KEY,
    Year INT,
    Quarter INT,
    Month INT,
    Day INT,
    Weekday VARCHAR(10)
)

项目维度(Dim_Project):

CREATE TABLE Dim_Project(
	Project_ID INT PRIMARY KEY,
	Project_Name VARCHAR(100),
	Budget DECIMAL(10,2),
    Start_Date DATE,
    End_Date DATE
);

2.构建总线矩阵(Bus Matrix)

总线矩阵（Bus Matrix）是一个二维表格，列出了数据仓库中所有的事实表和共享维度表。它有助于确保在不同的数据域和业务过程之间的一致性和统一性。

2.1 列出所有的事实表

首先，列出所有的数据域中的事实表。在招标业务中，可能的事实表包括：

• 投标事实表（Fact_Bid）
• 评标事实表（Fact_Evaluation）
• 合同事实表（Fact_Contract）
• 项目进度事实表（Fact_Project_Progress）
• 结算事实表（Fact_Settlement）

2.2 列出所有的共享维度

列出所有的数据域中共享的维度，例如：

• 时间维度（Dim_Time）
• 项目维度（Dim_Project）
• 供应商维度（Dim_Supplier）
• 地理维度（Dim_Location）

2.3 填写总线矩阵

构建一个表格，将事实表和维度表对应起来。总线矩阵的示例如下：

投标事实表（Fact_Bid）示例：

CREATE TABLE Fact_Bid (
    Bid_ID INT PRIMARY KEY,
    Project_ID INT,
    Supplier_ID INT,
    Bid_Amount DECIMAL(10, 2),
    Bid_Date INT,
    Evaluation_Result VARCHAR(50),
    FOREIGN KEY (Project_ID) REFERENCES Dim_Project(Project_ID),
    FOREIGN KEY (Supplier_ID) REFERENCES Dim_Supplier(Supplier_ID),
    FOREIGN KEY (Bid_Date) REFERENCES Dim_Time(Time_ID)
);

评标事实表（Fact_Evaluation）：

CREATE TABLE Fact_Evaluation (
    Evaluation_ID INT PRIMARY KEY,
    Bid_ID INT,
    Expert_ID INT,
    Score DECIMAL(5, 2),
    Evaluation_Date INT,
    FOREIGN KEY (Bid_ID) REFERENCES Fact_Bid(Bid_ID),
    FOREIGN KEY (Expert_ID) REFERENCES Dim_Expert(Expert_ID),
    FOREIGN KEY (Evaluation_Date) REFERENCES Dim_Time(Time_ID)
);

3.验证和优化

3.1明确统计指标

原子指标是明确的统计口径、计算逻辑： 原子指标=业务过程+度量。派生指标即常见的统计指标：派生指标=时间周期+修饰词+原子指标。原子指标的创建需要在业务过程定义后方才可创建。派生指标的创建一般需要在了解具体报表需求之后展开，在新建派生指标前必须新建好原子指标。 注意事项如下：

• 原子指标、修饰类型及修饰词，直接归属在业务过程下，其中修饰词继承修饰类型的数据域。
• 派生指标可以选择多个修饰词，由具体的派生指标语义决定。例如，支付金额为原子指标，则客单价（支付金额除以买家数）为派生指标。
• 派生指标唯一归属一个原子指标，继承原子指标的数据域，与修饰词的数据域无关。

根据之前的分析，我们确认业务过程为：确认收货（交易成功），而度量为商品的销售金额。因此根据业务需求，我们可以定义出原子指标：商品成功交易金额。

派生指标为：

• 最近一天全省厨具类目各商品销售总额
• 最近一天全省厨具类目人均消费额（消费总额除以人数）

最近一天全省厨具类目各商品销售总额进行降序排序后取前10名的名称，即可得到该类目Top10销售额商品名称。那么下一章我们再开始结合数据建模工具来详细开展下一步明细模型设计，来具体通过直观的数据建模工具来构建DWD,DIM和DWS。