Hive on My Learning Notes

【十】Hive 窗口函数：OVER / PARTITION BY / ORDER BY 与 OLAP 分析

Wed, 03 Jun 2026 22:37:14 +0800

Hive 窗口函数

窗口函数（Window Function，也叫 Analytic Function）用于在不改变查询结果行数的情况下，对某一“窗口范围”的数据进行计算。
与 GROUP BY 不同：

GROUP BY：会聚合并减少行数
窗口函数：在每一行上计算一个结果，但计算基于当前行周围的一组行（窗口）

窗口函数是实现SQL层面OLAP分析的利器，OLAP 是OnLine Analytical Processing 的简称，意思是对数据库数据进行实时分析处理。例如，市场分析、创建财务报表、创建计划等日常性商务工作。窗口函数就是为了实现OLAP 而添加的标准SQL 功能。

一、OLAP 和窗口函数

1.1 为什么窗口函数和 OLAP 相关

传统 SQL（早期 SQL）只有：

1
2


GROUP BY
SUM / AVG / COUNT

比如如下代码只能得到 每个部门的总sales值：

1
2
3


SELECT dept, SUM(sales)
FROM sales
GROUP BY dept;

但分析场景往往需要 更复杂的结果，例如：：

① 每个部门内部销售排名

A 部门
1 Jerry
2 Lucy
3 Tom

② 每天的累计销售

day sales cumulative_sales
1 100 100
2 200 300
3 150 450

③ 每条记录和上一条比较

day sales yesterday_sales

这些 都不能用普通 GROUP BY 实现。

于是 2003的SQL 标准就增加了一类函数窗口函数 (Window Function)，专门用于 OLAP分析计算，所以窗口函数又名Analytic Function。

OLAP 经常需要这些分析能力：

分析需求	SQL实现
排名	`RANK()`
TopN	`ROW_NUMBER()`
累计值	`SUM() OVER()`
移动平均	`AVG() OVER ROWS BETWEEN`
前后行比较	`LAG()` / `LEAD()`
每组第一条	`FIRST_VALUE()`

这些操作都有一个共同点：

计算某一行时，需要访问"当前行附近的一组数据"

例如：

day revenue
1 100
2 200
3 50

累计：

day1 → 100
day2 → 100 + 200
day3 → 100 + 200 + 50

显然：第3行计算需要看到前2行，因此 SQL 需要一个概念定义：

当前行 + 周围数据

这就是 Window Function。

OLAP = 业务数据分析需求
窗口函数 = SQL 为了实现这些分析需求而提供的工具

1.2 为什么叫“窗口”函数

核心思想：每一行的计算都不是只用当前行，而是使用“当前行周围的一组数据。

这个数据范围就叫：Window (窗口)

例如：

1
2
3
4
5
6


SUM(amount) 
OVER (
 PARTITION BY user
 ORDER BY day
 ROWS BETWEEN 3 PRECEDING AND CURRENT ROW
)

含义：当前行+前3行

这 4 行就形成了一个 window。

然后在这个 window 上计算：

sum / avg / rank

1.3 为什么窗口函数必须 partition + sort

窗口函数的核心本质是：

在一组有序数据中，针对当前行计算一个窗口范围

这就必然需要两个动作：partition+sort

原因如下：

1） partition

定义：哪几行属于同一组

例如：PARTITION BY region 表示：每个 region 单独计算

数据逻辑：

region = A
 ↓
A1
A2
A3

region = B
 ↓
B1
B2

2） sort

窗口函数必须 确定“前/后”顺序。

例如：

1
2
3


LAG()
RANK()
running sum

都依赖顺序。

例子：

1

ORDER BY revenue DESC

数据变为：

300
200
100

才能计算排名：rank

3） window frame

最后定义：窗口范围

例如：当前行+前三行

1

ROWS BETWEEN 3 PRECEDING AND CURRENT ROW

数据：

1
2
3
4


row5 (current)
row4
row3
row2

1.4 窗口函数分类

分类	作用	核心函数
1. 序号函数	给行编号/排名	`ROW_NUMBER`, `RANK`, `DENSE_RANK`, `NTILE`
2. 分布函数	看数据分布	`CUME_DIST`, `PERCENT_RANK`
3. 前后函数	看前一行/后一行	`LAG`, `LEAD`
4. 头尾函数	看窗口首尾值	`FIRST_VALUE`, `LAST_VALUE`
5. 聚合函数（窗口版）	在窗口内做统计	`SUM`, `AVG`, `COUNT`, `MAX/MIN`
6. 其他分析函数	特殊统计	`NTH_VALUE`

下面我按你给的 6 类，把 Hive 窗口函数讲透：给数据源（建表+样例数据）→ 示例 SQL → 输出结果示例 → 原理分析（逻辑/执行/坑点）。为避免来回切换数据，我全程使用同一份 sales 数据。

三、统一数据源

3.1 表结构 & 样例数据

场景：每个部门（dept）里有多名员工（emp），每天有一笔销售额（amount）。

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


DROP TABLE IF EXISTS sales;
CREATE TABLE sales (
dept STRING,
emp STRING,
dt STRING, -- 'yyyy-MM-dd'
amount INT
)
ROW FORMAT DELIMITED FIELDS TERMINATED BY '\t'
STORED AS TEXTFILE;

-- 样例数据（你也可以用 INSERT VALUES / LOAD DATA）
INSERT INTO sales VALUES
('A','alice','2026-05-01',100),
('A','alice','2026-05-02',120),
('A','bob' ,'2026-05-01',120), -- 与 alice 2026-05-02 并列金额 120（制造 tie）
('A','bob' ,'2026-05-03', 80),
('A','cindy','2026-05-02',120), -- 再制造 tie
('B','david','2026-05-01', 90),
('B','david','2026-05-02', 90), -- tie
('B','eric' ,'2026-05-01',200),
('B','eric' ,'2026-05-03', 50),
('B','frank','2026-05-02',200); -- tie 200

3.2 基础规则（先把“窗口”这件事说明白）

一个窗口函数长这样：

1
2
3
4
5


<窗口函数>(...) OVER (
 PARTITION BY ... -- 分组：每个分区独立计算
 ORDER BY ... -- 分区内排序：定义“第1行/前后行/累计”的顺序
 ROWS/RANGE ... -- 窗口帧：定义“本行能看到哪些行”（非常关键）
)

1、PARTITION BY：决定“组内计算”，类似 group by，但不折叠行。

2、ORDER BY：决定组内顺序，没有顺序就没有“前后/排名/累计”。

3、帧（FRAME）：决定“当前行的可见范围”。很多坑都来自默认帧。

窗口帧边界主要如下（按照起点到终点写）：

边界写法	含义
`UNBOUNDED PRECEDING`	分区内最前面
`n PRECEDING`	当前行前面第 n 行，或当前排序值前 n 个范围
`CURRENT ROW`	当前行，或当前排序值所在 peer group
`n FOLLOWING`	当前行后面第 n 行，或当前排序值后 n 个范围
`UNBOUNDED FOLLOWING`	分区内最后面

注意：起点不能晚于终点。 （可以得出合法的组合为4 + 4 + 3 + 2 = 13种）

ROWS 下，n PRECEDING / n FOLLOWING 按物理行数算。
RANGE 下，n PRECEDING / n FOLLOWING 按 ORDER BY 值的范围算。
不指定时表示从起点到当前行

其中工程中最常见的是这些：

场景	写法	含义
累计到当前行	`ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW`	从分区第一行累加到当前行
整个分区总和	`ROWS BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING`	当前分区所有行
最近 N 行滑动窗口	`ROWS BETWEEN N PRECEDING AND CURRENT ROW`	当前行和前 N 行
前后窗口	`ROWS BETWEEN N PRECEDING AND M FOLLOWING`	当前行前 N 行到后 M 行
只看当前行	`ROWS BETWEEN CURRENT ROW AND CURRENT ROW`	当前行本身
当前行到未来	`ROWS BETWEEN CURRENT ROW AND UNBOUNDED FOLLOWING`	当前行到分区最后

准备测试FRAME的数据源，来分别测试验证下效果

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


drop table if exists test_table;

create table test_table(
emp string,
amount int
)
row format delimited fields terminated by '\t'
stored as textfile;

INSERT INTO test_table VALUES
('A',100),
('B',100),
('C',80),
('D',60);

select * from test_table;

emp	amount
A	100
B	100
C	80
D	60

ROWS BETWEEN 2 PRECEDING AND CURRENT ROW 对每一行，计算“当前行 + 前面 2 行”的 amount 总和

1
2
3
4


SUM(amount) OVER (
 ORDER BY amount DESC
 ROWS BETWEEN 2 PRECEDING AND CURRENT ROW
);

emp	amount
A	100（前面没有数据，所以结果为A的amount）
B	200（前2行数据只有100，所以结果为100+100）
C	280（前2行数据为100+100，所以结果为100+100+80）
D	240（前2行数据为100+80，所以结果为100+80+60）

ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW：按“行数”算，对每一行，计算“从分区第一行开始+到当前行”的 amount 总和

1
2
3
4
5


select 
 SUM(amount) OVER (
 ORDER BY amount DESC
 ROWS between UNBOUNDED PRECEDING AND CURRENT ROW
) from test_table;

没有标记Partition，所以整体为一个分区

emp	amount
A	100（前面没有数据，所以结果为A的amount）
B	200（分区第一行到当前行的数据为:100,100，所以结果为100+100）
C	280（分区第一行到当前行的数据为:100,100,80，所以结果为100+100+80）
D	340（分区第一行到当前行的数据为:100,100,80,60，所以结果为100+100+80+60）

RANGE BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW，按“排序值范围”算，对每一行，计算amount在 ORDER BY 定义的排序方向里，从“排序后的最前面”一直到“当前排序值所在的同值组”为止

1
2
3
4
5


select 
 SUM(amount) OVER (
 ORDER BY amount DESC
 RANGE BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW
) from test_table;

没有标记Partition，所以整体为一个分区；按照 ORDER BY amount DESC，分区内先按照amount倒序排序（数据源本身就是按照amount倒序的：100 100 80 60）。对于第一行来说，其amount=100，RANGE看的是当前行的 ORDER BY 排序值。对于两个 amount = 100 的行，它们是同一个排序值。所以 RANGE 会把它们一起圈进来，因此两个 100 的结果都是 100+100=200

emp	amount
A	200（对于两个 amount = 100 的行，它们是同一个排序值，所以结果为100+100）
B	200（从排序开头到当前值的可见范围：所有 amount = 100 的行，所以结果为100+100）
C	280（从排序开头到当前值的可见范围为:100,100,80，所以结果为100+100+80）
D	340（从排序开头到当前值的可见范围为:100,100,80,60，所以结果为100+100+80+60）

重要坑：

聚合型窗口函数（SUM/AVG/COUNT/MAX/MIN）如果写了 ORDER BY，很多引擎（Hive 也常见）默认帧是 RANGE BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW（“从开头到当前值范围”）——对有重复排序值时会影响结果。工程上更稳的是显式写 ROWS BETWEEN ...。

LAST_VALUE 默认只看到“到当前行”为止，所以经常拿不到“分区最后一行”，需要 ... BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING。

四、序号函数（给行编号/排名）

ROW_NUMBER, RANK, DENSE_RANK, NTILE

我们统一用：每个部门按 amount 降序、dt 升序 排序（金额相同按日期先后打散）。

4.1 ROW_NUMBER：严格递增的行号（不管并列）

示例 SQL

1
2
3
4
5
6
7
8


SELECT
 dept, emp, dt, amount,
 ROW_NUMBER() OVER (
 PARTITION BY dept
 ORDER BY amount DESC, dt ASC, emp ASC
 ) AS rn
FROM sales
ORDER BY dept, rn;

输出结果示例（dept=‘A’）

dept	emp	dt	amount	rn
A	bob	2026-05-01	120	1
A	alice	2026-05-02	120	2
A	cindy	2026-05-02	120	3
A	alice	2026-05-01	100	4
A	bob	2026-05-03	80	5

原理分析

逻辑：分区（dept）内排序后，从 1 开始逐行加 1；并列不会共享名次。
执行：Hive 会把同一 dept 的数据拉到一起（通常需要 shuffle），并在 reducer 端按 ORDER BY 排序，然后流式输出行号。
常用场景：取 TopN（配合 WHERE rn <= N），去重（选择 rn=1 的那条）。

4.2 RANK：并列共享排名，名次会“跳号”

示例 SQL

1
2
3
4
5
6
7
8
9


SELECT
 dept, emp, dt, amount,
 RANK() OVER (
 PARTITION BY dept
 ORDER BY amount DESC
 ) AS rnk
FROM sales
WHERE dept='A'
ORDER BY amount DESC, dt ASC, emp ASC;

输出结果示例（dept=‘A’）

A 部门金额有三个 120 并列：

dept	emp	dt	amount	rnk
A	alice	2026-05-02	120	1
A	bob	2026-05-01	120	1
A	cindy	2026-05-02	120	1
A	alice	2026-05-01	100	4
A	bob	2026-05-03	80	5

原理分析

逻辑：同分（同排序键）共享排名；后面名次 = 前面行数 + 1，所以会出现 1,1,1,4…（跳过 2,3）。
注意：ORDER BY amount DESC 时，只有 amount 作为并列判定。若你想把 dt 也纳入并列判定，就写 ORDER BY amount DESC, dt ASC ...。

4.3 DENSE_RANK：并列共享排名，但不跳号

示例 SQL

1
2
3
4
5
6
7
8
9


SELECT
 dept, emp, dt, amount,
 DENSE_RANK() OVER (
 PARTITION BY dept
 ORDER BY amount DESC
 ) AS drnk
FROM sales
WHERE dept='A'
ORDER BY amount DESC, dt ASC, emp ASC;

输出结果示例（dept=‘A’）

dept	emp	dt	amount	drnk
A	alice	2026-05-02	120	1
A	bob	2026-05-01	120	1
A	cindy	2026-05-02	120	1
A	alice	2026-05-01	100	2
A	bob	2026-05-03	80	3

原理分析

逻辑：排名只跟“不同值的个数”有关：120 是第 1 档、100 第 2 档、80 第 3 档。
场景：按“分档/层级”分析更合适（例如薪资等级、评分等级）。

4.4 NTILE：把排序后的数据切成 N 份（分桶/分位组）

示例 SQL（每部门分成 4 份）

1
2
3
4
5
6
7
8


SELECT
 dept, emp, dt, amount,
 NTILE(4) OVER (
 PARTITION BY dept
 ORDER BY amount DESC, dt ASC
 ) AS bucket
FROM sales
ORDER BY dept, bucket, amount DESC, dt ASC;

输出结果示例（直观理解）

A 部门 5 行数据 → 分 4 份：前 1 份可能 2 行，其余各 1 行（尽量均匀）。
B 部门 5 行同理。

dept	emp	dt	amount	bucket
A	alice	2026-05-02	120	1
A	bob	2026-05-01	120	1
A	cindy	2026-05-02	120	2
A	alice	2026-05-01	100	3
A	bob	2026-05-03	80	4

原理分析

逻辑：排序后按行号切片：第 1 组 ≈ 前 25%，第 2 组 ≈ 25%~50%…（行数不能整除就前面的桶多 1 行）。
场景：用户分层（Top 25%/中间/尾部）、绩效分位、风险分层。

五、分布函数（看数据分布）

CUME_DIST, PERCENT_RANK

这类函数的核心是：把“排名”转换为 0~1 的比例，用来做分位/分布分析。

5.1 CUME_DIST：累计分布（<= 当前值的占比）

示例 SQL（部门内按金额升序看“有多少比例不超过我”）

1
2
3
4
5
6
7
8
9


SELECT
 dept, emp, dt, amount,
 CUME_DIST() OVER (
 PARTITION BY dept
 ORDER BY amount ASC
 ) AS cd
FROM sales
WHERE dept='A'
ORDER BY amount ASC, dt ASC, emp ASC;

输出结果示例（dept=‘A’，金额升序：80,100,120,120,120）

dept	emp	dt	amount	cd	解释
A	bob	2026-05-03	80	0.2	<=80 的有 1/5
A	alice	2026-05-01	100	0.4	<=100 的有 2/5
A	bob	2026-05-01	120	1.0	<=120 的有 5/5
A	alice	2026-05-02	120	1.0	<=120 的有 5/5
A	cindy	2026-05-02	120	1.0	<=120 的有 5/5

原理分析

公式（直观）：CUME_DIST = (分区内 <= 当前排序值的行数) / (分区总行数)
并列处理：同一个值的所有行，<= 当前值 都一样，所以 cd 相同。
场景：看某个金额处于分区的“累计比例”，比如“这条记录已经超过了 40% 的低值”。

5.2 PERCENT_RANK：百分比排名（基于 rank 的 0~1）

示例 SQL（金额升序）

1
2
3
4
5
6
7
8
9


SELECT
 dept, emp, dt, amount,
 PERCENT_RANK() OVER (
 PARTITION BY dept
 ORDER BY amount ASC
 ) AS pr
FROM sales
WHERE dept='A'
ORDER BY amount ASC, dt ASC, emp ASC;

输出结果示例（dept=‘A’）

对金额升序：80 最小 → rank=1；120 最大（并列）→ rank=3（因为 80、100、120 三档）

dept	emp	dt	amount	pr(rank-1)/(n-1), n=5
A	bob	2026-05-03	80	0.0
A	alice	2026-05-01	100	0.25
A	bob	2026-05-01	120	0.5
A	alice	2026-05-02	120	0.5
A	cindy	2026-05-02	120	0.5

注意：这里的 rank 是带并列的 rank 概念，所以 pr 不一定到 1（尤其是大量并列时）。

原理分析

公式（直观）：PERCENT_RANK = (RANK - 1) / (分区总行数 - 1)
n=1 特殊：分区只有 1 行时通常返回 0。
场景：更偏向“排名位置的比例”，而不是“累计不超过我的比例”（那是 CUME_DIST）。

六、前后函数（看前一行/后一行）

LAG(expr,offset,default_value), LEAD(expr,offset,default_value)

第一个参数为列名，第二个参数为往上第n行（可选，默认为1），第三个参数为默认值（当往上第n行为NULL时候，取默认值，如不指定，则为NULL）

这俩的本质是：在同一分区、同一排序下，读取偏移行的字段值。

1
2
3
4
5
6
7
8
9


LAG(expr, offset, default_value) OVER (
 PARTITION BY ...
 ORDER BY ...
)

LEAD(expr, offset, default_value) OVER (
 PARTITION BY ...
 ORDER BY ...
)

参数	是否必填	含义
`expr`	必填	要取值的列或表达式
`offset`	可选	向前/向后偏移几行，默认是 `1`
`default_value`	可选	如果取不到对应行，返回什么值，默认是 `NULL`
`PARTITION BY`	可选	确定分区，每个分区内部单独排序、单独取上一行。
`ORDER BY`	可选	确定顺序，决定谁是上一行/下一行

6.1 LAG：取前n行（默认偏移 1）

我们用“员工维度的时间序列”最直观：同一个 emp 按 dt 排序，比较今天 vs 昨天。

示例 SQL（看每个员工相对上一天的变化——环比增长额）

增长额 = 当前值 - 上一期值

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


SELECT
 emp, dt, amount,
 LAG(amount, 1, 0) OVER (
 PARTITION BY emp
 ORDER BY dt
 ) AS prev_amount,
 amount - LAG(amount, 1, 0) OVER (
 PARTITION BY emp
 ORDER BY dt
 ) AS diff_from_prev
FROM sales
WHERE emp IN ('alice','david')
ORDER BY emp, dt;

输出结果示例（alice 与 david）

emp	dt	amount	prev_amount	diff_from_prev
alice	2026-05-01	100	0	100
alice	2026-05-02	120	100	20
david	2026-05-01	90	0	90
david	2026-05-02	90	90	0

原理分析

LAG(amount, 1, 0) OVER (PARTITION BY emp ORDER BY dt) 以emp为分组条件，组内按照 dt 排序，取分组内当前行前 1 行的 amount。

如果没有前 1 行，则返回 0。
典型用途：环比/同比、差分、趋势检测、缺失填充（配合 COALESCE）。

应用

计算环比增长率

增长率 = (当前值 - 上一期值) / 上一期值即 growth_rate = (amount - prev_amount) / prev_amount

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


SELECT
 emp,
 dt,
 amount,
 prev_amount,
 CASE
 WHEN prev_amount IS NULL OR prev_amount = 0 THEN NULL
 ELSE (amount - prev_amount) / prev_amount
 END AS growth_rate
FROM (
 SELECT
 emp,
 dt,
 amount,
 LAG(amount) OVER (
 PARTITION BY emp
 ORDER BY dt
 ) AS prev_amount
 FROM sales
 WHERE emp IN ('alice','david')
) t;

结果：

emp	dt	amount	prev_amount	growth_rate
alice	2026-05-01	100
alice	2026-05-02	120	100	0.2
david	2026-05-01	90
david	2026-05-02	90	90	0.0

6.2 LEAD：取后n行

示例 SQL（看下一天金额）

1
2
3
4
5
6
7
8
9


SELECT
 emp, dt, amount,
 LEAD(amount, 1, NULL) OVER (
 PARTITION BY emp
 ORDER BY dt
 ) AS next_amount
FROM sales
WHERE emp IN ('alice','eric')
ORDER BY emp, dt;

输出结果示例

emp	dt	amount	next_amount
alice	2026-05-01	100	120
alice	2026-05-02	120	NULL
eric	2026-05-01	200	50
eric	2026-05-03	50	NULL

原理分析

LEAD 与 LAG 对称：向下取偏移行。
常用：找“下一次事件”、计算持续时间（next_dt - dt）、区间拼接。

七、头尾函数（看窗口首尾值）

FIRST_VALUE, LAST_VALUE

取分组内排序后，截至到当前行的第一个值

这俩强依赖窗口帧（FRAME），尤其是 LAST_VALUE，很多人第一次用都会踩坑。

7.1 FIRST_VALUE：窗口内第一行的值

示例 SQL（每部门按金额降序，取“当前窗口看到的第一名金额”）

1
2
3
4
5
6
7
8
9


SELECT
 dept, emp, dt, amount,
 FIRST_VALUE(amount) OVER (
 PARTITION BY dept
 ORDER BY amount DESC, dt ASC
 ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW
 ) AS first_amt_so_far
FROM sales
ORDER BY dept, amount DESC, dt ASC, emp ASC;

输出结果示例（dept=‘A’）

排序后第一行是 120，因此后续行的 first_amt_so_far 都是 120：、

dept	emp	dt	amount	first_amt_so_far
A	bob	2026-05-01	120	120
A	alice	2026-05-02	120	120
A	cindy	2026-05-02	120	120
A	alice	2026-05-01	100	120
A	bob	2026-05-03	80	120
B	eric	2026-05-01	200	200
B	frank	2026-05-02	200	200
B	david	2026-05-01	90	200
B	david	2026-05-02	90	200
B	eric	2026-05-03	50	200

原理分析

按照dept分为A、B两组，组内按照amount倒序，窗口frame为分组开始到当前行
FIRST_VALUE 在给定 frame 内取“第一行”的表达式值，A组最大的amount为120，所以从第1行开始 FIRST_VALUE的值就为120
当 frame 是“从开头到当前行”，它等价于“到目前为止的最大值对应的金额”（在按金额降序时）。

7.2 LAST_VALUE：窗口内最后一行的值（默认常踩坑）

坑示范（默认到 CURRENT ROW，last_value 往往等于当前行）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


SELECT
 dept, emp, dt, amount,
 LAST_VALUE(amount) OVER (
 PARTITION BY dept
 ORDER BY amount DESC, dt ASC
 ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW
 ) AS last_amt_so_far
FROM sales
WHERE dept='A'
ORDER BY amount DESC, dt ASC, emp ASC;

输出直觉：到当前行为止的“最后值”通常就是当前行的 amount（因为 last 就是 frame 的末端=当前行）。

dept	emp	dt	amount	last_amt_so_far
A	bob	2026-05-01	120	120
A	alice	2026-05-02	120	120
A	cindy	2026-05-02	120	120
A	alice	2026-05-01	100	100
A	bob	2026-05-03	80	80

正确拿“分区最后一行”的写法（UNBOUNDED FOLLOWING）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


SELECT
 dept, emp, dt, amount,
 LAST_VALUE(amount) OVER (
 PARTITION BY dept
 ORDER BY amount DESC, dt ASC
 ROWS BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING
 ) AS last_amt_in_partition
FROM sales
WHERE dept='A'
ORDER BY amount DESC, dt ASC, emp ASC;

输出：A 分区的最后一行（按金额降序）是 80，所以每行都是 80：

dept	emp	dt	amount	last_amt_in_partition
A	bob	2026-05-01	120	80
A	alice	2026-05-02	120	80
A	cindy	2026-05-02	120	80
A	alice	2026-05-01	100	80
A	bob	2026-05-03	80	80

原理分析

LAST_VALUE 取的是 frame 内最后一行，frame 若截止当前行，那 last 就是当前行。
想要“分区最后一行”，frame 必须覆盖整个分区：... AND UNBOUNDED FOLLOWING。

八、聚合函数（窗口版：在窗口内做统计）

SUM, AVG, COUNT, MAX/MIN over(…)

窗口聚合跟 group by 的最大区别：

group by：一组变一行（折叠）。
window agg：每行都保留，只是附加一列“该行所在窗口的聚合结果”。

8.1 分区总和（不写 ORDER BY → 默认整个分区）

示例 SQL：每部门总销售额

1
2
3
4
5


SELECT
 dept, emp, dt, amount,
 SUM(amount) OVER (PARTITION BY dept) AS dept_sum
FROM sales
ORDER BY dept, emp, dt;

输出结果示例（只看 dept_sum）

540 = (100+120+120+80+120)

630 = (90+90+200+50+200)

dept	emp	dt	amount	dept_sum
A	alice	2026-05-01	100	540
A	alice	2026-05-02	120	540
A	bob	2026-05-01	120	540
A	bob	2026-05-03	80	540
A	cindy	2026-05-02	120	540
B	david	2026-05-01	90	630
B	david	2026-05-02	90	630
B	eric	2026-05-01	200	630
B	eric	2026-05-03	50	630
B	frank	2026-05-02	200	630

原理分析

没有 ORDER BY 时，frame 等价于整个分区，sum 对分区内所有行求和。
执行上仍可能需要按 dept 分区聚合，但会把结果广播/附加回每一行。

8.2 累计和（Running Sum）：从开头累加到当前行（显式 ROWS 更稳）

示例 SQL：部门内按日期累计

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


SELECT
 dept, emp, dt, amount,
 SUM(amount) OVER (
 PARTITION BY dept
 ORDER BY dt ASC, emp ASC
 ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW
 ) AS running_sum
FROM sales
WHERE dept='A'
ORDER BY dt ASC, emp ASC;

输出结果示例（dept=‘A’）

A 的数据按 dt、emp 排序后做累计：

dt	emp	amount	running_sum
2026-05-01	alice	100	100
2026-05-01	bob	120	220
2026-05-02	alice	120	340
2026-05-02	cindy	120	460
2026-05-03	bob	80	540

原理分析（为什么强调 ROWS）

如果你用默认 RANGE ... CURRENT ROW，当 ORDER BY dt 且 dt 有重复值时，“当前行”可能会把同 dt 的其他行都算进去，导致“看起来跳一下”。
用 ROWS 表示“按行数”，严格按排序后的物理顺序累计，更符合工程直觉。

易错点

窗口函数里的 ORDER BY 决定 SUM 的累计计算顺序；外层 ORDER BY 只决定最终结果展示顺序

也就是说：

窗口内 ORDER BY：决定 SUM(...) OVER (...) 的计算顺序。
外层 ORDER BY：只决定最终结果怎么展示。
外层排序不会重新计算窗口函数，也不会重新分配 dept_sum。

先举两个例子，理解一下窗口函数内的ORDER BY

外层 ORDER BY 和窗口内 ORDER BY 不一致时，窗口函数仍然按照窗口内顺序正确计算，并把结果绑定到对应原始行；

但最终展示时按另一个顺序排列，所以结果看起来不像按当前展示顺序累计。

8.3 移动平均（Moving Average）：最近 N 行

示例 SQL：最近 3 行的平均销售额

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


SELECT
 dept, emp, dt, amount,
 AVG(amount) OVER (
 PARTITION BY dept
 ORDER BY dt ASC, emp ASC
 ROWS BETWEEN 2 PRECEDING AND CURRENT ROW
 ) AS ma_3
FROM sales
WHERE dept='A'
ORDER BY dt ASC, emp ASC;

输出结果示例（dept=‘A’）

dt	emp	amount	ma_3（最近3行均值）
2026-05-01	alice	100	100.0
2026-05-01	bob	120	110.0
2026-05-02	alice	120	113.33
2026-05-02	cindy	120	120.0
2026-05-03	bob	80	106.67

原理分析

frame 设为 2 PRECEDING AND CURRENT ROW，表示窗口最多包含 3 行：当前行 + 前两行。
常用于：移动平均、平滑指标、滑动窗口监控（比如延迟、QPS）。

8.4 COUNT / MAX / MIN 的窗口用法（举一组典型）

示例 SQL：部门内记录数、最大/最小金额

1
2
3
4
5
6
7


SELECT
 dept, emp, dt, amount,
 COUNT(*) OVER (PARTITION BY dept) AS dept_cnt,
 MAX(amount) OVER (PARTITION BY dept) AS dept_max,
 MIN(amount) OVER (PARTITION BY dept) AS dept_min
FROM sales
ORDER BY dept, emp, dt;

输出结果示例（只看聚合列）

dept	dept_cnt	dept_max	dept_min
A	5	120	80
B	5	200	50

原理分析

SUM 一样：无 ORDER BY → 全分区统计；有 ORDER BY → 可做“到当前”的 max/min/count（配合 frame）。

九、其他分析函数

GROUPING SETS，ROLLUP，CUBE，GROUPING__ID这 4 个概念都是 SQL 多维聚合分析 里的东西，常用于数仓报表、OLAP 分析、离线统计。

一句话概括：

GROUPING SETS 是“手动指定多种分组方式”；
ROLLUP 是“按层级逐级汇总”；
CUBE 是“所有维度组合都汇总”；
GROUPING__ID 是“标识当前这一行是哪种汇总层级”。

9.1 数据源

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


CREATE TABLE sales_location (
 dt STRING,
 province STRING,
 city STRING,
 amount BIGINT
);

-- 插入示例数据到sales_location表
INSERT INTO TABLE sales_location VALUES
('2024-01', 'Sichuan', 'Chengdu', 100),
('2024-01', 'Sichuan', 'Mianyang', 80),
('2024-01', 'Zhejiang', 'Hangzhou', 120),
('2024-02', 'Sichuan', 'Chengdu', 200),
('2024-02', 'Zhejiang', 'Hangzhou', 150);

9.2 为什么需要

普通分组

1
2
3
4
5
6


SELECT
 province,
 city,
 SUM(amount) AS total_amount
FROM sales_location
GROUP BY province, city;

结果只做了一个粒度（省份+城市）的聚合

province	city	total_amount
Sichuan	Chengdu	300
Sichuan	Mianyang	80
Zhejiang	Hangzhou	270

