Posts 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 计算引擎：MapReduce / Tez / Spark 对比与选型

Tue, 26 May 2026 21:37:59 +0800

一、什么是计算引擎

计算引擎是大数据处理中的核心软件框架，它负责对海量数据执行具体的计算任务，是数据从“存储”到“价值”的加工车间。

它的核心职责是：

资源管理：协调和管理集群中的CPU、内存等计算资源。
任务调度：将用户编写的计算逻辑（如一个复杂的分析或转换任务）拆解成多个小任务，并合理分配到集群的各个节点上并行执行。
执行计算：在分配的节点上真正执行代码，完成数据的过滤、聚合、关联、机器学习等操作。

为什么需要它？

它抽象了底层分布式计算的复杂性（如容错、并行、通信），让开发者可以像编写单机程序一样，通过高级API（如SQL、Python、Java）来处理TB/PB级的数据。

一个简单类比：

把数据比作食材，数据存储（如HDFS）是仓库，而计算引擎（如Spark、Flink）就是厨房和厨师，负责按照菜谱（你的程序）将食材加工成菜肴（分析结果）。

在企业数据平台里，计算需求通常会自然聚成三类：

三类主流大数据计算引擎举例：

批处理引擎：Apache Spark（核心，速度快，通用），MapReduce（Hadoop原生，较慢但经典）。
流处理引擎：Apache Flink（流批一体，延迟极低），Apache Spark Streaming（微批处理）。
查询引擎：Apache Hive（将SQL翻译成MapReduce/Spark/Tez任务），Presto/Trino（交互式快速查询）

三类计算引擎的定义是根据下面的指标划分的

数据边界不同
- 批处理：数据集是有界的（比如“昨天全量日志”“历史订单全量”），可以等数据齐了再算。
- 流处理：数据是无界的（事件持续产生），系统必须边来边算、一直跑。
- 查询：数据通常已落地（湖/仓/OLAP），重点是“对已存在数据做即席查询”。
时效/延迟目标不同
- 批：分钟~小时级（吞吐优先、成本友好）。
- 流：毫秒~秒级（低延迟 + 连续输出）。
- 查：秒级甚至亚秒级（交互体验优先）。
运行形态不同
- 批：典型是“提交一次作业 → 跑完结束”。
- 流：典型是“提交一个长期运行作业 → 持续处理”。
- 查：典型是“每个 SQL/请求是一条短查询”，并发高、响应快。
状态与一致性处理方式不同
- 批：很多时候“状态”隐含在 shuffle/sort 和中间结果里，失败可重跑整批。
- 流：必须显式维护跨事件状态（窗口、聚合、会话、去重），需要 checkpoint/一致性语义。Apache Flink Documentation 明确把 Flink定位为在有界/无界数据流上做有状态计算，并强调 exactly-once、事件时间等能力。
- 查：倾向“每次查询尽量无状态/弱状态”，靠列式、向量化、谓词下推、并行执行把单次查询做到极快。

二、三类引擎分别“负责什么功能”？

A. 批处理引擎（Batch Engine）——“算全量/大规模离线作业”

核心功能：对有界数据集进行一次性计算，强调吞吐、可扩展、成本效率。
典型任务：

离线 ETL/ELT（ODS→DWD→DWS→ADS 的批加工）
T+1 报表、历史回溯重算（backfill）
大规模 join、聚合、排序、离线特征工程、离线训练数据准备

典型特征

作业是“短生命周期”：提交→执行→结束
更能容忍较高延迟，换取更高吞吐/更低成本
容错常见方式：失败重跑整批或重跑失败 stage

常见代表（举例）：MapReduce、Spark（Batch）、Hive on Tez/Spark 等（按生态演进不同）。

B. 流处理引擎（Stream Engine）——“事件来了立刻算、持续产出结果”

核心功能：对无界数据流做持续计算，强调低延迟 + 有状态 + 时间语义 + 一致性。
典型任务：

实时指标/实时大屏（PV/UV、延迟、成功率）
实时风控/反欺诈、实时告警
会话窗口（session window）、滚动/滑动窗口聚合
CDC（变更数据捕获）入湖/入仓、实时维表关联（enrichment）

典型特征（以 Flink 的官方描述为例）

运行形态：长作业常驻
能力侧重：有状态计算、Exactly-once 状态一致性、事件时间处理、低延迟高吞吐、checkpoint（增量检查点）等。
结果输出：持续不断更新（流式 sink）

C. 查询/交互式查询引擎（Query Engine / Interactive SQL Engine）——“即席问、快速答”

核心功能：对已落地在数据湖/数仓/多数据源的数据做交互式 SQL，强调低延迟、并发、即席分析体验。
典型任务：

BI 报表/仪表盘（高并发、秒级响应）
数据分析师 ad-hoc 探索（临时 join、过滤、聚合）
联邦查询：跨 Hive/湖表 + MySQL/ES/Kafka 等多源联合分析（取决于引擎）

典型特征（以 Presto 官方首页描述为例）

定位：开源 SQL 查询引擎，面向数据分析；支持交互式/即席查询，目标是（可达）亚秒级性能；并强调“查询数据所在之处”、连接多种数据源、分布式内存 SQL 引擎等。
作业形态：每条查询是短请求；适合高并发、多用户
通常不负责复杂 ETL 流水线（更多是“读多、快查”）

三类引擎“功能边界”总结

维度	批处理引擎	流处理引擎	查询引擎（交互式）
主要处理对象	有界数据集（全量/分区批）	无界事件流（持续进入）	已落地数据（湖/仓/多源）
运行形态	提交一次作业→跑完结束	长期运行作业→持续处理	每条 SQL/请求一次执行
核心目标	吞吐、成本效率、可扩展	低延迟、状态一致性、时间语义	低延迟、并发、即席分析体验
状态管理	多为“批内隐式状态”，失败可重跑	强状态（窗口/去重/会话），需 checkpoint	尽量无状态/弱状态（单查询内）
典型延迟	分钟~小时	毫秒~秒	秒级~亚秒（视数据与查询）
典型产出	离线表、宽表、汇总表、离线特征	实时指标流、告警、实时明细/宽表增量	查询结果集（给人/BI）
代表例子（举例）	MapReduce、Spark Batch	Flink、Storm、Kafka Streams	Presto/Trino、Impala 等

说明：现实里很多系统在“流批一体/湖仓一体”趋势下会互相渗透，但主责仍按上表分工最清晰。

现在为什么又出现“流批一体/多引擎协作”？

你会发现越来越多平台不再只选一种引擎，而是组合拳：

Spark 的 Structured Streaming：官方文档强调它构建在 Spark SQL 引擎上，允许你用“写批处理”的方式表达流计算；默认内部用 micro-batch，把流当作一系列小批作业增量执行，并通过 checkpoint/WAL 提供端到端 exactly-once 等保证。 [spark.apache.org]
Flink：官方定位就是同时支持有界/无界数据流的有状态计算（把批看作有界流的一种情况）。 [flink.apache.org]

这背后的工程现实是：

批负责“把数据加工成可用形态”（治理、建模、汇总）
流负责“把最新变化尽快算出来/写进去”（实时指标、CDC 入湖）
查负责“让人/BI 快速取数”（交互式体验）
成熟平台往往三者共存，各做各的甜区，整体成本和体验最好。

三、查询引擎

今天学习的是查询引擎Apache Hive，目前Hive支持MapReduce、Tez和Spark三种执行引擎。

Hive 本质上是一个 SQL → 分布式计算任务的翻译器，它本身不执行计算，而是把 HiveQL 解析、优化后翻译成底层引擎可执行的物理计划。Hive 从 0.x 时代一路演进到 3.x/4.x，先后支持了 MapReduce、Tez、Spark 三种执行引擎，可通过 hive.execution.engine 参数切换：

1
2
3


SET hive.execution.engine=mr; -- MapReduce（已废弃）
SET hive.execution.engine=tez; -- Tez（Hortonworks/HDP 主推）
SET hive.execution.engine=spark; -- Spark（Cloudera/CDH 主推）

3.1 MapReduce 引擎（Hive 的"出生"引擎）

Hive 把 SQL 翻译成一连串的 MR Job：每个 Job 由一个 Map 阶段 + 一个 Reduce 阶段组成，中间结果必须落盘到 HDFS，下一个 Job 再从 HDFS 读取。

① 工作原理（详细数据流）

MapReduce 是一个严格的两段式计算模型：Map → Shuffle → Reduce，每个阶段的数据流动都涉及大量磁盘 I/O。

🟦 Map 端（输入侧）

Split 切分：输入文件（HDFS 上的大文件）会被按 InputSplit（默认与 HDFS Block 对齐，约 128MB）切分成若干份，每份对应一个 MapTask。
Record 读取：每个 MapTask 通过 RecordReader 把数据按行（或按 key-value）读入 map() 方法 进行业务处理。
环形缓冲区（Ring Buffer）：map() 的输出 不直接写磁盘，而是先写到一块内存缓冲区（默认 100MB，由 mapreduce.task.io.sort.mb 控制）。
分区 + 排序 + Spill 溢写：当缓冲区使用率达到阈值（默认 80%，mapreduce.map.sort.spill.percent）时，后台线程会：
- 按 Partitioner（默认 HashPartitioner）给每条记录打上分区号（决定将来去哪个 Reduce）；
- 在分区内按 key 进行快速排序；
- 将排序后的数据溢写（spill）到本地磁盘，形成一个个临时 spill 文件。
Merge 归并：一个 MapTask 通常会产生多个 spill 文件，Map 结束时会把它们多路归并成一个有序的大文件（按分区 + key 排序），存放在该节点的本地磁盘（注意：不是 HDFS！），等待 Reduce 来拉取。

🟥 Reduce 端（拉取 + 聚合）

Shuffle（Copy 阶段）：ReduceTask 启动后，会通过 HTTP 从所有 MapTask 节点拉取属于自己分区的数据，先写入 Reduce 节点的内存缓冲区。
内存溢写 + 再次排序：内存装不下时再次 spill 到磁盘，并对数据进行第二轮排序（保证全局有序）。
Merge 归并：所有 Map 端数据拉取完成后，对磁盘上的多个临时文件进行多路归并，形成一个有序的输入流。
Reduce 计算：归并后的数据作为 reduce() 函数的数据源，按 key 分组喂给业务逻辑，最终结果写入 HDFS。

📌 核心特征：整个过程中数据要经历 HDFS输入文件 → Map内存溢出到本地磁盘 → Reduce读取本地文件到内存 → Reduce内存溢出到多个本地磁盘→ 合并到一个本地文件 多次落盘，I/O 是性能瓶颈的根源。也就是为什么后面出现了Tez执行引擎

② 多 Job 串行的痛点

1
2
3


SELECT a.x, SUM(b.y) FROM a 
JOIN b ON a.id = b.id 
GROUP BY a.x;

会被拆分成：

Job 1（JOIN）：Map(读 a/b) → Shuffle → Reduce(关联) → 写 HDFS 临时目录
Job 2（GROUP BY）：Map(读临时文件) → Shuffle → Reduce(聚合) → 输出

两个 Job 之间通过 HDFS 传递中间结果，复杂 SQL 可能产生 5~10 个串行 Job，每个 Job 都要重启 JVM、重新读写 HDFS，性能极差。

③ 优缺点

维度	表现
✅ 稳定性	极高，“慢但不死”，适合 PB 级离线批处理
✅ 容错性	任务失败粒度细，单 Task 失败重跑代价小
❌ 性能	中间结果反复落盘（本地磁盘 + HDFS），磁盘 I/O 巨大
❌ 启动开销	每个 Job 启动 JVM，多 Stage SQL 启动开销叠加
❌ DAG 表达力	只能"两段式"（Map→Reduce），复杂 SQL 必须拆成多个 Job 串行

⚠️ Hive 2.0 起官方已标记 MR 为 deprecated，Hive 3.x 默认不再推荐使用，Hive 4.0 已彻底移除 MR 引擎支持。

3.2 Tez 引擎（在 MR 基础上的"DAG 化"升级）

① 定位与起源

Apache Tez 是面向大规模数据处理、支持 DAG(Directed Acyclic Graph) 作业的通用计算框架，直接源自 MapReduce——可以理解为"MR 的进化版"。它完全兼容 MR 的能力（Map/Reduce 语义、Shuffle 语义、容错语义），但在此之上提供了更灵活的作业表达模型，允许多种作业形式在同一集群内统一调度。

MapReduce的固定模型：一旦这个 Job 需要跨分区重分布数据，执行模式必须按Map -> Shuffle/Sort -> Reduce的固定三阶段执行，导致冗余的I/O和调度开销。
- 注意：这里强调的是一旦这个 Job 需要跨分区重分布数据，如对于 group by、join、distinct、全局排序等需要按 key 汇聚数据的任务。MapReduce 对这类复杂多阶段任务的表达能力较弱，多个阶段往往需要拆成多个 Job，通常需要经过 Shuffle/Sort，再由 Reduce 处理，并通过 HDFS 落盘（HDFS落盘=HDFS->本地磁盘）传递中间结果，从而带来额外 I/O 和调度开销。
- 并不是所有任务都必须有 Reduce，也不是所有场景都必须发生完整 Shuffle。Map-only 任务可以没有 Shuffle；如果数据已经按计算 key 做了合适的分区/分桶/排序，执行引擎可能减少或避免某些 Shuffle。

Directed Acyclic Graph 有向无环图：在计算引擎里，DAG 表示一个作业中，各个计算步骤之间的依赖关系图。比如 SQL：

1
2
3
4
5


SELECT user_id, COUNT(*)
FROM logs
WHERE dt = '2026-05-27'
 AND event_type = 'click'
GROUP BY user_id;

传统 MapReduce 更像这样：

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


Map：

各个Map（读 logs、过滤 dt、过滤 event_type）
→ 各个Map生成中间结果 
→ Map将中间结果写入本地磁盘 

Shuffle：
按照user_id进行分区，相同user_id分配到同一个 Reducer
→ 各个Reducer 通过网络从各个 Mapper 所在节点拉取对应分区的中间结果，合并结果

Reduce：
Reducer 对相同 `city` 的数据做最终聚合，例如 `COUNT(*)`

Output：
Reduce 结果直接写入 HDFS。

DAG 引擎会先看到完整流程，再切分执行阶段分析，而不是每一步都机械地变成一个 MR Job（例如：哪些操作可以合并？哪里必须 Shuffle？哪里可以 pipeline？哪里可以避免落盘？哪里可以并行？）
1 2 3 4 5

Read → Filter → Partial Count ↓ Shuffle ↓ Final Count → Outputort

Tez的DAG模型：允许你根据实际数据处理逻辑，自由定义任务节点（可以是Map、Reduce或其他处理器）和它们的依赖边。DAG 引擎相比 MapReduce 的优势在于，它能从全局依赖关系出发，把多个操作组合成更灵活的执行图，只在必要的边界进行 Shuffle 或落盘。例如，一个作业可以是 Map -> Reduce，也可以是 Map -> Map -> Reduce，甚至是多个Map的输出汇合到一个Reduce。

Tez 由 Hortonworks 主导贡献给 Apache 社区，HDP/CDP 体系（现 Cloudera CDP）默认采用。

② 核心抽象：Vertex + Edge

Tez 最关键的创新是把 MR 那种僵硬的 “Map + Reduce 两段式” 拆解为更细粒度的元操作，重新组合成 DAG：

Tez 抽象	含义	类比 MR
Vertex（顶点）	一个计算节点，代表一组并行执行的 Task	相当于一个 Map 阶段或 Reduce 阶段
Vertex Input	Vertex 的数据输入逻辑	类比 MR 的 InputFormat
Vertex Output	Vertex 的数据输出逻辑	类比 MR 的 OutputFormat
Sorting	排序原语	MR 中固化在 shuffle 里，Tez 中可选
Shuffling	跨节点数据传输	MR 的 shuffle 阶段
Merging	归并多源数据	MR 的 merge 阶段
Edge（边）	Vertex 之间的数据通信通道	相当于 MR Job 之间的 HDFS 中转

💡 关键思想：Sorting / Shuffling / Merging 这些在 MR 中强制绑定的步骤，在 Tez 里变成可拆卸、可组合的元操作。例如某些 Join 不需要排序，Tez 就可以跳过 Sorting；某些计算不需要全量 shuffle，可以用更轻量的 Edge 类型（如 Broadcast Edge）。

这些元操作被控制程序（DAG Plan）灵活组装后，形成一张完整的 DAG 作业——原本需要 N 个 MR Job 串行的 SQL，现在可以塞进一个 Tez DAG 任务一次性跑完。

③ 与 MR 的对比图（逻辑示意）

假设有 SQL：

1
2
3
4


SELECT city, COUNT(*) AS cnt
FROM user_log
WHERE dt = '2026-05-27'
GROUP BY city;

