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

数据库设计用于支持日常业务操作和事务处理。数据结构高度规范化，注重数据的一致性和实时性。优化事务处理性能，处理频繁的读写操作。数据仓库设计用于支持数据分析和决策支持系统。数据结构非规范化，存储大量的历史数据。优化查询性能，支持复杂的多维分析和大规模数据处理。数据库(Database)数据仓库(Data Warehouse)面向事务分析数据类型细节、业务综合、清洗过的数据数据特点当前的、最新的历史的

fanstuck

2484人浏览 · 2024-07-24 14:31:07

fanstuck · 2024-07-24 14:31:07 发布

前言

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

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

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

一、数据仓库概念

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

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

1.数据仓库架构

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

ODS（Operational Data Store）：

英文全称：Operational Data Store
含义：操作型数据存储层。用于存储从业务系统中抽取的原始数据，数据一般未经处理或仅进行了简单的清洗，保持其原始状态。

DWD（Data Warehouse Detail）：

英文全称：Data Warehouse Detail
含义：明细数据层。将ODS层的原始数据进行清洗、转换，存储详细的、经处理的数据，用于支持详细的业务分析需求。

DWS（Data Warehouse Summary）：

英文全称：Data Warehouse Summary
含义：汇总数据层。对DWD层的数据进行聚合和汇总，生成更高层次的统计数据和指标，便于快速查询和分析。

DIM（Dimension）：

英文全称：Dimension
含义：维度数据层。存储用于数据分析的维度数据，这些维度数据描述了事实表中的度量数据的上下文，如时间、地点、产品、客户等。

ADS（Application Data Store）：

英文全称：Application Data Store
含义：应用数据层。存储为特定应用或分析需求准备的汇总数据，支持特定的业务应用、报表和分析需求。

在这里插入图片描述

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了：
在这里插入图片描述 数据仓库擅长数据分析，如果直接开放业务查询接口，会加重其负担。

2.数据仓库VS数据库

谈到二者的区别，那我们就要了解二者设计的目的，是要解决什么需求。先从设计目的开始分析：

2.1设计目的

数据库（Database）：

设计目的：主要用于在线事务处理（OLTP），支持日常业务操作和事务处理。
功能：处理频繁的数据插入、更新和删除操作，确保数据的实时性和一致性。
使用场景：用于支持业务应用程序，如电子商务网站、银行交易系统、企业资源规划（ERP）系统等。

数据仓库（Data Warehouse）：

设计目的：主要用于在线分析处理（OLAP），支持复杂的查询和数据分析。
功能：聚合、清洗和转换大量的历史数据，支持决策支持系统（DSS）和商业智能（BI）应用。
使用场景：用于支持数据分析和商业报告，如市场分析、销售趋势分析、财务报表分析等。

2.2数据结构和存储

数据库：

数据结构：通常是高度规范化的（第三范式），以减少数据冗余和提高数据一致性。
存储方式：存储当前的操作数据，数据量相对较小，数据频繁更新。
示例：客户信息表、订单表、库存表等。

数据仓库：

数据结构：通常是非规范化的（如星型或雪花型模式），以提高查询性能和分析效率。
存储方式：存储大量的历史数据，数据量庞大，数据更新频率较低。
示例：销售事实表、客户维度表、时间维度表等。

2.3.性能优化

数据库：

优化目标：优化事务处理性能，确保快速的读写操作。
技术：使用索引、事务处理、锁机制等技术来保证数据一致性和操作性能。

数据仓库：

优化目标：优化查询性能，支持复杂的多维分析和大规模数据处理。
技术：使用分区、聚合索引、物化视图等技术来提高查询速度。

2.4.数据处理

数据库：

数据处理：处理实时数据，支持并发的读写操作。
数据加载：主要通过应用程序直接插入或更新数据。

数据仓库：

数据处理：处理批量数据，数据从多个源系统抽取、转换后加载（ETL）。
数据加载：通常通过ETL流程进行批量数据加载，数据加载过程可能在非高峰期进行。

2.5. 用户与操作

数据库：

用户：主要是应用程序和终端用户，进行日常的业务操作。
操作类型：CRUD操作（创建、读取、更新、删除），注重事务的原子性和一致性。

数据仓库：

用户：主要是数据分析师、数据科学家、商业用户，进行数据分析和报表生成。
操作类型：复杂的查询和分析操作，注重数据的整合和历史数据分析。

2.6.数据集成

数据库：

数据集成：通常处理单一业务领域的数据，集成度较低。
数据源：主要来自内部业务系统。

数据仓库：

数据集成：处理多个业务领域的数据，集成度较高，跨多个系统和数据源。
数据源：来自多个异构数据源，包括内部业务系统、外部数据源、日志数据等。

总结

数据库：

设计用于支持日常业务操作和事务处理。
数据结构高度规范化，注重数据的一致性和实时性。
优化事务处理性能，处理频繁的读写操作。

数据仓库：

设计用于支持数据分析和决策支持系统。
数据结构非规范化，存储大量的历史数据。
优化查询性能，支持复杂的多维分析和大规模数据处理。

	数据库(Database)	数据仓库(Data Warehouse)
面向	事务	分析
数据类型	细节、业务	综合、清洗过的数据
数据特点	当前的、最新的	历史的、跨时间维护
目的	日常操作	长期信息需求、决策支持
设计模型	基于ER模型、面向应用事务	星型/雪花模型，面向业务决策
操作	读/写	大多为读
数据规模	GB到TB	>=TB