但报表经常需要多多种粒度：省份 + 城市、省份、城市、全局总计。这时候就需要GROUPING SETS，ROLLUP，CUBE

9.3 GROUPING SETS 指定分组粒度

一次 SQL 中，同时执行多个 GROUP BY，最后把结果合并在一起。

语法：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


SELECT
 col1,
 col2,
 SUM(metric)
FROM table_name
GROUP BY GROUPING SETS (
 (col1, col2), -- 按col1, col2聚合
 (col1), -- 按col1聚合
 (col2), -- 按col2聚合
 () -- 全局总计
);

示例 SQL

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


SELECT
 province,
 city,
 SUM(amount) AS total_amount
FROM sales
GROUP BY GROUPING SETS (
 (province, city),
 (province),
 (city),
 ()
);

province	city	total_amount
Sichuan	Chengdu	300
Sichuan	Mianyang	80
Sichuan	NULL	380
Zhejiang	Hangzhou	270
Zhejiang	NULL	270
NULL	Chengdu	300
NULL	Hangzhou	270
NULL	Mianyang	80
NULL	NULL	650

逻辑上等价于下面 4 个 SQL 的 UNION ALL：

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


-- 1. 省份+城市级别
SELECT '省份+城市' as level, province, city, SUM(amount) AS total_amount
FROM sales_location
GROUP BY province, city;
UNION
-- 2. 仅省份级别
SELECT '仅省份' as level, province, NULL as city, SUM(amount) AS total_amount
FROM sales_location
GROUP BY province;
UNION
-- 3. 仅城市级别
SELECT '仅城市' as level, NULL as province, city, SUM(amount) AS total_amount
FROM sales_location
GROUP BY city;
UNION
-- 4. 总计
SELECT '总计' as level, NULL as province, NULL as city, SUM(amount) AS total_amount
FROM sales_location;

这里的 NULL 有特殊含义：

province = NULL, city = NULL：全局总计
city = NULL：按省份汇总
province = NULL：按城市汇总

注意：这里的 NULL 不一定是真实数据里的 NULL，它也可能表示“这个维度被聚合掉了”。

9.4 ROLLUP 按层级逐级汇总

ROLLUP 适合处理有层级关系的维度。比如省份 -> 城市、日期 -> 月 -> 日、国家 -> 省份 -> 城市、品类 -> 子品类 -> 商品

语法

1

GROUP BY ROLLUP(col1, col2, col3)

它会生成这些分组，从右往左逐级去掉维度。ROLLUP 是有顺序、有层级的。

1
2
3
4


(col1, col2, col3)
(col1, col2)
(col1)
()

示例：

1
2
3
4
5
6


SELECT
 province,
 city,
 SUM(amount) AS total_amount
FROM sales
GROUP BY ROLLUP(province, city);

等价于

1
2
3
4
5


GROUPING SETS (
 (province, city), -- 按 province + city 聚合
 (province), --按 province 聚合
 () -- 全局总计
)

province	city	total_amount
Sichuan	Chengdu	300
Sichuan	Mianyang	80
Sichuan	NULL	380
Zhejiang	Hangzhou	270
Zhejiang	NULL	270
NULL	NULL	650

9.5 CUBE 所有维度都汇总

对指定的所有维度，生成所有可能的分组组合。如果有 n 个维度，CUBE 会生成 2^n 个分组组合

1

GROUP BY CUBE(col1, col2, col3)

统计维度

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


GROUPING SETS (
 (col1, col2, col3),
 (col1, col2),
 (col1, col3),
 (col2, col3),
 (col1),
 (col2),
 (col3),
 ()
)

示例：

1
2
3
4
5
6


SELECT
 province,
 city,
 SUM(amount) AS total_amount
FROM sales
GROUP BY CUBE(province, city);

等价于

1
2
3
4
5
6


GROUPING SETS (
 (province, city), -- province + city
 (province), -- province
 (city), -- city
 () -- 全局总计
)

province	city	total_amount
Sichuan	Chengdu	300
Sichuan	Mianyang	80
Sichuan	NULL	380
Zhejiang	Hangzhou	270
Zhejiang	NULL	270
NULL	Chengdu	300
NULL	Hangzhou	270
NULL	Mianyang	80
NULL	NULL	650

如果维度数量很多，比如 10 个维度会产生 2^10 = 1024 种分组组合，每种分组还会产生大量聚合结果，所以在大数据场景里要谨慎使用。

9.6 GROUPING_ID 判断当前行属于哪种汇总层级

1）为什么需要GROUPING_ID

前面我们看到，ROLLUP、CUBE、GROUPING SETS 会产生很多 NULL。问题来了：

这里的 NULL 到底是真实数据里的 NULL？
还是因为这个维度被聚合掉了？

比如：province = NULL、city = Chengdu；这时候你就很难区分：真实 NULL和聚合产生的 NULL

所以需要 GROUPING__ID 来标识当前行的聚合层级。

2）示例

1
2
3
4
5
6
7


SELECT
 province,
 city,
 SUM(amount) AS total_amount,
 GROUPING__ID
FROM sales
GROUP BY CUBE(province, city);

province	city	total_amount	grouping__id
Sichuan	Chengdu	300	0
Sichuan	Mianyang	80	0
Sichuan	NULL	380	1
Zhejiang	Hangzhou	270	0
Zhejiang	NULL	270	1
NULL	Chengdu	300	2
NULL	Hangzhou	270	2
NULL	Mianyang	80	2
NULL	NULL	650	3

3）GROUPING__ID列怎么看

把每个字段看成一个 bit 位

如果某个字段还在参与分组，bit 位值为 0
如果某个字段被聚合掉了，bit 位值为 1

1
2


province city
 bit bit

它们对应关系可以理解为：

分组方式	province 是否聚合掉	city 是否聚合掉	二进制理解	十进制值	含义
`(province, city)`	否	否	`00`	0	明细层级
`(province)`	否	是	`01`	1	省份汇总
`(city)`	是	否	`10`	2	城市汇总
`()`	是	是	`11`	3	全局总计

4）CASE WHEN 做层级标记

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


SELECT
 province,
 city,
 SUM(amount) AS total_amount,
 GROUPING__ID AS grouping_id,
 CASE GROUPING__ID
 WHEN 0 THEN 'province_city_detail'
 WHEN 1 THEN 'province_subtotal'
 WHEN 2 THEN 'city_subtotal'
 WHEN 3 THEN 'grand_total'
 END AS aggregation_level
FROM sales
GROUP BY CUBE(province, city);

province	city	total_amount	grouping_id	aggregation_level
Sichuan	Chengdu	300	0	province_city_detail
Sichuan	Mianyang	80	0	province_city_detail
Sichuan	NULL	380	1	province_subtotal
Zhejiang	Hangzhou	270	0	province_city_detail
Zhejiang	NULL	270	1	province_subtotal
NULL	Chengdu	300	2	city_subtotal
NULL	Hangzhou	270	2	city_subtotal
NULL	Mianyang	80	2	city_subtotal
NULL	NULL	650	3	grand_total

5）总结对比

功能	含义	生成组合	是否有层级	适合场景
`GROUPING SETS`	手动指定分组组合	你写几个就生成几个	不一定	精确控制需要哪些汇总
`ROLLUP`	按层级逐级汇总	`n + 1` 个	有	年/月/日、省/市/区、品类/商品
`CUBE`	所有维度组合汇总	`2^n` 个	无	多维 OLAP 探索分析
`GROUPING__ID`	标识聚合层级	不生成分组，只辅助判断	不涉及	区分明细、小计、总计

十、总结：窗口函数的“本质执行模型”

把窗口函数当成一个“流水线”会更容易理解：

分区（PARTITION BY）：把数据逻辑分组（通常意味着 shuffle 把同组拉到一起）。
排序（ORDER BY）：在每个分区内部排序（通常在 reducer 端完成排序）。
确定窗口帧（ROWS/RANGE）：对每一行确定它能“看见”的行集合。
逐行计算函数：
- 排名类（row_number/rank/dense_rank）：只依赖排序位置和是否并列。
- 偏移类（lag/lead）：按相对位置取值。
- 帧聚合类（sum/avg/count/max/min、first/last/nth）：对帧内行做统计或取值。

工程建议（非常实用）：

只要你写了 ORDER BY，并且希望“按行移动/累计”，就尽量显式写 ROWS BETWEEN ...，避免 RANGE 对重复排序值带来的“多算/跳变”。
LAST_VALUE 想取全分区末尾，必须写到 UNBOUNDED FOLLOWING。
TopN：优先 ROW_NUMBER（唯一）或 DENSE_RANK（按档）而不是 RANK（会跳号，筛选 TopN 时容易“多/少”）。

Windows 使用 Docker Compose 搭建 Hive 4.1.0 + MySQL 持久化环境

Mon, 01 Jun 2026 22:12:03 +0800

Windows 使用 Docker Compose 搭建 Hive 4.1.0 + MySQL 持久化环境

这篇笔记记录一套适合本地学习的 Hive 环境：在 Windows 本机通过 Docker Compose 一次性启动 HiveServer2 + Hive Metastore + MySQL Metastore DB，并支持 Beeline 和 DBeaver 连接。

目标不是搭建生产级 Hadoop 集群，而是为了学习：

Hive SQL
database、table、partition、insert、join、group by、窗口函数
ODS、DWD、DWS、ADS 离线数仓分层
Hive 元数据、表数据和持久化的基本关系

1. 为什么用 Docker 而不是 VMware

使用 VMware 从零创建虚拟机，需要自己安装 Linux、Java、Hadoop、Hive、MySQL，并处理大量环境变量、网络、权限和服务启动顺序。这个过程更接近完整集群搭建，适合学习 Hadoop 运维，但对刚开始学习 Hive SQL 来说成本偏高。

Docker 更适合当前阶段：

方式	优点	缺点	适合场景
VMware 虚拟机	更接近真实 Linux 服务器；可完整体验 Hadoop/Hive 安装过程	配置步骤多；占用资源较大；排错成本高	学习集群安装、Linux 运维、生产环境结构
Docker Compose	一条命令启动多个服务；环境可删除重建；配置集中在 `docker-compose.yml`	不等于真实生产集群；部分底层细节被镜像封装	本地快速学习 Hive SQL、Metastore、数仓分层

所以这里选择 Docker Compose：先把 Hive 跑起来，尽快进入 SQL 和数仓建模练习。

2. 为什么使用 HiveServer2 + Metastore + MySQL

Hive 的核心可以拆成三部分：

组件	本文容器名	作用
HiveServer2	`hive4`	对外提供 JDBC/Beeline/DBeaver 查询入口
Hive Metastore	`hive-metastore`	管理 Hive 元数据，例如库、表、字段、分区、表数据位置
MySQL Metastore DB	`hive-mysql`	持久化保存 Metastore 元数据

这套结构比单容器 Hive 更稳定，也更接近真实使用方式。

方案	元数据保存位置	表数据保存位置	特点
单容器 Hive + 内置 Derby	容器内部 Derby	容器或 volume 中的 warehouse	最简单，但删除容器后元数据容易丢失
HiveServer2 + Metastore + MySQL	MySQL volume	warehouse volume	元数据和表数据都能持久化，适合长期学习

本文采用：

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


Windows / DBeaver / Beeline
 |
 | jdbc:hive2://localhost:10000
 v
HiveServer2 容器 hive4
 |
 | thrift://hive-metastore:9083
 v
Hive Metastore 容器 hive-metastore
 |
 | jdbc:mysql://mysql:3306/hive_metastore
 v
MySQL 容器 hive-mysql

持久化分两部分：

持久化对象	Docker volume	容器内路径	保存内容
MySQL 元数据	`mysql-data`	`/var/lib/mysql`	Hive 的库、表、字段、分区等元数据
Hive 表数据	`warehouse-data`	`/opt/hive/data/warehouse`	Hive managed table 的实际数据文件

3. 初始准备

需要先安装并启动：

Docker Desktop for Windows
DBeaver，可选，但推荐用于图形化连接 Hive
PowerShell 或 CMD

检查 Docker 是否可用：

1
2


docker --version
docker compose version

如果能看到版本号，说明 Docker 和 Compose 可用。

4. 创建 Compose 项目目录

建议单独建一个目录保存 Docker Compose 配置和 JDBC 驱动：

1
2


mkdir C:\Users\v-liuyuhang\source\repos\MyPro\docker-hive4
cd C:\Users\v-liuyuhang\source\repos\MyPro\docker-hive4

最终目录结构：

1
2
3


docker-hive4
├── docker-compose.yml
└── mysql-connector-j-8.4.0.jar

为什么要单独建目录：Docker Compose 默认读取当前目录下的 docker-compose.yml，并以当前目录作为一个独立项目来创建容器、网络和 volume。

5. 下载 MySQL JDBC Driver

Hive Metastore 是 Java 程序，连接 MySQL 需要 MySQL JDBC Driver。否则容易出现：

1
2


ClassNotFoundException: com.mysql.cj.jdbc.Driver
No suitable driver found for jdbc:mysql://...

在 Compose 项目目录中执行：

1
2
3


Invoke-WebRequest `
 -Uri "https://repo1.maven.org/maven2/com/mysql/mysql-connector-j/8.4.0/mysql-connector-j-8.4.0.jar" `
 -OutFile "mysql-connector-j-8.4.0.jar"

下载完成后检查文件：

1

dir

应该能看到：

1
2


docker-compose.yml
mysql-connector-j-8.4.0.jar

如果此时还没创建 docker-compose.yml，只看到 jar 文件也正常。

6. 创建 docker-compose.yml

在 Compose 项目目录中创建文件：

1

notepad docker-compose.yml

写入下面内容：

 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


services:
 mysql:
 image: mysql:8.4
 container_name: hive-mysql
 restart: unless-stopped
 environment:
 MYSQL_ROOT_PASSWORD: root
 MYSQL_DATABASE: hive_metastore
 MYSQL_USER: hive
 MYSQL_PASSWORD: hive
 ports:
 - "3307:3306"
 volumes:
 - mysql-data:/var/lib/mysql
 command:
 --character-set-server=utf8mb4
 --collation-server=utf8mb4_unicode_ci
 healthcheck:
 test: ["CMD-SHELL", "mysqladmin ping -h localhost -uroot -proot || exit 1"]
 interval: 10s
 timeout: 5s
 retries: 20

 hive-metastore:
 image: apache/hive:4.1.0
 container_name: hive-metastore
 restart: unless-stopped
 depends_on:
 mysql:
 condition: service_healthy
 environment:
 SERVICE_NAME: metastore
 DB_DRIVER: mysql
 SERVICE_OPTS: >
 -Djavax.jdo.option.ConnectionDriverName=com.mysql.cj.jdbc.Driver
 -Djavax.jdo.option.ConnectionURL=jdbc:mysql://mysql:3306/hive_metastore?createDatabaseIfNotExist=true&useSSL=false&allowPublicKeyRetrieval=true&serverTimezone=UTC
 -Djavax.jdo.option.ConnectionUserName=hive
 -Djavax.jdo.option.ConnectionPassword=hive
 -Dhive.metastore.warehouse.dir=/opt/hive/data/warehouse
 ports:
 - "9083:9083"
 volumes:
 - warehouse-data:/opt/hive/data/warehouse
 - ./mysql-connector-j-8.4.0.jar:/opt/hive/lib/mysql-connector-j-8.4.0.jar

 hiveserver2:
 image: apache/hive:4.1.0
 container_name: hive4
 restart: unless-stopped
 depends_on:
 - hive-metastore
 environment:
 SERVICE_NAME: hiveserver2
 SERVICE_OPTS: >
 -Dhive.metastore.uris=thrift://hive-metastore:9083
 -Dhive.server2.thrift.bind.host=0.0.0.0
 -Dhive.server2.thrift.port=10000
 -Dhive.server2.webui.host=0.0.0.0
 -Dhive.server2.webui.port=10002
 ports:
 - "10000:10000"
 - "10002:10002"
 volumes:
 - warehouse-data:/opt/hive/data/warehouse
 - ./mysql-connector-j-8.4.0.jar:/opt/hive/lib/mysql-connector-j-8.4.0.jar

volumes:
 mysql-data:
 warehouse-data:

7. 配置文件关键点解释

7.1 MySQL 服务

1
2
3


mysql:
 image: mysql:8.4
 container_name: hive-mysql

作用：启动一个独立的 Docker MySQL，专门给 Hive Metastore 保存元数据。它不是 Windows 本机安装的 MySQL。

1
2
3
4
5


environment:
 MYSQL_ROOT_PASSWORD: root
 MYSQL_DATABASE: hive_metastore
 MYSQL_USER: hive
 MYSQL_PASSWORD: hive

作用：MySQL 首次初始化时自动创建数据库和用户。

配置	含义
`MYSQL_DATABASE: hive_metastore`	创建 Hive 元数据库
`MYSQL_USER: hive`	创建普通用户 `hive`
`MYSQL_PASSWORD: hive`	设置 `hive` 用户密码
`MYSQL_ROOT_PASSWORD: root`	设置 root 密码

1
2


ports:
 - "3307:3306"

含义：

访问方向	地址
Windows 访问 Docker MySQL	`localhost:3307`
Docker 容器内部访问 MySQL	`mysql:3306`

如果 Windows 本机已经有 MySQL 占用 3306，Docker MySQL 就不能再映射 3306:3306，所以这里使用 3307:3306。

1
2


volumes:
 - mysql-data:/var/lib/mysql

作用：持久化 MySQL 数据。Hive 的库、表、字段、分区等元数据最终会保存到这个 volume 中。

1
2


healthcheck:
 test: ["CMD-SHELL", "mysqladmin ping -h localhost -uroot -proot || exit 1"]

作用：确认 MySQL 服务真正可连接后，再让 Metastore 启动，避免 Metastore 抢跑导致连接失败。

7.2 Hive Metastore 服务

1
2
3


hive-metastore:
 image: apache/hive:4.1.0
 container_name: hive-metastore

作用：启动 Hive 元数据服务。Hive Metastore 负责管理：

有哪些 database
有哪些 table
表有哪些 column
表数据存放在哪里
表有哪些 partition

1
2


SERVICE_NAME: metastore
DB_DRIVER: mysql

作用：告诉 apache/hive:4.1.0 镜像当前容器启动 Metastore，并且 Metastore 后端数据库是 MySQL。

1

-Djavax.jdo.option.ConnectionURL=jdbc:mysql://mysql:3306/hive_metastore?createDatabaseIfNotExist=true&useSSL=false&allowPublicKeyRetrieval=true&serverTimezone=UTC

这里必须使用 mysql:3306，不能写 localhost:3307。

原因是 Metastore 和 MySQL 都在 Docker Compose 内部网络中，容器之间通过服务名通信：

写法	是否正确	原因
`jdbc:mysql://mysql:3306/hive_metastore`	正确	`mysql` 是 Compose 服务名，`3306` 是容器内部端口
`jdbc:mysql://localhost:3307/hive_metastore`	错误	在容器内 `localhost` 指向 Metastore 自己，不是 MySQL 容器
`jdbc:mysql://mysql:3307/hive_metastore`	错误	`3307` 是 Windows 宿主机端口，不是容器内部端口

1
2
3


volumes:
 - warehouse-data:/opt/hive/data/warehouse
 - ./mysql-connector-j-8.4.0.jar:/opt/hive/lib/mysql-connector-j-8.4.0.jar

作用：

warehouse-data 保存 Hive 表数据。
mysql-connector-j-8.4.0.jar 让 Metastore 能加载 MySQL JDBC Driver。

7.3 HiveServer2 服务

1
2
3


hiveserver2:
 image: apache/hive:4.1.0
 container_name: hive4

作用：启动 HiveServer2。DBeaver 和 Beeline 连接的就是这个服务。

1

SERVICE_NAME: hiveserver2

作用：告诉 Hive 镜像当前容器启动 HiveServer2，不是 Metastore。

1

-Dhive.metastore.uris=thrift://hive-metastore:9083

作用：告诉 HiveServer2 去哪里找 Metastore。HiveServer2 自己不直接保存表结构，它需要通过 Metastore 查询元数据。

1
2
3


ports:
 - "10000:10000"
 - "10002:10002"

端口说明：

端口	作用
`10000`	HiveServer2 JDBC / Beeline 查询端口
`10002`	HiveServer2 Web UI 端口

DBeaver 连接 Hive 时使用：

1

jdbc:hive2://localhost:10000/default

8. 第一次启动环境

在 docker-compose.yml 所在目录执行：

1

docker compose up -d

命令含义：

命令	作用
`docker compose`	使用 Docker Compose
`up`	创建并启动服务
`-d`	后台运行

查看容器状态：

1

docker ps

正常情况下应该看到 3 个容器：

1
2
3


hive-mysql
hive-metastore
hive4

端口重点看：

1
2
3
4


0.0.0.0:3307->3306/tcp
0.0.0.0:9083->9083/tcp
0.0.0.0:10000->10000/tcp
0.0.0.0:10002->10002/tcp

9. 自测环境是否成功

9.1 查看日志

如果容器没有正常运行，按依赖顺序看日志：

1
2
3


docker logs hive-mysql
docker logs hive-metastore
docker logs hive4

顺序很重要：MySQL 起不来，Metastore 大概率也起不来；Metastore 起不来，HiveServer2 大概率也不可用。

9.2 使用 Beeline 连接 Hive

进入 HiveServer2 容器：

1

docker exec -it hive4 bash

在容器内部连接 HiveServer2：

1

beeline -u jdbc:hive2://localhost:10000

进入后执行：

1

SHOW DATABASES;

能看到 default，说明 HiveServer2 基本可用。

退出 Beeline：

1

!quit

退出容器：

1

exit

9.3 创建测试库表

在 Beeline 中执行：

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


CREATE DATABASE IF NOT EXISTS ods;

USE ods;

CREATE TABLE IF NOT EXISTS test_user (
 id INT,
 name STRING
);

INSERT INTO test_user VALUES
(1, 'Alice'),
(2, 'Bob');

SELECT * FROM test_user;

如果能查询到数据，说明完整链路可用：

1
2
3
4
5


SQL 请求
 -> HiveServer2
 -> Hive Metastore
 -> MySQL 保存表结构等元数据
 -> warehouse-data 保存表数据

9.4 验证持久化

停止并删除容器，但保留 volume：

1
2


docker compose down
docker compose up -d

重新连接 Hive 后执行：

1
2


USE ods;
SELECT * FROM test_user;

如果表和数据还在，说明 MySQL 元数据和 Hive warehouse 数据都已经持久化。

10. DBeaver 连接方式

10.1 连接 Hive

在 DBeaver 中新建 Hive 连接：

1
2
3
4


Host: localhost
Port: 10000
Database: default
JDBC URL: jdbc:hive2://localhost:10000/default

用户名和密码可以先尝试：

1
2


Username: hive
Password: hive

如果连接失败，再尝试用户名密码留空。

连接成功后，可以直接在 DBeaver 中执行 Hive SQL：

1
2
3
4


CREATE DATABASE IF NOT EXISTS ods;
CREATE DATABASE IF NOT EXISTS dwd;
CREATE DATABASE IF NOT EXISTS dws;
CREATE DATABASE IF NOT EXISTS ads;

10.2 连接 MySQL 元数据库

如果想观察 Hive 元数据，可以在 DBeaver 中再创建一个 MySQL 连接：

1
2
3
4
5


Host: localhost
Port: 3307
Database: hive_metastore
Username: hive
Password: hive

创建 Hive 表后，MySQL 的 hive_metastore 中会出现很多元数据表，例如：

1
2
3
4
5
6


DBS
TBLS
COLUMNS_V2
SDS
SERDES
PARTITIONS

这些表用于保存 Hive 的库、表、字段、存储描述、序列化方式和分区信息。

11. 日常启动和停止

进入 Compose 项目目录：

1

cd C:\Users\v-liuyuhang\source\repos\MyPro\docker-hive4

启动环境：

1

docker compose up -d

查看状态：

1

docker ps

停止环境但保留数据：

1

docker compose down

查看日志：

1
2
3


docker logs hive-mysql
docker logs hive-metastore
docker logs hive4

实时查看 HiveServer2 日志：

1

docker logs -f hive4

进入 Hive 容器：

1

docker exec -it hive4 bash

进入 MySQL 容器：

1

docker exec -it hive-mysql mysql -uroot -proot

查看 Compose 创建的数据卷：

1

docker volume ls

12. 重置环境

12.1 删除容器但保留数据

1

docker compose down

作用：删除容器和网络，保留 mysql-data 与 warehouse-data。下次执行 docker compose up -d 后，之前创建的 Hive 表和数据仍然存在。

12.2 删除容器并清空数据

1

docker compose down -v

作用：删除容器、网络和 volume，会清空：

MySQL 中的 Hive 元数据
Hive warehouse 中的表数据

只有在配置错了、想彻底重来、或者明确不需要旧数据时再执行。

12.3 修改配置后重新启动

如果修改了 docker-compose.yml：

1
2


docker compose down
docker compose up -d

如果只是想重启服务：

1

docker compose restart

13. 常见问题处理

13.1 端口 3306 被占用

现象：启动 MySQL 容器时报类似错误：

1
2


ports are not available: exposing port TCP 0.0.0.0:3306
Only one usage of each socket address is normally permitted

原因：Windows 本机已经有 MySQL 占用了 localhost:3306。

处理：Docker MySQL 对外端口使用 3307:3306。

1
2


ports:
 - "3307:3306"

注意：Metastore 连接 MySQL 仍然写 mysql:3306，不是 mysql:3307。

13.2 找不到 MySQL JDBC Driver

现象：Metastore 日志出现：

1
2


ClassNotFoundException: com.mysql.cj.jdbc.Driver
No suitable driver found for jdbc:mysql://...

检查：

1
2


dir
docker logs hive-metastore

处理：确认 mysql-connector-j-8.4.0.jar 和 docker-compose.yml 在同一个目录，并且 Compose 中挂载路径正确：

1

- ./mysql-connector-j-8.4.0.jar:/opt/hive/lib/mysql-connector-j-8.4.0.jar

13.3 Metastore 连接 MySQL 失败

现象：Metastore 日志出现：

1
2


Communications link failure
Connection refused

排查顺序：

1
2
3


docker ps
docker logs hive-mysql
docker logs hive-metastore

重点确认：

hive-mysql 是否正在运行
MySQL healthcheck 是否正常
ConnectionURL 是否为 jdbc:mysql://mysql:3306/hive_metastore...
不要把容器内部连接地址写成 localhost:3307

13.4 HiveServer2 连接不上

现象：DBeaver 或 Beeline 连不上 localhost:10000。

排查：

1
2
3


docker ps
docker logs hive4
docker logs hive-metastore

重点确认：

hive4 是否正在运行
10000:10000 端口是否已映射
hive-metastore 是否正常运行
HiveServer2 的 Metastore 地址是否为 thrift://hive-metastore:9083

13.5 修改配置后没有生效

原因：docker start 只会按旧配置启动已有容器，不会重新应用新的端口、环境变量、volume 或 Compose 配置。

处理：在 Compose 目录中执行：

1
2


docker compose down
docker compose up -d

如果要彻底重置数据，再使用：

1
2


docker compose down -v
docker compose up -d

14. 一次性速通命令

首次创建时按下面顺序执行：

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


mkdir C:\Users\v-liuyuhang\source\repos\MyPro\docker-hive4
cd C:\Users\v-liuyuhang\source\repos\MyPro\docker-hive4

Invoke-WebRequest `
 -Uri "https://repo1.maven.org/maven2/com/mysql/mysql-connector-j/8.4.0/mysql-connector-j-8.4.0.jar" `
 -OutFile "mysql-connector-j-8.4.0.jar"

notepad docker-compose.yml
docker compose up -d
docker ps
docker logs hive-mysql
docker logs hive-metastore
docker logs hive4
docker exec -it hive4 bash

进入容器后：

1

beeline -u jdbc:hive2://localhost:10000

Beeline 中执行：

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


SHOW DATABASES;

CREATE DATABASE IF NOT EXISTS ods;
USE ods;

CREATE TABLE IF NOT EXISTS test_user (
 id INT,
 name STRING
);

INSERT INTO test_user VALUES
(1, 'Alice'),
(2, 'Bob');

SELECT * FROM test_user;

日常使用只需要：

1
2


cd C:\Users\v-liuyuhang\source\repos\MyPro\docker-hive4
docker compose up -d

不用时停止：

1

docker compose down

15. 总结

这套环境本质上是用 Docker Compose 在 Windows 本地启动一个小型 Hive 学习环境：HiveServer2 负责接收 SQL，Hive Metastore 负责管理元数据，MySQL 负责持久化元数据，warehouse-data volume 负责持久化 Hive 表数据。

最容易混淆的是端口：Windows 访问 Docker MySQL 用 localhost:3307，但容器内部 Metastore 访问 MySQL 必须用 mysql:3306。DBeaver 连接 Hive 则使用 jdbc:hive2://localhost:10000/default。

【九】Hive 复杂数据类型：ARRAY / MAP / STRUCT 与嵌套展开

Wed, 27 May 2026 22:59:32 +0800

Hive 除了支持基础数据类型（INT、STRING、DOUBLE 等）之外，还提供了 4 种复合（Complex）数据类型，用于在单个字段中存储结构化/半结构化数据。这在数仓建模中非常常见——比如用户标签、嵌套 JSON、商品多属性等场景。

一、三种复合类型总览

类型	语法定义	取值	是否有序	是否允许重复	典型场景
ARRAY	`ARRAY<data_type>`	`列名[下标]` (下标从 0 开始) `scores[0]`	✅ 有序	✅ 允许	用户兴趣标签、商品图片列表
MAP	`MAP<key_type, value_type>`	`列名[key]` `info['name']`	❌ 无序	Key 唯一	用户属性、KV 配置项
STRUCT	`STRUCT<col1:type, col2:type, ...>`	`列名.字段名` `details.name`	✅ 有序（字段固定）	字段名唯一	地址（省市区）、嵌套实体
嵌套类型	`ARRAY<STRUCT<col1:type, col2:type, ...>>`	`列名[下标].字段名` `Array[0].name`	✅ 有序	✅ 允许	复杂嵌套 JSON

结配合 get_json_object / json_tuple 解析

场景	推荐类型	理由
用户多标签、商品多图片	ARRAY	顺序有意义、可重复
动态 KV 属性（如点参数）	MAP	Key 不固定、可扩展
嵌套实体（地址、设备信息）	STRUCT	字段固定、语义清晰
复杂嵌套 JSON

💡 本质：复合类型让 Hive 能直接承接 JSON、Parquet/ORC 这类嵌套结构的数据，避免拆表带来的 Join 开销。

二、ARRAY

2.1 建表

1
2
3
4


CREATE TABLE user_scores (
 user_id INT,
 scores ARRAY<INT> -- 成绩数组
);

2.2 访问

下标从 0 开始

1
2
3
4
5
6
7


-- 1. 访问特定元素（下标从0开始）
SELECT scores[0] AS first_score FROM user_scores;

-- 2. 展开数组（行转列）
SELECT user_id, score
FROM user_scores
LATERAL VIEW explode(scores) exploded AS score;

