1. 从零搭建Hadoop大数据平台核心原理与生产级部署实战大数据这个词喊了这么多年真正在企业里落地的时候绕不开的一个东西就是Hadoop。不管上层换什么计算引擎、换什么查询工具底层存储和资源调度大概率还是HDFS加YARN这套组合。很多刚接触的朋友会觉得Hadoop已经是老古董了但你去看看那些跑着几百台节点的生产集群核心架构依然是它。这篇文章我打算把Hadoop的工作原理、部署过程以及YARN资源管理器这三块内容串起来讲清楚从为什么这么设计到怎么装怎么配尽量把踩过的坑和实战经验都倒出来。如果你是一个刚接手大数据平台运维的工程师或者正在准备把公司业务从单机数据库往分布式平台迁移再或者你只是想把Hadoop这套东西真正搞明白而不是停留在知道有这个东西的层面那这篇内容应该能帮到你。我会从架构设计的底层逻辑讲起然后一步步走完部署流程最后重点拆解YARN的资源调度机制中间穿插大量实际运维中会遇到的问题和解决思路。2. Hadoop整体架构设计与核心组件拆解2.1 为什么需要Hadoop从单机瓶颈说起先聊一个最根本的问题为什么企业需要Hadoop假设你是一家电商公司的数据工程师每天产生的用户行为日志大概500GB订单数据200GB再加上各种埋点数据、服务端日志一天下来接近1TB。这些数据你要存下来还要能做分析。单台服务器能不能扛存储上一台机器插满硬盘也就几十TB而且没有冗余坏一块盘数据就没了。计算上单机CPU和内存有限处理1TB数据的聚合查询可能要跑几个小时。更关键的是当数据量增长到几十TB甚至PB级别的时候单机方案根本没有扩展的可能。Hadoop解决的就是这个问题。它的核心思路很朴素既然一台机器搞不定那就用一堆机器一起搞。但一堆机器一起搞说起来简单做起来要解决一系列问题——数据怎么分布到多台机器上某台机器挂了数据会不会丢多台机器之间怎么协调计算任务这些问题的答案就构成了Hadoop的核心架构。2.2 HDFS的架构逻辑一次写入多次读取的设计哲学HDFS是Hadoop的分布式文件系统它的设计假设非常明确一次写入、多次读取、超大文件、廉价硬件。这四个假设决定了它的所有架构选择。NameNode与DataNode的主从结构是HDFS最核心的设计。NameNode负责管理整个文件系统的元数据包括目录树、文件与数据块的映射关系、数据块与DataNode的映射关系。DataNode负责实际存储数据块。客户端要读一个文件先去问NameNode这个文件的数据块在哪几台机器上然后直接去对应的DataNode读数据。写文件的时候也是先问NameNode我该写到哪些DataNode上然后直接跟DataNode建立连接写数据。这个设计的好处是NameNode不需要参与实际的数据传输避免了单点瓶颈。但坏处也很明显NameNode成了整个集群的单点一旦挂了整个HDFS就不可用。所以生产环境必须做NameNode的高可用这个后面部署部分会详细讲。数据块机制是另一个关键设计。HDFS把文件切分成固定大小的数据块默认在Hadoop 2.x和3.x中都是128MB。为什么是128MB而不是更大或更小这背后有一个权衡块太小元数据量会暴增NameNode内存压力大块太大最后一个块可能浪费大量空间而且并行读取的粒度变粗。128MB是在当时硬件条件下算出来的一个平衡点——寻址时间约10ms磁盘传输速率约100MB/s为了让寻址时间只占传输时间的1%左右块大小大约就是100MB这个量级。副本机制保证了数据的可靠性。默认每个数据块存3份分布在不同的DataNode上。副本放置策略是第一份放在客户端所在的节点如果客户端在集群内第二份放在不同机架的某个节点第三份放在与第二份同机架但不同节点的位置。这个策略兼顾了可靠性和网络带宽——跨机架传输带宽有限所以只跨一次机架。2.3 MapReduce的计算模型移动计算而非移动数据MapReduce的核心思想是移动计算比移动数据更便宜。数据存在哪里就把计算任务调度到哪里去。这个理念在数据量大的时候尤其重要——1TB的数据跨网络传输可能要几十分钟但把计算程序分发到数据所在的节点只需要几秒钟。一个MapReduce作业分为Map阶段和Reduce阶段。Map阶段处理输入数据产生中间结果Reduce阶段对中间结果进行汇总。中间还有一个Shuffle阶段负责把Map的输出按照key分发到对应的Reduce任务。Shuffle是整个MapReduce中最复杂也最容易出问题的环节涉及大量的磁盘IO和网络传输。不过说实话现在直接用MapReduce写业务逻辑的场景已经很少了大部分时候我们用Spark、Flink或者Hive on Tez这些更上层的引擎。但理解MapReduce的模型依然重要因为YARN的资源调度模型、Hive的执行计划、Spark的Shuffle机制底层逻辑都跟MapReduce一脉相承。2.4 YARN的定位从计算框架到资源管理平台的进化Hadoop 1.0时代MapReduce既是计算框架又是资源管理器JobTracker既管资源又管任务调度压力非常大而且只能跑MapReduce一种计算框架。Hadoop 2.0引入YARN之后把资源管理和计算框架拆开了。YARN只负责管理集群的CPU、内存等资源具体跑什么计算框架它不管。这样一来MapReduce、Spark、Flink、Tez都可以跑在同一个YARN集群上共享资源。这个拆分是Hadoop发展史上最重要的架构演进之一。它让Hadoop从一个MapReduce专用平台变成了一个通用大数据操作系统。你可以把YARN理解成集群的操作系统——它管理硬件资源向上层应用提供资源分配服务至于上层应用是跑批处理、流计算还是交互式查询YARN不关心。3. 生产环境部署规划与实操全流程3.1 集群规划节点角色分配与硬件选型部署之前第一件事是规划。很多新手拿到几台机器就开始装装到一半发现角色分配不合理又得推倒重来。我建议在动手之前先把下面这张表填清楚。以一个中等规模的集群为例假设有6台服务器规划如下节点角色主机名示例内存CPU磁盘说明NameNode ResourceManagernode0164GB16核SSD 500GB SATA 4TB主节点元数据和资源调度NameNode(Standby) ResourceManager(Standby)node0264GB16核SSD 500GB SATA 4TB高可用备节点DataNode NodeManagernode03128GB32核SATA 12TB x 2工作节点DataNode NodeManagernode04128GB32核SATA 12TB x 2工作节点DataNode NodeManagernode05128GB32核SATA 12TB x 2工作节点DataNode NodeManagernode06128GB32核SATA 12TB x 2工作节点这里有几个规划要点值得展开说。主节点为什么用SSDNameNode的元数据操作对磁盘随机IO要求很高SSD能把元数据操作延迟降低一个数量级。工作节点为什么内存要大YARN的容器分配以内存为主要维度内存越大能同时跑的容器越多集群吞吐越高。磁盘为什么用两块12TB而不是一块24TBHDFS的DataNode可以配置多个数据目录多块盘可以并行读写提升IO吞吐。另外还有一个容易忽略的点机架感知。生产环境一定要配置机架感知否则HDFS的副本放置策略和YARN的容器分配策略都会退化成随机分配跨机架带宽会被打满。配置方式是在自定义的脚本中根据IP段返回机架信息然后在core-site.xml中通过net.topology.script.file.name指定脚本路径。3.2 基础环境准备从系统参数到免密登录操作系统层面的准备工作看起来琐碎但每一项没做好都可能导致后面集群跑不起来或者跑不稳。主机名和hosts解析是第一步。每台机器设置好主机名然后在所有节点的/etc/hosts中写入完整的映射关系。不要依赖DNS生产环境DNS出问题的时候你就知道hosts有多可靠了。关闭防火墙和SELinux。内网集群环境通常直接关闭防火墙用安全组或者网络ACL来控制访问。SELinux也建议关闭否则各种权限问题会让你怀疑人生。操作命令# 关闭防火墙 systemctl stop firewalld systemctl disable firewalld # 关闭SELinux setenforce 0 sed -i s/SELINUXenforcing/SELINUXdisabled/g /etc/selinux/config配置SSH免密登录。NameNode需要能免密SSH到所有DataNodeResourceManager需要能免密SSH到所有NodeManager。在node01上生成密钥对然后把公钥分发到所有节点ssh-keygen -t rsa -b 4096 -N -f ~/.ssh/id_rsa ssh-copy-id node01 ssh-copy-id node02 ssh-copy-id node03 # ... 其他节点系统参数调优。这部分是很多教程会忽略但生产环境必须做的。主要是调整文件句柄数和进程数限制以及一些内核参数# /etc/security/limits.conf 添加 * soft nofile 65536 * hard nofile 65536 * soft nproc 65536 * hard nproc 65536 # /etc/sysctl.conf 添加 vm.swappiness 1 net.core.somaxconn 32768 net.ipv4.tcp_tw_reuse 1vm.swappiness设为1是为了尽量避免内存交换Hadoop对内存延迟很敏感一旦发生swap性能会急剧下降。net.core.somaxconn调大是为了支持更多的并发连接。时间同步。集群内所有节点的时间必须同步否则会出现各种诡异的问题比如Kerberos认证失败、日志时间戳对不上导致排查困难。用chronyd或者ntpd都行确保所有节点跟同一个时间源同步。3.3 JDK安装与Hadoop部署包准备Hadoop 3.x要求JDK 8或JDK 11。生产环境建议用JDK 8兼容性最好。安装JDK没什么好说的解压、配置环境变量、验证版本。注意所有节点的JDK安装路径要一致否则后面配置起来很麻烦。Hadoop部署包从官方渠道获取下载binary版本即可不需要自己编译。下载后解压到统一路径比如/opt/hadoop。同样所有节点的路径要一致。3.4 核心配置文件逐项拆解Hadoop的配置文件都在$HADOOP_HOME/etc/hadoop/目录下需要修改的主要有这几个core-site.xml、hdfs-site.xml、yarn-site.xml、mapred-site.xml、workers。core-site.xml是全局配置最关键的几个参数configuration property namefs.defaultFS/name valuehdfs://mycluster/value /property property namehadoop.tmp.dir/name value/data/hadoop/tmp/value /property property nameha.zookeeper.quorum/name valuenode01:2181,node02:2181,node03:2181/value /property /configurationfs.defaultFS配成hdfs://mycluster而不是具体的主机名是因为我们后面要配NameNode高可用用nameservice ID来屏蔽具体的主节点。hadoop.tmp.dir一定要改到数据盘上默认的/tmp目录重启就没了而且空间可能不够。hdfs-site.xml是HDFS的核心配置configuration property namedfs.nameservices/name valuemycluster/value /property property namedfs.ha.namenodes.mycluster/name valuenn1,nn2/value /property property namedfs.namenode.rpc-address.mycluster.nn1/name valuenode01:8020/value /property property namedfs.namenode.rpc-address.mycluster.nn2/name valuenode02:8020/value /property property namedfs.namenode.shared.edits.dir/name valueqjournal://node01:8485;node02:8485;node03:8485/mycluster/value /property property namedfs.journalnode.edits.dir/name value/data/hadoop/journal/value /property property namedfs.ha.automatic-failover.enabled/name valuetrue/value /property property namedfs.client.failover.proxy.provider.mycluster/name valueorg.apache.hadoop.hdfs.server.namenode.ha.ConfiguredFailoverProxyProvider/value /property property namedfs.replication/name value3/value /property property namedfs.namenode.name.dir/name value/data/hadoop/namenode/value /property property namedfs.datanode.data.dir/name value/data1/hadoop/datanode,/data2/hadoop/datanode/value /property /configuration这里面的关键点是JournalNode集群。NameNode高可用依赖JournalNode来同步EditLog至少需要3个JournalNode节点奇数个跟ZooKeeper的原理一样。dfs.namenode.shared.edits.dir配置的就是JournalNode的地址列表。yarn-site.xml是YARN的核心配置这部分内容比较多我放到下一节专门讲。mapred-site.xml主要指定MapReduce运行在YARN上configuration property namemapreduce.framework.name/name valueyarn/value /property property nameyarn.app.mapreduce.am.env/name valueHADOOP_MAPRED_HOME/opt/hadoop/value /property property namemapreduce.map.env/name valueHADOOP_MAPRED_HOME/opt/hadoop/value /property property namemapreduce.reduce.env/name valueHADOOP_MAPRED_HOME/opt/hadoop/value /property /configuration后面三个环境变量配置是Hadoop 3.x的新要求不配的话MapReduce任务会找不到Hadoop类路径。workers文件列出所有DataNode和NodeManager节点的主机名每行一个。3.5 集群启动流程与验证配置分发到所有节点之后启动顺序很重要启动JournalNode在node01、node02、node03上执行hdfs --daemon start journalnode格式化NameNode在node01上执行hdfs namenode -format启动node01的NameNodehdfs --daemon start namenode同步node02的NameNode在node02上执行hdfs namenode -bootstrapStandby启动node02的NameNodehdfs --daemon start namenode启动ZKFC在node01和node02上执行hdfs --daemon start zkfc启动所有DataNode在node01上执行hdfs --workers --daemon start datanode启动YARN在node01上执行start-yarn.sh启动完成后用jps命令检查各节点的进程。NameNode节点应该有NameNode、ZKFC、JournalNodeDataNode节点应该有DataNode、NodeManager。然后通过Web UI验证NameNode的UI在http://node01:9870ResourceManager的UI在http://node01:8088。4. YARN资源管理器深度解析与调优4.1 YARN的核心组件与工作流程YARN的架构可以用一主多从加一个中间人来概括。ResourceManager是主负责整个集群的资源管理和分配。NodeManager是从运行在每个工作节点上负责管理单节点的资源。ApplicationMaster是中间人每个应用有一个负责跟ResourceManager申请资源跟NodeManager协调容器启动。一个作业提交到YARN的完整流程是这样的客户端向ResourceManager提交应用ResourceManager找到一个NodeManager启动ApplicationMaster。ApplicationMaster启动后向ResourceManager注册自己然后开始申请资源。ResourceManager以容器为单位分配资源ApplicationMaster拿到容器后通知对应的NodeManager启动任务。任务运行过程中ApplicationMaster持续监控状态任务完成后向ResourceManager注销并释放资源。这个流程中有几个关键概念需要理解清楚。容器是YARN的资源分配单位封装了CPU和内存资源。调度器决定了资源怎么分配YARN内置了三种调度器FIFO、Capacity和Fair。生产环境最常用的是Capacity调度器它支持多队列每个队列可以配置资源上限和下限适合多团队共享集群的场景。4.2 yarn-site.xml关键参数详解YARN的配置参数很多但真正影响集群性能和稳定性的就那么几个。我把最重要的列出来configuration property nameyarn.resourcemanager.hostname/name valuenode01/value /property property nameyarn.nodemanager.aux-services/name valuemapreduce_shuffle/value /property property nameyarn.nodemanager.resource.memory-mb/name value98304/value /property property nameyarn.nodemanager.resource.cpu-vcores/name value28/value /property property nameyarn.scheduler.minimum-allocation-mb/name value1024/value /property property nameyarn.scheduler.maximum-allocation-mb/name value32768/value /property property nameyarn.scheduler.minimum-allocation-vcores/name value1/value /property property nameyarn.scheduler.maximum-allocation-vcores/name value16/value /property property nameyarn.nodemanager.vmem-check-enabled/name valuefalse/value /property /configuration**yarn.nodemanager.resource.memory-mb**是最关键的参数之一。它决定了单个NodeManager能分配给容器的总内存。假设一台机器128GB内存操作系统和Hadoop守护进程占掉约20GB剩下约108GB。但不要全部分配给YARN留一些余量给系统缓存和其他进程。我一般设置为总内存的75%到80%128GB的机器设96GB左右比较稳妥。**yarn.nodemanager.resource.cpu-vcores**是CPU核心数。同样不要设成物理核心数因为系统本身也需要CPU。32核的机器设28到30比较合适。**yarn.nodemanager.vmem-check-enabled**建议设为false。虚拟内存检查在生产环境经常导致容器被误杀因为Java应用申请的虚拟内存往往远大于实际使用的物理内存。关掉这个检查可以避免很多莫名其妙的容器失败。4.3 容器资源计算与队列配置实战理解YARN的资源分配核心是理解容器内存的计算逻辑。假设yarn.scheduler.minimum-allocation-mb设为1024MB你提交一个ApplicationMaster需要1536MB内存YARN会把它向上取整到2048MB1024的整数倍。所以设置合理的minimum-allocation-mb很重要设太小会导致资源碎片化设太大会浪费内存。Capacity调度器的队列配置是生产环境必须掌握的技能。假设公司有三个团队数据仓库团队、实时计算团队、算法团队。集群总资源是4台工作节点每台96GB可分配内存总共384GB。可以这样配置property nameyarn.scheduler.capacity.root.queues/name valuewarehouse,realtime,algorithm/value /property property nameyarn.scheduler.capacity.root.warehouse.capacity/name value50/value /property property nameyarn.scheduler.capacity.root.realtime.capacity/name value30/value /property property nameyarn.scheduler.capacity.root.algorithm.capacity/name value20/value /property property nameyarn.scheduler.capacity.root.warehouse.maximum-capacity/name value70/value /propertycapacity是保证资源maximum-capacity是资源上限。数据仓库团队保证有50%的资源但空闲时可以弹性用到70%。这样既保证了各团队的基线资源又提高了整体利用率。4.4 YARN运维中的典型问题与排查思路YARN运维中最常见的问题就是容器被杀死。日志里看到Container killed by YARN for exceeding memory limits说明容器使用的内存超过了申请值。解决思路有两个一是调大容器的内存申请值二是排查应用本身是否有内存泄漏。我一般建议先调大申请值观察如果还是频繁被杀再深入排查应用代码。ApplicationMaster启动失败也是高频问题。常见原因包括队列资源不足、AM内存申请超过队列上限、节点本地磁盘空间不足。排查的时候先看ResourceManager日志找到具体的失败原因然后针对性解决。节点状态变为UNHEALTHY通常是因为磁盘空间不足。NodeManager会定期检查磁盘使用率超过yarn.nodemanager.disk-health-checker.max-disk-utilization-per-disk-percentage默认90%就会标记为不健康。这时候需要清理磁盘或者调整阈值。下面这张表整理了我遇到过的典型问题和处理方式问题现象可能原因排查方向解决方式容器被YARN杀死内存超限查看Container日志中的内存使用调大申请值或优化应用内存AM启动失败队列资源不足检查队列使用率和上限调整队列配置或等待资源释放节点UNHEALTHY磁盘使用率超阈值df -h检查磁盘清理磁盘或调整阈值任务长时间PENDING调度器资源不足查看RM UI的队列资源扩容或调整调度策略Shuffle失败网络或磁盘IO瓶颈检查NodeManager日志优化Shuffle参数或增加磁盘5. 集群日常运维要点与性能调优经验5.1 日常巡检清单与监控指标集群跑起来只是开始日常运维才是重头戏。我建议每天至少检查一次这几个方面NameNode的堆内存使用率、DataNode的磁盘使用率、YARN队列的资源使用率、各节点的负载情况。这些指标通过Web UI或者监控系统都能看到。NameNode的堆内存是最需要关注的指标。NameNode把所有元数据都放在内存里堆内存不够会导致NameNode响应变慢甚至OOM。一般来说每100万个文件块大约需要1GB堆内存。如果发现堆内存使用率持续超过80%就需要考虑调大堆内存或者增加NameNode的联邦配置。DataNode的磁盘使用率建议保持在70%以下。超过80%就要开始清理或者扩容了。HDFS的Balancer工具可以平衡各DataNode的磁盘使用率但Balancer本身会占用网络带宽建议在业务低峰期执行。5.2 性能调优的几个关键方向NameNode调优主要是JVM层面。-Xmx和-Xms设置成相同值避免堆动态调整一般设为物理内存的50%到60%。GC选择G1或者CMSHadoop 3.x默认用G1。dfs.namenode.handler.count控制NameNode的RPC处理线程数默认是10生产环境建议调到100以上。DataNode调优重点是磁盘IO。dfs.datanode.max.transfer.threads控制数据传输线程数默认4096一般够用。如果磁盘IO是瓶颈可以考虑增加数据目录数量让多块盘并行读写。YARN调优的核心是平衡资源利用率和任务等待时间。yarn.scheduler.minimum-allocation-mb设得太大会浪费资源设得太小会导致容器数量过多增加调度开销。我一般根据业务场景来定如果主要是大内存的Spark任务设2048或4096如果有很多小任务设1024。5.3 数据安全与权限管理生产环境必须配置权限管理。Hadoop支持两种认证方式Simple和Kerberos。Simple模式就是靠操作系统用户来认证安全性很低只适合测试环境。生产环境应该用Kerberos虽然配置复杂但安全性有保障。权限管理方面HDFS的文件权限模型跟Linux类似有owner、group、other三级权限。可以通过hdfs dfs -chmod和hdfs dfs -chown来修改。另外还有ACL访问控制列表可以实现更细粒度的权限控制。注意开启Kerberos之后所有跟Hadoop交互的客户端都需要配置Kerberos认证包括Hive、Spark、Flink等。部署之前一定要规划好principal和keytab的管理方案否则后期维护会很痛苦。5.4 常见故障恢复场景NameNode故障是最严重的场景。如果配置了高可用主NameNode挂了会自动切换到备NameNode业务基本无感知。如果没有配高可用那就只能从SecondaryNameNode恢复但会丢失最近一段时间的数据。所以生产环境强烈建议配置NameNode高可用。DataNode故障相对常见一块盘坏了或者一台机器宕机。只要副本数足够HDFS会自动从其他副本恢复数据。运维人员需要做的是尽快修复故障节点让DataNode重新上线然后触发数据平衡。ResourceManager故障同样建议配置高可用。YARN的ResourceManager高可用依赖ZooKeeper做选举配置方式跟NameNode高可用类似。6. 个人实操经验与避坑建议部署Hadoop集群这些年踩过的坑确实不少。说几个印象深刻的。第一个坑是主机名解析。有一次部署的时候偷懒没配hosts直接用IP地址配的。结果跑了一段时间之后某台机器的IP变了DHCP租约到期整个集群的配置全乱了。从那以后我坚持所有节点必须配静态IP加hosts解析绝不用IP直接配。第二个坑是磁盘挂载点。Hadoop默认用/tmp存临时数据而/tmp通常在系统盘上空间很小。有一次跑一个大作业临时数据把系统盘写满了导致整个节点不可用。后来我把所有Hadoop相关的目录都配到了数据盘上包括hadoop.tmp.dir、dfs.namenode.name.dir、dfs.datanode.data.dir、yarn.nodemanager.local-dirs和yarn.nodemanager.log-dirs。第三个坑是YARN的内存配置。刚开始的时候把yarn.nodemanager.resource.memory-mb设成了物理内存的全量结果NodeManager自己加上系统进程把内存吃满了机器开始swap性能急剧下降。后来改成物理内存的75%左右稳定多了。第四个坑是日志管理。Hadoop的日志量很大如果不做轮转和清理磁盘很快就会被日志写满。我现在的做法是配置log4j的日志轮转同时用cron定时清理超过7天的日志。YARN的容器日志也要定期清理yarn.nodemanager.log.retain-seconds控制保留时间默认3小时生产环境可以适当调大但不要超过7天。最后分享一个排查问题的思路遇到集群异常的时候先看监控大盘确认是全局问题还是单节点问题然后从NameNode和ResourceManager的日志入手这两个组件的日志包含了绝大部分关键信息。定位到具体节点后再去看NodeManager和DataNode的日志。不要一上来就翻所有日志那样效率太低。
