轻量云服务器搭建大数据学习环境：资源规划与集群初始化

先说明一下我的工作环境。手头这台腾讯轻量云服务器2核4G的配置学生认证后一年也就几十块钱放在家里当实验机再合适不过。大数据这行入门最大的拦路虎不是算法也不是框架而是环境搭建——本地虚拟机开三个节点笔记本风扇能起飞直接上云买三台机器钱包先扛不住。轻量云恰好卡在中间单台价格便宜配置虽比不上企业级云主机但跑伪分布式或者少量节点的集群绰绰有余。这篇文章是这个系列的第一篇核心任务是“打地基”。我会从最开始的资源规划讲起到服务器选型、系统初始化、JDK安装、SSH免密配置再到目录结构和软件包规划把每一步背后的道理都说清楚。不管你是准备大数据面试、做毕业设计还是单纯想搭一套能跑通Hadoop、Hive、Spark的练习环境这套流程都适用。前前后后我自己踩了不少坑会一并写出来算是给大家省点时间。1. 项目整体设计与资源评估1.1 轻量云跑大数据4核8G的账要算清楚先说个很多人问我的问题轻量云服务器到底能不能跑大数据我的答案是能跑但前提是别拿它当生产环境而且配置选择上有讲究。以腾讯轻量云为例常见的配置有2核2G、2核4G、4核8G、4核16G。大数据各组件对资源的消耗差异很大我给个大致参考组件最低内存要求4G内存表现8G内存表现备注Hadoop HDFS2GNameNodeDataNode勉强GC频繁流畅NameNode比较吃内存YARN1.5GResourceManagerNodeManager可运行流畅任务多时容易OOMHive2GMetastoreHS2较卡流畅依赖HDFS和YARNSpark2GDriverExecutor小数据集可跑较流畅别想跑大数据量Zookeeper512M无压力无压力轻量级Kafka1.5G小规模可跑流畅看分区数和消息量我实测下来的结论是2核4G是“体验版”能跑通Hadoop单机伪分布式但跑Hive或者Spark的时候内存会捉襟见肘经常要为了给YARN腾内存而关掉HDFS的某些进程。4核8G是“学习版”的甜点配置Hadoop、Hive、Spark、Zookeeper、Kafka这几件套都能跑起来虽然不能并行跑大任务但一个个来完全没问题。16G以上就属于“豪华版”了预算够直接上跑起来舒服很多。我自己的机器是4核8G这篇文章的实操基于这个配置。如果你只有2核4G流程完全一样的就是后面安装组件的时候内存参数要调小一点这个后面再说。1.2 集群部署策略为什么我建议用“主节点实体从节点容器”的混合模式规划轻量云上的集群有几种思路方案一完全分布式。搞三台轻量云分别当master、worker1、worker2。优点是最接近生产环境学到的架构知识能直接对标企业场景缺点是贵三台4核8G的机器一年下来一千多而且对个人学习来说大部分时间只有一台在干活浪费。方案二单机伪分布式。一台机器上把NameNode、DataNode、ResourceManager、NodeManager全跑起来一个进程代表一个角色。优点是省钱、配置简单缺点是HDFS的副本数只能配1很多分布式特性体验不到而且跟真实集群的差距比较大。方案三混合模式。我这次用的是这个思路用一台4核8G的物理机跑NameNode、ResourceManager、SecondaryNameNode这些“主节点”角色同时在这台机器的Docker里面跑1到2个容器分别作为DataNode和NodeManager。这样通过物理机Docker容器的方式从“物理机视角”看你拥有一个2到3个节点的集群从“资源视角”看你只付了一台机器的钱。这个方案特别适合轻量云这种资源有限、但你又想体验分布式效果的使用场景。我给个架构示意角色运行位置说明NameNode物理机HDFS主节点SecondaryNameNode物理机辅助namenode别小看它ResourceManager物理机YARN主节点DataNode物理机 Docker容器每个容器算一个节点NodeManager物理机 Docker容器每个容器算一个节点Zookeeper物理机后续组件的基础服务Docker容器的好处是它天然隔离了进程和端口你在容器里跑的HDFS DataNode跟物理机上的NameNode通信走的是正常的网络栈——这样就逼着你去理解端口开放、主机名解析、节点间通信这些真正的分布式运维知识而不是像纯伪分布式那样什么都跑在一起出了问题反而难排查。这个系列的整体规划我自己的安排大概是第一篇本篇做环境准备和基础配置第二篇装Hadoop并验证HDFS和YARN跑通第三篇装Hive和Spark做一个简单的离线分析项目第四篇再做实时部分引入Kafka和Flink。每篇之间是递进关系目录、用户、端口规划在第一步就要想好不然后面返工很痛苦。2. 服务器选型与初始化配置2.1 买机器前要想清楚的几件事腾讯轻量云购买页面上有几个选项很多人随手就点但后面常出问题。地域选择。这个对我的实验影响最大。轻量云的地域就像你家门牌号决定了你的网络延迟和访问速度。国内地域如广州、上海、北京访问快但如果你在海外可能就得选海外地域。我自己在国内选了广州。一个坑是轻量云的地域和可用区决定了你以后能不能用“内网互联”之类的功能虽然个人实验用不上但选的时候稍微留意下就行。镜像选择。腾讯轻量云提供好几种镜像系统镜像CentOS、Ubuntu、Debian、Windows、应用镜像如WordPress、LAMP、Docker基础镜像。我建议选系统镜像里的CentOS 7.9或者Ubuntu 22.04。两者选哪个我现在主力用的是Ubuntu 22.04因为它的软件源更新Python3版本高后面装一些Python工具方便。但如果你以后要进公司很多老牌公司的服务器还是CentOS 7选CentOS能提前适应。这里有个坑CentOS 7已经停止维护了腾讯轻量云的CentOS 7.9镜像虽然还能装但yum源默认已经指向了vault源速度慢且部分包已不可用。Ubuntu 22.04的apt源一切正常。所以我个人建议初次尝试选Ubuntu 22.04省心。防火墙设置。轻量云控制台的“防火墙”是云厂商层面的安全组跟系统内部的firewalld是两套东西。很多人只放行了控制台的端口但系统内部防火墙没关或没放行一样连不上。轻量云默认是“防火墙全开系统内防火墙关闭”的状态但也不太确定所以最稳的做法是先放行控制台端口SSH登录后再检查系统内防火墙状态。后面装Hadoop的时候NameNode的9870端口、ResourceManager的8088端口都要记得在控制台防火墙里加规则。这点忘了你会经历“明明服务起来了但浏览器就是打不开”的崩溃瞬间。2.2 登录服务器后的第一轮初始化新服务器到手先别急着装JDK把基础环境收拾利索了。创建普通用户。一直用root干活很容易出问题——比如后面用scp传文件、写服务启动脚本时权限错乱。我习惯创建一个普通用户用于日常操作比如叫bigdata# 用root登录后先更新系统 apt update apt upgrade -y # 创建用户并加入sudo组 adduser bigdata usermod -aG sudo bigdata # 切换到普通用户继续 su - bigdata这一步很有讲究。大数据组件Hadoop、Hive、Spark官方文档都明确要求“不要用root运行”原因很简单root权限太大HDFS在操作文件时如果用了root权限判断会和Linux系统本身的权限模型打架产生一堆莫名奇妙的权限错误。所以从第一天就养成好习惯一切用普通用户操作。修改主机名。主机名解析是分布式集群的关键。我把它设成bigdata-serversudo hostnamectl set-hostname bigdata-server然后编辑/etc/hosts写上本机IP和主机名映射127.0.1.1 bigdata-server这里有个容易忽略的点很多云服务器的/etc/hosts里默认只写了127.0.0.1 localhost如果你不额外加映射Hadoop在做主机名解析的时候可能把机器解析成localhost导致节点间通信时找不到对方。稳妥的做法是把内网IP也加进去# 假设内网IP是10.0.0.10这行一定要加 10.0.0.10 bigdata-server更新软件源和安装基础工具。Ubuntu 22.04的apt源默认是官方源在国内速度一般我习惯换成清华源或阿里源加快后续安装速度。这一步网上教程很多我主要说说必装的工具sudo apt install -y net-tools vim curl wget lrzsz unzip zip treenet-tools里包含ifconfig和netstat排查端口和网络问题必备。lrzsz提供rz和sz命令从本地上传下载文件到服务器很方便特别是当你不想用scp的时候。关闭swap。大数据组件对内存很敏感如果系统开了swap内存不够时就会疯狂读写swap表现为“物理机没崩但任务卡死”。Ubuntu云服务器默认可能开了swap分区或swapfile。我建议直接关掉sudo swapoff -a sudo sed -i /swap/s/^/#/ /etc/fstab free -h # 确认swap为0如果你担心内存实在不够可以保留1G的swap应急但做大数据的实验我个人倾向全关因为宁可OOM崩掉也不愿意看到一堆进程在swap里半死不活排查起来更麻烦。调整文件句柄数和进程数限制。Hadoop、Spark这类框架会开很多线程和文件句柄默认的ulimit偏小。改一下sudo tee -a /etc/security/limits.conf EOF * soft nofile 655350 * hard nofile 655350 * soft nproc 655350 * hard nproc 655350 EOF改完重新登录生效可以执行ulimit -n验证输出是否变成655350。这里不用写得太复杂企业里还会配合systemd的LimitNOFILE一起改但轻量云实验机没必要。时间同步。这点后文还会细讲这里先开启自动同步sudo apt install -y chrony sudo systemctl enable --now chrony timedatectl set-ntp true时间同步很重要的原因在于HDFS的租约、Zookeeper的会话超时都依赖准确的时钟。如果服务器时间和本机差了十几秒你会遇到“任务莫名其妙失败”但日志里看不出原因的情况。3. 大数据基础环境标准化部署3.1 JDK版本不要贪新8是兼容性之王大数据生态里JDK版本的选择比想象中更重要。我见过有人图新鲜装了个JDK 17结果项目编译时各种反射和字节码问题苦不堪言。目前Hadoop 3.x、Hive 3.x、Spark 3.x这些主流组件用JDK 8或者JDK 11最稳。考虑到很多教程和网上漏出来的源码都基于JDK 8而且后续如果要跑MapReduce的旧代码JDK 8的兼容性无可替代我最终选择OpenJDK 8。安装方式我不用apt因为apt装的JDK路径分散后面配JAVA_HOME麻烦。我手动解压到统一目录# 创建目录 sudo mkdir -p /usr/local/java # 解压假设下载的是jdk-8u202-linux-x64.tar.gz sudo tar -zxvf jdk-8u202-linux-x64.tar.gz -C /usr/local/java/ # 重命名方便管理 sudo mv /usr/local/java/jdk1.8.0_202 /usr/local/java/jdk8 # 给普通用户开权限 sudo chown -R bigdata:bigdata /usr/local/java为什么要放在/usr/local/java而不是/opt或者/root因为大数据组件一般会用统一的路径配置JAVA_HOME/usr/local是Linux放自行编译软件的标准位置语义清晰。另外记得把权限给到普通用户不然Hadoop在运行时会因为无法读取JDK文件而报错。然后配置环境变量。我不建议直接改~/.bashrc因为后续会有多个用户比如root要运维bigdata要跑任务都用这套JDK。我选择写到系统级profile文件里sudo tee /etc/profile.d/java.sh EOF export JAVA_HOME/usr/local/java/jdk8 export PATH$PATH:$JAVA_HOME/bin EOF source /etc/profile.d/java.sh java -version如果输出类似openjdk version 1.8.0_202 OpenJDK Runtime Environment (build 1.8.0_202-b08)说明安装成功。3.2 SSH免密登录集群操作的第一步大数据集群有个特点主节点经常需要“指挥”从节点干活比如启动HDFS时NameNode要SSH到各台DataNode机器上拉起进程。如果你每次都要输密码那集群根本起不来。所以免密登录是必须的。在本次的架构里物理机要免密登录自己因为DataNode容器也在本机网络里还要免密登录Docker容器。先做物理机到自己的免密# 在bigdata用户下生成密钥对 ssh-keygen -t rsa -b 4096 -P -f ~/.ssh/id_rsa # 把公钥加入授权列表 cat ~/.ssh/id_rsa.pub ~/.ssh/authorized_keys # 设置权限 chmod 700 ~/.ssh chmod 600 ~/.ssh/authorized_keys注意权限一定要对。.ssh目录要是700authorized_keys文件要是600否则ssh服务会为了安全拒绝加载你的密钥文件。我见过太多人卡在这一步一测试免密失败检查半天才发现是authorized_keys权限是644。验证ssh bigdata-server如果能免密登录到自己的机器第一关就过了。Docker容器的免密我放到下篇细说这里先留个思路容器里的用户也要生成密钥并把物理机的公钥加入容器的authorized_keys。3.3 时间同步与主机名映射分布式集群最容易忽略的雷区先说说时区问题。很多云服务器默认是UTC时区你人在东八区日志时间全是UTC排查问题时有如神游。第一件事把时区改到上海sudo timedatectl set-timezone Asia/Shanghai date然后是时间同步。我刚才已经装了chrony现在说明一下为什么必须做这一步。HDFS有一套租约lease机制用来保证并发写入的独占性。如果一个DataNode的时钟比NameNode慢了超过阈值NameNode会认为该节点“失联”从而触发副本复制造成不必要的数据移动。Zookeeper也是如果两个节点的时钟差超过sessionTimeout就会反复断连重连。所以时间同步不是锦上添花是刚需。主机名映射刚才也提过。这里再补充一个细节不要只改/etc/hosts还要检查一下/etc/hostname文件是不是和hostname命令输出一致。有些系统里这两个值如果不一致Hadoop解析时会用/etc/hostname里的值导致hosts里写的映射匹配不上那就有得查了。4. 大数据目录规划与软件包准备4.1 标准目录规划不要让软件散成一地这一步很多教程都不讲但我觉得非常关键。你想想以后Hadoop、Hive、Spark、Kafka、Zookeeper、Flink这一堆组件都要装在服务器上如果每个任性地解压到随机位置环境变量写得乱七八糟到时候维护起来就是灾难。我推荐一套目录规划方案路径用途/usr/local/javaJDK安装目录/opt/software软件安装包tar包存放目录/opt/module解压后的软件主目录/data/hadoopHDFS数据存储目录/data/logs各组件的运行日志统一放置注意/data/hadoop就是给NameNode和DataNode存放元数据和数据块的目录。Linux根分区一般20G到40G轻量云老板默认给的系统盘可能不大所以最好把数据目录放在数据盘挂载点下。如果你买了数据盘还需要做挂载这个流程稍微繁琐但是值得的# 查看数据盘设备名 sudo fdisk -l # 假设数据盘是/dev/vdb格式化和挂载 sudo mkfs.ext4 /dev/vdb sudo mkdir -p /data sudo mount /dev/vdb /data echo /dev/vdb /data ext4 defaults 0 0 | sudo tee -a /etc/fstab如果不加fstab这行重启后数据盘不会自动挂载可能导致HDFS找不到块存储直接起不来。软件包统一放/opt/software解压后统一放/opt/module这样以后写脚本、配环境变量都有章可循。顺便说一句这个“softwaremodule”的结构我参考了很多互联网公司内部的标准做法好处显而易见要清理时不用的包直接删software下的tar要升级时替换module下的软链接就行。4.2 软件包清单与镜像源选择版本匹配是隐形的深坑决定装哪些组件之前先列个版本兼容性矩阵。这个比什么都重要。我给的版本组合是经过实测的组件版本说明Hadoop3.3.6稳定版JDK8兼容Hive3.1.3兼容Hadoop 3.xSpark3.5.1兼容JDK8支持Hadoop 3Zookeeper3.7.2稳定Kafka3.6.2注意内置zookeeper模式3.x新版可不用ZKFlink后续1.18.1后续实时部分再装版本匹配有个经典坑Hive 2.x和Hadoop 3.x不兼容会报Unsupported class file major version的错误Spark 2.x连接Hadoop 3.x时会有元数据版本问题。所以选版本前先查官方文档或看网上最新的搭配方案。软件包从哪里下载不要从Apache官网直接下国内速度慢到怀疑人生。用国内镜像站快得多清华大学镜像站https://mirrors.tuna.tsinghua.edu.cn/阿里云镜像站https://mirrors.aliyun.com/华为云镜像站https://mirrors.huaweicloud.com/Hadoop、Hive、Spark、Zookeeper这些Apache项目的包在镜像站都有同步路径形如/apache/hadoop/common/hadoop-3.3.6/hadoop-3.3.6.tar.gz。下载示例cd /opt/software wget https://mirrors.tuna.tsinghua.edu.cn/apache/hadoop/common/hadoop-3.3.6/hadoop-3.3.6.tar.gz下载完先校一下sha512防止包损坏。这一步看着多余但我栽过跟头下载的Spark包居然损坏了解压时一切正常一运行spark-shell就报classNotFound排查了一下午才发现是包的事。5. 初始化阶段常见问题与排查实录5.1 防火墙导致SSH连不上这个太经典了。新买的轻量云控制台放行了22端口但死活连不上SSH。排除完密钥和密码的问题后八成就是系统内防火墙没放行。Ubuntu 22.04默认可能装了ufw检查命令如下sudo ufw status如果active放行22端口sudo ufw allow 22/tcp另外还有一种情况轻量云的系统内其实没有防火墙但云控制台的“防火墙”规则里有一个“默认拒绝所有”的高级安全规则你没留意后面开8088端口时就被静默丢弃。所以我建议在轻量云控制台的防火墙页面先把22、8088、9870、9000NameNode RPC、2181Zookeeper、8080Spark UI这些常用端口一次性加进去免得后面每次加一个组件都要来一下。5.2 JDK版本隐坑环境变量配好了但java命令还是老版本这种问题在我帮人排查的时候经常遇到。原因通常是系统里通过apt或者其他方式已经存在了一个OpenJDK而它的路径也被写进了PATH。当你配置新的JAVA_HOME时可能在/etc/profile.d/java.sh里写的是export PATH$PATH:$JAVA_HOME/bin注意这里用的是$PATH:$JAVA_HOME/bin把新路径放在了旧路径后面。如果旧JDK在/usr/bin/java已经存在执行java -version时系统先找到/usr/bin/java于是你用到的还是旧的。正确的做法是把JAVA_HOME/bin放在最前export PATH$JAVA_HOME/bin:$PATH同时检查一下是否残留了替代机制sudo update-alternatives --config java把默认java切换到你的目录。这两个步骤都做完才算彻底切换干净。5.3 时钟不同步导致的HDFS启动异常我自己第一次搭集群的时候遇到过一个问题namenode启动后datanode总是连不上日志里报Starting thread to transfer block blk_xxx to 10.0.0.11:9866然后超时。排查了一整个晚上最后发现是两台机器的时间差了快5分钟。虽然轻量云默认开启了NTP但我当时手动改过系统时间把chrony给顶了。解决办法sudo systemctl restart chrony sudo chronyc tracking观察Stratum字段是不是变成数字而不是0。如果一直是0说明还没同步成功再等等或者查看日志journalctl -u chrony。从这件事之后我养成了一个习惯每次搭集群在安装Hadoop之前先确认所有节点的时间误差不超过1秒。这个习惯在后续做Kafka和Flink集群的时候帮我避了很多雷。5.4 swap导致的内存评估失准最后一个常见问题是我看到很多人内存明明4G跑free -h一看swap显示的用了几百M。这就是我把swap关掉的原因。Hadoop的NameNode在启动时会根据物理内存大小自动设置JVM堆内存。如果开着swap某些JVM参数在评估可用内存时会把swap也算进去结果就是堆内存设置得过大一旦实际用起来就开始疯狂换页整个服务器假死SSH敲命令都要卡几秒。排查方法很简单确保swap是0free -h如果你确实需要靠swap撑一下那就在给各个组件分配内存时留足余量别让JVM觉得自己有很多内存可用。最稳妥的做法还是关掉swap让每个组件的内存都在规划好的范围内。下面整理成速查表问题表现原因排查命令解决办法SSH连不上超时或拒绝系统内防火墙未放行sudo ufw status放行22端口java版本不对java -version还是旧版本PATH顺序或alternatives未切换which java调整PATH顺序用update-alternatives集群节点连不上日志报连接超时时间不同步date; chronyc tracking重启chrony并确认Stratum为数字内存评估失准任务卡死swap开启free -h关闭swap6. 个人实操心得先把地基打扎实再起高楼到这里基础环境的准备工作算是告一段落了。最后分享几点我自己的体会。第一我强烈建议你在做完这些初始化之后把整个过程整理成一个初始化脚本保存下来。比如init.sh里面包含用户创建、目录规划、JDK安装、SSH免密、时间同步、内核参数调整这些步骤。后续如果再买一台新服务器或者把环境重置了直接跑一遍脚本十分钟就恢复初始状态。我现在手上这套环境就是当时写脚本创建的后来有次手滑把/opt/module删了靠脚本和备份的软件包一晚上就重建回来了。第二路径规划真的值得在一开始就认真想清楚。很多人学习时只想“赶紧把Hadoop跑起来”软件到处乱放等学到后面要装Hive、Spark时环境变量改得一团糟最后只能重装系统。用我上面推荐的/opt/software/opt/module/data这套结构不管以后装多少组件都会很有条理。第三学会看日志。大数据组件本身像一个黑洞出了问题如果不看日志全靠网上搜效率极低。Hadoop的日志在$HADOOP_HOME/logs目录下Hive的日志在/tmp/当前用户下Zookeeper的日志在$ZOOKEEPER_HOME/logs下。养成启动完组件之后先看日志的习惯很多问题的答案就在日志的最后几十行里。接下来第二篇我会在这台服务器上正式部署Hadoop 3.3.6配置HDFS和YARN并验证NameNode、DataNode、ResourceManager、NodeManager各个进程是否按预期工作。到时候见。