数据仓库 on My Learning Notes

【四】HiveSQL 语法大全

Sun, 17 May 2026 22:37:02 +0800

一、对 Hive 数据库（Database / Schema）的操作

在 Hive 里，Database 和 Schema 是同义词，本质是 HDFS 上的一个目录（默认在 /user/hive/warehouse/<db_name>.db），用于隔离表的命名空间。

1. 创建数据库

1
2
3
4


CREATE DATABASE [IF NOT EXISTS] db_name
[COMMENT '数据库描述']
[LOCATION 'hdfs_path'] -- 自定义 HDFS 存储路径
[WITH DBPROPERTIES ('key1'='value1', ...)]; -- 附加元数据

示例：

1
2
3
4


CREATE DATABASE IF NOT EXISTS tcec_dw
COMMENT 'TCEC 数据仓库'
LOCATION '/warehouse/tcec_dw.db'
WITH DBPROPERTIES ('owner'='liuyuhang', 'created'='2026-05-17');

显示更多行

📌 要点：不指定 LOCATION 时，默认路径为 hive.metastore.warehouse.dir 配置项 + db_name.db。

2. 查看数据库

操作	语法	说明
列出所有库	`SHOW DATABASES;`	类似 MySQL 的 `SHOW DATABASES`
模糊匹配	`SHOW DATABASES LIKE 'tcec*';`	支持通配符
查看库详情	`DESC DATABASE db_name;`	显示路径、owner
查看完整信息	`DESC DATABASE EXTENDED db_name;`	额外显示 DBPROPERTIES
查看当前库	`SELECT current_database();`	当前会话所在库

3. 切换数据库

1

USE db_name;

4. 修改数据库

Hive 数据库的元数据大部分不可修改（如名字、位置），只能改属性和 owner：

1
2
3
4
5


ALTER DATABASE db_name SET DBPROPERTIES ('edited-by'='liu', 'createtime'='20260515');

ALTER DATABASE db_name SET OWNER USER liuyuhang;

ALTER DATABASE db_name SET LOCATION 'hdfs://new_path'; -- Hive 2.2.1+ 支持

5. 删除数据库

1

DROP DATABASE [IF EXISTS] db_name [RESTRICT | CASCADE];

模式	行为
`RESTRICT`（默认）	库里有表则报错，必须先清空
`CASCADE`	级联删除库下所有表（⚠️ 生产慎用）

1

DROP DATABASE IF EXISTS tcec_dw CASCADE;

二、对数据表（Table）的操作

Hive 表分为：内部表（Managed Table）、外部表（External Table）、分区表（Partitioned）、分桶表（Bucketed）、临时表（Temporary）。

1. 创建表

1.1 完整建表语法

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23


CREATE [TEMPORARY] [EXTERNAL] TABLE [IF NOT EXISTS] [db_name.]table_name
( col_name data_type [COMMENT '列注释'], ... )
[COMMENT '表注释']

[PARTITIONED BY (col_name data_type, ...)] -- 分区

[CLUSTERED BY (col_name, ...)
[SORTED BY (col_name [ASC|DESC], ...)]

INTO num_buckets BUCKETS] -- 分桶

[ROW FORMAT DELIMITED -- 指定分隔符
FIELDS TERMINATED BY ',' 

COLLECTION ITEMS TERMINATED BY '|'
MAP KEYS TERMINATED BY ':'
LINES TERMINATED BY '\n'] -- 行格式

[STORED AS TEXTFILE | ORC | PARQUET | SEQUENCEFILE | AVRO] -- 存储格式

[LOCATION 'hdfs_path'] -- 数据位置

[TBLPROPERTIES ('key'='value', ...)]; -- 表属性

1.2 内部表 vs 外部表

维度	内部表（Managed）	外部表（External）
关键字	`CREATE TABLE`	`CREATE EXTERNAL TABLE`
数据归属	Hive 管理数据生命周期	Hive 仅管理元数据
`DROP TABLE` 影响	同时删除元数据 + HDFS 数据	只删元数据，HDFS 数据保留
典型场景	中间结果、临时数仓表	ODS 层原始数据、共享数据

内部表

1
2
3
4
5
6
7


CREATE TABLE dws_user_order (
user_id BIGINT COMMENT '用户ID',
order_cnt INT,
total_amt DECIMAL(18,2)
)
STORED AS ORC
TBLPROPERTIES ('orc.compress'='SNAPPY');

外部表（指向已存在的 HDFS 数据）

1
2
3
4
5
6
7


CREATE EXTERNAL TABLE ods_user_log (
user_id BIGINT,
action STRING,
ts STRING
)
ROW FORMAT DELIMITED FIELDS TERMINATED BY '\t'
LOCATION '/data/raw/user_log/';

1.3 分区表

1
2
3
4
5
6
7


CREATE TABLE dwd_order (
order_id BIGINT,
user_id BIGINT,
amount DECIMAL(18,2)
)
PARTITIONED BY (dt STRING, region STRING) -- 二级分区
STORED AS PARQUET;

在HDFS上，分区会体现为目录结构：

1
2
3
4
5
6


/user/hive/warehouse/dwd_order/
├── dt=2024-05-17/
│ ├── region=Chengdu/
│ │ └── 000000_0 (Parquet文件)
│ ├── region=Beijing/
│ └── region=Shanghai/

📌 分区字段不出现在普通列中，它们的值是通过目录名体现的，本质是 HDFS 上的子目录：/dt=2026-05-17/region=cn/。

错误案例：

1
2
3
4
5
6


-- 错误示例：CTAS缺少分区字段
CREATE TABLE employee_partitioned
PARTITIONED BY (dept STRING, year INT)
AS
SELECT id, name, salary -- 只有3个字段，但表需要5个字段（3个普通+2个分区）
FROM source_table;

报错信息（Hive 3.x）：FAILED: SemanticException [Error 10044]: Line 1:18 Insert to partition columns requires all partition columns to be specified in the SELECT expression. Specified: id,name,salary; Missing: dept,year

原因：分区字段的值必须来自查询结果。Hive不知道如何为每条记录分配 dept='?'和 year=?

加载数据到分区

1
2
3


LOAD DATA LOCAL INPATH '/path/to/data_china_0517.csv'
INTO TABLE dwd_order s
PARTITION (dt='2024-05-17', region='2024-05-17China');

查询分区表

查询时，在WHERE中使用分区字段作为条件，才能触发分区裁剪。

1
2
3


-- 高效查询：只扫描‘China’分区下的‘2024-05-17’子目录
SELECT * FROM dwd_order 
WHERE region='China' AND dt='2024-05-17';

查看分区

1

show partitions dwd_order;

添加分区

添加分区的字段必须之前在表中存在否则会报错

1
2
3
4


ALTER TABLE dwd_order ADD
PARTITION(dt='2024-05-17', region='Chengdu')
PARTITION(dt='2024-05-17', region='Beijing')
PARTITION(dt='2024-05-17', region='Shanghai');

删除分区

DROP PARTITION

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


-- 这将删除 dt='2024-05-17' 下的所有region分区
ALTER TABLE dwd_order DROP PARTITION(dt='2024-05-17');

-- 或者删除多个指定分区
ALTER TABLE dwd_order DROP PARTITION(dt='2024-05-17', region='Chengdu'), PARTITION(dt='2024-05-17', region='Beijing');


-- 删除所有以特定模式匹配的分区
ALTER TABLE dwd_order DROP PARTITION(dt='2024-05-*');
ALTER TABLE dwd_order DROP PARTITION(region LIKE 'Cheng%');

TRUNCATE PARTITION

1
2
3


-- TRUNCATE PARTITION: 只删除数据，保留分区结构
TRUNCATE TABLE dwd_order PARTITION(dt='2024-05-17');
-- 执行后，分区目录还存在，但里面的数据文件被清空

动态分区

动态分区 是指Hive在执行INSERT操作时，根据SELECT语句中某几列的值，自动决定数据应该写入哪个分区，而无需手动为每条数据指定分区值。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


-- 静态分区：需要明确指定分区值
INSERT INTO sales PARTITION (dt='2024-05-17', region='Chengdu')
SELECT order_id, amount FROM source_table WHERE dt='2024-05-17' AND region='Chengdu';

-- 动态分区：分区值从数据中自动提取
INSERT INTO sales PARTITION (dt, region)
SELECT order_id, amount, dt, region FROM source_table;

-- 常用模式：一级静态分区 + 二级动态分区
INSERT OVERWRITE TABLE user_behavior PARTITION (dt='2024-05-17', province)
SELECT 
 user_id,
 action,
 province -- 动态分区字段
FROM source_table
WHERE dt = '2024-05-17';
-- 结果：在 dt=2024-05-17 下，按province自动创建子分区

动态分区的核心配置参数

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


-- 1. 启用动态分区（必须）
SET hive.exec.dynamic.partition=true;

-- 2. 设置分区模式（重要！）
SET hive.exec.dynamic.partition.mode=nonstrict;
-- strict: 必须至少有一个静态分区（安全但繁琐）
-- nonstrict: 允许所有分区都是动态的（生产常用）

-- 3. 控制最大分区数（防止创建过多分区）
SET hive.exec.max.dynamic.partitions=10000; -- 总共允许的最大动态分区数
SET hive.exec.max.dynamic.partitions.pernode=1000; -- 每个Mapper/Reducer允许的最大分区数

-- 4. 控制文件数量
SET hive.exec.max.created.files=100000; -- 整个作业允许创建的最大文件数

-- 5. 错误处理
SET hive.error.on.empty.partition=false; -- 是否在动态分区插入产生空分区时报错

1.4 分桶表

分桶的本质是在数据写入时，通过计算指定字段的哈希值，将哈希值相同的分到同一个桶（值相同则一定在同一个桶，但同一个桶的值不一定相同），每个桶对应一个文件。这需要读取、计算哈希、排序、写入等多个步骤。

