1. Hadoop到底解决了什么问题先聊一个很多初学者都会想的问题大数据到底“大”在哪为什么传统的MySQL、Oracle处理不了我给你打个比方。假设你开了一家小超市账本记在Excel里每天几千条交易记录用Excel的筛选和排序完全够用。突然有一天你开成了全国连锁每天的订单量变成几亿条Excel打开文件都要卡死五分钟这时候怎么办你需要的是一套能把这几亿条数据拆开、分给几千台机器同时处理的体系。Hadoop干的就是这件事。Hadoop最早源自Google发表的三篇论文分别是GFS分布式文件系统、MapReduce分布式计算模型和BigTable分布式列式存储Doug Cutting和Mike Cafarella参考这些思路实现了开源版本并以Doug儿子的一只玩具大象命名。这个名字的由来一直挺有意思所以Hadoop的Logo是一只黄色小象。从本质上讲Hadoop是一套生态体系解决的核心问题就三个海量数据的可靠存储原本单台机器存不下、怕丢失的数据分散存到成百上千台机器上而且每份数据自动保留多个副本。海量数据的分布式计算把一个大任务拆分成成千上万个小任务分发给多台机器并行处理再把结果汇总。资源的统一调度管理多套框架同时跑在一个集群上谁来管理CPU、内存怎么分、任务排队怎么排需要统一管家。这三个问题分别由HDFS、MapReduce/YARN来回答。而生态里其他的组件比如Hive、HBase、Zookeeper、Flume、Sqoop、Spark、Flink全部是围绕着这三个核心能力做延伸和补充。如果你只是想跑通一个Demo、交个课程设计那装个伪分布式就够了如果你想搭一个接近生产环境的集群那就要考虑资源规划、组件选型、高可用设计。这篇文章会从原理讲到实操从单体讲到集群尽量让你看完之后既能理解底层逻辑也能动手搭建。2. 核心组件逐个拆解HDFS、MapReduce、YARN2.1 HDFS数据是怎么被可靠地存下来的HDFS全称Hadoop Distributed File System是整个Hadoop生态的存储底座。它的设计思路是“把大文件切成小块分散存到多台机器每块存多份”。一个128MB的文件HDFS默认块大小是128MB在较早版本中是64MB文件会被切分成多个Block每个Block独立存储默认副本数是3。这意味着同一个Block的三个副本会分布在集群中不同的DataNode上任何一台机器挂了数据依然可以从另外两台读出来。HDFS集群由两类节点组成NameNode主节点负责管理文件系统的元数据也就是“目录结构、每个文件对应哪些Block、每个Block在哪些DataNode上”。NameNode不存实际数据只存“地图”。DataNode从节点真正存数据的地方负责Block的读写、复制和心跳上报。DataNode会定时向NameNode报告自己存了哪些Block、磁盘还剩多少空间。HDFS写入数据的流程值得细看。客户端要写一个文件时先向NameNode发起请求NameNode返回“你应该把第一个Block写到哪几个DataNode上”客户端拿到这个地址列表后把数据切块逐个发送。这里有一个关键机制叫Pipeline复制客户端把数据发给第一个DataNode第一个DataNode收到后转给第二个第二个转给第三个像一条流水线一样数据不是客户端复制三份分别发给三台机器而是串行转发这样能显著减轻客户端的网络压力。读数据时反过来客户端先问NameNode“我要读的这个文件包含哪些Block”拿到Block位置列表后直接去对应的DataNode读取如果某个DataNode挂了或网络慢会自动切换到另一个持有副本的节点。这里有一个细节HDFS会尽量让客户端读取“距离最近”的副本优先本机、同机架、再跨机架这个机制叫机架感知能大幅降低跨机架流量。关于HDFS你在搭建和使用中最常遇到的几个坑我提前说一下NameNode是单点默认配置下NameNode只有一个它挂了整个集群就不可用了。生产环境必须配置NameNode高可用HA用两个NameNode Zookeeper做故障自动切换。小文件问题HDFS对大量小文件很不友好。每个文件、每个Block的元数据都存在NameNode内存里如果存了一亿个小文件NameNode内存直接爆掉。解决办法是合并小文件或者用HBase这类适合大量小对象的存储方案。Block副本数不是越多越好副本数3是默认配置很多初学者喜欢改成4或者5觉得“更安全”。实际上副本越多写入开销和存储开销越大3份已经能保证绝大多数场景的容错性。只有数据极其重要且磁盘充足的场景才需要调高。2.2 MapReduce把大任务拆成小任务再合并MapReduce是一种编程模型理解它只需要掌握两个阶段Map映射和Reduce归约。Map阶段做的事情是把输入数据“拆开、整理成键值对”。比如你有一堆文本文件要统计每个单词出现了多少次Map阶段会把每个文件切分成一行一行再把每行拆成一个个单词每个单词输出一个word, 1这样的键值对。Reduce阶段做的事情是把相同key的值归拢起来求和最终输出word, totalCount。这里有个经典的中间过程叫Shuffle很多人学了几个月都说不清它到底干了什么。Shuffle发生在Map端输出之后、Reduce端输入之前核心工作有三件事对Map输出的键值对按key排序把相同key的数据分到同一个分区每个分区对应一个Reduce任务将分区后的数据通过网络传输到对应的Reduce节点。你可以把Shuffle理解成一个快递分拣中心每个Map任务像是各个区县的发货仓库先把包裹按目的地分类打包分区排序再由运输车队网络传输送往对应城市的处理中心Reduce任务。Shuffle的设计是否合理直接影响整个作业的执行效率MapReduce跑得慢很大一部分原因就出在Shuffle阶段的数据传输上。MapReduce的编程接口在Hadoop 2.x之后有些变化。老的写法是继承Mapper和Reducer类重写map和reduce方法新版本建议用新的MapReduce API通过job.setMapperClass()、job.setReducerClass()这种方式配置。但说句实在话现在直接用MapReduce写业务逻辑的场景已经很少了因为开发效率太低、调试太麻烦。大部分人要么用Hive写SQL要么用Spark写更高效的分布式计算任务。那为什么还要学MapReduce的原理两个原因。第一Hive底层跑的还是MapReduce你写一条SQLHive会帮你翻译成若干个MapReduce作业不懂底层原理你很难理解为什么一条简单的关联查询要跑十分钟。第二MapReduce体现的“分而治之”思想是整个分布式计算的通用范式搞懂了它后面学Spark、Flink都会轻松很多。2.3 YARN集群资源的统一调度器YARN的全称是Yet Another Resource Negotiator直译过来是“又一个资源协调者”。它解决的是“谁用多少资源、什么时候用”的问题。没有YARN之前Hadoop集群里的资源调度非常混乱MapReduce作业直接抢占集群资源多个作业同时跑的时候容易冲突。YARN出现之后把资源管理和作业调度彻底拆分核心组件有三个ResourceManagerRM集群的总管家只有一个负责接收作业请求、分配资源、监控所有NodeManager的状态。NodeManagerNM每个节点上的资源管理者负责管理当前节点的CPU、内存并定时向RM汇报。ApplicationMasterAM每个作业的“项目经理”作业启动时由RM在某个节点上创建一个AMAM负责为这个作业申请资源、跟踪任务进度、处理任务失败重试。举一个具体的例子你同时提交了一个Hive查询和一个Spark计算任务。RM会把这些任务放入队列根据配置的调度策略FIFO、容量调度器、公平调度器决定谁先执行、分配多少容器Container。每个Container就是一块资源CPU核数内存AM拿到Container后把具体任务分发到对应的NM上执行。任务执行完AM向RM注销释放资源。YARN的调度器有三种生产环境最常用的是容量调度器和公平调度器FIFO调度器先进先出简单粗暴按提交顺序执行前面的大任务不跑完后面的都等着适合单用户测试环境。容量调度器把集群资源划分成多个队列每个队列有资源上限队列之间互不抢占适合多团队共用一个集群的场景。公平调度器动态平衡各作业的资源短任务能快速拿到资源避免长时间等待。这里给个实用建议如果你们公司是多个业务线共用一套Hadoop集群一定不要用FIFO要用容量调度器并给每条业务线划分独立队列否则一个跑全量数据的任务能把整个集群的资源吃光其他业务全被堵死。3. 从伪分布式到集群部署动手搭建Hadoop3.1 环境准备JDK版本与操作系统选择动手搭建之前先把环境说清楚。Hadoop是基于Java开发的所以第一件事是安装JDK。这里有个关键点Hadoop各版本对JDK版本有严格要求。以Apache Hadoop 3.x为例支持JDK 8和JDK 113.3.x开始支持JDK 11但业界用JDK 8的最多因为最稳定、踩坑资料最全。千万不要用JDK 17以上版本去跑Hadoop大概率会遇到各种莫名其妙的兼容性问题。操作系统方面最常见的搭配是CentOS 7/Ubuntu Server作为服务器Windows上通过WSL或者虚拟机的方式来做单机练习。我个人建议你直接装一个Ubuntu Server虚拟机练习一次性把Linux基础、SSH配置、环境变量这些常用的运维技能全练了。还有个细节是SSH免密登录。Hadoop集群启动时主节点要通过SSH登录到各从节点执行命令如果不配置免密每次启动都要输入密码集群根本没法自动管理。配置方法是把主节点的公钥分发到所有从节点的authorized_keys文件里这一步在伪分布式模式下同样需要因为伪分布式是“本机模拟多节点”NameNode还是要通过SSH登录localhost启动DataNode。3.2 伪分布式搭建最快跑通Hadoop的方式伪分布式英文叫Pseudo-Distributed Mode意思是“一台机器模拟一个集群”。在这个模式下HDFS的NameNode和DataNode跑在同一台机器上YARN的ResourceManager和NodeManager也在同一台机器上。虽然物理上只有一台机器但完整的分布式逻辑都跑起来了非常适合学习、开发和测试。搭建步骤大致如下第一步创建Hadoop用户并配置SSH免密生产环境不建议用root用户直接跑Hadoop创建一个专用用户是惯例做法useradd -m hadoop passwd hadoop su - hadoop ssh-keygen -t rsa -P -f ~/.ssh/id_rsa cat ~/.ssh/id_rsa.pub ~/.ssh/authorized_keys chmod 600 ~/.ssh/authorized_keys ssh localhost执行ssh localhost能直接登录不要求输密码说明免密配置成功。第二步下载并解压Hadoop从Apache官网下载稳定版比如hadoop-3.3.6.tar.gz解压到指定目录tar -zxvf hadoop-3.3.6.tar.gz -C /opt/ mv /opt/hadoop-3.3.6 /opt/hadoop chown -R hadoop:hadoop /opt/hadoop第三步配置环境变量在~/.bashrc中添加export HADOOP_HOME/opt/hadoop export PATH$PATH:$HADOOP_HOME/bin:$HADOOP_HOME/sbin export JAVA_HOME/usr/lib/jvm/java-8-openjdk-amd64配置完执行source ~/.bashrc让它生效。第四步修改五个核心配置文件这是整个搭建过程里最关键的环节所有的细节都在这里core-site.xml中设置HDFS的访问入口configuration property namefs.defaultFS/name valuehdfs://localhost:9000/value /property property namehadoop.tmp.dir/name value/opt/hadoop/tmp/value /property /configurationhdfs-site.xml中设置副本数和NameNode端口configuration property namedfs.replication/name value1/value /property property namedfs.namenode.name.dir/name value/opt/hadoop/namenode/value /property property namedfs.datanode.data.dir/name value/opt/hadoop/datanode/value /property /configuration注意伪分布式下副本数必须设为1因为只有一个DataNode副本数为3时会一直报块不足的错误。这个坑我在教学时见过无数人踩。mapred-site.xmlconfiguration property namemapreduce.framework.name/name valueyarn/value /property /configurationyarn-site.xmlconfiguration property nameyarn.nodemanager.aux-services/name valuemapreduce_shuffle/value /property /configuration第五步格式化NameNode首次启动之前必须执行格式化操作hdfs namenode -format这一步会在NameNode的目录下创建元数据的初始镜像。格式化是一个“一次性”操作以后重装或元数据损坏时才需要再做。切记不要每次启动都格式化格式化等于把文件系统清空重来我见过不少新手因为启动报错就重新格式化结果原本的数据全部丢失只能从头再来。第六步启动集群start-dfs.sh start-yarn.sh启动完成用jps命令检查能看到NameNode、DataNode、ResourceManager、NodeManager四个进程说明伪分布式搭建成功。3.3 集群部署的几个关键策略如果要做真集群先把核心原则讲清楚主节点和从节点的角色分离。一个最小的高可用集群至少需要三台机器。角色规划建议如下两台Master节点一台跑NameNode ResourceManager另一台跑备用的NameNodeQJM方式和ResourceManager这样主节点挂了能自动切换。三台及以上Worker节点全部跑DataNode NodeManager。在集群部署时还要决策几个问题副本放置策略Hadoop默认的机架感知策略是第一个副本放在客户端所在节点如果客户端不在集群中则随机第二个副本放在与第一个不同的机架第三个副本与第二个同机架、不同节点。这样的放置方式兼顾了容错性和写入效率。如果是三副本、两个机架的架构任意一个机架整个挂掉数据依然可读。配置分发策略集群里每台机器的Hadoop配置必须完全一致。实际操作中一般先在Master上配置好再用scp命令把整个配置目录分发到各从节点。我自己习惯写一个简单的分发脚本避免一台台手动拷贝时出现配置不一致的隐患。磁盘规划DataNode的存储目录可以配置多个比如property namedfs.datanode.data.dir/name value/data1/hdfs,/data2/hdfs,/data3/hdfs/value /property数据会在多个目录间均衡存放。建议把每块物理磁盘单独挂载目录不要用RAID做阵列因为HDFS本身就有一份数据三副本的冗余机制不需要RAID来保证数据安全RAID反而会降低磁盘利用率和写入性能。这算是Hadoop集群部署里一个不太容易意识到、但很重要的存储规划原则。端口规划如果服务器上有防火墙需要放行以下几个常用端口端口用途9870NameNode Web UIHadoop 3.x8088YARN ResourceManager Web UI9000HDFS客户端访问端口8020NameNode RPC端口HA模式9864DataNode数据传输端口3.4 用Docker跑Hadoop集群很多人在自己电脑上想搭一套测试集群但机器配置不够装虚拟机太费资源。用Docker是一个非常好的替代方案。我做过的做法是写一个Dockerfile基于CentOS镜像安装JDK和Hadoop然后通过docker-compose.yml编排三个容器一个主节点、两个从节点容器之间用hostname互相通信。关键点有三个主容器要以特权模式启动因为HDFS格式化、挂载目录这些操作涉及权限容器间通信要通过自定义网络并给每个容器固定IP数据目录要挂载到宿主机否则容器销毁后数据全没了。Docker方式最大的优势是环境隔离、快速重建非常适合课程设计、实验验证和CI/CD集成测试。我自己的做法一般是在Docker里跑通整个Hadoop集群严格验证无误后再把同样的步骤放到真实服务器上执行省去大量环境调试时间。4. 生态组件实战Hive、HBase、Zookeeper与数据采集4.1 Hive用SQL操作HDFSHive解决的核心痛点是MapReduce的Java编程门槛太高大部分数据分析师和业务人员只会写SQL。Hive把SQL翻译成MapReduce作业让用户“用SQL的方式操作HDFS上的数据”。Hive的关键概念有三个表Table逻辑概念对应HDFS上的一个目录。Hive的表分为内部表和外部表。内部表的数据由Hive管理删除表数据一起删外部表的数据由外部系统管理Hive只记录元数据删除表不影响数据。生产环境中强烈建议使用外部表否则误删一张表可能导致底层数据全部丢失。分区Partition根据某个字段比如日期把表的数据拆成多个子目录查询时只扫描需要的分区能大幅减少扫描量。分桶Bucket在分区的基础上进一步对数据做哈希散列主要用于抽样查询和MapJoin优化。Hive的元数据存放在哪里默认是用内置的Derby数据库但这个只支持单会话多人同时用会报锁冲突。任何正式一点的场景都要把元数据切换到MySQLCREATE DATABASE hive_metastore CHARACTER SET utf8mb4; CREATE USER hive% IDENTIFIED BY Hive123; GRANT ALL PRIVILEGES ON hive_metastore.* TO hive%; FLUSH PRIVILEGES;然后在hive-site.xml中配置MySQL连接地址、驱动类、用户名密码。这一步是Hive部署中最容易出错的环节常见问题是MySQL 8的驱动版本不匹配、时区参数缺失。建议用MySQL 5.7配合mysql-connector-java-5.1.x的驱动最省心。再讲一个实际生产中很实用的Hive调优点小文件合并。如果你的数据源每天产生几万个小文件Hive查询时会启动大量Map任务去读取每个Map任务读一个文件启动开销远大于计算开销。解决方式是在写入Hive表后执行INSERT OVERWRITE TABLE target_table SELECT * FROM source_table DISTRIBUTE BY FLOOR(RAND()*10);DISTRIBUTE BY的作用是把数据重新分布到指定数量的文件中。如果要做精细控制可以让大写字段的值参与分布配和适当的Reduce数量把输出文件数控制在一个合理的范围内一般每个文件128MB左右。4.2 HBase面向海量数据的实时读写HDFS能存海量数据但是它的读写延迟是秒级的不适合实时查询。HBase就是为了解决“海量数据实时随机读写”而出现的列式存储数据库。HBase的数据模型可以理解为“一个稀疏的、多维度的Map”。每一行数据有一个行键RowKey每个字段可以有任意多个列族Column Family列族下可以有任意多个列限定符Column Qualifier。查询的时候只需要指定RowKey就能在毫秒级返回整行数据。HBase为什么快核心机制是LSM树Log-Structured Merge Tree。写入的数据先写到内存中的MemStore达到一定大小后批量刷写到磁盘生成HFile这个过程是顺序写入速度极快。读取时先查MemStore、再查BlockCache、最后查HFile配合布隆过滤器快速定位数据是否存在省去了大量磁盘IO。HBase和HDFS的关系是HBase依赖HDFS做最终的数据存储自己负责索引、分区、缓存和并发控制。RowKey的设计是HBase用的最核心的技巧避免热点如果RowKey是自增ID写入会全部集中在同一个Region上。常见的解法是加盐salting比如rowKey 反向ID 随机前缀。保证顺序查询范围内数据按RowKey字典序排列所以设计RowKey时要尽量让相关数据在物理上相邻比如时间戳反转存储让最新的数据排在前面。4.3 Zookeeper分布式协调的中枢Zookeeper在整个Hadoop生态中承担的核心角色是领导者选举、配置维护、分布式锁。HDFS的NameNode高可用、YARN的ResourceManager高可用、HBase的HMaster高可用、Kafka的Controller选举全部依赖Zookeeper。它自己的机制也很经典多个节点通过ZAB协议Zookeeper Atomic Broadcast选出一个LeaderLeader负责处理写入请求Follower负责读请求过半投票机制保证了只要超过一半的节点存活集群就能正常工作。搭建Zookeeper集群至少要三台机器奇数台核心配置就一段tickTime2000 initLimit10 syncLimit5 dataDir/data/zookeeper clientPort2181 server.1zk1:2888:3888 server.2zk2:2888:3888 server.3zk3:2888:38882181是客户端连接端口2888是集群内部通信端口3888是选举端口。还要在dataDir目录下创建一个名为myid的文件里面写当前节点的编号1、2、3Zookeeper就是靠这个文件识别各节点身份的。有个细节值得注意启动顺序。三个节点要互相能连通的情况下先启动第一个再启动第二个再启动第三个。如果第一个启动后长时间收不到其他节点的投票信息卡住不要慌等另外两个也启动后选举会自动完成。4.4 Flume和Sqoop数据进出管道Flume负责“数据进来”主要做日志采集。它可以监听一个目录、一个端口或者Kafka主题把数据源源不断地写入HDFS、HBase或Kafka。Flume的架构是Source数据源→Channel缓冲通道→Sink输出目标比如最常见的日志采集配置agent.sources tailSrc agent.channels memChannel agent.sinks hdfsSink agent.sources.tailSrc.type taildir agent.sources.tailSrc.filegroups f1 agent.sources.tailSrc.filegroups.f1 /var/log/app/.*\.log agent.sources.tailSrc.channels memChannel agent.channels.memChannel.type memory agent.channels.memChannel.capacity 10000 agent.sinks.hdfsSink.type hdfs agent.sinks.hdfsSink.hdfs.path /data/logs/%Y%m%d agent.sinks.hdfsSink.hdfs.filePrefix app_log agent.sinks.hdfsSink.channels memChannelSqoop则相反负责把数据从关系型数据库MySQL、Oracle、PostgreSQL导入导出HDFS。一条典型的导入命令sqoop import \ --connect jdbc:mysql://localhost:3306/shop \ --username root --password 123456 \ --table orders \ --target-dir /data/orders \ --m 4-m 4表示启动4个Map任务并行导入注意不要设置太大否则会给源数据库造成额外压力。全量导入用Sqoop增量数据同步更推荐用Canal监听MySQL的binlog这个后面有机会展开。5. 从Hadoop到Spark/Flink生态迭代与选型5.1 Spark为什么能替代MapReduceMapReduce的硬伤是中间结果必须落盘。每个Map任务输出的数据要写到磁盘Reduce任务再从磁盘读取对于迭代式算法比如机器学习里的梯度下降、PageRank这种需要反复扫描同一份数据的计算每次都落盘就意味着数十倍的磁盘IO和时间浪费。Spark的核心创新是基于内存的分布式计算它把数据放到RDD弹性分布式数据集中可以对数据执行多次操作而不用反复读写磁盘。同样是WordCountMapReduce可能要跑几十秒Spark只要几秒。在Spark-SQL上跑同样的查询在集群规模不大的情况下能比Hive快5~10倍。5.2 Flink与Spark的侧重点Flink和Spark经常被放在一起比较。简单区分Spark擅长批量处理和微批处理Flink擅长真正的流式处理。Spark Streaming的本质是“把流切成一个个小批次”每个批次之间有一点延迟Flink是逐条处理数据事件能够做到毫秒级延迟还支持精确一次Exactly-Once的语义保证。所以在实时数仓场景中Flink成了事实标准。常见的架构是Flink从Kafka消费实时数据经过清洗后写入HBase或Kafka供实时报表查询同时同一份数据还会以批量方式进入Hadoop数仓供T1的离线分析使用这就是业内常说的Lambda架构。5.3 怎么选型一张表说清楚场景推荐方案原因海量离线数据清洗、报表Hive on Spark / Spark SQLSQL门槛低、生态成熟实时日志分析、风控预警Flink Kafka毫秒级延迟、精确一次语义海量数据实时点查HBase基于RowKey查询毫秒级返回数据仓库存储层HDFS / Hive数仓成本低、可靠、支持超大文件元数据管理Hive Metastore Atlas血缘追踪、数据治理调度编排Azkaban / DolphinScheduler任务依赖、周期调度、告警选型的核心原则是用合适的工具做合适的事不要为了新而新。很多传统企业的数仓到现在还是Hive MapReduce跑得好好的没必要为了炫技强行引入Flink。6. 遇到的坑和排查思路6.1 HDFS频繁出现“No space left on device”这个报错有几种可能性不只是磁盘满了这么简单。最容易被忽略的是inode耗尽。HDFS的Block数量达到上限时会报这个错即使磁盘还有大量剩余空间。检查方法是用hdfs dfsadmin -report查看Block数量和磁盘使用情况用df -i检查各节点磁盘inode是否耗尽用hdfs dfs -count /找出哪个目录下的小文件数量最多。解决思路是清理过期临时文件、合并小文件、调大dfs.namenode.fs-limits.max-blocks-per-file等限制参数。6.2 YARN任务卡在ACCEPTED状态不动新提交的任务一直显示ACCEPTED不进入RUNNING最常见的原因是可用内存不足。检查YARN的ResourceManager Web UI看看每个节点剩余内存是多少。如果一个NodeManager配了8GB内存很可能会因为基础系统占用了大半YARN可分配内存被卡得特别少而作业默认申请的容器内存又比较大任务永远等不到足够的资源。解决办法是把yarn.nodemanager.resource.memory-mb调低一些或者把作业申请的容器规格调小。我见过很多新手说“我的集群明明有很多资源任务却一直不跑”基本都是这个原因。6.3 NameNode启动失败元数据损坏NameNode启动时报“Cannot determine directory”或者“Incorrect DFS version”通常是元数据目录损坏或者版本不匹配。如果是测试环境可以重新格式化NameNode如果是生产环境要用备份的fsimage和edits进行恢复。这里我要特别强调NameNode的元数据是整个Hadoop集群最珍贵的东西数据中心的机器挂了可以换磁盘坏了可以换但是元数据丢了等于所有数据变成了无法访问的裸块。所有生产集群必须配置NameNode高可用同时定期把fsimage备份到远端存储。6.4 伪分布式DataNode起不来伪分布式模式下DataNode启动失败是一个高频问题常见原因有两个第一次格式化后执行了多次格式化集群ID不一致DataNode与NameNode无法匹配。解决办法是删除dataDir下的所有内容重新格式化或者手动在VERSION文件中修改clusterID。/tmp目录权限不对。Hadoop默认把数据放在/tmp/hadoop-xxx目录下如果/tmp有清理策略或者权限不对DataNode会启动失败。建议在hdfs-site.xml中设置单独的目录比如我们自己规划到了/opt/hadoop/datanode。7. 面试和实际应用中常问的高频问题很多准备找大数据开发相关工作的人会问Hadoop到底要学到什么程度才能去面试我整理了面试中出现频率最高的一批问题你自己对照检查关于HDFSHDFS的读写流程是怎样的为什么Block默认是128MB为什么不是1KB或者1GB三副本放置策略是什么样的NameNode挂了怎么办为什么HDFS不适合存大量小文件关于MapReduceShuffle的全过程是怎样的Map阶段的输出结果为什么要有Combiner什么情况下没有Reduce阶段Map任务和Reduce任务的数量是怎么决定的关于YARN一个作业从提交到运行结束的完整流程三种调度器的区别Container是什么关于Hive内部表和外部表的区别为什么Hive查询很慢怎么解决数据倾斜分区和分桶的区别关于集群集群规模怎么估算一般按数据量1PB数据大约需要30~50台机器你们的集群多少个节点为什么这样规划数据量日增多少离线任务多久跑完面试官问这些问题的潜台词不是要你背答案而是验证你是否真的理解分布式系统的设计逻辑。比如“为什么Block是128MB”这个问题只要理解“减少磁盘寻道开销、让数据块大小与Map任务数匹配”就足够了。8. 学习路线建议怎么从零到能干活最后给一份我实践下来最合理的学习路线按照这个顺序大概一两个月就能从零到能跑一个完整的离线数仓项目。第一阶段打基础1~2周Linux常用命令、Shell基础、SSH无密登录掌握JDK环境配置理解环境变量的作用会写简单的Shell脚本交付部署任务。第二阶段把Hadoop跑起来1周在虚拟机或Docker中完成伪分布式搭建使用hdfs shell完成文件的上传、下载、删除、查看跑通一个自带的WordCount示例理解MapReduce的执行流程。第三阶段深入核心原理1周用Web UI观察HDFS和YARN的运行状态手动kill一个DataNode进程观察副本复制机制写一个自定义的MapReduce程序处理实际数据。第四阶段生态组件串联2周搭建Hive把MySQL作为元数据库学会用HiveSQL完成常规的ETL操作用Sqoop把MySQL数据导入Hive再通过Hive进行分析用Flume采集日志写入HDFS完成一条完整的数据管道理解Zookeeper的选举机制能搭一套三节点集群。第五阶段做一个小项目长期找一份公开数据集做一套完整的离线数仓流程数据采集Flume/Sqoop→ 数据存储HDFS→ 数据清洗Hive/SparkSQL→ 数据输出MySQL/BI可视化。比如网约车订单分析、电商用户行为分析这类题目网上能找到大量公开数据集把整个流程从零跑通比看书一个月都管用。在实际学习和面试的过程中我的体会是大多数人并不是被技术难倒的而是被“不知道下一步该学什么”拖住了。上面这条路线走一遍你会发现Hadoop生态这套东西其实没有想象中那么高深它的设计思想都是围绕着“怎么用一堆便宜的机器扛住海量数据”这个朴素的问题展开的。想明白这一点后面接触再多的新组件你都能做到触类旁通。