一、ETL概述与数据仓库基础
大家好，我是老张。做数据这行十几年了，今天咱们聊聊ETL和数据仓库的入门知识。说实话，很多新人一上来就被各种概念搞晕了。别急，咱们一个一个来拆解。
1.1 什么是ETL？
ETL，全称是Extract-Transform-Load。说白了，就是从源系统把数据抽出来，洗一洗，再装到目标系统里。我习惯把它比作「做饭」——买菜（抽取）、洗菜切菜（转换）、上桌（加载）。
核心三步骤：
- Extract（抽取）：从业务数据库、日志文件、API接口等源头获取数据
- Transform（转换）：清洗、去重、格式转换、业务逻辑计算
- Load（加载）：将处理好的数据写入数据仓库或数据集市
我在项目中遇到过最头疼的事，就是源系统的数据质量太差。比如日期字段里混着「2023-01-01」和「2023/01/01」两种格式，还有空值、乱码。嗯，这时候ETL的转换环节就特别重要了。
1.2 数据仓库架构：星型 vs 雪花型
数据仓库的建模方式，最常见的就是星型和雪花型。你想想看，这俩名字其实挺形象的。
星型模型
中间一张事实表，周围一圈维度表。就像星星一样，中心发光，四周点缀。我个人的习惯是，业务查询场景简单、追求查询性能时，首选星型模型。
雪花型模型
维度表继续拆分成更细的维度表。比如「产品维度」拆成「产品表」和「类别表」。这样数据冗余更少，但查询时要多关联几张表。
我的建议： 刚开始做数仓，别纠结太多。80%的场景用星型就够了。雪花型虽然规范，但查询性能会下降。我曾经在一个项目中为了追求「完美范式」，把维度表拆了七八层，结果报表跑不动了……后来老老实实改回星型。
1.3 OLTP vs OLAP：两个世界的差异
这两个概念，我刚开始也傻傻分不清。后来一个老前辈跟我说：OLTP是「干活用的」，OLAP是「分析用的」。一下就通了。
| 对比维度 | OLTP（联机事务处理） | OLAP（联机分析处理） |
|---|---|---|
| 典型场景 | 订单录入、银行转账 | 销售报表、用户画像 |
| 数据特点 | 频繁增删改，数据量小 | 大量查询，数据量大 |
| 响应时间 | 毫秒级 | 秒级到分钟级 |
| 设计目标 | 高并发、高一致性 | 高吞吐、高分析能力 |
注意： 千万不要在OLTP库上直接跑复杂分析查询！我曾经见过一个团队，直接在业务库上跑月报统计，结果把生产库搞挂了，老板差点炸毛。OLTP和OLAP必须分开，这是铁律。
1.4 数据仓库分层：ODS、DWD、DWS、ADS
数据仓库为什么要分层？说白了，就是为了「各司其职」。我习惯把数仓比作一个工厂：原材料进来，经过粗加工、精加工、包装，最后出货。
ODS层（操作数据存储）
这是最原始的数据层。从业务系统抽取过来，基本不做转换。我建议这一层只做「镜像」，保留原始数据的样子。万一后面处理错了，还能回溯。
DWD层（明细数据层）
这一层开始做清洗和标准化。比如把日期格式统一、把空值处理掉、把编码翻译成中文。嗯，这里要注意，DWD层还是明细数据，不做聚合。
DWS层（汇总数据层）
按主题做轻度汇总。比如按天统计每个商品的销量、按小时统计网站PV/UV。我个人的习惯是，DWS层的数据要「够用但不过度」，太细了查询慢，太粗了不够用。
ADS层（应用数据层）
这是直接给报表、BI工具用的。按业务需求定制，比如「月度销售排行榜」、「用户留存分析」。这一层的数据，通常已经高度聚合了。
分层的好处：
- 数据血缘清晰，出了问题好排查
- 不同角色各取所需，开发人员用DWD，分析师用ADS
- 避免重复计算，DWS层算好的指标，多个报表都能复用
我记得刚入行时，有个项目没做分层，所有逻辑都写在一个脚本里。后来业务变了，改一个指标要翻半天代码，还经常改出bug。从那以后，我再也不敢不分层了。
好了，这一章的内容就到这里。ETL和数据仓库的基础概念，说白了就是这些。后面我们会一步步深入，把每个环节都讲透。
公众号:蓝海资料掘金营，微信deep3321