分桶可以提高JOIN 查询和抽样效率，详见 Hive分桶.md

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


-- 1. 开启分桶约束（老版本需要，新版本Hive默认开启）
SET hive.enforce.bucketing = true;
-- 2. 设置Reduce任务数等于桶数，确保能生成对应数量的文件
SET mapreduce.job.reduces = 32; -- 注意：这里应该设置为32，与INTO 32 BUCKETS对应

CREATE TABLE dwd_user (
 user_id BIGINT,
 name STRING
)
-- 3. 核心定义：此表根据user_id的哈希值，将数据分散到32个桶文件中
CLUSTERED BY (user_id)
-- 4. 在每个桶文件内部，数据按照user_id升序排列
SORTED BY (user_id)
-- 5. 总共创建32个桶
INTO 32 BUCKETS
-- 6. 数据以ORC列式存储格式保存，以获得最佳的压缩和查询性能
STORED AS ORC;

📌 分桶字段必须是表中已有列，根据 hash(col) % num_buckets 分配到不同文件。配合你之前学的 Bucket Map Join / SMB Join 来优化大表 JOIN。

hdfs dfs -put 和 LOAD DATA INPATH都无法加载数据到分桶表，需要使用INSERT OVERWRITE

hdfs dfs -put 的问题（纯文件移动）

1
2


# 这只是简单的文件复制，Hive完全无法控制
hdfs dfs -put /local/user.txt /user/hive/warehouse/dwd_user/

问题所在：

你上传的文件可能包含多个用户的混合数据
Hive不知道如何将文件内容分配到32个桶中
文件格式不匹配（ORC格式需要特殊的二进制编码）
没有桶的元数据信息（如索引、统计信息）

结果：Hive会把这个文件当成一个普通文件，分桶功能完全失效。

LOAD DATA 的问题（格式转换但无计算）

1
2


-- 这只会移动和转换数据格式，但不会计算分桶
LOAD DATA INPATH '/input/user.txt' INTO TABLE dwd_user;

LOAD DATA实际上做了什么：

将HDFS上的源文件移动到表目录
如果格式不同，会做简单转换
但不会执行MapReduce计算

为什么不行：

没有对user_id计算哈希值
没有按哈希值分配数据到不同桶
没有在每个桶内排序
没有生成ORC的复杂结构（索引、统计信息等）

INSERT OVERWRITE 为什么能行

1
2
3


-- 这才是正确的分桶表数据加载方式
INSERT OVERWRITE TABLE dwd_user
SELECT user_id, name FROM source_table;

这个过程发生了什么（简化版）：

1
2
3
4
5
6
7
8


-- 1. 启动MapReduce/Spark作业
-- 2. Map阶段：读取源数据
-- 3. 为每行计算哈希：hash(user_id) % 32 → 得到桶编号(0-31)
-- 4. Reduce阶段：32个Reducer各自处理分配到的数据
-- - 每个Reducer处理一个桶的数据
-- - 在Reducer内部对user_id排序
-- - 以ORC格式写入到对应桶文件
-- 5. 结果：生成32个有序的ORC文件

1.5 CTAS & LIKE 建表

CTAS（Create Table As Select）根据查询结果建表（含数据）

1
2
3


CREATE TABLE dws_top_user AS
SELECT user_id, SUM(amount) AS total
FROM dwd_order GROUP BY user_id;

LIKE：仅复制结构（不含数据）

1

CREATE TABLE dws_top_user_bak LIKE dws_top_user;

⚠️ CTAS 不能创建分区表/外部表，因为分区/外部属性需要显式声明。

2. 查看表

操作	语法
列出当前库所有表	`SHOW TABLES;`
模糊查询	`SHOW TABLES LIKE 'dwd_*';`
查看表结构	`DESC table_name;`
查看详细信息	`DESC FORMATTED table_name;` （生产高频：能看到存储路径、格式、压缩、行数等）
查看建表语句	`SHOW CREATE TABLE table_name;`
查看分区	`SHOW PARTITIONS table_name;`
查看分区（过滤）	`SHOW PARTITIONS table_name PARTITION(dt='2026-05-17');`

3. 修改表（ALTER TABLE）

3.1 表级别修改

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


-- 重命名
ALTER TABLE old_name RENAME TO new_name;

-- 修改表属性
ALTER TABLE t SET TBLPROPERTIES ('comment'='新描述');

-- 修改 SerDe
ALTER TABLE t SET SERDE 'org.apache.hadoop.hive.serde2.OpenCSVSerde';

-- 内外部表互转
ALTER TABLE t SET TBLPROPERTIES ('EXTERNAL'='TRUE'); -- 改外部表
ALTER TABLE t SET TBLPROPERTIES ('EXTERNAL'='FALSE'); -- 改内部表

3.2 列级别修改

1
2
3
4
5
6
7
8


-- 增加列
ALTER TABLE t ADD COLUMNS (email STRING COMMENT '邮箱');

-- 修改列（改名、改类型、调整位置）
ALTER TABLE t CHANGE COLUMN old_col new_col STRING [AFTER other_col | FIRST];

-- 替换全部列（保留表，覆盖列定义，⚠️慎用）
ALTER TABLE t REPLACE COLUMNS (id BIGINT, name STRING);

⚠️ Hive 不支持直接 DROP COLUMN，要删列必须用 REPLACE COLUMNS 把保留的列重列一遍。

3.3 分区级别修改

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


-- 添加分区（手动）
ALTER TABLE t ADD PARTITION (dt='2026-05-17', region='cn')
LOCATION '/data/t/dt=2026-05-17/region=cn';

-- 删除分区
ALTER TABLE t DROP IF EXISTS PARTITION (dt='2026-05-17');
-- 修改分区路径
ALTER TABLE t PARTITION (dt='2026-05-17') SET LOCATION 'hdfs://new_path';

-- 修复分区（HDFS 上有目录但元数据没注册时常用）
MSCK REPAIR TABLE t;

4. 删除/清空表

1
2
3
4
5


-- 删除表（内部表会删 HDFS 数据，外部表只删元数据）
DROP TABLE [IF EXISTS] table_name;

-- 清空表（保留结构，删数据；仅对内部表生效）
TRUNCATE TABLE table_name [PARTITION (dt='2026-05-17')];

如果HDFS开启了回收站，drop的数据是可以恢复的，表结构恢复不了，需要自己创建

TRUNCATE清空的表不进回收站，无法恢复（慎用）

5. 数据加载

分区中加载数据

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21


-- 从本地文件加载（复制）
LOAD DATA LOCAL INPATH '/home/liu/data.csv' INTO TABLE t;

-- 从 HDFS 加载（移动，原路径文件消失）
LOAD DATA INPATH '/tmp/data.csv' [OVERWRITE] INTO TABLE t PARTITION (dt='2026-05-17');

-- INSERT 查询写入
INSERT INTO TABLE t PARTITION (dt='2026-05-17') SELECT ... FROM src;
INSERT OVERWRITE TABLE t PARTITION (dt='2026-05-17') SELECT ... FROM src;

-- 创建表时加载查询结果数据
CREATE TABLE t AS SELECT ... FROM src;

-- 创建表时加载本地文件数据
CREATE EXTERNAL TABLE t (t_id, t_name)
ROW FORMAT DELIMITED FIELDS TERMINATED BY ',' LOCATION './teacher';

-- 根据已有表结构建表,并导入表数据
CREATE TABLE teacher2 like teacher;
EXPORT TABLE teacher TO '/export/teacher';
IMPORT TABLE teacher2 FROM '/export/teacher';

6. 数据导出

Hive本身不存储数据，它管理的是存储在HDFS（或对象存储）上数据的“元数据”。因此，数据导出本质是将数据文件从Hive表对应的位置复制或转换到其他位置。

导出方式主要分为三类：insert导出、Hadoop导出、Hive Shell 导出、Export导出。

insert导出

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18


-- 基本语法：导出整个表或查询结果（格式化导出）
INSERT OVERWRITE LOCAL DIRECTORY '/export/teacher'
ROW FORMAT DELIMITED
FIELDS TERMINATED BY ',' -- 指定字段分隔符，例如CSV格式
STORED AS TEXTFILE
SELECT * FROM teacher;

-- 导出指定查询结果到本地
INSERT OVERWRITE LOCAL DIRECTORY '/export/dept_sales'
SELECT dept_id, sum(salary) as total_salary
FROM employee
GROUP BY dept_id;

-- 导出指定查询结果到HDFS（没有LOCAL关键字）
INSERT OVERWRITE DIRECTORY '/export/dept_sales'
SELECT dept_id, sum(salary) as total_salary
FROM employee
GROUP BY dept_id;

Hadoop导出到本地

dfs -get /export/servers/exporthive/000000_0 /export/servers/exporthive/local.txt;

Hive Shell 导出

hive -f/-e 执行语句或脚本 > file

hive -e "select * from myhive.score;" > /export/servers/exporthive/score.txt;

将插入的查询语句写入.hql文件，再执行文件

1
2
3
4


-- export.hql
-- 可以包含多条SQL语句
USE myhive;
SELECT * FROM score;

1

hive -f export_data.hql > /export/servers/exporthive/score.txt;

将插入的查询语句写入.sh文件，再执行文件

1
2
3
4


#!/bin/bash
# export.sh
# 这是Shell脚本，内部调用Hive
hive -e "SELECT * FROM myhive.score;"

1

hive -f export_data.sh > /export/servers/exporthive/score.txt;

Export导出到HDFS

1

EXPORT TABLE score TO '/export/exporthive/score';

7. 命令对照速查表（数据库 vs 数据表）