组件	解释
`explode(scores)`	核心函数：`explode()`是一个内置的UDTF（用户自定义表生成函数）。它接收一个数组（或Map）作为输入，然后将数组中的每个元素输出为一行。
`LATERAL VIEW`	连接机制：这是一个Hive/Spark SQL的关键字。它的作用是将UDTF（如`explode`）生成的结果集（一个虚拟表）与原始表的每一行进行连接（JOIN）。你可以把它想象成一种“横向连接”。
`exploded`	虚拟表的别名：这是为`explode(scores)`生成的结果虚拟表起的一个表别名。
`score`	列的别名：这是虚拟表中那唯一一列的列名，这一列的值就来自数组`scores`中的每一个元素。

2.3 统计

⚠️ 常见误区：length() 是字符串函数，不能用于 ARRAY/MAP；反之 size() 也不能用于 STRING（会报错或返回意外结果）。

1
2


 统计数组长度
SELECT size(scores) AS score_count FROM user_scores;

三、Map

3.1 建表

1
2
3
4


CREATE TABLE user_info (
 user_id INT,
 info MAP<STRING, STRING> -- 用户属性映射
);

3.2 访问

1
2
3
4
5
6
7
8


-- 1. 访问特定key的值
SELECT info['name'] AS user_name FROM user_info;


-- 3. 获取所有keys或values
SELECT map_keys(info) AS all_keys,
 map_values(info) AS all_values
FROM user_info;

3.3 统计

⚠️ 常见误区：length() 是字符串函数，不能用于 ARRAY/MAP；反之 size() 也不能用于 STRING（会报错或返回意外结果）。

1
2


-- 统计Map键值对数量
SELECT size(info) AS info_count FROM user_info;

四、Struct

4.1 建表

1
2
3
4


CREATE TABLE employees (
 id INT,
 details STRUCT<name:STRING, age:INT, dept:STRING>
);

4.2 访问

1
2


-- 1. 访问字段（用点号）
SELECT details.name, details.age FROM employees;

4.3 统计

STRUCT 字段数是建表时固定的，没有运行时的 size 函数。如果一定要拿字段数，可以通过 DESCRIBE 或元数据查询，但实际工程中很少这么做

五、嵌套类型访问

复合类型可以嵌套，比如 ARRAY<STRUCT<...>> 或 MAP<STRING, ARRAY<INT>>：

1
2
3
4
5


-- 假设有列 orders ARRAY<STRUCT<order_id:INT, amount:DOUBLE>>
SELECT orders[0].amount FROM t; -- 取第一个订单的金额

-- 假设有列 tag_scores MAP<STRING, ARRAY<INT>>
SELECT tag_scores['vip'][0] FROM t; -- 取 vip 标签下数组的第一个元素

这类嵌套结构在解析 JSON / Parquet 时非常常见，掌握后能极大减少展开表的工作量。

六、常用辅助函数UDTF（配合复合类型）

UDTF = User-Defined Table-Generating Function（中文：用户定义表生成函数）

核心特性

一行输入 → 多行输出：将单行数据展开为多行
一对多转换：类似SQL中的LATERAL VIEW+ EXPLODE
内置常用UDTF：explode()、posexplode()、inline()等

函数	作用	示例
`explode(array)`	把 ARRAY 炸开成多行	`SELECT explode(hobbies) FROM user_profile;`
`explode(map)`	把 MAP 炸开成 key, value 两列多行	`SELECT explode(scores) FROM user_profile;`
`posexplode(map/array)`	把 MAP/ARRAY 炸开成多行并保留炸开后的索引	`SELECT posexplode(scores) FROM user_profile;`
`LATERAL VIEW explode()`	炸开后与原表 Join，保留其他列	见下
`map_keys(map)`	返回 MAP 所有 key 的 ARRAY	`map_keys(scores)` → `['math','english']`
`map_values(map)`	返回 MAP 所有 value 的 ARRAY	`map_values(scores)` → `[90, 85]`
`array_contains(arr, val)`	判断 ARRAY 是否包含某值	`array_contains(hobbies,'coding')`
`sort_array(arr)`	对 ARRAY 排序	`sort_array(hobbies)`

lateral view用于和split、explode等UDTF一起使用的，能将一行数据拆分成多行数据，在此基础上可以对拆分的数据进行聚合，lateral view首先为原始表的每行调用UDTF，UDTF会把一行拆分成一行或者多行，lateral view在把结果组合，产生一个支持别名表的虚拟表。

6.1 Array相关函数

① explode(array) 数组展开

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


-- 基础用法：将数组元素展开为多行
CREATE TABLE user_scores (
 user_id INT,
 scores ARRAY<INT> -- 成绩数组
);

-- 插入测试数据
INSERT INTO user_hobbies VALUES
(1, ARRAY(85, 92, 78)),
(2, ARRAY(90, 88));

-- 实际场景：分析用户浏览历史
SELECT user_id, score
FROM user_scores
LATERAL VIEW explode(scores) exploded AS score;

数据源

user_id	scores
1	[85, 92, 78]
2	[90, 88]

执行步骤：

遍历：查询引擎开始逐行扫描 user_scores表。
第一行 (user_id=1)：
- explode([85, 92, 78])开始工作，生成一个包含3行的虚拟表。我们给这个虚拟表起名为 exploded，它只有一列，我们叫这列为 score。
- 虚拟表 exploded的内容是：
  
  score
  
  85
  
  92
  
  78
- LATERAL VIEW将原始行 (user_id=1) 与这个虚拟表 exploded进行笛卡尔积（在这个场景下是1对多连接）。于是，我们得到：
  
  user_id score
  
  1 85
  
  1 92
  
  1 78
第二行 (user_id=2)：
- 重复相同过程：explode([90, 88])生成虚拟表，内容为 [90, 88]。
- LATERAL VIEW将原始行 (user_id=2) 与虚拟表连接，得到：
  
  user_id score
  
  2 90
  
  2 88
合并结果：
- 将上述所有中间结果合并，就是最终的输出。原始的一行数据（包含数组），被“炸开”成了多行扁平化数据。
  
  user_id score
  
  1 85
  
  1 92
  
  1 78
  
  2 90
  
  2 88

为什么要用 LATERAL VIEW？

因为 explode()这样的UDTF，输入一行会输出多行，这破坏了SQL中“一行进，一行出”的常规函数规则。LATERAL VIEW就是Hive/Spark SQL为了解决“如何将这种一行变多行的结果，与上下文（原表其他列）正确关联”而引入的语法。

一个常见错误写法（无法运行）：

1
2


-- 错误！SELECT子句中不能直接使用返回多行的UDTF
SELECT user_id, explode(scores) AS score FROM user_scores;

这个查询会报错，因为它不知道如何将 user_id(1行) 与 explode(scores)(3行) 对齐。LATERAL VIEW就是解决这个对齐问题的标准方式。

② posexplode(array) 带索引展开

和 explode(array) 相比，在炸开时增加了索引position，在合并的结果中可以体现出来，类似分组排序

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


-- 用法：同时返回数组索引和元素
CREATE TABLE user_hobbies (
 user_id INT,
 hobbies ARRAY<STRING> -- 爱好数组
);

-- 插入测试数据
INSERT INTO user_hobbies VALUES
(1, ARRAY('reading', 'music', 'sports')),
(2, ARRAY('coding', 'gaming'));

-- 查询
SELECT user_id, hobby, position
FROM user_hobbies
LATERAL VIEW posexplode(hobbies) exploded AS position, hobby;

数据源

user_id	hobbies
1	[‘reading’, ‘music’, ‘sports’]
2	[‘coding’, ‘gaming’]

执行步骤：

遍历：查询引擎开始逐行扫描 user_hobbies表。
第一行 (user_id=1, hobbies=[‘reading’,‘music’,‘sports’])：
- posexplode(['reading','music','sports'])开始工作，生成一个包含3行的虚拟表。我们给这个虚拟表起名为 exploded，它有两列：位置列和值列，分别命名为 position和 hobby。
- 虚拟表 exploded的内容是：
  
  position hobby
  
  0 reading
  
  1 music
  
  2 sports
- LATERAL VIEW将原始行 (user_id=1) 与这个虚拟表 exploded进行连接。于是，我们得到：
  
  user_id position hobby
  
  1 0 reading
  
  1 1 music
  
  1 2 sports
第二行 (user_id=2, hobbies=[‘coding’,‘gaming’])：
- 重复相同过程：posexplode(['coding','gaming'])生成虚拟表，内容为：
  
  position hobby
  
  0 coding
  
  1 gaming
- LATERAL VIEW将原始行 (user_id=2) 与虚拟表连接，得到：
  
  user_id position hobby
  
  2 0 coding
  
  2 1 gaming
合并结果：
- 将上述所有中间结果合并，就是最终的输出。原始的一行数据（包含数组），被"炸开"成了多行扁平化数据，并保留了元素在数组中的位置索引。
  
  user_id position hobby
  
  1 0 reading
  
  1 1 music
  
  1 2 sports
  
  2 0 coding
  
  2 1 gaming

③ array_contains(arr, value) 数组包含判断

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


-- 用法：判断数组是否包含特定值
CREATE TABLE products (
 product_id INT,
 tags ARRAY<STRING> -- 商品标签
);

-- 插入测试数据
INSERT INTO products VALUES
(1, ARRAY('electronics', 'discount', 'new')),
(2, ARRAY('clothing', 'summer')),
(3, ARRAY('electronics', 'home'));

-- 查询：查找所有电子类商品
SELECT product_id, tags
FROM products
WHERE array_contains(tags, 'electronics');

数据源

product_id	tags
1	[’electronics’, ‘discount’, ’new’]
2	[‘clothing’, ‘summer’]
3	[’electronics’, ‘home’]

执行步骤：

遍历：查询引擎开始逐行扫描 products表。
逐行应用 array_contains函数：
- 第一行 (product_id=1, tags=[’electronics’,‘discount’,’new’])：
  - 计算 array_contains(['electronics','discount','new'], 'electronics')
  - 检查数组 ['electronics','discount','new']是否包含字符串 'electronics'
  - 结果为 TRUE（包含）

第二行 (product_id=2, tags=[‘clothing’,‘summer’])：
- 计算 array_contains(['clothing','summer'], 'electronics')
- 检查数组 ['clothing','summer']是否包含字符串 'electronics'
- 结果为 FALSE（不包含）
第三行 (product_id=3, tags=[’electronics’,‘home’])：
- 计算 array_contains(['electronics','home'], 'electronics')
- 检查数组 ['electronics','home']是否包含字符串 'electronics'
- 结果为 TRUE（包含）

应用WHERE条件过滤：
- 只保留 array_contains返回 TRUE的行
- 符合条件的是第1行和第3行
返回结果：
- 输出满足条件的行
  
  product_id tags
  
  1 [’electronics’,‘discount’,’new’]
  
  3 [’electronics’,‘home’]

④ sort_array(arr) 数组排序

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


-- 用法：对数组元素进行排序
CREATE TABLE student_results (
 student_id INT,
 scores ARRAY<INT>, -- 多次考试成绩
 subjects ARRAY<STRING> -- 科目列表
);

-- 插入测试数据
INSERT INTO student_results VALUES
(1, ARRAY(85, 92, 78, 90), ARRAY('physics', 'math', 'english', 'chemistry')),
(2, ARRAY(88, 75, 95), ARRAY('history', 'geography', 'biology'));

-- 查询：对成绩数组进行排序
SELECT 
 student_id,
 scores,
 sort_array(scores) AS sorted_scores,
 subjects,
 sort_array(subjects) AS sorted_subjects
FROM student_results;

数据源

student_id	scores	subjects
1	[85, 92, 78, 90]	[‘physics’, ‘math’, ’english’, ‘chemistry’]
2	[88, 75, 95]	[‘history’, ‘geography’, ‘biology’]

执行步骤：

遍历：查询引擎开始逐行扫描 student_results表。
逐行应用 sort_array函数：
- 第一行 (student_id=1)：
  - 原始数据：
    - scores = [85, 92, 78, 90]
    - subjects = ['physics','math','english','chemistry']
  - 计算 sort_array([85, 92, 78, 90])：
    - 对整数数组进行升序排序
    - 结果：[78, 85, 90, 92]
  - 计算 sort_array(['physics','math','english','chemistry'])：
    - 对字符串数组按字典序排序
    - 结果：['chemistry','english','math','physics']

第二行 (student_id=2)：
- 原始数据：
  - scores = [88, 75, 95]
  - subjects = ['history','geography','biology']
  - 计算 sort_array([88, 75, 95])：
    - 对整数数组进行升序排序
    - 结果：[75, 88, 95]
  - 计算 sort_array(['history','geography','biology'])：
    - 对字符串数组按字典序排序
    - 结果：['biology','geography','history']

构造结果行：
- 对每一行，保留原始列，并添加排序后的新列

返回结果：

原来scores和subjects的对应关系在排序后消失

student_id	scores	sorted_scores	subjects	sorted_subjects
1	[85,92,78,90]	[78,85,90,92]	[‘physics’,‘math’,’english’,‘chemistry’]	[‘chemistry’,’english’,‘math’,‘physics’]
2	[88,75,95]	[75,88,95]	[‘history’,‘geography’,‘biology’]	[‘biology’,‘geography’,‘history’]

6.2 Map映射相关函数

① explode(map) Map展开

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


-- 用法：将Map展开为key-value对
CREATE TABLE student_scores (
 student_id INT,
 scores MAP<STRING, INT> -- 科目-分数映射
);

-- 插入测试数据
INSERT INTO student_scores VALUES
(1, MAP('math', 90, 'english', 85, 'physics', 88)),
(2, MAP('math', 92, 'chemistry', 78));

-- 查询
SELECT student_id, subject, score
FROM student_scores
LATERAL VIEW explode(scores) exploded AS subject, score;

数据源

student_id	scores
1	{‘math’:90,’english’:85,‘physics’:88}
2	{‘math’:92,‘chemistry’:78}

执行步骤：

遍历：查询引擎开始逐行扫描 student_scores表。
第一行 (student_id=1, scores={‘math’:90,’english’:85,‘physics’:88})：
- explode({'math':90,'english':85,'physics':88})开始工作，生成一个包含3行的虚拟表。我们给这个虚拟表起名为 exploded，它有两列：键列和值列，分别命名为 subject和 score。
- 虚拟表 exploded的内容是：
  
  subject score
  
  math 90
  
  english 85
  
  physics 88
- LATERAL VIEW将原始行 (student_id=1) 与这个虚拟表 exploded进行连接。于是，我们得到：
  
  student_id subject score
  
  1 math 90
  
  1 english 85
  
  1 physics 88
第二行 (student_id=2, scores={‘math’:92,‘chemistry’:78})：
- 重复相同过程：explode({'math':92,'chemistry':78})生成虚拟表，内容为：
  
  subject score
  
  math 92
  
  chemistry 78
- LATERAL VIEW将原始行 (student_id=2) 与虚拟表连接，得到：
  
  student_id subject score
  
  2 math 92
  
  2 chemistry 78
合并结果：
- 将上述所有中间结果合并，就是最终的输出。原始的一行数据（包含Map），被"炸开"成了多行扁平化数据，每行包含一个键值对。
  
  student_id subject score
  
  1 math 90
  
  1 english 85
  
  1 physics 88
  
  2 math 92
  
  2 chemistry 78

②map_keys(map) map_values(map) 提取Map的键或值

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


-- 用法：提取Map中的所有键或所有值
CREATE TABLE employee_skills (
 emp_id INT,
 skills MAP<STRING, INT> -- 技能:熟练度映射
);

-- 插入测试数据
INSERT INTO employee_skills VALUES
(1, MAP('Java', 5, 'Python', 4, 'SQL', 3)),
(2, MAP('JavaScript', 4, 'React', 5));

-- 查询1：提取所有技能名称
SELECT 
 emp_id,
 map_keys(skills) AS skill_names
FROM employee_skills;

-- 查询2：提取所有熟练度
SELECT 
 emp_id,
 map_values(skills) AS skill_levels
FROM employee_skills;

数据源

emp_id	skills
1	{‘Java’:5,‘Python’:4,‘SQL’:3}
2	{‘JavaScript’:4,‘React’:5}

执行步骤（查询1 - map_keys）：

遍历：查询引擎开始逐行扫描 employee_skills表。
逐行应用 map_keys函数：
- 第一行 (emp_id=1, skills={‘Java’:5,‘Python’:4,‘SQL’:3})：
  - 计算 map_keys({'Java':5,'Python':4,'SQL':3})
  - 提取Map中的所有键
  - 结果：数组 ['Java','Python','SQL']

第二行 (emp_id=2, skills={‘JavaScript’:4,‘React’:5})：
- 计算 map_keys({'JavaScript':4,'React':5})
- 提取Map中的所有键
- 结果：数组 ['JavaScript','React']

构造结果行：
- 每一行包含 emp_id和对应的技能名称数组
返回结果：

emp_id skill_names

1 [‘Java’,‘Python’,‘SQL’]

2 [‘JavaScript’,‘React’]

执行步骤（查询2 - map_values）：

遍历：查询引擎开始逐行扫描 employee_skills表。
逐行应用 map_values函数：
- 第一行 (emp_id=1, skills={‘Java’:5,‘Python’:4,‘SQL’:3})：
  - 计算 map_values({'Java':5,'Python':4,'SQL':3})
  - 提取Map中的所有值
  - 结果：数组 [5, 4, 3]

第二行 (emp_id=2, skills={‘JavaScript’:4,‘React’:5})：
- 计算 map_values({'JavaScript':4,'React':5})
- 提取Map中的所有值
- 结果：数组 [4, 5]

构造结果行：
- 每一行包含 emp_id和对应的熟练度数组
返回结果：

emp_id skill_levels

1 [5, 4, 3]

2 [4, 5]

6.3 多个 LATERAL VIEW

① 基本语法回顾

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


CREATE TABLE user_data (
 user_id INT,
 tags ARRAY<STRING>,
 hobbies ARRAY<STRING>
);

-- 基本用法
SELECT user_id, tag
FROM user_data
LATERAL VIEW explode(tags) t AS tag;

② 多个 LATERAL VIEW 的笛卡尔积问题

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


-- 创建测试表
CREATE TABLE user_interests (
 user_id INT,
 tags ARRAY<STRING>, -- 标签数组
 skills ARRAY<STRING> -- 技能数组
);

-- 插入测试数据
INSERT INTO user_interests VALUES
(1, ARRAY('student', 'coder'), ARRAY('Java', 'SQL')),
(2, ARRAY('teacher'), ARRAY('Python', 'C++', 'Go'));

-- 示例1：多个LATERAL VIEW（可能产生笛卡尔积）
SELECT 
 user_id,
 tag,
 skill
FROM user_interests
LATERAL VIEW explode(tags) t1 AS tag
LATERAL VIEW explode(skills) t2 AS skill;

数据源

user_id	tag	skill
1	[‘student’, ‘coder’]	[‘Java’, ‘SQL’]
2	[’teacher’]	[‘Python’, ‘C++’, ‘Go’]

执行步骤分析：

遍历原始表：
- 第一行：user_id=1, tags=[‘student’,‘coder’], skills=[‘Java’,‘SQL’]
- 第二行：user_id=2, tags=[’teacher’], skills=[‘Python’,‘C++’,‘Go’]
第一个 LATERAL VIEW 展开 tags：
- 对第一行：
  - 虚拟表t1：tag=‘student’
  - 虚拟表t1：tag=‘coder’

对第二行：
- 虚拟表t1：tag=‘teacher’

第二个 LATERAL VIEW 展开 skills：
- 对第一行的第一个tag（‘student’）：
  - 展开skills数组：[‘Java’,‘SQL’]
  - 生成：(‘student’, ‘Java’), (‘student’, ‘SQL’)

对第一行的第二个tag（‘coder’）：
- 展开skills数组：[‘Java’,‘SQL’]
- 生成：(‘coder’, ‘Java’), (‘coder’, ‘SQL’)
对第二行的tag（’teacher’）：
- 展开skills数组：[‘Python’,‘C++’,‘Go’]
- 生成：(’teacher’, ‘Python’), (’teacher’, ‘C++’), (’teacher’, ‘Go’)

最终结果：

user_id tag skill

1 student Java

1 student SQL

1 coder Java

1 coder SQL

2 teacher Python

2 teacher C++

2 teacher Go

⚠️ 注意：这产生了笛卡尔积！user_id=1 的 2个tags × 2个skills = 4行。这可能不是你想要的效果。

③ 使用 posexplode 按索引对齐

对齐

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


-- 创建表
CREATE TABLE student_subjects (
 student_id INT,
 subjects ARRAY<STRING>, -- 科目
 grades ARRAY<INT> -- 对应成绩
);

-- 插入测试数据
INSERT INTO student_subjects VALUES
(1, ARRAY('数学', '英语', '物理'), ARRAY(90, 85, 88)),
(2, ARRAY('化学', '生物'), ARRAY(92, 78));

-- ✅ 正确做法：使用 posexplode 按位置对齐
SELECT 
 student_id,
 subject,
 grade
FROM student_subjects
LATERAL VIEW posexplode(subjects) s AS pos1, subject
LATERAL VIEW posexplode(grades) g AS pos2, grade
WHERE pos1 = pos2; -- 关键：按相同位置连接

数据源

student_id	subjects	grades
1	[‘数学’, ‘英语’, ‘物理’]	[90, 85, 88]
2	[‘化学’, ‘生物’]	[92, 78]

执行步骤：

1. 使用 posexplode 展开 subjects：

第一行：
- (0, ‘数学’), (1, ‘英语’), (2, ‘物理’)
第二行：
- (0, 90), (0, 85), (0, 88)

2. 使用 posexplode 展开 grades：

第一行：
- (0, ‘化学’), (1, ‘生物’)
第二行：
- (0, 92), (0, 78)

3. 按照笛卡尔积展开所有组合：

student_id	pos1	subject	pos2	grade
1	0	数学	0	90
1	0	数学	1	85
1	0	数学	2	88
1	1	英语	0	90
1	1	英语	1	85
1	1	英语	2	88
1	2	物理	0	90
1	2	物理	1	85
1	2	物理	2	88
2	0	化学	0	92
2	0	化学	1	78
2	1	生物	0	92
2	1	生物	1	78

3. 按where指定的pos1=pos2进行连接：

student_id=1，pos1=0 只能连接 pos2=0 → (‘数学’, 90)
student_id=1，pos1=1 只能连接 pos2=1 → (‘英语’, 85)
student_id=1，pos1=2 只能连接 pos2=2 → (‘物理’, 88)
student_id=2，pos1=0 只能连接 pos2=0 → (‘化学’, 92)
student_id=2，pos1=1 只能连接 pos2=1 → (‘物理’, 78)

最终结果：

user_id	subject	grade
1	数学	90
1	英语	85
1	物理	88
2	化学	92
2	物理	78

✅ 正确：按位置对齐，避免了意外的笛卡尔积。

对不齐

1
2
3
4
5
6
7
8
9


-- 使用 posexplode 按位置对齐
SELECT 
 user_id,
 tag,
 skill
FROM user_interests
LATERAL VIEW posexplode(tags) t1 AS pos1, tag
LATERAL VIEW posexplode(skills) t2 AS pos2, skill
WHERE pos1 = pos2; -- 按相同位置对齐

数据源

user_id	tag	skill
1	[‘student’, ‘coder’]	[‘Java’, ‘SQL’]
2	[’teacher’]	[‘Python’, ‘C++’, ‘Go’]

执行步骤：

1. 使用 posexplode 展开 tags：

第一行：
- (0, ‘student’), (1, ‘coder’)
第二行：
- (0, ’teacher’)

2. 使用 posexplode 展开 skills：

第一行：
- (0, ‘Java’), (1, ‘SQL’)
第二行：
- (0, ‘Python’), (1, ‘C++’), (2, ‘Go’)

3. 按位置连接：

user_id	pos1	tag	pos2	skill
1	0	student	0	Java
1	0	student	1	SQL
1	1	coder	0	Java
1	1	coder	1	SQL
2	0	teacher	0	Python
2	0	teacher	1	C++
2	0	teacher	2	Go

第一行，pos1=0 只能连接 pos2=0 → (‘student’, ‘Java’)
第一行，pos1=1 只能连接 pos2=1 → (‘coder’, ‘SQL’)
第二行，pos1=0 只能连接 pos2=0 → (’teacher’, ‘Python’)

最终结果：

user_id	tag	skill
1	student	Java
1	coder	SQL
2	teacher	Python

✅ 正确：按位置对齐，避免了意外的笛卡尔积。

④ OUTER 关键字的作用

几乎没有额外性能开销，但会让结果集包含更多行（保留了空数组对应的行）。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


-- 创建包含空数组的数据
INSERT INTO user_interests VALUES
(3, ARRAY('engineer'), ARRAY()), -- skills为空数组
(4, ARRAY(), ARRAY('Java')); -- tags为空数组

-- 没有OUTER关键字
SELECT 
 user_id,
 tag
FROM user_interests
LATERAL VIEW explode(tags) t AS tag;

数据源

user_id	tag	skill
1	[‘student’, ‘coder’]	[‘Java’, ‘SQL’]
2	[’teacher’]	[‘Python’, ‘C++’, ‘Go’]
3	[’engineer’]	[]
4	[]	[‘Java’]

执行结果（没有OUTER）：

user_id	tag
1	student
1	coder
2	teacher
3	engineer
4	❌ 这行会丢失！

user_id=4 的标签数组为空，explode([])不会生成任何行，所以这行数据完全丢失了。

1
2
3
4
5
6


-- 使用OUTER关键字
SELECT 
 user_id,
 tag
FROM user_interests
LATERAL VIEW OUTER explode(tags) t AS tag;

执行结果（有OUTER）：

user_id	tag
1	student
1	coder
2	teacher
3	engineer
4	NULL

✅ 关键区别：OUTER关键字会保留原始行，即使 UDTF 没有输出任何行，也会用 NULL 填充。

⑤ 复杂场景示例

 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


-- 创建电商订单表
CREATE TABLE orders (
 order_id STRING,
 order_date STRING,
 items ARRAY<STRUCT< -- 商品项
 product_id STRING,
 quantity INT,
 price DECIMAL(10,2)
 >>,
 promotions ARRAY<STRING> -- 优惠活动
);

-- 插入测试数据
INSERT INTO orders VALUES
('O001', '2024-01-01', 
 ARRAY(
 STRUCT('P001', 2, 50.00),
 STRUCT('P002', 1, 100.00)
 ), 
 ARRAY('NEW_USER', 'FREE_SHIPPING')
),
('O002', '2024-01-01',
 ARRAY(
 STRUCT('P003', 3, 30.00)
 ),
 ARRAY() -- 没有促销
),
('O003', '2024-01-02',
 ARRAY(), -- 没有商品
 ARRAY('DISCOUNT_10')
);

-- 示例1：展开订单商品，保留没有商品的订单
SELECT 
 order_id,
 order_date,
 item.product_id,
 item.quantity,
 item.price
FROM orders
LATERAL VIEW OUTER explode(items) t AS item;

数据源：

order_id	order_date	items	promotions
O001	2024-01-01	[(‘P001’, 2, 50.00),(‘P002’, 1, 100.00)]	[‘NEW_USER’, ‘FREE_SHIPPING’]
O002	2024-01-01	[(‘P003’, 3, 30.00)]	[]
O003	2024-01-02	[]	[‘DISCOUNT_10’]

执行结果：

order_id	order_date	product_id	quantity	price
O001	2024-01-01	P001	2	50.00
O001	2024-01-01	P002	1	100.00
O002	2024-01-01	P003	3	30.00
O003	2024-01-02	NULL	NULL	NULL

注意：O003 订单没有商品，但使用了 OUTER，所以被保留下来，商品相关字段为 NULL。

⑥ 多个 LATERAL VIEW 与 OUTER 的组合

1
2
3
4
5
6
7
8


-- 同时展开商品和促销
SELECT 
 order_id,
 item.product_id,
 promotion
FROM orders
LATERAL VIEW OUTER explode(items) t1 AS item
LATERAL VIEW OUTER explode(promotions) t2 AS promotion;

执行过程分析：

原始数据：
- O001: 2个商品 × 2个促销 = 4行
- O002: 1个商品 × 0个促销 = 1行（因为OUTER）
- O003: 0个商品 × 1个促销 = 1行（因为OUTER）

最终结果：

order_id	product_id	promotion
O001	P001	NEW_USER
O001	P001	FREE_SHIPPING
O001	P002	NEW_USER
O001	P002	FREE_SHIPPING
O002	P003	NULL
O003	NULL	DISCOUNT_10

⑦ 实际业务场景示例

 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


-- 用户行为分析
CREATE TABLE user_events (
 user_id INT,
 date STRING,
 page_views ARRAY<STRING>, -- 访问页面
 clicks ARRAY<STRUCT< -- 点击事件
 element_id STRING,
 timestamp BIGINT
 >>,
 sessions ARRAY<STRUCT< -- 会话信息
 session_id STRING,
 duration INT
 >>
);

-- 复杂的多维度分析
SELECT 
 user_id,
 date,
 page_view,
 click.element_id AS clicked_element,
 click.timestamp AS click_time,
 session.session_id,
 session.duration
FROM user_events
LATERAL VIEW OUTER explode(page_views) pv AS page_view
LATERAL VIEW OUTER explode(clicks) c AS click
LATERAL VIEW OUTER explode(sessions) s AS session
WHERE date = '2024-01-15';

⑧ 性能优化建议

 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


-- ❌ 不推荐的写法：在WHERE前做复杂的展开
SELECT 
 user_id,
 page_view,
 click.element_id
FROM user_events
LATERAL VIEW OUTER explode(page_views) pv AS page_view
LATERAL VIEW OUTER explode(clicks) c AS click
WHERE page_view LIKE '%product%'
 AND click.timestamp > 1673712000;

-- ✅ 推荐的写法：先过滤，再展开
WITH filtered_data AS (
 SELECT 
 user_id,
 page_views,
 clicks
 FROM user_events
 WHERE EXISTS (
 SELECT 1
 FROM UNNEST(page_views) AS pv
 WHERE pv LIKE '%product%'
 )
)
SELECT 
 user_id,
 page_view,
 click.element_id
FROM filtered_data
LATERAL VIEW OUTER explode(page_views) pv AS page_view
LATERAL VIEW OUTER explode(clicks) c AS click
WHERE click.timestamp > 1673712000;

七、Spark 3.0+ 的新语法 CROSS JOIN UNNEST（推荐）

这是现代SQL（Spark 3.0+、Presto/Trino、BigQuery等）中处理数组的标准方法。

UNNEST 是 SQL（尤其在 Hive、Spark SQL、Flink SQL 等大数据框架中）用于将嵌套的集合类型数据“展开”成多行数据的核心操作。它主要用于处理数组（Array）和映射（Map）类型的数据。

7.1 基本概念对比

首先，我们对比两种语法：

特性	`LATERAL VIEW explode()`(Hive风格)	`CROSS JOIN UNNEST()`(SQL标准)
语法来源	Hive/Spark特有扩展	SQL标准语法
可读性	较复杂，需要理解UDTF概念	更直观，类似表连接
SQL标准	非标准	SQL:2016标准
支持平台	Hive, Spark (2.x+)	Spark 3.0+, Presto, Trino, BigQuery, Snowflake
多个数组展开	需要多个LATERAL VIEW	可在UNNEST中指定多个数组
默认行为	内连接，丢弃空/空数组行	内连接，丢弃空/空数组行
保留原行语法	`LATERAL VIEW OUTER explode()`	`LEFT JOIN UNNEST() ON true`

