数据开发/数仓工程师上手指南(一)数仓概念架构

前言

笔者毕业最开始从事的就是大数据开发和数据仓库建设工作，途中曾担任过人工智能工程师和计算机视觉工程师，没想到最后兜兜转转还是回到了最原本的工作数据开发工程师。但很少有写关于本职工作的技术内容输出。

之前笔者撰文内容大部分都是关于算法建模这块，大部分算是赋能计算这块内容，大家也多很关注这块，但是随着大环境改变，企业更注重多领域均衡发展，也就是比原来工作环境要求人才多元化，需要掌握多维的知识而不是深耕单一领域的。说白了就是更卷了，因此一些离不开数据体系搭建的知识可以说是必须要掌握的。就比如说公司的数仓建设和数仓体系架构的基本知识。因此借由此机会给大家好好分享企业级数仓建设以及最前沿的数据分析技术。

笔者的人工智能应用技术和实践项目还是会一直更新的，不过速度暂时没有往常那么快，谢谢大家的支持！

一、数据仓库概念

首先我们可以先在脑子里面建立一个中转站的概念，好比你开车上路，是想从国道开往高速，肯定高速开车速度要快而且体验感要好。那么你就把数据仓库认为是一个国道汇总到高速的一个高速中转站，负责收集这些不同地方来源的数据，统一归纳整理好再放到高速上去用，达到高效数据中转的效果。

数据仓库的目的就是为了统筹集中所有可以使用的数据，构建面向分析的集成数据环境，通过最终数据分析结果为企业提供决策导向支持。对于整个数据仓库而言，它不需要生产数据，也不用消费数据，而是通过数仓的一系列处理运算操作，将结果提供给外部。

1.数据仓库架构

我们再以整体架构为例来理解：

1.1数据采集层

首先我们需要存储对应业务相关的数据，这块数据来源有很多途径，不仅只是我上图所画的那些途径，通过外部来源数据进行整合。因为数据来源不同，非一致性质格式数据，可能有的为日志格式数据或者是日志格式数据和JSON格式数据，所以我们需要通过ETL进行数据的转换处理，统一格式放入我们的数据仓库中。

1.2.数据加工层

数据加工层为数据仓库核心功能，需要将汇总的数据全部处理成我们可以进行分析的数据，其中我们还不希望损失原始数据信息，所以我们要尽可能建立很多规则表格来保存我们收集到的数据信息，数据就是资产。

在这个理念下我们就衍生出了很多个数据仓库分层理念，一般我们将数据仓库分为三层，自下而上，逐层提取精炼。从提取开始分别为:数据引入层(ODS，Operation Data Store)，数据公共层(CDM，Common Data Model)和数据应用层(ADS，Application Data Service)。

我们还是根据数据入库流程架构来分析：

1.2.1数据引入层ODS（Operational Data Store）

一般来说ODS可以说得上是作为一张原始数据表的映射表，存放未经过处理的原始数据至数据仓库系统，结构上与原始数据信息保持一致，是数据仓库的数据准备缓存区，还可以到保存历史数据记录的作用，也可增加字段。存储的历史数据是只读的。

在离线数仓中，业务数据定期通过ETL流程导入到ODS中，导入方式有全量、增量两种

• 全量导入：数据第一次导入时，选择此种方式
• 增量导入：数据非第一次导入，每次只需要导入新增、更改的数据，建议使用外连接&全覆盖方式

1.2.2数据公共层CDM（Common Data Model）

数据公共层CDM（Common Data Model，又称通用数据模型层），包括DIM维度表、DWD和DWS，由ODS层数据加工而成。主要完成数据加工与整合，建立一致性的维度，构建可复用的面向分析和统计的明细事实表，以及汇总公共粒度的指标。

其中这CDM中构建三层DIM维度表，DWD和DWS的过程为：

首先我们最后都是要为ADS层服务的，那么首先我们要提取出业务以及分析主题两个抽象事物，其中需要统一口径。

1.2.2.1 公共维度汇总层DIM（Dimension）

公共维度汇总层（DIM）主要由维度表（维表）构成。维度是逻辑概念，是衡量和观察业务的角度。维表是根据维度及其属性将数据平台上构建的物理化的表，采用宽表设计的原则。因此，公共维度汇总层（DIM）首先需要定义维度，建立整个企业的一致性维度。降低数据计算口径和算法不统一风险。

如果我们需要对一个招标业务进行构建DIM公共维度汇总层构建维度表，首先，详细了解招标业务的需求，确定需要分析和查询的主要维度。对于招标业务，可能需要考虑的维度有：