维度	数据库（Database）	数据表（Table）
创建	`CREATE DATABASE`	`CREATE [EXTERNAL/TEMPORARY] TABLE`
查看列表	`SHOW DATABASES`	`SHOW TABLES`
查看详情	`DESC DATABASE [EXTENDED]`	`DESC [FORMATTED]` / `SHOW CREATE TABLE`
切换/使用	`USE db_name`	（SELECT 时通过 `db.table` 引用）
修改属性	`ALTER DATABASE ... SET DBPROPERTIES`	`ALTER TABLE ... SET TBLPROPERTIES`
改名	❌ 不支持	✅ `ALTER TABLE ... RENAME TO`
改结构	仅改属性/owner/location	增/改/换列、加减分区
删除	`DROP DATABASE [CASCADE]`	`DROP TABLE` / `TRUNCATE TABLE`

三、Hive的DQL查询语法

Hive 的 DQL（Data Query Language，数据查询语言）整体语法和标准 SQL 很相似，但因为底层是分布式计算（MapReduce/Tez/Spark），所以在排序、分桶采样、Join 等地方有自己的特色。

SELECT 完整语法骨架

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


SELECT [ALL | DISTINCT] select_expr, select_expr, ...
FROM table_reference
[WHERE where_condition]
[GROUP BY col_list]
[HAVING having_condition]
[CLUSTER BY col_list
| [DISTRIBUTE BY col_list] [SORT BY col_list]
| [ORDER BY col_list]
]
[LIMIT [offset,] rows]

这里的 | 表示"或者"（互斥选择），也就是说这三种排序方式只能选其中一种，不能同时使用：

选项	写法	含义
①	`CLUSTER BY col`	分发 + 排序（合二为一，同字段升序）
②	`DISTRIBUTE BY col1 SORT BY col2`	按 col1 分发到不同 Reducer，再按 col2 在 Reducer 内排序（可以拆开用）
③	`ORDER BY col`	全局排序（强制 1 个 Reducer）

📌 [ ] 表示可选；| 表示三选一；DISTRIBUTE BY 和 SORT BY 内部各自也是可选的，但通常成对出现。

执行顺序（面试高频）：

FROM → JOIN → WHERE → GROUP BY → HAVING → SELECT → DISTINCT → ORDER BY / SORT BY → LIMIT

WHERE

WHERE < 是不包含null的，查询结果中没有deptno=null的情况

1

SELECT * FROM employees WHERE deptno < 20;

运算符	含义
`=, <>, !=, <, >, <=, >=`	比较
`BETWEEN A AND B`	闭区间
`IS [NOT] NULL`	空值判断
`IN / NOT IN`	集合
`LIKE`	通配符 `% _`
`RLIKE / REGEXP`	正则匹配（Java 正则）
`AND / OR / NOT`	逻辑

GROUP BY

GROUP BY 使用group by则select后只能写分组的字段或聚合函数

WHERE vs HAVING：

区别点	WHERE	HAVING
过滤阶段	分组前	分组后
能否用聚合函数	❌ 不能	✅ 可以
操作对象	原始行	分组结果/聚合函数

1
2
3
4
5
6


SELECT 
 province,
 city,
 COUNT(DISTINCT user_id) AS 活跃用户数
FROM user_behavior
GROUP BY province, city;

排序

SORT BY

SORT BY 非全局排序，在数据进入reducer前完成排序，不保证全局有序

1
2
3


SELECT * FROM employees
DISTRIBUTE BY deptno
SORT BY sal DESC;

SORT BY 单独使用时，数据是随机分发到 Reducer 的，所以你无法控制"哪些数据进同一个 Reducer"。

而 DISTRIBUTE BY 就是用来控制分发规则（使用Hash算法）的，相当于 MapReduce 里的 Partitioner，

1
2
3


Map1 ┐ ┌──→ Reducer1: 部门10的所有员工，按 sal 降序
Map2 ┼──hash──→ ├──→ Reducer2: 部门20的所有员工，按 sal 降序
Map3 ┘ └──→ Reducer3: 部门30的所有员工，按 sal 降序

CLUSTER BY

CLUSTER BY 是 DISTRIBUTE BY + SORT BY 的简写，但有两个限制：

分发字段 = 排序字段（必须同一个字段）
只能升序（不能 DESC）

1
2
3


-- 以下两句等价
SELECT * FROM emp CLUSTER BY deptno;
SELECT * FROM emp DISTRIBUTE BY deptno SORT BY deptno;

ORDER BY

ORDER BY 对输入做全局排序，因此只有1个reducer，当规模较大时会耗时

1
2
3


Map1 ┐
Map2 ┼──→ [单个 Reducer，所有数据汇总] → 输出 1 个全局有序文件
Map3 ┘

总结

子句	作用范围	是否全局有序	Reduce 数量	使用场景
`ORDER BY`	全局排序	✅ 是	强制为 1	小数据量全排序
`SORT BY`	每个 Reducer 内部排序	❌ 否	多个	局部排序，输出多个有序文件
`DISTRIBUTE BY`	控制数据到哪个 Reducer	❌ 否	多个	类似 MR 中的 partitioner
`CLUSTER BY`	= DISTRIBUTE BY + SORT BY（同字段、升序）	❌ 否	多个	简写形式

JOIN

Join hive2 支持在ON·后连接 < > = OR，一个JOIN就会启动一个job，

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


-- 表A: employees
+-----+-------+---------+
| id | name | dept_id |
+-----+-------+---------+
| 1 | Alice | 101 |
| 2 | Bob | 102 |
| 3 | Carol | NULL |
+-----+-------+---------+

-- 表B: departments
+-------+-----------+
| dept_id | dept_name |
+-------+-----------+
| 101 | Sales |
| 103 | IT |
+-------+-----------+

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38


-- INNER JOIN 内连接（A ∩ B）: 基于连接条件的交集，只返回满足条件的行
-- 等价于 SELECT employees, departments 
SELECT e.name, d.dept_name
FROM employees e
INNER JOIN departments d ON e.dept_id = d.dept_id;
-- 返回
Alice Sales

-- LEFT [OUTER] JOIN 左外连接：左边数据会完全保留，右边符合连接条件的才会保留（右连接则相反）
SELECT e.name, d.dept_name
FROM employees e
LEFT JOIN departments d ON e.dept_id = d.dept_id;
--返回
Alice Sales
Bob NULL
Carol NULL

-- FULL [OUTER] JOIN 全连接（左连接 ∪ 右连接 但要去除重复行）：左表所有行 + 右表所有行,不匹配的行用NULL填充
SELECT e.name, d.dept_name
FROM employees e
FULL JOIN departments d ON e.dept_id = d.dept_id;
-- 返回
Alice Sales
Bob NULL
Carol NULL
NULL IT

-- 显式CROSS JOIN(笛卡尔积)左表×右表 = 全部组合
SELECT e.name, d.dept_name
FROM employees e
CROSS JOIN departments d;
-- 返回
Alice Sales
Alice IT
Bob Sales
Bob IT
Carol Sales
Carol IT

三种 Join 优化策略（联系上次聊的内容）

Join 类型	触发条件	原理
Common Join (Shuffle Join)	默认	Map 阶段输出 key，Reduce 阶段做 Join，开销大
Map Join	小表 < 25MB	小表广播到每个 Mapper，无 Shuffle
Bucket Map Join / SMB Join	两表分桶（+排序）且桶数成倍数	桶对桶 Join，无需 Shuffle

LIMIT（带 offset）

1
2
3


SELECT * FROM emp LIMIT 5; -- 前 5 行

SELECT * FROM emp LIMIT 10, 5; -- 跳过 10 行，取 5 行（部分版本支持）

UNION / UNION ALL

1
2
3
4
5
6


-- UNION ALL：不去重，效率高
SELECT * FROM emp WHERE deptno = 10
UNION ALL
SELECT * FROM emp WHERE deptno = 20;

-- UNION：去重，会触发额外 MR

什么时候使用雪花模型

Sun, 10 May 2026 20:24:22 +0800

一、多对多关系下“星型模型”的限制

1、无法处理类目层级过深

结构限制：星型模型的维度表是扁平的单表，一条商品记录只能对应一个类目值（或固定数量的几个字段）。

使用星型模型抽象只能将这一串抽象为一个类目，（如：“食品/饮料/碳酸饮料/可乐”）但这就会导致后面想统计其中任意一个层级时很困难

1
2
3
4
5


食品(level1)
 └ 饮料/(level2)
 └ 碳酸饮料(level3)
 └ 可乐(level4)
 └ 可口可乐 330ml(level5)

如果用星型模型来设计：

商品维度表通常是扁平化的，每个商品只有一条记录：

1
2
3
4
5
6
7


-- 星型模型的商品维度表（简化版）
CREATE TABLE dim_product_star (
 product_id INT PRIMARY KEY,
 product_name VARCHAR(100),
 -- 类目信息被“拍平”存储在这里
 category_full_path VARCHAR(200) -- 例如："食品/乳制品/牛奶/纯牛奶"
);

致命问题出现了：

这个表结构只能存储一个类目路径！
如果硬要存多个，只能这样设计：

1
2
3
4
5
6
7
8
9


-- 糟糕的设计：添加多个类目字段
CREATE TABLE dim_product_star_bad (
 product_id INT PRIMARY KEY,
 product_name VARCHAR(100),
 main_category_path VARCHAR(200), -- 主类目
 promo_category_path VARCHAR(200), -- 促销类目
 scene_category_path VARCHAR(200) -- 场景类目
 -- 如果还有第4个类目怎么办？再加字段？
);

这种设计的弊端：

不灵活：如果商品需要第4个类目，必须修改表结构（ALTER TABLE）。

查询困难：要找出所有属于“健康饮品”的商品，需要这样写：

1
2
3
4


SELECT * FROM dim_product_star_bad
WHERE main_category_path LIKE '%健康饮品%'
OR promo_category_path LIKE '%健康饮品%'
OR scene_category_path LIKE '%健康饮品%';