7.2 基本数组展开

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


-- 创建测试表
CREATE TABLE student_grades (
 student_id INT,
 name STRING,
 grades ARRAY<INT>
);

-- 插入数据
INSERT INTO student_grades VALUES
(1, '张三', ARRAY(85, 90, 92)),
(2, '李四', ARRAY(78, 82)),
(3, '王五', ARRAY()), -- 空数组
(4, '赵六', NULL); -- NULL数组

-- 展开数组
SELECT 
 student_id,
 name,
 grade
FROM student_grades
CROSS JOIN UNNEST(grades) AS t(grade);

数据源

student_id	name	grades
1	张三	[85, 90, 92]
2	李四	[78, 82]
3	王五	ARRAY()
4	赵六	NULL

结果：

1
2
3
4
5
6
7
8
9


+-----------+------+-------+
| student_id| name | grade |
+-----------+------+-------+
| 1 | 张三 | 85 |
| 1 | 张三 | 90 |
| 1 | 张三 | 92 |
| 2 | 李四 | 78 |
| 2 | 李四 | 82 |
+-----------+------+-------+

⚠️ 注意：王五和赵六的数据丢失了，因为CROSS JOIN不会保留空数组或NULL数组的行。

7.3 保留空数组的行 (LEFT JOIN)

1
2
3
4
5
6
7


-- 使用 LEFT JOIN 保留空数组
SELECT 
 student_id,
 name,
 grade
FROM student_grades
LEFT JOIN UNNEST(grades) AS t(grade) ON true;

结果：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


+-----------+------+-------+
| student_id| name | grade |
+-----------+------+-------+
| 1 | 张三 | 85 |
| 1 | 张三 | 90 |
| 1 | 张三 | 92 |
| 2 | 李四 | 78 |
| 2 | 李四 | 82 |
| 3 | 王五 | NULL | -- 空数组，grade为NULL
| 4 | 赵六 | NULL | -- NULL数组，grade为NULL
+-----------+------+-------+

✅ 关键：LEFT JOIN UNNEST(...) ON true相当于 LATERAL VIEW OUTER explode(...)

7.4 展开多个数组 (按元素对齐)

 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


-- 创建表
CREATE TABLE student_subjects (
 student_id INT,
 subjects ARRAY<STRING>, -- 科目
 grades ARRAY<INT> -- 对应成绩
);

-- 插入测试数据
INSERT INTO student_subjects VALUES
(1, ARRAY('数学', '英语', '物理'), ARRAY(90, 85, 88)),
(2, ARRAY('化学', '生物'), ARRAY(92, 78));

-- 同时展开多个数组（按位置对齐）
SELECT 
 student_id,
 subject,
 grade
FROM student_subjects
CROSS JOIN UNNEST(subjects, grades) AS t(subject, grade);


-- ✅ 等价于 posexplode 按位置对齐
SELECT 
 student_id,
 subject,
 grade
FROM student_subjects
LATERAL VIEW posexplode(subjects) s AS pos1, subject
LATERAL VIEW posexplode(grades) g AS pos2, grade
WHERE pos1 = pos2; -- 关键：按相同位置连接

数据源

student_id	subjects	grades
1	[‘数学’, ‘英语’, ‘物理’]	[90, 85, 88]
2	[‘化学’, ‘生物’]	[92, 78]

执行过程：

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


UNNEST(subjects, grades) 按位置对齐展开：

student_id=1:
 - 第一组：('数学', 90)
 - 第二组：('英语', 85)
 - 第三组：('物理', 88)

student_id=2:
 - 第一组：('化学', 92)
 - 第二组：('生物', 78)

结果：
+-----------+--------+-------+
| student_id| subject| grade |
+-----------+--------+-------+
| 1 | 数学 | 90 |
| 1 | 英语 | 85 |
| 1 | 物理 | 88 |
| 2 | 化学 | 92 |
| 2 | 生物 | 78 |
+-----------+--------+-------+

🆚CROSS JOIN UNNEST()与LATERAL VIEW posexplode()对比

特性	`CROSS JOIN UNNEST(arr1, arr2)`	`LATERAL VIEW posexplode()`组合
语法简洁性	⭐⭐⭐⭐⭐ 一行搞定	⭐⭐ 需要多行，复杂
按位置对齐	✅ 自动按位置对齐	❌ 不会自动对齐
避免笛卡尔积	✅ 自动避免	❌ 会产生笛卡尔积，需手动处理
可读性	⭐⭐⭐⭐⭐ 直观易懂	⭐⭐ 需要理解 posexplode 和连接条件
数组长度检查	✅ 自动处理长度不匹配，用NULL填充	❌ 需要手动处理长度不匹配
多字段下的性能	✅ 单次扫描表一次操作完成多数组展开	❌ 多次扫描表或生成中间结果需要额外连接操作，可能产生大量中间数据

语法对比表

场景	Hive/Spark 2.x 语法	SQL标准语法 (Spark 3.0+)
基本展开	`LATERAL VIEW explode(arr) t AS elem`	`CROSS JOIN UNNEST(arr) AS t(elem)`
带位置展开	`LATERAL VIEW posexplode(arr) t AS pos, elem`	`CROSS JOIN UNNEST(arr) WITH ORDINALITY AS t(elem, pos)`
保留空数组	`LATERAL VIEW OUTER explode(arr) t AS elem`	`LEFT JOIN UNNEST(arr) AS t(elem) ON true`
展开多个数组	需要多个LATERAL VIEW	`CROSS JOIN UNNEST(arr1, arr2) AS t(elem1, elem2)`
展开Map	`LATERAL VIEW explode(map) t AS k, v`	`CROSS JOIN UNNEST(map) AS t(k, v)`

处理数组长度不匹配

数据源

student_id	subjects	grades
1	[‘数学’, ‘英语’, ‘物理’]	[90, 85, 88]
2	[‘化学’, ‘生物’]	[92, 78]
3	[‘历史’, ‘地理’, ‘政治’]	[80, 85]

使用 CROSS JOIN UNNEST（自动处理）：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


-- UNNEST 自动处理长度不匹配
INSERT INTO student_subjects VALUES
(3, ARRAY('历史', '地理', '政治'), ARRAY(80, 85)); -- 长度不匹配

SELECT 
 student_id,
 subject,
 grade
FROM student_subjects
CROSS JOIN UNNEST(subjects, grades) AS t(subject, grade);

结果（自动用NULL填充）：

1
2
3
4
5


student_id | subject | grade
-----------|---------|------
3 | 历史 | 80
3 | 地理 | 85
3 | 政治 | NULL -- 自动用NULL填充

使用 LATERAL VIEW posexplode（手动处理）：

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


-- 使用 FULL OUTER JOIN 处理长度不匹配
SELECT 
 COALESCE(s.student_id, g.student_id) AS student_id,
 s.subject,
 g.grade
FROM (
 SELECT student_id, pos, subject
 FROM student_subjects
 LATERAL VIEW posexplode(subjects) s AS pos, subject
) s
FULL OUTER JOIN (
 SELECT student_id, pos, grade
 FROM student_subjects
 LATERAL VIEW posexplode(grades) g AS pos, grade
) g ON s.student_id = g.student_id AND s.pos = g.pos;

7.5 带位置索引展开 (WITH ORDINALITY)

1
2
3
4
5
6
7


-- 使用 WITH ORDINALITY 获取元素位置
SELECT 
 student_id,
 pos, -- 位置索引（从1开始）
 grade
FROM student_grades
CROSS JOIN UNNEST(grades) WITH ORDINALITY AS t(grade, pos);

数据源

student_id	subjects	grades
1	[‘数学’, ‘英语’, ‘物理’]	[90, 85, 88]
2	[‘化学’, ‘生物’]	[92, 78]

结果：

1
2
3
4
5
6
7
8
9


+-----------+----+-------+
| student_id| pos| grade |
+-----------+----+-------+
| 1 | 1 | 85 |
| 1 | 2 | 90 |
| 1 | 3 | 92 |
| 2 | 1 | 78 |
| 2 | 2 | 82 |
+-----------+----+-------+

7.6 展开 Map 类型

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


-- 创建包含Map的表
CREATE TABLE student_scores (
 student_id INT,
 scores MAP<STRING, INT> -- 科目:分数
);

-- 插入数据
INSERT INTO student_scores VALUES
(1, MAP('数学', 90, '英语', 85, '物理', 88)),
(2, MAP('化学', 92, '生物', 78));

-- 展开Map
SELECT 
 student_id,
 subject,
 score
FROM student_scores
CROSS JOIN UNNEST(scores) AS t(subject, score);

数据源

student_id	scores
1	{‘数学’:90,‘英语’:85,‘物理’:88}
2	{‘化学’:92,‘生物’:78}

结果：

1
2
3
4
5
6
7
8
9


+-----------+--------+-------+
| student_id| subject| score |
+-----------+--------+-------+
| 1 | 数学 | 90 |
| 1 | 英语 | 85 |
| 1 | 物理 | 88 |
| 2 | 化学 | 92 |
| 2 | 生物 | 78 |
+-----------+--------+-------+

7.7 🔄 高级用法

① 多层嵌套展开

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


-- 复杂数据结构
CREATE TABLE nested_data (
 id INT,
 data ARRAY<STRUCT<
 name STRING,
 values ARRAY<INT>
 >>
);

-- 插入数据
INSERT INTO nested_data VALUES
(1, ARRAY(
 STRUCT('A', ARRAY(1, 2, 3)),
 STRUCT('B', ARRAY(4, 5))
));

两层展开

1
2
3
4
5
6
7


SELECT 
 id,
 outer_data.name,
 inner_value
FROM nested_data
CROSS JOIN UNNEST(data) AS outer_data 
CROSS JOIN UNNEST(outer_data.values) AS inner_value;

等价于：

1
2
3
4
5
6
7


SELECT 
 id,
 outer_data.name,
 inner_value
FROM nested_data,
UNNEST(data) AS outer_data,
UNNEST(outer_data.values) AS inner_value;

id	outer_data.name	inner_value
1	A	1
1	A	2
1	A	3
1	B	1
1	B	2
1	B	3

② 过滤展开后的数据

1
2
3
4
5
6
7


-- 只展开特定条件的元素
SELECT 
 student_id,
 grade
FROM student_grades
CROSS JOIN UNNEST(grades) AS t(grade)
WHERE grade > 85; -- 只保留大于85的成绩

③ 聚合与展开组合

1
2
3
4
5
6
7
8


-- 计算每个学生的平均分
SELECT 
 student_id,
 name,
 AVG(grade) AS avg_grade
FROM student_grades
CROSS JOIN UNNEST(grades) AS t(grade)
GROUP BY student_id, name;

【六】Hive 函数：聚合 / 统计 / 分位数 / 集合 / 高级分组

Wed, 20 May 2026 22:47:22 +0800

聚合函数（Aggregate Functions）是 Hive 中用于对一组行进行计算并返回单个结果的函数，通常配合 GROUP BY 使用，是数仓查询、报表统计的核心工具。

聚合函数注意 NULL 值	说明
`count(*)` 包含 NULL 值	统计行数，不看列值
`count(id)` 不包含 NULL 值	只统计该列非 NULL 的行
`min/max/avg` 忽略 NULL	NULL 不参与计算
全部是 NULL 时，结果为 NULL	不是 0，是 NULL
`avg` 不包含 NULL = 分母不算那一行	分子分母同时排除 NULL

一、聚合函数总览

类别	常见函数	作用	是否支持 DISTINCT
基础聚合	`count`, `sum`, `avg`, `max`, `min`	计数 / 求和 / 平均 / 最值	✅
统计学	`variance`, `var_pop`, `var_samp`, `stddev_pop`, `stddev_samp`, `covar_pop`, `covar_samp`, `corr`	方差、标准差、协方差、相关系数	❌
分位数	`percentile(col, p)`, `percentile_approx(col, p)`	精确 / 近似分位数	❌
集合聚合	`collect_list`, `collect_set`, `histogram_numeric(col, b)`, `map_agg`,`map_from_arrays`	把多行合并成数组	`collect_set` 自动去重
直方图	`histogram_numeric(col, b)`, `ngrams`	近似直方图	❌
高级分组	`grouping`, `grouping__id`	配合`GROUPING SETS / CUBE / ROLLUP` 标识聚合维度	—

二、基础聚合函数（最常用）

1. count

1
2
3
4
5
6
7
8


-- 统计所有行（包括 NULL）
SELECT count(*) FROM orders;

-- 统计指定列非 NULL 的行数
SELECT count(user_id) FROM orders;

-- 去重统计（注意性能：会强制走一个 Reducer）
SELECT count(DISTINCT user_id) FROM orders;

count(DISTINCT user_id) 为什么会强制走一个Reducer？

COUNT本身是可合并的，每个部分计数，最后加总即可。
DISTINCT去重操作是不可合并的。假设数据被分散到10个Mapper处理，每个Mapper都能得到自己局部的去重结果，但这10个局部结果之间很可能有重复。为了得到全局唯一的去重结果，必须将可能重复的键（user_id）全部集中到一起处理。

假设有3个user_id：A, A, B, B, C, C
- Map阶段：读取orders表，以user_id为key输出
  
  (A), (A), (B), (B), (C), (C)
- Shuffle阶段：这是关键！由于需要对user_id进行全局去重，Hive默认会设置 mapred.reduce.tasks = 1，或者通过一个特殊的、强制所有数据流向一个Reducer的分区器。这导致所有数据在网络上传输后，都会堆积到唯一的一个Reducer节点上。
  
  [(A), (A), (B), (B), (C), (C)]→Reducer 0
- Reduce阶段：这个唯一的Reducer节点接收全量数据，在内存中维护一个HashSet结构来去重，然后计数。
  
  HashSet{A, B, C} → count=3

瓶颈：

单点计算与网络瓶颈：所有数据都流向一个Reducer，该节点的CPU、内存、网络IO成为瓶颈，而集群其他节点闲置，资源利用率极低。
内存压力巨大： Reducer需要在内存中存储所有不重复的user_id 用于去重。如果去重后的基数（cardinality）很大，比如有上亿个不同的用户，极易导致Java Heap Space内存溢出（OOM）。
数据倾斜的极端情况：这本质上是100%的数据倾斜，所有数据都“倾斜”到了那一个Reducer上。

⚠️ 性能坑点：count(distinct) 在 Hive 中默认只用 1 个 Reducer，数据量大时极慢。 优化方案：

count(distinct)优化

使用 `GROUP BY`改写（最推荐，处理精确去重）

这是标准优化手段，将计算拆分成“局部去重”和“全局汇总”两步。

1
2
3
4
5
6
7


-- 优化后的写法
SELECT count(1)
FROM (
 SELECT user_id
 FROM orders
 GROUP BY user_id
) t;

假设有3个user_id：A, A, B, B, C, C 执行过程解析：

第一个Job（GROUP BY）:
- Map阶段：以user_id为Key输出： (A), (A), (B), (B), (C), (C)
- Shuffle阶段：相同的user_id会被发送到同一个Reducer，但不同的user_id可以分散到多个Reducer上。通过设置 set mapred.reduce.tasks = N;来控制并行度。
  1 2 3
  
  A的hash→Reducer 0: (A), (A) B的hash→Reducer 1: (B), (B) C的hash→Reducer 0: (C), (C) // 假设A和C的hash模2相同
- Reduce阶段：每个Reducer对自己接收到的user_id做局部去重（因为相同user_id已在一起，去重很快），每个user_id输出一行。
  1 2
  
  Reduce0: 去重后输出 (A), (C) Reduce1: 去重后输出 (B)
第二个Job（count(1)）这个Job数据量很小，执行飞快:
- Map阶段：以user_id为Key输出：(A), (C), (B)
- Shuffle阶段：所有→Reducer 0
- Reduce阶段：Reduce0: count=3

优点：完美利用集群并行能力，解决了单点瓶颈和内存溢出问题。

使用近似计算（处理超大基数去重）

如果业务可以接受微小误差（误差率通常在1%以内），使用近似聚合函数速度极快，因为它使用了HyperLogLog等概率算法，内存占用恒定且极小。

1
2
3
4


-- 使用近似计算，性能极高
SELECT count(DISTINCT user_id) as exact_cnt, -- 精确值（慢）
 approx_count_distinct(user_id) as approx_cnt -- 近似值（快）
FROM orders;

适用场景：浏览UV、独立访客等超大基数统计，对绝对精确性要求不高的场景。

2. sum / avg / max / min

1
2
3
4
5
6
7
8


SELECT
dept_id,
sum(salary) AS total_salary,
avg(salary) AS avg_salary,
max(salary) AS max_salary,
min(salary) AS min_salary
FROM employee
GROUP BY dept_id;

📝 NULL 处理规则：除 count(*) 外，所有聚合函数自动忽略 NULL。

避坑指南

坑	描述	解决方案
`count(distinct)` 慢	只用 1 个 Reducer	用`group by` 子查询替代
聚合后 select 非聚合列	Hive 会报错或返回非预期值	所有非聚合列必须放进`group by`
NULL 影响统计	`count(col)` 不统计 NULL	改用`count(*)` 或 `nvl(col,0)`
`collect_list` 数据膨胀	大 group 下数组超大 OOM	加`LIMIT` 或预先过滤
分位数选错函数	`percentile` 慢且只支持 int	用`percentile_approx`
group by 倾斜	单 Reducer 跑爆	开启`hive.groupby.skewindata`

三、统计学聚合函数

函数	英文全称	含义	公式（可复制）	使用场景说明
`variance(col)`/ `var_pop(col)`	Variance (Population)	总体方差	`∑(xᵢ - μ)² / N`	已知全体数据时使用
`var_samp(col)`	Variance (Sample)	样本方差	`∑(xᵢ - x̄)² / (N-1)`	从样本推断总体时使用（无偏估计）
`stddev_pop(col)`	Standard Deviation (Population)	总体标准差	`√(var_pop)`	与总体方差配套使用
`stddev_samp(col)`	Standard Deviation (Sample)	样本标准差	`√(var_samp)`	与样本方差配套使用
`covar_pop(c1, c2)`	Covariance (Population)	总体协方差	`∑(xᵢ - μₓ)(yᵢ - μᵧ) / N`	两变量总体线性关系度量
`covar_samp(c1, c2)`	Covariance (Sample)	样本协方差	`∑(xᵢ - x̄)(yᵢ - ȳ) / (N-1)`	样本数据的协方差估计
`corr(c1, c2)`	Correlation Coefficient	皮尔逊相关系数	`cov(x,y) / (σₓ × σᵧ)`	标准化协方差，范围[-1, 1]

公式符号说明

符号	含义	代码表示
∑	求和	`\sum`或 `SUM()`
xᵢ	第 i 个数据点	`x_i`
μ	总体均值	`\mu`或 `avg_pop`
x̄	样本均值	`\bar{x}`或 `avg_samp`
N	总体数据个数	`N`
n	样本数据个数	`n`
σ	总体标准差	`\sigma`
s	样本标准差	`s`
cov	协方差	`\text{cov}`

1、总体方差/样本方差

1
2


总体方差: var_pop(col)
样本方差: var_samp(col)

方差是衡量一组数据离散程度（波动大小）的核心统计指标。它计算的是每个数据点与平均值之间距离的平方的平均值。

方差越大，数据越分散、波动越大；方差越小，数据越集中、越稳定。

$$ \begin{align} \text{总体方差(Population Variance)} = \frac{\sum_{i=1}^{N}(x_i - \mu)^2}{N}\text{ N为总体数据个数}\ \text{样本方差(Sample Variance)} = \frac{\sum_{i=1}^{n}(x_i - \bar{x})^2}{n-1}\text{ n为样本数据个数} \end{align} $$

关键区别：样本方差的分母用 n-1（贝塞尔校正），这是为了得到对总体方差更准确的无偏估计。大数据分析中，我们通常处理的是样本数据，所以更常用 var_samp()。

场景：分析用户日活跃时长

1
2
3
4
5
6
7


-- 计算用户每日使用时长的波动情况
SELECT 
 AVG(duration_minutes) AS avg_duration, -- 平均时长
 VAR_SAMP(duration_minutes) AS variance_duration, -- 时长方差
 STDDEV_SAMP(duration_minutes) AS stddev_duration -- 时长标准差
FROM user_behavior
WHERE dt BETWEEN '2023-10-01' AND '2023-10-31';

解读结果：

如果 variance_duration值很大 → 用户使用习惯不稳定，有的天用很久，有的天几乎不用
如果值很小 → 用户使用习惯很规律，每天时长差不多

计算方差时为什么要平方？

①避免正负偏差相互抵消；②放大较大偏差的影响，使方差对异常值更敏感。

2、总体标准差/样本标准差

1
2


总体标准差: stddev_pop(col)
样本标准差: stddev_samp(col)

标准差是方差的平方根，它衡量数据点相对于平均值的平均离散程度。与方差相比，标准差的单位与原数据一致，因此更直观、更易于业务解释。

标准差是数据波动大小的“标尺”——标准差越大，数据越分散；标准差越小，数据越集中。

$$ \begin{align} \text{总体标准差 ( Population Standard Deviation ) σ} = \sqrt{\frac{\sum_{i=1}^{N}(x_i - \mu)^2}{N}}\text{ N为总体数据个数}\ \text{样本标准差 ( Sample Standard Deviation ) s} = \sqrt{\frac{\sum_{i=1}^{n}(x_i - \bar{x})^2}{n-1}}\text{ n为样本数据个数} \end{align} $$

📊 标准差 vs 方差（关键区别）

指标	计算公式	单位	直观性	大数据函数
方差	N∑(xi−μ)2	原单位的平方（如：元²、分钟²）	较差，难以直接解释	`VAR_SAMP()`
标准差	方差	与原数据一致（如：元、分钟）	极好，可直接用于业务分析	`STDDEV_SAMP()`

简单比喻：

方差 = 衡量“波动能量”（平方后放大）
标准差 = 衡量“波动幅度”（恢复原单位，可直接感知）

经验法则（68-95-99.7规则）

对于正态分布数据：

68% 的数据落在均值 ± 1个标准差内
95% 的数据落在均值 ± 2个标准差内
99.7% 的数据落在均值 ± 3个标准差内

应用

场景1：分析电商用户订单金额波动

1
2
3
4
5
6
7
8
9


-- 计算用户订单金额的标准差，了解消费稳定性
SELECT 
 user_id,
 AVG(order_amount) AS avg_amount, -- 平均订单金额
 STDDEV_SAMP(order_amount) AS std_amount -- 订单金额标准差
FROM order_table
WHERE dt >= '2023-10-01'
GROUP BY user_id
LIMIT 10;

结果解读示例：

用户A：avg_amount=200元, std_amount=20元 → 消费很稳定（200±20元）
用户B：avg_amount=200元, std_amount=80元 → 消费波动大（有时几十，有时几百）

场景2：监控系统接口响应时间

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


-- 监控API响应时间的稳定性
SELECT 
 api_name,
 AVG(response_time_ms) AS avg_time,
 STDDEV_SAMP(response_time_ms) AS std_time,
 -- 计算波动系数：标准差/平均值，衡量相对波动
 STDDEV_SAMP(response_time_ms) / AVG(response_time_ms) AS cv
FROM api_monitor
WHERE hour = '2023-10-22 10:00:00'
GROUP BY api_name;

场景3：异常检测与监控

1
2
3
4
5
6


-- 识别响应时间异常的服务
SELECT *
FROM api_monitor
WHERE response_time_ms > 
 (SELECT AVG(response_time_ms) + 3 * STDDEV_SAMP(response_time_ms) 
 FROM api_monitor WHERE dt = '2023-10-22')

3σ原则：在正态分布中，99.7%的数据落在均值±3个标准差内。超出此范围可视为异常。

1. 用户分群与画像

低标准差用户：行为稳定，适合标准化服务
高标准差用户：行为多变，需个性化策略

2. 风险评估（金融领域）

股票收益率的标准差 = 波动率 = 风险指标
标准差越大，投资风险越高

3. 质量控制（生产领域）

产品尺寸的标准差衡量生产一致性
六西格玛管理：要求标准差极低

3、总体协方差/样本协方差

1
2


总体协方差: covar_pop(col1, col2)
样本协方差: covar_samp(col1, col2)

协方差衡量两个变量之间的协同变化关系。它告诉你：当一个变量变化时，另一个变量是倾向于同向变化还是反向变化。

协方差的正负表示变化方向，绝对值大小表示变化关系的强弱（但受数据尺度影响）。

$$ \begin{align} \text{总体标准差 ( Population Covariance ) cov(x,y)} = \frac{\sum_{i=1}^{N}(x_i - \mu_x)(y_i - \mu_y)}{N}\text{ N为总体数据个数}\ \text{样本标准差 ( Sample Covariancen ) cov(x,y)} = \frac{\sum_{i=1}^{n}(x_i - \bar{x})(y_i - \bar{y})}{n-1}\text{ n为样本数据个数} \end{align} $$

📈 协方差的三种情况

协方差值	变化关系	图形表现	业务示例
正值	正相关一个↑，另一个也↑	点从左下到右上分布	广告曝光量↑，点击量↑
负值	负相关一个↑，另一个↓	点从左上到右下分布	商品价格↑，销量↓
接近0	无线性关系	点随机分布，无趋势	用户身高与购物金额

协方差的局限性

2. 量纲敏感问题

1
2
3
4
5
6


-- 同一关系，不同单位导致协方差值完全不同
SELECT 
 COVAR_SAMP(price_yuan, sales) AS covar_yuan, -- 价格(元)与销量
 COVAR_SAMP(price_cent, sales) AS covar_cent -- 价格(分)与销量
FROM product_data;
-- covar_cent 会是 covar_yuan 的100倍，但实际关系相同！

2. 无法比较不同变量对

协方差A=1000，协方差B=50 → 不能说A的关系比B强1000/50=20倍
因为量纲不同，绝对值大小无直接可比性

这正是需要“相关系数”的原因：相关系数=标准化协方差，消除了量纲影响。

应用

场景1：分析广告效果

1
2
3
4
5
6
7
8


-- 分析广告曝光量与点击量的关系
SELECT 
 COVAR_SAMP(impressions, clicks) AS covar_imp_clk,
 -- 业务解读：正值表示曝光增加时点击也倾向于增加
 AVG(impressions) AS avg_impressions,
 AVG(clicks) AS avg_clicks
FROM ad_performance
WHERE dt = '2023-10-22';

场景2：用户行为分析

1
2
3
4
5
6
7
8
9


-- 分析用户浏览时长与购买金额的关系
SELECT 
 user_id,
 COVAR_SAMP(session_duration, purchase_amount) AS covar_duration_amount
FROM user_sessions
GROUP BY user_id
HAVING COVAR_SAMP(session_duration, purchase_amount) > 0
-- 只筛选正相关用户：浏览越久，买得越多
LIMIT 10;

场景3：特征选择（机器学习）

1
2
3
4
5
6
7
8


-- 选择与目标变量相关性强的特征
SELECT 
 feature_name,
 COVAR_SAMP(feature_value, target_value) AS covar_with_target
FROM training_data
GROUP BY feature_name
ORDER BY ABS(COVAR_SAMP(feature_value, target_value)) DESC;
-- 协方差绝对值越大，特征与目标变量关系越强

4、皮尔逊相关系数

1

皮尔逊相关系数: corr(c1, c2)

皮尔逊相关系数是协方差的标准化版本，它衡量两个变量之间线性关系的强度和方向，取值范围固定为[-1, 1]，消除了量纲影响，可直接比较不同变量对的相关性强弱。

相关系数 = 标准化的协方差。值越接近±1，线性关系越强；值越接近0，线性关系越弱。

$$ \begin{align} \text{皮尔逊相关系数 ( Correlation Coefficient ): } r(X,Y) = \frac{\text{cov}(x,y)}{\sigma_x \sigma_y} \quad \text{ 其中：cov(x,y)为协方差，σ为总体标准}\

\frac{\sum_{i=1}^{n}(x_i - \bar{x})(y_i - \bar{y})} {\sqrt{\sum_{i=1}^{n}(x_i - \bar{x})^2} \cdot \sqrt{\sum_{i=1}^{n}(y_i - \bar{y})^2}} \quad \text{其中: } -1 \leq r \leq 1

\end{align} $$

应用

场景1：特征工程（机器学习）

1
2
3
4
5
6
7
8


-- 筛选与目标变量相关性强的特征
SELECT 
 feature_name,
 ABS(CORR(feature, target)) AS abs_correlation
FROM model_features
GROUP BY feature_name
ORDER BY abs_correlation DESC;
-- 通常保留|r|>0.3的特征，剔除|r|<0.1的特征

场景2：业务指标监控

1
2
3
4
5
6
7
8


-- 监控关键指标对的相关性是否稳定
SELECT 
 dt,
 CORR(active_users, revenue) AS dau_revenue_corr
FROM daily_business_metrics
GROUP BY dt
ORDER BY dt;
-- 如果某天相关性突然下降，需要排查原因

场景3：用户分群与推荐

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


-- 基于行为相关性进行用户分群
SELECT 
 user_id,
 CASE 
 WHEN CORR(browse_time, purchase_amount) > 0.6 THEN '高价值探索型'
 WHEN CORR(browse_time, purchase_amount) < -0.3 THEN '快速决策型'
 ELSE '普通型'
 END AS user_segment
FROM user_behavior
GROUP BY user_id;

四、分位数函数（数仓常用）

分位数定义

将数据从小到大排序后，分成若干等份的切分点值。常用分位数：

分位数	别名	含义	数据位置
中位数	二分位数	50%分位点	正中间的值
四分位数	Q1, Q2, Q3	25%, 50%, 75%分位点	四等分点
百分位数	P1, P10, P90, P99	1%, 10%, 90%, 99%分位点	百等分点

分位数 vs 平均值

1
2
3
4


-- 平均值受异常值影响大，分位数更稳健
数据: [1, 2, 3, 4, 1000]
平均值: 202 (被1000拉高)
中位数: 3 (不受极端值影响)

1、PERCENTILE() - 精确分位数

1
2
3
4
5
6
7


-- 语法：PERCENTILE(col, p) OVER()
-- 计算精确分位数，但性能较差，适合小数据集
SELECT 
 PERCENTILE(CAST(salary AS BIGINT), 0.5) AS median_salary,
 PERCENTILE(CAST(salary AS BIGINT), 0.25) AS q1_salary,
 PERCENTILE(CAST(salary AS BIGINT), 0.75) AS q3_salary
FROM employee_table;

注意：PERCENTILE()要求列为 BIGINT或 DOUBLE类型，需要显式转换。

2、PERCENTILE_APPROX() - 近似分位数（推荐）

使用 T-Digest算法，内存效率高，适合大数据集。

1
2
3
4
5


-- 计算单个百分位数
PERCENTILE_APPROX(col, p [, B])

-- 计算多个百分位数（返回数组）
PERCENTILE_APPROX(col, array(p1, p2, ...) [, B])

参数说明表

参数	数据类型	必选/可选	说明	示例值
col	DOUBLE, DECIMAL, INT 等数值类型	必选	要计算百分位数的数值列	`response_time`, `amount`
p	DOUBLE 或 ARRAY	必选	百分位数值，范围 [0, 1]	`0.95`（P95） `array(0.5, 0.95, 0.99)`
B	INT	可选	精度控制参数，默认 10000	`10000`, `20000`, `9999`

