简介面向大数据平台运维与开发人员这份Cloudera Manager 5.10.0离线安装包专为CentOS7系统准备能够一站式完成CDH集群管理环境的快速搭建尤其适合企业内网等无法直接访问外网获取安装包的部署场景。压缩包为tar.gz格式大小约615.94MB共包含2000个文件整体分为cm-5.10.0与cloudera两个子目录。文件类型以Python运行库及py/pyc脚本、Java组件jar包、Web管理控制台前端静态资源html/js/css、properties与conf服务配置、Hive相关ddl/sql脚本为主同时涵盖so动态库、sh部署脚本、xml/json配置等辅助文件结构清晰便于离线分发与批量部署。已有825人学习下载。借助该包可完成CM Server与Agent的安装启动并通过7180端口Web界面执行主机添加、CDH组件部署、服务监控及告警配置等完整管理工作对需要在内网环境搭建CDH集群或系统学习Cloudera Manager的中高级大数据工程师具有较强参考价值是一份可直接落地的完整离线资源。1. 装大数据环境先过 Cloudera Manager 这一关搞大数据集群绕不开 Cloudera Manager但很多人在它面前翻车。同一个安装包有人四小时装好五个节点跑通 HDFS 和 Hive有人三天卡在 Agent 起不来、元数据库连不上最后把整个系统重装。差别往往不在命令熟不熟而在几个容易被忽略的版本与环境前提上。这篇笔记围绕cloudera-manager-centos7-cm5.10.0_x86_64.tar.gz这个安装包完整走一遍 CentOS 7 上从解压、装 Server/Agent、配 MySQL 元数据库到 Web 控制台跑通的流程。它解决的是 CM 5.10.0对应 CDH 5.10.0在 x86_64 上的安装与配置落地。适合正要搭 CDH 5.10 测试环境或维护旧集群的开发者——照着走能少折腾几个晚上。2. 环境准备OpenJDK 还是 Oracle JDK先在这里选对2.1 CM 5.10.0 对系统与 JDK 的硬性要求CM 5.10.0 官方支持 CentOS 77.2 及以上、RedHat 7 和 Oracle Linux 7内核版本要求在 3.10 以上。安装前先确认系统版本和架构避免装到一半发现基础系统不满足注意 5.10.0 版本只面向 x86_64 架构如果机器是 ARM 架构则无法使用。JDK 方面CM 5.10.0 要求 JDK 1.8Oracle JDK 或 OpenJDK 均可。但这里有个容易踩坑的地方Cloudera Manager 5.10 对 JDK 版本有测试范围Oracle JDK 1.8如 8u77、8u91、8u101、8u111、8u121 等没有问题OpenJDK 1.8 配合较新的 CentOS 7 小版本也能正常工作。我一般推荐在生产集群或要长期使用的环境上用 Oracle JDK 1.8测试环境用系统自带的 OpenJDK 1.8 即可。注意不要用 JDK 9 及以上CM 5.10 的 Java 组件无法兼容。2.2 前置依赖Python、MySQL、NTP 与主机名规划除 JDK 外以下几项也需要提前准备Python 2.7CentOS 7 自带MySQL 5.7 或 MariaDB 10.2用于存储 CM 自身的元数据NTP 时间同步集群节点间时间差过大会导致各类通信异常正确的 hostname 和 /etc/hosts 配置要求主机名能互相解析不允许用 IP 或 localhost 作为主机名具体版本对比如下组件推荐版本版本说明操作系统CentOS 7.6内核需 3.10 以上架构x86_64不支持 ARMJDKOracle JDK 8u77 或 OpenJDK 1.8不支持 JDK 9元数据库MySQL 5.7 / MariaDB 10.2存储 CM 与各组件的元数据Python2.7系统自带无需额外安装2.3 关闭防火墙、SELinux 并规划端口Cloudera Manager 5.10 的组件之间通信端口很多且不同组件使用的端口并不统一。如果开着 firewalld 或 SELinux会时不时出现某个组件起不来的怪问题因此建议直接在安装阶段关闭。如果无法关闭需要放行 7180CM Web 控制台、7182Agent 与 Server 通信、8020NameNode、50070NameNode Web UI、9083Hive Metastore、10000HiveServer2等常用端口。关闭命令如下注意这里需要 root 权限且要在所有节点上执行systemctl stop firewalld systemctl disable firewalld setenforce 0 sed -i s/^SELINUXenforcing/SELINUXdisabled/ /etc/selinux/config这段命令关闭防火墙并禁用然后临时关闭 SELinux并通过修改 /etc/selinux/config 保证重启后不会重新启用到 enforcing 状态。注意setenforce 0只对当前运行期生效如果跳过 sed 那一步重启后 SELinux 会回到 enforcing之前能跑的组件可能突然起不来。新装环境建议先确认 /etc/selinux/config 里确实是 disabled再做后续操作。2.4 主机名与 /etc/hosts 规划这是安装 Cloudera Manager 时最容易出问题的一点。CM 要求所有节点的主机名不能是 localhost且/etc/hosts中必须配置完整的 IP 与主机名映射。很多人在 Agent 安装完成后发现节点无法在 Web 控制台注册都是这一步出了问题。常见的错误配置是这样127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4这样配置后CM 会无法正确识别节点身份导致 Agent 注册失败。正确的配置是127.0.0.1 localhost 192.168.10.2 cm-server 192.168.10.3 cm-node1 192.168.10.4 cm-node2修改主机名的命令如下在每台机器上设置对应的主机名# 在 Server 节点执行 hostnamectl set-hostname cm-server # 在 Agent 节点执行 hostnamectl set-hostname cm-node1 hostnamectl set-hostname cm-node2hostnamectl 是 CentOS 7 中推荐的主机名管理命令会持久化到 /etc/hostname。设置完成后需要在所有节点之间通过ping命令验证互相能解析到对方的 IP再进入下一步。另外很多人在 /etc/hosts 中直接删掉 127.0.0.1 那行来避免 localhost 问题但这样可能导致本机解析出问题建议保留同时让主机名映射排在它后面。3. 安装与配置从 JDK、MySQL 到 Cloudera Manager Server3.1 JDK 安装与 JAVA_HOME 配置在所有节点上安装 JDK并配置好 JAVA_HOME。以 Oracle JDK 8u77 为例解压安装后需要把路径写入 /etc/profile注意 CM 5.10.0 的脚本在查找 Java 时会先看 JAVA_HOME 环境变量如果找不到再看其他优先级路径。因此 JAVA_HOME 必须正确配置且不可省略。安装 JDK 的命令如下# 在每一台节点上执行同样的操作 mkdir -p /usr/java tar -zxvf jdk-8u77-linux-x64.tar.gz -C /usr/java然后将以下内容写入/etc/profile末尾export JAVA_HOME/usr/java/jdk1.8.0_77 export PATH$JAVA_HOME/bin:$PATH export CLASSPATH.:$JAVA_HOME/lib/dt.jar:$JAVA_HOME/lib/tools.jarJAVA_HOME 指向 JDK 的根目录不是 bin 目录PATH 中的 $JAVA_HOME/bin 确保 java 命令可用。CLASSPATH 不是必须配置的但如果后续要用一些基于 JDK 的工具加上会更省事。执行source /etc/profile并验证java -version输出为 1.8 版本即可。如果在之后的安装过程中出现JAVA_HOME not found的报错可以执行以下命令确认echo $JAVA_HOME ls -l $JAVA_HOME/bin/java3.2 MySQL 5.7 元数据库安装与初始化Cloudera Manager 需要一个关系型数据库来存储集群的配置、部署信息、主机状态和历史记录。这一步建议直接使用 MySQL 5.7。安装完成后需要做三个动作创建数据库、创建用户、授权并且注意 CM 需要scm用户具备所有权限而不仅仅是部分权限。MySQL 安装并启动服务后执行如下初始化命令mysql -uroot -p进入 MySQL 后执行以下 SQL 语句CREATE DATABASE scm DEFAULT CHARACTER SET utf8; CREATE USER scm% IDENTIFIED BY scm_password; GRANT ALL PRIVILEGES ON scm.* TO scm%; FLUSH PRIVILEGES;关于GRANT ALL PRIVILEGES这里要解释一下CM 初始化时不仅会建表还会在后续运行时写入大量配置信息与历史状态数据权限不足会在 Web 控制台启动时直接报无法连接数据库或权限 denied。% 表示允许任意主机登录实际部署时可以收紧为 CM Server 所在节点的 IP但如果集群规模较大或后续有 HA 需求建议保留 %。另外注意数据库的默认字符集要设置为 utf8避免中文或其他字符出现乱码问题。MySQL 5.7 默认情况下 root 用户只允许 localhost 登录如果安装时使用了自定义的安装方式导致 root 密码未设置可以先以 skip-grant-tables 模式启动数据库完成密码重置再恢复正常模式。不推荐在图省事的情况下用mysql_secure_installation跳过 root 密码之前就见过因为 root 密码为空导致 CM 连接测试通过后却无法正常创建表结构的情况。3.3 免密 SSH 配置这步不做后面部署组件会卡死Cloudera Manager 在安装 CDH 组件时需要向集群中的各台机器分发 parcel 文件并执行安装脚本。这个过程中CM Server 会通过 SSH 连接各节点的 root 账号因此免密 SSH 必须配置正确。配置方法如下# 在 CM Server 节点执行 ssh-keygen -t rsa -b 4096 -P -f /root/.ssh/id_rsa ssh-copy-id -i /root/.ssh/id_rsa.pub rootcm-node1 ssh-copy-id -i /root/.ssh/id_rsa.pub rootcm-node2ssh-keygen -t rsa -b 4096生成一对 RSA 密钥-P 表示空口令-f指定输出位置。ssh-copy-id会把公钥追加到目标节点的 /root/.ssh/authorized_keys 中。这里需要注意两点第一CM Server 与各 Agent 的 SSH 必须能直连不能经过跳板机第二密钥必须是 root 用户的不能使用普通用户。生成完密钥后用ssh cm-node1验证一次是否能免密登录能登录再继续。如果后续出现Failed to connect to host或Host key verification failed之类的错误多半是 SSH 密钥或 known_hosts 的问题。可以在 CM Server 上删除 /root/.ssh/known_hosts 后重新 ssh 一次或者直接在 ssh 命令中加上-o StrictHostKeyCheckingno来跳过公钥确认但这只建议在测试环境使用生产环境不要这样做。3.4 安装 NTP 并同步时间集群中每个节点的时间不一致会导致 HDFS 和 HBase 出现写入异常、心跳超时等问题。CM 自身对时间差也非常敏感。用系统自带的 chrony 或 NTP 服务都可以下使用 chrony 作为示例yum install -y chrony systemctl start chronyd systemctl enable chronyd chronyc sources -vchrony 是 CentOS 7 下默认的时间同步服务启动后会自动使用配置文件 /etc/chrony.conf 中指定的时间源。执行chronyc sources -v可以查看时间同步的状态如果显示^*表示已经同步成功。对于离线环境可以用一台节点作为 NTP Server其他节点指向该节点这一点在很多内网部署中是必须的。3.5 解压 Cloudera Manager 安装包并安装 Server 和 Agent现在进入正题。将cloudera-manager-centos7-cm5.10.0_x86_64.tar.gz上传到 CM Server 节点并解压。这个压缩包中包含 CM Server、Agent、Daemons 等所有需要的组件解压后可以直接执行安装。解压命令如下mkdir -p /opt/cloudera-manager tar -zxvf cloudera-manager-centos7-cm5.10.0_x86_64.tar.gz -C /opt/cloudera-manager cd /opt/cloudera-manager/cm-5.10.0/etc/cloudera-scm-agent/解压后进入 agent 配置目录需要先做两处关键调整一是 agent 的 server_host 要指向 CM Server 的 IP二是 agent 的 user 要改为 root。这两个配置直接影响 Agent 和 Server 的通信以及后续组件的安装权限。编辑/opt/cloudera-manager/cm-5.10.0/etc/cloudera-scm-agent/config.ini找到并修改以下配置[General] # 填写 CM Server 的 IP server_host192.168.10.2 server_port7182server_host 必须填写 CM Server 的 IP 或可解析的主机名不能是 localhost。server_port 是 Agent 与 Server 的通信端口默认 7182一般情况下不需要改。如果 Agent 和 Server 之间有防火墙需要提前放行这个端口。接下来需要安装 CM Server 和 Agent 的 RPM 包。解压后的目录中会有RPM子目录里面有各个组件的 rpm 文件。安装命令如下cd /opt/cloudera-manager/cm-5.10.0/RPMS/x86_64/ yum localinstall -y cloudera-manager-server-5.10.0-1.cdh5.10.0.p0.41.x86_64.rpm yum localinstall -y cloudera-manager-agent-5.10.0-1.cdh5.10.0.p0.41.x86_64.rpm yum localinstall -y cloudera-manager-daemons-5.10.0-1.cdh5.10.0.p0.41.x86_64.rpmyum localinstall会自动解决依赖关系比直接rpm -ivh省心得多。这里要注意的是CM 的 RPM 包之间是有依赖顺序的一般先装 daemons再装 server 和 agent。如果顺序错了可能提示缺少某些文件或服务。另外所有 Agent 节点也需要安装 agent 和 daemons 这两个 RPMServer 节点则安装全部三个。安装完成后启动顺序有讲究。先启动 CM Server等它完成初始化再启动各节点的 Agent。Server 的初始化过程会扫描数据库并创建表结构如果数据库连接失败Server 进程会直接退出而不会在日志中提示等待重试。启动命令如下systemctl start cloudera-scm-server systemctl start cloudera-scm-agent注意如果先启动了 Agent而 Server 还没有就绪Agent 会在日志中反复输出 server not found 之类的错误但这并不是致命问题。如果 Agent 启动失败多半是 config.ini 中的配置有问题可以查看/var/log/cloudera-scm-agent/cloudera-scm-agent.log日志排查。Server 的日志则在/var/log/cloudera-scm-server/cloudera-scm-server.log。3.6 初始化 CM 数据库Cloudera Manager Server 启动前需要先初始化元数据库。CM 提供了专门的脚本来完成这个动作/opt/cloudera-manager/cm-5.10.0/share/cmf/schema/scm_prepare_database.sh mysql scm scm scm_password这个脚本的参数依次是数据库类型、数据库名、用户名、密码。它会自动在 MySQL 中创建 CM 所需的表结构因此执行前必须先完成 3.2 中的建库和授权步骤。如果执行时提示 Cant connect to MySQL先检查 MySQL 是否已启动、scm 用户是否能从当前机器连接。执行完成后再次启动 cloudera-scm-server 服务systemctl start cloudera-scm-server这个时候 Server 会进行首次初始化日志中会出现 Started Jetty server 或 Started Cloudera Manager Server 等字样说明 Server 已经启动成功。之后可以等待 30 到 60 秒让 Server 完全初始化注册信息再打开 Web 控制台验证。4. 配置 Cloudera Manager Web 控制台并部署 CDH 组件4.1 首次登录与 License 确认打开浏览器访问http://192.168.10.2:7180看到登录页后输入默认账号 admin 和密码 admin系统会提示修改密码。这里建议立即修改不要保留默认密码因为 CM 控制台能够管理整个集群的启停和配置修改权限极大默认密码暴露在内网中风险很大。登录后CM 会引导选择 CDH 版本。这里选择 CDH 5.10.0并将 parcel 包放到指定目录中。CM 在安装 CDH 组件时默认会去 Cloudera 官方仓库下载 parcel 文件但在内网或离线环境下通常需要手动下载并分发。在界面中选择使用本地 Parcel后需要把 CDH 5.10.0 的 parcel 文件放到/opt/cloudera/parcel-repo目录中。parcel 文件放好后CM 的 Web 控制台会在 Parcel 页面中自动扫描并显示可用的 CDH 版本。点击下载和分发CM 会通过之前配置好的 SSH 将 parcel 分发到所有 Agent 节点然后依次执行解压、激活等动作。这个过程是 CM 首次安装中最耗时的一步因为 parcel 文件通常有 2GB 左右分发到每个节点都需要时间。4.2 集群创建与角色分配parcel 激活完成后进入集群安装向导。CM 会让用户选择一个集群名称并分配主机角色。对于测试环境最典型的角色分配可以是这样角色分配节点NameNodecm-serverSecondaryNameNodecm-node1DataNodecm-node1, cm-node2ResourceManagercm-serverNodeManagercm-node1, cm-node2Hive Metastorecm-serverHiveServer2cm-node1Huecm-server实际分配时建议将 NameNode 和 ResourceManager 放在 CM Server 节点避免大数据量的读写操作影响控制台的稳定性。Hive Metastore 这类需要访问数据库的角色放在 CM Server 节点可以省去额外的网络连接配置。角色分配完成后CM 会检查各项配置并提示需要修改的参数常见的有HDFS 数据目录默认 /dfs/data建议改为独立挂载盘YARN 的虚拟内存比例需要根据机器实际内存调整各服务的内存分配需要根据机器实际内存调整CM 控制台会针对每个配置项给出推荐值测试环境可以直接采用推荐值生产环境则需要根据业务量重新规划。4.3 常用配置项调整与参数说明CM 控制台支持在配置页面中修改各项服务的参数。以下是在安装 CDH 5.10 时建议检查和调整的配置项配置项默认值推荐值或说明NameNode 数据目录/dfs/nn必须使用挂载盘避免放系统盘DataNode 数据目录/dfs/dn建议多个目录分散 IOHive Metastore 数据库密码无填写 3.2 中创建的数据库密码YARN NodeManager 内存根据机器自动检测建议物理内存的 1/2 到 3/4HDFS 副本数3测试环境可改为 2节省空间这其中的逻辑是HDFS 数据目录决定数据块存放在哪个路径如果系统盘空间不足集群会直接出现容量告警甚至写入失败Hive Metastore 数据库密码配置错误会导致 Hive 服务无法初始化YARN 内存配置过大会导致 NodeManager 启动失败过小则任务执行效率低。这些参数在首次配置时就该调好等集群跑起来后再改往往需要重启整个服务影响面很大。5. 排查避坑CM 5.10 安装中 5 个最常见的翻车点5.1 Agent 注册不上或 Web 控制台显示主机心跳丢失现象所有 Agent 启动成功防火墙也已关闭但 Web 控制台中的主机列表只有 CM Server 一台其他节点一直没有心跳。日志中显示 Failed to connect to server 或 Unable to fetch certificate。原因最常见的三个原因一是 config.ini 中的 server_host 填的是 localhost二是 /etc/hosts 里没有对应主机名解析三是 Agent 和 Server 之间 7182 端口不通。解决逐一排查。先看/var/log/cloudera-scm-agent/cloudera-scm-agent.log确认 server_host 是否正确再在 Agent 节点执行telnet CM-Server-IP 7182测试端口连通性最后检查 /etc/hosts 中是否包含了 Agent 节点的完整主机名映射。如果日志中出现证书相关的报错可以将 Agent 节点的 /etc/cloudera-scm-agent/config.ini 中 ssl 相关配置临时关闭重启 Agent 验证是否为加密通道的问题。5.2 parcel 分发失败或卡在解压阶段现象在 Web 控制台的 Parcel 页面中点击分发和解压后状态一直停留在正在下载或正在解压即使等待几小时也无变化。原因这个现象在离线环境中最常见。CM 默认会从官方仓库下载 parcel如果网络不通下载会一直处于重试状态。另外多个 Agent 节点会同时从 CM Server 拉取 parcel 文件如果 Server 所在节点磁盘 IO 或带宽不足也会导致整体分发缓慢。解决实际部署时建议将 parcel 文件先手动下载好放到/opt/cloudera/parcel-repo。同时需要在 CM 的配置中将 parcel 下载源改为本地仓库具体方法是在 Web 控制台中进入管理 - 设置 - Parcel 配置将远程仓库地址留空或替换为一个本地 HTTP 服务地址。手动分发时可以把 parcel 文件通过 scp 先同步到每个 Agent 的/opt/cloudera/parcel-cache目录中再在 Web 控制台中点击解压这样能大幅缩短等待时间。5.3 Hive 启动失败Metastore 无法连接数据库现象在安装 Hive 服务时Metastore 角色启动失败日志中报错为 Communications link failure 或 Access denied for user。原因要么是 Hive 配置中的数据库密码和 3.2 中创建的不一致要么是 scm 用户没有权限访问 Hive 的元数据库。还有一个常见原因如果 MySQL 配置了 skip-grant-tables 或 root 密码为空Hive 初始化时写入权限不足。解决进入 Hive 配置页面仔细检查 Metastore 数据库的用户名和密码。如果用户名不是 scm确认该用户是否拥有对应数据库的全部权限并执行GRANT ALL PRIVILEGES ON hive.* TO hive%补充权限。另外检查 MySQL 的 max_allowed_packet 参数如果过小Hive 在初始化大量表时会因包过大而断开连接建议设置为 256M 以上。5.4 NameNode 格式化后无法启动目录权限错误现象NameNode 启动失败日志中提示 Failed to create storage directory 或 Permission denied。原因CentOS 7 中如果数据目录是独立挂载的磁盘目录的属主和属组需要是 hdfs 用户或在某些版本中是 hdfs:hadoop而手动创建的目录默认属主是 root。CM 在启动 NameNode 时以 hdfs 用户运行没有写入权限。解决将数据目录的所有权改为 hdfs 用户chown -R hdfs:hadoop /dfs/nn /dfs/dn chmod -R 755 /dfs/nn /dfs/dn在操作前先确认数据目录的挂载情况不要误把整个挂载盘的权限修改掉。如果 NameNode 在格式化后依然无法启动检查 /etc/fstab 中是否配置了自动挂载确保磁盘在重启后能自动挂载。5.5 重启服务器后集群整体起不来现象服务器重启后打开 CM Web 控制台所有集群服务都显示停止状态手动启动时提示 Command timed out 或 Role has no host。原因多数情况下是服务启动顺序出了问题或者是 Agent 没有随系统自动启动。如果 cloudera-scm-agent 服务未启动Web 控制台无法向节点下发启动指令所有角色都会启动超时。解决先在每个节点上确认 Agent 状态并补上自启动systemctl enable cloudera-scm-agent systemctl start cloudera-scm-agent再在 Web 控制台中先启动 HDFS 的 NameNode启动完成后依次启动 DataNode、YARN 和 Hive。实践中集群重启后 CM 会按依赖关系自动排序但如果出现异常可以手动按顺序逐个启动角色。注意不要一次启动全部服务容易因资源竞争导致启动超时。6. 装完怎么验证从 Web 控制台到命令行的一整套检查安装完成后不要只看 Web 控制台显示运行中就认为一切正常。以一次完整的验证流程为例通常在集群启动后按照以下顺序检查先验证 CM Server 与 Agent 的心跳状态再检查 HDFS 的读写能力最后验证 YARN 的任务执行链路。在 Web 控制台中点击主机页面可以看到所有 Agent 的心跳状态和运行状态。正常情况是所有节点显示绿色图标CPU、内存、磁盘等指标正常上报。如果发现某个节点的心跳图标是黄色或红色说明对应 Agent 与 Server 通信不稳定需立即排查。通过图表可以看到该节点的负载和网络情况便于定位是资源问题还是网络问题。然后验证 HDFS 是否真正可用执行以下命令sudo -u hdfs hdfs dfs -mkdir /test_dir sudo -u hdfs hdfs dfs -put /etc/hosts /test_dir/hosts sudo -u hdfs hdfs dfs -cat /test_dir/hostshdfs dfs -mkdir用于在 HDFS 上创建测试目录-put将本机文件上传至 HDFS-cat则读取并输出内容。命令执行过程中不要只关心最终结果还要观察执行时间。如果 HDFS 操作在几十秒后才响应说明 NameNode 或 DataNode 的性能存在问题或者网络延迟异常。再用hdfs dfsadmin -report检查数据块状态sudo -u hdfs hdfs dfsadmin -report输出内容中会包含每个 DataNode 的容量、已使用空间、剩余空间和文件块数量。重点查看两个指标Datanode available数量是否为集群节点数以及各节点的剩余空间是否充足。最后验证 YARN 是否能正常调度任务。在命令行中提交一个简单的 MapReduce 作业sudo -u hdfs yarn jar /opt/cloudera/parcels/CDH-5.10.0-1.cdh5.10.0.p0.41/lib/hadoop-mapreduce/hadoop-mapreduce-examples.jar pi 2 100这个命令会提交一个计算圆周率的示例作业pi 2 100表示使用 2 个 Map 任务和 100 个样本点。如果能在合理时间内得到输出结果说明 YARN 的 ResourceManager、NodeManager 和 HDFS 的配合链路是完整的。整套流程走完后再回到 Web 控制台查看活动或事件页面确认没有红色告警。CM 中每个组件的日志都在/var/log/cloudera-scm-*目录下遇到问题不要只盯着进程状态看日志中会有更具体的报错原因。从那以后我每次搭完 CDH 环境都强制自己走一遍这三条验证命令先看心跳、再写 HDFS、最后跑一个 YARN 作业。这套流程虽然简单但凡是之前翻过车的问题都能在这三步里暴露出来。希望帮到你。本文还有配套的精品资源点击获取
