分桶 on My Learning Notes

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

分桶 on My Learning Notes

【三】Hive 抽样

二、Hive 抽样的三大类型

三、分桶抽样（TABLESAMPLE+BUCKET 最推荐）

1. 分桶表的核心设计

2. 分桶抽样执行流程

四、块抽样（TABLESAMPLE）

1、按数据大小百分比抽样

2、按固定大小抽样

3、按行数抽样

4、❌TABLESAMPLE + WHERE

4.1、一起使用导致的问题

4.2、替代方案

WHERE + RAND

子查询包装

CTE表达式

临时表存储

精确行数抽样

五、随机抽样（RAND）

5.1、概率过滤

5.2、可复现随机样本

5.3、局部随机

5.4、全局随机

×分层抽样（按分组比例）

五、实战案例：用户行为分析抽样

场景：分析国庆期间高活跃用户

【二】Hive 分区与分桶

一、不分区+不分桶

1、表结构

2、物理存储

3、Join 的本质要求：相同 key 必须"碰面"

4、执行过程（Reduce Join / Common Join）

4.1、Map

4.2、Shuffle

4.3、Reduce

4.4 总结

5、引申出分区/分表的概念

二、分区+不分桶

1、表结构

2、物理存储

3、执行过程

3.1、Map

3.2、Shuffle

3.3、Reduce

3.4 总结

4、分区设计原则

三、分桶+不分区

1.1、表结构(小表桶+大表桶) HashMap

1.2、表结构(大表桶+大表桶) SMB Join（Sort Merge Bucket Join）

2、物理存储

3、执行过程（启用Bucket Map Join）

3.1、Map

(小表桶+大表桶) 小表桶加载到HashMap+大表桶流式扫描匹配

(大表桶+大表桶) Sort Merge Bucket Join

3.2、Shuffle（跳过）

3.3、Reduce（跳过）

3.4、总结

4、特殊分桶

情况1：只对一张表分桶

情况2：分桶但桶数不同

情况3：分桶JOIN后还要GROUP BY

四、分桶+分区

1、表结构

2、物理存储

3、执行过程

3.1、Map

3.2、Shuffle（跳过）

3.3、Reduce（跳过）

3.4 总结

五、最佳实践总结

六、性能量化对比

七、参数设置

1️⃣ hive.optimize.bucketmapjoin = true

2️⃣ hive.optimize.bucketmapjoin.sortedmerge = true

3️⃣ hive.enforce.bucketing = true

4️⃣ hive.enforce.sorting = true

四个参数的协作关系图

典型踩坑场景

生产环境推荐配置组合

A. 通用 Bucket Map Join 配置

1️⃣ `hive.optimize.bucketmapjoin = true`

2️⃣ `hive.optimize.bucketmapjoin.sortedmerge = true`

3️⃣ `hive.enforce.bucketing = true`

4️⃣ `hive.enforce.sorting = true`