性能极差，且难以维护。

数据冗余：类目路径字符串被大量重复存储。

2、无法表达多对多的关系

在电商平台中，商品分类是复杂，这个商品可能同时属于以下类目：

主类目：食品 -> 乳制品 -> 牛奶 -> 纯牛奶
促销类目：食品 -> 饮料 -> 健康饮品（平台做活动时把它归到这里）
场景类目：早餐食材（早餐专题活动）

类目复杂
- 类目层数不固定
- 层数不固定
- 类目关系会动态变化（今天在A类目，明天可能加到B类目）
冗余巨大
- “食品/饮料/碳酸饮料” 重复出现几百万次
类目改名要更新全表
- 比如“碳酸饮料”改名为“气泡饮料”
- 数百万行要 update ❌

3、多类目统计困难

假设我们有销售事实表：

1
2
3
4
5


CREATE TABLE fct_sales (
 sale_id INT,
 product_id INT, -- 关联商品
 sale_amount DECIMAL(10,2)
);

需求：统计每个类目的总销售额。

在星型模型中，由于一个商品只关联一个主类目（即使它实际属于多个类目），你只能：

要么只按主类目统计，忽略其他类目 → 数据不准确
要么把销售额重复计算到多个类目 → 数据虚高

示例代码（错误统计）：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29


-- 错误方法1：只统计主类目（漏掉了促销类目和场景类目的贡献）
SELECT 
 p.main_category_path AS category,
 SUM(s.sale_amount) AS total_sales
FROM fct_sales s
JOIN dim_product_star_bad p ON s.product_id = p.product_id
GROUP BY p.main_category_path;

-- 错误方法2：重复计算（同一笔销售额被算了3次）
SELECT 
 '主类目' AS category_type,
 p.main_category_path AS category,
 SUM(s.sale_amount) AS total_sales
FROM fct_sales s
JOIN dim_product_star_bad p ON s.product_id = p.product_id
GROUP BY p.main_category_path

UNION ALL

SELECT 
 '促销类目' AS category_type,
 p.promo_category_path AS category,
 SUM(s.sale_amount) AS total_sales
FROM fct_sales s
JOIN dim_product_star_bad p ON s.product_id = p.product_id
WHERE p.promo_category_path IS NOT NULL
GROUP BY p.promo_category_path

-- 还要UNION场景类目...

结果：要么少算，要么多算，永远无法得到准确数据！

⚠️ 问题总结：

结构限制：星型模型的维度表是扁平的单表，一条商品记录只能对应一个类目值（或固定数量的几个字段）。
关系限制：它天然假设事实表（销售记录）和维度表（商品）是一对多关系，然后通过商品维度表连接到类目维度表。这种链式关系无法表达“一个商品→多个类目”。
业务现实：在真实电商中，商品分类是复杂的：
- 一个商品可以属于多个类目
- 不同类目可能有不同权重
- 类目关系会动态变化（今天在A类目，明天可能加到B类目）
数据准确性：星型模型要么丢失关系（只存一个主类目），要么重复计算（存多个字段但无法合理分摊指标）

二、解决方案：雪花模型 + 桥接表

现在看雪花模型如何优雅地解决这个问题：

初级解决方案

步骤1：规范化设计

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24


-- 1. 类目维度表（支持无限层级）
CREATE TABLE dim_category (
 category_id INT PRIMARY KEY,
 category_name VARCHAR(50),
 parent_id INT, -- 父类目ID，形成树形结构
 level INT
);

-- 2. 商品维度表（只存商品基本信息）
CREATE TABLE dim_product (
 product_id INT PRIMARY KEY,
 product_name VARCHAR(100),
 price DECIMAL(10,2)
 -- 注意：这里没有类目字段！
);

-- 3. 商品-类目桥接表（核心！处理多对多）
CREATE TABLE bridge_product_category (
 product_id INT,
 category_id INT,
 relation_type VARCHAR(20), -- 关系类型：'main'主类目, 'promo'促销, 'scene'场景
 weight DECIMAL(3,2) DEFAULT 1.0, -- 权重，用于分摊销售额
 PRIMARY KEY (product_id, category_id, relation_type)
);

步骤2：插入数据

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19


-- 插入类目数据
INSERT INTO dim_category VALUES 
(1, '食品', NULL, 1),
(2, '乳制品', 1, 2),
(3, '牛奶', 2, 3),
(4, '纯牛奶', 3, 4),
(5, '饮料', 1, 2),
(6, '健康饮品', 5, 3),
(7, '早餐食材', NULL, 1); -- 注意：早餐食材可能是一级类目

-- 插入商品数据
INSERT INTO dim_product VALUES (1001, '蒙牛纯牛奶250ml', 3.5);

-- 插入桥接关系：一个商品关联多个类目
INSERT INTO bridge_product_category VALUES 
(1001, 4, 'main', 0.6), -- 主类目：纯牛奶，权重60%
(1001, 6, 'promo', 0.3), -- 促销类目：健康饮品，权重30%
(1001, 7, 'scene', 0.1); -- 场景类目：早餐食材，权重10%
-- 权重总和为1.0，表示销售额将按此比例分摊

步骤3：准确统计各类目的销售额

1
2
3
4
5
6
7
8
9


-- 正确统计：按权重分摊销售额
SELECT 
 c.category_name,
 SUM(s.sale_amount * b.weight) AS allocated_sales
FROM fct_sales s
JOIN bridge_product_category b ON s.product_id = b.product_id
JOIN dim_category c ON b.category_id = c.category_id
GROUP BY c.category_name
ORDER BY allocated_sales DESC;

结果示例：

类目名称	分摊后销售额
纯牛奶	6000元（10000元×0.6）
健康饮品	3000元（10000元×0.3）
早餐食材	1000元（10000元×0.1）

总销售额仍然是10000元，但被合理地分摊到了各个类目！

拓展SCD概念

SCD（Slowly Changing Dimensions，缓慢变化维）是指数据仓库中维度表的数据会随时间缓慢变化的维度。这里的"缓慢"是相对于事实表而言的——事实表数据变化速度快（如交易记录），而维度表数据变化较慢（如用户信息、产品信息）。

典型示例：用户维度表中，用户的出生日期、住址、手机号等信息可能随时间发生变化

出现原因

业务数据的自然演变：

业务数据更新：用户修改个人信息（如搬家后更新地址）
数据修正：发现历史数据错误需要更正（如身份证号录入错误）
状态变更：产品价格调整、员工职位变动等
属性扩展：业务需求变化导致维度属性增加

如果不妥善处理这些变化，数据分析会出现以下问题：

历史事实与当前维度不匹配
无法追踪历史变化趋势
跨时间分析结果失真

应对措施

场景	推荐方案	说明
错误数据修正	Type 1	直接覆盖错误值
用户地址追踪	Type 2（拉链表）	完整历史分析
产品价格变化	Type 2或Type 3	根据分析需求选择
员工职位变动	Type 2	支持晋升路径分析

桥接表的时间化扩展

问题：今天在A类目，明天可能加到B类目

标准的桥接表需要增加时间有效性字段来处理关系的动态变化：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


CREATE TABLE bridge_product_category (
 product_id INT,
 category_id INT,
 relation_type VARCHAR(20), -- 关系类型：'main'主类目, 'promo'促销
 weight DECIMAL(3,2) DEFAULT 1.0, -- 权重

 -- 增加时间有效性字段！
 start_date DATE, -- 关系生效日期
 end_date DATE, -- 关系失效日期（'9999-12-31'表示当前有效）

 -- 记录变化时间戳
 created_at TIMESTAMP,
 updated_at TIMESTAMP,

 PRIMARY KEY (product_id, category_id, start_date)
);

实际案例：跟踪商品类目的历史变化

假设"蒙牛纯牛奶250ml"的类目关系变化如下：

2024-01-01 到 2024-03-31：属于纯牛奶类目
2024-04-01 开始：被重新分类到低温牛奶类目
2024-05-15 到 2024-06-15：添加了夏季饮品的促销类目

步骤1：初始化数据（2024-01-01）

1
2
3
4


-- 商品属于"纯牛奶"类目
INSERT INTO bridge_product_category VALUES 
(1001, 4, 'main', 1.0, '2024-01-01', '9999-12-31', '2024-01-01 00:00:00', '2024-01-01 00:00:00');
-- 商品ID=1001, 类目ID=4(纯牛奶)

步骤2：类目变更（2024-04-01）

注意：我们不能直接更新原有记录，而是需要：

关闭原有关系的有效期
添加新的关系记录

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


-- 1. 关闭旧的"纯牛奶"关系
UPDATE bridge_product_category 
SET end_date = '2024-03-31',
 updated_at = '2024-04-01 10:00:00'
WHERE product_id = 1001 
 AND category_id = 4 
 AND end_date = '9999-12-31';

-- 2. 创建新的"低温牛奶"关系
INSERT INTO bridge_product_category VALUES 
(1001, 8, 'main', 1.0, '2024-04-01', '9999-12-31', '2024-04-01 10:00:00', '2024-04-01 10:00:00');
-- 新类目ID=8(低温牛奶)

步骤3：添加促销类目（2024-05-15）

1
2
3
4


-- 添加夏季促销类目（只有一个月有效期）
INSERT INTO bridge_product_category VALUES 
(1001, 9, 'promo', 0.3, '2024-05-15', '2024-06-15', '2024-05-15 09:00:00', '2024-05-15 09:00:00');
-- 类目ID=9(夏季饮品)

步骤4：查看时间线上的关系变化

现在桥接表的状态：

product_id	category_id	relation_type	weight	start_date	end_date
1001	4	main	1.0	2024-01-01	2024-03-31
1001	8	main	1.0	2024-04-01	9999-12-31
1001	9	promo	0.3	2024-05-15	2024-06-15

