小菜鸟

HDFS 小文件处理全攻略：问题到底在哪？怎么治？

HDFS 对大文件很友好，但小文件是它的”天敌”。

几 KB 的日志、几 MB 的图片、一堆零散的小 JSON——如果数量到了百万级，HDFS 的性能就会急剧下降。不是磁盘不够，是 NameNode 的内存扛不住。

小文件为什么是问题？根源在 NameNode

小文件的危害，根源是 HDFS 的架构设计。

1. NameNode 内存被撑爆

每个文件/目录的元数据在 NameNode 内存中大约占 150 字节。看起来不大，但数量上去就恐怖了：

• 1 亿个小文件 → 约 15GB 内存
• 10 亿个小文件 → 约 150GB 内存

NameNode 的内存是有限的（通常 64GB-256GB），元数据占满了，整个集群就不稳定了。

2. 计算框架的任务爆炸

MapReduce、Spark 通常按块划分任务。1 亿个 1MB 小文件 → 1 亿个 Map 任务。任务启动、调度、销毁的开销远超实际计算时间，作业跑不动。

3. 存储浪费

1MB 文件在 128MB 块大小下，磁盘只占 1MB，但元数据按一个块算（约 150 字节）。浪费的是 NameNode 内存，不是磁盘空间。

HDFS Block 深度解析：为什么是 128MB？大了小了各有什么问题？

HDFS 把文件切成固定大小的块（Block）来存。这个块大小不是随便定的——128MB 这个数字背后有一套权衡逻辑。

理解 Block 的设计原理，你就理解了 HDFS 性能调优的底层逻辑：为什么小文件是大忌？为什么块大小会影响 MapReduce 任务的并行度？什么时候该调大、什么时候该调小？

Block 是什么？存数据的基本单位

HDFS 把每个文件切成固定大小的块，每个块独立存储在不同的 DataNode 上，通过多副本保证可靠性。

三个核心特性：

• 固定大小：默认 128MB（Hadoop 2.x 起），可以调
• 独立存储：一个文件的多个块分布在不同的 DataNode 上
• 对用户透明：你操作的是完整文件，不用管它切成了几块

一个重要细节： 一个 10MB 的文件不会占满 128MB 的磁盘空间，它只占 10MB。块大小只是”切分上限”，不是”分配上限”。

块大小为什么是 128MB？核心是”寻址时间 vs 传输时间”

块大小的设计目标：让传输数据的时间远大于定位数据的时间。

寻址时间：NameNode 告诉客户端”这个块在哪台机器上”的时间，毫秒级（约 10ms）。

传输时间：从磁盘读取一个块并传输的时间。

如果块太小（比如 1MB），传输只要 0.01 秒，但寻址要 0.01 秒——寻址时间占 50%，效率极低。

如果块太大（比如 1GB），传输要 10 秒，寻址时间占比只有 0.1%。但带来另一个问题：任务并行度下降（每个块对应一个 Map 任务，块太大任务数太少，集群闲着）。

128MB 是怎么来的？

结论：128MB 是在”寻址开销可接受”和”任务并行度充足”之间取的平衡点。 磁盘速度越快，这个平衡点可以往上移（比如 256MB）。

HDFS常用命令全解析

HDFS（Hadoop Distributed File System）作为 Hadoop 生态的核心分布式存储系统，其命令操作与 Linux Shell 命令高度相似，仅需添加 hadoop fs 或 hdfs dfs 前缀即可使用。其中 dfs 是 fs 的具体实现，实际使用中两者功能基本一致。

基础语法与通用选项

HDFS 命令的基本语法格式为：

hdfs dfs [通用选项] [命令] [命令参数]
# 或
hadoop fs [通用选项] [命令] [命令参数]

常用通用选项

• -conf <配置文件>：指定应用程序配置文件
• -D <property=value>：定义配置属性值
• -fs <文件系统>：指定默认文件系统（如 hdfs://namenode:port 或 file:///）
• -jt <资源管理器>：指定 ResourceManager 地址

HDFS 深度解析：大数据存储的”硬盘不够、单盘坏了怎么办”

做大数据的人，绕不开 HDFS。

你的数据量上了 PB 级，单机硬盘装不下；硬盘总会坏，数据丢了怎么办？HDFS 就是 Google GFS 的开源实现，专门解决这两个问题：存储不够，加机器；硬盘坏了，多副本。

HDFS 解决的两个核心问题

问题1：硬盘不够用

单机硬盘容量有限（比如一块 20TB），但数据量可能是 PB 级。解决方案：分布式存储——多台机器组成集群，数据分散存到各个节点上。机器不够就加机器，理论上无限扩展。

问题2：硬盘坏了数据丢

单机硬盘会坏，坏了数据就没了。解决方案：多副本——每个数据块默认存 3 份，分别放到不同的机器上。一台机器挂了，数据还在。

这就是 HDFS 的核心理念：用廉价硬件的集群，解决海量数据的可靠存储问题。

HDFS 核心架构：主从协同的三层模型

HDFS 是典型的 Master-Slave 架构，四个角色各司其职：

graph TD
    A[Client<br/>客户端] -->|1. 元数据交互| B[NameNode<br/>主节点 元数据管理]
    A -->|2. 数据读写| C[DataNode1] & D[DataNode2] & E[DataNode3]
    B -->|3. 心跳/块报告| C & D & E
    B -->|4. 元数据合并| F[Secondary NameNode<br/>辅助节点]
    C & D & E -->|存储数据| G[本地磁盘<br/>Block 副本]
    note[核心分工 NameNode 管元数据,DataNode 存数据,Client 直接读写数据节点]

一句话总结：NameNode 管”什么东西存在哪”，DataNode 管”东西本身”，Secondary NameNode 帮 NameNode 整理账本。

广告创意轮播实现：从 Redis 到 HBase 的方案详解

在广告投放中，创意轮播是一种常见策略，通过让同一广告单元下的多个创意按顺序或比例交替展示，帮助广告主对比不同创意的效果（如点击率、转化率），优化投放策略。本文将详细介绍基于 Redis 和 HBase 的创意轮播实现方案，分析其适用场景与优化思路。

创意轮播的核心需求

创意轮播的核心目标是让多个创意 “雨露均沾”，确保各创意的曝光量尽可能均衡。具体需求包括：

• 顺序轮播：按固定顺序循环展示创意（如创意 A→创意 B→创意 C→创意 A…）。
• 状态记录：记住用户最后一次看到的创意，确保下次展示下一个。
• 高并发支持：在百万级 QPS 的广告请求中，快速判断并返回下一个创意。
• 数据持久化：长期保存用户的创意展示记录，支持历史数据分析。

基于 Redis 的创意轮播实现（高并发场景）

Redis 凭借内存存储的高效性，适合作为创意轮播的实时存储方案，尤其适用于对响应速度要求高的场景（如信息流广告、开屏广告）。

数据结构设计

• Key：采用 用户ID:广告单元ID（uid:dealId）的格式，唯一标识 “用户 - 广告单元” 组合。
• Value：使用 Redis List 存储用户对该广告单元的创意曝光记录，按时间倒序排列（最新记录在最前），或仅存储最后一次曝光的创意 ID（简化版）。