资讯详情

深入了解 · 专业解读

Hadoop分布式集群部署与故障排查实战指南

发布时间：2026/7/21 12:52:04
Hadoop分布式集群部署与故障排查实战指南 1. 项目概述这不是一次“装个软件”的操作而是一次对分布式系统思维的实地拉练你点开这篇文字大概率不是为了找一个“Hadoop安装教程”——网上能搜出几百篇带截图、带命令行的步骤文档但真正用过 Hadoop 做过真实数据处理的人十有八九会在第三步卡住namenode 启动失败、datanode 连不上、yarn 的 ResourceManager 页面打不开、或者 MapReduce 任务提交后永远显示 ACCEPTED 却不运行。这不是你手生也不是配置写错了几个空格而是你正站在一个经典认知断层上单机思维和分布式思维之间隔着一堵看不见的墙。我在金融风控团队搭过日均 20TB 日志的离线计算平台在电商中台维护过三年的 HadoopHive 生产集群也带过十几届校招新人从零部署伪分布式环境。所有踩过的坑、重装过的系统、抓包分析过的 RPC 调用、翻烂的 Apache 官方 JIRA issue最后都沉淀成一句话Hadoop 不是“装好就能跑”它是你第一次亲手把一台机器“掰开”让它的存储、计算、调度三部分分别住在不同进程里再用网络把它们重新焊死在一起的过程。这篇文章要带你做的就是亲手完成这道焊接。它不讲“Hadoop 是什么”这种教科书定义那一页纸就能写完而是聚焦在“为什么必须这么配”“哪个参数改错会导致整个集群静默死亡”“当 web UI 显示红色告警时第一眼该盯哪三个日志文件”。关键词里的 “Towards AI” 和 “Medium” 只是原始出处标记我们彻底剥离平台属性回归技术本体——所有操作基于 Apache Hadoop 3.3.6当前 LTS 最稳版本所有路径、端口、用户权限都按生产级最小权限原则设计所有命令都经过 Ubuntu 22.04 OpenJDK 11 systemd 环境实测。如果你刚学完 MapReduce 编程模型却连本地 WordCount 都跑不起来如果你在云上开了三台 ECS 却发现 datanode 死活注册不上或者你正被公司要求两周内上线一个测试集群但毫无头绪——这篇文章就是为你写的。它不承诺“一键部署”但保证你合上页面时能独立诊断 85% 的常见启动故障并理解背后每一层网络、Java、Linux 的协作逻辑。2. 核心架构解构先拆开再组装——Hadoop 四大组件的真实分工与依赖链2.1 HDFS不是“分布式硬盘”而是“带心跳的文件切片保险柜”很多人把 HDFS 理解成“把大文件切成块存在多台机器上”这没错但漏掉了最关键的两个字心跳。HDFS 的 namenodeNN和 datanodeDN之间不是简单的“我存你管”关系而是一套精密的生存监测系统。NN 每隔 3 秒向每个 DN 发送心跳请求heartbeatDN 必须在 10 秒内响应并附带自身存储块报告block report。如果连续 10 次心跳失败即约 3 分钟NN 就会将该 DN 标记为“dead”并触发副本复制流程——这才是 HDFS 高可用的底层逻辑。所以当你看到hdfs dfsadmin -report输出里某个 DN 状态是DEAD别急着重启服务先查/var/log/hadoop-hdfs/hadoop-hdfs-datanode-*.log里有没有java.net.ConnectException: Connection refused这往往意味着 DN 进程根本没起来或者防火墙拦住了 9866DN 数据传输端口和 9867DN HTTP 端口。HDFS 的核心配置文件hdfs-site.xml里dfs.namenode.http-address和dfs.datanode.http.address这两个参数必须指向可被集群内所有节点解析的主机名而不是localhost或127.0.0.1。我见过太多人因为/etc/hosts里只写了127.0.0.1 localhost导致 DN 启动后向http://localhost:9870注册结果 NN 在另一台机器上根本收不到注册请求。正确的做法是在每台机器的/etc/hosts里明确写出所有节点的 IP 和主机名映射例如192.168.1.10 namenode 192.168.1.11 datanode1 192.168.1.12 datanode2然后在core-site.xml的fs.defaultFS中写hdfs://namenode:9000而不是hdfs://192.168.1.10:9000。这样做的好处是当某台机器 IP 变更时只需改 hosts不用动所有配置文件。这是运维老手才懂的“配置解耦”技巧。2.2 YARN资源调度器不是“分配 CPU”而是“拍卖时间片空间席位”的双轨制YARN 的 ResourceManagerRM和 NodeManagerNM协作模式常被类比为“机场塔台登机口”。但这个类比不够准——塔台只管航班起降时间而 YARN 的 RM 同时拍卖两样东西CPU 时间片vcores和内存席位memory-mb。一个 Container 的启动必须同时竞拍成功这两样资源。这就是为什么你常看到日志里报Failed to allocate container: Insufficient memory但free -h显示内存充足。真相是YARN 默认把物理内存的 80% 划给 NM 管理由yarn.nodemanager.resource.memory-mb控制剩下的 20% 留给系统和 OS 进程。假设你有 32GB 内存的机器yarn.nodemanager.resource.memory-mb设为2457624GB而你的 MapReduce 任务申请了32768MB 内存NM 就会直接拒绝哪怕物理内存还有空闲。更隐蔽的坑在 vcoresyarn.nodemanager.resource.cpu-vcores默认等于机器 CPU 核数但 Java 进程的 GC 线程会抢占 vcore导致实际可用 vcore 少于理论值。我在测试 Spark on YARN 时就遇到过8 核机器设vcores8但 Spark Executor 启动后频繁 Full GC监控显示 CPU 使用率 95%而 YARN UI 显示 vcore 使用率仅 40%。最后发现是 JVM 参数-XX:UseG1GC的并发线程数占用了额外 vcore解决方案是把vcores提到 10并在yarn-site.xml中增加yarn.nodemanager.vmem-pmem-ratio3.0放宽虚拟内存限制。YARN 的本质是把硬件资源抽象成可编程的“数字席位”而你的任务代码就是一张张需要精确填写席位编号container id和使用时长timeout的电子机票。2.3 MapReduce不是“写两个函数”而是“在数据不动的前提下移动计算”的空间换时间哲学MapReduce 的经典误区是“map 函数处理一行reduce 函数汇总结果”。这在单机模拟时成立但在 HDFS 上完全错误。真实流程是Map 阶段的输入分片InputSplit必须与 HDFS 的 block 对齐。HDFS 默认 block size 是 128MB那么一个 1GB 的文本文件会被切成 8 个 block每个 block 存在 3 个副本默认 replication3。MapTask 的调度策略是“数据本地性优先”RM 会尽量把 MapTask 分配到存储着该 block 副本的机器上执行。这意味着如果你的 datanode1 存着 block1 的副本那么处理 block1 的 map task 就大概率在 datanode1 的 NM 上启动。这就是“移动计算而非移动数据”的核心——省掉的是跨网络传输 128MB 数据的时间。但问题来了如果mapred-site.xml里mapreduce.input.fileinputformat.split.minsize设得过大比如 256MB系统就会强行把两个 block 合并成一个 split导致 map task 必须从远程 datanode 拉取数据性能暴跌。我实测过处理 10GB 日志split size 从 128MB 改为 256MB作业耗时从 8 分钟涨到 15 分钟。另一个致命细节是 shuffle 阶段map 输出的 key-value 对不是直接发给 reduce而是先写入本地磁盘mapreduce.cluster.local.dir指定路径再由 reduce task 主动拉取。这个磁盘路径必须是高速 SSD 且有足够剩余空间否则 map task 会因磁盘 IO 等待超时而失败。我们在生产环境强制要求mapreduce.cluster.local.dir必须挂载在独立 NVMe 盘且预留 50GB 以上空间否则集群健康检查直接告警。2.4 组件间依赖链启动顺序不是“习惯”而是由 RPC 协议栈决定的硬约束Hadoop 集群的启动顺序HDFS → YARN → MapReduce常被当作运维口诀背诵但没人告诉你为什么不能反过来。答案藏在 RPC 协议栈里HDFS 的 namenode 启动后会监听 8020 端口IPC 端口提供ClientProtocol接口YARN 的 ResourceManager 启动后需要调用这个接口检查 HDFS 是否可用通过FileSystem.get()创建连接才能初始化其内部的RMStateStore状态存储默认存在 HDFS 的/rmstate目录下。如果你先启 YARN它会在日志里疯狂打印org.apache.hadoop.ipc.RemoteException: java.io.IOException: Filesystem closed因为 NN 根本没起来FileSystem实例创建失败。同理MapReduce 的 historyserver 依赖 YARN 的 timeline service而 timeline service 又依赖 HDFS 存储应用历史数据。这个依赖链是由 Java 接口继承关系和配置文件中的fs.defaultFS、yarn.resourcemanager.hostname等硬编码 URL 决定的不是脚本顺序能绕过的。所以我的集群初始化脚本里永远有三道锁hdfs namenode -format成功后才执行hdfs --daemon start namenodehdfs dfsadmin -safemode wait返回 0安全模式退出后才执行yarn --daemon start resourcemanageryarn node -list | grep RUNNING输出至少一个节点后才启动mapred --daemon start historyserver这三步缺一不可跳过任何一步后续服务都会在日志里留下“Connection refused”或“UnknownHostException”的幽灵错误。这不是保守而是对分布式系统 RPC 调用失败重试机制的尊重——Hadoop 默认重试 10 次每次间隔 1 秒你等 10 秒不如手动确认。3. 实操部署全链路从单机伪分布到三节点集群的逐层穿透3.1 环境筑基JDK 与 SSH 的“隐形地基”必须夯实Hadoop 对 Java 版本极其敏感。官方明确支持 JDK 8 和 JDK 11但 JDK 17 会因javax.xml.bind包移除导致hdfs namenode -format报NoClassDefFoundError。我选 OpenJDK 11.0.222023 年 10 月 LTS 版安装后必须验证三件事# 1. 确认 JAVA_HOME 指向正确路径不是 /usr/bin/java 的软链接 echo $JAVA_HOME # 应输出 /usr/lib/jvm/java-11-openjdk-amd64 # 2. 验证 java 命令和 javac 命令版本一致 java -version javac -version # 两者输出必须都是 11.0.22 # 3. 关键检查 JAVA_HOME 下的 jre/lib/ext 目录是否存在Hadoop 3.x 依赖此路径加载 native lib ls $JAVA_HOME/jre/lib/ext/ | grep hadoop # 应无输出但目录必须存在SSH 配置常被忽略但它决定了集群能否“信任”。Hadoop 启动脚本如start-dfs.sh本质是用ssh命令批量登录各节点执行hdfs --daemon start datanode。所以必须所有节点关闭 SELinuxsudo setenforce 0和防火墙sudo ufw disable否则 ssh 会因端口拦截失败在 namenode 节点生成免密密钥ssh-keygen -t rsa -P -f ~/.ssh/id_rsa将公钥分发到所有节点包括自己ssh-copy-id -i ~/.ssh/id_rsa.pub namenode、ssh-copy-id -i ~/.ssh/id_rsa.pub datanode1最关键一步在每台机器的/etc/ssh/sshd_config中确保PubkeyAuthentication yes和AuthorizedKeysFile .ssh/authorized_keys未被注释然后重启 sshdsudo systemctl restart sshd。 我曾因sshd_config里AuthorizedKeysFile被改成%h/.ssh/authorized_keys意为用户主目录下的 .ssh导致ssh-copy-id把公钥写到了/root/.ssh/authorized_keys而 Hadoop 脚本以hdfs用户身份运行找不到密钥最终所有 datanode 启动失败。这个坑没有日志提示只能靠ssh -v hdfsdatanode1查看详细连接过程才能发现。3.2 伪分布式实战用一台机器模拟集群的“最小可行闭环”伪分布式Pseudo-Distributed Mode不是玩具而是理解组件交互的显微镜。它把 NN、DN、RM、NM 全部跑在同一台机器的不同 JVM 进程里但严格遵循分布式协议。配置要点如下core-site.xml全局基础配置configuration property namefs.defaultFS/name valuehdfs://localhost:9000/value !-- 注意这里用 localhost因为所有服务在同一台 -- /property /configurationhdfs-site.xmlHDFS 专属配置configuration property namedfs.replication/name value1/value !-- 伪分布只需 1 副本避免磁盘爆满 -- /property property namedfs.namenode.name.dir/name valuefile:///usr/local/hadoop/hadoop_data/hdfs/namenode/value /property property namedfs.datanode.data.dir/name valuefile:///usr/local/hadoop/hadoop_data/hdfs/datanode/value /property /configurationyarn-site.xmlYARN 专属配置configuration property nameyarn.nodemanager.aux-services/name valuemapreduce_shuffle/value /property property nameyarn.resourcemanager.hostname/name valuelocalhost/value /property property nameyarn.nodemanager.resource.memory-mb/name value4096/value !-- 根据机器内存调整16GB 内存机器设 4GB -- /property /configurationmapred-site.xmlMapReduce 配置configuration property namemapreduce.framework.name/name valueyarn/value !-- 强制走 YARN不是 local 模式 -- /property /configuration格式化 namenode 并启动# 创建数据目录必须提前建好否则启动报错 sudo mkdir -p /usr/local/hadoop/hadoop_data/hdfs/{namenode,datanode} sudo chown -R hdfs:hdfs /usr/local/hadoop/hadoop_data # 格式化仅首次执行 sudo -u hdfs hdfs namenode -format # 启动 HDFS start-dfs.sh # 自动启动 namenode 和 datanode 进程 # 启动 YARN start-yarn.sh # 自动启动 resourcemanager 和 nodemanager # 验证jps 命令应看到 5 个进程 jps # 输出应包含NameNode, DataNode, ResourceManager, NodeManager, Jps此时访问http://localhost:9870HDFS UI和http://localhost:8088YARN UI能看到活跃节点数为 1。执行经典 WordCount# 创建输入目录 sudo -u hdfs hdfs dfs -mkdir -p /input # 上传测试文件本地文件 echo hello world hello hadoop /tmp/input.txt sudo -u hdfs hdfs dfs -put /tmp/input.txt /input # 运行 MapReduceHadoop 自带示例 sudo -u hdfs hadoop jar $HADOOP_HOME/share/hadoop/mapreduce/hadoop-mapreduce-examples-3.3.6.jar wordcount /input /output # 查看输出 sudo -u hdfs hdfs dfs -cat /output/part-r-00000如果输出hadoop 1hello 2world 1恭喜你的伪分布式闭环已打通。注意所有命令前加sudo -u hdfs是因为 HDFS 进程以hdfs用户运行权限隔离是安全基石。3.3 三节点集群部署从“单机幻觉”到“真实网络拓扑”的跨越当伪分布跑通下一步是三节点1 NNRM 2 DNNM真实集群。关键变化是所有localhost必须替换成真实主机名且 DNS 解析必须 100% 可靠。网络规划表角色主机名IP 地址服务Masternamenode192.168.1.10NameNode, ResourceManager, SecondaryNameNodeWorker1datanode1192.168.1.11DataNode, NodeManagerWorker2datanode2192.168.1.12DataNode, NodeManagerworkers文件替代旧版slaves在 namenode 的$HADOOP_HOME/etc/hadoop/workers文件中写入datanode1 datanode2core-site.xmlMaster 节点configuration property namefs.defaultFS/name valuehdfs://namenode:9000/value !-- 指向 Master 主机名 -- /property /configurationhdfs-site.xml所有节点configuration property namedfs.namenode.http-address/name valuenamenode:9870/value !-- Web UI 地址 -- /property property namedfs.namenode.rpc-address/name valuenamenode:8020/value !-- RPC 地址DN 注册用 -- /property property namedfs.datanode.http.address/name value0.0.0.0:9864/value !-- DN Web UI0.0.0.0 允许外部访问 -- /property /configurationyarn-site.xml所有节点configuration property nameyarn.resourcemanager.hostname/name valuenamenode/value !-- RM 必须在 Master -- /property property nameyarn.nodemanager.remote-app-log-dir/name value/app-logs/value !-- 日志统一存 HDFS -- /property /configuration部署流程在 namenode 执行# 1. 将配置文件同步到所有 worker for node in datanode1 datanode2; do scp $HADOOP_HOME/etc/hadoop/*.xml $node:$HADOOP_HOME/etc/hadoop/ done # 2. 格式化 namenode仅 Master 执行一次 sudo -u hdfs hdfs namenode -format # 3. 启动 HDFS自动 ssh 到 workers 启 datanode start-dfs.sh # 4. 启动 YARN自动 ssh 到 workers 启 nodemanager start-yarn.sh # 5. 在 Master 启动 SecondaryNameNode非必须但推荐 hdfs --daemon start secondarynamenode验证集群状态# 查看 HDFS 状态 sudo -u hdfs hdfs dfsadmin -report | grep -E (Live|Dead|Decommissioned) # 正常应显示 Live datanodes : 2 # 查看 YARN 节点 yarn node -list -all | grep RUNNING # 应显示 2 个 RUNNING 节点 # 检查进程在各节点执行 jps # namenode: NameNode, ResourceManager, SecondaryNameNode, Jps # datanode1: DataNode, NodeManager, Jps # datanode2: DataNode, NodeManager, Jps如果hdfs dfsadmin -report显示Live datanodes : 0立刻检查datanode1的/var/log/hadoop-hdfs/hadoop-hdfs-datanode-datanode1.log90% 的概率是java.net.UnknownHostException: namenode—— 这说明datanode1的/etc/hosts里没配192.168.1.10 namenode。记住Hadoop 集群里DNS 解析失败比网络不通更致命因为后者会报 timeout前者直接抛异常中断流程。3.4 云环境适配AWS EC2 上的 Hadoop 集群避坑指南在 AWS 上部署 Hadoop最大的陷阱是安全组Security Group配置。EC2 默认安全组只开放 22 端口而 Hadoop 需要开放数十个端口。必须一次性放行以下端口组端口服务协议开放范围22SSHTCP你的 IP9000HDFS IPCTCP所有节点自定义源sg-xxxx9870HDFS Web UITCP你的 IP9864DataNode Web UITCP你的 IP8088YARN Web UITCP你的 IP8030-8033YARN RPCTCP所有节点9866-9867DataNode RPC HTTPTCP所有节点特别注意不要用0.0.0.0/0开放所有端口这是严重安全隐患“所有节点”指集群内所有 EC2 实例应通过安全组 ID如sg-12345678作为源而非 IP 段在yarn-site.xml中yarn.resourcemanager.webapp.address必须设为0.0.0.0:8088否则 YARN UI 只能本机访问EC2 的hostname默认是ip-172-31-xx-xx.ec2.internal但 Hadoop 配置中建议用自定义主机名如namenode并在/etc/hosts中绑定私有 IP避免因 DNS 解析延迟导致启动超时。4. 故障排查实战手册从日志红字到秒级定位的黄金四步法4.1 黄金四步法定位问题的标准化流水线面对 Hadoop 启动失败或任务卡死我从不靠猜。我的标准动作是四步循环看 UI 红字先打开http://namenode:9870和http://namenode:8088UI 上的红色告警如Dead Nodes: 1、Unhealthy Nodes: 1是最高优先级线索查进程存活在对应节点执行jps确认关键进程NameNode/DataNode/ResourceManager/NodeManager是否在列表中读最新日志进入$HADOOP_HOME/logs/用tail -n 100 hadoop-*-namenode-*.log | grep -i error\|exception\|failed快速抓取错误堆栈验网络连通用telnet namenode 8020测试 NN RPC 端口是否可达用curl -I http://datanode1:9864测试 DN Web 端口。这四步覆盖了 95% 的问题。下面是我整理的高频故障速查表现象可能原因定位命令解决方案start-dfs.sh后jps看不到 DataNodedatanode进程启动即退出tail -n 50 $HADOOP_HOME/logs/hadoop-*-datanode-*.log检查dfs.datanode.data.dir目录权限chown -R hdfs:hdfs /path/to/dataYARN UI 显示0 active nodesNodeManager 未启动或注册失败jps看是否有NodeManagertail -n 50 $HADOOP_HOME/logs/yarn-*-nodemanager-*.log检查yarn.nodemanager.resource.memory-mb是否超过物理内存调小该值MapReduce 任务卡在ACCEPTEDResourceManager 无法分配 Containeryarn application -status app_idyarn node -list检查yarn.resourcemanager.scheduler.class是否为CapacityScheduler并确认队列default有资源hdfs dfs -ls /报Connection refusedNamenode 未监听 8020 端口netstat -tulngrep 8020sudo lsof -i :8020SecondaryNameNode 启动失败无法连接 Namenodetail -n 50 $HADOOP_HOME/logs/hadoop-*-secondarynamenode-*.log检查fs.defaultFS是否指向hdfs://namenode:9000且namenode可解析4.2 一个经典案例DataNode 启动后立即消失的完整复盘现象在 datanode1 上执行hdfs --daemon start datanodejps瞬间看到DataNode进程2 秒后消失hdfs dfsadmin -report显示Dead datanodes: 1。排查过程UI 红字HDFS UI 无明显告警但Live datanodes为 0查进程jps确认 DataNode 进程闪退读日志tail -n 100 $HADOOP_HOME/logs/hadoop-hdfs-datanode-datanode1.log发现关键错误ERROR org.apache.hadoop.hdfs.server.datanode.DataNode: Exception in secureMain java.io.IOException: All directories in dfs.datanode.data.dir are invalid: /usr/local/hadoop/hadoop_data/hdfs/datanode验网络telnet namenode 8020成功排除网络问题。根因分析dfs.datanode.data.dir目录权限错误。Hadoop 要求该目录必须由hdfs用户拥有且不能有 group 或 other 的写权限即权限必须是755或700。我之前执行了chmod 777 /usr/local/hadoop/hadoop_data/hdfs/datanodeHadoop 认为这是不安全的直接拒绝启动。解决方案sudo chown -R hdfs:hdfs /usr/local/hadoop/hadoop_data/hdfs/datanode sudo chmod 755 /usr/local/hadoop/hadoop_data/hdfs/datanode sudo -u hdfs hdfs --daemon start datanode再次jpsDataNode 进程稳定运行hdfs dfsadmin -report显示Live datanodes : 1。这个案例揭示了一个核心原则Hadoop 的安全模型比你想象的更严格。它宁可启动失败也不接受“看似能用”的宽松权限。所有数据目录、日志目录、pid 目录都必须用chown hdfs:hdfs和chmod 755严格加固。4.3 生产环境必备日志轮转与磁盘空间守护脚本Hadoop 日志不清理半年就能吃掉 100GB 磁盘。我写的自动化清理脚本放在/usr/local/bin/hadoop-log-clean.sh#!/bin/bash # 清理 Hadoop 日志保留最近 7 天 LOG_DIR/usr/local/hadoop/logs find $LOG_DIR -name *.log.* -type f -mtime 7 -delete find $LOG_DIR -name *.out -type f -mtime 7 -delete # 清理 HDFS 临时文件/tmp/hadoop-* find /tmp -maxdepth 1 -name hadoop-* -type d -mtime 1 -exec rm -rf {} \;加入 crontab 每日凌晨 2 点执行0 2 * * * /usr/local/bin/hadoop-log-clean.sh /var/log/hadoop-log-clean.log 21同时我用df -h监控/usr/local/hadoop/hadoop_data分区当使用率 85% 时自动触发告警邮件。这个脚本已在三个生产集群稳定运行两年零事故。5. 扩展能力图谱Hadoop 不是终点而是大数据生态的中央枢纽5.1 与 Spark 的共生为什么 Spark on YARN 是生产首选很多人纠结“Hadoop vs Spark”这是伪命题。Spark 本身不提供存储它需要 HDFS 作为底层文件系统。Spark on YARN 的优势在于资源复用。同一个 YARN 集群可以同时运行 MapReduce 作业批处理、Spark Streaming实时流、甚至 Flink 任务事件驱动。我管理的集群里70% 的 ETL 用 Spark SQL20% 的报表用 Hive on Tez10% 的风控模型用 MapReduce全部共享同一套 YARN 资源池。部署 Spark on YARN 的关键配置spark-defaults.confspark.master yarn spark.submit.deployMode client spark.yarn.jars hdfs://namenode:9000/spark-jars/* spark.yarn.archive hdfs://namenode:9000/spark-archive.zip注意spark.yarn.jars必须指向 HDFS 上的 jar 包路径而不是本地路径。我通常把$SPARK_HOME/jars/下所有 jar 上传到 HDFS 的/spark-jars目录这样所有节点都能通过 HDFS 协议拉取避免 jar 包分发失败。5.2 与 HBase 的协同HDFS 是骨HBase 是肉HBase 是构建在 HDFS 之上的 NoSQL 数据库。它的 RegionServer 进程直接读写 HDFS 的/hbase目录。这意味着HBase 的稳定性高度依赖 HDFS 的健康度。当 HDFS 出现大量 Dead Datanode 时HBase 的 RegionServer 会因无法写入 WALWrite-Ahead Log而崩溃。因此HBase 集群的监控必须把hdfs dfsadmin -report的输出纳入告警体系。我在 Prometheus 中配置了自定义 exporter当Live datanodes数量 总节点数的 80% 时自动触发 HBase 服务降级预案。5.3 云原生演进Kubernetes 上的 Hadoop现实很骨感有人问“能不能把 Hadoop 搬到 K8s” 答案是技术上可行但生产不推荐。原因有三存储绑定难题HDFS 的 DataNode 必须绑定本地磁盘dfs.datanode.data.dir而 K8s 的 PersistentVolume 通常是网络存储NFS/Ceph

相关新闻