1. 数据工程概述

各位同学，咱们今天正式开课。

聊数据工程，绕不开一个老话题——数据到底怎么从源头搬到目标？
我见过太多团队，一上来就纠结用ETL还是ELT，结果连最基础的概念都没对齐。
说白了，地基没打牢，楼盖得再高也悬。

这一章，咱们先把地基夯实。

数据仓库基础概念

先问个问题：你手头有几十张业务表，每天几千万条记录，老板要看「上季度华东区毛利率」——你怎么查？
直接查业务库？别闹，一个慢查询就能把生产库拖死。

这就是数据仓库存在的理由。

数据仓库，说白了就是一个专门存「分析用数据」的地方。
它跟业务库最大的区别在于：

• 面向主题：按「销售」「库存」「客户」这种分析主题组织，不是按「订单表」「商品表」这种业务流程组织。
• 集成性：来自不同系统的数据，在这里统一编码、统一单位、统一口径。
• 非易失性：数据一旦入库，基本只读不删不改——你想想，历史销售数据要是能随便改，审计还不炸锅？
• 随时间变化：保留历史快照，能回答「上个月和这个月比怎么样」这类问题。

我记得刚入行时，有个老前辈跟我说过一句话：「业务库是拿来用的，仓库是拿来分析的。」
这么多年下来，我越来越觉得这句话值千金。

ETL与ELT的定义

好，数据有了，仓库有了，怎么把数据弄进去？
这就引出了两个经典架构：ETL 和 ELT。

名字就差一个字母，但背后的设计哲学天差地别。

ETL：先转换，再加载

Extract（抽取）→ Transform（转换）→ Load（加载）

流程很简单：
从源系统把数据抽出来，在中间层（通常是专门的ETL服务器）做完清洗、合并、聚合，最后把处理好的数据加载进数据仓库。

我早期做的一个零售项目，用的就是经典ETL。
每天晚上，从POS系统、ERP系统、CRM系统分别抽数据，在中间服务器上做字段映射、去重、计算毛利率，凌晨2点准时灌入仓库。
那时候硬件贵，仓库算力也弱，只能这么干。

-- 一个典型的ETL转换步骤（伪代码）
-- 1. 抽取
SELECT * FROM source_orders WHERE order_date = '2024-01-01';

-- 2. 转换（在ETL服务器上执行）
-- 清洗空值、统一货币单位、计算折扣后金额

-- 3. 加载
INSERT INTO dw.fact_orders (order_id, amount, currency, ...)
VALUES (...);

ELT：先加载，再转换

Extract（抽取）→ Load（加载）→ Transform（转换）

ELT把顺序调了个个儿。
先把原始数据一股脑儿倒进数据仓库，利用仓库自身的计算能力（比如Snowflake、BigQuery、Redshift的分布式算力）来做转换。

你想想看，现在云数据仓库的算力多强？
与其在中间层折腾，不如让仓库自己干。

-- ELT流程：先加载原始数据
COPY INTO raw_orders
FROM 's3://source-data/orders/2024/01/01/'
FILE_FORMAT = (TYPE = 'CSV');

-- 再在仓库内转换
CREATE TABLE dw.fact_orders AS
SELECT
  order_id,
  amount * exchange_rate AS amount_usd,
  ...
FROM raw_orders r
JOIN ref.exchange_rates e ON r.currency = e.currency;

ETL vs ELT：核心差异对比

光说定义不够直观，咱们直接上表。

对比维度	ETL	ELT
转换位置	中间层（ETL服务器）	目标端（数据仓库内）
数据存储	加载前已清洗，仓库只存最终数据	仓库同时存原始数据和转换后数据
算力依赖	依赖ETL服务器	依赖数据仓库
灵活性	转换逻辑固定，改起来麻烦	原始数据在手，随时可以重新转换
数据量	适合GB~TB级	适合TB~PB级
典型工具	Informatica、Talend、DataStage	dbt、Snowflake、BigQuery

这张表我建议你存一下。
以后跟团队讨论架构选型，直接拿出来对，省得扯皮。

为什么需要数据集成？

聊完概念，咱们回到一个更根本的问题——为什么非要搞数据集成？

我直接说一个真实场景吧。
之前帮一家电商公司做数据治理，发现他们的「订单金额」在三个系统里对不上：
订单系统存的是「商品总价」，财务系统存的是「实付金额」，BI报表里又算的是「含税金额」。
三个数字，三个口径，老板开会问「这个月到底卖了多少钱」，没人能说清楚。

这就是数据孤岛。

数据集成要解决的，就是这个问题：

• 消除孤岛：把散落在各个系统里的数据打通。
• 统一口径：同一个指标，同一个算法，同一个结果。
• 提升时效：从T+1到T+0，甚至实时。
• 降低成本：别让分析师花80%的时间在「找数据、对数据」上。

本章知识体系总览

下面这张图，把咱们这一章的核心逻辑串起来了。
你可以把它当作整个课程的地图——后面每一章，都会在这张图上展开。

从这张图可以看得很清楚：
ETL和ELT的起点一样——都是数据源，都是先抽取。
但到了中间环节，一个向左走（先转换），一个向右走（先加载）。
最终都汇入数据仓库，但路径不同，带来的灵活性、性能、维护成本也完全不同。

嗯，这一章的内容就到这儿。
概念清楚了，后面咱们再深入每个环节的实战细节。