这才是桥接表的强大之处！我们可以查询任意时间点的商品-类目关系：

适用场景

场景1：查询2024-02-15（春节促销）的商品类目

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


SELECT 
 p.product_name,
 c.category_name,
 b.relation_type,
 b.weight
FROM dim_product p
JOIN bridge_product_category b ON p.product_id = b.product_id
JOIN dim_category c ON b.category_id = c.category_id
WHERE p.product_id = 1001
 AND '2024-02-15' BETWEEN b.start_date AND b.end_date;

-- 结果：
-- 蒙牛纯牛奶250ml | 纯牛奶 | main | 1.0
-- 只有纯牛奶类目，此时还未变更

场景2：查询2024-05-20（夏季促销）的商品类目

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


SELECT 
 p.product_name,
 c.category_name,
 b.relation_type,
 b.weight
FROM dim_product p
JOIN bridge_product_category b ON p.product_id = b.product_id
JOIN dim_category c ON b.category_id = c.category_id
WHERE p.product_id = 1001
 AND '2024-05-20' BETWEEN b.start_date AND b.end_date;

-- 结果：
-- 蒙牛纯牛奶250ml | 低温牛奶 | main | 1.0
-- 蒙牛纯牛奶250ml | 夏季饮品 | promo | 0.3
-- 有两个类目关系同时生效！

场景3：统计2024年Q1（1-3月）各类目的销售额

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


SELECT 
 c.category_name,
 SUM(s.sale_amount * b.weight) AS allocated_sales
FROM fct_sales s
-- 关键：关联时要确保销售时间在关系有效期内
JOIN bridge_product_category b ON s.product_id = b.product_id
 AND s.sale_date BETWEEN b.start_date AND b.end_date
JOIN dim_category c ON b.category_id = c.category_id
WHERE s.sale_date BETWEEN '2024-01-01' AND '2024-03-31'
GROUP BY c.category_name;

-- 结果：所有销售额都会归到"纯牛奶"类目

如何处理复杂的权重变化？

有时候，商品在不同类目间的权重也会随时间变化。比如：

1-3月：主类目权重100%
4月开始：主类目60%，促销类目40%

这需要在变更时创建两条新记录：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


-- 2024-04-01变更权重
-- 1. 关闭旧的单一权重关系
UPDATE bridge_product_category 
SET end_date = '2024-03-31'
WHERE product_id = 1001 
 AND end_date = '9999-12-31';

-- 2. 创建新的多权重关系
INSERT INTO bridge_product_category VALUES 
(1001, 8, 'main', 0.6, '2024-04-01', '9999-12-31', NOW(), NOW()),
(1001, 9, 'promo', 0.4, '2024-04-01', '9999-12-31', NOW(), NOW());

为什么桥接表的时间化拓展的设计是优秀的？

1. 历史可追溯

可以查询任意历史时间点的类目归属关系。比如审计时想知道"2023年双十一期间，这个商品属于哪个类目"。

2. 时间一致性

确保销售事实与当时的维度关系一致。今天做的报表和历史报表在逻辑上是一致的。

3. 变更无影响

增加新类目：直接插入新记录
移除旧类目：将原记录的end_date设为昨天
修改权重：关闭旧记录，插入新权重的新记录
所有历史报表不受影响

4. 支持复杂的业务场景

季节性类目（如"夏季特饮"只存在6-8月）
促销活动类目（如"双十一专区"只在活动期间有效）
测试分组（A/B测试时，不同用户看到不同类目）

实际查询模板

模板1：获取当前有效的类目关系

1
2


SELECT * FROM bridge_product_category
WHERE CURRENT_DATE BETWEEN start_date AND end_date;

模板2：生成类目历史变化时间线

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


SELECT 
 p.product_name,
 c.category_name,
 b.relation_type,
 b.start_date,
 b.end_date,
 -- 计算持续时间
 DATEDIFF(
 IF(b.end_date = '9999-12-31', CURRENT_DATE, b.end_date),
 b.start_date
 ) + 1 AS duration_days
FROM bridge_product_category b
JOIN dim_product p ON b.product_id = p.product_id
JOIN dim_category c ON b.category_id = c.category_id
WHERE p.product_id = 1001
ORDER BY b.start_date;

三、完整的数仓分层设计

以下是基于商品订单的完整分层设计：

1. ODS层（操作数据存储）

目标：原样同步，保留历史，快速恢复

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45


-- 1.1 订单表（增量同步，按天分区）
CREATE TABLE ods_order_inc (
 order_id BIGINT COMMENT '订单ID',
 user_id BIGINT COMMENT '用户ID',
 product_id BIGINT COMMENT '商品ID',
 quantity INT COMMENT '购买数量',
 amount DECIMAL(10,2) COMMENT '订单金额',
 order_time TIMESTAMP COMMENT '订单时间',
 -- 原样字段
 order_status INT COMMENT '订单状态',
 payment_type INT COMMENT '支付方式',
 shipping_address STRING COMMENT '收货地址',
 -- 技术字段
 dt STRING COMMENT '分区字段(yyyy-MM-dd)',
 update_time TIMESTAMP COMMENT '更新时间',
 data_source STRING COMMENT '数据源标识'
) PARTITIONED BY (dt)
STORED AS ORC;

-- 1.2 商品表（全量/增量，视业务而定）
CREATE TABLE ods_product (
 product_id BIGINT COMMENT '商品ID',
 product_name STRING COMMENT '商品名称',
 sku_code STRING COMMENT 'SKU编码',
 price DECIMAL(10,2) COMMENT '价格',
 category_id BIGINT COMMENT '当前类目ID（业务系统的当前值）',
 brand_id BIGINT COMMENT '品牌ID',
 is_active TINYINT COMMENT '是否有效',
 create_time TIMESTAMP COMMENT '创建时间',
 update_time TIMESTAMP COMMENT '更新时间',
 dt STRING COMMENT '分区字段(yyyy-MM-dd)'
) PARTITIONED BY (dt)
STORED AS ORC;

-- 1.3 类目表（通常全量）
CREATE TABLE ods_category (
 category_id BIGINT COMMENT '类目ID',
 category_name STRING COMMENT '类目名称',
 parent_id BIGINT COMMENT '父类目ID',
 level INT COMMENT '层级',
 sort_order INT COMMENT '排序',
 is_leaf TINYINT COMMENT '是否叶子节点',
 dt STRING COMMENT '分区字段(yyyy-MM-dd)'
) PARTITIONED BY (dt)
STORED AS ORC;

2. DWD层（数据仓库明细层）

目标：清洗、规范化、构建维度模型

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78


-- 2.1 时间维度表（经典维度表）
CREATE TABLE dim_date (
 date_sk INT COMMENT '代理键',
 date_str STRING COMMENT '日期(yyyy-MM-dd)',
 year INT COMMENT '年',
 quarter INT COMMENT '季度',
 month INT COMMENT '月',
 day INT COMMENT '日',
 week_of_year INT COMMENT '周数',
 is_weekend TINYINT COMMENT '是否周末',
 holiday_flag TINYINT COMMENT '是否节假日',
 PRIMARY KEY (date_sk)
);

-- 2.2 商品维度表（缓慢变化维Type 2）
CREATE TABLE dim_product (
 product_sk BIGINT COMMENT '商品代理键',
 product_id BIGINT COMMENT '商品业务ID',
 product_name STRING COMMENT '商品名称',
 sku_code STRING COMMENT 'SKU编码',
 price DECIMAL(10,2) COMMENT '价格',
 brand_id BIGINT COMMENT '品牌ID',
 brand_name STRING COMMENT '品牌名称',
 -- 有效时间范围
 start_date DATE COMMENT '生效日期',
 end_date DATE COMMENT '失效日期',
 is_current TINYINT COMMENT '是否当前有效',
 create_time TIMESTAMP COMMENT '创建时间',
 update_time TIMESTAMP COMMENT '更新时间',
 PRIMARY KEY (product_sk)
);

-- 2.3 类目维度表（雪花模型，支持层级变化）
CREATE TABLE dim_category (
 category_sk BIGINT COMMENT '类目代理键',
 category_id BIGINT COMMENT '类目业务ID',
 category_name STRING COMMENT '类目名称',
 parent_sk BIGINT COMMENT '父类目代理键',
 level INT COMMENT '层级',
 full_path STRING COMMENT '完整路径',
 -- 缓慢变化维字段
 start_date DATE COMMENT '生效日期',
 end_date DATE COMMENT '失效日期',
 is_current TINYINT COMMENT '是否当前有效',
 PRIMARY KEY (category_sk)
);

-- 2.4 商品-类目桥接表（处理多对多和历史变化）
CREATE TABLE bridge_product_category (
 product_sk BIGINT COMMENT '商品代理键',
 category_sk BIGINT COMMENT '类目代理键',
 relation_type STRING COMMENT '关系类型(main/promo/scene)',
 weight DECIMAL(3,2) COMMENT '权重',
 -- 时间有效性
 start_date DATE COMMENT '生效日期',
 end_date DATE COMMENT '失效日期',
 is_current TINYINT COMMENT '是否当前有效',
 PRIMARY KEY (product_sk, category_sk, start_date)
);

-- 2.5 订单事实表（事务型事实表）
CREATE TABLE fct_order (
 order_sk BIGINT COMMENT '订单代理键',
 order_id BIGINT COMMENT '订单业务ID',
 date_sk INT COMMENT '日期代理键',
 product_sk BIGINT COMMENT '商品代理键',
 user_sk BIGINT COMMENT '用户代理键',
 quantity INT COMMENT '购买数量',
 amount DECIMAL(10,2) COMMENT '订单金额',
 order_status INT COMMENT '订单状态',
 payment_type INT COMMENT '支付方式',
 -- 退化维度
 shipping_city STRING COMMENT '收货城市',
 shipping_province STRING COMMENT '收货省份',
 create_time TIMESTAMP COMMENT '创建时间',
 update_time TIMESTAMP COMMENT '更新时间',
 PRIMARY KEY (order_sk)
);