B 参数的作用机制

内存控制：B 代表算法保留的数据压缩点数量，B 越大，近似精度越高
精确条件：当列中不同值（distinct values）的数量 ≤ B 时，返回精确百分位数
性能权衡：B 值增加会提升计算成本和内存消耗

快速估算，性能优先（大数据集）B=5000

平衡精度与性能（默认推荐）B=10000

高精度需求（小数据集或关键指标）B=50000

1
2
3
4
5
6
7


-- 语法：PERCENTILE_APPROX(col, p [, B])
-- B: 精度参数，默认10000，越大越精确但越慢
SELECT 
 PERCENTILE_APPROX(salary, 0.5) AS median_salary, -- 中位数
 PERCENTILE_APPROX(salary, 0.95) AS p95_salary, -- 95分位
 PERCENTILE_APPROX(salary, 0.99, 100000) AS p99_salary -- 高精度99分位
FROM employee_table;

与 PERCENTILE 函数的区别

函数	输入类型	计算方式	性能	适用场景
PERCENTILE	仅限 INT 类型	精确计算	较慢，需全排序	小数据集，整数列，要求精确
PERCENTILE_APPROX	所有数值类型（DOUBLE等）	近似计算，精度由B控制	快，适合大数据	海量数据，浮点数列，允许近似

1
2
3
4
5
6


-- 错误示例：PERCENTILE 不能用于浮点数
SELECT PERCENTILE(response_time, 0.95) FROM logs; -- 可能报错

-- 正确做法：使用 PERCENTILE_APPROX 或先转换
SELECT PERCENTILE_APPROX(response_time, 0.95) FROM logs;
SELECT PERCENTILE(CAST(response_time AS INT), 0.95) FROM logs; -- 精度丢失

应用

场景1：多个分位数一次性计算

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


-- 使用数组一次计算多个分位数
SELECT 
 PERCENTILE_APPROX(salary, ARRAY(0.25, 0.5, 0.75, 0.9, 0.95, 0.99)) AS percentiles
FROM employee_table;

-- 结果：数组形式 [q1, median, q3, p90, p95, p99]
-- 提取特定分位值：
SELECT 
 percentiles[0] AS q1, -- 25%分位（数组索引从0开始）
 percentiles[1] AS median, -- 中位数
 percentiles[5] AS p99 -- 99%分位
FROM (
 SELECT PERCENTILE_APPROX(salary, ARRAY(0.25, 0.5, 0.75, 0.9, 0.95, 0.99)) AS percentiles
 FROM employee_table
) t;

场景2：系统性能监控（P99延迟）

P99表示在一组数据中，有99%的数据点小于或等于该值，只有1%的数据点大于该值。例如，如果API响应时间的P99是200ms，意味着99%的请求响应时间≤200ms，只有1%的请求超过200ms。

指标	特点	适用场景
平均值	易受极端值影响，掩盖长尾问题	整体趋势分析
P50 中位数	50%数据低于此值，反映典型情况	普通用户体验
P95	95%数据低于此值，关注大多数用户	一般性能要求
P99	99%数据低于此值，关注最差情况	关键业务、SLA保障 P99突增通常表示系统存在性能瓶颈
P999	99.9%数据低于此值	极端场景、金融交易

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


-- 监控API响应时间的P99，用于SLA评估
SELECT 
 api_name,
 COUNT(*) AS request_count,
 AVG(response_time_ms) AS avg_time,
 MIN(response_time_ms) AS min_time,
 MAX(response_time_ms) AS max_time,
 PERCENTILE_APPROX(response_time_ms, 0.99) AS p99_time, -- 关键指标
 PERCENTILE_APPROX(response_time_ms, 0.95) AS p95_time
FROM api_monitor
WHERE dt = '2023-10-22' AND hour = '10'
GROUP BY api_name
HAVING p99_time > 1000 -- 筛选P99超过1秒的API
ORDER BY p99_time DESC;

场景3： IQR 方法

IQR = Q3（第三四分位数，75%分位点） - Q1（第一四分位数，25%分位点）
反映了数据中间50%的离散程度，对极端值不敏感

计算步骤

1
2
3
4
5
6
7


1. 将数据从小到大排序
2. 计算 Q1（第25百分位数）和 Q3（第75百分位数）
3. IQR = Q3 - Q1
4. 异常值边界：
 - 下界 = Q1 - 1.5 × IQR
 - 上界 = Q3 + 1.5 × IQR
5. 任何低于下界或高于上界的数据点视为异常值

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


-- 计算订单金额的IQR并识别异常订单
WITH order_stats AS (
 SELECT 
 PERCENTILE_APPROX(order_amount, 0.25) as q1,
 PERCENTILE_APPROX(order_amount, 0.75) as q3,
 PERCENTILE_APPROX(order_amount, 0.75) - PERCENTILE_APPROX(order_amount, 0.25) as iqr
 FROM orders
 WHERE dt = '2024-01-01'
)
SELECT 
 o.order_id,
 o.order_amount,
 CASE 
 WHEN o.order_amount < (s.q1 - 1.5 * s.iqr) THEN '过低异常'
 WHEN o.order_amount > (s.q3 + 1.5 * s.iqr) THEN '过高异常'
 ELSE '正常'
 END as outlier_type,
 s.q1 - 1.5 * s.iqr as lower_bound,
 s.q3 + 1.5 * s.iqr as upper_bound
FROM orders o
CROSS JOIN order_stats s
WHERE o.dt = '2024-01-01'
 AND (o.order_amount < (s.q1 - 1.5 * s.iqr) 
 OR o.order_amount > (s.q3 + 1.5 * s.iqr));

3、PERCENTILE_CONT() - 连续分位数（Hive 2.2.0+）

1
2
3
4
5
6


-- 语法：PERCENTILE_CONT(p) WITHIN GROUP (ORDER BY col)
-- 返回插值结果（如果分位点不在具体数据点上）
SELECT 
 PERCENTILE_CONT(0.5) WITHIN GROUP (ORDER BY response_time) AS median_time,
 PERCENTILE_CONT(0.9) WITHIN GROUP (ORDER BY response_time) AS p90_time
FROM api_logs;

1
2
3
4
5
6
7
8
9


-- 精确分位数（只支持 int 类型，数据量大时慢）
SELECT percentile(age, 0.5) AS median_age FROM employee;

-- 近似分位数（支持 double，性能好，推荐）
SELECT percentile_approx(salary, 0.95) AS p95_salary FROM employee;

-- 一次算多个分位数（传数组）
SELECT percentile_approx(salary, array(0.5, 0.9, 0.95, 0.99))
FROM employee;

💡 使用建议：生产环境优先用 percentile_approx，效率高、支持任意数值类型。

五、集合聚合（行转列利器）

集合聚合函数概览

函数	返回值类型	功能描述	是否去重	保留顺序
COLLECT_LIST	`ARRAY<T>`	将多行值收集到数组中	❌ 不去重	✅ 保留输入顺序
COLLECT_SET	`ARRAY<T>`	将多行值收集到集合中	✅ 去重	❌ 不保证顺序
MAP_AGG	`MAP<K,V>`	将多行键值对收集为Map	✅ Key去重，最新值覆盖
MAP_FROM_ARRAYS	`MAP<K,V>`	从两个数组创建Map

1. COLLECT_LIST - 收集为数组（保留重复）

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


-- 语法：COLLECT_LIST(expr)
-- 收集所有值，保留重复项，按照输入顺序排列

-- 示例：收集每个部门的员工姓名
SELECT 
 department,
 COLLECT_LIST(employee_name) AS all_employees,
 COUNT(*) AS employee_count
FROM employees
GROUP BY department;

-- 结果示例：
-- IT → ['张三', '李四', '张三', '王五'] -- 张三出现两次
-- HR → ['赵六', '钱七']

应用：

数据透视（行转列）

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


-- 将多行数据转为宽表格式
SELECT 
 user_id,
 MAP_AGG(metric_name, metric_value) AS metrics_map
FROM user_metrics
WHERE dt = '2023-10-22'
GROUP BY user_id;

-- 展开为列
SELECT 
 user_id,
 metrics_map['pv'] AS page_views,
 metrics_map['uv'] AS unique_visitors,
 metrics_map['avg_duration'] AS avg_duration
FROM (
 SELECT 
 user_id,
 MAP_AGG(metric_name, metric_value) AS metrics_map
 FROM user_metrics
 WHERE dt = '2023-10-22'
 GROUP BY user_id
) t;

收集用户行为序列
生成特征数组用于机器学习
数据透视（行转列）

2. COLLECT_SET - 收集为集合（去重）

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


-- 语法：COLLECT_SET(expr)
-- 收集唯一值，不保证顺序

-- 示例：收集每个部门的唯一员工姓名
SELECT 
 department,
 COLLECT_SET(employee_name) AS unique_employees,
 SIZE(COLLECT_SET(employee_name)) AS unique_count
FROM employees
GROUP BY department;

-- 结果示例：
-- IT → ['张三', '李四', '王五'] -- 张三只出现一次
-- HR → ['赵六', '钱七']

注意：COLLECT_SET不保证顺序，如需有序去重，可以这样：

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


-- 有序去重：先排序，再去重
SELECT 
 department,
 COLLECT_LIST(employee_name) AS all_ordered, -- 先收集有序列表
 ARRAY_DISTINCT(COLLECT_LIST(employee_name)) AS unique_ordered -- 再去重
FROM (
 SELECT department, employee_name
 FROM employees
 DISTRIBUTE BY department
 SORT BY department, employee_name
) t
GROUP BY department;

3. MAP_AGG - 创建键值对Map

 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


-- 语法：MAP_AGG(key_expr, value_expr)
-- 将多行键值对收集为Map，重复key会取最后一个value

-- 示例：收集员工ID到姓名的映射
SELECT 
 department,
 MAP_AGG(employee_id, employee_name) AS id_name_map
FROM employees
GROUP BY department;

-- 结果示例：
-- IT → {1001: '张三', 1002: '李四', 1003: '王五'}
-- HR → {2001: '赵六', 2002: '钱七'}

-- 提取Map中的值
SELECT 
 department,
 id_name_map[1001] AS employee_1001, -- 获取key为1001的值
 MAP_KEYS(id_name_map) AS all_ids, -- 获取所有key
 MAP_VALUES(id_name_map) AS all_names -- 获取所有value
FROM (
 SELECT department, MAP_AGG(employee_id, employee_name) AS id_name_map
 FROM employees
 GROUP BY department
) t;

4. MAP_FROM_ARRAYS - 从两个数组创建Map

从两个数组创建Map，要求两个数组长度相同

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


-- 语法：MAP_FROM_ARRAYS(keys_array, values_array)
-- 示例：从两列创建Map
SELECT 
 user_id,
 MAP_FROM_ARRAYS(
 COLLECT_LIST(behavior_type), -- 行为类型数组
 COLLECT_LIST(behavior_count) -- 行为次数数组
 ) AS behavior_map
FROM user_behavior
GROUP BY user_id;

-- 结果示例：
-- 用户1 → {'view': 10, 'click': 5, 'purchase': 2}
-- 用户2 → {'view': 15, 'click': 3}

2. HISTOGRAM_NUMERIC - 数值直方图

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


-- 语法：HISTOGRAM_NUMERIC(expr, nbuckets)
-- 生成数值分布的直方图，nbuckets指定分桶数量

-- 示例：分析工资分布（分10个桶）
SELECT 
 department,
 HISTOGRAM_NUMERIC(salary, 10) AS salary_histogram
FROM employees
GROUP BY department;

-- 结果示例：Map<桶的上界, 频数>
-- IT → {5000.0: 5, 10000.0: 12, 15000.0: 8, ...}
-- 表示：5000以下5人，5000-10000之间12人，以此类推

3. NGRAMS - N-gram分析

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


-- 语法：NGRAMS(array<T>, n, k)
-- 从数组中提取最常见的n-gram序列，返回前k个

-- 示例：分析搜索词的最常见二元组
SELECT 
 NGRAMS(SPLIT(search_query, ' '), 2, 5) AS top_bigrams
FROM search_logs
WHERE dt = '2023-10-22';

-- 结果示例：
-- [{'ngram': ['大数据', '学习'], 'estfrequency': 100},
-- {'ngram': ['Hive', '教程'], 'estfrequency': 85}]

💻 实战应用场景

场景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
25
26


-- 收集用户按时间排序的行为序列
SELECT 
 user_id,
 COLLECT_LIST(
 STRUCT(
 event_time,
 event_type,
 page_id
 )
 ) AS behavior_sequence
FROM (
 SELECT 
 user_id,
 event_time,
 event_type,
 page_id
 FROM user_events
 WHERE dt = '2023-10-22'
 DISTRIBUTE BY user_id
 SORT BY user_id, event_time -- 保证按用户和时间排序
) t
GROUP BY user_id
LIMIT 10;

-- 结果：每个用户的行为轨迹数组
-- 用于后续的序列分析、路径分析、用户画像

场景2：订单商品聚合

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


-- 将订单中的所有商品聚合
SELECT 
 order_id,
 COLLECT_LIST(
 NAMED_STRUCT(
 'product_id', product_id,
 'product_name', product_name,
 'quantity', quantity,
 'price', price
 )
 ) AS order_items,
 SUM(quantity * price) AS order_total,
 COUNT(DISTINCT product_id) AS distinct_products
FROM order_items
GROUP BY order_id
HAVING order_total > 1000
ORDER BY order_total DESC;

场景3：用户标签聚合

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


-- 将用户的多个标签聚合为Map
SELECT 
 user_id,
 MAP_AGG(tag_category, tag_value) AS user_tags
FROM user_tags
WHERE tag_weight > 0.5
GROUP BY user_id;

-- 结果示例：用户标签Map
-- 用户1 → {'兴趣': '科技', '年龄段': '25-30', '消费水平': '高'}
-- 用户2 → {'兴趣': '美食', '年龄段': '30-35', '城市': '成都'}

场景4：数据透视（行转列）

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


-- 将多行数据转为宽表格式
SELECT 
 user_id,
 MAP_AGG(metric_name, metric_value) AS metrics_map
FROM user_metrics
WHERE dt = '2023-10-22'
GROUP BY user_id;

-- 展开为列
SELECT 
 user_id,
 metrics_map['pv'] AS page_views,
 metrics_map['uv'] AS unique_visitors,
 metrics_map['avg_duration'] AS avg_duration
FROM (
 SELECT 
 user_id,
 MAP_AGG(metric_name, metric_value) AS metrics_map
 FROM user_metrics
 WHERE dt = '2023-10-22'
 GROUP BY user_id
) t;

场景5：用户相似度计算（基于共同行为）

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


-- 计算用户间的共同行为数量
WITH user_behavior_set AS (
 SELECT 
 user_id,
 COLLECT_SET(page_id) AS viewed_pages
 FROM page_views
 WHERE dt = '2023-10-22'
 GROUP BY user_id
)
SELECT 
 a.user_id AS user1,
 b.user_id AS user2,
 SIZE(ARRAY_INTERSECTION(a.viewed_pages, b.viewed_pages)) AS common_pages_count,
 -- 计算Jaccard相似度
 SIZE(ARRAY_INTERSECTION(a.viewed_pages, b.viewed_pages)) * 1.0 /
 SIZE(ARRAY_UNION(a.viewed_pages, b.viewed_pages)) AS jaccard_similarity
FROM user_behavior_set a
JOIN user_behavior_set b
WHERE a.user_id < b.user_id
 AND SIZE(ARRAY_INTERSECTION(a.viewed_pages, b.viewed_pages)) > 5
ORDER BY common_pages_count DESC
LIMIT 100;

`collect_list` vs `collect_set`

1
2
3
4
5
6
7
8
9


-- collect_list：保留重复值，保留顺序（不严格保证）
SELECT user_id, collect_list(product_id) AS bought_items
FROM orders
GROUP BY user_id;

-- collect_set：自动去重，无序
SELECT user_id, collect_set(product_id) AS unique_items
FROM orders
GROUP BY user_id;

配合 concat_ws 实现字符串拼接（经典面试题）：

1
2
3
4
5


SELECT
user_id,
concat_ws(',', collect_list(cast(product_id AS string))) AS items_str
FROM orders
GROUP BY user_id;

六、高级分组聚合：`GROUPING SETS / CUBE / ROLLUP`

这是数仓多维分析的核心能力，相当于一次 SQL 跑出多种粒度的聚合结果。

示例数据

假设有订单表：orders(year, month, region, sales)

1. GROUPING SETS：指定哪些维度组合

1
2
3
4
5
6
7
8
9


SELECT year, month, region, sum(sales)
FROM orders
GROUP BY year, month, region
GROUPING SETS (
    (year, month, region), -- 最细粒度
    (year, month), -- 按年月
    (year), -- 按年
    () -- 总计
);

等价于 4 条 SQL 的 union all，但只扫一次表。

2. ROLLUP：层级递进（小计 + 总计）

1
2
3


SELECT year, month, region, sum(sales)
FROM orders
GROUP BY year, month, region WITH ROLLUP;

等价于：

1
2
3
4
5
6


GROUPING SETS (
 (year, month, region),
 (year, month),
 (year),
 ()
)

3. CUBE：所有维度组合

1
2
3


SELECT year, month, region, sum(sales)
FROM orders
GROUP BY year, month, region WITH CUBE;

等价于 2³ = 8 种组合：

1
2


(year,month,region), (year,month), (year,region), (month,region),
(year), (month), (region), ()

4. grouping__id 区分聚合层级

1
2
3
4
5
6


SELECT
year, month, region,
sum(sales) AS total,
grouping__id AS gid
FROM orders
GROUP BY year, month, region WITH CUBE;

grouping__id 可标识当前行是哪一个维度组合的小计，方便下游处理。

【五】Hive 存储格式与压缩

Tue, 19 May 2026 21:45:12 +0800

一、行存储、列存储

假设有一张订单表 orders：

order_id	user_id	amount	city	status
1001	U01	99.5	Beijing	PAID
1002	U02	50.0	Shanghai	PAID
1003	U03	200.0	Beijing	UNPAID

1.1 存储和读取区别

🟦 行存储（Row-Based）：一整行的字段紧挨着，读到一行就能拿到所有列。（当满足条件需要选取一整行数据时，行查询最快）

[1001, U01, 99.5, Beijing, PAID ] ← 第1行整体连续存放
[1002, U02, 50.0, Shanghai, PAID ] ← 第2行整体连续存放
[1003, U03, 200.0, Beijing, UNPAID] ← 第3行整体连续存放

1

SELECT amount FROM orders WHERE city = 'Beijing'

1
2


读 Block → 拿到整行(5 列) → 丢掉 4 列 → 只用 amount 和 city
读 Block → 拿到整行(5 列) → 丢掉 4 列 → 只用 amount 和 city

问题：你只要 2 列，但磁盘把 5 列全读进来了，80% 的 IO 是浪费。

🟩 列存储（Columnar）：同一列的所有值紧挨着，不同列分块存放（甚至不同文件）。（当满足条件需要选取指定少数列数据时，列查询最快）

order_id 列: [1001, 1002, 1003] ← 同一列连续存放
user_id 列: [U01, U02, U03 ]
amount 列: [99.5, 50.0, 200.0]
city 列: [Beijing, Shanghai, Beijing]
status 列: [PAID, PAID, UNPAID]

1

SELECT amount FROM orders WHERE city = 'Beijing'

1
2


只读 city 列 → 过滤出 Beijing 对应的行号 [0, 2]
只读 amount 列对应位置 → 拿到 [99.5, 200.0]

优势：要几列读几列，IO 直接降到行存的 2/5。表越宽（列越多），收益越大。

1.2 为什么列存还能"压缩率超高"？

因为同一列的数据类型相同、取值相近，压缩算法效率惊人。指的就是ORC

列	行存放一起的数据	列存放一起的数据	压缩效果
status	`1001,U01,99.5,Beijing,PAID,1002,U02,...`	`PAID,PAID,PAID,PAID,UNPAID,PAID...`	列存可用 RLE（Run-length encoding 游程编码）：`(PAID×4, UNPAID×1, PAID×1)`，压缩到几个字节
city	类型混杂	`Beijing,Shanghai,Beijing,Beijing...`	字典编码：`{0:Beijing, 1:Shanghai}` + `[0,1,0,0...]`，整数比字符串小得多
amount	类型混杂	`99.5, 50.0, 200.0, 100.5...`	位压缩 / Delta 编码：数值范围小，能用少 bit 数表示

实测数据：同一份数据，TextFile 行存 100GB → ORC/Parquet 列存常常压缩到 10-20GB，5-10 倍的压缩比是常态。

1.3 列存的"杀手锏"：向量化 + 谓词下推

① 向量化执行（Vectorized Execution）

列存中同列数据类型一致，可以一次性加载一批（如 1024 个 int）到 CPU SIMD 寄存器，单条指令处理多个数据。
行存做不到，因为一行里有 int/string/decimal 混在一起，CPU 没法批量处理。

1
2


行存：for (row in rows) { process(row.amount) } ← 一次处理 1 个
列存：SIMD_ADD(amount[0..1024]) ← 一次处理 1024 个

② 谓词下推（Predicate Pushdown, PPD）

列存文件在每个列块里预先存了 min/max/Bloom Filter，可以在不读数据的情况下跳过整块。

1
2
3
4


查询：WHERE amount > 1000
列存元数据：Block1 [min=10, max=500] → 直接跳过！
 Block2 [min=800, max=2000] → 需要读
 Block3 [min=50, max=300] → 直接跳过！

3 个块只读 1 个，IO 再降 67%。

1.4 那行存就一无是处了吗？

完全不是。行存有它无可替代的场景：

① 行存的优势场景

OLTP 事务处理：INSERT INTO ... VALUES (...) 一次写入一整行，行存只需写一个连续区域；列存要拆成 N 列分别写到 N 个位置。
按主键查整行：SELECT * FROM orders WHERE id=1001，行存一次 IO 拿到整行；列存要去 N 个列块拼回来。
频繁更新单条记录：行存原地改即可；列存要改 N 个列文件。

② 列存的劣势

写入慢：一行数据要拆开写到多个地方，且通常要批量积攒后落盘。
不适合点查：查一整行要重新"拼装"。
更新困难：通常只支持追加（Append-Only），更新要靠 Delta 文件 + Compaction（这就是 Delta/Iceberg/Hudi 在解决的问题）。

模式类似于HDFS中的edits/fsimage/Checkpoint：
- Delta 文件（或日志文件）：记录对表数据的所有增量更改（增、删、改）。每次事务提交都会生成新的增量文件。类比edits文件
- 基础文件（如Parquet/ORC文件）：存储表数据在某个时间点的完整列式存储快照。类比fsimage文件
- Compaction：将一段时间内积累的 Delta 文件合并到基础文件中，生成新的、更紧凑的基础文件，并清理旧的增量文件。这正是为了避免 Delta 文件无限增长，保证查询性能。类比Checkpoint

1.5 行存 vs 列存对比总表

维度	行存储	列存储
物理布局	一行所有字段连续存放	一列所有值连续存放
读取单位	整行	单列
列裁剪	❌ 必须读整行	✅ 只读需要的列
压缩率	低（数据异构）	高（数据同构，5-10×）
谓词下推	弱	强（列级 min/max/Bloom）
向量化执行	难	天然支持 SIMD
写入性能	✅ 快（一次写一行）	❌ 慢（拆成 N 列写）
更新性能	✅ 原地更新	❌ 通常 Append + Compaction
点查（按主键）	✅ 快	❌ 需拼装多列
范围扫描 + 聚合	❌ 全列读取浪费 IO	✅ 极快
典型代表	MySQL/Oracle/PostgreSQL（堆表）、TextFile、SequenceFile、Avro	ORC、Parquet、ClickHouse、Doris、StarRocks、HBase（列族级伪列存）
适用场景	OLTP、高频写入、点查、整行读取	OLAP、分析查询、大宽表、聚合统计

1.6 混合模式：PAX（行列混合）

现实中纯行/纯列都有缺陷，ORC 和 Parquet 实际上用的是 PAX（Partition Attributes Across）——折中方案：

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


┌─────────────────────────────────┐
│ Row Group / Stripe（一组行） │ ← 先按行切大块（便于并行/分割）
│ ├─ Column Chunk: order_id │ ← 块内再按列存放
│ ├─ Column Chunk: user_id │
│ ├─ Column Chunk: amount │
│ └─ Column Chunk: city │
└─────────────────────────────────┘

[行组1]
 - 列块1: 用户ID数据: [1, 2, 3, 4, 5, ... 100万]
 - 列块2: 用户名数据: ["Alice", "Bob", "Charlie", ...]
 - 列块3: 行为数据: ["login", "click", "login", ...]
 - 列块4: 时间戳数据: [100, 101, 102, ...]

块间：按行切分（每个 Stripe/RowGroup 包含若干行），方便 HDFS 分块并行处理。
块内：按列存放，享受列存的所有优势（压缩、向量化、PPD）。

这就是为什么 ORC/Parquet 能兼具列存性能 + HDFS 分布式可分割性。

二、Hive 存储格式详解

Hive 的存储格式决定了数据在 HDFS 上以什么物理形式落盘，直接影响查询性能、压缩率、IO 开销和计算引擎兼容性。

一个简单的协作流程：你的SQL -> Hive(翻译成MapReduce作业) -> MapReduce框架调用InputFormat读取数据、调用SerDe解析成行对象 -> 执行计算 -> 调用SerDe序列化、调用OutputFormat写入数据

在Hive 本身只是"翻译器"，真正读写文件的是底层的 InputFormat/OutputFormat 和 SerDe（序列化/反序列化器）。

存储格式演进路线：早期：TextFile → SequenceFile/RCFile → 列存储时代：ORC/Parquet → 数据湖格式：Delta/ICE/Hudi

2.1 Hive 支持的主流存储格式总览

格式	类型	是否列式	压缩支持	可分割	典型场景
TextFile	行式（默认）	❌	支持（Gzip/Bzip2/LZO）	部分支持	原始日志、ODS 落地、跨系统交换
SequenceFile	行式（K-V 二进制）	❌	支持	✅	Hadoop 内部中间数据
RCFile	行列混合（已淘汰）	✅(早期)	支持	✅	历史遗留
ORC	列式（Hive 原生）	✅	内置（Zlib/Snappy/LZ4/Zstd）	✅	Hive 数仓首选（DWD/DWS/ADS）
Parquet	列式（跨生态）	✅	内置（Snappy/Gzip/Zstd）	✅	Spark/Impala/Presto 通用，湖仓首选
Avro	行式（Schema 演化友好）	❌	支持	✅	Kafka→Hive 入湖、Schema 频繁变更
JSON/CSV	行式（文本）	❌	支持	部分	调试、外部数据导入

2.2 逐个格式详解

① TextFile（默认行式）

本质：纯文本文件，Hive默认格式
存储结构：行存储，每行一条记录，列之间用分隔符（默认 \001）
```
1,Alice,login,2023-10-01
2,Bob,click,2023-10-01
3,Charlie,login,2023-10-02
```
常见类型：CSV、JSON、TSV、日志文件
建表示例
1 2 3 4 5 6 7 8

CREATE TABLE logs_text ( id INT, name STRING, action STRING, log_date Date ) ROW FORMAT DELIMITED FIELDS TERMINATED BY ' ' STORED AS TEXTFILE;
数据存入：当MapReduce的Mapper开始读取第一行1,Alice,login,2023-10-01时，TextInputFormat只是简单地将它作为一个Text对象（可理解为Java的String）读出。这里几乎没有计算开销，所以“无序列化开销”是优点。

数据读取：此时数据在内存里只是一串文本1,Alice,login,2023-10-01。Hive不知道这串文本的各个部分是什么。这时，SerDe（默认是LazySimpleSerDe）出场了。它需要根据Hive元数据（你在建表时定义的(id INT, name STRING, action STRING, log_date DATE)）来“解释”这行文本。SerDe会按照你指定的分隔符（比如,）将这行文本拆分成字段数组["1", "Alice", "login", "2023-10-01"]，然后逐个字段地尝试转换为目标类型（String转成INT，String转成DATE）。这个“转换”过程就是反序列化，它发生在数据读取时，而不是文件本身存储了类型信息。

所以，“不存schema”导致每次查询都要做一次“文本解析+类型转换”，这是性能损耗的来源之一。
优点：
- 人类可读，易于调试
- 跨平台，兼容性极佳，几乎所有工具都支持，易导入导出
- 无序列化/反序列化开销
缺点：
- 无压缩，存储效率最低
  - 行存储，同一行存储的数据类型不同，无法进行数据压缩
- 不存 schema，类型靠 Hive 元数据"解释"
  - 需要按照定义的元数据类型，将文本转为元数据类型
- 不支持复杂类型
- 查询性能最差，要全表扫描。
  - 这是由TextInputFormat的“行定位”方式决定的。它无法像ORC/Parquet那样，在文件的“头部”或“尾部”找到数据的统计信息（如最大值、最小值）或索引。
  - 当你执行SELECT * FROM user_log WHERE id = 100时，优化器（如果有的话）发现TextFile没有任何可以用来“跳过”部分数据的信息。InputFormat只能老老实实地从文件第一字节开始，逐行读取、切分、然后由SerDe转换成行对象，再判断id是否等于100。即使你要找的数据在最后一行，也必须读完前面所有行。这就是“全表扫描”。
- 可结合Gzip、Bzip2使用（系统自动价差，执行查询时自动解压），但使用这种方式，hive不会对数据进行切分，从而无法对数据进行并行操作。会导致 MapReduce 只能单 Mapper 处理整个文件。
  - 正常情况（未压缩）：假设user_log.txt有1GB，HDFS默认块大小128MB，那么这个文件会被切分成约8个块，存储在不同的DataNode上。TextInputFormat可以为每个块启动一个Mapper来并行处理。因为文本文件很容易从任意位置开始找到一行的起始点（向后扫描直到遇到换行符即可）。
  - Gzip压缩后：Gzip/Bzip2是整体压缩算法。为了解压1,Alice,...这段数据，可能需要依赖前面几十KB的压缩上下文。这意味着：
    
    无法从任意点开始解压：你无法从第128MB的位置（第二个块的起始点）开始解压，因为你没有之前的压缩字典。
    - 只能单线程：因此，TextInputFormat在遇到一个Gzip压缩的.txt文件时，不会把它切成多个Split，而是将整个文件作为一个Split，交给**一个Mapper** 处理。这就完全丧失了MapReduce的并行能力，性能瓶颈极大。
使用场景：
- ODS 原始落地层
- 数据交换格式
- 小规模测试数据

② SequenceFile（行式二进制）

本质：Hadoop键值对序列化格式
存储结构：行存储，二进制格式

文件结构：

1
2
3
4


Header (版本、Key/Value类名、压缩信息)
Record 1: [Key长度][Value长度][Key][Value]
Record 2: ...
Sync Marker (用于切分)

三种压缩模式：

1
2
3
4
5
6


// 1. 不压缩
SequenceFile.createWriter(..., CompressionType.NONE);
// 2. 记录压缩（只压缩Value）
SequenceFile.createWriter(..., CompressionType.RECORD);
// 3. 块压缩（多个记录一起压缩）
SequenceFile.createWriter(..., CompressionType.BLOCK);

