Hadoop on My Learning Notes

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

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地址和路由表来推断网络距离

Hadoop on My Learning Notes

【二】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 配置

B. SMB Join 完整配置（超大表 Join 超大表）

3、分布式计算 MapReduce & YARN

3.1、分布式概述

MapReduce

YARN

3.2、YARN部署

MapReduce配置文件

启动YARN

3.3、提交MapReduce任务到YARN

3.3.1、wordcount示例

3.3.1、pi示例

2、分布式存储 HDFS

一、HDFS集群环境部署

1.1 Hadoop 安装包目录结构

1.2 配置HDFS回收站

1.3 HDFS集群的Web页面

二、HDFS的Shell操作

2.1 Yarn、HDFS、Hadoop启停命令

2.2 HDFS的文件操作

2.3 HDFS的UI操作

2.4 HDFS的权限

三、Windows连接HDFS

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

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

3.2.1 NFS 定义

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

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

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

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