兄弟既然点进来了说明你准备啃Hadoop这块硬骨头。这个系列就是干这个的把Hadoop从里到外掰碎了讲明白。今天这篇是“002篇-简介”是整个系列的第一篇正式内容主要解决三个问题Hadoop到底是什么、它解决了什么、你该怎么理解它的核心设计。我尽量用大白话加实际场景来讲别怕听不懂也别觉得啰嗦基础打不牢后面搭建集群、调优、看源码全都会卡壳。这篇内容适合刚转大数据方向的开发、准备大数据面试的求职者以及想系统了解Hadoop生态但被网上零散资料劝退的朋友。我把这几年用Hadoop踩过的坑和总结的经验也一起融进来讲希望能让你少走点弯路。1. 先把Hadoop到底是什么说清楚1.1 一个仓库加一条流水线很多人一上来就背概念“Hadoop是一个开源的分布式存储和计算框架”背完就忘。我用个生活化的例子帮你建立画面感。假设你开了一家大型电商仓库每天产生的货物数据多到一个小房间放不下。单个房间就是一台服务器它的硬盘容量有限CPU和内存也有限。Hadoop做的事很简单租下整栋楼把货物分门别类地塞进各个房间然后安排工人按订单在整栋楼里协同干活。对应到技术上HDFS分布式文件系统负责把数据切块存到多台服务器的硬盘上MapReduce和YARN负责调度计算任务让多台机器一起处理数据。所以我说“Hadoop 一个分布式存储系统 一个分布式计算框架”这个理解比背官方定义管用得多。你可能会问为什么一定要“分布式”因为单机存不下、算不动。一个TB的数据单块硬盘可以勉强放下但处理它的时候单颗CPU跑上几天几夜也不一定能出结果。分布式核心就是“人多力量大”把一个大问题拆成很多小问题让一堆机器同时开工。Hadoop的设计哲学有一条非常关键移动计算比移动数据更划算。数据量大了之后把几百TB数据从存储节点搬到计算节点网络传输成本高到无法接受。所以Hadoop反过来把计算程序发送到数据所在的节点上去执行这就是所谓的“数据本地性”。1.2 为什么当年非要有Hadoop回过头看Hadoop的历史能帮你理解它设计上的很多取舍。2003年到2004年Google发表了三大论文GFSGoogle文件系统、MapReduce分布式计算模型、BigTable分布式存储系统。这几篇论文解决了一个当时很棘手的问题互联网搜索产生的海量网页数据单机存储和计算已经完全撑不住了。Hadoop就是根据这几篇论文的开源实现。Doug Cutting在开发中继Nutch搜索引擎项目时发现处理上亿网页的规模传统方案根本跑不动于是照着GFS和MapReduce的论文实现了对应的开源版本。2006年这个项目正式从Nutch中独立出来成为Apache Hadoop。为什么不用传统数据库因为关系型数据库在海量数据面前有两个硬伤一是单表数据量过千万、上亿之后查询性能急剧下降即使做了分库分表运维复杂度也高得吓人二是传统数据库的扩展方式是纵向扩展也就是买更强的服务器但最强服务器也有上限而且贵得离谱。Hadoop走的是横向扩展堆普通x86服务器就行成本低很多扩容也简单加几台机器就够了。Hadoop还有一点在当时非常难得开源免费。商业大数据方案动辄几百万授权费而Hadoop可以跑在任何一台普通服务器上。这也是它能在短短几年内迅速占领互联网公司数据平台的根本原因。1.3 三驾马车HDFS、MapReduce、YARNHadoop生态现在非常庞大但核心底座始终是三个组件我称之为“三驾马车”。HDFS管存储全称是Hadoop Distributed File System。负责把大文件切成数据块默认128MB分散存储在多台机器的硬盘上同时维护这些块的副本保证某台机器挂了数据还在。举个例子你有一个1GB的日志文件HDFS会把它切成大约8个128MB的块每个块默认存3份分布在不同节点上。MapReduce管计算是一种编程模型。它把计算分成两个阶段Map阶段负责“分而治之”把数据拆分处理Reduce阶段负责“合而为一”把Map输出的中间结果汇总。经典的例子就是单词计数统计一部小说中每个单词出现的次数Map阶段并行统计各个章节Reduce阶段把所有章节的结果合并成最终结果。YARN管资源调度全称是Yet Another Resource Negotiator。它负责把集群中每台机器的CPU、内存统一管理起来谁有计算任务就给它分配一部分资源。没有YARN之前MapReduce既负责计算又负责资源管理导致其他计算框架很难复用Hadoop集群。YARN把资源调度这一层剥离开后来Spark、Flink这些计算框架就能直接跑在YARN上共享同一套计算资源。这三者的关系你可以这样理解HDFS是仓库MapReduce和Spark这些计算框架是流水线工人YARN是调度中心负责安排工人去哪条线、什么时候开工。2. 核心组件拆开揉碎别光记名词2.1 HDFS内部是怎么工作的HDFS采用主从架构。主节点叫NameNode从节点叫DataNode。NameNode管元数据也就是“文件和块的对应关系、每个块在哪台机器上”这类信息但不存真实数据。DataNode才是真正存放数据块的。客户端要读一个文件时先问NameNode这个文件有哪些块、都在哪几台DataNode上拿到地址列表后客户端直接去对应的DataNode读数据。注意数据在读写过程中不经过NameNodeNameNode只负责索引这种设计避免了主节点成为数据瓶颈。写入流程有趣一些。客户端把128MB的数据块写好之后需要向NameNode汇报NameNode会在元数据里登记。为了保证数据不丢每个块默认有3个副本放置策略是第一个副本放在客户端所在的节点如果客户端不在集群内则随机选一个第二个副本放在与第一个副本不同机架的某个节点第三个副本放在与第二个副本同机架但不同节点的位置上。这样设计的好处是如果整个机架断电至少还留有分布在另一个机架上的副本如果某个节点损坏同机架内还有一份可以快速恢复。很多新手不理解为什么数据块大小是128MB不是1MB也不是1GB。这里有个权衡HDFS在读取一个块时磁盘寻址时间大约在10毫秒左右磁盘顺序传输速率大约在100MB/s。如果想让寻址时间控制在传输时间的1%左右那么块大小应该在100MB量级。如果块设置得太小比如1MB那么读写大量小块的寻址开销会占据很大比例效率很低如果块设置得太大比如1GBMapReduce计算时很难并行处理单个块因为一个块只会被一个Map任务处理。128MB是一个经过实践检验的平衡值。HDFS还有一个我必须要提的头疼问题小文件问题。如果集群里存了几百万个几KB的小文件每个文件都要在NameNode内存里占用一条元数据记录NameNode的内存会很快被撑爆。所以生产环境里小文件一定要合并成大文件再入HDFS这是所有Hadoop工程师都知道的铁律。2.2 MapReduce的“慢”是有原因的MapReduce的计算过程有点像流水线加工。假设我们要统计一年内每个用户的购买次数。数据在HDFS上分布在上千个块中。Map阶段每个块会被分给一个Map任务Map任务逐行读取数据解析出用户ID输出一条“用户ID - 1”的中间记录。这些中间记录会先写入本地磁盘不是内存因为数据量太大内存放不下。接下来是Shuffle也就是把Map输出的中间记录按照用户ID进行分组相同用户ID的记录发送到同一个Reduce节点。这个过程是MapReduce最耗时也最复杂的阶段Map端会做一次本地排序然后分区Reduce端要从不同的Map节点拉取属于自己分区的数据再合并、排序。数据在网络中传输加上磁盘读写速度自然快不起来。Reduce阶段每个Reduce任务拿到一个用户ID对应的所有“1”之后直接累加得到总次数最后把结果写入HDFS。整个过程中数据经历了“读HDFS - 写本地磁盘 - 网络传输 - 写本地磁盘 - 写HDFS”的多次落盘。在传统MR的实现里每个步骤之间都可能产生序列化和反序列化开销这使得MapReduce的延迟很高通常以分钟甚至小时计。所以MapReduce适合跑离线批处理不适合做实时计算。我见过不少刚入行的朋友吐槽MapReduce又慢又笨重但它的价值在于模型足够简单稳定性和容错性极强任何一台机器挂了任务会被重新调度到其他节点继续执行在大规模集群上是经过时间验证的可靠选择。后来Spark的一大优势就是尽量把中间结果放在内存中减少磁盘IO速度比MapReduce快很多但这是建立在YARN的资源管理之上的计算框架可以替换底座依然是HDFS。2.3 为什么中间非得插一个YARNHadoop早期版本只有两个组件HDFS和MapReduce。1.x的时候MapReduce承担了两份工作一是执行计算任务二是管理集群资源。这在当时没太大问题但后来社区发现很多其他计算框架也需要使用同一份数据比如图计算、机器学习如果每个框架都要自己管理资源集群就会乱成一锅粥。所以YARN在Hadoop 2.0被独立出来它的核心是两层调度全局有一个ResourceManager资源管理器每个节点上有一个NodeManager节点管理器。ResourceManager负责接收客户端的作业请求分配资源NodeManager负责管理单个节点的容器。容器就是内存和CPU的分配单位一个作业可以在一个节点上申请多个容器。作业提交后YARN会先启动一个ApplicationMaster这个家伙是作业的“项目经理”它负责向ResourceManager申请资源和各个NodeManager协商启动容器并监控任务的执行进度。同一个集群可以同时跑多个不同的计算任务互不干扰资源还能动态调整。打个比方YARN就像写字楼的物业不同的租户计算框架都在同一栋楼里办公物业统一负责水电空调分配。没有物业之前每个公司都得自己扯一根电线一层楼可能被几个公司同时拉扯乱到崩溃。3. 搞明白了Hadoop再聊那些绕不开的场景和面试题3.1 哪些场景适合Hadoop哪些不适合硬上Hadoop不是万能药我就见过有人非要用Hive跑一条只查几百条记录的小查询结果启动任务就要几十秒查出来还没Excel快。选型之前先搞清楚边界。Hadoop适合的场景有这几类海量离线批处理、历史数据分析、数据仓库建设、大规模日志处理。比如电商平台每天产生的几十亿条行为日志入仓后用Hive做ETL清洗按天产出统计报表这种模式Hadoop非常拿手。再比如推荐系统的用户行为特征计算从海量历史数据中提取用户偏好数据量大但处理周期长Hadoop也完全合适。Hadoop不适合的场景也讲清楚。第一实时计算别用Hadoop毫秒级延迟和它无缘应该用Flink或Spark Streaming。第二OLTP类型的业务查询不能用Hadoop它不支持事务、行级更新应该用MySQL、PostgreSQL这类数据库。第三数据量很小的时候别用Hadoop一台机器能搞定的事非要搭集群运维成本、开发成本全部翻倍纯属自找麻烦。3.2 大数据面试高频题这一篇先串讲在做面试辅导的时候我发现Hadoop的面试题其实高度集中核心知识点就那么几个换着花样考。提前掌握了面试基本不会被问倒。面试题一NameNode宕机怎么办这个问题的得分点在于NameNode单点故障是HDFS的经典问题。在没有启用高可用HA的情况下NameNode挂了整个HDFS的读写服务就中断了。虽然有SecondaryNameNode但它不是热备它只定期合并NameNode的日志无法接管服务。生产环境必须配置HA也就是跑两个NameNode用ZooKeeper做分布式协调监控主NameNode的状态。一旦主的挂了备用的NameNode自动切换接管服务整个集群感知不到明显中断。这里可以顺带引出Hadoop和ZooKeeper的关系Hadoop的HA依赖ZooKeeper做故障自动切换HBase的HMaster选举也依赖ZooKeeper所以在企业中搭建大数据平台ZooKeeper几乎是必装的组件。面试题二HDFS副本数为什么默认是3存储副本的本质是为了容错。副本数为1任何一台机器坏了数据就永久丢失副本数为2理论上有一定容错能力但如果坏两台中有一台是同一份数据的副本数据照样丢。副本数为4或5容错性更强但存储成本直接翻倍。3份是经过实践检验的平衡点——存储成本增加200%换来的是比较稳妥的容错能力加上上面提到的机架感知策略即使整个机架宕机数据依然安全。面试题三MapReduce的Shuffle过程说一下这个能考察求职者有没有真正研究过MR。要讲清楚四个阶段Map端输出先写入环形缓冲区默认大小100MB写入超过阈值后溢写到本地磁盘并做分区和排序Reduce端启动时从各个Map节点拉取属于自己的分区数据拉取的数据在Reduce端做合并和排序最后才进入Reduce函数处理。如果能再补一句“Shuffle是MR性能瓶颈的核心”面试官会认为你真的理解MR。面试题四为什么HDFS块大小不能太小这就回到我上面讲的原理。块太小寻址开销占比高NameNode元数据量大块太大单个Map任务处理时间长并行度低且任务失败重算的代价略高。所以128MB是一个经过实践平衡的参数。3.3 别焦虑Hadoop过时的问题我第一次接触Hadoop是2016年那时候Spark已经火了。后来Flink又火起来了越来越多新人问我Hadoop是不是要被淘汰了我的回答一直是你看到的那些大数据技术栈几乎全都跑在Hadoop生态之上。Hive跑在有HDFS和YARN的集群上Spark也是Flink也可以。数据永远放在HDFS里资源永远由YARN统一调度。Hadoop的核心价值在于提供了一个稳定的大数据底座而Spark和Flink是跑在底座上的高性能引擎。你可以把Hadoop理解为操作系统Spark和Flink是应用程序操作系统会被很快抛弃吗不会。所以新手的学习路线我建议这样走先死磕HDFS和MapReduce理解分布式存储和分布式计算的本质然后学Hive用SQL的方式操作HDFS数据下一步学Spark理解它和MapReduce在计算模型上的差异如果处理实时需求学Flink。整个过程最好配合实践只看书不敲命令是学不会的睡觉都能梦见NameNode。4. 动手之前先看懂部署方式和一些必踩的坑4.1 三种部署模式怎么选Hadoop有三种部署模式网上教程很多但很多人搞不清区别导致照着教程搭完之后还是一头雾水。本地模式。所有组件跑在单个Java进程中不用HDFS直接访问本地文件系统。一般用于开发调试和跑MapReduce测试。新手学MapReduce时本地模式单测是最快的上手方式比如在IDE里直接跑一个WordCount几秒钟就能看到输出。伪分布式模式。一台机器上模拟完整的Hadoop运行环境多个进程分别扮演不同角色。关键配置是HDFS的复制因子设为1YARN也在这台机器上启动ResourceManager和NodeManager。伪分布式适合学习和开发验证能让你在一台笔记本上体验完整的“提交作业、调度、执行”流程但完全没有高可用和性能可言。完全分布式模式。生产环境的标准至少三台机器起步NameNode与DataNode分机部署也可以配置HA提高可靠性。实际生产集群少则几十台多则上千台。如果你只是学习先搭伪分布式就够了不要直接上三台服务器操心网卡、磁盘、内核参数反而会分散学习精力。等伪分布式玩熟了再考虑用多台虚拟机搭一个三节点完全分布式集群。4.2 用Docker快速体验是我推荐的一条捷径我得先感谢Docker它把Hadoop的学习门槛拉低了一大截。以前我学习时配环境要折腾一天现在一条命令就能启动一个单节点Hadoop。常见做法是找一个现成的Hadoop单机镜像比如sequenceiq/hadoop-docker这类社区镜像启动容器后进入里面直接使用HDFS命令和MapReduce命令。端口方面NameNode的Web UI默认在50070端口新版在9870ResourceManager在8088端口需要映射到宿主机。数据目录建议用docker -v挂载一个宿主机目录否则容器一删数据全没了。用Docker体验Hadoop时有个心理铺垫要做好Docker里跑的是单节点伪分布式NameNode和DataNode在同一台机器上它只用来练习命令和熟悉原理和生产集群差得很远但作为入门体验已经足够。如果你想练习多节点集群可以用Docker Compose定义多个容器模拟一台NameNode加两台DataNode不过这就是后话了。4.3 我当年踩过的坑提前帮你们排一排第一个坑是JVM内存不足。伪分布式下如果机器只有2G内存默认参数可能撑不住三个角色同时运行启动时直接报Java heap space。解决办法很简单在hadoop-env.sh里设置HADOOP_HEAPSIZE比如256MB别贪大。第二个坑是SSH免密没配好。完全分布式集群中NameNode需要通过SSH免密登录到DataNode来启动和停止进程。新手第一次配集群时经常在这里卡住启动DataNode时报错Permission denied。建议在搭建集群之前先把所有机器之间的SSH免密配好并测试通过不要配完了再排查。第三个坑也是出现频率最高的第二次格式化NameNode。很多人在启动失败后直接把dfs/name目录删了重新格式化。这是大忌因为格式化NameNode会生成一个新的clusterID而DataNode已经用旧的clusterID启动过了两边不一致DataNode会拒绝服务。正确的做法是只有第一次初始化时格式化之后如果要重置需要把NameNode和所有DataNode的数据目录全部清掉后重新格式化或者直接清空数据目录而不要动NameNode再做一次更新的格式化。拿不准的时候先想想两份元数据的clusterID这个思路能救很多次命。第四个坑是端口冲突或没开防火墙端口。NameNode RPC端口9000新版本是8020、NameNode Web UI端口9870、DataNode端口9864、ResourceManager Web UI端口8088这些端口容易和集群里其他应用冲突。在云服务器上跑集群的话安全组也要把这些端口放行不然从本机网页上访问不到管理界面会误以为服务没起来。第五个坑是小文件堆积。我见过有人把清洗后的明细数据不做合并直接丢进HDFS结果NameNode Web UI上显示文件数量几十万单个文件都不到1KBNameNode内存压力巨大。后来我养成了习惯凡是清洗结果能合并就合并输出控制HDFS里的小文件数量这个习惯救了我很多次。5. 关于这个系列我再说几句掏心窝的话写这一篇简介其实比我预想的花了更多心思。因为“简介”听起来简单但真正要把Hadoop的来龙去脉讲清楚、讲透又不变成百科搬运很难。我尽量把技术原理用生活化的比喻和真实场景串起来你如果读到这里说明已经对Hadoop有了一个整体的框架感。✅ 在后续的系列文章中我会逐步带你走一遍完整的实操流程。从HDFS命令行操作开始到上传文件、查看块分布到编写一个MapReduce程序并用三种模式跑通再到配置伪分布式、搭一个三节点的完全分布式集群然后深入Hive数据仓库、Hadoop与ZooKeeper的HA整合、Hadoop常用调优参数、面试高频题集Step by Step不是干讲概念而是边做边学遇到坑就记录下来给出排查思路。我个人在实际操作中的体会是Hadoop最难的地方不在技术本身而在抽象能力的建立。当你第一次在几台机器上成功跑通一个分布式单词计数看到一堆日志在屏幕上滚动作业进度从map 0%走到reduce 100%的时候那种“原来分布式是这个意思”的顿悟感是任何文档都给不了的。希望这个系列能成为你大数据路上的第一块垫脚石。