Hadoop

第一章

大数据发展的三个阶段

• 萌芽期：上世纪90年代至本世纪初。主要产品如数据仓库、专家系统、知识管理系统等。
• 成熟期：本世纪前十年。非结构化数据大量产生，主要产品具有并行计算和分布式系统两大核心技术，hadoop很牛逼
• 大规模应用期：2010年以后，大规模应用。

各类结构化和非结构化数据

• 10%的结构化数据，存储在数据库中
• 90%的非结构化数据，它们与人类信息密切相关

数据来源

科学研究

• 基因组
• LHC 加速器
• 地球与空间探测

企业应用

• Email、文档、文件
• 应用日志
• 交易记录

Web 1.0 数据

• 文本
• 图像
• 视频

Web 2.0 数据

• 查询日志、点击流
• Twitter、Blog、SNS
• Wiki

第二章

Hadoop生态中的HDFS，HBase，MapReduce，YARN，Zookeeper

Hadoop 生态核心组件

Hadoop 是一套用于海量数据存储和处理的分布式系统。其核心组件可以概括为：

• HDFS：分布式存储
• HBase：分布式数据库
• MapReduce：分布式批处理
• YARN：资源管理与任务调度
• ZooKeeper：分布式协调

HDFS

HDFS 全称为 Hadoop Distributed File System，是 Hadoop 的分布式文件系统。

HDFS 会将大文件切分为多个数据块，并将数据块分散存储在不同服务器上。每个数据块通常保存多个副本，以提高系统的容错能力。

主要组件

• NameNode：管理文件系统的元数据，如文件目录、文件名和数据块位置。
• DataNode：负责实际存储数据块。
• Checkpoint Node：定期合并元数据文件，不是 NameNode 的实时备份。

特点

• 适合存储大文件。
• 支持高吞吐量的顺序读写。
• 采用多副本机制，容错能力较强。
• 适合“一次写入、多次读取”的场景。
• 不适合大量小文件和低延迟随机访问。

⸻

HBase

HBase 是建立在 HDFS 上的分布式 NoSQL 数据库，适合海量数据的随机读写。

HDFS 主要用于文件存储，而 HBase 可以根据 Row Key 快速查询、插入和更新某条数据。

数据模型

• Row Key：一行数据的唯一标识。
• Column Family：列族，用于组织相关列。
• Column Qualifier：列族中的具体列。
• Timestamp：用于保存数据的多个版本。
• Cell：由行键、列族、列和时间戳共同确定的数据单元。

主要组件

• HMaster：负责表管理、Region 分配和负载均衡。
• RegionServer：负责数据的实际读写。
• Region：表按照 Row Key 范围划分形成的数据分区。
• ZooKeeper：负责节点协调和状态管理。

特点

• 支持海量数据存储。
• 支持高频随机读写。
• 可以根据 Row Key 快速查询。
• 不擅长复杂 JOIN 和关系型事务。

⸻

MapReduce

MapReduce 是 Hadoop 的分布式批处理计算模型。

它将一个大型计算任务拆分为多个小任务，并分配到多台服务器上并行执行。

Map 阶段

Map 读取输入数据，并将其转换为键值对。

输入：Hadoop HBase Hadoop 输出： (Hadoop, 1) (HBase, 1) (Hadoop, 1)

Reduce 阶段

Reduce 对相同 Key 的数据进行汇总。

输出： (Hadoop, 2) (HBase, 1)

中间过程

• Shuffle：将相同 Key 的数据发送到同一个 Reduce。
• Sort：按照 Key 对数据进行排序。
• Partition：决定数据由哪个 Reduce 任务处理。

特点

• 适合离线批处理。
• 适合日志分析、数据清洗和大规模统计。
• 中间结果经常写入磁盘，执行延迟较高。
• 不适合实时计算和交互式查询。

⸻

YARN

YARN 全称为 Yet Another Resource Negotiator，是 Hadoop 的资源管理和任务调度系统。

YARN 负责统一管理集群中的 CPU、内存等资源，并将资源分配给 MapReduce、Spark 等计算框架。

主要组件

• ResourceManager：整个集群的资源管理中心。
• NodeManager：管理单台服务器的资源和任务。
• ApplicationMaster：管理某个具体应用的执行过程。
• Container：任务运行所获得的 CPU、内存等资源单位。

工作流程

1. 客户端向 ResourceManager 提交应用。
2. ResourceManager 分配 Container。
3. 在 Container 中启动 ApplicationMaster。
4. ApplicationMaster 向 ResourceManager 申请更多资源。
5. NodeManager 在 Container 中运行具体任务。
6. ApplicationMaster 监控任务执行状态。
7. 任务结束后释放资源。

YARN 不负责存储或处理数据，而是负责资源分配和任务调度。

⸻

ZooKeeper