3. DWS层（数据仓库汇总层）⭐

目标：反规范化，构建星型宽表，提升查询性能

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75


-- 3.1 商品销售日汇总宽表（星型模型）
CREATE TABLE dws_product_sales_di (
 -- 日期维度（冗余）
 date_sk INT COMMENT '日期代理键',
 date_str STRING COMMENT '日期',
 year INT COMMENT '年',
 month INT COMMENT '月',
 day INT COMMENT '日',
 is_weekend TINYINT COMMENT '是否周末',

 -- 商品维度（冗余）
 product_sk BIGINT COMMENT '商品代理键',
 product_id BIGINT COMMENT '商品ID',
 product_name STRING COMMENT '商品名称',
 sku_code STRING COMMENT 'SKU编码',
 price DECIMAL(10,2) COMMENT '价格',
 brand_id BIGINT COMMENT '品牌ID',
 brand_name STRING COMMENT '品牌名称',

 -- 类目维度（展平冗余）
 leaf_category_sk BIGINT COMMENT '叶子类目代理键',
 leaf_category_name STRING COMMENT '叶子类目名称',
 -- 层级展平（假设最多5级）
 l1_category_sk BIGINT COMMENT '一级类目代理键',
 l1_category_name STRING COMMENT '一级类目名称',
 l2_category_sk BIGINT COMMENT '二级类目代理键',
 l2_category_name STRING COMMENT '二级类目名称',
 l3_category_sk BIGINT COMMENT '三级类目代理键',
 l3_category_name STRING COMMENT '三级类目名称',
 l4_category_sk BIGINT COMMENT '四级类目代理键',
 l4_category_name STRING COMMENT '四级类目名称',
 l5_category_sk BIGINT COMMENT '五级类目代理键',
 l5_category_name STRING COMMENT '五级类目名称',

 -- 销售指标
 order_count BIGINT COMMENT '订单数',
 sale_quantity BIGINT COMMENT '销售数量',
 sale_amount DECIMAL(20,2) COMMENT '销售金额',
 user_count BIGINT COMMENT '购买用户数',

 -- 衍生指标
 avg_order_amount DECIMAL(10,2) COMMENT '客单价',
 conversion_rate DECIMAL(5,4) COMMENT '转化率',

 -- 分区字段
 dt STRING COMMENT '分区字段(yyyy-MM-dd)'
) PARTITIONED BY (dt)
STORED AS ORC
TBLPROPERTIES ('orc.compress'='SNAPPY');

-- 3.2 类目销售周汇总宽表
CREATE TABLE dws_category_sales_wi (
 -- 时间维度
 week_sk INT COMMENT '周代理键',
 year INT COMMENT '年',
 week_of_year INT COMMENT '周数',

 -- 类目维度（展平）
 category_sk BIGINT COMMENT '类目代理键',
 category_name STRING COMMENT '类目名称',
 level INT COMMENT '层级',
 parent_sk BIGINT COMMENT '父类目代理键',
 parent_name STRING COMMENT '父类目名称',

 -- 聚合指标
 order_count BIGINT COMMENT '订单数',
 sale_quantity BIGINT COMMENT '销售数量',
 sale_amount DECIMAL(20,2) COMMENT '销售金额',
 sale_amount_mom DECIMAL(8,4) COMMENT '环比增长率',
 sale_amount_yoy DECIMAL(8,4) COMMENT '同比增长率',

 -- 分区字段
 dt STRING COMMENT '分区字段(yyyy-MM-dd)'
) PARTITIONED BY (dt)
STORED AS ORC;

4. ADS层（应用数据服务）

目标：面向应用，直接供给报表/接口

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26


-- 4.1 类目销售排行榜（供BI展示）
CREATE TABLE ads_category_rank_di (
 date_str STRING COMMENT '日期',
 category_name STRING COMMENT '类目名称',
 level INT COMMENT '层级',
 sale_amount DECIMAL(20,2) COMMENT '销售额',
 sale_amount_rank INT COMMENT '销售额排名',
 sale_amount_percent DECIMAL(5,2) COMMENT '销售额占比%',
 mom_growth_rate DECIMAL(8,4) COMMENT '环比增长率',
 dt STRING COMMENT '分区字段'
) PARTITIONED BY (dt)
STORED AS PARQUET;

-- 4.2 商品销售明细报表（供运营使用）
CREATE TABLE ads_product_sales_report_di (
 date_str STRING COMMENT '日期',
 product_id BIGINT COMMENT '商品ID',
 product_name STRING COMMENT '商品名称',
 category_full_path STRING COMMENT '类目全路径',
 sale_quantity BIGINT COMMENT '销售数量',
 sale_amount DECIMAL(20,2) COMMENT '销售额',
 inventory_count BIGINT COMMENT '库存数量',
 stock_days INT COMMENT '可售天数',
 dt STRING COMMENT '分区字段'
) PARTITIONED BY (dt)
STORED AS PARQUET;

数据处理流程示例

从DWD到DWS的ETL过程

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69


-- 构建DWS商品销售日汇总宽表
INSERT OVERWRITE TABLE dws_product_sales_di PARTITION(dt='${date}')
SELECT 
 -- 日期维度
 d.date_sk,
 d.date_str,
 d.year,
 d.month,
 d.day,
 d.is_weekend,

 -- 商品维度
 p.product_sk,
 p.product_id,
 p.product_name,
 p.sku_code,
 p.price,
 p.brand_id,
 p.brand_name,

 -- 类目维度（展平处理）
 bc.category_sk as leaf_category_sk,
 cat_leaf.category_name as leaf_category_name,
 -- 递归获取上级类目（实际生产中可用递归CTE或UDF）
 get_category_by_level(cat_leaf.category_sk, 1) as l1_category_sk,
 get_category_by_level(cat_leaf.category_sk, 1) as l1_category_name,
 get_category_by_level(cat_leaf.category_sk, 2) as l2_category_sk,
 get_category_by_level(cat_leaf.category_sk, 2) as l2_category_name,
 get_category_by_level(cat_leaf.category_sk, 3) as l3_category_sk,
 get_category_by_level(cat_leaf.category_sk, 3) as l3_category_name,

 -- 销售指标
 COUNT(DISTINCT o.order_id) as order_count,
 SUM(o.quantity) as sale_quantity,
 SUM(o.amount) as sale_amount,
 COUNT(DISTINCT o.user_sk) as user_count,

 -- 衍生指标
 SUM(o.amount) / NULLIF(COUNT(DISTINCT o.order_id), 0) as avg_order_amount

FROM fct_order o
-- 关联时间维度
JOIN dim_date d ON o.date_sk = d.date_sk
-- 关联商品维度（取当前有效的商品）
JOIN dim_product p ON o.product_sk = p.product_sk 
 AND o.date_sk BETWEEN p.start_date AND p.end_date
 AND p.is_current = 1
-- 关联桥接表（取当前有效的主类目）
JOIN bridge_product_category bc ON o.product_sk = bc.product_sk
 AND o.date_sk BETWEEN bc.start_date AND bc.end_date
 AND bc.is_current = 1
 AND bc.relation_type = 'main'
-- 关联叶子类目
JOIN dim_category cat_leaf ON bc.category_sk = cat_leaf.category_sk
 AND o.date_sk BETWEEN cat_leaf.start_date AND cat_leaf.end_date
 AND cat_leaf.is_current = 1
-- 通过UDF获取各层上级类目
LEFT JOIN dim_category cat_l1 ON get_parent_category_sk(cat_leaf.category_sk, 1) = cat_l1.category_sk
 AND o.date_sk BETWEEN cat_l1.start_date AND cat_l1.end_date
 AND cat_l1.is_current = 1
-- ... 类似关联其他层级

WHERE d.date_str = '${date}'
GROUP BY 
 d.date_sk, d.date_str, d.year, d.month, d.day, d.is_weekend,
 p.product_sk, p.product_id, p.product_name, p.sku_code, p.price, p.brand_id, p.brand_name,
 bc.category_sk, cat_leaf.category_name,
 -- 各层类目字段...
;

查询性能对比

雪花模型查询（DWD层）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


-- 查询某个一级类目下所有商品的销售额（需要多层JOIN）
SELECT 
 cat_l1.category_name as level1_category,
 SUM(o.amount) as total_sales
FROM fct_order o
JOIN dim_product p ON o.product_sk = p.product_sk
JOIN bridge_product_category bpc ON p.product_sk = bpc.product_sk
JOIN dim_category cat_leaf ON bpc.category_sk = cat_leaf.category_sk
JOIN dim_category cat_l2 ON cat_leaf.parent_sk = cat_l2.category_sk
JOIN dim_category cat_l1 ON cat_l2.parent_sk = cat_l1.category_sk
WHERE o.date_sk BETWEEN 20240101 AND 20240131
 AND cat_l1.category_name = '食品'
GROUP BY cat_l1.category_name;
-- 执行时间：~5-10秒（5-6个JOIN）

星型模型查询（DWS层）

1
2
3
4
5
6
7
8
9


-- 同样的查询，在DWS层只需要单表扫描
SELECT 
 l1_category_name as level1_category,
 SUM(sale_amount) as total_sales
FROM dws_product_sales_di
WHERE dt BETWEEN '2024-01-01' AND '2024-01-31'
 AND l1_category_name = '食品'
GROUP BY l1_category_name;
-- 执行时间：~0.5-1秒（无JOIN，只需单表聚合）

分层架构总结