对比项	Hive on MapReduce	Hive on Tez	Hive on Spark
核心定位	Hive SQL 被编译成一个或多个 MapReduce Job 执行	Hive SQL 被编译成 Tez DAG 执行	Hive SQL 被编译成 Spark 执行计划，通过 Spark DAG/Stage 执行
执行模型	主要是 `Map-only` 或 `Map → Shuffle/Sort → Reduce`	`DAG → Vertex → Task`	`Application → Job → Stage → Task`
过程	Map 阶段：读取 HDFS 上的输入数据执行过滤条件，例如 `dt = '2026-05-27'` 生成中间 KV，例如 `(city, 1)` Map 输出会按照分区规则写入本地磁盘的中间文件，不是写入 HDFS Shuffle/Sort 阶段：按照 `city` 进行分区。相同 `city` 的数据会被分配到同一个 Reducer。 Reducer 通过网络从各个 Mapper 所在节点拉取对应分区的中间结果。拉取后会进行 merge/sort。 Reduce 阶段： Reducer 对相同 `city` 的数据做最终聚合，例如 `COUNT()`。 Output 阶段：* Reduce 结果直接写入 HDFS。如果 SQL 很复杂，例如包含多个 join、group by、order by，可能被拆成多个 MR Job 串联执行，Job 之间通常通过 HDFS 落盘传递中间结果。	Vertex 1：读取数据。执行过滤条件。执行局部聚合，例如先在每个 Task 内部做 `city → partial count`。 Shuffle Edge by city：通过 Tez Edge 按 `city` 重新分布数据。相同 `city` 的数据进入下游对应的 Vertex Task。 Vertex 2：执行全局聚合。输出最终结果。相比 MapReduce，Tez 可以把多个处理阶段组织成一个 DAG，不一定每个阶段都落 HDFS。	Stage 0：读取数据。执行过滤。执行 map-side combine / partial aggregation。执行 shuffle write，把按 `city` 分区后的中间结果写到本地磁盘，供下游 Stage 拉取。 Shuffle：按照 `city` 重新分布数据。 Stage 1：执行 shuffle read。读取上游 Stage 的 shuffle 文件。执行 reduce aggregation，也就是最终聚合。输出结果到 HDFS 或其他存储。
是否必须有 Reduce/Shuffle	不一定。如果只是 `SELECT ... WHERE ...` 这种过滤/投影，可以是 Map-only Job。如果有 `GROUP BY city`，一般需要 Shuffle 和 Reduce。	不一定。如果只是过滤/投影，可以只有一个 Vertex。如果有 group by/join/order by，则 DAG 中会出现 Shuffle Edge。	不一定。窄依赖操作，例如 filter/map/project，可以放在同一个 Stage。遇到 groupBy/join/distinct/orderBy 这类宽依赖，通常会产生 Shuffle 并切分 Stage。
中间结果位置	Map 输出中间结果主要在 Mapper 节点本地磁盘。多个 MR Job 之间的中间结果通常落 HDFS。	Vertex 之间可以通过内存、本地磁盘、网络传输。不必像多个 MR Job 那样频繁落 HDFS。	Stage 内部可以 pipeline。 Shuffle 文件通常写本地磁盘。 RDD/DataFrame 可以 cache/persist 到内存或磁盘。
DAG 能力	单个 MR Job 本身不是灵活 DAG。复杂 SQL 往往拆成多个 MR Job 串起来。	Tez 的核心就是 DAG。 Hive 会把 SQL 编译成 Vertex + Edge 的 DAG。	Spark 也是 DAG 执行。 Spark 根据 RDD lineage 或 Spark SQL 物理计划生成 DAG，再切分 Stage。
优化	主要依赖 Hive 优化器 + MapReduce 能力。常见优化包括：分区裁剪。列裁剪。谓词下推。 Map-side aggregation。 Combiner。 MapJoin。 Bucket Map Join。 Sort-Merge Bucket Join。压缩。合理设置 Reducer 数量。	相比 MR，可以减少不必要的 HDFS 落盘。多个阶段可以组织成一个 DAG。支持更灵活的数据传输边，例如 shuffle edge、broadcast edge。可以减少 Job 启动开销。更适合 Hive SQL 批处理查询。	支持 Catalyst 优化器和 Tungsten 执行优化。可以做 whole-stage codegen。支持 cache/persist。对迭代计算、交互式查询、复杂 ETL 更友好。可以通过 AQE 自适应优化 shuffle 分区、join 策略等。
优点	模型简单。稳定成熟。容错能力强。适合传统大规模离线批处理。	相比 MR 更快。减少多 MR Job 之间的 HDFS 落盘。更适合 Hive SQL。资源利用率更好。	通用性强。不只支持 SQL，还支持 DataFrame、RDD、机器学习、流处理。内存计算能力强。复杂任务性能通常更好。
缺点	多阶段 SQL 容易拆成多个 MR Job。 Job 启动开销较大。中间结果频繁落 HDFS。对复杂 DAG 表达能力弱。交互式查询性能较差。	主要作为 DAG 执行框架，本身不是完整通用计算生态。通常依赖 Hive/Pig 等上层系统。调优也有一定复杂度。	集群资源消耗可能更高。内存管理、shuffle、倾斜、executor 配置调优复杂。 Hive on Spark 在很多企业环境中不一定是主流 Hive 执行方式。
适合场景	传统离线批处理。稳定性要求高、性能要求不极致的任务。老 Hadoop 集群。	Hive SQL 批处理查询。希望替代 Hive on MR，提高 SQL 执行效率。	复杂 ETL。交互式分析。机器学习。流批一体。需要复用 Spark 生态的场景。

④ Tez 在 Hive 上的关键收益

DAG 一次性执行：让 Hive 一条复杂 SQL 在一个 Tez 任务内跑完，而不是多个 MR Job 串行。
中间结果免落 HDFS：上游 Vertex 输出通过 Edge 直接传给下游 Vertex，走内存或本地磁盘，不强制写 HDFS。
容器复用（Container Reuse）：一个 YARN Container 可被多个 Task 复用，避免反复启动 JVM。
动态优化：Dynamic Partition Pruning、Runtime Reoptimization 等，运行时根据数据量动态调整 reducer 数、shuffle 策略。

⑤ 优缺点

维度	表现
✅ 性能	相比 MR 提升 3~10 倍，尤其多 Join、多聚合 SQL
✅ 资源利用	Container 复用 + 动态调度，YARN 资源效率更高
✅ Hive 集成度	专为 Hive 优化，与 CBO、向量化执行、LLAP 配合最好
❌ 通用性	几乎只服务 Hive/Pig，不像 Spark 是通用计算引擎
❌ 社区活跃度	近几年活跃度下降，主要靠 Cloudera 维护

💡 HDP/CDP 体系的 Hive 默认引擎就是 Tez，配合 LLAP（Long-Live and Process） 可以做到秒级交互式查询。

3.3 Spark 引擎（Hive on Spark）

① 定位

Apache Spark 是专为大规模数据处理而设计的快速、通用、支持 DAG 作业的计算引擎，类似于 Hadoop MapReduce 的通用并行框架，可用来构建大型、低延迟的数据分析应用。Spark 是大规模数据处理的统一分析引擎，核心特点：

基于内存计算：中间结果优先驻留内存（RDD/DataFrame Cache），相比 MR 的反复落盘，数据处理实时性大幅提升。
高容错：通过 RDD 的 Lineage（血缘）机制，失败时可重算丢失分区，无需全量重跑。
高可伸缩：可部署在大量普通硬件上形成集群，从单机到数千节点弹性扩展。
通用性：同一个引擎覆盖批处理、流计算（Structured Streaming）、机器学习（MLlib）、图计算（GraphX）。

Hive on Spark 就是把 Hive 的物理计划翻译成 Spark 的 RDD/DAG 任务 来执行，由 Cloudera 主导推进（CDH 体系默认）。

② 概念定义

1、RDD = Resilient Distributed Dataset 弹性分布式数据集，它是 Spark 早期最核心的抽象，可以拆成三层理解

Dataset：数据集，RDD 表示一批数据。比如日志文件：
1 2 3 4

line1 line2 line3 ...
在 Spark 里可以表示成 val rdd = sc.textFile("hdfs://logs")
Distributed：分布式，RDD 不是存在一台机器上，而是被切成多个 partition，分布在集群多个 Executor 上。
1 2 3 4 5

RDD ├── Partition 0 → Executor A ├── Partition 1 → Executor B ├── Partition 2 → Executor C └── Partition 3 → Executor D
这里的 partition 是 Spark 内部的计算分区，不要和 Hive 表分区完全混淆。（Hive 表分区通常是物理目录：/dt=2026-05-27/hour=10/）

Spark RDD partition 是执行层面的数据切片：
1 2 3

Task 0 处理 Partition 0 Task 1 处理 Partition 1 Task 2 处理 Partition 2
Resilient：弹性/容错，RDD 的重点是：

它不一定要把每一步的中间结果都持久化下来，而是记录“这个 RDD 是怎么由上游 RDD 计算出来的”。（这就是 lineage，血缘）例如：
1 2 3 4 5

val rdd1 = sc.textFile("logs") val rdd2 = rdd1.map(parse) val rdd3 = rdd2.filter(_.isValid) val rdd4 = rdd3.map(x => (x.userId, 1)) val rdd5 = rdd4.reduceByKey(_ + _)
血缘关系是：rdd1 → rdd2 → rdd3 → rdd4 → rdd5 用于实现 RDD 的容错能力

如果 rdd3 的某个 partition 丢了，Spark 可以根据血缘重新算：
1 2 3 4 5 6 7

rdd1 的对应 partition ↓ 重新 map ↓ 重新 filter ↓ 恢复 rdd3 的那个 partition

2、某分区数据丢失

“分区数据丢失”通常不是指 Hive 表分区目录丢了，而是指：计算过程中，某个 Task 产生的中间结果丢失了。比如 Spark 中：

1

RDD Partition 3 缓存在 Executor B 内存中

后来：Executor B 挂了，那么 Partition 3 的缓存数据就没了 但是 Spark 有 lineage存储了 Partition 3 是怎么从上游 partition 算出来的，所以可以重新计算。

MapReduce 的 Map 输出中间结果通常在本地磁盘。比如：

1
2


MapTask_1 在 NodeA 上产生中间文件
ReduceTask_3 需要从 NodeA 拉这个文件

如果 NodeA 挂了，Reduce 拉不到这个中间结果。

MapReduce 的处理方式是：

1
2
3


重新运行失败的 MapTask_1
重新生成中间输出
Reduce 再去拉

所以 MapReduce 也有容错。但是它的容错方式更偏：Task 级别重试

Spark RDD 更强调：通过 RDD 血缘关系重算丢失的 partition

③ ⚠️ 区分两个易混概念

概念	入口	SQL 解析	物理执行	元数据
Hive on Spark	Hive CLI / HS2	Hive 解析器	Spark RDD	Hive Metastore
Spark on Hive（Spark SQL + HMS）	Spark / SparkSQL	Spark Catalyst	Spark Tungsten	Hive Metastore

业界主流是后者：Spark 自己解析 + 自己执行，只借用 HMS 读元数据。Hive 退化成元数据中枢。

④ 核心改进

天然 DAG + 内存计算：中间结果优先驻留内存（RDD/DataFrame Cache），磁盘 I/O 大幅降低。
统一执行模型：Map/Reduce/Shuffle 都是 RDD 上的算子，调度粒度细化为 Stage → Task。
Tungsten + CodeGen：堆外内存管理 + 全阶段代码生成，把物理执行下推到接近手写代码的效率。
丰富生态：批/流/ML/图一栈式复用，无需为不同负载切换引擎。

⑤ 优缺点

维度	表现
✅ 性能	内存计算 + Tungsten 优化，复杂 SQL 与 Tez 相当或更快
✅ 生态	MLlib、Structured Streaming、GraphX 一栈式
✅ 通用性	不仅服务 Hive，还能跑批/流/ML，企业一栈式落地
❌ 资源占用	内存吃得多，OOM 风险比 Tez 高
❌ 版本耦合	Hive on Spark 版本兼容性敏感（Hive ↔ Spark 严格对应）

维度	表现
✅ 性能	内存计算，复杂 SQL 表现优秀，与 Tez 相当或更快
✅ 生态	Spark 生态丰富（MLlib、Streaming、GraphX），同一个引擎可复用
✅ 通用性	Spark 不仅服务 Hive，还能跑批/流/ML，企业一栈式
❌ 资源占用	内存吃得多，OOM 风险比 Tez 高
❌ 与 Hive 耦合	Hive on Spark 版本兼容性较敏感（Hive 版本 ↔ Spark 版本严格对应）

3.4 三者对比总表（重点记忆）

对比项	MapReduce	Tez	Spark
执行模型	两段式 Map-Reduce	DAG	DAG + 内存计算
中间结果	必须落 HDFS	内存 / 本地磁盘	优先内存（可 cache）
JVM 启动	每 Task 一个，启动开销大	Container 复用	Executor 长驻，任务复用，启动开销小。
多 Stage SQL	多个 Job 串行	一个 DAG	一个 DAG
性能	⭐（最慢）	⭐⭐⭐⭐	⭐⭐⭐⭐ 比基于磁盘的 MapReduce 快 10-100 倍
稳定性	⭐⭐⭐⭐⭐	⭐⭐⭐⭐	⭐⭐⭐
资源占用	低（磁盘换内存）	中	高（内存密集）
典型发行版	Hive 1.x、早期 CDH	HDP / CDP	CDH / 通用
当前状态	已废弃	仍在维护	主流之一
适用场景	超大规模、稳定优先的离线批	Hive 交互式 / 批处理（HDP/CDP）	批流一体、ML 一栈式

3.5 实际工程中的选型建议

新项目几乎不再选 MR：太慢，且官方已废弃。除非有遗留作业兼容性需求。
HDP/CDP 体系 → Tez + LLAP：交互式查询体验最好，是 Hive 原生最优解。
需要一栈式（批 + 流 + ML）→ Spark SQL on Hive Metastore：现代数据平台主流姿势，Hive 退化为元数据服务（HMS），计算全交给 Spark。
湖仓一体场景（Delta/Iceberg/Hudi）→ Spark / Flink / Trino：Hive 本身的执行引擎已经不是重点，HMS 仍作为元数据中枢继续存在。

🎯 趋势总结：Hive 正在从"计算+存储+元数据"的三合一系统，演变为Hive Metastore（HMS）+ 计算引擎插件化的模式。MR 已退场，Tez 守住 Hive 自家阵地，Spark 则在更大的数据平台范畴内成为事实标准。

引擎	核心思想	优点	缺点	应用场景比喻
MapReduce	分而治之。将任务分成Map（映射）和Reduce（归约）两个阶段，中间结果写入磁盘。	1. 非常稳定，Hadoop原生支持。 2. 适合处理海量离线数据。 3. 容错性强。	1. 速度慢，每一步都要读写磁盘。 2. 编程模型相对复杂。	“绿皮火车”：稳定、能拉重货（海量数据），但速度慢。
Tez	有向无环图优化。将多个MR任务拼接成一个更复杂的执行图，减少不必要的磁盘I/O。	1. 比MR快数倍。 2. 资源利用率更高。 3. 与Hive、YARN集成好。	生态系统和社区活跃度低于Spark。	“动车组”：在原有铁路（YARN）上大幅提速，是MR的优化升级版。
Spark	基于内存的迭代计算。将数据尽可能放在内存中处理，并提供了更丰富的算子（API）。	1. 速度极快，比MR快10-100倍。 2. 提供一站式解决方案（Spark SQL, Streaming, MLlib）。 3. 生态火爆，是当前主流。	对内存资源要求高，配置不当易OOM（内存溢出）。	“高铁”：速度最快，乘坐体验（开发体验）好，是现代主流选择。

【七】Hive 运算逻辑：数学 / 逻辑 / 条件 / 日期 / 字符串函数

Sun, 24 May 2026 21:19:27 +0800

Hive运算

一、数学运算（Arithmetic Operations）

Hive 支持标准 SQL 的数学运算符，用于数值计算。

1.1 基本算术运算符

1
2
3
4
5
6
7
8
9


-- 加、减、乘、除、取余
SELECT 
 10 + 5 AS addition, -- 15
 10 - 5 AS subtraction, -- 5 
 10 * 5 AS multiplication, -- 50
 10 / 3 AS division, -- 3.3333
 10 % 3 AS modulus, -- 1
 10 DIV 3 AS integer_division -- 3 (Hive 3.0+)
FROM table_name LIMIT 1;

1.2 数学函数

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


-- 常用数学函数
SELECT
 ABS(-10) AS absolute, -- 10（绝对值）
 ROUND(3.14159, 2) AS round2, -- 3.14（四舍五入）
 CEIL(3.2) AS ceiling, -- 4（向上取整）
 FLOOR(3.8) AS floor, -- 3（向下取整）
 POWER(2, 3) AS power, -- 8.0（平方）
 SQRT(16) AS sqrt, -- 4.0（开根）
 EXP(1) AS exp, -- 2.71828（e的n次方）
 LN(10) AS ln, -- 2.30259（log2）
 LOG10(100) AS log10, -- 2.0（log10）
 RAND() AS random, -- 0.0~1.0随机数（随机数）
 SIGN(-5) AS sign_negative -- -1（符号函数（取正负号））
FROM table_name LIMIT 1;

1.3 三角函数

1
2
3
4
5
6
7


-- 角度弧度转换
SELECT
 SIN(RADIANS(30)) AS sin30, -- 0.5
 COS(0) AS cos0, -- 1.0
 TAN(PI()/4) AS tan45, -- 1.0
 DEGREES(PI()) AS degrees -- 180.0
FROM table_name LIMIT 1;

二、逻辑运算（Logical Operations）

用于条件判断和布尔运算，返回 TRUE/FALSE/NULL。

2.1 比较运算符

支持：

等值(=)、不等值(!= 或 <>)、小于(<)、小于等于(<=)、大于(>)、大于等于(>=)

字符串比较（字典序）

BETWEEN

LIKE 模糊匹配

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


SELECT
 -- 数值比较
 10 > 5 AS greater_than, -- TRUE
 10 <= 10 AS less_equal, -- TRUE
 10 != 5 AS not_equal, -- TRUE
 10 <> 5 AS not_equal2, -- TRUE

 -- 字符串比较（字典序）
 'apple' < 'banana' AS str_compare, -- TRUE

 -- BETWEEN
 15 BETWEEN 10 AND 20 AS between, -- TRUE

 -- IN
 'red' IN ('red', 'blue', 'green') AS in_set, -- TRUE

 -- LIKE 模糊匹配
 'hello' LIKE 'he%' AS like_match, -- TRUE
 'data' LIKE 'd_t_' AS like_single -- TRUE
