1. 分布式到底在解决什么问题：Hadoop就是在找这组答案
第一次接触Hadoop的人，最容易被一堆名词吓住：分布式、HDFS、MapReduce、YARN、Zookeeper……每个词单独看都认识，连在一起就懵了。我当初也是这样，花了两周时间在各种教程里打转，始终想不明白：这玩意儿到底解决了什么痛点？为什么非要绕这么大一个圈子去存数据、算数据？
先把这个根本问题掰开揉碎讲清楚。所谓分布式，本质上就是把一台机器干不完的活，拆给多台机器一起干。为什么一台机器干不完？因为数据量太大了。一台普通服务器的硬盘容量也就几TB到几十TB，可互联网公司一天产生的日志、用户行为数据可能就是几百GB甚至几个TB的量级，一周下来单机就装不下了。更麻烦的是，数据不只是要“存下来”，还要被分析和计算，单机的CPU、内存就那么多，你让一台机器去处理几个TB的数据，跑一个统计任务可能要十几个小时甚至直接内存溢出。
这就好比你开了一家小餐馆，生意好到一个人完全忙不过来：食材没地方放，炉灶只有一个，客人点单做不出来。这时候要么拒绝顾客，要么咬牙换更大的店面。可数据增长是没有止境的，换再大的店面总有一天还是不够。Hadoop给出的答案是：不换大店面，而是开连锁店——多开几家分店，每家店只处理一部分食材、只服务一部分客人，后厨之间再有个总管统一调度，告诉各家店谁做什么菜、做完的菜往哪儿送。
这里有个很多人一开始没绕过来的弯：分店越多，协调成本越高，搞不好比一家大店还慢。所以分布式不是简单地把数据散到多台机器上就完事了，它真正的难点在“协调”——怎么保证所有机器步调一致，怎么让一台机器挂了不影响整体运行，怎么让计算结果拼起来是完整且正确的。Hadoop的核心价值，恰恰就是把这套极其复杂的协调逻辑封装成了现成的框架，让普通工程师不需要自己处理多机通信、节点故障、数据分片这些底层难题，就能直接利用一群廉价机器完成海量数据的存储与计算。
正是基于这个背景，Apache基金会推出了Hadoop，它从诞生之日起就是奔着“用一堆便宜机器取代一台昂贵超级计算机”这个目标去的。后来的事实也证明，这个思路不仅可行，而且成了整个大数据生态的地基。今天大家常说的Hive、Spark、Flink、HBase，底层存储几乎都跑在HDFS上，离线批处理引擎MapReduce更是Hadoop原生自带，理解Hadoop就是在理解整个大数据技术栈共同的根。
对于一个正要入门分布式的人来说，我的建议是别急着装环境、跑代码，先建立三个基本认知：第一，单机有极限，数据增长没有极限，所以必须横向扩展；第二，横向扩展之后，核心矛盾从“算不快”变成“难协调”；第三，Hadoop就是为了把“难协调”这件事从你手里接管过去。有了这三点打底，后面的HDFS、MapReduce、YARN学起来就是顺理成章的事，而不是一个个孤立的技术名词了。
2. Hadoop三件套：HDFS、MapReduce、YARN各自干什么
搞清楚Hadoop要解决的核心问题之后，就可以正式认识它的三个核心组件了。很多教材喜欢一上来就列架构图、配置文件，我反而觉得应该先把“角色分工”弄清楚。Hadoop整个体系就像一个分工明确的企业：HDFS负责仓库管理，MapReduce负责生产加工，YARN负责车间调度和资源分配。三家各管一摊，又互相配合。
2.1 HDFS：把一份大文件切碎了散落在多台机器上
HDFS全称是Hadoop Distributed File System，中文就是Hadoop分布式文件系统。它的设计目标非常纯粹：在一个由普通服务器组成的集群上，可靠地存储超大文件。什么叫超大文件？单个文件达到GB级、TB级甚至PB级那种。普通文件系统（比如你电脑上的NTFS、ext4）在设计上根本没有考虑这种量级，单个文件最大就几个GB，而且文件一旦超出单块硬盘容量就束手无策了。
HDFS的解决办法很直接：把大文件切成一个个固定大小的块（Block），默认128MB一块，然后把这些块分散存储到集群中的不同机器上。比如一个1GB的文件，会被切成8个128MB的块，分别落到8台（甚至更多，因为有副本机制）不同的服务器上。读文件的时候，客户端只需要知道哪个块在哪台机器上，就可以并行地去各台机器读取，速度远快于单机顺序读。
为了保证数据不丢，HDFS还做了副本机制：每个块默认存3份，分布在不同的机器上。也就是说，上面那个1GB的文件实际占用3GB存储空间，但换来的是极高的容错能力——集群里随便挂两台机器，数据照样完整。这就像你把同一份重要档案复印了三份，分别锁在三个不同的保险柜里，烧掉一个柜子，另外两个还能给你拼出完整资料。
整个HDFS里有两种关键角色。一个叫NameNode，是“总管”，负责维护整个文件系统的目录结构，知道每个文件被切成多少块、每块存在哪几台机器上。它本身不存文件内容，只存“索引”，类似于图书馆的总书目。另一个叫DataNode，是“库管员”，真正保管数据块，机器上的硬盘里存的就是这些块。客户端要读文件，先问NameNode“这个文件的第X块在哪儿”，NameNode告诉它具体地址，客户端再直接去对应的DataNode取数据，取完再问下一个块的地址，直到整个文件拼齐。
这个设计的精妙之处在于：元数据和数据分离。NameNode管的东西“又小又关键”，DataNode管的东西“又大又普通”，哪怕某个DataNode整个挂了，NameNode只需要把原来存在它上面的块的副本地址更新一下，系统照常运行。
2.2 MapReduce：把复杂的计算拆成“分而治之”两步走
有了HDFS把数据存好，接下来自然要问：数据怎么算？如果你还是把几个TB的数据拉回一台机器算，那分布式存储就没有意义了。MapReduce的核心理念是：计算向数据移动，而不是数据向计算移动。也就是说，框架把计算任务派到数据所在的机器上就地执行，每台机器只处理自己本地的数据切片，最后再把各台机器的结果汇总。
MapReduce的计算模型只有两个阶段：Map（映射）和Reduce（归约）。Map阶段做的事是把一批杂乱数据整理成“键值对”的形式，比如统计一篇文档里每个单词出现了几次，Map阶段就是把文档拆成一个一个单词，每个单词输出一条<word, 1>的记录。Reduce阶段做的事是把Map阶段产出的结果按键合并统计，比如把所有<word, 1>记录按单词分组，累加出每个单词的总次数。整个过程就是标准的“分而治之”：先分头处理再汇总归并。
用生活化的例子理解：假设要统计全国每个城市的奶茶店数量，MapReduce的做法是派一群调查员分头去每个城市，各城市的调查员数出自己城市的奶茶店数量（Map），然后再把所有城市的统计结果汇总到一张总表上（Reduce）。每个调查员只跑一个城市，互相不干扰，最终汇总的工作量很小。
但MapReduce之间在两个阶段中间夹着一个隐形的“桥梁”——Shuffle（洗牌）过程。Map阶段产出的数据不能直接进Reduce，必须按key排序并分组，把所有同一个key的值都路由到同一个Reducer那里去。这个Shuffle过程是MapReduce里最复杂、也最影响性能的环节。不少初学者以为MapReduce就两个函数，实际生产环境里作业慢，往往就慢在Shuffle上——跨机器的数据拷贝、排序、分组，每一步都有开销。
2.3 YARN：统一调度计算资源的大管家
MapReduce要做计算，得有人给它分配CPU、内存、磁盘资源，这个问题在Hadoop早期版本里是由MapReduce自己包揽的，结果是“又当裁判又当运动员”，资源利用率低，还不好管理。后来Hadoop把资源管理和作业调度这块独立了出来，这就是YARN。
YARN的角色划分同样清晰：ResourceManager是全局大管家，管着整个集群的资源账本；NodeManager是每台机器上的小管家，监控本机资源并上报；ApplicationMaster是每个作业的“监工”，负责跟ResourceManager申请资源，再指挥分配到的容器去执行具体的Map或Reduce任务。
这个架构最大的好处是通用性。YARN不关心你是不是MapReduce作业，只要你按它的接口规范申请资源，任何计算框架都能跑在上面，Spark、Flink都可以把YARN当底座。Hadoop从2.x版本开始，默认就是这个“HDFS存数据、YARN分资源、MapReduce算数据”的三层架构。
这三者的关系可以类比成一家餐饮连锁集团：HDFS是中央冷库（食材分散储存在各分店冷库），MapReduce是后厨团队（各分店现场加工），YARN是中央调度中心（决定哪个分店有多少厨师、多少灶台去做哪批订单）。缺了任何一个，整套体系都转不起来。
3. HDFS读写机制：把“大文件切块分散存”讲透
前面说HDFS把文件切成128MB的块分散存储，听起来很简单，可一旦落到具体的读写流程上，不少细节就会让初学者犯晕：客户端是怎么知道去哪台机器读数据的？写文件的时候为什么还要跟NameNode反复确认？副本是怎么选择存储位置的？这一节我们沿着一条完整的读写链路，把问题一个个解开。
先说大体脉络。HDFS的写流程是：客户端先跟NameNode打招呼，说“我要创建/opt/logs/access.log这个文件，大小大概几百MB”，NameNode检查目录和权限后同意创建，并在文件系统的元数据里登记一条记录。然后客户端开始把文件按128MB切块，每切好一块，就先问NameNode“这个块该写到哪三台机器上去”，NameNode根据机架感知策略返回一个DataNode列表，客户端再把这块数据按顺序推给第一个DataNode，由它负责把数据复制给第二个、第二个再复制给第三个——这就是流水线复制。数据写完后，客户端通知NameNode“这一块已提交”，接着切下一块，重复整个过程。全部块写完，NameNode把文件标记为“已关闭”，写流程结束。
读流程相对简单。客户端调Open接口打开文件，NameNode返回文件包含的所有块的分布列表（即每个块在哪些DataNode上），客户端根据这个列表直接跟对应DataNode建立连接，并行拉取每个块的数据，按顺序拼接成完整文件。因为各个块可以并行读取，所以文件越大、块越多，并行度越高，读取速度越快，这正是HDFS适合大文件的原因。
这里有一个面试里高频出现的细节：副本的放置策略。Hadoop 3.x默认的三副本策略是：第一个副本放在客户端本地的那个DataNode上（如果你在集群外提交，就随机选一个存储空间充足的节点），第二个副本放在跟第一个副本不同机架的某个节点上，第三个副本放在跟第二个副本同一个机架但不同节点的机器上。这样设计是为了在“数据可靠性”和“写性能”之间取平衡：同一机架内复制很便宜，跨机架复制虽然贵一些，但能保证某个机架整体故障时还有一个副本存活。你不需要死记这个策略，理解背后的权衡就够了——所有分布式系统的设计都在做这种折中。
再说一个HDFS新手最容易忽略的点：小文件问题。HDFS的块是128MB，可你要是硬往里塞一堆几KB的小文件，NameNode就得为每个文件维护一条元数据记录。一个几KB的文件和一个1GB的文件，在NameNode里占用元数据的内存开销差不多。集群里文件数一多，NameNode的内存就成了瓶颈，严重时整集群都没法正常服务。所以生产环境里一般会用SequenceFile将小文件合并成大文件，或者改用HBase这类针对小对象优化的存储方案。这个坑我见过不止一个团队踩过，数据量不大时看不出来，一旦文件数上了百万级，NameNode直接撑不住。
HDFS还有一个在入门阶段容易搞混的点：文件是不可修改的。你已经写入HDFS的一个文件内容，不能像普通文件系统那样在中间改几行。HDFS支持的操作是追加写（append）和删除/改名，不支持随机修改。这跟MapReduce“一次写入、多次读取”的批处理模型是配套的。你要是想做实时更新，得用到别的东西（比如HBase在HDFS之上做随机读写）。
最后说一个在Windows环境开发时极易中招的问题：HDFS文件权限和本机用户名不对应。你在Windows上用IDEA连接集群，客户端拿到的是Windows下你当前的用户名，比如Administrator或你的拼音名，而集群里HDFS目录归属的是hadoop用户。默认情况下，你没有权限写HDFS根目录。新手在这上面卡两三个小时很常见。最简单的解决办法是给HDFS根目录设置宽松权限，或者把客户端的HADOOP_USER_NAME环境变量指定为hadoop。但要注意这只是开发环境做法，生产环境可千万别这么放宽权限。
4. MapReduce的思维切换：移动计算比移动数据便宜得多
很多教程把MapReduce当成一个“写两个Java类的编程题”，教完WordCount就结束了。但真正理解MapReduce，最重要的不是那几个API怎么写，而是思维方式的转变——从“把数据拉回来算”变成“把计算送过去算”。这个思维听着简单，实际养成并不容易。
普通程序员的直觉是：数据在数据库里，我写一段SQL或代码，把数据读到内存里，执行逻辑，输出结果。这个过程隐含的假设是“数据到计算”。但在海量数据场景下，这个假设彻底失效。几个TB的数据通过网络传回一台机器，光是传输时间就是天文数字。而且你根本搬不动——没有哪台普通服务器的内存能一次性装下几个TB。
MapReduce反其道而行之：计算逻辑（也就是你的Map/Reduce函数）通常只有几十KB或者几MB，把这份“说明书”复制到集群里的一百台机器上，成本低得可以忽略。每台机器拿到说明书和数据切片后，只需要在自己本地完成Map阶段，产出中间结果，再通过网络把中间结果交给少数几台Reducer机器归并。也就是说，真正大规模跨机器的数据传输，只发生在Shuffle阶段，而且传输的是经过Map加工后的精简中间结果，不是原始数据。
举个例子你就明白了。假设有一个电商平台，HDFS里存着过去一年的订单记录，分布在200台机器上，每台机器存一部分。现在要算全站月度总销售额。如果按传统思路，需要把200台机器上的数据全部通过网络汇总到一台机器，再执行求和。而MapReduce是让每台机器各自算自己那部分数据里的月度销售额（Map），得出200份“每月销售小计”，然后再把这200份小计汇总成一份总表（Reduce）。网络传输的量从“全年订单原始数据”压缩成“一个月一行的小计结果”，数据量可能缩小成原来的千分之一甚至万分之一。
这种“移动计算”思想在后来的Spark、Flink里不但被继承，而且被推到了更极致——不只是把计算派到数据旁边，还尽可能让数据在内存里多轮复用，减少落盘次数。但万丈高楼平地起，MapReduce这套“分而治之、先Map后Reduce”的框架是所有分布式计算引擎的共同基因。
理解了这一层，再看MapReduce的那些“奇怪设计”就容易接受了。比如为什么Map阶段的输出要先写到本地磁盘而不是直接发给Reducer？因为Reducer可能有多个，Map输出的数据要按key划分成多个分区，每个分区对应一个Reducer，不落盘就得在内存里把所有分区都攒齐，这对内存是不小的压力。而且Map任务可能失败重跑，落盘的数据可以重复使用。这些设计在当年内存紧张、硬件可靠性低的年代都是合理权衡。
还有一个反直觉的地方值得讲：MapReduce对“迭代计算”极不友好。比如机器学习里常见的梯度下降，需要反复多轮迭代，每一轮都要用到上一轮的结果。在MapReduce里每轮迭代都是一次完整的作业——从HDFS读数据、Map、Shuffle、Reduce、写回HDFS，下一轮再从头读一遍。磁盘IO开销大得离谱。这也是Spark诞生的重要动机之一：Spark把中间结果尽量留内存，迭代速度能有数量级提升。所以别把MapReduce当万能药，它就是为“一次性的批处理”设计的，你手里的活儿要是迭代式的，换个引擎更合适。
学MapReduce的时候还有一个思维关口要过：别把每个Map任务想复杂了。Map任务之间是完全独立的，一个Map处理一行输入就产出一行输出，它不在乎前后行之间有什么上下文。这种设计让整个系统天然具备极强的并行能力，一百台机器可以同时跑一百个Map，谁也不用等谁。代价是写业务逻辑时你没法像写普通Java循环那样随心所欲地访问全局状态——一旦你在Map里用了可变静态变量，结果很可能乱掉。新手最容易在这里翻车，写出的MapReduce程序本地跑没问题，丢到集群上就结果错乱，多半就是没管住状态。
5. 从装环境到跑通第一个WordCount：版本选型、搭建流程、踩坑实录
聊完了原理，咱们来点实际的。初识Hadoop，不亲手跑一个WordCount，总觉得心里没底。可环境搭建这个环节，拦住了不知道多少人。我在教学和答疑中见过的典型问题包括：版本不匹配、环境变量配错、Java版本太新导致HDFS启动失败、Windows本机连不上Linux容器里的集群等等。这一节把我反复验证过的流程整理出来，照着做基本能一次跑通。
5.1 版本选型：先想清楚你学的是哪个Hadoop
打开Apache Hadoop下载页，你会发现有一大堆版本号，3.1.x、3.2.x、3.3.x、3.4.x都有。我的建议是：学习阶段选择一个相对成熟的3.3.x版本（比如3.3.4或3.3.6），而不是最新的3.4.x。原因很简单：3.3.x的生态兼容性最广，网上的教程、遇到的坑基本都覆盖齐全；而太新的版本，某些外围工具（比如IDE插件、第三方连接器）可能还没跟上。
JDK版本务必和Hadoop匹配。Hadoop 3.3.x官方要求Java 8或Java 11，我个人建议用Java 8（即JDK 1.8）。不是因为Java 11不好，而是大量老项目、教学示例、IDE插件默认都是基于Java 8编译的，换到11容易碰到莫名其妙的兼容问题。选手头工具宁可“落后”一个版本，也别把自己卡在一个孤立的最前沿。
还有一个新手常犯的错：直接下载Hadoop的Windows编译版，在Windows本地跑伪分布式。Hadoop官方并不提供Windows原生二进制包，社区编译的版本往往有各种兼容问题。入门阶段老老实实按Linux环境来，或者在Windows上用Docker跑Linux容器，别自己给自己上难度。
5.2 搭建流程：以Ubuntu上伪分布式模式为例
伪分布式（Pseudo-Distributed Mode）是指在一台Linux机器上同时模拟NameNode、DataNode、ResourceManager、NodeManager几个角色。配置信息量最小，又完整覆盖了启动、管理、验证的整个流程，最适合学习。操作步骤如下：
首先准备一个干净的Ubuntu系统（22.04 LTS即可），创建专门用户并配置SSH：
sudo useradd -m -s /bin/bash hadoop sudo passwd hadoop su - hadoop ssh-keygen -t rsa -P '' -f ~/.ssh/id_rsa cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys chmod 0600 ~/.ssh/authorized_keys ssh localhostSSH免密这一步，是为了让Hadoop脚本能顺畅地在各节点（哪怕是伪分布式里的本机）来回切换用户执行命令。当初我第一次搭的时候就是跳过了这一步，结果启动时一直报"Permission denied"，排查半天才发现不是权限问题，是SSH本身就要输密码。
接着安装JDK并配置环境变量。下载JDK 8的tar.gz包解压到/opt/java，然后在~/.bashrc里追加：
export JAVA_HOME=/opt/java/jdk1.8.0_xxx export PATH=$JAVA_HOME/bin:$PATH export HADOOP_HOME=/opt/hadoop-3.3.6 export PATH=$HADOOP_HOME/bin:$PATH export HADOOP_CONF_DIR=$HADOOP_HOME/etc/hadoop然后解压Hadoop到/opt目录，需要改的配置文件集中在$HADOOP_HOME/etc/hadoop/下。伪分布式模式只需要留意四个文件：
core-site.xml里设置NameNode地址和临时目录：
<configuration> <property> <name>fs.defaultFS</name> <value>hdfs://localhost:9000</value> </property> <property> <name>hadoop.tmp.dir</name> <value>/opt/hadoop-3.3.6/tmp</value> </property> </configuration>hdfs-site.xml里把副本数设为1：
<configuration> <property> <name>dfs.replication</name> <value>1</value> </property> </configuration>yarn-site.xml保持默认即可，主要确认yarn.resourcemanager.hostname不指向奇怪的地址。mapred-site.xml里指定用YARN来运行MapReduce任务：
<configuration> <property> <name>mapreduce.framework.name</name> <value>yarn</value> </property> </configuration>配置完成后的启动顺序有讲究：先格式化NameNode，再启动HDFS，再启动YARN。格式化命令是：
hdfs namenode -format start-dfs.sh start-yarn.sh格式化只是一次性的，千万别每次启动都格式化，否则NameNode的元数据会丢失，眼睁睁看着文件系统被重置，这是个特别经典的误操作。启动完成后用jps命令检查进程，正常的伪分布式应该能看到NameNode、DataNode、SecondaryNameNode、ResourceManager、NodeManager这五个进程。
5.3 第一个WordCount的完整验证链路
环境起来了，放一个经典WordCount进去验证。先在HDFS里建目录、传文件：
hdfs dfs -mkdir -p /input echo "hello hadoop hello world" | hdfs dfs -put - /input/test.txt hdfs dfs -cat /input/test.txt然后准备一个最简单的MapReduce作业。虽然Hadoop自带examples.jar，但新手最好从写代码开始理解两个函数的输入输出。Map类的核心逻辑是逐行拆分单词，输出<word, 1>；Reduce类把同一个单词的计数累加。整体代码结构就三块：Mapper类、Reducer类、main函数里配置Job。这里不贴完整代码，但三个关键点必须说透：Map输出的key/value类型要符合业务需求（统计词频就用Text和IntWritable）；Reduce输出的key/value类型就是最终结果文件的格式；main里要清楚指定输入输出路径，输出路径不能事先存在，否则作业直接报错。
提交命令：
hadoop jar /opt/hadoop-3.3.6/share/hadoop/mapreduce/hadoop-mapreduce-examples-3.3.6.jar wordcount /input /output跑完后的输出文件是/output/part-r-00000，用hdfs dfs -cat查看，能看到一个单词一行、后面跟着计数的结果。整个流程验证通过，说明你的Hadoop环境已经具备了存储（HDFS）和计算（MapReduce）的基本能力，下一步无论是上伪分布扩展成三节点集群，还是开始啃HDFS的Java API，都有清晰的起点可以继续。
5.4 常见安装坑的排查备忘
我自己反复搭过不下十次环境，下面这几个问题出现频率最高：
一是端口占用。NameNode默认监听9000或8020端口，ResourceManager默认8088端口（Web界面）。如果本机有别的东西占用了，启动日志会出现BindException。用netstat -tlnp | grep 9000查一下就能定位。
二是内存设置。老版本的Hadoop有默认的堆大小上限，新生代、老年代分配不合理会导致频繁Full GC甚至启动即退出。解决方法是修改$HADOOP_HOME/etc/hadoop/hadoop-env.sh里的HADOOP_HEAPSIZE，伪分布式机器给2GB到4GB就够用。
三是Windows下连集群报错。如果你是在Windows上用IDEA连Linux容器里跑着的Hadoop，除了前面提到的HADOOP_USER_NAME，还要注意把客户端的core-site.xml指向容器的IP而不是localhost，且必须确保Linux端的namenode端口对宿主机开放。
四是不要用root用户直接跑Hadoop。HDFS脚本对root用户的限制很严格，会直接拒绝启动。所以前面特意建议创建专用用户，这一步省不得。
6. 看完这一章之后：往集群、HA、生态方向怎么走
一篇“初识Hadoop”的文章，写到这儿其实刚好到了一个微妙的分岔口：原理懂了，环境跑通了，WordCount也出结果了，接下来往哪儿走？我根据自己的学习路径和带新人的经验，给你一条比较顺的路线参考，以及每个阶段应该重点解决的问题。
如果你还想继续深挖Hadoop本身，下一步应该做三件事。第一是把伪分布式升级成真正的三节点集群：一个节点当NameNode，两个节点当DataNode，同时把YARN的资源调度打开，体会数据分片在真实多机环境下的行为。这个过程会让你真正理解什么叫“数据本地性”（Data Locality），也会遇到SSH免密需要跨机器配置、DataNode之间需要互相通信等新问题。第二是学习高可用（HA）方案：用Zookeeper协调两个NameNode，解决单点故障问题。这是BAT大厂面试的高频考点，也是生产环境的标配。第三是接触HDFS的Java API，尝试自己写一个上传、下载、删除文件的工具类，把存储层的调用搞通透。
如果方向是“由Hadoop入门整个大数据生态”，那么建议的学习序列是：先学Hive，用类SQL的方式跑数仓任务，大大降低写MapReduce的痛苦；再学Spark，理解为什么它在迭代计算上全面碾压MapReduce；然后根据工作方向决定是学实时计算Flink，还是学列式存储HBase，又或是学调度框架如DolphinScheduler。你会发现这一路下来，处处都带着Hadoop的影子——Hive的表数据落在HDFS上，Spark可以跑在YARN上，HBase底层也依赖HDFS做持久化。地基打得越扎实，上面盖楼越顺手。
实际工作中还有一个容易被忽略的点：面试。如果你学完这章想去面大数据相关的岗位，第一轮的八股题基本绕不开这些：HDFS的副本放置策略是什么？MapReduce的Shuffle过程详细讲讲？NameNode挂了怎么办？YARN的调度器有哪几种，有什么区别？为什么说HDFS不适合存小文件？一篇“初识”文章写不到这么深，但这些问题全都在你接下来的学习路线上，提前列出来当路标，等你逐项打勾的时候，那种“从入门到从容”的感觉会非常具体。
回看我自己的学习过程，最大的体会是：Hadoop这套东西，看文档觉得名字又多又绕，上手跑通一个简单作业之后，再看架构图会发现每一条线都有了意义。初识的阶段不需要贪多，把存储、计算、调度三层各自解决的诉求记清楚，把一次WordCount从头到尾跑明白，你就已经越过了一座很高的山。剩下的路，是沿着山脊慢慢铺开的风景，走一步有一步的收获。