Hive中使用：

1
2
3
4


CREATE TABLE seq_table (
 id INT,
 data STRING
) STORED AS SEQUENCEFILE;

优点：
- 比 TextFile 高效，可分割，适合MapReduce
- 支持压缩（块压缩效率高）
- 支持二进制数据
缺点：
- 仍是行式，非列存储，分析性能有限
- 非Hive专属，优化有限
- 可读性差
使用场景：MapReduce中间数据存储
现状：已逐渐被 ORC/Parquet 替代，更多用于 MR 中间结果。

③ RCFile (Record Columnar File) - 早期的列存储尝试

设计思想：先按行分块，块内按列存储

物理结构：

1
2
3
4
5
6
7
8


Row Group 1:
 Sync Marker
 Metadata Header
 Column 1 Data (压缩)
 Column 2 Data (压缩)
 Column 3 Data (压缩)
Row Group 2:
 ...

特点：
- 混合行列存储：大方向是行分块，块内是列存储
- 轻量级索引：每个行组的元数据

示例：

1
2
3
4
5


CREATE TABLE rc_table (
 user_id INT,
 name STRING,
 age INT
) STORED AS RCFILE;

现状：已被ORC取代，基本淘汰

④ ORC（Optimized Row Columnar）⭐ Hive 首选

Hive 阵营的"亲儿子"，由 Hortonworks 在hive 0.11版本提出，为Hive优化的极致列存储

核心特性：列存储 + 轻量级索引 + 复杂类型支持 + ACID事务

文件结构

每个ORC文件由一个或多个stripe组成，每个scripe大小250MB，stripe相当于RowGroup概念

 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


┌──────────────────────────────────────────────┐
│ File Header（魔数 "ORC"，3 字节） │
├──────────────────────────────────────────────┤
│ Stripe 1（默认 ~250MB，是并行处理的基本单位） │
│ ├─ Index Data │
│ │ ├─ 每列的 min/max/sum/count（实现谓词下推，跳过不满足条件的数据块） │
│ │ ├─ Row Group 索引（每 10000 行一组） │
│ │ └─ Bloom Filter（可选，针对等值过滤） │
│ ├─ Row Data（列式存放的实际数据） 
│ │ ├─ 实际数据，先取部分行，对行进行按列存储 │
│ │ ├─ Column 1: Stream A、Stream B... │
│ │ ├─ Column 2: Stream A、Stream B... │
│ │ └─ ... │
│ └─ Stripe Footer（各列的编码方式、位置） │
├──────────────────────────────────────────────┤
│ Stripe 2 ... │
├──────────────────────────────────────────────┤
│ Stripe N ... │
├──────────────────────────────────────────────┤
│ File Footer（schema、行组(Stripe)列表、各列统计信息（每个col的数据类型等） │
├──────────────────────────────────────────────┤
│ Postscript（压缩类型、Footer 长度、版本） │
└──────────────────────────────────────────────┘

在读取文件时，会seek到文件尾部读PostScript，从里面解析到File Footer长度，再读FileFooter，
从里面解析到各个Stripe信息，再读各个Stripe，即从后往前读。

核心优化技术

三层索引体系：

层级	粒度	作用
File 级	整个文件	每列的 min/max/count，跳过整个文件
Stripe 级	~250MB	每个 Stripe 内每列的 min/max，跳过整个 Stripe
Row Group 级	10000 行	每个 Row Group 内每列的 min/max，跳过 Row Group
Bloom Filter	可配置	等值查询时快速判断"一定不存在"

实现谓词下推，跳过不满足条件的数据块

高效编码：

1
2
3
4


// ORC支持的编码
- Integer Column Encoding (RLE, Delta, Zigzag)
- String Dictionary Encoding (字典编码)
- Bit Packing (位打包)

复杂类型支持：

1
2
3
4
5
6
7


-- 支持struct, array, map, union
CREATE TABLE nested_orc (
 id INT,
 user STRUCT<name:STRING, age:INT>,
 tags ARRAY<STRING>,
 scores MAP<STRING, INT>
) STORED AS ORC;

4- Stream 概念

ORC 把一列拆成多个 Stream（流） 物理存储：

PRESENT Stream：位图，标记每行是否为 NULL。
DATA Stream：实际数据。
LENGTH Stream：变长字段（如 STRING）的长度。
DICTIONARY_DATA Stream：字典编码时的字典内容。
SECONDARY Stream：辅助流（如 Decimal 的小数部分）。

好处：NULL 值不占数据空间，字典和数据分离便于压缩。

ORC性能调优参数

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


CREATE TABLE optimized_orc (
 id BIGINT,
 data STRING
) STORED AS ORC
TBLPROPERTIES (
 "orc.compress"="SNAPPY", -- 压缩算法：NONE, ZLIB, SNAPPY
 "orc.compress.size"="262144", -- 压缩块大小
 "orc.stripe.size"="67108864", -- Stripe大小，默认64MB
 "orc.row.index.stride"="10000", -- 索引粒度
 "orc.create.index"="true", -- 创建索引
 "orc.bloom.filter.columns"="id", -- 布隆过滤，加速等值查询
 "orc.bloom.filter.fpp"="0.05" -- 误判率
);

ORC ACID事务支持（Hive 3+）

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


-- 1. 启用ACID
SET hive.support.concurrency=true;
SET hive.txn.manager=org.apache.hadoop.hive.ql.lockmgr.DbTxnManager;

-- 2. 创建事务表
CREATE TABLE acid_table (
 id INT,
 value STRING
) STORED AS ORC
TBLPROPERTIES ('transactional'='true');

-- 3. 支持更新/删除/合并
UPDATE acid_table SET value='new' WHERE id=1;
DELETE FROM acid_table WHERE id=2;
MERGE INTO acid_table AS target ...

核心优势

列式存储：只读需要的列，IO 大幅降低。
三级索引：File / Stripe / Row Group（每 1 万行一个 index），支持谓词下推（PPD），可在不读数据的情况下用 min/max 跳过整段。
轻量编码：RLE（游程编码）、字典编码、Bit Packing。
ACID 支持：Hive 3.x 事务表必须用 ORC（INSERT/UPDATE/DELETE）。
向量化执行：配合 hive.vectorized.execution.enabled=true，按 1024 行一批处理，性能翻倍。

⑤ Parquet（列式，跨生态）⭐ 湖仓首选

由 Twitter + Cloudera 2015-5月联合提出，Spark/Impala/Presto/Flink 原生支持，是 Delta/Iceberg/Hudi 的默认底层格式。

Parquet文件是以二进制方法存储，不可直接读取，文件中包括文件的数据和元数据，所以Parquet格式是自解析的。

存储Parquet数据时会按照Block大小设置行组的大小，一个mapper任务处理的最小单位是block，所以一行由一个mapper处理，增大任务并行度。

Parquet 文件结构

 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


+---------------------------+
| Magic Number "PAR1" | # 4字节，文件起始标识（校验是否是一个Parquet文件）
+---------------------------+
| |
| Row Group 1 | # 第一个行组 （默认 128MB，对齐 HDFS Block） 
| +-----------------+ |
| | Column Chunk 1 | | # id列 （一整列在该 Row Group 的数据）
| | Page 1 | |
| | Page 2 | |
| +-----------------+ |
| | Column Chunk 2 | | # name列
| | Page 1 | |
| +-----------------+ |
| | ... | |
| |
| Row Group 2 | # 第二个行组
| ... |
| |
+---------------------------+
| File MetaData | # 文件元数据
| +-----------------+ |
| | Schema | | # 数据结构
| | Row Group 1 Meta| | # 行组1统计信息
| | Row Group 2 Meta| | # 行组2统计信息
| | Column Metadata | | # 列统计信息
| +-----------------+ |
+---------------------------+
| MetaData/Footer Length | # 4字节，元数据长度
+---------------------------+
| Magic Number "PAR1" | # 4字节，文件结束标识
+---------------------------+

Dremel 嵌套模型（Parquet 的"独门绝技"）

Parquet 通过 Repetition Level（重复层级） 和 Definition Level（定义层级） 把任意嵌套结构（Struct/Array/Map）“扁平化"成列存。

示例 schema：
message User {
 required int64 id;
 repeated group address {
 optional string city;
 optional string zip;
 }
}

一个用户可以有多个 address，每个 address 有 city/zip 可空。Parquet 用两个额外的整数列记录"这是第几次重复"和"嵌套到第几层是有值的”，从而精确还原结构。

ORC 也支持嵌套，但实现不如 Parquet 优雅，这也是 Parquet 在 JSON/半结构化数据场景占优的原因。

关键点：Parquet 自身没有事务能力，是靠 Delta/Iceberg/Hudi 在它之上叠加事务层实现的。而 ORC 在 Hive 3.x 是原生事务表的唯一选择。

⑥ Avro（行式，Schema 演化）

行式 + Schema 与数据一起存，对字段增减、类型变更非常友好。
常用于 Kafka → Hive 的入湖链路（配合 Schema Registry）。
分析性能弱于 ORC/Parquet，但灵活性强。

2.3 ORC vs Parquet（重点对比）

维度	ORC	Parquet
生态归属	Hive 原生	Spark/Impala/Presto 原生
压缩率	通常更高（5%-10%）	略低，但已很优秀
查询性能（Hive）	更快（向量化、PPD 更成熟）	也很快
查询性能（Spark）	良好	更优（Spark 默认）
嵌套类型支持	支持，但不如 Parquet 优雅	原生 Dremel 模型，更强
ACID 事务	✅ Hive 事务表必须 ORC	❌ 不支持 Hive 事务
索引	File/Stripe/RowGroup 三级 + Bloom	RowGroup + Page 统计
湖仓兼容	Iceberg 支持	Delta/Iceberg/Hudi 默认

① 建表对比

ORC 建表（Hive 推荐）

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


CREATE TABLE dwd_order_orc (
 order_id BIGINT,
 user_id STRING,
 amount DECIMAL(18,2),
 city STRING,
 create_time TIMESTAMP
)
PARTITIONED BY (dt STRING)
CLUSTERED BY (user_id) INTO 32 BUCKETS
STORED AS ORC
TBLPROPERTIES (
 "orc.compress"="ZSTD", -- 压缩算法
 "orc.compress.size"="262144", -- 压缩块大小 256KB
 "orc.stripe.size"="268435456", -- Stripe 大小 256MB
 "orc.row.index.stride"="10000", -- Row Group 行数
 "orc.create.index"="true", -- 启用索引
 "orc.bloom.filter.columns"="user_id,city",-- 对高频过滤列建 Bloom
 "orc.bloom.filter.fpp"="0.05" -- Bloom 误判率
);

Parquet 建表（Spark / 多引擎推荐）

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


CREATE TABLE dwd_order_parquet (
 order_id BIGINT,
 user_id STRING,
 amount DECIMAL(18,2),
 city STRING,
 create_time TIMESTAMP
)
PARTITIONED BY (dt STRING)
STORED AS PARQUET
TBLPROPERTIES (
 "parquet.compression"="SNAPPY", -- 或 ZSTD
 "parquet.block.size"="134217728", -- Row Group 大小 128MB
 "parquet.page.size"="1048576", -- Page 大小 1MB
 "parquet.enable.dictionary"="true", -- 启用字典编码
 "parquet.bloom.filter.enabled"="true" -- Bloom（1.12+）
);

② 结构对应关系

Parquet	ORC	含义
File	File	整个文件
Row Group（128MB）	Stripe（250MB）	并行处理基本单位
Column Chunk	Column（在 Stripe 内）	一列在一个并行单元的数据
Page（1MB）	Row Group（10000 行）	编码压缩 + 索引最小单位
Page Header 统计	Row Index	行级粒度索引
Column Chunk 统计	Stripe-level Statistics	块级索引
File Metadata	File Footer	文件级元数据

③ 索引与谓词下推（PPD）

ORC 的索引能力（更强）

查询: SELECT * FROM orders 
WHERE amount > 1000 AND city = 'Beijing'

ORC 的过滤路径：

File Footer：看整个文件的 amount.max，如果 < 1000 直接跳过。
Stripe Statistics：逐个 Stripe 看 amount.max，过滤掉。
Row Group Index（每 10000 行）：精确到 10000 行粒度过滤。
Bloom Filter：对 city = 'Beijing' 直接判断"该 Row Group 是否可能包含 Beijing"。
读取数据：上面层层过滤后只剩很少的数据需要真正解码。

Parquet 的索引能力

传统 Parquet：只有 Row Group 级和 Column Chunk 级的统计（min/max/null_count）。
Parquet 2.x 新增 Page Index：补齐了 Page 级（≈ ORC 的 Row Group 级）索引。
Bloom Filter：Parquet 1.12+ 才支持（晚于 ORC）。

结论：在 Hive 引擎下，ORC 的谓词下推历史更成熟、过滤更精细；但 Parquet 新版本已经追上，且在 Spark/湖仓生态中表现优秀。

④ 编码与压缩技术

1）编码（Encoding）—— 减少数据本身的体积

编码方式	原理	适用列	ORC	Parquet
RLE（游程编码）	`AAAABBC` → `(A,4)(B,2)(C,1)`	重复值多的列（如 status、gender）	✅	✅
字典编码（Dictionary）	用整数 ID 代替字符串，建一张字典	低基数字符串（如 city、product_name）	✅	✅
Bit Packing（位压缩）	用最少 bit 表示数值（如 0-100 只需 7 bit）	小范围整数	✅	✅
Delta 编码	存差值（如时间戳、自增 ID）	单调/近单调数值	✅	✅
Run Length + Dictionary 混合	字典 + 游程	高重复低基数	✅	✅
FOR（Frame of Reference）	存"基准值 + 偏移"	范围集中的数值	✅（变种）	❌

2）压缩（Compression）—— 在编码基础上再压一层

压缩算法	压缩比	速度	ORC 默认	Parquet 默认	适用场景
None	1×	极快	-	-	测试
Snappy	2-3×	快	可选	✅ 默认	平衡型，查询友好
Zlib (Gzip)	3-4×	中等	✅ 默认	可选	存储成本敏感
LZ4	2×	极快	可选	可选	实时查询
Zstd	3-5×	快	可选	可选	新选择，压缩比+速度俱佳
Brotli	4-5×	慢	❌	可选	冷数据归档

实战推荐：现代生产环境优先用 ZSTD，压缩比接近 Zlib，速度接近 Snappy。

三、Hive 压缩格式

核心理解：Hive 不自己实现压缩，它复用 Hadoop 的压缩 Codec 体系。所以 Hive 压缩 = Hadoop 压缩 + MapReduce 压缩参数 + Hive 自己的开关。

3.1 Hive 中的压缩格式（总览）

Hive 中常见的压缩格式有 6 种，决策核心是三个维度：压缩率、压缩/解压速度、是否可切分（splittable）。

压缩格式	扩展名	压缩率	压缩速度	解压速度	是否可切分	Hadoop 原生支持
DEFLATE	.deflate	中	中	中	❌	✅
Gzip	.gz	高	慢	中	❌	✅
Bzip2	.bz2	极高	极慢	慢	✅	✅
LZO	.lzo	中	快	快	✅（需建索引）	❌（需额外安装）
Snappy	.snappy	中	极快	极快	❌	❌（需额外安装）
LZ4	.lz4	中	极快	极快	❌	✅
Zstd	.zst	高	快	快	❌	✅（新版本）

📌 关键认知：

是否可切分 决定了一个大文件能否被多个 Map 并行处理 → 大数据场景下极其重要。
Gzip / Snappy 不可切分，所以大文件用 Gzip 会丢掉并行度。
解决方式：用 ORC / Parquet 这种自带分块的列式存储 + 内部 Snappy/Zlib 压缩（块级别可切分）。

3.2 MR 支持的压缩格式 & Hadoop 压缩类（Codec）

输入压缩：MR自动识别并解压（通过InputFormat自动处理）

输出压缩：需显式配置

1
2
3
4
5
6
7
8
9


<!-- mapred-site.xml 配置示例 -->
<property>
 <name>mapreduce.output.fileoutputformat.compress</name>
 <value>true</value>
</property>
<property>
 <name>mapreduce.output.fileoutputformat.compress.codec</name>
 <value>org.apache.hadoop.io.compress.SnappyCodec</value>
</property>

MapReduce 通过 CompressionCodec 接口 调用各种压缩算法，每种格式对应一个 Codec 类。

Hadoop 编码/解码器类（必背）

压缩格式	对应的 Codec 类
DEFLATE	`org.apache.hadoop.io.compress.DefaultCodec`
Gzip	`org.apache.hadoop.io.compress.GzipCodec`	Java自带，无需Native库
Bzip2	`org.apache.hadoop.io.compress.BZip2Codec`	纯Java实现，支持分片
LZO	`com.hadoop.compression.lzo.LzopCodec`	需单独安装，支持索引创建
Snappy	`org.apache.hadoop.io.compress.SnappyCodec`	需Native库(libsnappy.so)，性能极佳
LZ4	`org.apache.hadoop.io.compress.Lz4Codec`	需Native库，超高速压缩
Zstd	`org.apache.hadoop.io.compress.ZStandardCodec`

📌 这些类的作用：告诉 MR / Hive 用什么算法去压缩或解压数据。

Native库检查命令：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


# 检查Hadoop Native库支持
hadoop checknative

# 预期输出示例：
# Native library checking:
# hadoop: true /opt/hadoop/lib/native/libhadoop.so.1.0.0
# zlib: true /lib64/libz.so.1
# snappy: true /usr/lib64/libsnappy.so.1
# lz4: true /usr/lib64/liblz4.so.1
# bzip2: false
# openssl: false

3.3 压缩性能比较（经典对比数据）

以一个 ~8.3 GB 文本文件压缩为例（业内常引用的对比）：

算法	压缩后大小	压缩比	压缩速度	解压速度
Gzip	1.8 GB	78%	17.5 MB/s	58 MB/s
Bzip2	1.1 GB	86%	2.4 MB/s	9.5 MB/s
LZO	2.9 GB	65%	49.3 MB/s	74.6 MB/s
Snappy	~2.2 GB	73%	250+ MB/s	500+ MB/s

选型口诀（🔥面试高频）

业务场景	推荐
高压缩比的存储优化（冷数据/归档）	Bzip2 / Gzip
低CPU开销的计算优化（Shuffle 中间数据）	Snappy / LZ4
支持分片+较好压缩比的平衡选择（大日志文本）	LZO（带索引）/ Bzip2
现代综合最优	Zstd

📌 结论：

I/O 密集型作业 → 加压缩往往提速（少传输 = 快）。
CPU 密集型作业 → 压缩反而拖慢（CPU 已满，再压缩没资源）。

3.4 Hadoop 压缩参数（必须熟记）

Hadoop 中压缩可发生在三处：输入端、Map 输出端、Reduce 输出端。

① 输入端（通常自动识别扩展名解压）

在core-site.xml中配置如下（Hadoop通过扩展名判断是否支持某种编解码器）

1
2
3
4
5
6


io.compression.codecs =
 org.apache.hadoop.io.compress.GzipCodec,
 org.apache.hadoop.io.compress.DefaultCodec,
 org.apache.hadoop.io.compress.BZip2Cod
 org.apache.hadoop.io.compress.Lz4Codec,
 org.apache.hadoop.io.compress.SnappyCodec

② Map 输出端压缩参数（Shuffle 优化的关键）

1
2
3
4


-- 默认为false，设置为true启用压缩
mapreduce.map.output.compress = true
-- 默认为DefaultCodec，可以使用core-site.xml中设置的其他编码器
mapreduce.map.output.compress.codec = org.apache.hadoop.io.compress.SnappyCodec

③ Reduce 输出端（最终落盘）压缩参数

1
2
3
4
5
6


-- 默认为false，设置为true启用压缩
mapreduce.output.fileoutputformat.compress = true
-- 默认为DefaultCodec，可以使用core-site.xml中设置的其他解码器
mapreduce.output.fileoutputformat.compress.codec = org.apache.hadoop.io.compress.GzipCodec
-- 输出使用的压缩类型，默认为RECORD
mapreduce.output.fileoutputformat.compress.type = BLOCK # 推荐 BLOCK，比 RECORD 压缩率高

📌 type 参数：

NONE：不压缩
RECORD：按记录压缩（压缩率低）
BLOCK：按块压缩（推荐，压缩率高，仅作用于 SequenceFile）

3.5 Hive 在 Map 端 / Reduce 端的压缩方式

Hive 在 Hadoop 参数上又封装了两个自己的开关，必须先打开 Hive 的开关，再设置 Hadoop 参数才生效。

① Map 端压缩（中间结果，影响 Shuffle）

1
2
3
4
5
6
7
8


-- 启用Map输出压缩（推荐Snappy/LZ4）
SET hive.exec.compress.intermediate=true; -- 总开关
SET hive.intermediate.compression.codec=org.apache.hadoop.io.compress.SnappyCodec;
SET hive.intermediate.compression.type=BLOCK;

-- 底层对应对应MR参数
SET mapreduce.map.output.compress=true;
SET mapreduce.map.output.compress.codec=org.apache.hadoop.io.compress.SnappyCodec;

👉 目的：减少 Map → Reduce 之间的网络传输和磁盘 IO。
👉 推荐：Snappy / LZ4（压缩快、解压快，CPU 开销低）。

② Reduce 端压缩（最终输出到 HDFS）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


-- ① Hive 总开关
set hive.exec.compress.output = true;

-- ② 底层 Hadoop 参数
-- 开启mapreduce最终输出数据压缩
set mapreduce.output.fileoutputformat.compress = true;
-- 开启mapreduce最终输出数据压缩
set mapreduce.output.fileoutputformat.compress.codec = org.apache.hadoop.io.compress.GzipCodec;
-- 开启mapreduce最终输出数据压缩为块压缩
set mapreduce.output.fileoutputformat.compress.type = BLOCK;

👉 目的：节省 HDFS 存储空间。
👉 推荐：Gzip / Zstd / Bzip2（压缩率优先）。

③ Hive 压缩流程图（建议背下来）

 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


+---------------------------+ +---------------------------+ +---------------------------+ +---------------------------+
| 输入文件 | | 自动解压 | | Map处理 | | Map输出压缩 |
| |-->| |-->| |-->| |
| [data.gz/.snappy/...] | | (自动识别压缩格式) | | (执行Map任务逻辑) | | (hive.exec.compress. |
| | | | | | | intermediate控制) |
+---------------------------+ +---------------------------+ +---------------------------+ +---------------------------+
 ↓
 +---------------------------+
 | 中间压缩配置 |
 | |
 | hive.exec.compress. |
 | intermediate=true |
 | |
 | 常用codec: |
 | • Snappy (速度快) |
 | • LZ4 (快速) |
 +---------------------------+

+---------------------------+ +---------------------------+ +---------------------------+ +-------------------------+
| 网络传输(Shuffle) | | 解压 | | Reduce处理 | | 输出压缩 |
| |-->| |-->| |-->| |
| (压缩数据通过网卡传输) | | (准备Reduce处理) | | (执行Reduce任务逻辑) | | (hive.exec.compress. |
| ↓网络带宽优化 | | | | | | output控制) |
+---------------------------+ +---------------------------+ +---------------------------+ +-------------------------+
 ↓
 +---------------------------+ +--------------------------+
 | 最终输出配置 | | 写入HDFS |
 | | | |
 | hive.exec.compress. |-->| |
 | output=true | | (压缩存储，节省空间) |
 | | | |
 | 常用codec: | +-------------------------+
 | • Gzip (压缩率高) | | 常用存储格式: |
 | • Zstandard (平衡性好) | | • ORC+ZSTD |
 +---------------------------+ | • Parquet+SNAPPY |
 +--------------------------+

3.6 与 Hive 存储格式（ORC / Parquet）的配合

Hive 真实生产中，压缩往往和列式存储格式绑定使用：

存储格式	默认压缩	可选压缩
TextFile	无	Gzip / Bzip2 / Snappy
SequenceFile	RECORD	RECORD / BLOCK
ORC	Zlib	Zlib / Snappy / LZO / Zstd
Parquet	Snappy	Snappy / Gzip / LZO / Zstd

📌 建表时指定压缩示例：

1
2
3
4
5
6
7
8


-- ORC + Snappy
CREATE TABLE t_orc (id INT, name STRING)
STORED AS ORC
TBLPROPERTIES ("orc.compress" = "SNAPPY");
-- Parquet + Gzip
CREATE TABLE t_parquet (id INT, name STRING)
STORED AS PARQUET
TBLPROPERTIES ("parquet.compression" = "GZIP");

📌 重要认知：

ORC / Parquet 天然按块压缩 → 即使用 Snappy / Gzip 这种不可切分算法，仍然可以并行处理（因为切分发生在 stripe / row group 级别）。
所以列式存储 + Snappy 是当前数仓的事实标准组合。

【四】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

【三】Hive 抽样

Fri, 15 May 2026 23:10:00 +0800

在 Hive 场景中：

数据量：TB / PB 级
查询方式：MapReduce / Spark（高延迟）
全表扫描成本极高

👉 所以抽样的本质是：

用小数据近似大数据特征（加速分析/调试）

二、Hive 抽样的三大类型

Hive 一共有 3 种主流抽样方式：

类型	关键语法	随机性	性能	是否需要分桶
✅ 分桶抽样（Bucket Sampling）	TABLESAMPLE(BUCKET …)	✅ 好	✅ 高	✅ 必须
✅ 块抽样（Block Sampling）	TABLESAMPLE(…)	❌ 差	✅ 非常高	❌
✅ 随机抽样（Random Sampling）	rand() + limit	✅ 真随机	❌ 较差	❌

三、分桶抽样（TABLESAMPLE+BUCKET 最推荐）

最推荐的高性能抽样方式，利用Hive分桶机制直接定位数据块，速度最快。

1. 分桶表的核心设计

通过建表的分桶设计，在物理层面上按照bucket_id = hash(user_id) % 32让数据均匀分布到32个桶中，之前学到的分桶可以优化两个分桶表的JOIN操作，使得JOIN时user_id 相同的一定落在同一个桶中（一个节点内），避免了不同node节点之间的shuffle（无需将同一个键值的记录汇总到一起，分桶建表时就已经放入同一个桶中了）。

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


传统HDFS存储：
data_2023-10-01.txt (包含所有user_id的记录)
data_2023-10-02.txt

分桶表存储结构：/user/hive/warehouse/user_bucketed/dt=2023-10-01/
 ├── 000000_0 (bucket-00000) - user_id哈希值%32=0的记录
 ├── 000001_0 (bucket-00001) - user_id哈希值%32=1的记录
 ├── ...
 └── 000031_0 (bucket-00031) - user_id哈希值%32=31的记录

分桶文件命名规则
分桶文件名格式：
bucket文件: 00000N_0
- 前6位: 桶编号（5位数字，从00000开始）
- 下划线: 分隔符
- 最后数字: 桶内文件编号（分桶文件可再分小文件）

示例：000025_0
- 桶编号: 25
- 文件编号: 0(第一个文件)

我们可以理解为分桶优化了表的存储方式，使得在查找时无需进行复杂的数据交换。

分桶抽样之所以成立，是因为 hash(user_id) 近似均匀分布 → 随机选一个 bucket ≈ 全局数据的一个“随机子集”。

2. 分桶抽样执行流程

相信现在你已经明白为什么会有分桶抽样了，通过分桶建表，我们将数据随机分布在桶中，所以通过抽取桶就可以等价于随机抽样。可以理解为空间换时间，事先将数据准备好了，这样随机抽样时无需遍历所有的行来达到随机的效果。

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


-- 1. 创建分桶表
CREATE TABLE user_bucketed (
 user_id BIGINT,
 user_name STRING,
) CLUSTERED BY (user_id) INTO 32 BUCKETS
STORED AS ORC;

-- 2. 查询示例 基于分桶列的抽样（需已创建分桶表）
SELECT * FROM user_bucketed 
TABLESAMPLE(BUCKET 3 OUT OF 8 ON user_id);
-- 注意：Hive中的桶编号是0-based（从0开始）但在TABLESAMPLE语法中，x是1-based（从1开始）
-- 执行过程分解：
1. 计算抽样桶号：桶数=32, 抽样组数=32/8=4（最后会取出4个桶，相当于抽取了4/32=1/8的数据）
2. 目标桶：
 k=0: 2 + 0×8 = 2
 k=1: 2 + 1×8 = 10
 k=2: 2 + 2×8 = 18
 k=3: 2 + 3×8 = 26
 k=4: 2 + 4×8 = 34 ≥ 32，停止
得到 3, 3+8=11, 3+16=19, 3+24=27

3. 直接读取4个对应的HDFS文件：000002_0, 000010_0, 000018_0, 000026_0
4. 无需全表扫描，直接定位物理文件，返回结果

参数说明：BUCKET x OUT OF y ON col

y：总桶数（必须是分桶数的约数）
x：抽取的桶编号（从1开始）
抽样比例 = 1/y

如果表不是分桶表，但是仍使用分桶抽样，如下

1
2
3


-- 随机分桶抽样（无需分桶列）
SELECT * FROM user_bucketed 
TABLESAMPLE(BUCKET 3 OUT OF 8 ON RAND()) s;

则具体执行过程：

1️⃣ 启动MapReduce任务，全表扫描每一行（因为没有预分桶）
2️⃣ 对每一行执行
- 调用RAND()生成随机数
- 计算RAND()值的哈希：hash(rand())
- 哈希值对8取模，得到桶号(0-7)：bucket_id = hash(rand()) % 32 (虚拟bucket)
3️⃣ 过滤出桶号=2的行
4️⃣ 输出数据

👉 本质 = 全表 scan + 行级 hash + 过滤

四、块抽样（TABLESAMPLE）

本质是直接在 HDFS 数据块（block）（默认128MB/256MB）层面做抽样，而不是逐行随机抽

步骤：

1️⃣ 获取文件列表（Partition / Directory）
2️⃣ 生成 InputSplit（HDFS block）
3️⃣ 按比例选部分 InputSplit ✅（关键，1-3步多是发生在scan之前）
4️⃣ Map任务只读取这些 block（scan）
5️⃣ 输出数据

举例：已知表 = 1TB，block = 128MB。执行快抽取10%的步骤如下

总共 1T/128M ≈ 8000 个 block，执行TABLESAMPLE(10 PERCENT) 时，Hive从8000个block中随机选800个，只启动对应的 map task（只启动对应的 map task）

👉 因此：

✅ speed非常快（减少IO） ❌ 不严格随机（受数据分布影响，比如按日期分区写入， block 抽样可能只抽到某几天的数据，抽的是文件块，而不是打散后的数据）

1、按数据大小百分比抽样

抽取原hive表中10%的数据，并保存到新表中

1

SELECT * FROM logs TABLESAMPLE(0.1 PERCENT)

2、按固定大小抽样

1
2


抽样
SELECT * FROM logs TABLESAMPLE(100M)

3、按行数抽样

按行数抽样（可能不准确，因Hive不严格维格维护行数）

1

SELECT * FROM logs TABLESAMPLE(1000 ROWS);

✅ 适合场景

✔ 快速预览数据 ✔ 调试 pipeline ❌ 不适合统计分析（不随机）

4、❌TABLESAMPLE + WHERE

4.1、一起使用导致的问题