FROM table_name LIMIT 1;

2.2 逻辑运算符

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


SELECT
 -- AND/OR/NOT
 (10 > 5) AND (3 < 4) AS and_result, -- TRUE
 (10 < 5) OR (3 < 4) AS or_result, -- TRUE
 NOT (10 < 5) AS not_result, -- TRUE

 -- 处理 NULL
 NULL IS NULL AS is_null, -- TRUE
 NULL IS NOT NULL AS is_not_null, -- FALSE

 -- 特殊NULL处理函数
 COALESCE(NULL, 'default') AS coalesce, -- 'default'
 NVL(NULL, 'backup') AS nvl_result, -- 'backup'
 NULLIF(10, 10) AS nullif_same, -- NULL
 NULLIF(10, 5) AS nullif_diff -- 10
FROM table_name LIMIT 1;

2.3 CASE 条件表达式

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


-- 简单CASE
SELECT 
 user_id,
 CASE age
 WHEN age < 18 THEN '未成年'
 WHEN age BETWEEN 18 AND 35 THEN '青年'
 WHEN age BETWEEN 36 AND 60 THEN '中年'
 ELSE '老年'
 END AS age_group
FROM users;

-- 搜索CASE
SELECT
 order_id,
 amount,
 CASE
 WHEN amount > 1000 THEN '大额'
 WHEN amount > 500 THEN '中额'
 WHEN amount > 0 THEN '小额'
 ELSE '异常'
 END AS amount_level
FROM orders;

三、数值运算与聚合

3.1 类型转换函数

1
2
3
4
5
6
7


SELECT
 CAST('123' AS INT) AS cast_int, -- 123
 CAST(123.456 AS DECIMAL(5,2)) AS cast_decimal, -- 123.46
 CONVERT('123.45', DOUBLE) AS convert_double, -- 123.45
 -- 隐式转换（自动）
 10 + '5' AS implicit_cast -- 15.0
FROM table_name LIMIT 1;

3.2 聚合计算

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


-- 基本聚合
SELECT
 COUNT(*) AS total_count,
 COUNT(DISTINCT user_id) AS distinct_users,
 SUM(amount) AS total_amount,
 AVG(amount) AS avg_amount,
 MIN(amount) AS min_amount,
 MAX(amount) AS max_amount,
 VARIANCE(amount) AS variance_amount,
 STDDEV(amount) AS stddev_amount
FROM transactions
WHERE dt = '2023-10-01';

-- 分组聚合
SELECT
 department,
 AVG(salary) AS avg_salary,
 PERCENTILE_APPROX(salary, 0.5) AS median_salary -- 近似中位数
FROM employees
GROUP BY department;

3.3 窗口计算

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


-- 窗口函数（分析函数）
SELECT
 user_id,
 order_date,
 amount,
 SUM(amount) OVER (
 PARTITION BY user_id 
 ORDER BY order_date 
 ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW
 ) AS running_total,
 AVG(amount) OVER (PARTITION BY user_id) AS user_avg,
 RANK() OVER (PARTITION BY product_id ORDER BY amount DESC) AS sales_rank
FROM orders;

四、条件函数（Conditional Functions）

4.1 函数清单一览

函数	语法	作用
`IF`	`IF(boolean testCondition, T valueTrue, T valueFalseOrNull)`	二选一分支
`COALESCE`	`COALESCE(T v1, T v2, ...)`	返回第一个非 NULL 值
`NVL`	`NVL(T value, T default_value)`	如果是 NULL 返回默认值
`CASE WHEN`	`CASE WHEN c1 THEN r1 WHEN c2 THEN r2 ELSE rN END`	多分支判断
`CASE 字段`	`CASE col WHEN v1 THEN r1 ELSE rN END`	等值多分支
`NULLIF`	`NULLIF(a, b)`	当 a=b 时返回 NULL，否则返回 a
`ISNULL` / `ISNOTNULL`	`ISNULL(a)`	判断是否为 NULL
`assert_true`	`assert_true(boolean)`	断言为真，否则抛异常（常用于数据校验）

4.2 详解 + 示例

① IF

1
2
3
4


SELECT IF(score >= 60, '及格', '不及格') AS result FROM students;
-- 注意：valueTrue 和 valueFalse 必须类型一致或可隐式转换

SELECT IF(1=1, 'a', 100); -- 会报错或隐式转 string

② COALESCE（最常用！）

返回第一个非 NULL 的值,如果所有值都为NULL，那么返回NULL

1
2
3
4


SELECT COALESCE(phone, email, '未知联系方式') FROM user_info;
-- 先判断 phone，若非 NULL 则返回 phone；
-- 若 phone为 NULL，则判断 email，若非 NULL 则返回 email；
-- 若 phone和 email都为 NULL，则返回字符串 '未知联系方式'。

👉 场景：多字段降级取值、空值兜底。

③ NVL（COALESCE 的简化版，只支持两个参数）

1
2
3
4


SELECT NVL(salary, 0) FROM emp;
-- 等价于 COALESCE(salary, 0)
-- 如果 salary字段不为 NULL，就返回 salary的值；
-- 如果 salary为 NULL，就返回 0

④ CASE WHEN（最灵活）

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


-- 写法一：搜索式（条件可以是任意表达式）
SELECT
CASE
WHEN score >= 90 THEN 'A'
WHEN score >= 80 THEN 'B'
WHEN score >= 60 THEN 'C'
ELSE 'D'
END AS grade
FROM students;

-- 写法二：简单式（只能做等值判断）
SELECT
CASE gender
WHEN 'M' THEN '男'
WHEN 'F' THEN '女'
ELSE '未知'
END
FROM user_info;

👉 易错点：CASE 必须以 END 结尾；多个 WHEN 命中时只返回第一个。

⑤ NULLIF

为0则返回NULL

1
2
3


SELECT NULLIF(a, 0); -- 当 a=0 时返回 NULL，避免除零

SELECT amount / NULLIF(qty, 0) FROM orders; -- 经典防除零写法

⑥ ISNULL / ISNOTNULL

过滤指定值为NULL的数据行

1
2
3
4
5


SELECT * FROM t WHERE ISNULL(col);
SELECT * FROM employee WHERE col IS NULL;

SELECT * FROM t WHERE ISNOTNULL(col); -- 等价于 col IS NOT NULL
SELECT * FROM employee WHERE col IS NOT NULL;

4.3 易错点 ⚠️

类型一致性：IF、CASE 返回的多个分支必须是兼容类型，否则报错或隐式转换出错。
NULL 比较：NULL = NULL 结果是 NULL（不是 true），所以 CASE WHEN col = NULL 永远不命中，必须用 IS NULL。
短路求值：COALESCE 是短路的，但所有参数会先做类型检查。

五、日期函数（Date Functions）

Hive 中日期可以是 DATE（仅日期）、TIMESTAMP（含时间）、STRING（‘yyyy-MM-dd HH:mm:ss’ 格式）三种形式，函数大多对字符串友好。

5.1 函数清单一览（按用途分类）

📌 获取当前时间

函数	返回
`current_date()`	当前日期，DATE
`current_timestamp()`	当前时间戳，TIMESTAMP
`unix_timestamp()`	当前时区的 Unix 秒数（已不推荐，因为非确定性）

📌 时间戳 ↔ 字符串/日期转换

函数	说明
`unix_timestamp(string date[, pattern])`	字符串 → Unix 秒（默认 `yyyy-MM-dd HH:mm:ss`）转换失败则返回0
`unix_timestamp(string date, string pattern)`	自定义格式 → Unix 秒
`from_unixtime(bigint unixtime[, pattern])`	Unix 秒 → 字符串,pattern为yyyyMMdd
`to_date(string ts)`	截取日期部分
`to_unix_timestamp(...)`	确定性版本（推荐）

📌 日期组件提取

函数	说明
`year(date)`	取年
`month(date)`	取月
`day(date)` / `dayofmonth(date)`	取日
`hour/minute/second(date)`	取时/分/秒
`weekofyear(date)`	年内第几周
`dayofweek(date)`	星期几（1=Sunday）
`quarter(date)`	季度

📌 日期运算

函数	说明
`datediff(end, start)`	相差天数
`date_add(date, n)`	加 n 天
`date_sub(date, n)`	减 n 天
`add_months(date, n)`	加 n 月
`months_between(d1, d2)`	相差月份（含小数）
`last_day(date)`	当月最后一天
`next_day(date, 'MO')`	下一个周一
`trunc(date, 'MM'/'YY')`	截断到月/年（月初/年初）
`date_format(date, pattern)`	格式化输出

5.2 详解 + 示例

① 当前时间

1
2
3
4
5


SELECT current_date(); -- 2026-05-25

SELECT current_timestamp(); -- 2026-05-25 21:42:41.123

SELECT unix_timestamp(); -- 1748180561（秒）

② Unix 时间戳 ↔ 字符串（最常用！）

1
2
3
4
5
6
7


-- 字符串 → Unix 秒
SELECT unix_timestamp('2026-05-25 21:42:41'); -- 默认格式
SELECT unix_timestamp('2026/05/25', 'yyyy/MM/dd'); -- 自定义格式

-- Unix 秒 → 字符串
SELECT from_unixtime(1748180561); -- '2026-05-25 21:42:41'
SELECT from_unixtime(1748180561, 'yyyy-MM-dd'); -- '2026-05-25'

显示更多行

👉 结合你的项目：Cosmos 时间戳（毫秒）→ Hive 友好的字符串经常需要 from_unixtime(ts/1000, 'yyyy-MM-dd HH') 这类写法。

③ 日期组件提取

1
2
3
4
5


SELECT year('2026-05-25'), -- 2026
month('2026-05-25'), -- 5
day('2026-05-25'), -- 25
weekofyear('2026-05-25'), -- 21
quarter('2026-05-25'); -- 2

④ 日期加减

1
2
3
4
5
6
7
8
9


SELECT date_add('2026-05-25', 7); -- 2026-06-01

SELECT date_sub('2026-05-25', 7); -- 2026-05-18

SELECT add_months('2026-05-25', 1); -- 2026-06-25

SELECT datediff('2026-05-25', '2026-05-01'); -- 24

SELECT months_between('2026-05-25', '2026-01-01'); -- 4.77...

⑤ 截断 & 格式化

1
2
3
4
5
6
7
8
9


SELECT trunc('2026-05-25', 'MM'); -- 2026-05-01（月初）

SELECT trunc('2026-05-25', 'YY'); -- 2026-01-01（年初）

SELECT last_day('2026-05-25'); -- 2026-05-31

SELECT date_format('2026-05-25', 'yyyyMMdd'); -- '20260525'

SELECT date_format('2026-05-25 21:42:41', 'yyyy-MM-dd HH:00:00'); -- 小时桶

⑥ 时区处理

1
2
3
4
5
6


-- from_utc_timestamp / to_utc_timestamp
SELECT from_utc_timestamp('2026-05-25 13:42:41', 'Asia/Shanghai');
-- → '2026-05-25 21:42:41'（UTC + 8h）

SELECT to_utc_timestamp('2026-05-25 21:42:41', 'Asia/Shanghai');
-- → '2026-05-25 13:42:41'

5.3 易错点 ⚠️

unix_timestamp() 无参版本是非确定性函数：在 MapReduce 中可能每个分片得到不同的值，Hive 2.0+ 推荐用 current_timestamp() 或 to_unix_timestamp()。
格式 pattern 大小写敏感：yyyy（年）、MM（月）、mm（分钟）、HH（24h）、hh（12h），写错就全错。
日期相减不是 date1 - date2，必须用 datediff。
dayofweek 默认 Sunday=1，不是 Monday=1。
NULL 输入：所有日期函数对 NULL 输入返回 NULL。

六、字符串函数（String Functions）

6.1 函数清单一览（按用途分类）

📌 长度 & 大小写

函数	说明
`length(s)`	字符长度（中文按字符计数）
`lower(s)` / `lcase(s)`	转小写
`upper(s)` / `ucase(s)`	转大写
`initcap(s)`	首字母大写

📌 截取 & 拼接

函数	说明
`substr(s, start[, len])` / `substring`	截取子串（从 1 开始）
`concat(s1, s2, ...)`	拼接，任一为 NULL 则结果为 NULL
`concat_ws(sep, s1, s2, ...)`	用分隔符拼接，自动忽略 NULL “ws” 是 “with separator”

📌 去空格 & 填充

函数	说明
`trim(s)`	去两端空格
`ltrim(s)` / `rtrim(s)`	去左/右空格
`lpad(s, len, pad)` / `rpad`	左/右补齐
`space(n)`	生成 n 个空格
`repeat(s, n)`	重复 n 次
`reverse(s)`	反转

📌 查找 & 替换

函数	说明
`instr(s, substr)`	子串首次出现位置（从 1 开始，0=未找到）
`locate(substr, s[, pos])`	同 instr，可指定起始位置
`replace(s, old, new)`	普通替换
`regexp_replace(s, regex, new)`	正则替换，s中符合regex的替换为new
`regexp_extract(s, regex, idx)`	通过正则表达式提取字符串匹配部分 idx=0：返回整个匹配的字符串
idx=1：返回第一个捕获组
idx=2：返回第二个捕获组
`regexp(s, regex)`	正则匹配（Hive 2.0+）

📌 拆分 & 解析

函数	说明
`split(s, regex)`	拆成数组
`parse_url(url, partKey[, key])`	解析 URL，partKey为要提取的部分，可以是以下值（不区分大小写）：
`HOST`：主机名
`PATH`：路径
`QUERY`：查询字符串
`REF或 FRAGMENT`：锚点部分
`PROTOCOL`：协议
`AUTHORITY`：授权机构
`FILE`：文件名
`USERINFO`：用户信息
`QUERY:<key>`：查询参数中指定key的值（需要指定第三个参数key）
`get_json_object(json, '$.path')`	从JSON字符串中提取指定路径的值，能处理嵌套的JSON
`json_tuple(json, k1, k2, ...)`	一次提取多个 JSON 字段（更高效），但注意，它不能处理嵌套的JSON，只能提取顶层的键

📌 编码 & 类型转换

函数	说明
`cast(x as string)`	类型转换
`base64(binary)` / `unbase64(s)`	Base64 编解码
`encode(s, charset)` / `decode(b, charset)`	字符集编码
`ascii(s)`	取首字符 ASCII

6.2 详解 + 示例

① 长度与大小写

1
2
3
4


SELECT length('hello世界'); -- 7（按字符算）

SELECT upper('abc'), lower('ABC'), initcap('hello world');
-- 'ABC', 'abc', 'Hello World'

② 截取与拼接

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


-- 注意：Hive substr 索引从 1 开始
SELECT substr('abcdef', 2, 3); -- 'bcd'

SELECT substr('abcdef', -3); -- 'def'（负数从右数）

SELECT concat('a', 'b', 'c'); -- 'abc'

SELECT concat('a', NULL, 'c'); -- NULL ⚠️

SELECT concat_ws('-', 'a', NULL, 'c'); -- 'a-c'（自动忽略 NULL）

SELECT concat_ws(',', array('a', 'b', 'c')); -- 'a,b,c'（拼数组）

③ 去空格 & 填充

1
2
3
4
5
6
7
8
9


SELECT trim(' hello '); -- 'hello'

SELECT lpad('5', 3, '0'); -- '005'（左补 0）

SELECT rpad('abc', 6, '*'); -- 'abc***'

SELECT repeat('ab', 3); -- 'ababab'

SELECT reverse('hello'); -- 'olleh'

④ 查找与替换

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


-- 从头开始查找字符o的出现位置(索引从1开始)
SELECT instr('hello world', 'o'); -- 5

-- 指定起始位置为6，开始搜索字符o
SELECT locate('o', 'hello world', 6); -- 8

-- 将字符串中-替换为_
SELECT replace('a-b-c', '-', '_'); -- 'a_b_c'

-- 正则替换（脱敏经典场景）
SELECT regexp_replace('13812345678', '(\\d{3})\\d{4}(\\d{4})', '$1****$2');
-- '138****5678'

-- 正则提取
SELECT regexp_extract('order_20260525_001', '(\\d{8})', 1); -- '20260525'

👉 注意：Hive 中正则 \d 要写成 \\d（双反斜杠转义）。

⑤ 拆分与 JSON

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


SELECT split('a,b,c', ','); -- ['a','b','c']

SELECT split('a,b,c', ',')[1]; -- 'b'

-- JSON 提取
SELECT get_json_object('{"name":"Tom","age":18}', '$.name'); -- 'Tom'

-- 一次提多个字段（推荐，性能好）
SELECT b.name, b.age
FROM (SELECT '{"name":"Tom","age":18}' AS json) t
LATERAL VIEW json_tuple(t.json, 'name', 'age') b AS name, age;

⑥ URL 解析

1
2
3
4
5


SELECT parse_url('https://www.bing.com/search?q=hive', 'HOST'); -- 'www.bing.com'

SELECT parse_url('https://www.bing.com/search?q=hive', 'QUERY', 'q'); -- 'hive'SELECT parse_url('https://www.bing.com/search?q=hive', 'HOST'); -- 'www.bing.com'

SELECT parse_url('https://www.bing.com/search?q=hive', 'QUERY', 'q'); -- 'hive'

6.3 易错点 ⚠️