ZooKeeper 是一个分布式协调服务，用于协调多个分布式节点之间的状态和行为。

主要功能

• 配置管理
• 服务注册与发现
• 主节点选举
• 分布式锁
• 节点状态监控
• 集群成员管理

ZooKeeper 中的数据采用树形结构存储，每个节点称为 ZNode。

常见 ZNode 类型

• 持久节点：客户端断开后仍然存在。
• 临时节点：客户端断开后自动删除。
• 顺序节点：创建时自动添加递增编号。

在 Hadoop 生态中，ZooKeeper 常用于协调 HBase 节点、进行主节点选举和监控服务器状态。

ZooKeeper 主要保存协调信息，不适合存储大规模业务数据。

⸻

五个组件之间的关系

                Hadoop 生态
                    │
      ┌─────────────┼─────────────┐
      │             │             │
    HDFS           YARN        ZooKeeper
  数据存储       资源管理       分布式协调
      │             │             │
      │        MapReduce          │
      │         批量计算          │
      │                           │
      └──────── HBase ────────────┘
             随机读写数据库

• 数据通常存储在 HDFS 中。
• HBase 基于 HDFS 提供随机读写能力。
• MapReduce 对 HDFS 中的数据进行批量计算。
• YARN 为 MapReduce 等计算任务分配资源。
• ZooKeeper 协调 HBase 等分布式服务的节点。

对比总结

组件 核心作用 典型场景 HDFS 分布式文件存储 海量文件、大规模数据集 HBase 分布式 NoSQL 数据库 海量数据随机读写 MapReduce 分布式批处理 日志分析、数据统计 YARN 资源管理与任务调度 管理集群 CPU 和内存 ZooKeeper 分布式协调 主节点选举、状态监控

记忆方式：

HDFS 管存储，HBase 管查询，MapReduce 管计算，YARN 管资源，ZooKeeper 管协调。

第三章

名称节点中的FsImage和EditLog

• FsImage文件包含文件系统中所有目录和文件inode的序列化形式。每个inode是一个文件或目录的元数据的内部表示，并包含此类信息：文件的复制等级、修改和访问时间、访问权限、块大小以及组成文件的块。对于目录，则存储修改时间、权限和配额元数据

• FsImage文件没有记录每个块存储在哪个数据节点。而是由名称节点把这些映射信息保留在内存中，当数据节点加入HDFS集群时，数据节点会把自己所包含的块列表告知给名称节点，此后会定期执行这种告知操作，以确保名称节点的块映射是最新的。

• NameNode 启动与元数据更新

NameNode 启动时，会先将 FsImage 文件中的内容加载到内存中，然后依次执行 EditLog 文件中记录的各项操作，使内存中的文件系统元数据与实际状态保持一致。

存储在内存中的元数据主要用于支持客户端的读操作。

当文件系统元数据在内存中成功建立后，系统会生成一个新的 FsImage 文件，并创建一个空的 EditLog 文件。

NameNode 启动后，HDFS 中产生的更新操作会继续写入 EditLog，而不是直接写入 FsImage。原因是 FsImage 通常很大，达到 GB 级别很常见。如果每次更新都直接修改 FsImage，会导致系统运行速度明显下降。

相比之下，EditLog 文件较小，将更新操作追加写入 EditLog 的效率更高。

每次执行写操作时，EditLog 都必须先完成同步更新，NameNode 才会向客户端返回操作成功的信息。

• NameNode 运行期间 EditLog 不断变大的问题

在 NameNode 运行期间，HDFS 中的所有更新操作都会直接写入 EditLog。随着系统持续运行，EditLog 文件会不断增大。

这在 NameNode 正常运行时通常不会产生明显影响。但是，当 NameNode 重启时，需要：

1. 将 FsImage 中的文件系统元数据加载到内存；
2. 按顺序执行 EditLog 中记录的所有更新操作；
3. 恢复最新的文件系统元数据状态。

当 EditLog 文件非常大时，NameNode 需要执行大量日志记录，因此启动过程会非常缓慢。在此期间，HDFS 无法正常对外提供服务，从而影响用户使用。

SecondaryNameNode

为了解决 EditLog 不断增大导致 NameNode 启动缓慢的问题，HDFS 引入了 SecondaryNameNode。

SecondaryNameNode 会定期将 FsImage 和 EditLog 进行合并，生成新的 FsImage，这个过程称为 Checkpoint。

通过定期执行 Checkpoint，可以：

• 减小 EditLog 文件的大小；
• 减少 NameNode 重启时需要重放的日志数量；
• 缩短 NameNode 的启动时间。

SecondaryNameNode 一般单独运行在一台机器上。

注意： SecondaryNameNode 不是 NameNode 的备用节点。它的主要作用是执行 Checkpoint，而不是在 NameNode 故障时直接接管 NameNode 的工作。