• 招标项目
• 投标公司
• 招标类别
• 地理区域
• 时间维度（年、季度、月、日）
• 项目负责人
• 投标状态

这里暂时不展开，在往后详细数据仓库数据建模流程中会详细讲解建模过程。

1.2.2.2 明细粒度事实层DWD（Data Warehouse Detail）

在数据仓库架构中，DWD（明细数据层）是非常关键的一环，它将ODS层中的原始数据进行清洗和转换，提供细粒度的明细数据，支持进一步的数据分析和应用。以业务过程作为建模驱动，基于每个具体的业务过程特点，构建最细粒度的明细层事实表。可以结合企业的数据使用特点，将明细事实表的某些重要维度属性字段做适当冗余，即宽表化处理。明细粒度事实层的表通常也被称为逻辑事实表。

倘若我们还是以招标业务来进行数据建模，明细事实表应包含所有需要分析的详细数据。

明细事实表结构：

• DWD_招标明细：
• 招标项目ID
• 招标项目名称
• 招标类别ID
• 地区ID
• 项目负责人ID
• 投标公司ID
• 投标金额
• 投标日期
• 投标状态（如投标、未中标、中标等）
• 投标次数
• 其他相关字段（如评审分数、评审意见等）

1.2.2.3公共汇总粒度事实层DWS（Data Warehouse Summary）

构建公共汇总粒度事实层（DWS）是数据仓库中的一个重要步骤，目的是将详细的数据进行汇总，提供更高效的查询和分析支持。以业务过程作为建模驱动。以分析的主题对象作为建模驱动，基于上层的应用和产品的指标需求，构建公共粒度的汇总指标事实表，以宽表化手段物理化模型。构建命名规范、口径一致的统计指标，为上层提供公共指标，建立汇总宽表、明细事实表。

公共汇总粒度事实层的表通常也被称为汇总逻辑表，用于存放派生指标数据。

首先，确定需要进行汇总的数据以及汇总的维度和指标。对于招标业务，可能需要以下汇总：

• 按时间汇总（年、季度、月）
• 按地区汇总
• 按投标公司汇总
• 按招标类别汇总
• 按项目负责人汇总

设计汇总粒度的事实表结构，选择合适的度量值（Measures）和维度（Dimensions）。例如：

• 汇总度量值：
• 总投标金额
• 中标金额
• 投标次数
• 中标次数
• 维度：
• 时间维度
• 地区维度
• 投标公司维度
• 招标类别维度
• 项目负责人维度

根据确定的维度和度量值，创建汇总粒度的事实表：

-- 创建DWS汇总事实表
CREATE TABLE DWS_招标汇总 (
    时间ID INT,
    地区ID INT,
    投标公司ID INT,
    招标类别ID INT,
    项目负责人ID INT,
    总投标金额 DECIMAL(18, 2),
    中标金额 DECIMAL(18, 2),
    投标次数 INT,
    中标次数 INT,
    PRIMARY KEY (时间ID, 地区ID, 投标公司ID, 招标类别ID, 项目负责人ID)
);

通过ETL过程将DWD层的明细数据汇总后加载到DWS层。可以使用SQL聚合函数来实现数据的汇总。

-- 插入汇总数据到DWS_招标汇总表
INSERT INTO DWS_招标汇总 (时间ID, 地区ID, 投标公司ID, 招标类别ID, 项目负责人ID, 总投标金额, 中标金额, 投标次数, 中标次数)
SELECT 
    时间ID,
    地区ID,
    投标��司ID,
    招标类别ID,
    项目负责人ID,
    SUM(投标金额) AS 总投标金额,
    SUM(CASE WHEN 投标状态 = '中标' THEN 投标金额 ELSE 0 END) AS 中标金额,
    COUNT(*) AS 投标次数,
    SUM(CASE WHEN 投标状态 = '中标' THEN 1 ELSE 0 END) AS 中标次数
FROM 
    FACT_招标
GROUP BY 
    时间ID,
    地区ID,
    投标公司ID,
    招标类别ID,
    项目负责人ID;

以上便是整个数仓开发架构核心理念。

3.数据应用层

数据应用层一般是存放数据产品个性化的统计指标数据。根据CDM与ODS层加工生成。主要是提供给数据产品和数据分析使用的数据，一般会存放在ES、PostgreSql、Redis等系统中供线上系统使用，也可能会存在Hive或者Druid中供数据分析和数据挖掘使用。

一般来说就是数据报表BI了：

需要注意的是数据仓库擅长数据分析，如果直接开放业务查询接口，会加重其负担。