concat 遇 NULL 全 NULL：拼接字段时强烈建议用 concat_ws 或先 COALESCE 兜底。
substr 索引从 1 开始，不是 0（和很多编程语言不同）。
正则要双重转义：\d → \\d，\. → \\.。
split 第二个参数是正则：拆分 .、|、+ 等特殊字符要转义，如 split(s, '\\.')。
length 统计字符数，不是字节数：UTF-8 中文一个字符是 3 字节，但 length 返回 1。

6.4 速查表（按使用频率排序）

排名	函数	类别	用途
🔥1	`COALESCE` / `NVL`	条件	空值兜底
🔥2	`CASE WHEN`	条件	多分支判断
🔥3	`date_format`	日期	任意格式化
🔥4	`from_unixtime` / `unix_timestamp`	日期	时间戳互转
🔥5	`datediff` / `date_add`	日期	日期算术
🔥6	`concat_ws`	字符串	安全拼接
🔥7	`substr`	字符串	截取
🔥8	`regexp_replace` / `regexp_extract`	字符串	正则处理
🔥9	`split`	字符串	拆分
🔥10	`get_json_object`	字符串	JSON 解析

【六】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.* 管"读得聪明"。 写时不规整，读时再优化也白搭；写时规整了，读时不开优化也浪费。

什么时候使用雪花模型

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

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

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

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

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

1
2
3
4
5


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

如果用星型模型来设计：

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

1
2
3
4
5
6
7


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

致命问题出现了：

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

1
2
3
4
5
6
7
8
9


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

这种设计的弊端：

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

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

1
2
3
4


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

性能极差，且难以维护。

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

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

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

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

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

3、多类目统计困难

假设我们有销售事实表：

1
2
3
4
5


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

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

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

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

示例代码（错误统计）：

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


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

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

UNION ALL

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

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

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

⚠️ 问题总结：

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

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

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

初级解决方案

步骤1：规范化设计

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


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

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

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

步骤2：插入数据

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


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

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

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

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

1
2
3
4
5
6
7
8
9


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

结果示例：

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

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

拓展SCD概念

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

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

出现原因

业务数据的自然演变：

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

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

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

应对措施

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

桥接表的时间化扩展

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

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

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


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

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

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

 PRIMARY KEY (product_id, category_id, start_date)
);

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

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

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

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

1
2
3
4


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

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

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

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

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


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

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

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

1
2
3
4


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

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

现在桥接表的状态：

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

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

适用场景

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

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


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

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

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

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


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

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

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

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


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

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

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

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

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

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

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


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

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

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

1. 历史可追溯

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

2. 时间一致性

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

3. 变更无影响

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

4. 支持复杂的业务场景

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

实际查询模板

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

1
2


SELECT * FROM bridge_product_category
WHERE CURRENT_DATE BETWEEN start_date AND end_date;

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

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


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

三、完整的数仓分层设计

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

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

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

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


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

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

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

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

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

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


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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

数据处理流程示例

从DWD到DWS的ETL过程

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


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

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

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

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

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

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

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

查询性能对比

雪花模型查询（DWD层）

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


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

星型模型查询（DWS层）

1
2
3
4
5
6
7
8
9


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

分层架构总结

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

关键设计原则：

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

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

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

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

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

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

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

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

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

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

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

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

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

数据类型

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

关键辨析：

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

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

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

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

存储方式与设计原因

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

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

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

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

大数据中的易混淆概念

数据流动方向

如下：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


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

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

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

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

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

假设你有一个电商平台：

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

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

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

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

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

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

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

电商场景的实例

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

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

现代趋势：湖仓一体

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

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

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

为什么会出现 Lakehouse

1）数据仓库的问题

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

2）数据湖的问题

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

湖仓一体 vs. 其他概念

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

Lakehouse 核心能力

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

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

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

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

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

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

Lakehouse的5层架构

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


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

3、分布式计算 MapReduce & YARN

Wed, 08 Apr 2026 21:47:41 +0800

3.1、分布式概述

分布式数据计算分为两种

分散->汇总模式 Spark、Flink
中心调度->步骤执行模式 MapReduce

MapReduce

MapReduce是Hadoop的分布式计算组件（分散->汇总模式），包含两个变成接口

Map提供分散功能，由服务器分布式对数据进行处理
Reduce提供汇总功能，将分布式的处理结果汇总

YARN

YARN是Hadoop内提供的分布式资源调度组件，（资源包括：CPU、内存、硬盘、网络）

服务器会运行多个程序，每个程序对资源（CPU内存等）的使用都不同，程序有多少用多少，没有节制，调度就非常重要了

架构

YARN中的核心角色

ResourceManager：整个集群的资源调度者，负责协调各个程序所需资源
NodeManager：单个服务器的资源调度者，负责调度单个服务器上的资源给应用程序使用

YARN中的辅助角色（运行更稳定）

代理服务器 ProxyServer：Web Application Proxy Web应用程序代理

减少通过YARN进行基于网络的攻击可能性：警告用户正在访问一个不受信任的站点、剥离用户访问的Cookie等
历史服务器 JobHistoryServer：应用程序历史信息记录服务

程序运行时是在各自的map容器中，对应的日志也产生在那里，当想看某个map的日志需要登录对应的服务器+命令行查看。使用JobHistoryServer就可以将日志统一到HDFS中，在页面中查看

3.2、YARN部署

MapReduce配置文件

核心配置文件,hadoop-env.sh - Java环境配置

1
2


cd /export/server/hadoop-3.4.2/etc/hadoop/
vim mapred-env.sh

打开后输入

1
2
3
4
5
6


# 设置JDK路径
export JAVA_HOME=/export/server/jdk
# 设置 JobHistoryServer进程为1G
export HADOOP_JOB_HISTORYSERVER_HEAPSIZE=1024
# 设置日志级别为INFO
export HADOOP_MAPRED_ROOT_LOGGER=INFO,RFA

mapred-site.xml - MapReduce配置（关键！）

1

vim mapred-site.xml

打开后输入

 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


<configuration>
 <property>
 <name>mapreduce.framework.name</name>
 <value>yarn</value>
 <description>指定MapReduce的运行框架为YARN</description>
 </property>
 
 <property>
 <name>mapreduce.jobhistory.address</name>
 <value>node1:10020</value>
 <description>MapReduce历史服务器地址</description>
 </property>

 <property>
 <name>mapreduce.jobhistory.webapp.address</name>
 <value>node1:19888</value>
 <description>MapReduce历史服务器Web UI地址</description>
 </property>
 
 <property>
 <name>mapreduce.jobhistory.intermediate-done-dir</name>
 <value>/data/mr-history/tmp</value>
 <description>历史信息在HDFS的记录临时路径</description>
 </property>
 
 <property>
 <name>mapreduce.jobhistory.done-dir</name>
 <value>/data/mr-history/done</value>
 <description>历史信息在HDFS的记录路径</description>
 </property>
 
 <property>
 <name>yarn.app.mapreduce.am.env</name>
 <value>HADOOP_MAPRED_HOME=$HADOOP_HOME</value>
 <description>MapReduce HOME设置为HADOOP_HOME,作用对象Application Master</description>
 </property>
 <property>
 <name>mapreduce.map.env</name>
 <value>HADOOP_MAPRED_HOME=$HADOOP_HOME</value>
 <description>MapReduce HOME设置为HADOOP_HOME,作用对象Map任务容器</description>
 </property>
 
 <property>
 <name>mapreduce.reduce.env</name>
 <value>HADOOP_MAPRED_HOME=$HADOOP_HOME</value>
 <description>MapReduce HOME设置为HADOOP_HOME,作用对象Reduce任务容器</description>
 </property>
</configuration>

在 $HADOOP_HOME/etc/hadoop 文件夹内，修改

yarn-env.sh文件，添加4行环境变量内容

1

vim yarn-env.sh

1
2
3
4
5
6
7
8


# 设置JDK的环境变量
export JAVA_HOME=/export/server/jdk
# 设置HADOOP_HOME的环境变量
export HADOOP_HOME=/export/server/hadoop
# 设置配置文件路径的环境变量
export HADOOP_CONF_DIR=$HADOOP_HOME/etc/hadoop
# 设置日志文件路径的环境变量
export JAVA_LOG_DIR=$HADOOP_HOME/logs

yarn-site.xml - YARN资源配置

1

vim yarn-site.xml

 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


<configuration>
 <property>
 <name>yarn.resourcemanager.hostname</name>
 <value>node1</value>
 <description>ResourceManager设置在node1节点</description>
 </property>
 
 <property>
 <name>yarn.nodemanager.local-dirs</name>
 <value>/data/nm-local</value>
 <description>NodeManager中间数据本地存储路径</description>
 </property>
 
 <property>
 <name>yarn.nodemanager.log-dirs</name>
 <value>/data/nm-log</value>
 <description>NodeManager数据日志本地存储路径</description>
 </property>
 
 <property>
 <name>yarn.nodemanager.aux-services</name>
 <value>mapreduce_shuffle</value>
 <description>NodeManager上运行的附属服务：开启Shuffle</description>
 </property>
 
 <property>
 <name>yarn.log.server.url</name>
 <value>http://node1:19888/jobhistory/logs</value>
 <description>历史服务器URL</description>
 </property>
 
 <property>
 <name>yarn.web-proxy.address</name>
 <value>node1:8089</value>
 <description>代理服务器主机和端口</description>
 </property>
 
 <property>
 <name>yarn.log-aggregation-enable</name>
 <value>true</value>
 <description>开启日志聚合</description>
 </property>
 
 <property>
 <name>yarn.nodemanagrer.remote-app-log-dir</name>
 <value>/tmp/logs</value>
 <description>程序日志和HDFS的存储路径</description>
 </property>
 
 <property>
 <name>yarn.resourcemanager.scheduler.class</name>
 <value>org.apache.hadoop.yarn.server.resourcemanager.scheduler.fair.FairScheduler</value>
 <description>选择公平调度器</description>
 </property>
</configuration>

分发配置文件

1
2


scp mapred-env.sh mapred-site.xml yarn-env.sh yarn-site.xml node2:`pwd`/
scp mapred-env.sh mapred-site.xml yarn-env.sh yarn-site.xml node3:`pwd`/

启动YARN

	启动	关闭
逐个启停yarn	$HADOOP_HOME/bin/yarn –daemon start resourcemanager\|nodemanager\|proxyserver	$HADOOP_HOME/bin/yarn –daemon stop resourcemanager\|nodemanager\|proxyserver
一键启停yarn	$HADOOP_HOME/sbin/start-yarn.sh	$HADOOP_HOME/sbin/stop-yarn.sh
historyserver	$HADOOP_HOME/bin/mapred –daemon start historyserver	$HADOOP_HOME/bin/mapred –daemon stop historyserver

YARN的WEB UI：查看YARN集群的监控页面（ResourceManager的WEB UI）http://node1:8088

HDFS的WEB UI：http://node1:9870

1

$HADOOP_HOME/sbin/start-yarn.sh

从yarn-site.xml中读取配置，确定ResourceManager所在机器，并启动它
读取workers文件，确定机器，启动全部的NodeManager
当前机器启动ProxySercer（代理服务器）

3.3、提交MapReduce任务到YARN

Hive底层用的MapReduce,目前很少写MapReduce的程序代码

YARN作为资源调度管控框架，提供资源给很多程序运行

MapReduce
Spark
Flink

Hadoop中内置了一些预置的MapReduce程序代码，无需编程，通过命令即可使用。示例程序代码记录在(Hadoop编译之后的jar包)$HADOOP_HOME/share/hadoop/mapreduce/hadoop-mapreduce-examples-3.4.2.jar

wordcount：单词计数（统计指定文件内各个单词出现的次数）
pi：求圆周率（通过蒙特卡罗算法，统计模拟法）

语法：Hadoop jar 程序文件 java类名 [程序参数] ... [程序参数]

3.3.1、wordcount示例

1

hadoop jar $HADOOP_HOME/share/hadoop/mapreduce/hadoop-mapreduce-examples-3.4.2.jar wordcount hdfs://node1:8020/input hdfs://node1:8020/output/wc

输出：

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


2026-04-06 12:10:27,044 INFO client.DefaultNoHARMFailoverProxyProvider: Connecting to ResourceManager at node1/192.168.88.101:8032
2026-04-06 12:10:27,351 INFO mapreduce.JobResourceUploader: Disabling Erasure Coding for path: /tmp/hadoop-yarn/staging/hadoop/.staging/job_1775445823073_0001
2026-04-06 12:10:27,816 INFO input.FileInputFormat: Total input files to process : 1
2026-04-06 12:10:27,874 INFO mapreduce.JobSubmitter: number of splits:1
2026-04-06 12:10:27,954 INFO mapreduce.JobSubmitter: Submitting tokens for job: job_1775445823073_0001
2026-04-06 12:10:27,954 INFO mapreduce.JobSubmitter: Executing with tokens: []
2026-04-06 12:10:28,039 INFO conf.Configuration: resource-types.xml not found
2026-04-06 12:10:28,040 INFO resource.ResourceUtils: Unable to find 'resource-types.xml'.
2026-04-06 12:10:28,406 INFO impl.YarnClientImpl: Submitted application application_1775445823073_0001
2026-04-06 12:10:28,425 INFO mapreduce.Job: The url to track the job: http://node1:8089/proxy/application_1775445823073_0001/
2026-04-06 12:10:28,425 INFO mapreduce.Job: Running job: job_1775445823073_0001
2026-04-06 12:10:34,503 INFO mapreduce.Job: Job job_1775445823073_0001 running in uber mode : false
2026-04-06 12:10:34,503 INFO mapreduce.Job: map 0% reduce 0%
2026-04-06 12:10:40,556 INFO mapreduce.Job: map 100% reduce 0%
2026-04-06 12:10:45,636 INFO mapreduce.Job: map 100% reduce 100%
2026-04-06 12:10:45,645 INFO mapreduce.Job: Job job_1775445823073_0001 completed successfully
2026-04-06 12:10:45,699 INFO mapreduce.Job: Counters: 54
	File System Counters
		FILE: Number of bytes read=136
		FILE: Number of bytes written=621481
		FILE: Number of read operations=0
		FILE: Number of large read operations=0
		FILE: Number of write operations=0
		HDFS: Number of bytes read=152
		HDFS: Number of bytes written=82
		HDFS: Number of read operations=8
		HDFS: Number of large read operations=0
		HDFS: Number of write operations=2
		HDFS: Number of bytes read erasure-coded=0
	Job Counters 
		Launched map tasks=1
		Launched reduce tasks=1
		Data-local map tasks=1
		Total time spent by all maps in occupied slots (ms)=3217
		Total time spent by all reduces in occupied slots (ms)=2836
		Total time spent by all map tasks (ms)=3217
		Total time spent by all reduce tasks (ms)=2836
		Total vcore-milliseconds taken by all map tasks=3217
		Total vcore-milliseconds taken by all reduce tasks=2836
		Total megabyte-milliseconds taken by all map tasks=3294208
		Total megabyte-milliseconds taken by all reduce tasks=2904064
	Map-Reduce Framework
		Map input records=2
		Map output records=12
		Map output bytes=106
		Map output materialized bytes=136
		Input split bytes=94
		Combine input records=12
		Combine output records=12
		Reduce input groups=12
		Reduce shuffle bytes=136
		Reduce input records=12
		Reduce output records=12
		Spilled Records=24
		Shuffled Maps =1
		Failed Shuffles=0
		Merged Map outputs=1
		GC time elapsed (ms)=178
		CPU time spent (ms)=1100
		Physical memory (bytes) snapshot=342614016
		Virtual memory (bytes) snapshot=5439385600
		Total committed heap usage (bytes)=165810176
		Peak Map Physical memory (bytes)=221446144
		Peak Map Virtual memory (bytes)=2715934720
		Peak Reduce Physical memory (bytes)=121167872
		Peak Reduce Virtual memory (bytes)=2723450880
	Shuffle Errors
		BAD_ID=0
		CONNECTION=0
		IO_ERROR=0
		WRONG_LENGTH=0
		WRONG_MAP=0
		WRONG_REDUCE=0
	File Input Format Counters 
		Bytes Read=58
	File Output Format Counters 
		Bytes Written=82

程序运行结束会在目标文件夹中生成两个文件，一个标识运行是否成功，一个为统计结果

1
2
3
4


[hadoop@node1 ~]$ hdfs dfs -ls /output/wc/
Found 2 items
-rw-r--r-- 3 hadoop supergroup 0 2026-04-06 12:10 /output/wc/_SUCCESS
-rw-r--r-- 3 hadoop supergroup 82 2026-04-06 12:10 /output/wc/part-r-00000

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


[hadoop@node1 ~]$ hdfs dfs -cat /output/wc/part-r-00000
a	1
count	1
guess	1
here	1
how	1
is	1
many	1
test	1
text.	1
this	1
word	1
words	1

同时在http://node1:8088/的application中可以看到资源运行的过程，下图为log日志内容

3.3.1、pi示例

1

hadoop jar $HADOOP_HOME/share/hadoop/mapreduce/hadoop-mapreduce-examples-3.4.2.jar pi 3 1000

3表示3个map任务，1000表示模拟求的样本数（越大，越准，耗时越长）输出：

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