分层	模型	核心目标	数据特征	用户	存储策略
ODS	原始模型	数据同步、历史备份	原始数据、无清洗	数据工程师	全量/增量
DWD	雪花模型	数据质量、一致性、灵活性	规范化、明细数据	数据开发	分区+列存
DWS	星型模型	查询性能、易用性	反规范化、汇总数据	分析师/业务	宽表+索引
ADS	应用模型	业务适配、接口性能	高度聚合、应用定制	应用/报表	缓存+分区

关键设计原则：

DWD层保持灵活性：用雪花模型支持多对多、历史变化、层级可变
DWS层追求性能：用星型模型预关联、预计算，空间换时间
层层递进：ODS → DWD（清洗） → DWS（汇总） → ADS（应用）
适度冗余：在DWS层合理冗余维度属性，避免过度规范化
数据复用：DWS层宽表可被多个ADS应用复用

数据中台、数据仓库、大数据平台、数据湖概念区分

Tue, 05 May 2026 21:23:00 +0800

数据源、数据特点、存储方式

“数据源”是一个泛指，它包含企业内外部所有可能产生数据的系统。关系型数据库（如MySQL、Oracle）只是其中最重要、最结构化的一类。

根据行业实践，数据源主要分为以下几类：

数据源类型	典型示例	数据特点	常用采集技术
企业内部业务数据	ERP、CRM、OA、财务系统	高度结构化，质量高，价值密度大	数据库同步（Sqoop、CDC）、API
应用日志与埋点	服务器日志、APP/Web用户行为埋点	半结构化/非结构化，数据量大，实时性强	Flume、Logstash、Kafka
物联网与传感器	智能设备、工业传感器、GPS	流式数据，频率高，实时性要求极高	MQTT、边缘计算、Flink
互联网与社交媒体	网页、电商评论、社交媒体内容	非结构化为主，格式多样，更新快	网络爬虫、公开API
第三方数据	数据服务商、政府公开数据	标准化程度不一，有合规要求	API下载、文件导入

结论：数据源是多源异构的。大数据平台的首要任务就是将这些不同来源、不同格式、不同时效的数据统一接入。

数据源：远不止关系型数据库

你图中的“数据源”是一个泛指，它包含企业内外部所有可能产生数据的系统。关系型数据库（如MySQL、Oracle）只是其中最重要、最结构化的一类。

根据行业实践，数据源主要分为以下几类：

数据源类型	典型示例	数据特点	常用采集技术
企业内部业务数据	ERP、CRM、OA、财务系统	高度结构化，质量高，价值密度大	数据库同步（Sqoop、CDC）、API
应用日志与埋点	服务器日志、APP/Web用户行为埋点	半结构化/非结构化，数据量大，实时性强	Flume、Logstash、Kafka
物联网与传感器	智能设备、工业传感器、GPS	流式数据，频率高，实时性要求极高	MQTT、边缘计算、Flink
互联网与社交媒体	网页、电商评论、社交媒体内容	非结构化为主，格式多样，更新快	网络爬虫、公开API
第三方数据	数据服务商、政府公开数据	标准化程度不一，有合规要求	API下载、文件导入

结论：数据源是多源异构的。大数据平台的首要任务就是将这些不同来源、不同格式、不同时效的数据统一接入。

数据类型

数据类型	定义	典型示例	类比
结构化数据	具有严格固定模式的数据，可以用二维表结构（行和列）逻辑表达。	关系型数据库表（MySQL订单表）、Excel表格、CSV文件。	乐高积木：每个零件都有固定的形状和接口，可以精确拼接。
半结构化数据	具有一定结构，但模式不固定，常以自描述的形式存在（如标签、标记）。	JSON、XML、日志文件、HTML页面。	一封信：有固定的开头（称呼）、正文、结尾（署名）结构，但正文内容自由。
非结构化数据	没有预定义数据模型，格式多样，无法用简单的二维表表示。	文本（文章、邮件）、图片、音频、视频、PDF文档。	一团黏土：没有固定形状，可以塑造成任何样子。
流式数据	按时间顺序持续不断、无限生成的数据序列，强调数据的时效性和顺序性。	传感器实时读数、股票交易流水、APP点击流、直播弹幕。	自来水管中的水：持续流动，必须用容器（如桶）接住并实时处理，否则就流走了。

关键辨析：

结构化/半结构化/非结构化 是 从数据格式的规范性 角度划分。
流式数据 是 从数据产生的时序性和处理方式 角度划分，它可以是结构化的（如交易流水），也可以是半结构化的（如JSON格式的日志）。

为什么数据源对应不同的数据特点

这由数据产生的源头和方式决定。

业务系统（如ERP、CRM）：
- **为什么是结构化数据？**因为这些系统基于关系型数据库构建，必须遵循严格的表结构来保证事务的ACID特性。一条“订单”数据，必须包含订单ID、用户ID、金额、时间等固定字段。
- 设计原因：保证数据的一致性、完整性和准确性，这是业务运转的基石。
应用日志与埋点：
- **为什么是半结构化数据（如JSON）？** 因为日志需要灵活地记录各种事件，不同事件的参数差异很大。JSON的键值对形式既能保持一定的可读性，又能灵活扩展。
- 示例：一个“点击事件”的JSON日志可能包含 {“event”: “click”, “user_id”: “123”, “page”: “home”, “timestamp”: “2023-05-12 10:00:00”}，而一个“支付事件”的日志会增加 “amount”: 100, “order_id”: “456”等字段。
- 设计原因：灵活性和可扩展性。业务快速迭代时，可以随时增加新的日志字段，而无需修改数据库表结构。
物联网与传感器：
- **为什么是流式数据？** 因为物理世界是连续变化的，传感器以固定的频率（如每秒100次）持续产生读数。
- 设计原因：实时监控与即时响应。例如，监控电网频率，必须在毫秒级发现异常并触发保护。
图片、音视频：
- **为什么是非结构化数据？** 其信息蕴含在像素、声波、帧序列中，计算机无法直接理解其“含义”。
- 设计原因：承载人类可感知的丰富信息。一张产品图片所包含的信息，远非“颜色：红，尺寸：大”这几个结构化字段所能概括。

存储方式与设计原因

不同的数据类型，因其使用方式不同，采用了截然不同的存储方案。

数据类型	典型存储方案	为什么这么设计？
结构化数据	关系型数据库（MySQL/Oracle）、数据仓库（Hive/ClickHouse）	为了高效的关联查询和事务处理。二维表结构和SQL语言是为关联查询而生的最优解。数据仓库则针对海量数据的分析查询做了列式存储等优化。
半结构化数据	NoSQL数据库（MongoDB/ES）、分布式文件系统（HDFS）、消息队列（Kafka）	为了灵活的模式和快速的读写。MongoDB的文档模型直接存储JSON，便于扩展。HDFS和Kafka则提供了高吞吐的廉价存储，适合海量日志的批量或流式处理。
非结构化数据	对象存储（AWS S3/阿里云OSS）、分布式文件系统（HDFS）	为了存储海量、低访问频率的“大文件”。对象存储提供近乎无限的容量、极高的持久性和低廉的成本，并通过HTTP接口访问，非常适合存储图片、视频。
流式数据	消息队列（Kafka/Pulsar）、流处理引擎内存	为了缓冲和削峰填谷。流数据产生速度不稳定，需要消息队列作为“缓冲区”来承接，再让下游的流处理引擎（如Flink）以可控的速度消费处理。Kafka的持久化机制也允许数据重播。

一个综合案例：用户上传短视频

视频文件（非结构化） -> 存入 对象存储（OSS），获得一个URL。
视频元信息（结构化）：标题、作者、时长、OSS URL -> 存入 关系数据库（MySQL）。
用户播放行为日志（半结构化JSON） -> 实时写入 消息队列（Kafka）。
Kafka中的日志 -> 被 流处理引擎Flink实时消费，计算热度指标。
**计算结果（结构化）** -> 写回 数据库或数据仓库，用于推荐。

大数据中的易混淆概念

数据流动方向

如下：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


 数据源（业务系统 / 日志 / IoT）
 ↓
 数据湖（原始数据池）
 ↓
 数据仓库（结构化分析层）
 ↓
 数据中台（数据服务层）
 ↓
 业务应用 / BI / AI

 大数据平台 = 整体技术底座（承载以上所有）

数据湖 vs. 数据仓库ODS层：核心区别

这是一个经典问题。两者虽然都可能存储“原始数据”，但定位、设计和用途有本质区别。

对比维度	数据湖	数据仓库ODS层
核心定位	企业级原始数据“蓄水池”	面向分析的数据“预处理区”
设计哲学	“先存储，后定义” (Schema-on-Read)	“先定义，后存储” (Schema-on-Write)
数据范围	全量原始数据：结构化、半结构化、非结构化（文本、图片、视频、日志）	业务系统结构化数据的镜像：主要来自关系型数据库、日志文件等
数据状态	绝对原始，基本不做清洗转换，保留所有细节和可能的“脏数据”。	轻度清洗整合：会进行字段标准化、编码统一、简单去重等，保证数据一致性。
存储目标	长期存储，用于数据探索、机器学习、回溯分析等未知场景。	短期或周期存储，作为数据仓库ETL流程的缓冲区和数据来源。
主要用户	数据科学家、算法工程师，进行数据挖掘和模型训练。	数据开发工程师、数据分析师，进行ETL加工和即席查询。
技术实现	基于 HDFS、对象存储（如S3、OSS），搭配 Hive、Spark、Presto 进行查询。	通常是 Hive 或 MPP数据库中的一个逻辑层，有明确的表结构。

假设你有一个电商平台：

数据湖 里存了什么？
- MySQL 里订单表的 全量二进制日志。
- 用户在前端的所有 点击流JSON日志。
- 商品页的 详情图片。
- 客服与用户的 聊天录音。
- 这些数据可能几年都不会被用到，但一旦需要训练一个“以图搜图”的模型，商品图片就派上用场了。
ODS层 里存了什么？
- 从MySQL同步过来的 ods_order表，已经将时间字段统一为UTC，将用户状态编码（如0/1）统一为中文（‘有效’/‘无效’）。
- 从日志服务器同步过来的 ods_user_click表，已经将JSON日志解析成了结构化的字段（user_id, page_url, click_time）。
- 它的目的非常明确：快速、稳定地为下游的DWD（明细层）、DWS（汇总层）提供高质量的、结构化的数据源。