❌无法和where一起使用：根据块抽样的执行步骤可知，TABLESAMPLE发生在scan读取之前，WHERE发生在数据读取后，所以二者同时出现就会导致结果比例不确定、抽样失去意义、Hive 难以保证正确性的问题，具体如下：

1）结果比例不确定

举个例子：10% 的 gender='F' 意思是先找到gender='F'的所有记录，再从中抽取10%

但是如果使用TABLESAMPLE 和 WHERE => 先选取10% block → 再筛选 gender=‘F’。👉 最终可能 <10%

2）抽样失去意义

gender='F' 本来只有 5%。先抽block，可能抽不到任何 female 记录

3）Hive 难以保证正确性的问题

Hive设计原则：抽样应该严格作用在表级别，而不是过滤后数据

4.2、替代方案

WHERE + RAND

先过滤，再抽样的逻辑正确

1
2
3
4


SELECT *
FROM table
WHERE gender = 'F'
 AND RAND() <= 0.1;

子查询包装

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


-- 先抽样，后过滤
SELECT * FROM (
 SELECT * FROM user_behavior 
 TABLESAMPLE(1 PERCENT) -- 全表1%的块
) sampled_data
WHERE event_type = 'click'; -- 在抽样结果中过滤

-- 先过滤，后抽样
SELECT * FROM (
 SELECT * FROM user_behavior 
 WHERE dt = '2023-10-01' -- 先按条件筛选
) filtered_data
TABLESAMPLE(10 PERCENT); -- 在筛选结果上抽样= 0.1;

CTE表达式

1
2
3
4
5
6


WITH sampled_orders AS (
 SELECT * FROM orders TABLESAMPLE(100M)
)
SELECT * FROM sampled_orders
WHERE amount > 1000
AND status = 'COMPLETED';

临时表存储

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


-- 1. 创建抽样临时表
CREATE TEMPORARY TABLE temp_sample AS
SELECT * FROM large_table TABLESAMPLE(0.5 PERCENT);

-- 2. 在临时表上执行复杂查询
SELECT user_id, COUNT(*) as cnt
FROM temp_sample
WHERE event_time >= '2023-10-01'
GROUP BY user_id
HAVING cnt > 5;

精确行数抽样

1
2
3
4
5
6
7
8
9


SELECT *
FROM (
 SELECT *
 FROM table
 WHERE gender = 'F'
 DISTRIBUTE BY rand()
 SORT BY rand()
) t
LIMIT 1000;

五、随机抽样（RAND）

最灵活的抽样方式，但需要全表扫描，性能较差。

limit关键字限制抽样返回的数据，其中rand函数前的distribute和sort关键字可以保证数据在mapper和reducer阶段是随机分布的。

5.1、概率过滤

步骤：

Map scan
过滤：每一行执行 rand(123) -> 0~1 满足条件<= 0.1的保留。（没有固定种子，每次就可以得到不同的随机序列）
输出

👉 本质：每行独立 Bernoulli 抽样（概率采样）

所以没有Reduce阶段、全局排序、网络shuffle

1
2


-- 随机抽取10%的数据
SELECT * FROM orders WHERE RAND() <= 0.1;

适合场景

✔ 大数据快速抽样
✔ SQL调试
✔ 统计分析近似

结果行数 ≠ 精确10% （因为WHERE RAND() <= 0.1的概率抽样是波动的）

5.2、可复现随机样本

步骤：

Map scan
过滤：每一行执行 rand(123) -> 0~1 满足条件<= 0.05的保留。（固定种子为123，每次就可以得到相同的随机序列）
shuffle：DISTRIBUTE BY RAND(123) 把数据随机打散到 reducer
局部排序：SORT BY RAND(123) 每个reducer内部排序

1
2
3
4
5


-- 可重现的随机抽样（设置随机种子）
SELECT * FROM orders 
WHERE RAND(123) <= 0.05 -- 固定种子，结果可重现
DISTRIBUTE BY RAND(123) SORT BY RAND(123)
LIMIT 1000;

适合场景

✔ 实验可复现（A/B Test）
✔ 调试稳定样本
✔ 模型训练数据抽样

5.3、局部随机

步骤：

Map scan
shuffle：DISTRIBUTE BY RAND() 把数据随机打散到 reducer
局部排序：SORT BY RAND() 每个reducer内部排序

1
2
3
4


SELECT * FROM orders 
WHERE col = 'xxx'
DISTRIBUTE BY RAND() SORT BY RAND()
LIMIT 1000;

比 ORDER BY RAND() 快
比 WHERE RAND() 更随机

但是它不是全局随机！（因为多个 reducer 各自排序）👉 偏随机（但不是严格均匀）

5.4、全局随机

步骤：

Map scan
shuffle：所有数据 shuffle 到一个reducer节点
全局排序：ORDER BY RAND() 1个reducer内部全局排序

1
2
3
4


SELECT *
FROM orders 
ORDER BY rand()
LIMIT 1000;

完全随机，但是单reducer和全shuffle会导致整个过程很慢

适合场景

✔ 少量数据 ✔ 强随机要求

❌ 不适合大表

写法	抽样方式	是否全表扫描	是否Shuffle	随机性	性能
`WHERE RAND() <= p`	✅ 概率过滤	✅ 是	❌ 否	✅ 好	✅ 高
`RAND(seed)` + distribute/sort	✅ 可复现随机	✅ 是	✅ 有	✅ 很好	⚠️ 中
`distribute by rand() sort by rand()`	✅ 局部随机	✅ 是	✅ 有	⚠️ 一般	⚠️ 中
`order by rand()`	✅ 全局随机	✅ 是	✅ 超大	✅ 最好	❌ 慢

×分层抽样（按分组比例）

1
2
3
4
5
6
7
8


-- 每个城市抽取5%的用户
SELECT * FROM (
 SELECT *,
 ROW_NUMBER() OVER (PARTITION BY city ORDER BY RAND()) as rn,
 COUNT(*) OVER (PARTITION BY city) as total
 FROM users
) t
WHERE rn <= total * 0.05;

五、实战案例：用户行为分析抽样

场景：分析国庆期间高活跃用户

 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


-- 错误做法（可能漏掉目标用户）
SELECT user_id, COUNT(*) as login_count
FROM user_logs 
TABLESAMPLE(100M) -- 随机块，可能不包含国庆数据
WHERE login_date BETWEEN '2023-10-01' AND '2023-10-07'
GROUP BY user_id
HAVING login_count > 10;

-- 正确做法1：先过滤后抽样
SELECT * FROM (
 SELECT user_id, COUNT(*) as login_count
 FROM user_logs 
 WHERE login_date BETWEEN '2023-10-01' AND '2023-10-07'
 GROUP BY user_id
 HAVING login_count > 10
) active_users
TABLESAMPLE(20 PERCENT); -- 在结果集上抽样

-- 正确做法2：分桶表高效查询
CREATE TABLE user_logs_bucketed (
 user_id BIGINT,
 login_date STRING
) CLUSTERED BY (user_id) INTO 100 BUCKETS
PARTITIONED BY (dt STRING)
STORED AS ORC;

-- 分区剪枝 + 分桶抽样
SELECT user_id, COUNT(*) as login_count
FROM user_logs_bucketed
TABLESAMPLE(BUCKET 1 OUT OF 20 ON user_id)
WHERE dt BETWEEN '2023-10-01' AND '2023-10-07'
GROUP BY user_id;

【一】Hive数据类型

Wed, 13 May 2026 22:47:21 +0800

一、Hive 数据类型详解

Hive的数据类型主要分为两大类：基本数据类型 和复杂数据类型。理解它们，是写出高效、正确HiveQL的基础。

1. 基本数据类型（Primitive Types）

类似于传统关系数据库（如MySQL）中的数据类型，用于存储单个值。

类型	说明	示例	应用场景与注意事项
`TINYINT`	1字节有符号整数，范围[-128, 127]	`1`， `-100`	存储状态码、性别编码等小范围枚举值。
`SMALLINT`	2字节有符号整数，范围[-32,768, 32,767]	`1000`， `-20000`	存储稍大范围的ID或编码。
`INT`	4字节有符号整数，范围约±21亿	`1000000`， `-1`	最常用的整数类型，用于存储用户ID、订单数等。
`BIGINT`	8字节有符号整数，范围极大	`10000000000L`	存储非常大的计数，如全局唯一长ID、交易流水号。
`FLOAT`	4字节单精度浮点数	`3.14159`	对精度要求不高的科学计算或指标。存在精度损失。
`DOUBLE`	8字节双精度浮点数	`3.141592653589793`	最常用的浮点数类型，如金额、比率、统计数据。
`DECIMAL(p, s)`	高精度小数，p是总位数，s是小数位	`DECIMAL(10,2)`表示 `12345678.12`	【面试重点】存储精确数值，如金融金额、精确费率。避免`DOUBLE`计算时的精度问题。
`BOOLEAN`	布尔型，TRUE/FALSE	`TRUE`	存储标记位，如“是否VIP”、“是否完成”。
`STRING`	变长字符串，无需定义长度	`‘Hello’`, `‘张三’`	【最常用】存储文本、名称、地址等。Hive的`STRING`优于`VARCHAR`，更通用。
`VARCHAR(max)`	变长字符串，需指定最大长度	`VARCHAR(100)`	在需要限制长度的场景使用，与`STRING`类似但功能稍少。
`CHAR(n)`	定长字符串，不足补空格	`CHAR(10)`	较少用，用于长度严格固定的场景。
`DATE`	日期，格式 ‘YYYY-MM-DD’	`‘2023-10-26’`	存储日期。
`TIMESTAMP`	时间戳，精度到纳秒	`‘2023-10-26 14:30:00.123’`	存储精确的时间点，如日志时间、订单创建时间。

最佳实践建议：

整数优选INT，大数用BIGINT。
浮点优选DOUBLE，金额/精确值必用DECIMAL。
字符串优选STRING。

2. 复杂数据类型（Complex Types）

这是Hive区别于传统SQL的强大特性，允许在单个列中存储结构化的数据集合，非常适合处理半结构化数据（如JSON）。

类型	说明	定义与示例数据	访问与查询方式
`ARRAY<data_type>`	相同类型元素的数组，索引从0开始。	`hobbies ARRAY<STRING>` 数据： `[‘篮球’， ‘音乐’， ‘阅读’]`	`SELECT hobbies[0] FROM user; -- 获取‘篮球’` `SELECT hobby FROM user LATERAL VIEW explode(hobbies) tmp AS hobby; -- 展开数组`
`MAP<primitive_type, data_type>`	键值对集合，键必须是基本类型。	`properties MAP<STRING, STRING>` 数据： `{‘age’ -> ‘25’, ‘city’ -> ‘成都’}`	`SELECT properties[‘city’] FROM user; -- 获取‘成都’` `SELECT map_keys(properties) FROM user; -- 获取所有键`
`STRUCT<col_name : data_type, ...>`	类似于C语言的结构体，可以包含多个命名字段。	`address STRUCT<province:STRING, city:STRING, detail:STRING>` 数据： `{‘四川’， ‘成都’， ‘天府三街’}`	`SELECT address.city FROM user; -- 获取‘成都’`
`UNIONTYPE<data_type, ...>`	多种数据类型中的一种。	较少用，了解即可。

示例DDL（创建表）：

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


CREATE TABLE IF NOT EXISTS user_info (
 uid BIGINT COMMENT '用户ID',
 name STRING COMMENT '姓名',
 salary DECIMAL(10,2) COMMENT '薪资',
 tags ARRAY<STRING> COMMENT '用户标签',
 ext_info MAP<STRING, STRING> COMMENT '扩展信息，如：{"department":"bigdata","level":"P6"}',
 address STRUCT<province:STRING, city:STRING, district:STRING> COMMENT '居住地址'
)
COMMENT '用户信息表'
PARTITIONED BY (dt STRING COMMENT '按天分区') -- 这里用到了你图片中的Partition模型
ROW FORMAT DELIMITED
FIELDS TERMINATED BY '\t' -- 列分隔符
COLLECTION ITEMS TERMINATED BY ',' -- 数组和Struct中元素分隔符
MAP KEYS TERMINATED BY ':' -- Map键值对分隔符
STORED AS TEXTFILE; -- 存储格式

复杂类型的优势：避免了将所有字段“扁平化”存储带来的大量NULL值和表结构僵化问题，使数据模型更贴近业务逻辑。

3. 数据类型转换与NULL

隐式转换：Hive会在必要时自动进行类型转换，如INT转DOUBLE。但反向转换（如DOUBLE转INT）或STRING转数字可能会失败或丢失精度。
显式转换：使用CAST函数，如 CAST(‘123’ AS INT)。
NULL值：Hive中所有数据类型的字段都支持NULL值。NULL与任何值运算、比较结果均为NULL。过滤需用 WHERE column IS NULL。

二、Hive 数据模型

Hive中包含以下数据模型（db、table、external table、partition、bucket）定义了表、库、分区等逻辑结构及其在HDFS上的物理映射。

组件	含义与HDFS表现	适用场景与目的
Database (DB)	命名空间，用于组织和管理表。在HDFS上表现为`${hive.metastore.warehouse.dir}`目录下的一个子文件夹。	多项目/团队管理：将不同业务或项目的表隔离在不同的DB下，避免表名冲突。例如，创建 `db_fin`（财务库）和 `db_user`（用户库）。
Table	Hive中核心的数据逻辑抽象。在HDFS上表现为所属DB目录下的一个子文件夹。表中的数据文件就存储在此文件夹内。	存储结构化/半结构化数据：绝大多数数据分析和数仓建设的基础。例如 `user_info`（用户信息表）、`order_fact`（订单事实表）。
External Table	外部表。与普通表类似，但Hive只管理其元数据，不管理其数据生命周期。数据文件可以存放在HDFS任意指定路径。	【非常重要】 1. 数据共享与安全：数据由其他程序（如Spark、Flink）生成，或被多系统共享，不希望删除表时连带删除数据。 2. 数仓ODS层标配：原始数据层通常使用外部表指向HDFS上的原始数据路径，实现数据与计算的解耦。
Partition	分区。根据表中某列（通常是日期、地区等）的值，将数据在物理上划分到不同的子目录中。 Table目录下的子目录。目录名格式如 `dt=2023-10-26`。	【核心优化手段】 1. 大幅提升查询效率：查询时通过`WHERE`条件指定分区，Hive只会扫描对应分区的数据，避免全表扫描（分区裁剪）。 2. 按时间、地域等维度管理数据：例如按 `dt`（天）、`province`（省）分区，是数仓的常见做法。
Bucket	分桶。在分区内（或表内），根据另一列的哈希值，将数据划分为多个固定数量的文件。同一个表目录下根据hash散列之后的多个文件	【高级优化手段】 1. 提升JOIN和采样效率：对两个表在相同列上分桶且桶数成倍数，可以大大优化`Map-Side Join`效率。 2. 数据倾斜优化：与分区结合，对倾斜键进行分桶有时能缓解问题。 3. 高效随机采样：`TABLESAMPLE`语法可以高效地对桶进行采样。

1. Table（内部表/托管表）

在HDFS中表现为其所属数据库目录下的一个文件夹。
本质：Hive不仅管理这张表的元数据（如表名、列、类型），还全权管理其数据生命周期。

创建与存储：

1
2
3
4
5
6
7


-- 创建一张内部表
CREATE TABLE my_managed_table (
 id INT,
 name STRING
);
-- 加载数据后，数据文件会默认存储在Hive仓库目录下，例如：
-- /user/hive/warehouse/mydb.db/my_managed_table/datafile1.txt

删除操作的影响：执行 DROP TABLE my_managed_table;时，表的元数据和HDFS上的数据文件都会被删除。
适用场景：
- 数仓的中间层和结果层：例如，经过清洗、转换后的明细数据表（DWD）、聚合汇总表（DWS/DWT）。这些数据由Hive ETL作业生成，并完全由Hive管理。
- 临时或生命周期明确的数据：不需要被其他引擎共享的中间结果。

2. External Table（外部表）

与table类似，不过其数据存放位置可以在任意指定路径。
本质：Hive只管理这张表的元数据，但不管理数据本身。数据文件可以位于HDFS的任何位置。

创建与存储：

1
2
3
4
5
6
7


-- 创建一张外部表，必须使用 `EXTERNAL` 关键字和 `LOCATION` 子句
CREATE EXTERNAL TABLE my_external_table (
 log_time STRING,
 client_ip STRING
)
ROW FORMAT DELIMITED FIELDS TERMINATED BY ','
LOCATION '/data/logs/web_server/'; -- 指向一个已存在数据的HDFS路径

删除操作的影响：执行 DROP TABLE my_external_table;时，仅删除元数据，HDFS上的数据文件会原封不动地保留。
适用场景：
- 数仓的原始数据层（ODS）：这是最经典的应用。日志采集（Flume）、消息队列（Kafka）中的数据通常由其他程序写入HDFS固定目录。用外部表关联此目录，可实现“数据不动，计算就绪”。
- 多引擎共享数据：当一份数据需要被Spark、Flink、Presto等多个计算引擎分析时，使用外部表是最佳实践，避免数据被某个引擎误删。
- 基于现有数据文件建表：已有数据文件在HDFS上，只需通过Hive为其建立映射关系进行分析。

📊 内部表 vs. 外部表（面试必考题）

特性	内部表（Managed Table）	外部表（External Table）
关键字	默认，或`MANAGED`	`EXTERNAL`
数据管理	Hive全权管理	Hive只管理元数据
存储位置	默认仓库目录	用户`LOCATION`指定的任意路径
`DROP TABLE`后果	元数据 + 数据文件均被删除	仅元数据被删除，数据文件保留
数仓应用层	DWD, DWS, ADS, 临时表	ODS（原始数据层）
设计哲学	“我的数据，我负责”	“你的数据，我来读”

3. Partition（分区）

在HDFS中表现为table目录下的子目录。
本质：根据表中某一列（通常是日期、地区、类别等）的值，在物理存储上将数据拆分到不同的子目录中。目录名格式为 分区列=值。

创建与存储：

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


-- 创建一张按日期（dt）和地区（country）分区的表
CREATE TABLE logs (
 user_id BIGINT,
 event STRING
)
PARTITIONED BY (dt STRING, country STRING); -- 分区列是虚拟列，不体现在数据文件中

-- 加载数据到特定分区
LOAD DATA INPATH '/input/log_20231026_us.csv' INTO TABLE logs PARTITION (dt='2023-10-26', country='US');
-- 数据在HDFS上的存储路径类似：
-- /user/hive/warehouse/logs/dt=2023-10-26/country=US/datafile.csv
-- /user/hive/warehouse/logs/dt=2023-10-26/country=CN/datafile.csv

核心价值：分区裁剪：当查询带有分区条件时，Hive只会读取相关分区目录下的数据，跳过无关分区，从而极大提升查询性能。

1
2


-- 这个查询只会扫描 dt='2023-10-26', country='US' 这个子目录，而不是全表
SELECT COUNT(*) FROM logs WHERE dt='2023-10-26' AND country='US';

适用场景：
- 按时间范围查询：这是最主要、最普遍的用法，例如按年/月/日（dt）分区，查询某一天的数据。
- 按业务维度筛选：如按国家、省份、产品线分区。
- 数据生命周期管理：可以方便地删除整个过期分区（ALTER TABLE DROP PARTITION），效率极高。

4. Bucket（分桶/桶表）

在HDFS中表现为同一个表（或分区）目录下根据hash散列之后的多个文件。
本质：在分区内（或表内），根据某一列值的哈希值，将数据均匀分发到固定数量的桶（文件）中。

创建与存储：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


-- 创建一张对user_id分桶的表
CREATE TABLE user_bucketed (
 user_id INT,
 username STRING
)
CLUSTERED BY (user_id) INTO 4 BUCKETS -- 根据user_id的哈希值，将数据散列到4个桶文件中
STORED AS ORC;

-- 插入数据后，在HDFS上该表或分区的目录下，会出现4个文件，例如：
-- 000000_0, 000001_0, 000002_0, 000003_0
-- 所有user_id哈希值相同的记录，一定会被分到同一个文件里。

分桶后的最终效果

user_orders_bucketed user_info_bucketed
 桶0文件 桶0文件
 桶1文件 桶1文件 
 桶2文件 桶2文件
 桶3文件 桶3文件
 ↓ ↓
 Mapper 0 Mapper 0
 (只读桶0文件) (只读桶0文件)
 ↘ ↙
 相同的user_id已经在同一个桶中！
 可以在Mapper本地直接JOIN

核心价值：
1. 高效抽样：TABLESAMPLE(BUCKET x OUT OF y)可以直接对特定桶进行高效、随机的采样。
2. 提升特定JOIN性能：如果两个表基于相同的JOIN键分桶，且桶的数量成倍数关系，可以触发高效的桶映射连接（Map-Side Join），大幅减少Shuffle开销。
3. 缓解数据倾斜：将倾斜的键值通过哈希打散到不同桶中，有时能优化后续处理。
适用场景：
- 超大表间的等值JOIN优化：这是分桶最重要的应用场景之一。
- 需要高效进行随机采样的场景。
- 与分区结合：先按时间分区，在分区内再按用户ID分桶，实现两级数据组织。
分桶的代价与注意事项
1. 写入性能下降：写入时需要计算哈希并确保数据进入正确的桶，比直接写入慢
2. 小文件问题：桶数过多会产生大量小文件，影响HDFS和Hive性能
3. 哈希冲突：不同值可能哈希到同一个桶（概率很小）
4. 数据倾斜：如果分桶列值分布不均，某些桶可能很大
分桶原则
- 桶数量选择经验公式：每个桶文件大小在200MB-1GB为宜（假设表大小100GB，目标每个桶500MB，则桶数=100GB/0.5GB=200个）
- 分桶列选择原则
  - a) 高基数（不同值多）的列
  - b) 经常作为JOIN条件的列
  - c) 经常用于WHERE等值过滤的列
  - d) 不会导致数据倾斜的列

5、视图（View）

视图是Hive中一个逻辑上的虚拟表，它不存储实际数据，通过隐藏复杂数据操作（Join、子查询、过滤、数据扁平化）简化查询操作。

一旦创建视图，他的schema会立刻确定，后续他的底层表的更改（如新增列），并不会影响视图的schema。底层表消失后视图的查询将失败。所以ETL和数据仓库中经常变化的表应慎用视图。

本质：一条预定义的查询语句的封装。

创建与使用：

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


-- 基于现有的复杂查询创建一个视图
CREATE VIEW view_user_summary AS
SELECT 
 user_id,
 COUNT(*) AS pv_count,
 MAX(event_time) AS last_active_time
FROM dwd_user_event
WHERE dt >= '2023-10-01'
GROUP BY user_id;

-- 像查询普通表一样使用视图
SELECT * FROM view_user_summary WHERE pv_count > 100;
-- 更改视图属性
ALTER VIEW view_user_summary SET TBLPROPERTIES('comment'='This is a view');
-- 重新定义视图
ALTER VIEW view_user_summary AS SELECT * FROM dwd_user_event;
-- 删除视图
DROP VIEW view_user_summary;

核心价值：
1. 简化复杂查询：将多表关联、复杂过滤和聚合的逻辑封装起来，对使用者透明。
2. 数据安全与权限控制：可以只将视图（包含部分列或行）的权限开放给用户，而不暴露底层原始表。
3. 逻辑抽象：为不同的业务场景提供定制化的数据视角，即使底层表结构发生变化，也可以通过更新视图来屏蔽影响。
与表的区别：视图不占用HDFS存储空间（只存储元数据），其数据在查询时动态计算生成。

综合应用示例（电商数仓场景）

让我们用一个完整的例子，串联起这四种模型：

 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


-- 1. 创建外部表（ODS层）：指向原始Nginx日志目录
CREATE EXTERNAL TABLE ods_nginx_log (
 ip STRING,
 request_time STRING,
 url STRING,
 user_id INT
)
PARTITIONED BY (dt STRING) -- 按天分区
LOCATION '/data/ods/nginx_log/';

-- 2. 创建内部表（DWD层）：清洗后的明细数据，并分桶
CREATE TABLE dwd_user_pv (
 user_id INT,
 session_id STRING,
 page_url STRING,
 view_time TIMESTAMP
)
PARTITIONED BY (dt STRING) -- 按天分区
CLUSTERED BY (user_id) INTO 32 BUCKETS -- 按user_id分32个桶，为后续JOIN优化做准备
STORED AS ORC; -- 使用高效的列式存储格式

-- 3. 从ODS层向DWD层插入数据，并进行分区裁剪
INSERT OVERWRITE TABLE dwd_user_pv PARTITION (dt='2023-10-26')
SELECT 
 user_id,
 get_session_id(url) as session_id,
 url,
 parse_time(request_time) as view_time
FROM ods_nginx_log
WHERE dt='2023-10-26' -- 分区裁剪，只处理今天的数据
 AND user_id IS NOT NULL;

学习与实践结合：一个完整示例

假设你要在一家电商公司构建用户行为日志表，可以这样设计：

 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


-- 1. 创建数据库（对应图片中的DB，在HDFS创建一个文件夹）
CREATE DATABASE IF NOT EXISTS dw_web;
USE dw_web;

-- 2. 创建外部表（对应图片中的External Table，指向原始日志路径）
CREATE EXTERNAL TABLE IF NOT EXISTS ods_user_log (
 user_id BIGINT COMMENT '用户ID',
 device_id STRING COMMENT '设备ID',
 event_name STRING COMMENT '事件名',
 event_time TIMESTAMP COMMENT '事件时间',
 page_info STRUCT<url:STRING, referer:STRING> COMMENT '页面信息', -- 复杂数据类型
 properties MAP<STRING, STRING> COMMENT '事件属性' -- 复杂数据类型
)
COMMENT '用户行为日志原始表'
PARTITIONED BY (`dt` STRING COMMENT '按天分区，格式yyyymmdd') -- 分区列，物理上成为子目录
ROW FORMAT DELIMITED
FIELDS TERMINATED BY '\001'
STORED AS ORC -- 使用ORC列式存储格式，性能更好
LOCATION '/data/ods/web/user_log'; -- 外部表，数据在此路径下

-- 3. 加载数据到指定分区（数据会进入 /data/ods/web/user_log/dt=20231026/ 目录下）
ALTER TABLE ods_user_log ADD PARTITION (dt='20231026');

-- 4. 基于ODS层，创建一张分桶的DWD（明细层）表
CREATE TABLE dwd_user_event (
 user_id BIGINT,
 event_name STRING,
 hour STRING,
 -- ... 其他清洗后的字段
)
PARTITIONED BY (dt STRING)
CLUSTERED BY (user_id) INTO 32 BUCKETS -- 根据user_id分32个桶
STORED AS ORC;

-- 5. 查询时利用分区裁剪，极大提升效率
SELECT COUNT(*)
FROM ods_user_log
WHERE dt = '20231026' -- Hive只会扫描20231026这一天的数据文件
 AND event_name = 'purchase';

【二】Hive 分区与分桶

Wed, 13 May 2026 20:55:47 +0800

一、不分区+不分桶

假设两张表分别为orders、users（后面直接简称为A、B表）。执行普通JOIN（无分区、无分桶）会发生什么？

1、表结构

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


-- 表结构和数据
CREATE TABLE orders (
 order_id BIGINT,
 user_id BIGINT,
 amount DECIMAL(10,2),
 order_time TIMESTAMP
);

CREATE TABLE users (
 user_id BIGINT,
 name STRING,
 city STRING
);

2、物理存储

HDFS路径：
/user/hive/warehouse/orders/
 ├── 000000_0 (100GB，杂乱存储)
 ├── 000000_1
 └── ...
/user/hive/warehouse/users/
 ├── 000000_0 (10GB，杂乱存储)
 └── ...

假设 orders 表 100GB，HDFS 默认 128MB 一个 block，那么会被切成约 800 个 block，随机分散在集群几十/几百台机器上：

机器1: orders的block_001, block_017, block_233 ...
机器2: orders的block_002, block_089, block_456 ...
机器3: orders的block_003, users的block_012 ...
...

HDFS 存储时不关心 user_id 的值，只按"写入顺序 + 128MB 切块"分散 👉 也就是说：同一个 user_id 对应的 A 表记录和 B 表记录，几乎一定不在同一台机器上。

3、Join 的本质要求：相同 key 必须"碰面"

SQL 的 ON o.user_id = u.user_id 本质是要做：

对于每一个 user_id 值，把 A 表里所有这个 user_id 的行 + B 表里所有这个 user_id 的行，放到同一个地方，然后两两配对。

举个例子，user_id=1001：

A 表（orders）里有 5 条订单
B 表（users）里有 1 条用户信息
Join 结果 = 5 × 1 = 5 行

要完成这个匹配，这 6 条记录必须出现在同一个进程的内存里，否则根本无法对比。

4、执行过程（Reduce Join / Common Join）

1
2
3
4
5
6
7


;

-- 查询：按user_id JOIN
SELECT o.*, u.name
FROM orders o
JOIN users u ON o.user_id = u.user_id
WHERE o.order_tim

4.1、Map

每个 Map 任务只能读取自己机器上的一个 block（数据本地性原则）：

1
2
3
4
5
6
7
8


Map任务1（在机器1上）：读 orders 的 block_001
 → 看到了 user_id = 1001, 2003, 1001, 5008 ...

Map任务2（在机器2上）：读 orders 的 block_002
 → 看到了 user_id = 1001, 3007, 8002 ...

Map任务800（在机器30上）：读 users 的 block_012
 → 看到了 user_id = 1001, 1002, 1003 ...

map 任务彼此之间是隔离的，无法通信。Map1 不知道 Map2 看到了什么，更不知道 users 表的 1001 在哪里。所以必须 Shuffle —— 它就是"重新洗牌"

4.2、Shuffle

Shuffle 的作用：按 join key 对所有数据重新分组,把相同 key 的数据搬运到同一个 Reducer。

1
2
3
4
5
6


Shuffle 规则： reducer_id = hash(user_id) % R

假设 R=3：
 user_id=1001 → hash%3=0 → 全部送到 Reducer0
 user_id=2003 → hash%3=1 → 全部送到 Reducer1
 user_id=5008 → hash%3=2 → 全部送到 Reducer2

无论 user_id=1001 原本在哪台机器、哪个 block、来自 A 表还是 B 表，Shuffle 后都会被搬到 Reducer0。

4.3、Reduce

1、收集：到了 Reducer0，它收到的所有具有相同JOIN键的记录, user_id=1001 的记录长这样：

1
2
3
4


user_id=1001, order_id=8001, amount=99.0
user_id=1001, order_id=8002, amount=50.0
user_id=1001, order_id=8003, amount=120.0
user_id=1001, name="张三", city="成都"

2、分组：Reducer 在内存里把来自两表的记录按JOIN键分组
- A 组（orders）：3 条
- B 组（users）：1 条
3、JOIN：在组内进行笛卡尔积：3 × 1 = 3 条 Join 结果输出。

4.4 总结

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


Map阶段：
 - 启动M个Map任务读取orders表 ===> 输出键值对：<order_id,B记录> <order_id,B记录> ...
 - 启动N个Map任务读取users表 ===> 输出键值对：<user_id,A记录> <user_id,A记录> ...