[hadoop@node1 ~]$ hadoop jar $HADOOP_HOME/share/hadoop/mapreduce/hadoop-mapreduce-examples-3.4.2.jar pi 3 1000
Number of Maps = 3
Samples per Map = 1000
Wrote input for Map #0
Wrote input for Map #1
Wrote input for Map #2
Starting Job
2026-04-08 22:25:26,997 INFO client.DefaultNoHARMFailoverProxyProvider: Connecting to ResourceManager at node1/192.168.88.101:8032
2026-04-08 22:25:27,205 INFO mapreduce.JobResourceUploader: Disabling Erasure Coding for path: /tmp/hadoop-yarn/staging/hadoop/.staging/job_1775445823073_0003
2026-04-08 22:25:27,285 INFO input.FileInputFormat: Total input files to process : 3
2026-04-08 22:25:27,326 INFO mapreduce.JobSubmitter: number of splits:3
2026-04-08 22:25:27,411 INFO mapreduce.JobSubmitter: Submitting tokens for job: job_1775445823073_0003
2026-04-08 22:25:27,411 INFO mapreduce.JobSubmitter: Executing with tokens: []
2026-04-08 22:25:27,495 INFO conf.Configuration: resource-types.xml not found
2026-04-08 22:25:27,495 INFO resource.ResourceUtils: Unable to find 'resource-types.xml'.
2026-04-08 22:25:27,552 INFO impl.YarnClientImpl: Submitted application application_1775445823073_0003
2026-04-08 22:25:27,568 INFO mapreduce.Job: The url to track the job: http://node1:8089/proxy/application_1775445823073_0003/
2026-04-08 22:25:27,568 INFO mapreduce.Job: Running job: job_1775445823073_0003
2026-04-08 22:25:32,633 INFO mapreduce.Job: Job job_1775445823073_0003 running in uber mode : false
2026-04-08 22:25:32,633 INFO mapreduce.Job: map 0% reduce 0%
2026-04-08 22:25:36,680 INFO mapreduce.Job: map 33% reduce 0%
2026-04-08 22:25:37,687 INFO mapreduce.Job: map 100% reduce 0%
2026-04-08 22:25:41,709 INFO mapreduce.Job: map 100% reduce 100%
2026-04-08 22:25:41,718 INFO mapreduce.Job: Job job_1775445823073_0003 completed successfully
2026-04-08 22:25:41,778 INFO mapreduce.Job: Counters: 54
	File System Counters
		FILE: Number of bytes read=72
		FILE: Number of bytes written=1244037
		FILE: Number of read operations=0
		FILE: Number of large read operations=0
		FILE: Number of write operations=0
		HDFS: Number of bytes read=783
		HDFS: Number of bytes written=215
		HDFS: Number of read operations=17
		HDFS: Number of large read operations=0
		HDFS: Number of write operations=3
		HDFS: Number of bytes read erasure-coded=0
	Job Counters 
		Launched map tasks=3
		Launched reduce tasks=1
		Data-local map tasks=3
		Total time spent by all maps in occupied slots (ms)=7594
		Total time spent by all reduces in occupied slots (ms)=1977
		Total time spent by all map tasks (ms)=7594
		Total time spent by all reduce tasks (ms)=1977
		Total vcore-milliseconds taken by all map tasks=7594
		Total vcore-milliseconds taken by all reduce tasks=1977
		Total megabyte-milliseconds taken by all map tasks=7776256
		Total megabyte-milliseconds taken by all reduce tasks=2024448
	Map-Reduce Framework
		Map input records=3
		Map output records=6
		Map output bytes=54
		Map output materialized bytes=84
		Input split bytes=429
		Combine input records=0
		Combine output records=0
		Reduce input groups=2
		Reduce shuffle bytes=84
		Reduce input records=6
		Reduce output records=0
		Spilled Records=12
		Shuffled Maps =3
		Failed Shuffles=0
		Merged Map outputs=3
		GC time elapsed (ms)=207
		CPU time spent (ms)=2110
		Physical memory (bytes) snapshot=840318976
		Virtual memory (bytes) snapshot=10928119808
		Total committed heap usage (bytes)=548610048
		Peak Map Physical memory (bytes)=279293952
		Peak Map Virtual memory (bytes)=2772090880
		Peak Reduce Physical memory (bytes)=123793408
		Peak Reduce Virtual memory (bytes)=2724159488
	Shuffle Errors
		BAD_ID=0
		CONNECTION=0
		IO_ERROR=0
		WRONG_LENGTH=0
		WRONG_MAP=0
		WRONG_REDUCE=0
	File Input Format Counters 
		Bytes Read=354
	File Output Format Counters 
		Bytes Written=97
Job Finished in 14.825 seconds
Estimated value of Pi is 3.14133333333333333333

2、分布式存储 HDFS

Wed, 25 Mar 2026 22:30:47 +0800

Hadoop 是一个整体生态 / 框架，HDFS 和 YARN 是它里面两个核心组件：

HDFS = 分布式存储 Hadoop Distributed File System（存数据）
YARN = 分布式资源调度 Yet Another Resource Negotiator（管资源、分配算力）
MapReduce = 第一代分布式计算引擎
Hadoop = HDFS + YARN + MapReduce + 周边工具

一、HDFS集群环境部署

1.1 Hadoop 安装包目录结构

安装位置：/export/server/hadoop-3.4.2/,包含以下文件夹

目录	说明
bin	Hadoop最基本的管理脚本和使用脚本的目录，脚本时sbin目录下管理脚本的基础实现，用户可以使用这些脚本管理和使用Hadoop
sbin	Hadoop管理脚本所在目录，包含HDFS和YARN中各类服务的启动/关闭脚本
etc	Hadoop配置文件所在目录(/export/server/hadoop-3.4.2/etc/hadoop/) 第一类1个：hadoop-env.sh(执行任何Hadoop命令，它都会第一时间自动读取hadoop-env.sh，是启动前必须知道的环境信息) 第二类4个：xxxx-site.xml，site表示的是用户定义的配置，会覆盖default中的默认配置。 core-site.xml 核心模块配置（配置回收站） hdfs-site.xml hdfs文件系统模块配置 mapred-stie.xml MapReduce模块配置 yarn-site.xml yarn模块配置第三类1个：workers
share	Hadoop各个模块编译后的jar包所在目录
include	对外提供的变成库头文件（具体动态库+静态库在lib目录中）这些头文件均用C++定义，通常用于C++程序访问HDFS或者编写MapReduce程序
lib	包含Hadoop对外提供的变成动态\|静态库，与include目录中的头文件结合使用
libexec	各个服务对应的shell配置文件所在目录，用于配置日志输出、启动参数，如JVM参数等信息
logs	日志

/data/nn # NameNode 存储目录

/data/dn # DataNode 存储目录

1.2 配置HDFS回收站

HDFS 会保证被删除的文件在回收站（/user/<username>/.Trash/Current）中至少存放 1440min=24h。超过这个时间，系统在下次检查点任务运行时就可以永久删除文件保留。

每 120 分钟（2 小时），HDFS 的 NameNode会启动一个后台任务，检查回收站中哪些文件已经超过了 fs.trash.interval设置的保留期。对于超期的文件，会将其从 Current目录移动到 Checkpoint目录，并最终清理掉。

1
2
3
4
5
6
7
8


 <property>
 <name>fs.trash.interval</name>
 <value>1440</value>
 </property>
 <property>
 <name>fs.trash.checkpoint.interval</name>
 <value>120</value>
 </property>

回收站位置：

1

/usr/hadoop/.Trash

在哪个集群配置就在哪里生效，无需重启集群。配置好后删除文件会进入回收站

1
2


[hadoop@node1 ~]$ hdfs dfs -rm test1.txt
2026-03-24 21:15:54,536 INFO fs.TrashPolicyDefault: Moved: 'hdfs://node1:8020/user/hadoop/test1.txt' to trash at: hdfs://node1:8020/user/hadoop/.Trash/Current/user/hadoop/test1.txt

恢复回收站文件

1
2
3
4
5


# 列出当前用户回收站根目录的内容
[hadoop@node1 ~]$ hdfs dfs -ls /user/hadoop/.Trash/Current

# 如果文件原来在深层目录，回收站会保留完整路径，可以递归查找
[hadoop@node1 ~]$ hdfs dfs -ls -R /user/hadoop/.Trash/Current | grep "被删文件名"

例如：

您删除了文件：/test/data/important.log
它在回收站中的路径将变为：/user/hadoop/.Trash/Current/test/data/important.log

1

hdfs dfs -mv <文件在回收站中的完整路径> <目标恢复路径>

1.3 HDFS集群的Web页面

启动成功后就可以看到hdfs的web：http://node1:9870/

yarn的web：http://node1:8088/

二、HDFS的Shell操作

2.1 Yarn、HDFS、Hadoop启停命令

“启动 Hadoop” = 启动 HDFS + YARN

启动必须切换为非root用户才行

1
2
3
4


[root@node1 ~]# su - hadoop
Last login: Thu Mar 12 21:42:54 CST 2026 on pts/0
[hadoop@node1 ~]$ hdfs namenode -format
# 格式化HDFS（仅首次启动时执行，重复执行会清空数据！）

执行原理：执行脚本的机器上，启动SecondaryNameNode-》读取core-site.xml内容，确定NameNode所在机器，启动NameNode-》读取workers内容，确定DataNode所在机器，启动全部DataNode

以下所有命令的文件存储位置均为

1

$HADOOP_HOME/sbin/stop-dfs.sh(hadoop-daemon.sh)

	手动逐个进程启停(控制所在机器的进程启停)	shell脚本一键启停 (配置好机器之间的SSH免密登录和workers文件)
HDFS集群	# hadoop2.x版本命令($HADOOP_HOME/sbin/hadoop-daemon.sh) `hadoop-daemon.sh start	status
YARN集群	# yarn2.x版本命令 `yarn-daemon.sh start	stop resourcemanager
Hadoop集群		`start-all.sh` `stop-all.sh` 一个命令代替start-dfs.sh和start-yarn.sh

启动完毕之后可以使用jps命令查看进程是否启动成功

1
2
3
4
5
6


[hadoop@node1 ~]$ jps
4608 NameNode
5063 SecondaryNameNode
5421 NodeManager
5789 Jps
5294 ResourceManager

Hadoop启动日志路径：/export/server/hadoop-3.4.2/logs/

2.2 HDFS的文件操作

命令行操作大全：

https://hadoop.apache.org/docs/r3.4.2/hadoop-project-dist/hadoop-common/FileSystemShell.html

当登录linux的hadoop用户后，默认会进入 /home/hadoop/文件夹

当执行hadoop fs或者hdfs dfs命令时操作的都是HDFS 分布式文件系统
HDFS 的实际数据存储路径由 Hadoop 配置文件指定（和 Linux 本地路径是两回事），默认路径是 hdfs://node1:9000/user/hadoop/hdfsAddDirTest（hadoop 用户的 HDFS 家目录）；
这个目录不会直接对应 Linux 本地的某个文件夹，HDFS 的数据是「分块存储」在集群节点的本地磁盘上的，而非单个目录。