数据中台、数据仓库、大数据平台、数据湖

数据湖（Data Lake）
- 定义：一个集中存储所有原始数据（结构化、半结构化、非结构化）的存储库，就像一个大湖，无论河水、雨水都先汇集于此。
- 核心特征：“先存后用”，存储成本低，格式不限，支持灵活的数据探索与高级分析（如AI训练）。
数据仓库（Data Warehouse）
- 定义：一个面向主题的、集成的、相对稳定的、反映历史变化的数据集合，用于支持管理决策。
- 核心特征：“先用后存”，数据经过清洗、转换、建模（如维度建模），形成易于理解的、高质量的数据模型（如分层模型：ODS→DWD→DWS→ADS）。
大数据平台（Big Data Platform）
- 定义：提供数据全生命周期管理能力的技术底座与工具集合。它是承载数据湖、数据仓库、数据中台运行的“操作系统”和“工具箱”。
- 核心特征：技术导向，包含存储（HDFS / S3）、计算（Spark、Flink、MapReduce）、工具（Hive、Kafka、HBase）、调度系统、元数据管理等一整套技术组件。
数据中台（Data Middle Platform）
- 定义：一种组织战略与架构理念，通过将数据资产、数据能力、数据服务进行平台化、组件化、标准化，以API服务的形式快速响应前台业务需求。
- 核心特征：业务与组织导向，核心目标是“降本增效”和“数据业务化”。它不是一个具体软件，而是基于大数据平台构建的“数据产品工厂”和“服务超市”。
- 数据治理（标准、质量、血缘）、数据资产（标签 / 指标）、数据服务（API / 数据接口）、数据复用（跨部门使用）

核心区别与联系（一张图看懂）

维度	数据湖	数据仓库	大数据平台	数据中台
核心定位	原始数据 “仓库”	分析数据“超市”	技术“工具箱”与“地基”	数据能力“服务商”
主要目的	存储一切，探索未知	支撑已知的、稳定的分析报表	提供稳定可靠的数据处理技术能力	快速响应业务变化，赋能创新
数据状态	原始、未加工、格式多样	清洗、整合、建模后的高质量数据	承载上述所有数据状态	不直接存储数据，提供数据的服务化封装
典型用户	数据科学家、算法工程师	数据分析师、业务决策者	数据开发工程师、平台运维	前端业务开发、产品经理、运营
技术栈	HDFS/S3 + Spark/Presto	Hive/Spark + 维度建模 + BI工具	Hadoop生态全家桶 + 调度/监控	基于大数据平台，增加服务化、资产化管理组件
产出物	原始数据集、AI模型	报表、指标、分析结论	稳定运行的集群、任务、管道	统一数据服务API（如“用户画像API”、“实时风控API”）
通俗比喻	毛坯房仓库（什么都能放，但找东西难）	精装陈列馆（分门别类，方便参观）	建筑工地与工具（水泥、钢筋、起重机）	物业管理公司+精品店（提供标准化服务，快速满足住户需求）

它们的关系链可以概括为：

大数据平台 提供了从“数据源”抽取数据到 **“数据湖” 的能力，并对湖中数据进行加工后存入 “数据仓库”。“数据中台”** 则将数据仓库（及数据湖）中的核心数据资产，封装成易用的服务，通过 大数据平台 的能力，高效地提供给“业务应用”。

电商场景的实例

假设“淘宝”要做一个“猜你喜欢”功能：

数据湖：存储用户所有的原始点击流日志、商品图片、搜索词、甚至客服语音。
数据仓库：将点击流日志清洗成结构化表 dwd_user_click，并与商品表dim_product关联，生成用户行为宽表 dws_user_behavior。
大数据平台：用 Flink 实时处理点击流写入数据湖，用 Spark 每天定时计算 dws_user_behavior表，用 Airflow 调度整个任务。
数据中台：数据中台团队将 dws_user_behavior表中的核心逻辑（如“用户近期偏好类目”）封装成一个名为 **“用户实时偏好服务”** 的API。推荐系统的开发团队直接调用这个API，而无需关心数据在哪里、如何计算。

现代趋势：湖仓一体

湖仓一体 是一种融合性数据架构，它试图在一个统一的平台上，同时提供数据湖的灵活性、低成本存储和数据仓库的高性能、强管理性。

核心思想：不再将“湖”和“仓”物理分离成两套系统，而是构建一个统一的数据管理层，让数据“一份存储”，却能同时支持数据科学探索（像用湖）和高性能BI分析（像用仓）。

👉 不再分湖和仓，而是直接在“湖”里建“仓能力”

为什么会出现 Lakehouse

1）数据仓库的问题

✅ 查询快 ❌ 只能结构化数据 ❌ 成本高 ❌ 不适合 AI / ML

2）数据湖的问题

✅ 什么都能存 ✅ 成本低 ❌ 数据乱（容易变“数据沼泽”） ❌ 无事务、无治理 ❌ 查询慢

湖仓一体 vs. 其他概念

概念	与湖仓一体的相同点	与湖仓一体的核心不同点
数据湖	存储原始数据：湖仓一体继承了数据湖存储原始、多格式数据的能力。	缺乏治理与性能：传统数据湖是“野蛮生长”的，缺乏ACID事务、数据版本管理、行级更新和查询优化，难以直接支撑高性能BI。湖仓一体补上了这些能力。
数据仓库	支撑BI分析：湖仓一体提供了可与传统数据仓库媲美的SQL性能和数据治理能力。	不够开放灵活：传统数据仓库对非结构化数据和AI场景支持弱，且常是封闭、昂贵的专用系统。湖仓一体基于开放的存储格式（如Parquet/ORC）和计算引擎（如Spark），更开放、成本更低。
大数据平台	技术底座：湖仓一体是构建在大数据平台（如HDFS、对象存储、Spark）之上的一种具体架构实现。	范围更聚焦：大数据平台是一个更宽泛的“工具箱”概念。湖仓一体是这个工具箱为解决“湖仓割裂”问题而组合出的一种特定“解决方案”或“产品形态”。
数据中台	共同目标：两者都致力于提升数据利用效率、降低数据使用成本。	层次不同：数据中台是业务和组织层面的战略与架构，强调数据服务化。湖仓一体是偏技术层面的存储与计算架构，是中台战略得以实现的重要技术支撑。一个强大的湖仓一体平台，能让数据中台的数据资产管理和服务封装更高效。

Lakehouse 核心能力

序号	核心能力	含义	解决的问题	关键技术 / 实现方式	你项目里的对应
1️⃣	统一存储	所有数据（结构化 / 半结构化 / 非结构化）都存在同一份存储中	消除“湖一份 + 仓一份”的数据冗余	对象存储（ADLS / S3 / OSS）	ADLS / ObjectStore 作为底座
2️⃣	支持所有数据类型	同时支持表、JSON、日志、图片、音视频等	数据仓库只能存结构化数据的局限	Parquet / ORC / Avro / 二进制文件	Cosmos 原始日志 + Kusto 结构化数据
3️⃣	ACID 事务支持 ⭐	提供原子性、一致性、隔离性、持久性	数据湖没有事务、数据混乱、无法 Update/Delete	Delta Lake / Apache Iceberg / Apache Hudi	类似 Kusto 的 ingestion 一致性，但更通用
4️⃣	统一计算（多工作负载）	一套系统支持 BI、SQL、流计算、ML/AI	传统架构需要 Hive + Spark + Kafka + DWH 多套系统	Spark SQL / Flink / Presto / Databricks SQL	Spark + ADF + Kusto 的统一替代方案
5️⃣	存算分离	存储与计算独立扩展，按需付费	传统数仓存算耦合，扩容成本高	存储：ADLS / S3；计算：Spark / Trino / StarRocks	你现在 Spark on ADLS 就是典型存算分离
6️⃣	批流一体	离线和实时数据用同一套链路处理	Lambda 架构（批+流双链路）维护复杂	Delta Streaming / Flink CDC / Structured Streaming	替代“ADF批 + Kafka流”双链路

🎯 一句话记忆口诀（建议背下来）

一存（统一存储）、多类（多数据类型）、强事务（ACID）、多算（统一计算）、分离（存算分离）、一体（批流一体）

湖仓一体是如何实现的？（技术关键）

它并非魔法，而是通过一系列技术创新实现的：

统一的元数据层：在HDFS或对象存储（S3/OSS）之上，增加一个统一的元数据管理层，像“智能目录”一样管理所有数据。
开放的表格式：采用 Apache Iceberg、Apache Hudi、Delta Lake 等“事务化表格式”层。这是湖仓一体的技术核心。
- 它们为存储在湖上的文件提供了类似数据库表的抽象，支持ACID事务、时间旅行、模式演进、高效upsert/delete。
计算引擎分离：计算引擎（Spark、Flink、Presto、BI工具）可以直接通过统一的表格式层访问数据，而无需移动数据。

Lakehouse的5层架构

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


┌─────────────────────────────────────┐
│ 5. 应用层（BI / ML / AI / 实时） │
├─────────────────────────────────────┤
│ 4. 计算引擎层（Spark/Flink/Trino） │
├─────────────────────────────────────┤
│ 3. 元数据 / 事务层（Delta Log）⭐⭐ │ ← 核心
├─────────────────────────────────────┤
│ 2. 表格式层（Parquet + 索引） │
├─────────────────────────────────────┤
│ 1. 存储层（ADLS / S3 / OSS） │
└─────────────────────────────────────┘