Shuffle阶段： hash(user_id) 网络传输重新分组 ⭐⭐⭐⭐⭐ 性能瓶颈！
 - 所有记录按user_id哈希，发送到R个Reducer
 - 网络传输：100GB + 10GB = 110GB全部通过网络传输
 - 如果某个user_id有大量订单（大V用户），会发送到同一个Reducer

Reduce阶段：每个Reducer内做笛卡尔积
 - 每个Reducer接收特定user_id范围的所有记录
 - 在Reducer内存中分组：orders记录 vs users记录
 - 执行笛卡尔积：orders × users

5、引申出分区/分表的概念

到这里应该能明白：为什么"都在HDFS存储了"，Join还要网络传输到内存才能计算了吧！

误解	真相
HDFS 是共享存储，数据已经"在一起"了	HDFS 是分布式存储，数据物理上分散在几百台机器的磁盘上
读取就能 Join	读取只能拿到"局部数据"，Join 需要"全局按 key 聚合"
Shuffle 没必要	Shuffle 是分布式计算里"让相同 key 相遇"的唯一手段（除非用 Map Join / Bucket Join 提前规划好）

二、分区+不分桶

1、表结构

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


CREATE TABLE orders_partitioned (
 order_id BIGINT,
 user_id BIGINT,
 amount DECIMAL(10,2)
)
PARTITIONED BY (dt STRING); -- 按天分区

CREATE TABLE users ( -- users表通常不分区，因为用户维度表变化慢
 user_id BIGINT,
 name STRING,
 city STRING
);

2、物理存储

1
2
3
4
5
6
7
8
9


HDFS路径：
/user/hive/warehouse/orders_partitioned/
 ├── dt=2024-01-01/ (1GB)
 ├── dt=2024-01-02/ (1GB)
 ├── dt=2024-01-03/ (1GB)
 └── ... (共100天，100GB)

/users/
 └── 000000_0 (10GB)

3、执行过程

1
2
3
4
5


-- 带分区条件的查询
SELECT o.*, u.name
FROM orders_partitioned o
JOIN users u ON o.user_id = u.user_id
WHERE o.dt = '2024-01-01'; -- 关键：使用分区条件

3.1、Map

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


启动 机器数 个 Map 任务，每个任务只处理一对桶
1. Map任务1（在机器1上）：读 orders 的 block_001
 Key: user_id
 Value: 用户记录
2. 流式读取orders表桶i的数据
3. 第i个Map任务：
 对每条order记录，在HashMap中查找匹配的user_id
 读取orders表的桶i文件 + users表的桶i文件
 在内存中直接JOIN（因为相同user_id必然在同一编号桶中）小表桶加载到 HashMap，大表桶流式扫描匹配
4. 输出结果

分区裁剪（Partition Pruning）：只扫描 dt>='2024-01-01' 的目录，100GB 可能只读 10GB
但读出来的数据user_id 依然是乱的

3.2、Shuffle

user_id 在分区内完全随机分布，user_id=1001 可能出现在任何一个分区的任何一个文件
依然要按 user_id 哈希，全网传输 → Shuffle 不可避免

Shuffle 的作用：按 join key 对所有数据重新分组,把相同 key 的数据搬运到同一个 Reducer。

1
2
3
4
5
6


Shuffle 规则： reducer_id = hash(user_id) % R

假设 R=3：
 user_id=1001 → hash%3=0 → 全部送到 Reducer0
 user_id=2003 → hash%3=1 → 全部送到 Reducer1
 user_id=5008 → hash%3=2 → 全部送到 Reducer2

无论 user_id=1001 原本在哪台机器、哪个 block、来自 A 表还是 B 表，Shuffle 后都会被搬到 Reducer0。

3.3、Reduce

到了 Reducer0，它收到的所有 user_id=1001 的记录长这样：

1
2
3
4


user_id=1001, order_id=8001, amount=99.0
user_id=1001, order_id=8002, amount=50.0
user_id=1001, order_id=8003, amount=120.0
user_id=1001, name="张三", city="成都"

Reducer 在内存里按表来源分成两组：

A 组（orders）：3 条
B 组（users）：1 条

然后做笛卡尔积：3 × 1 = 3 条 Join 结果输出。

3.4 总结

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


Map阶段：
 - orders表：只启动Map任务读取dt=2024-01-01分区（1GB）===> 输出键值对：<order_id,B记录> <order_id,B记录> ...
 - users表：启动Map任务读取全部（10GB） ===> 输出键值对：<user_id,A记录> <user_id,A记录> ...

Shuffle阶段：
 - 所有记录按user_id哈希，发送到R个Reducer
 - 网络传输：1GB(orders) + 10GB(users) = 11GB
 - 相比普通JOIN的110GB，减少90%！

Reduce阶段：(同普通JOIN)
 - 每个Reducer接收特定user_id范围的所有记录
 - 在Reducer内存中分组：orders记录 vs users记录
 - 执行笛卡尔积：orders × users

分区 = 减少输入数据量，但 Shuffle 一分都没少。 如果 WHERE 条件不带分区字段，分区等于白做。

4、分区设计原则

1
2
3
4
5
6
7
8


-- 按时间分区（最常用）
PARTITIONED BY (dt STRING, hour STRING)

-- 按业务维度分区
PARTITIONED BY (country STRING, province STRING)

-- 分区不宜过多，否则产生大量小文件
-- 每个分区数据量建议：100MB-2GB

三、分桶+不分区

1.1、表结构(小表桶+大表桶) HashMap

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


CREATE TABLE orders_bucketed (
 order_id BIGINT,
 user_id BIGINT,
 amount DECIMAL(10,2),
 order_time TIMESTAMP
)
CLUSTERED BY (user_id) INTO 32 BUCKETS; -- 按user_id分32个桶

CREATE TABLE users_bucketed (
 user_id BIGINT,
 name STRING,
 city STRING
)
CLUSTERED BY (user_id) INTO 32 BUCKETS; -- 同样分32个桶

-- 设置参数启用桶优化
SET hive.optimize.bucketmapjoin = true;
SET hive.optimize.bucketmapjoin.sortedmerge = true;

1.2、表结构(大表桶+大表桶) SMB Join（Sort Merge Bucket Join）

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


CREATE TABLE orders_bucketed (
 order_id BIGINT,
 user_id BIGINT,
 amount DECIMAL(10,2),
 order_time TIMESTAMP
)
CLUSTERED BY (user_id) SORTED BY (user_id) INTO 32 BUCKETS; -- 按user_id分32个桶 + 排序：

CREATE TABLE users_bucketed (
 user_id BIGINT,
 name STRING,
 city STRING
)
CLUSTERED BY (user_id) SORTED BY (user_id) INTO 32 BUCKETS; -- 同样分32个桶 + 排序：


SET hive.optimize.bucketmapjoin.sortedmerge = true;
SET hive.auto.convert.sortmerge.join = true;

2、物理存储

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


HDFS路径：
/user/hive/warehouse/orders_bucketed/
 ├── 000000_0 (桶0：user_id哈希后%32=0的记录)
 ├── 000001_0 (桶1)
 ├── ...
 └── 000031_0 (桶31)

/users_bucketed/
 ├── 000000_0 (桶0)
 ├── ...
 └── 000031_0 (桶31)

3、执行过程（启用Bucket Map Join）

1
2
3
4


SELECT o.*, u.name
FROM orders_bucketed o
JOIN users_bucketed u ON o.user_id = u.user_id
WHERE o.order_time >= '2024-01-01';

3.1、Map

(小表桶+大表桶) 小表桶加载到HashMap+大表桶流式扫描匹配

A表的桶0 和 B表的桶0，包含的 user_id 是完全一致的集合！

因为两边都用 hash(user_id) % 32 分桶，所以 user_id=1001 在 A 表必在桶 X，在 B 表也必在桶 X。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


启动 32 个 Map 任务，每个任务只处理一对桶
1. 将users表桶i的全部数据加载到内存的HashMap中，内存占用：≈ users表桶大小
    Key: user_id
    Value: 用户记录
2. 流式读取orders表桶i的数据
3. 第i个Map任务：
    对每条order记录，在HashMap中查找匹配的user_id
 读取orders表的桶i文件 + users表的桶i文件
    在内存中直接JOIN（因为相同user_id必然在同一编号桶中）小表桶加载到 HashMap，大表桶流式扫描匹配
4. 输出结果

(大表桶+大表桶) Sort Merge Bucket Join

1
2
3
4
5
6


启动 32 个 Map 任务，每个任务只处理一对桶
1. 第i个Map任务：
    双指针归并读取users表桶i的数据
    双指针归并读取order表桶i的数据
    在内存中直接JOIN（因为相同user_id必然在同一编号桶中）
2. 输出结果

那么连 HashMap 都不用建，双指针归并即可，内存几乎为 0，可处理超大表 Join 超大表。

3.2、Shuffle（跳过）

Shuffle阶段 ✅ 完全跳过！

因为相同 key 已经在同一个桶里"碰面"了，没有跨机器传输的必要

3.3、Reduce（跳过）

在map阶段就已经join并合并结果了，是完整的数据分组！不需要 Reducer将相同userId的记录合并

Map任务0处理了所有user_id哈希值为0的记录
Map任务1处理了所有user_id哈希值为1的记录
没有跨任务的重叠数据（每个任务的userId本来就是相同的），所以不需要合并

3.4、总结

1
2
3
4
5
6
7


Map阶段：
 - 启动M个Map任务读取orders表 ===> 输出键值对：<order_id,B记录> <order_id,B记录> ...
 - 启动M个Map任务读取users表 ===> 输出键值对：<user_id,A记录> <user_id,A记录> ...
 - 读取orders表的桶i文件 + users表的桶i文件
 - 在内存中直接JOIN（因为相同user_id必然在同一编号桶中）
- 输出结果
无Shuffle阶段！⭐⭐⭐⭐⭐

4、特殊分桶

情况1：只对一张表分桶

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


-- orders分桶，users未分桶
SELECT o.*, u.name
FROM orders_bucketed o -- 分桶表
JOIN users u -- 未分桶表
ON o.user_id = u.user_id;

-- 执行过程：
-- 如果users小：Map Join（广播users表到所有Map任务）
-- 如果users大：Reduce Join（退化为普通JOIN，分桶优势很小）
-- 最差的分桶情况

只有A表分桶，B表广播

Map任务数：64个（A表的每个桶一个任务）
每个Map任务处理：
 - order表：1个桶文件（1/64的A表数据）
 - users表：如果users小,Map Join（广播整个users表到64个Map任务）
 如果users大：Reduce Join（退化为普通JOIN，分桶优势很小）
 - 内存压力：每个任务都需要缓存整个B表
网络传输：B表被传输64次

情况2：分桶但桶数不同

1
2
3
4
5


-- orders分64，users分32
SELECT o.*, u.name
FROM order_64_bucket o -- 分桶表
JOIN users_32_bucket u -- 未分桶表
ON o.user_id = u.user_id;

理想情况（两表都是64桶）

1
2
3
4
5
6
7


-- 最优效率：Bucket Map Join
Map任务数：64个
每个Map任务处理：
 - order表：1个桶文件（1/64的数据）
 - users表：1个桶文件（1/64的数据）
 - 总计：每个任务处理 1/32 的总数据量
无Shuffle，完全本地JOIN

混合情况（A表64桶，B表32桶）

1
2
3
4
5
6
7


-- 次优但高效的方案
Map任务数：64个
每个Map任务处理：
 - 处理users表的任务：1个桶文件（1/32的B表数据）
 - 处理order表的任务：2个桶文件（2/64 = 1/32的A表数据）
 - 注意：实际是order表和users表分开处理，但对应关系一致
无Shuffle，完全本地JOIN

情况3：分桶JOIN后还要GROUP BY

1
2
3
4


SELECT u.city, COUNT(*) as order_count, SUM(o.amount) as total_amount
FROM orders o
JOIN users u ON o.user_id = u.user_id
GROUP BY u.city;

执行计划变化

1
2
3
4
5
6
7
8
9


Map阶段（Bucket Map Join）：
 - 每个Map任务执行本地JOIN
 - 然后执行本地预聚合（Partial Aggregation）
 - 输出：<city, (count, sum)>

Reduce阶段（这次有了！）：
 - 收集所有Map任务的本地聚合结果
 - 按city合并：sum(count), sum(sum)
 - 输出最终结果

注意：此时仍然有Reduce，但：

Reduce的输入已经是聚合后的中间结果，数据量小很多
主要的JOIN工作已经在Map端完成，避免了大数据Shuffle

四、分桶+分区

1、表结构

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


CREATE TABLE orders_partitioned (
 order_id BIGINT,
 user_id BIGINT,
 amount DECIMAL(10,2)
)
PARTITIONED BY (dt STRING); -- 按天分区
CLUSTERED BY (user_id) SORTED BY (user_id) INTO 32 BUCKETS; -- 按user_id分32个桶 + 排序：

CREATE TABLE users ( -- users表通常不分区，因为用户维度表变化慢
 user_id BIGINT,
 name STRING,
 city STRING
);
CLUSTERED BY (user_id) SORTED BY (user_id) INTO 32 BUCKETS; -- 按user_id分32个桶 + 排序：

SET hive.optimize.bucketmapjoin = true; -- 允许优化器把 Join 转成 Bucket Map Join
SET hive.optimize.bucketmapjoin.sortedmerge = true; -- 允许优化器把 Join 转成 SMB Join
SET hive.auto.convert.sortmerge.join = true;

2、物理存储

HDFS路径：
/user/hive/warehouse/orders_partitioned/
 ├── dt=2024-01-01/ (1GB)
 │ ├── 000000_0 ← 桶0文件
 │ ├── 000001_0 ← 桶1文件
 │ ├── ...
 │ └── 000031_0 ← 桶31文件
 ├── dt=2024-01-03/ (1GB)
 │ ├── 000000_0 ← 桶0文件
 │ ├── 000001_0 ← 桶1文件
 │ ├── ...
 │ └── 000031_0 ← 桶31文件
 └── ... (共100天，100GB)

/users_bucketed/
 ├── 000000_0 (桶0)
 ├── ...
 └── 000031_0 (桶31)

3、执行过程

1
2
3
4
5


-- 带分区条件的查询
SELECT o.*, u.name
FROM orders_partitioned o
JOIN users u ON o.user_id = u.user_id -- 关键：使用分桶条件
WHERE o.dt = '2024-01-01'; -- 关键：使用分区条件

3.1、Map

由于使用PARTITIONED BY (dt STRING);根据天进行了分区，

1
2
3
4
5
6
7


启动 32 个 Map 任务，每个任务只处理一对桶

1. 第i个Map任务：
 双指针归并读取users表桶i的数据
 双指针归并读取order表桶i的数据
 在内存中直接JOIN（因为相同user_id必然在同一编号桶中）
2. 输出结果

Map阶段 ✅ 优化点：

分区裁剪（Partition Pruning）：只扫描 dt>='2024-01-01' 的目录，100GB 可能只读 10GB
但读出来的数据user_id 依然是乱的

那么连 HashMap 都不用建，双指针归并即可，内存几乎为 0，可处理超大表 Join 超大表。

3.2、Shuffle（跳过）

Shuffle阶段 ✅ 完全跳过！

因为相同 key 已经在同一个桶里"碰面"了，没有跨机器传输的必要

3.3、Reduce（跳过）

在map阶段就已经join并合并结果了，是完整的数据分组！不需要 Reducer将相同userId的记录合并

Map任务0处理了所有user_id哈希值为0的记录
Map任务1处理了所有user_id哈希值为1的记录
没有跨任务的重叠数据（每个任务的userId本来就是相同的），所以不需要合并

3.4 总结

1
2
3
4
5
6
7


Map阶段：
 - 启动M个Map任务读取orders表 ===> 输出键值对：<order_id,B记录> <order_id,B记录> ...
 - 启动M个Map任务读取users表 ===> 输出键值对：<user_id,A记录> <user_id,A记录> ...
 - 读取orders表的桶i文件 + users表的桶i文件
 - 在内存中直接JOIN（因为相同user_id必然在同一编号桶中）
- 输出结果
无Shuffle阶段！⭐⭐⭐⭐⭐

分区 = 减少输入数据量，但 Shuffle 一分都没少。 如果 WHERE 条件不带分区字段，分区等于白做。

五、最佳实践总结

分桶设计原则：

选择高基数、常作为JOIN条件的列

桶数计算：总数据量 / 每个桶目标大小(200MB-1GB) 例如：100GB数据，目标500MB/桶 → 200个桶

确保频繁JOIN的表在JOIN键上分桶，且桶数相同或成倍数

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


-- 最佳：桶数相同
CREATE TABLE table_a CLUSTERED BY (key) INTO 64 BUCKETS;
CREATE TABLE table_b CLUSTERED BY (key) INTO 64 BUCKETS;

-- 可接受：桶数成倍数（大表桶数是小表的整数倍）
CREATE TABLE large_table CLUSTERED BY (key) INTO 64 BUCKETS; -- 大表
CREATE TABLE small_table CLUSTERED BY (key) INTO 32 BUCKETS; -- 小表

-- 避免：桶数不成倍数
CREATE TABLE table_a CLUSTERED BY (key) INTO 64 BUCKETS;
CREATE TABLE table_b CLUSTERED BY (key) INTO 30 BUCKETS; -- 不好！

配置调优：

1
2
3
4
5


-- 确保启用桶优化
SET hive.optimize.bucketmapjoin = true;
SET hive.optimize.bucketmapjoin.sortedmerge = true;
SET hive.enforce.bucketing = true; -- 确保写入时正确分桶
SET hive.enforce.sorting = true; -- 如果使用sortedmerge，需要排序

监控与验证：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


-- 查看桶的统计信息
DESCRIBE FORMATTED table_a;

-- 检查桶数是否匹配
SHOW TBLPROPERTIES table_a;
SHOW TBLPROPERTIES table_b;

-- 查看执行计划确认优化
EXPLAIN EXTENDED
SELECT /*+ MAPJOIN(b) */ a.*, b.*
FROM table_a a JOIN table_b b ON a.key = b.key; 

六、性能量化对比

假设：

总数据量：A表（100GB），B表（10GB）
集群节点：10个
每个节点内存：16GB

效率对比表

场景	任务类型	总数据移动	内存使用	网络开销	执行时间估算
不分桶（Reduce Join）	Map + Reduce	110GB全部Shuffle	中等	极高	慢（5-10分钟）
只有A分桶，B广播	Map Only	B表广播10次（100GB）	极高（每个节点存10GB B表）	高	中等（2-3分钟）
A64桶，B32桶	Map Only	无Shuffle，本地读取	低（每个任务约0.3GB A + 0.3GB B）	极低	快（1-2分钟）
都分桶64桶	Map Only	无Shuffle，本地读取	最低（每个任务约0.16GB A + 0.16GB B）	极低	最快（30秒-1分钟）

内存效率：混合分桶每个任务只处理1/32的数据，内存压力小
网络效率：混合分桶无Shuffle，只有A分桶需要广播整个B表
计算效率：两者都是Map-Only，但混合分桶的数据本地性更好

七、参数设置

配置速览表

配置项	作用阶段	作用对象	默认值（不同版本）	一句话说明
`hive.optimize.bucketmapjoin`	查询时	读	false	允许优化器把 Join 转成 Bucket Map Join
`hive.optimize.bucketmapjoin.sortedmerge`	查询时	读	false	允许优化器把 Join 转成 SMB Join
`hive.enforce.bucketing`	写入时	写	Hive 2.x 起默认 true	强制 INSERT 时按桶数生成对应 reducer
`hive.enforce.sorting`	写入时	写	Hive 2.x 起默认 true	强制 INSERT 时按 SORTED BY 排序

📌 关键区分：optimize.* 是"查询读取时的优化开关"，enforce.* 是"数据写入时的约束开关"。两者必须配合使用，否则查询优化没有数据基础。

1️⃣ `hive.optimize.bucketmapjoin = true`

作用：告诉 Hive 优化器——如果检测到 Join 两边的表都按 Join Key 分桶，且桶数成倍数关系，就自动把 Common Join（Reduce Join）转换成 Bucket Map Join。

触发条件（必须全部满足）：

✅ 两张表都用 CLUSTERED BY (join_key) 分桶
✅ 分桶字段 = Join 字段
✅ 桶数成整数倍关系（如 32 vs 32，或 32 vs 8）
✅ Join 类型为 INNER / LEFT / RIGHT（不支持 FULL OUTER）

没开会怎样？ 即使表分桶了，Hive 也会当成普通表走 Common Join，分桶白做、Shuffle 照常发生。

开了之后的执行变化：

1
2


Before (Common Join): Map → Shuffle → Reduce ❌
After (Bucket MJ): Map (桶对桶直接Join) → 输出 ✅

2️⃣ `hive.optimize.bucketmapjoin.sortedmerge = true`

作用：在 Bucket Map Join 基础上再进一步——如果两张表不仅分桶，还按 Join Key 排序了，就用 SMB Join (Sort Merge Bucket Join)。

触发条件（在 Bucket Map Join 基础上加一条）：

✅ 满足 Bucket Map Join 所有条件
✅ 两张表都用了 SORTED BY (join_key) 排序

SMB Join 比普通 Bucket Map Join 强在哪？

维度	Bucket Map Join	SMB Join
内存需求	小桶要全部装进 HashMap	几乎零内存（双指针归并）
桶数要求	成倍数即可	必须完全相等
排序要求	不需要	必须按 Join Key 排序
适用场景	大表 Join 中表	超大表 Join 超大表

归并原理（这就是为什么不用内存）：

A表桶0(已排序): 1001 → 1003 → 1005 → 1008
B表桶0(已排序): 1001 → 1002 → 1005 → 1009
 ↓ 双指针对齐扫一遍即可
匹配: 1001 ✓, 1005 ✓

配套推荐参数：

1
2


SET hive.auto.convert.sortmerge.join = true; -- 自动转换为 SMB
SET hive.auto.convert.sortmerge.join.noconditionaltask = true;

3️⃣ `hive.enforce.bucketing = true`

作用：INSERT 写入数据时，强制 Hive 启动正好等于桶数的 reducer，确保数据按 hash(bucket_col) % N 严格分配到 N 个文件。

为什么需要？ Hive 的分桶不是数据库式的强约束——你建表时声明了 CLUSTERED BY (user_id) INTO 32 BUCKETS，但写入时如果不强制，Hive 可能：

启动 100 个 reducer，写出 100 个文件 → 桶完全乱套
启动 5 个 reducer，写出 5 个文件 → 根本没有 32 桶
数据分配规则混乱 → 同一个 user_id 落到不同桶

开启后的写入行为：

1
2
3
4
5


NSERT INTO orders_bucketed SELECT * FROM orders_raw;
-- 自动行为：
-- 1. 启动正好 32 个 reducer
-- 2. 按 hash(user_id) % 32 分配数据
-- 3. 每个 reducer 输出一个桶文件 000000_0 ~ 000031_0

不开会怎样？

桶数和文件数不一致
Bucket Map Join 时按桶号配对会找错数据或直接报错
查询结果可能不正确 ⚠️

📌 Hive 2.x 起默认就是 true，老版本（0.x、1.x）需要手动开。

4️⃣ `hive.enforce.sorting = true`

作用：和 hive.enforce.bucketing 配对——INSERT 写入数据时，对建表语句中的 SORTED BY 字段强制排序后再写入文件。

为什么需要？ 建表时声明的：

1

CLUSTERED BY (user_id) SORTED BY (user_id) INTO 32 BUCKETS

只是元数据声明，Hive 默认不会真的去排序。如果不强制，写入的桶文件内部数据是乱的，SMB Join 时的"归并"前提就不成立。

开启后的写入行为：

1
2
3
4
5


桶0文件内容（开启sorting）：
 user_id=1001, ...
 user_id=1003, ...
 user_id=1005, ...
 user_id=1008, ... ← 严格按 user_id 升序

不开会怎样？

桶内数据无序
SMB Join 的归并算法直接失效
结果错误或回退到普通 Bucket Map Join ⚠️

四个参数的协作关系图

 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


┌─────────────────────────────────────────────────────────────┐
│ 【写入侧】 │
│ 建表：CLUSTERED BY (user_id) SORTED BY (user_id) INTO 32 │
│ │ │
│ ┌───────────┴───────────┐ │
│ ▼ ▼ │
│ hive.enforce.bucketing hive.enforce.sorting │
│ （保证桶数正确） （保证桶内有序） │
│ │ │ │
│ └──────数据落盘─────────┘ │
│ ▼ │
│ 32个桶文件，每个内部有序 ✅ │
└─────────────────────────────────────────────────────────────┘
 │
 ▼
┌─────────────────────────────────────────────────────────────┐
│ 【查询侧】 │
│ SELECT ... JOIN ... │
│ │ │
│ ┌───────────┴───────────┐ │
│ ▼ ▼ │
│ hive.optimize.bucketmapjoin hive.optimize. │
│ （启用桶对桶Join） bucketmapjoin.sortedmerge │
│ （启用SMB Join） │
│ │ │
│ ▼ │
│ 跳过 Shuffle，桶对桶归并 ✅ │
└─────────────────────────────────────────────────────────────┘

典型踩坑场景

现象	原因	解决
表分桶了，但 Join 还是 Shuffle	没开`hive.optimize.bucketmapjoin`	启用查询优化参数
开了 bucketmapjoin，但 Join 报错或结果不对	写入时没开`hive.enforce.bucketing`，桶文件数和声明不一致	重建表 + 开 enforce
SMB Join 没生效，回退到 Bucket MJ	桶内未排序 / 没开 sortedmerge	开`enforce.sorting` + `optimize.bucketmapjoin.sortedmerge`
桶数对，但 Join 结果有遗漏	写入时用了`DISTRIBUTE BY` 但 hash 函数不同	用`INSERT` 让 Hive 自动按桶规则写

生产环境推荐配置组合

A. 通用 Bucket Map Join 配置

1
2
3
4
5


-- 写入侧
SET hive.enforce.bucketing = true;
-- 查询侧
SET hive.optimize.bucketmapjoin = true;
SET hive.auto.convert.join = true; -- 自动判断是否走 Map Join

B. SMB Join 完整配置（超大表 Join 超大表）

1
2
3
4
5
6
7
8
9


-- 写入侧
SET hive.enforce.bucketing = true;
SET hive.enforce.sorting = true;
-- 查询侧
SET hive.optimize.bucketmapjoin = true;
SET hive.optimize.bucketmapjoin.sortedmerge = true;
SET hive.auto.convert.sortmerge.join = true;
SET hive.auto.convert.sortmerge.join.noconditionaltask = true;
SET hive.input.format = org.apache.hadoop.hive.ql.io.BucketizedHiveInputFormat;

一句话记忆口诀

enforce.* 管"写得规整"，optimize.* 管"读得聪明"。 写时不规整，读时再优化也白搭；写时规整了，读时不开优化也浪费。

product_id	tags
1	[’electronics’,‘discount’,’new’]
3	[’electronics’,‘home’]

emp_id	skill_names
1	[‘Java’,‘Python’,‘SQL’]
2	[‘JavaScript’,‘React’]

特性	协方差	皮尔逊相关系数
取值范围	(-∞, +∞)	[-1, 1]（固定范围）
量纲影响	受数据单位影响	无量纲，消除单位影响
可比性	不同变量对无法直接比较	可直接比较不同变量对
直观性	数值大小难以解释	绝对值越接近1，关系越强
大数据函数	`COVAR_SAMP()`	`CORR()`

r 值范围	关系强度	方向	业务意义
0.8 ~ 1.0	极强相关	正	一个变量可高度预测另一个
0.6 ~ 0.8	强相关	正	明显协同变化关系
0.4 ~ 0.6	中等相关	正	有一定关联性
0.2 ~ 0.4	弱相关	正	轻微关联，需谨慎解读
-0.2 ~ 0.2	极弱/无线性相关	-	无明显线性关系（可能有非线性关系）
-0.4 ~ -0.2	弱相关	负	轻微反向变化
-0.6 ~ -0.4	中等相关	负	明显反向变化
-0.8 ~ -0.6	强相关	负	强烈反向变化
-1.0 ~ -0.8	极强相关	负	高度反向预测关系

Hive on My Learning Notes

【十】Hive 窗口函数：OVER / PARTITION BY / ORDER BY 与 OLAP 分析

Hive 窗口函数

一、OLAP 和 窗口函数

1.1 为什么窗口函数和 OLAP 相关

1.2 为什么叫“窗口”函数

1.3 为什么窗口函数必须 partition + sort

1） partition

2） sort

3） window frame

1.4 窗口函数分类

三、统一数据源

3.1 表结构 & 样例数据

3.2 基础规则（先把“窗口”这件事说明白）

四、序号函数（给行编号/排名）

4.1 ROW_NUMBER：严格递增的行号（不管并列）

示例 SQL

输出结果示例（dept=‘A’）

原理分析

4.2 RANK：并列共享排名，名次会“跳号”

示例 SQL

输出结果示例（dept=‘A’）

原理分析

4.3 DENSE_RANK：并列共享排名，但不跳号

示例 SQL

输出结果示例（dept=‘A’）

原理分析

4.4 NTILE：把排序后的数据切成 N 份（分桶/分位组）

示例 SQL（每部门分成 4 份）

输出结果示例（直观理解）

原理分析

五、分布函数（看数据分布）

5.1 CUME_DIST：累计分布（<= 当前值的占比）

示例 SQL（部门内按金额升序看“有多少比例不超过我”）

输出结果示例（dept=‘A’，金额升序：80,100,120,120,120）

原理分析

5.2 PERCENT_RANK：百分比排名（基于 rank 的 0~1）

示例 SQL（金额升序）

输出结果示例（dept=‘A’）

原理分析

六、前后函数（看前一行/后一行）

6.1 LAG：取前n行（默认偏移 1）

示例 SQL（看每个员工相对上一天的变化——环比增长额）

输出结果示例（alice 与 david）

原理分析

应用

计算环比增长率

6.2 LEAD：取后n行

示例 SQL（看下一天金额）

输出结果示例

原理分析

七、头尾函数（看窗口首尾值）

7.1 FIRST_VALUE：窗口内第一行的值

示例 SQL（每部门按金额降序，取“当前窗口看到的第一名金额”）

输出结果示例（dept=‘A’）

原理分析

7.2 LAST_VALUE：窗口内最后一行的值（默认常踩坑）

坑示范（默认到 CURRENT ROW，last_value 往往等于当前行）

正确拿“分区最后一行”的写法（UNBOUNDED FOLLOWING）

原理分析

八、聚合函数（窗口版：在窗口内做统计）

8.1 分区总和（不写 ORDER BY → 默认整个分区）

示例 SQL：每部门总销售额

输出结果示例（只看 dept_sum）

原理分析

8.2 累计和（Running Sum）：从开头累加到当前行（显式 ROWS 更稳）

示例 SQL：部门内按日期累计

输出结果示例（dept=‘A’）

原理分析（为什么强调 ROWS）

易错点

8.3 移动平均（Moving Average）：最近 N 行

示例 SQL：最近 3 行的平均销售额

输出结果示例（dept=‘A’）

原理分析

8.4 COUNT / MAX / MIN 的窗口用法（举一组典型）

示例 SQL：部门内记录数、最大/最小金额

输出结果示例（只看聚合列）

原理分析

九、其他分析函数

9.1 数据源

一、OLAP 和窗口函数