HDFS同Linux系统一样均以 / 作为根目录，同一个文件如果同时保存在HDFS、Linux中，此时就无法区分。所以引入协议头的概念(一般会自动识别为file://和hdfs://不用写)

	Linux	HDFS
假设文件位置	/usr/local/hello.txt	/usr/local/hello.txt
协议头	file://	hdfs://namenode:port/
＋协议头后	file:///usr/local/hello.txt	hdfs://node1:8020//usr/local/hello.txt

Hadoop fs [options] fs = File System（通用文件系统）：是更顶层、通用的命令，支持操作 HDFS、本地文件系统（Linux）、S3 等多种文件系统；

hdfs dfs [options] dfs = Distributed File System（分布式文件系统）：是专用于 HDFS 的命令，仅针对 HDFS 操作（本质是 fs 针对 HDFS 的别名）。

早期 Hadoop 只有 HDFS 一种核心文件系统，所以设计了 hdfs dfs 专用于 HDFS；
后来 Hadoop 支持了更多文件系统（如 S3、本地文件），为了统一入口，推出了 hadoop fs，兼容所有文件系统；
为了兼容老用户的使用习惯，hdfs dfs 被保留，本质上 hdfs dfs 就是 hadoop fs 针对 HDFS 的 “快捷方式”。

以下为HDFS文件系统和Linux系统文件的交互方式，必须要记住HDFS上的文件是「分块存储」在集群节点的本地磁盘上的，而非单个目录。

	Hadoop	hdfs
创建文件夹	hadoop fs -mkdir [-p] -p：递归创建	hdfs dfs -mkdir [-p]
查看指定目录下内容	hadoop fs -ls [-h] [-R]	hdfs dfs -ls [-h] [-R]
上传Linux文件到HDFS指定目录下	hadoop fs -put [-f] [-p] -f: 覆盖 -p: 保留访问时间	hdfs dfs -put [-f] [-p] -f: 覆盖 -p: 保留访问时间
查看HDFS文件内容	hadoop fs -cat	hdfs dfs -cat
下载HDFS文件到Linux指定目录下	hadoop fs -get [-f] [-p] -f: 覆盖 -p: 保留访问时间	hdfs dfs -get [-f] [-p] -f: 覆盖 -p: 保留访问时间
拷贝HDFS文件到HDFS文件	hadoop fs -cp [-f] -f: 覆盖	hdfs dfs -cp [-f] -f: 覆盖
追加数据到HDFS文件中(无法修改)	hadoop fs -appendToFile	hdfs dfs -appendToFile
HDFS文件移动	hadoop fs -mv	hdfs dfs -mv
删除指定HDFS文件/文件夹	hadoop fs -rm [-r] [-skipTrash] URI -r：删除文件夹时使用 -skipTrash：	hdfs dfs -rm [-r] [-skipTrash] URI

举例:上传Linux文件到HDFS指定目录下：

1
2
3
4
5
6
7


#上传Linux中/home/hadoop/TestDir/test.txt到hdfs的根目录(写明源为linux)
[hadoop@node1 logs]$ hdfs dfs -put file:///home/hadoop/TestDir/test.txt hdfs://node1:8020/

#查看
[hadoop@node1 logs]$ hdfs dfs -ls / 
#Found 1 items
#-rw-r--r-- 3 hadoop supergroup 44 2026-03-22 10:55 /test.txt

1
2
3
4
5
6
7


[hadoop@node1 ~]$ vim TestDir/test2.txt
#不写明源为linux
[hadoop@node1 ~]$ hdfs dfs -put TestDir/test2.txt /
[hadoop@node1 ~]$ hdfs dfs -ls /
Found 2 items
-rw-r--r-- 3 hadoop supergroup 44 2026-03-22 10:55 /test.txt
-rw-r--r-- 3 hadoop supergroup 21 2026-03-22 11:02 /test2.txt

举例:下载HDFS文件到Linux指定目录下

1
2
3
4
5


[hadoop@node1 ~]$ hdfs dfs -get / ~
[hadoop@node1 ~]$ ll
total 8
-rw-r--r-- 1 hadoop hadoop 21 Mar 22 11:12 test2.txt
-rw-r--r-- 1 hadoop hadoop 44 Mar 22 11:12 test.txt

举例:HDFS文件移动(mv 命令不会自动帮你创建不存在的目录，必须先建目录再移动)

1

[hadoop@node1 ~]$ hdfs dfs -mv /test2.txt /TestDir/new.txt

bash 会先把 ~ 替换成你本地 Linux 的家目录，也就是 /home/hadoop，然后才把命令交给 HDFS 执行

本地 Linux 的家目录：/home/hadoop

HDFS 的家目录：/user/hadoop

所以hdfs dfs -mv /test2.txt ~ 就变成了hdfs dfs -mv /test2.txt /home/hadoop。因此hdfs的home路径只能用 .

1

[hadoop@node1 ~]$ hdfs dfs -mv /test2.txt .

2.3 HDFS的UI操作

hdfs的启动端口保存在$HADOOP_HOME/etc/hadoop/hdfs-site.xml中，可以通过命令行查取

1

[hadoop@node1 ~]$ grep "dfs.namenode.http-address" $HADOOP_HOME/etc/hadoop/hdfs-site.xml

或者使用Hadoop命令直接查询，返回NameNode的HTTP地址和端口

1

[hadoop@node1 ~]$ hdfs getconf -confKey dfs.namenode.http-address

浏览器进入 node1:9870

但是UI页面中的权限无法创建文件，相当于匿名登录（dr.who登录，具有drwxr-xr-x），使用命令行是最高权限hadoop用户登录

如果需要在页面中具有操作权限，则在core.xml中配置网站的用户，并重启集群

1
2
3
4


 <property>
 <name>hadoop.http.staticuser.user</name>
 <value>hadoop</value>
 </property>

2.4 HDFS的权限

Linux系统中的超级用户是root，HDFS中的超级用户是启动namenode的用户(hadoop)

三、Windows连接HDFS

3.1 使用Data Grid中Big Data Tools插件连接HDFS

安装Data Grid，并配置相关环境：

下载java8，配置环境变量 JAVA_HOME=C:\Develop\Java\jdk1.8.0_202;
下载hadoop3.3.6，配置环境变量 HADOOP_HOME=C:\Users\Eleanora\softwares\hadoop-3.3.6;（路径中不能有空格）
配置环境变量Path中添加
1 2

%JAVA_HOME%\bin %HADOOP_HOME%\bin
Data Grid 安装Big Data Tools插件，但是由于在Windows平台部署HDFS时，还需解决两大核心问题：依赖库兼容性与运行环境适配。Windows系统缺少Linux的本地库支持（如libc.so），且路径格式、权限模型存在差异，因此需要额外引入Windows适配层。

典型依赖包括：
- Winutils.exe：替代Linux下的hadoop命令行工具，处理HDFS权限、路径转换等操作。
- Hadoop.dll：核心动态链接库，需与Java环境交互。
- 第三方库：如压缩库（snappy.dll、lz4.dll）、协议缓冲（protobuf.dll）等。
将 https://github.com/cdarlint/winutils 中hadoop3.3.6/bin的文件下载下来后，替换本地的文件（引入Windows适配层）
配置集群URL：192.168.88.101:8020 + user：hadoop 或者配置Hadoop文件夹：C:\Users\Eleanora\softwares\hadoop-3.3.6\etc\hadoop + user：hadoop

3.2 使用Widows连接HDFS(HDFS NFS Gateway) （可选，windows专业版）

3.2.1 NFS 定义

hdfs提供了基于NFS（Network File System）的插件，可以对外提供NFS网关，供其他系统挂载使用。支持上传、下载、删除、追加内容。说人话翻译一下：HDFS NFS网关就像一个“协议翻译器”，它让HDFS这个“大数据专用仓库”能伪装成一台普通的“网络硬盘”，从而被那些只认识传统文件协议的系统直接访问。HDFS为了降低使用门槛、方便与传统系统集成，提供了一个“协议适配器”服务。这个服务让HDFS能够“说”传统的NFS语言，从而允许任何支持NFS的系统像使用普通网络文件夹一样，直接挂载和访问HDFS海量数据，实现了“开箱即用”的集成。这是HDFS从“专用系统”走向“企业通用存储平台”的重要功能之一。

1、NFS是什么？

定义：网络文件系统，一种古老而通用的标准协议。它的核心功能是让一台计算机能像访问本地硬盘一样，通过网络访问另一台计算机上的文件和目录。
类比：就像在Windows上设置一个“网络驱动器（Z:盘）”，这个盘符实际上指向的是公司文件服务器。

2、HDFS的“原生语言”问题

HDFS有自己的一套API（Java API， REST API）和通信协议，专为大数据吞吐量设计。
传统的操作系统（如Linux、Windows）和应用程序（如Notepad++、FFmpeg、甚至cat， ls命令）天生不认识HDFS的协议。它们只认识像NFS、SMB（Windows共享）这样的标准文件协议。

3、NFS网关的作用 —— “协议翻译”

功能：HDFS NFS网关是一个独立的服务。它启动后，会“挂载”到HDFS的某个目录上，然后对外暴露一个标准的NFS协议接口。
过程：
- 外部系统：发出一个标准的NFS请求，比如“读取 /mnt/hdfs/data.txt文件”。
- NFS网关：接收到这个NFS请求，将其翻译成HDFS客户端能理解的RPC调用，向真正的HDFS集群请求数据。
- HDFS集群：处理请求，将数据返回给NFS网关。
- NFS网关：再将数据包装成标准的NFS格式，返回给外部系统。
结果：对于外部系统而言，它完全感知不到背后的HDFS，它只是觉得自己在访问一个有点慢的“网络硬盘”。

3.2.2 NFS使用场景

你可以直接在Linux终端里使用 cp， ls， cat， vim等所有熟悉的命令来操作HDFS里的文件，无需学习hdfs dfs命令
实现与现有应用的零代码集成：

任何能读写本地文件的程序，现在都能直接处理HDFS上的数据。比如，一个用Python写的日志分析脚本，或者一个视频转码工具，无需任何修改，只要把输入/输出路径指向挂载的HDFS目录即可。
方便数据迁移和交换：在HDFS和本地或其他NFS存储之间拷贝大量数据变得像拷贝文件一样简单直观。

3.2.3 NFS局限性

性能：由于多了一层协议转换和网络跳转，性能一定低于原生的HDFS客户端API。它适合做数据访问、管理和小文件操作，不适合做高性能计算中间数据的频繁交换。
功能完整性：并非所有HDFS的高级功能都能通过NFS完美映射（比如文件追加写入在早期版本支持不好）。
单点风险：NFS网关服务本身可能成为单点故障。通常需要做高可用配置。

3.2.4 配置 NFS

将 NFS 服务挂载到Windows后可以在Windows中以盘的形式去访问HDFS的文件。

NFS网关需要以一个“代理用户”的身份访问HDFS，因此需要在NameNode的 core-site.xml中添加配置。假设你启动NFS服务的Linux用户是 hadoop（也是启动HDFS集群的用户）。

步骤1：配置代理用户（核心）

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


<!-- 允许用户 'hadoop' 代理任何用户组（* 表示所有组） -->
<property>
 <name>hadoop.proxyuser.hadoop.groups</name>
 <value>*</value>
 <description>允许hadoop用户代理所有组的成员。通常需要包含'root'组。</description>
</property>

<!-- 允许从任何主机（*）发起的请求被代理 -->
<property>
 <name>hadoop.proxyuser.hadoop.hosts</name>
 <value>*</value>
 <description>运行NFS网关的主机。设为'*'允许来自任何主机的请求。</description>
</property>

步骤2：配置NFS网关参数

 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


<!-- 设置HDFS文件访问时间精度，可提升NFS性能 -->
<property>
 <name>dfs.namenode.accesstime.precision</name>
 <value>3600000</value>
 <description>HDFS文件访问时间精确到该值（毫秒），默认1小时。设为0则禁用。</description>
</property>

<!-- 设置NFS操作HDFS系统的超级用户 -->
<property>
 <name>nfs.superuser</name>
 <value>hadoop</value>
 <description>设置NFS操作HDFS系统的超级用户为hadoop</description>
</property>

<!-- NFS网关临时文件转储目录 -->
<property>
 <name>nfs.dump.dir</name>
 <value>/tmp/.hdfs-nfs</value>
 <description>NFS接收上传数据时使用的临时目录。确保该目录存在且有写权限。</description>
</property>

<!-- 允许挂载的客户端及权限 -->
<property>
 <name>nfs.exports.allowed.hosts</name>
 <value>192.168.88.1 rw</value>
 <description>允许客户端192.168.88.1以读写(rw)权限挂载。可指定IP如'* rw'表示所有。</description>
</property>

VMware提供了几种网络连接方式，其中 NAT（网络地址转换） 是最常用的。在这种模式下：

虚拟机获得一个私有IP地址（如 192.168.88.101）。
宿主机上创建一个虚拟网卡（VMnet8），并分配一个网关IP地址（如 192.168.88.1）。
虚拟机通过宿主机的这个虚拟网卡共享宿主机的物理网络连接上网，对外部网络来说，所有虚拟机的流量都“伪装”成了宿主机的IP。

电脑和VMware的通信是由VMware Network Adapter VMnet8连接的，其ip是192.168.88.1

每次登录的时候也可以看到。所以这里允许挂载的客户端及权限设置为192.168.88.1

1
2
3
4
5
6
7
8


[C:\~]$ 

Host 'node1' resolved to 192.168.88.101.
Connecting to 192.168.88.101:22...
Connection established.
To escape to local shell, press 'Ctrl+Alt+]'.

Last login: Sun Mar 29 11:15:55 2026 from 192.168.88.1

步骤3：分发配置并重启HDFS

将修改后的 core-site.xml和 hdfs-site.xml同步到集群所有节点（NameNode和DataNodes）。

1
2
3
4
5
6


[root@node1 hadoop]# scp core-site.xml hdfs-site.xml node2:`pwd`
core-site.xml 100% 1731 541.4KB/s 00:00 
hdfs-site.xml 100% 2424 1.8MB/s 00:00 
[root@node1 hadoop]# scp core-site.xml hdfs-site.xml node3:`pwd`
core-site.xml 100% 1731 1.6MB/s 00:00 
hdfs-site.xml 

重启HDFS集群以使配置生效：

1
2


stop-dfs.sh
start-dfs.sh

3.2.5 启动NFS网关服务

由于NFS协议标准端口是固定的：

111端口：rpcbind/portmap
2049端口：nfs-server/nfs3

如果同时运行系统NFS和Hadoop NFS，会发生端口冲突：

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


传统NFS架构： Hadoop NFS网关架构：
┌─────────────────┐ ┌─────────────────┐
│ NFS客户端 │ │ NFS客户端 │
│ (mount命令) │ │ (mount命令) │
└────────┬────────┘ └────────┬────────┘
 │ │
 ▼ ▼
┌─────────────────┐ ┌─────────────────┐
│ 系统rpcbind │ │ Hadoop portmap │
│ (端口111) │ │ (端口111) │
└────────┬────────┘ └────────┬────────┘
 │ │
 ▼ ▼
┌─────────────────┐ ┌─────────────────┐
│ 系统nfs-server │ │ Hadoop nfs3 │
│ (端口2049) │ │ (端口2049) │
└────────┬────────┘ └────────┬────────┘
 │ │
 ▼ ▼
┌─────────────────┐ ┌─────────────────┐
│ 本地文件系统 │ │ HDFS │
│ (ext4/xfs) │ │ (分布式存储) │
└─────────────────┘ └─────────────────┘

	传统NFS	Hadoop NFS
rpcbind / portmap - “电话总机” RPC（远程过程调用）端口映射服务监听在端口111（TCP/UDP），维护一个"服务名 → 端口号"的映射表，户端查询"nfs服务在哪个端口？"，rpcbind回答"在2049端口"	使用系统自带的`rpcbind`	使用Hadoop自带的`portmap`（功能相同，但专为Hadoop优化）
nfs-server / nfs3 - “文件服务前台实际的NFS文件服务监听在端口2049（TCP/UDP）处理客户端的文件操作请求（读、写、创建、删除等）实现NFSv3协议规范	`nfs-server`→ 访问本地磁盘文件系统	`nfs3`→ 访问HDFS分布式文件系统
存储后端	本地文件系统（ext4, xfs）	HDFS分布式文件系统
数据位置	单机磁盘	多节点分布式存储
元数据管理	本地inode	NameNode管理
数据块管理	本地块设备	DataNode管理

NFS协议 - “沟通语言”

无状态协议（简化了错误恢复）
支持大文件（64位文件大小）
异步写入（提高性能）支持TCP传输（更可靠）

传统NFS

Hadoop NFS

1. 客户端执行：mount -t nfs server:/share /mnt
2. 客户端查询server:111（rpcbind）→ “mountd在哪个端口？"
3. rpcbind回复：mountd在端口4242
4. 客户端连接server:4242（mountd）→ 请求挂载/share
5. mountd验证权限，返回文件句柄
6. 客户端查询server:111（rpcbind）→ “nfs在哪个端口？"
7. rpcbind回复：nfs在端口2049
8. 客户端连接server:2049（nfs-server）进行文件操作

1. 客户端执行：mount -t nfs hadoop-gateway:/hdfs /mnt
2. 客户端查询hadoop-gateway:111（Hadoop portmap）→ “mountd在哪个端口？"
3. Hadoop portmap回复：mountd在端口4242
4. 客户端连接hadoop-gateway:4242（Hadoop mountd）→ 请求挂载/hdfs
5. Hadoop mountd验证权限，返回HDFS文件句柄
6. 客户端查询hadoop-gateway:111（Hadoop portmap）→ “nfs在哪个端口？"
7. Hadoop portmap回复：nfs在端口2049
8. 客户端连接hadoop-gateway:2049（Hadoop nfs3）进行文件操作
9. Hadoop nfs3将NFS操作转换为HDFS API调用

为什么Hadoop要自己实现？

架构差异

步骤1：停止系统自带的NFS服务（避免端口冲突）

使用root用户在计划运行NFS网关的机器上执行，关掉系统自带的NFS，卸载rpcbind，替换为hadoop中的NFS和portmap

1
2
3
4
5


systemctl stop nfs
systemctl disable nfs
# 或者使用
sudo systemctl stop nfs
sudo systemctl disable nfs # 或 nfs，取决于发行版

卸载系统自带的rpcbind

1

yum remove -y rpcbind

启动portmap(HDFS自带的rpcbind，root用户执行)

1

hdfs --daemon start portmap

启动nfs3服务（hadoop用户执行）

1

hdfs --daemon start nfs3

3.2.6 验证NFS网关服务

切换到node2：检查RPC服务是否注册成功，应看到portmapper（100000）、mountd（100005）、nfs（100003）服务

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


[root@node2 ~]# rpcinfo -p node1
 program vers proto port service
 100005 3 udp 4242 mountd
 100005 1 tcp 4242 mountd
 100000 2 udp 111 portmapper
 100000 2 tcp 111 portmapper
 100005 3 tcp 4242 mountd
 100005 2 tcp 4242 mountd
 100003 3 tcp 2049 nfs
 100005 2 udp 4242 mountd
 100005 1 udp 4242 mountd

允许192.168.88.1连接到node1

1
2
3


[root@node2 ~]# showmount -e node1
Export list for node1:
/ 192.168.88.1

3.2.7 Windows挂载HDFS文件系统

这里以你的Windows宿主机（IP: 192.168.88.1） 挂载到Linux虚拟机（IP: 192.168.88.101，运行NFS网关） 为例。

步骤1：在Windows上启用NFS客户端功能

打开“控制面板” → “程序” → “启用或关闭Windows功能”。
勾选 “NFS客户端” 和 “用于NFS的Telnet客户端”（可选），点击确定并重启。

步骤2：在Windows命令提示符（管理员）中挂载

1

net use X: \\192.168.88.101\!

1
2
3


# 语法：mount -o 选项 NFS服务器IP:导出路径 本地盘符
# 注意：Windows NFS客户端默认使用NFSv3，但参数语法与Linux不同
mount -o anon \\192.168.88.101\ /hdfs Z:

参数解释：

\192.168.88.101`：NFS网关服务器的IP，后面跟的是HDFS的导出路径（根目录/）。在Windows中，路径用反斜杠和共享名表示。
Z:：希望映射的本地驱动器号。
-o anon：以匿名身份挂载。因为我们在core-site.xml中配置了代理用户hadoop，NFS网关会以该用户身份执行操作。

步骤3：验证挂载

打开计算机，可以看到 NFS服务器以磁盘的形式显示

四、HDFS的存储原理

文件在存储到HDFS的集群前会被拆分为Block块，HDFS的最小储存单位(每个256M,可改)。并通过副本冗余防止数据丢失

4.1 fsck命令 File System Check

4.1.1 配置HDFS数据块的副本数量

功能	位置	代码
修改副本数	每个集群中`hdfs-site.xml`中配置	dfs.replication 3
上传文件时临时决定副本数量	上传命令的中间添加`-D dfs.replication=2`	`hdfs dfs -D dfs.replication=2 -put test.txt /tmp/`
已存在的HDFS文件，修改副本数量	指定path的内容会被修改为2个副本存储	`hdfs dfs -setrep [-R] 2 path` -R表示对子目录的文件同样生效

4.1.2 fsck命令查看文件副本数

1

hdfs fsck 文件路径 [-files [-blocks [-locations]]]

-files 列出路径内的文件状态

-files -blocks 输出文件块报告（有几个块，多少副本）

-files -blocks -location 输出每个block的详情

举例，查看某文件的状态+blocks+blocks详情：

1

[hadoop@node1 ~]$ hdfs fsck new.txt -files -blocks -locations

输出

 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


Connecting to namenode via http://node1:9870/fsck?ugi=hadoop&files=1&blocks=1&locations=1&path=%2Fuser%2Fhadoop%2Fnew.txt
FSCK started by hadoop (auth:SIMPLE) from /192.168.88.101 for path /user/hadoop/new.txt at Mon Mar 30 21:19:48 CST 2026

/user/hadoop/new.txt 42 bytes, replicated: replication=3, 1 block(s): OK
0. BP-397460804-192.168.88.101-1774236967721:blk_1073741826_1003 len=42 Live_repl=3 [DatanodeInfoWithStorage[192.168.88.103:9866,DS-1045212b-874e-4331-84bf-4fcff0a31ddc,DISK], DatanodeInfoWithStorage[192.168.88.102:9866,DS-fdb19663-a199-4777-986a-75a2e43d1231,DISK], DatanodeInfoWithStorage[192.168.88.101:9866,DS-37aaf5d8-3886-47ac-bd88-998ae2deef58,DISK]]


Status: HEALTHY
 Number of data-nodes: 3
 Number of racks: 1
 Total dirs: 0
 Total symlinks: 0

Replicated Blocks:
 Total size: 42 B
 Total files: 1
 Total blocks (validated): 1 (avg. block size 42 B)
 Minimally replicated blocks: 1 (100.0 %)
 Over-replicated blocks: 0 (0.0 %)
 Under-replicated blocks: 0 (0.0 %)
 Mis-replicated blocks: 0 (0.0 %)
 Default replication factor: 3
 Average block replication: 3.0
 Missing blocks: 0
 Corrupt blocks: 0
 Missing replicas: 0 (0.0 %)
 Blocks queued for replication: 0

Erasure Coded Block Groups:
 Total size: 0 B
 Total files: 0
 Total block groups (validated): 0
 Minimally erasure-coded block groups: 0
 Over-erasure-coded block groups: 0
 Under-erasure-coded block groups: 0
 Unsatisfactory placement block groups: 0
 Average block group size: 0.0
 Missing block groups: 0
 Corrupt block groups: 0
 Missing internal blocks: 0
 Blocks queued for replication: 0
FSCK ended at Mon Mar 30 21:19:48 CST 2026 in 3 milliseconds


The filesystem under path '/user/hadoop/new.txt' is HEALTHY

验证了文件有多个副本、文件被分成多个块存储，每个块256M

默认每个块256M，但也可以在hdfs-site.xml中配置

1
2
3
4
5


<property>
 <name>dfs.blocksize</name>
 <value>268435456</value>
 <descriptino>设置HDFS块大小，单位b</descriptino>
</property>

4.2 NameNode元数据

hdfs中文件很多，每个文件又被分为了很多个块，当想要查询一个文件时应该找？ NameNode基于edits**（NameNode记录）**和FSImage的配合，完成整个文件系统的管理

每次对HDFS的操作，均被edits文件记录。NameNode 会定期（默认1小时）或当 edits 文件达到一定大小（默认64MB）时，触发 SecondaryNameNode执行 检查点操作。
该操作会将上一个检查点之后的 edits 日志与上一个检查点的 FSImage 合并，生成一个全新的、更完整的 FSImage
这个新生成的 FSImage 会被保存到磁盘，它并不会覆盖旧的 FSImage，而是作为一个新的版本存在

“最终状态”的载体：最新的“文件系统最终状态”实际上是由“最新的那个 FSImage + 它之后的所有 edits 日志”共同定义的。 NameNode 启动时，正是将这两者结合，在内存中生成唯一的最新元数据镜像。

其中hdfs的数据目录current路径记录在

1

vim /export/server/hadoop/etc/hadoop/hdfs-site.xml

的

1
2
3
4


<property>
 <name>dfs.namenode.name.dir</name>
 <value>/data/nn</value>
 </property>

进入数据目录current路径后，即可看到edits和FSImage

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


[root@node1 nn]# cd /data/nn/current
[root@node1 current]# ls -nl
total 5244
# 省略 。。。。
-rw-rw-r-- 1 1001 1001 664 Mar 30 21:47 edits_0000000000000000114-0000000000000000123
-rw-rw-r-- 1 1001 1001 1048576 Mar 30 21:47 edits_inprogress_0000000000000000124
-rw-rw-r-- 1 1001 1001 690 Mar 30 08:12 fsimage_0000000000000000113
-rw-rw-r-- 1 1001 1001 62 Mar 30 08:12 fsimage_0000000000000000113.md5
-rw-rw-r-- 1 1001 1001 760 Mar 30 21:47 fsimage_0000000000000000123
-rw-rw-r-- 1 1001 1001 62 Mar 30 21:47 fsimage_0000000000000000123.md5
-rw-rw-r-- 1 1001 1001 4 Mar 30 21:47 seen_txid
-rw-rw-r-- 1 1001 1001 217 Mar 27 21:00 VERSION

4.3 SecondaryNamenode 负责元数据合并

元数据的合并通过检查时间，条件符合来控制

检查是否达到条件：dfs.namenode.checkpoint.check.period 默认60s
以下任意一个条件满足则发生
- dfs.namenode.checkpoint.period，默认3600s(1h)
- dfs.namenode.checkpoint.txns，默认100w次事务

4.4 HDFS数据读写流

无论读写，namenode都不经手数据，均由客户端和datanode直接通讯，否则namenode压力太大。

网络距离：

同一台机器->同一个局域网（交换机）->跨越交换机->跨越交数据中心

HDFS内置网络距离算法，通过IP地址和路由表来推断网络距离

六、Linux 文件与目录管理

Tue, 02 Apr 2024 11:00:00 +0800

6.1 目录与路径

6.1.2 目录的相关操作

命令	含义	用法	参数
cd	Change Directory 变换目录	`cd ~user2` 进入使用者的主文件夹 `cd ~` 或`cd` 回到自己的主文件夹 `cd -` 回到刚刚的目录 `cd ../postfix` 进入某目录
pwd	Print Working Directory 显示目前的目录	`pwd -P`显示目前的目录	-P ：显示出确实的路径，而非使用链接（link）路径
mkdir	make directory 创建一个新的目录	`mkdir -p test1/test2/test3`创建多层目录 `mkdir -m 711 test2` 创建权限为rwx–x–x的目录	-m ：设置文件的权限，不需要看默认权限。最终权限 = 777 - umask，默认用户环境中umask = 022 -p ：将所需要的目录（包含上层目录）递回创建起来
rmdir	remove directory 删除一个空的目录	`rmdir -p test1/test2/test3/test4`删除多层空目录	-p ：连同“上层”“空的”目录也一起删除

6.1.3 可执行文件路径的变量：$PATH

当我们在执行一个指令时，系统会依照PATH的设置去每个PATH定义的目录下搜寻文件名为ls的可执行文件，如果在PATH定义的目录中含有多个文件名为ls的可可执行文件，那么先搜寻到的同名指令先被执行！

1
2


user2@DESKTOP-I0DQE4R:~$ echo $PATH
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin

PATH变量的内容是由一堆目录所组成的，每个目录中间用冒号（:）来隔开。所以可以在任何地方执行ls来找到/bin/ls可执行文件

如果PATH中没有定义某个指令所在目录，那么要用/root/ls指定命令的地址才能调用

不同身份使用者默认的PATH不同，默认能够随意执行的指令也不同（如root与dmtsai）；
PATH是可以修改的；
使用绝对路径或相对路径直接指定某个指令的文件名来执行，会比搜寻PATH来的正确；
指令应该要放置到正确的目录下，执行才会比较方便；
本目录（.）最好不要放到PATH当中

6.2 文件与目录管理

6.2.1 文件与目录的检视： ls

很多distribution 在默认的情况中，已经将 ll （L 的小写）设置成为 ls -l 的意思（这个功能是 Bash shell 的 alias 功能）

参数	含义
-a（all）	全部的文件，连同隐藏文件（开头为 . 的文件）一起列出来（常用）
-d（directory）	仅列出目录本身，而不是列出目录内的文件数据（常用）
-l（long format）	长数据串行出，包含文件的属性与权限等等数据；（常用）
-f（fast / no sort）	直接列出结果，而不进行排序（ls 默认会以文件名排序！）
-F（file type indicator）历史语义	根据文件、目录等信息，给予附加数据结构 `*`代表可可执行文件 `/`代表目录； `=`:代表 socket 文件 `\|`代表 FIFO文件
-h （human-readable）	将文件大小以人类较易读的方式（例如 GB, KB 等等）列出来
-i	列出 inode 号码
-A（almost all）	全部的文件，连同隐藏文件，但不包括 . 与 .. 这两个目录
-n	列出 UID 与 GID 而非使用者与群组的名称
-r（reverse）	将排序结果反向输出，例如：原本文件名由小到大，反向则为由大到小；
-R（Recursive）大写 R 是历史约定	连同子目录内容一起列出来，等于该目录下的所有文件都会显示出来
-S（size）	以文件大小大小排序，而不是用文件名排序
-t（time）	依时间排序，而不是用文件名
–color	=never：不要依据文件特性给予颜色显示 =always ：显示颜色 =auto ：让系统自行依据设置来判断是否给予颜色
–full-time	以完整时间模式（包含年、月、日、时、分）输出
–time={atime,ctime}	输出 access 时间或改变权限属性时间 (ctime)而非内容变更时间(modification time)

6.2.2 复制、删除与移动： cp, rm, mv

cp 复制文件或目录

参数	参数含义
-a（archive）	= -dr –preserve=all 的意思归档模式：递归复制、保留所有属性、保留符号链接 -a = -dR –preserve=all
-i（interactive）	若目标文件（destination）已经存在时，在覆盖时会先询问动作的进行（常用）
-p（preserve）	连同文件的属性（权限、用户、时间）一起复制过去，而非使用默认属性（-p 是 –preserve 的子集）
-r（recursive）	递回持续复制，用于目录的复制行为；（常用）
-d（no dereference）	若来源文件为链接文件的属性（link file），则复制链接文件属性而非文件本身
-f（force）	为强制（force）的意思，若目标文件已经存在且无法打开，则移除后再尝试一次
-l（link）	进行硬式链接（hard link）的链接文件创建，而非复制文件本身，指向同一个 inode
-s（symbolic link）	复制成为符号链接文件，亦即“捷径”文件（很小），指向文件路径字符串
-u（update）	destination 比 source 旧才更新 destination，或 destination 不存在的情况下才复制
–preserve=all	除了 -p 的权限相关参数外，还加入 SELinux 的属性, links,xattr 等也复制了

目的文件的拥有者通常会是指令操作者本身，由于具有这个特性，进行备份的时需要特别注意的特殊权限文件，例如密码档（/etc/shadow）以及一些配置文件，就不能直接以 cp 来复制，而必须要加上 -a 或者是 -p 等等可以完整复制文件权限的选项才行

-s vs -l

cp -s 创建的是"软链接"，也就是我们常说的"快捷方式"

1

lrwxrwxrwx 1 root root 6 Jul 18 22:31 bashrc_slink -> bashrc

cp -l 创建的是"硬链接"，指向同一个 inode，第二栏的数字（link count）从1变成了2，本质上和原文件是同一个文件，只是有两个文件名指向它。当删除其中一个时不影响另外一个，修改任意一个另一个立刻变化（看不出“谁是原文件”）。

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


fileA fileB fileA fileB
 | | | |
 v v v v
+----------------+ +--------+ +--------------+
| inode 12345 | ← 同一个 inode（链接计数=2） | inode | | inode 67890 |
+----------------+ +--------+ +--------------+
 | | |
 v v v
+----------------+ +----------------+ "fileA" ← 路径字符串
| data blocks | | data blocks |
| "Hello World" | | "Hello World" |
+----------------+ +----------------+

当你创建一个文件时，它有一个链接计数（通常是1）每创建一个硬链接，链接计数就加1，反之减一。链接计数变成0时，系统才会真正删除文件内容

1

-rw-r--r-- 2 root root 395 Jul 18 22:08 bashrc_hlink

将多个文件复制到目录下

1

cp ~/.bashrc ~/.bash_history /tmp

维度	`cp -l`（硬链接）	`cp -s`（软链接）
inode	✅ 相同	❌ 不同
指向方式	数据本身	文件路径
跨文件系统	❌ 不行	✅ 可以
链接目录	❌ 不行	✅ 可以
原文件删除	✅ 仍可用	❌ 失效
修改影响	✅ 双向同步	✅ 通过路径访问
常见用途	快照、节省空间	目录映射、别名

由于 cp 有种种的文件属性与权限的特性，所以，在复制时，你必须要清楚的了解到： • 是否需要完整的保留来源文件的信息？ • 来源文件是否为链接文件（symbolic link file）？ • 来源文件是否为特殊的文件，例如 FIFO, socket 等？ • 来源文件是否为目录？

rm 移除文件或目录

1

rm [-fir] 文件或目录

参数	含义	举例
-f	就是 force 的意思，忽略不存在的文件，不会出现警告讯息
-i	互动模式，在删除前会询问使用者是否动作	`rm -i bashrc*`
-r	递回删除啊！最常用在目录的删除了！这是非常危险的选项！！！	`rm -r /tmp/etc`

身份是 root ，默认已经加入了 -i 的选项，所以你要一直按 y 才会删除

mv 移动文件与目录，或更名

参数	含义
-f	就是 force 的意思，如果目标文件已经存在，不会询问而直接覆盖
-i	若目标文件（destination）已经存在时，就会询问是否覆盖
-r	目标文件已经存在，且 source 比较新，才会更新（update）

文件改名（还有个指令叫rename）

1

mv mvtest mvtest2

移动多个来源文件或目录，则最后一个目标文件一定是“目录！”

1

 mv bashrc1 bashrc2 mvtest2

6.2.3 取得路径的文件名称与目录名称

每个文件的完整文件名包含了前面的目录与最终的文件名，而每个文件名的长度都可以到达 255 个字符

basename获取文件名

1
2


user2@DESKTOP-I0DQE4R:~$ basename /tmp/testing/testfile
testfile 

basedir获取目录名

1
2


user2@DESKTOP-I0DQE4R:~$ dirname /tmp/testing/testfile
/tmp/testing

详见第三篇内的 shell scripts

6.3 文件文件内容查阅

指令	用途
cat	由第一行开始显示文件内容
tac	从最后一行开始显示，可以看出 tac 是 cat 的倒着写！
nl	显示的时候，顺道输出行号
more	一页一页的显示文件内容
less	与 more 类似，但是比 more 更好的是，他可以往前翻页
head	只看头几行
tail	只看尾巴几行
od	以二进制的方式读取文件内容

6.3.1 直接检视文件内容

使用 cat/tac/nl

命令	参数	范例
cat/tac concatenate 将一个文件的内容连续的印出在屏幕上 /由最后一行到第一行反向打印在屏幕上	-A ：相当于 -vET 的整合选项，可列出一些特殊字符而不是空白而已；	`cat -A /etc/man_db.conf`
	-b ：列出行号，仅针对非空白行做行号显示，空白行不标行号！
	-E ：将结尾的断行字符 $ 显示出来；
	-n ：打印出行号，连同空白行也会有行号，与 -b 的选项不同；	`cat -n /etc/issue`
	-T ：将 [tab] 按键以 ^I 显示出来；
	-v ：列出一些看不出来的特殊字符
nl 添加行号，打印可以将行号做比较多的显示设计	-b ：指定行号指定的方式，主要有两种： -b a ：表示不论是否为空行，也同样列出行号（类似 cat -n） -b t ：如果有空行，空的那一行不要列出行号（默认值）；	`nl -b a /etc/issue`
```	-n ：列出行号表示的方法，主要有三种： -n ln ：行号在屏幕的最左方显示； rz-n rn ：行号在自己字段的最右方显示，且不加 0 ； -n rz ：行号在自己字段的最右方显示，且加 0 ；	`nl -n rz /etc/issue`
	-w ：行号字段的占用的字符数。和-n一起用才能看出来效果	`nl -n rz -w 3 /etc/issue`

nl加上-b a的效果

1
2
3
4
5
6


root@DESKTOP-I0DQE4R:~ nl /etc/issue
 1 Ubuntu 24.04.1 LTS \n \l

root@DESKTOP-I0DQE4R:~# nl -b a /etc/issue
 1 Ubuntu 24.04.1 LTS \n \l
 2

-n rz -w 2的效果

1
2
3


root@DESKTOP-I0DQE4R:~# nl -b a -n rz -w 2 /etc/issue
01 Ubuntu 24.04.1 LTS \n \l
02

6.3.2 可翻页检视

使用 more 与 less

如果 more 后面接的文件内容行数大于屏幕输出的行数时，最后一行会显示出目前显示的百分比，在最后一行输入一些有用的指令

参数	含义
空白键（space）	代表向下翻一页
Enter	代表向下翻“一行”
/字串	代表在这个显示的内容当中，向下搜寻“字串”这个关键字
:f	立刻显示出文件名以及目前显示的行数
q	代表立刻离开 more ，不再显示该文件内容
b 或 [ctrl]-b	代表往回翻页，不过这动作只对文件有用，对管线无用

less可以使用 [pageup] [pagedown] 等按键的功能来往前往后翻看文件

参数	含义
空白键（space）	代表向下翻一页
pagedown/pageup	向下/上翻动一页
/字串 ?字串	向下/上搜寻“字串”的功能
n/N	反向的重复前一个搜寻（与 / 或 ? 有关！）
g/G	前进到这个数据的第一行/最后一行
q	离开 less 这个程序

6.3.3 数据提取

取出文件前面几行（head）或取出后面几行（tail）文字的功能。head 与 tail 都是以“行”为单位

1

head [-n number] 文件 （默认的情况中，显示前面十行）

如果接的是负数，例如上面范例的-n -100时，代表列出所有行数，但不包括后面100行

1

tail [-n number] 文件 （默认的情况中，显示最后十行）

有数据写入时就立刻显示到屏幕上，就利用 -f 这个选项，一直侦测文件，新加入的数据都会被显示到屏幕上（摁下Ctrl c会离开tail的侦测）

显示 /etc/man_db.conf 的第 11 到第 20 行，并添加行号

1

cat -n /etc/man_db.conf | head -n 20 | tail -n 10

管线的意思是：“前面的指令所输出的讯息，请通过管线交由后续的指令继续使用”

6.3.4 非纯文本文件：od

Octal Dump

事实上，由于可执行文件通常是 binary file，使用上头提到的指令来读取他的内容时，会产生类似乱码的数据，可以利用 od 这个指令来读取

1

od [-t TYPE] 文件

TYPE	含义
a	利用默认的字符来输出
c	使用 ASCII 字符来输出
d[size]	利用十进制（decimal）来输出数据，每个整数占用 size Bytes
f[size]	利用浮点数值（floating）来输出数据，每个数占用 size Bytes
o[size]	利用八进位（octal）来输出数据，每个整数占用 size Bytes
x[size]	利用十六进制（hexadecimal）来输出数据，每个整数占用 size

6.3.5 修改文件时间或创建新文件： touch

touch 这个指令最常被使用的情况

创建一个空的文件
将某个文件日期修订为目前（mtime 与 atime）

每个文件在linux下面都会记录三个时间参数

modification time （mtime）文件的内容变更（默认显示）
status time （ctime）文件的状态变更，如权限与属性
access time （atime）文件的内容被取用时，如用 cat 读

1
2
3
4


root@DESKTOP-I0DQE4R:/etc# ls -l /etc/ucf.conf ; ls -l --time=atime /etc/ucf.conf ; ls -l --time=ctime /etc/ucf.conf
-rw-r--r-- 1 root root 1260 Jan 27 2023 /etc/ucf.conf
-rw-r--r-- 1 root root 1260 Jan 7 2025 /etc/ucf.conf
-rw-r--r-- 1 root root 1260 Sep 4 17:50 /etc/ucf.conf

某些情况下，由于BIOS的设置错误，导致系统时间跑到未来时间并且你又创建了某些文件。等你将时间改回正确的时间时，该文件不就变成来自未来

1

touch [-acdmt] 文件

参数	含义	示例
-a	仅修订 access time
-c	仅修改文件的时间，若该文件不存在则不创建新文件	如果文件不存在，命令不会创建新文件 `touch -c non_existing_file`
-m	仅修改 mtime
-d	后面可以接欲修订的日期而不用目前的日期，也可以使用 –date=“日期或时间”	`touch -m -d "2024-10-01" file.txt` `touch -d "yesterday" file.txt`
-t	后面可以接欲修订的时间而不用目前的时间，格式为[YYYYMMDDhhmm]	`touch -t 202405201430.25 file.txt`

如果 touch 后面有接文件则该文件的三个时间（atime/ctime/mtime）都会更新为目前的时间.若该文件不存在则会主动的创建一个新的空的文件

使用cp命令时数据的内容与属性是被复制过来的，因此文件内容时间（mtime）与原本文件相同，状态（ctime）就变成现在的时间

权限例题：

系统有个一般身份使用者userA，他的群组属于GroupA，他的主文件夹在 /home/userA。你是root，你想将你的 ~/.bashrc 复制给他，可以怎么做？

root 虽然可以将这个文件复制给 userA，不过这个文件在 userA的主文件夹中却可能让 userA没有办法读写（因为该文件属于 root 的嘛！而 userA又不能使用 chown 之故）此外，我们又担心覆盖掉 userA自己的 .bashrc 配置文件，因此，我们可以复制文件：

1

cp ~/.bashrc ~dmtsai/.bashrc

修改属性：

1

chown dmtsai:dmtsai ~dmtsai/.bashrc

6.4 文件与目录的默认权限与隐藏权限

一个文件有若干个属性，包括读写执行（r, w, x）等基本权限，及是否为目录（d）与文件（-）或者是链接文件（l）等等的属性。修改属性的方法在前面也约略提过了（chgrp, chown, chmod）

除了基本r, w, x权限外我们还可以设置其他的系统隐藏属性(只能增加/不能删除等)，这部份可使用chattr来设置，lsattr查看

6.4.1 文件默认权限：umask

创建一个新的文件或目录时，他的默认权限与 umask 有关。 umask 就是指定 “目前使用者在创建文件或目录时候的权限默认值”

查阅的方式有两种：

1
2
3
4
5


root@DESKTOP-I0DQE4R:~# umask -S
u=rwx,g=rx,o=rx

root@DESKTOP-I0DQE4R:~# umask
0022

在默认权限的属性上，目录与文件是不一样的。 x 权限对于目录是非常重要的！但是一般文件的创建则不应该有执行的权限。因此，默认的情况如下：

	文件	目录
初始默认	没有可执行（ x ）权限，亦即只有 rw 这两个项目	x 与是否可以进入此目录有关，因此默认为所有权限均开放
最大分数	666	777
默认权限	-rw-rw-rw-	drwxrwxrwx
当umask=002	（-rw-rw-rw-） - （—–w–w-） ==> -rw-r–r–	（drwxrwxrwx） - （d—-w–w-） ==> drwxr-xr-x

umask 的分数指的是“该默认值需要减掉的权限，r、w、x 分别是 4、2、1 分。final_permission = default_permission - umask

应用场景：

当我们需要新建文件给同群组的使用者共同编辑时（需要r w权限），那么需要给others拿掉w权限即2，所以设置 umask = 002。得到文件的权限为rw-rw-r–，目录权限为rwxrwxr-x

1
2
3
4
5
6


root@DESKTOP-I0DQE4R:~# umask 002
root@DESKTOP-I0DQE4R:~# mkdir TestDir002
root@DESKTOP-I0DQE4R:~# touch testfile002
root@DESKTOP-I0DQE4R:~# ll -d test*
# drwxrwxr-x 2 root root 4096 Mar 27 16:48 testDir002/
# -rw-rw-r-- 1 root root 0 Mar 27 16:48 testfile002

相比普通用户，root 更“保守”，不给 group/others 写权限（因为 root 创建的东西很可能属于系统关键文件）所以root 的 umask 默认是 022 ；普通用户umask 为 002 。

6.4.2 文件隐藏属性

chattr指令只能在Ext2/Ext3/Ext4的 Linux 传统文件系统上面完整生效，为文件提供了真正的保护，可以防止意外删除或篡改。设置的属性是隐藏的性质，所以需要以 lsattr 才能看到该属性

File Sys Introduction

文件系统 Extended File System	Ext2	Ext3	Ext4
年代	比较老	改进版	现代版
特点	无日志：突然断电/系统崩溃，文件系统就可能损坏。系统重启后要全盘扫描	有日志Ext3 = Ext2 + Journal（日记功能）系统重启后查看日志，按日志恢复操作	更快更安全 ✅ 支持更大文件 ✅ 支持更大磁盘 ✅ 延迟分配（delayed allocation） ✅ extent（区块连续存储） ✅ journal 优化 ✅ fsck 更快 ✅ I/O 性能更高
存储方式		1GB 文件拆成上万个离散 block 寻址效率低	extent（区段）从 block1000 连续存 2000 个 block用一条记录就行

使用场景

场景	常用 FS	全称	支持
Linux 默认	Ext4	Extended File System
大数据（Hadoop）	Ext4 / XFS	Extended File System
云服务器	Ext4	Extended File System
Docker 存储	overlay2 + Ext4/XFS	Extended File System
Windows	NTFS	New Technology File System	文件权限控制（ACL）、文件压缩、文件加密、最大 16EB 分区、单个文件可大于4GB、日志（Journal）、恢复能力强但不能跨平台
macOS	APFS	Apple File System	专门为 SSD、闪存设备优化设计。写时复制Copy-On-Write（新数据写好再替换就指针）、Snapshot、原生加密、空间共享Space Sharing（多个分区可以共享同一块存储空间）。 Unix 权限兼容的文件系统（本质是 Unix 系统）
U盘	FAT32	File Allocation Table 32	非常古老，兼容性极强它可以被： Windows、macOS、Linux、电视、相机、车载系统、游戏机全部识别但FAT32 单最大=4GB，超过会失败
	exFAT	Extended FAT	取消了单文件4GB限制

NTFS、FAT32、exFAT可以执行chmod 777 file但权限不会真的生效（因为磁盘底层不支持 inode 权限位，没有 Linux rwx 权限模型）权限位（rwx）、inode、ACL、sticky bit、SUID / SGID都是Linux系统提出的

chattr （设置文件隐藏属性）

参数	含义
+	增加某一个特殊参数，其他原本存在参数则不动
-	移除某一个特殊参数，其他原本存在参数则不动
=	设置一定，且仅有后面接的参数
A	当设置了 A 这个属性时，若你有存取此文件（或目录）时，他的存取时间 atime 将不会被修改可避免 I/O 较慢的机器过度的存取磁盘。（目前建议使用文件系统挂载参数处理这个项目）
S	一般文件是非同步写入磁盘的，如果加上 S 这个属性时，
当你进行任何文件的修改，该更动会“同步”写入磁盘中。
a	当设置 a 之后，这个文件将只能增加数据，而不能删除也不能修改数据，只有root 才能设置这属性
c	这个属性设置之后，将会自动的将此文件“压缩”，在读取的时候将会自动解压缩，但是在储存的时候，将会先进行压缩后再储存（看来对于大文件似乎蛮有用的！）
d	当 dump 程序被执行的时候，设置 d 属性将可使该文件（或目录）不会被 dump 备份
i	他可以让一个文件“不能被删除、改名、设置链接也无法写入或新增数据！”
对于系统安全性有相当大的助益！只有 root 能设置此属性
s	当文件设置了 s 属性时，如果这个文件被删除，他将会被完全的移除出这个硬盘空间，
所以如果误删了，完全无法救回来了喔！
u	与 s 相反的，当使用 u 来设置文件时，如果该文件被删除了，则数据内容其实还存在磁盘中，可以使用来救援该文件喔！

设置了+i属性的文件，即便是root用户也无法删除。 +i 与 +a 常用于在系统的数据安全，log file 这种的登录文件，就更需要 +a 参数，这样文件只能增加，但是不能修改旧有的数据与删除的参数

1
2
3
4


root@DESKTOP-I0DQE4R:/tmp# touch attrtest
root@DESKTOP-I0DQE4R:/tmp# chattr +i attrtest
root@DESKTOP-I0DQE4R:/tmp# rm attrtest
rm: cannot remove 'attrtest': Operation not permitted

lsattr （显示文件隐藏属性）

参数	含义
-a	将隐藏文件的属性也秀出来
-d	如果接的是目录，仅列出目录本身的属性而非目录内的文件名
-R	连同子目录的数据也一并列出来

1
2
3


root@DESKTOP-I0DQE4R:/tmp# chattr +aiS attrtest
root@DESKTOP-I0DQE4R:/tmp# lsattr attrtest
--S-ia--------e------- attrtest

使用 chattr 设置后，可以利用 lsattr 来查阅隐藏的属性。如果将 /etc/shadow 这个重要的密码记录文件给他设置成为具有 i 的属性，那么过了若干天之后，你突然要新增使用者，却一直无法新增。

6.4.3 文件特殊权限： SUID, SGID, SBIT

查看 /tmp 和 /usr/bin/passwd 的权限，发现还有其他的特殊权限（ x位置变成了s和 t ）

✅ s / t = 特殊权限存在 + x 存在（有效） ✅ S / T= 特殊权限存在 + x 不存在（无效，占位显示）

	出现位置	含义	示例	数字设置	符号设置
SUID	在文件owner的 x	Set UID	x->s: rwsr-xr-x	chmod u=rwxs,go=x test; ls -l test	chmod u=rwxs,go=x test; ls -l test
SGID	在文件group的 x	Set GID	x->s: -rwxr-sr-x
SBIT	在文件others的 x	Set Sticky Bit	x->t: -rwxr-xr-t

1
2
3


root@DESKTOP-I0DQE4R:/tmp# ls -ld /tmp; ls -l /usr/bin/passwd
drwxrwxrwt 9 root root 4096 Dec 4 09:53 /tmp
-rwsr-xr-x 1 root root 64152 May 30 2024 /usr/bin/passwd

SUID

当 s 这个标志出现在文件owner的 x 权限上时，如-rwsr-xr-x此时就被称为 Set UID，简称为SUID 的特殊权限，SUID有这样的限制与功能： • SUID 权限仅对二进制程序（binary program）有效； • 执行者对于该程序需要具有 x 的可执行权限； • 本权限仅在执行该程序的过程中有效（run-time）； • 执行者将具有该程序拥有者（owner）的权限

举个例子： Linux 系统中，所有帐号的密码都记录在 /etc/shadow中，权限为 ---------- 1 root root仅有root可读且仅有root可以强制写入，但是一般帐号使用者修改自己的密码

答：——关键不在于直接去碰那个被锁得死死的 /etc/shadow文件，而在于一个被赋予了特殊“权力”的桥梁——/usr/bin/passwd命令，命令的权限为-rwsr-xr-x任何用户在执行这个程序时，进程的有效用户ID（euid） 会暂时变更为该程序文件的所有者（通常是 root）的 ID，而不是当前执行它的用户的 ID。

userA 对于 /usr/bin/passwd 这个程序来说是具有 x 权限的，表示userA能执行 passwd；
passwd 的拥有者是 root 这个帐号；
userA 执行 passwd 的过程中，会“暂时”获得 root 的权限；
/etc/shadow 就可以被 userA 所执行的 passwd 所修改。

SUID 仅可用在binary program 上，不能够用在 shell script (调用binary的程序)

SGID

当 s 标志在文件拥有者的 x 项目为 SUID，那 s 在群组的 x 时则称为 Set GID（如：-rwx–s–x），简称为SGID 的特殊权限。与 SUID 不同的是，SGID 可以针对文件或目录来设置SGID

文件	目录
SGID 对二进制程序有用	使用者若对于此目录具有 r 与 x 的权限时，该使用者能够进入此目录
程序执行者对于该程序来说，需具备 x 的权限	使用者在此目录下的有效群组（effective group）将会变成该目录的群组
执行者在执行的过程中将会获得该程序（group）的支持	用途：若使用者在此目录下具有 w 的权限（可以新建文件），则使用者所创建的新文件，该新文件的群组与此目录的群组相同

SBIT：Sticky Bit

只针对目录有效，作用是： • 当使用者对于此目录具有 w, x 权限，亦即具有写入的权限时； • 当使用者在该目录下创建文件或目录时，仅有自己与 root 才有权力删除该文件

如果将 A 目录加上了 SBIT 的权限时，只能够针对自己创建的文件或目录进行删除/更名/移动等动作，而无法删除他人的文件。

设置SUID/SGID/SBIT 权限

4 为 SUID、2 为 SGID、1 为 SBIT

假设要将一个文件权限改为“-rwsr-xr-x”时，由于 s 在owner权限中，所以是SUID ，因此，在原先的 755 之前还要加上 4 ，也就是：chmod 4755 filename来设置

举例

1

chmod u=rwxs,go=x test; ls -l test

显示：-rws--x--x

user = rws（rwx+SUID）
group = –x（group = –x）
others = –x （others = –x）

1

chmod g+s,o+t test

显示：-rws--s--t

user rws
group –s
others –t

6.4.4 文件类型 file

某个文件的基本数据，例如是属于 ASCII 或者是 data 文件，或者是 binary ，且其中有没有使用到动态函数库（share library）等等的信息

1
2


[root@study ~]# file ~/.bashrc
/root/.bashrc: ASCII text ;==告诉我们是 ASCII 的纯文本文件啊！

6.5 指令与文件的搜索

6.5.1 查找命令的完整文件名 which

1
2
3


[root@study ~]# which [-a] command
选项或参数：
-a ：将所有由 PATH 目录中可以找到的指令均列出，而不止第一个被找到的指令名称

因为 history 是“bash 内置的指令”啦！但是 which 默认是找 PATH内所规范的目录，所以当然一定找不到的

6.5.1 查找指定文件的路径 whereis locate find

where 只找系统中某些特定目录下面的文件，所以会比find快

参数	功能	示例
-l	列出 whereis 会去查询的主要目录 /bin、/sbin、/usr/share/man等
-b（）	只找 binary 格式的文件
-m	只找在说明文档 manual 路径下的文件	`whereis -m passwd`
-s	只找 source 来源文件
-u	搜寻不在上述三个项目当中的其他特殊文件

locate / updatedb

locate 寻找的数据是由“已创建的数据库 /var/lib/mlocate/” 里面的数据所搜寻到的，而数据库的创建默认是在每天执行一次。所以当你新创建起来的文件，却还在数据库更新之前搜寻该文件，那么 locate 会告诉你“找不到。更新 locate 数据库的方法非常简单，直接输入updatedb

updatedb：根据 /etc/updatedb.conf 的设置去搜寻系统硬盘内的文件名，并更新 /var/lib/mlocate 内的数据库文件
locate：依据 /var/lib/mlocate 内的数据库记载，找出使用者输入的关键字文件名。

参数	功能	示例
-i（ignore case）	忽略大小写
-c（count）	不输出文件名，仅计算找到的文件数量
-l（limit）	限制输出行数	`locate -l 5 passwd`
-S（statistics）	查看数据库统计信息，(文件/目录数量等)	`locate -S`
-r（regex/regexp）	正则匹配

find

与时间有关的选项：共有 -atime, -ctime 与 -mtime

参数	功能	示例
-mtime n	在 n 天之前的“一天之内”被更动过内容的文件	`find / -mtime 0` 从现在开始到 24 小时前
-mtime +n	在 n 天之前（不含 n 天本身）被更动过内容的文件文件名
-mtime -n	在 n 天之内（含 n 天本身）被更动过内容的文件文件名	`find /var -mtime -4` 4天内被更动过的文件文件名
-newer file	file 为一个存在的文件，列出比 file 还要新的文件文件名	`find /etc -newer /etc/passwd` 如果文件日期比 /etc/passwd 新就列出

1
2
3


<------(+4) <-(4)-> --------(+4)-------->

7 6 5 4 3 2 1 现在

与使用者或群组名称相关的参数

1️⃣ 先去 /etc/passwd 或 /etc/group 查 username的映射 2️⃣ 查到 username对应的 UID=1001 3️⃣ 再去 inode 里面匹配 UID

参数	功能	示例
-uid n	查找 UID对应的文件
-gid n	查找 GID对应的文件
-user name	查找 username 对应的文件	`find /home -user dmtsai` 搜寻 /home 下面属于 dmtsai 的文件
-group name	查找 groupname 对应的文件	查孤儿文件（安全审计必用）
-nouser	user 不存在 /etc/passwd 的文件	`find / -nouser` 不属于任何人的文件
-nogroup	group 不存在 /etc/group 的文件

与文件权限及名称有关的参数

参数	功能	示例
-name filename	搜寻文件名称为 filename 的文件	`find / -name "passwd"` 找出文件名包含 passwd 这个文件
-size [+-]SIZE	搜寻比 SIZE 还要大（+）或小（-）的文件 c: 代表 Byte， k: 代表 1024Bytes	`find / -size +50k`
-type TYPE	搜寻文件的类型为 TYPE 的文件一般正规文件（f）,设备文件（b, c）,目录（d）链接文件（l）, socket （s）, 及 FIFO （p）	`find /run -type s` 找出 /run 目录下，文件类型为 Socket 文件名
-perm mode	搜寻文件权限 = mode 的文件
-perm -mode	搜寻文件每一位权限都与 mode每位>=的文件	`find / -perm /7000` 同时含有 —s–s–t 的所有三个权限
-perm /mode	用户 or 组 or 其它权限 >= mode文件	`find /usr/bin /usr/sbin -perm /6000` /usr/bin和/usr/sbin 目录下，只要具有 SUID 或 SGID 就列出来

额外动作

参数	功能	示例
-exec command	-exec 后面可再接额外的指令来处理搜寻到的结果(指令不支持命令别名) -exec 必须指定“对每个匹配结果执行的命令”，并用`\` 表示“每找到一个就执行一次”（分次print）或`+`表示“尽量批量执行（一起print，更高效）” 还必须用`{}`作为“当前找到的文件”的占位符	`find /usr/bin /usr/sbin -perm /7000 -exec ls -l {} +;`
-print	将结果打印到屏幕上

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	极强相关	负	高度反向预测关系

Posts 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 和窗口函数