Hadoop成长史-从Nutch子项目到大数据生态王者

Hadoop 成长史 — 从 Nutch 子项目到大数据生态王者2003 年Google 发表了三篇论文。一个叫 Doug Cutting 的程序员读后灵光一现于是他写了一个开源项目。谁也想不到这个项目日后会成为大数据时代的操作系统。一、开篇一个人的灵感一群人的生态想象一下你有一份1TB的文件里面是过去十年全国电商的交易记录。你想统计哪个省份的哪类商品销量最高。单机读一遍这个文件就需要大半天——这还是不考虑 CPU 处理时间的情况。怎么办答案只有一个把文件拆开让多台机器一起算。2004 年前后这就是 Doug Cutting 面临的真实问题。他当时正在做一个开源的搜索引擎Nutch需要对海量网页进行索引。单机搞不定集群又没有好用的软件框架——于是他决定自己写一个。二、Hadoop 的前世今生2.1 Google 的三驾马车2000 年代初Google 已经是有海量数据的互联网巨头。他们是如何处理 PB 级数据的2003-2006 年间Google 公开发表了三篇论文业界称为“Google 三驾马车”论文发表时间解决了什么问题影响GFSGoogle File System2003 年如何在成百上千台廉价服务器上可靠地存储海量数据HDFS 的灵感来源MapReduce2004 年如何对海量数据进行分布式并行计算Hadoop MapReduce 的灵感来源BigTable2006 年如何在分布式环境下实现结构化数据的存储和查询HBase 的灵感来源这三篇论文的出现改变了整个大数据产业的走向。以至于后来有人感叹“Google 不是在写论文而是在定义行业标准。”2.2 Doug Cutting 与 NutchDoug Cutting是一位对搜索引擎充满热情的程序员。他开发的Nutch是一个开源的搜索引擎——就像当时市面上的 Lucene也是他开发的一样他希望给互联网世界提供一个自由、开放的搜索方案。但问题来了要搜索互联网必须能处理海量的网页数据。Nutch 在单机上跑不动。读到了 Google 的 GFS 和 MapReduce 论文后Cutting 像发现新大陆一样——这就是他梦寐以求的架构他立刻在 Nutch 中实现了DFS分布式文件系统和MapReduce机制。这就是 Hadoop 的雏形。2.3 从 Nutch 剥离成为独立项目随着 DFS 和 MapReduce 在 Nutch 中的成熟Cutting 意识到这套分布式处理的框架不只是一个搜索引擎的附属品它可以独立出来成为一个通用的平台。于是DFS MapReduce 从 Nutch 中被剥离起了一个新名字Hadoop——这是 Cutting 给他儿子的大象玩具起的名字。后来 Hadoop 的 logo 就是一头黄色的大象 2006 年Hadoop 被引入 Apache 基金会随后迅速发展。2.4 发展历程时间线时间 / 版本里程碑事件意义2004-2005Cutting 在 Nutch 中实现 DFS 和 MapReduceHadoop 的基因诞生2006Hadoop 从 Nutch 剥离加入 Apache 基金会独立项目的开始早期Hive、MapReduce、HDFS、Avro、Chukwa 成为 Hadoop 子项目生态体系初步形成—Hadoop 成为 Apache顶级项目身份确立Hadoop 1.0.0Avro、HBase、Hive、Pig、ZooKeeper 陆续脱离 Hadoop 成为 Apache 顶级项目生态组件成熟独立Hadoop 2.0.0-alphaYARN 框架引入 Impala 加入生态系统架构大升级Hadoop 2.0.0正式版发布2.x 时代全面到来Hadoop 3.0.0Spark 成为 Apache 顶级项目生态进一步壮大2.5 Hadoop 的版本演进 — 为什么需要改进Hadoop 1.x 时代的局限Hadoop 1.0 的核心由两部分组成HDFS分布式存储MapReduce分布式计算 资源管理耦合在一起MapReduce 在 1.x 中既负责任务计算又负责资源管理。这种架构的后果问题描述JobTracker 单点故障JobTracker 只有一个挂了整个集群不能提交新任务功能耦合MapReduce 既要算数据又要管资源——两头没讨好扩展性差集群超过 4000 个节点时JobTracker 成为瓶颈只支持 MapReduce其他计算框架如 Impala、Spark无法接入Hadoop 2.x 的改进Hadoop 2.0 在架构层面做了两件大事引入 YARN 资源管理框架→ 把资源管理从 MapReduce 中拆出来变成通用组件HDFS 高可用HA→ 解决 NameNode 单点故障这就是 Hadoop 2.0 最核心的两个改进——解耦计算和资源管理分离 高可用不因为一个节点挂了就停摆。Hadoop 3.x 的变化支持erasure coding纠删码——比副本节省 50% 存储空间支持多个NameNode联邦模式默认最低 Java 版本升级三、YARN — 资源管理的内阁部长3.1 YARN 的设计思想YARNYet Another Resource Negotiator另一种资源协调者的核心思想是把 Hadoop 1.0 中 JobTracker 的功能拆成两个独立的角色。Hadoop 1.0 Hadoop 2.0 以后 ┌────────────┐ ┌──────────────────┐ │ JobTracker │ → │ ResourceManager │ ← 全局资源调度 │既管计算 │ │ 只负责分配资源 │ │ 又管资源 │ ├──────────────────┤ └────────────┘ │ ApplicationMaster │ ← 每个应用一个 │ 只负责本任务 │ └──────────────────┘3.2 YARN 三大核心组件① ResourceManagerRM— 全局大管家职责对整个集群的资源CPU、内存进行统一管理和分配内部有两个重要组件Scheduler调度器负责将资源分配给各个应用程序不关心任务状态和监控ApplicationsManager负责接收客户端提交的任务、协商第一个 Container、以及重启失败的 ApplicationMaster② NodeManagerNM— 每个节点的监工职责管理单个节点上的资源每个节点一个具体工作定时向 RM 汇报本节点的资源使用情况CPU、内存、磁盘负责启动和停止 Container任务容器管理本节点上的任务生命周期③ ApplicationMasterAM— 每个应用的项目经理职责每个提交的应用程序对应一个 AM具体工作与 RM 协商申请资源Container把获得的资源进一步分配给内部的各个任务二次分配与 NM 协作启动/停止任务监控任务执行状态失败时重新申请资源打个比方RM是公司的人力资源部——不关心具体项目怎么做只负责给项目分配人员名额NM是每个部门的小组长——知道部门里谁在干什么、什么资源被占用了AM是项目经理——拿到名额后决定让谁做什么事、怎么分工3.3 YARN 完整工作流程7 步骤下面是一个完整的 YARN 任务执行流程Step 1用户提交应用 │ ▼ Step 2RM 分配第一个 Container → 启动 ApplicationMaster │ ▼ Step 3AM 向 RM 注册RM 知道这个项目的项目经理上线了 │ ▼ Step 4AM 轮询向 RM 申请资源老板我还要 5 个人 │ ▼ Step 5RM 分配资源 → AM 获得 Container │ ▼ Step 6AM 通知 NM 启动任务 → NM 设置运行环境并启动 │ ▼ Step 7各任务向 AM 汇报状态 → 全部完成后 AM 向 RM 注销逐步骤详细解释步骤动作实现细节1客户端 Client 向 YARN 提交 Application包含任务代码、配置、输入输出路径等信息2RM 的调度器为应用分配一个 Container这个 Container 用来运行ApplicationMaster3AM 被创建后向 RM 注册RM 可以在 Web UI 上显示应用运行状态4AM 采用轮询方式通过 RPC 向 RM 申请资源AM 会估算计算所需的资源量分批申请5RM 向 AM 分配ContainerContainer 是资源分配的单位指定 CPU 核数 内存大小6NM 为任务设置好运行环境把任务启动命令写入一个脚本 → 运行该脚本启动任务7各任务通过 RPC 向 AM 汇报状态如果任务失败AM 负责重新申请资源重启任务全部完成 → AM 向 RM 注销并关闭自己3.4 YARN 的优势通用性不只是 MapReduceSpark、Flink 等计算框架都可以跑在 YARN 上可扩展性ResourceManager 的职责比 JobTracker 轻很多集群规模可以更大高利用率资源细粒度分配多个框架共享集群资源高可用RM 可以配置主备模式四、HDFS 高可用架构 — 解决单点故障4.1 单点故障问题在 Hadoop 1.0 中NameNode是 HDFS 的大脑——元数据全部存储在 NameNode 的内存中。如果 NameNode 挂了整个 HDFS 集群就无法访问所有数据失联。就像图书馆的目录系统管理员突然消失——书都还在书架上但没人知道哪本书在哪个位置。4.2 高可用HA设计Hadoop 2.0 引入了HDFS High Availability高可用机制┌──────────────┐ ZooKeeper ┌──────────────┐ │ NameNode │ ◄──────────────► │ NameNode │ │ Active │ │ Standby │ │ 正在服务 │ │ 热备 │ └──────┬───────┘ └──────┬───────┘ │ │ ▼ ▼ DataNode 1 ─ DataNode 2 ─ DataNode 3 ─ DataNode 4 ... 所有 DataNode 同时向 Active 和 Standby 汇报核心设计要点角色职责Active NameNode处理所有客户端请求读写、增删改等Standby NameNode随时准备接替保持最新的元数据状态ZooKeeper协调者监控 NameNode 健康状态ZKFC故障恢复控制器每个 NameNode 配一个负责发送心跳给 ZooKeeper4.3 故障转移流程正常运行 Active NN 正常工作 → ZKFC 定期发心跳 → ZooKeeper 知道Active 活着 故障发生 Active NN 宕机 → ZKFC 检测到心跳停止 → ZooKeeper 通知 Standby 故障恢复 Standby NN 的 ZKFC 收到通知 → 将 Standby 切换为 Active → 接管服务整个过程通常是自动的从故障发生到服务恢复一般在几十秒以内。4.4 数据一致性保证Standby NameNode 要保持和 Active NameNode数据一致否则切换后会丢失数据。这是如何保证的JournalNode 共享编辑日志Active NN 把每次修改操作写入 JournalNode 集群通常是 3 个节点Standby NN 从 JournalNode 读取并应用这些操作DataNode 同时向两个 NN 汇报块信息保证 Standby NN 的块映射表也是最新的通过这种方式当 Active 宕机时Standby 可以无缝接替不会丢失数据也不会丢失已经提交的写操作。五、Hadoop 生态系统一览经过十几年的发展Hadoop 从最初的 HDFS MapReduce成长为一个庞大的生态系统┌──────────────────────┐ │ ZooKeeper协调服务 │ └──────────────────────┘ │ ┌───────┐ ┌───────┐ ┌───────┴───────┐ ┌───────┐ ┌───────┐ │ Flume │ │ Sqoop │ │ HBase │ │ Hive │ │ Pig │ │ 日志采集│ │ 数据迁移│ │ 列式数据库 │ │ 数据仓库│ │ 脚本语言│ └───────┘ └───────┘ └───────────────┘ └───────┘ └───────┘ │ ┌──────────┴──────────┐ │ MapReduce / Tez │ ← 计算引擎 │ Spark / Impala │ └──────────┬──────────┘ │ ┌──────────┴──────────┐ │ YARN │ ← 资源管理 └──────────┬──────────┘ │ ┌──────────┴──────────┐ │ HDFS │ ← 分布式存储 └─────────────────────┘组件一句话定位典型场景HDFS分布式文件系统数据存储的基石存储 PB 级文件MapReduce分布式计算框架分而治之大规模数据批处理YARN资源管理和调度平台统一管理集群资源Hive基于 Hadoop 的数据仓库SQL 查询分析师用 SQL 查大数据HBase分布式列式数据库实时读写实时在线查询如 Facebook 消息Pig数据流脚本语言简化 MapReduce 编程ZooKeeper分布式协调服务配置管理、命名服务、分布式锁Flume日志采集和聚合系统收集 Web 服务器日志到 HDFSSqoop数据导入导出工具HDFS ↔ 传统数据库Mahout机器学习算法库推荐系统、聚类、分类Spark内存分布式计算引擎比 MapReduce 快 10-100 倍Impala实时 SQL 查询引擎交互式分析秒级响应六、篇末小结Hadoop 的核心定位Hadoop 是一个能够对大量数据进行分布式处理的软件框架。用户可以利用 Hadoop 生态体系开发和处理海量数据。由于 Hadoop 有可靠及高效的处理性能它逐渐成为分析大数据的领先平台。本篇知识点脉络图Hadoop 起源 ├── Google 三驾马车GFS/MapReduce/BigTable ├── Doug Cutting Nutch 搜索引擎 └── 从 Nutch 剥离 → Apache 顶级项目 │ 版本演进 ← 1.0存储计算耦合→ 2.0YARN HA→ 3.0纠删码/联邦 │ ├── YARN 架构 │ ├── ResourceManager全局调度 │ ├── NodeManager节点管理 │ ├── ApplicationMaster任务协调 │ └── 7 步骤工作流程 │ ├── HDFS HA │ ├── Active / Standby 双 NameNode │ ├── ZKFC ZooKeeper 自动故障转移 │ └── JournalNode 共享编辑日志 │ └── 生态系统全景HBase / Hive / Spark……下一篇预告深入 HDFS 内部——什么是 NameNodeDataNode 如何工作128MB 的数据块是怎么来的读写数据的 Pipeline 流水线是怎么建立的还会用 Java 代码操作 HDFS从理论到实战一篇搞定。