點集群實戰(zhàn))
1. 為什么非得在Windows上用VMware搭三節(jié)點集群——而不是直接上云或用Docker很多人看到“大數(shù)據(jù)集群”第一反應(yīng)是這不就該上云服務(wù)嗎點幾下鼠標開三臺ECS配個Hadoop環(huán)境十分鐘完事。但如果你真這么干過很快就會發(fā)現(xiàn)——它根本不是學習環(huán)境而是一個“黑盒運維現(xiàn)場”。你連NameNode的JVM堆內(nèi)存是怎么被自動分配的都看不到更別說觀察DataNode心跳超時觸發(fā)的Block副本重調(diào)度過程。我?guī)н^幾期某高校的實訓課學生一上來就用云平臺跑MapReduce作業(yè)結(jié)果連hdfs dfs -ls /報錯“Connection refused”都不知道該查哪個端口、哪個進程、哪份日志。這就是本地虛擬化不可替代的價值你掌控的是整個Linux內(nèi)核啟動鏈路從GRUB加載、網(wǎng)卡驅(qū)動初始化、systemd服務(wù)依賴圖到Hadoop各組件的Java進程樹全部裸露在你眼皮底下。Windows宿主機VMware Workstation這個組合恰恰是當前最平衡的學習入口它不像VirtualBox那樣在NAT網(wǎng)絡(luò)模式下對端口轉(zhuǎn)發(fā)支持生硬也不像WSL2那樣缺失完整的虛擬網(wǎng)卡設(shè)備抽象比如無法模擬真實的eth0/eth1雙網(wǎng)卡綁定場景。更重要的是VMware的克隆功能能讓你在5分鐘內(nèi)復(fù)制出第三臺虛擬機而不用重復(fù)裝系統(tǒng)、配SSH、調(diào)時區(qū)——這點對學習者太關(guān)鍵了。我試過用Docker Compose拉起三個Hadoop容器表面看是“三節(jié)點”但實際所有容器共享宿主機網(wǎng)絡(luò)命名空間netstat -tuln | grep 9000能看到NameNode監(jiān)聽在0.0.0.0:9000可一旦你進容器里執(zhí)行ping node2得到的永遠是“unknown host”因為Docker默認不建內(nèi)部DNS你得手動改/etc/hosts或搭dnsmasq——這已經(jīng)偏離了學習HDFS架構(gòu)的初衷變成學容器網(wǎng)絡(luò)編排了。所以這個標題里的每一個詞都是經(jīng)過權(quán)衡的“Windows”是絕大多數(shù)學生和轉(zhuǎn)行者的默認桌面系統(tǒng)“VMware”提供了穩(wěn)定可靠的虛擬網(wǎng)卡橋接與NAT混合模式“三臺虛擬機”對應(yīng)Hadoop經(jīng)典部署模型1個Master 2個Slave既避開單點故障的假象又不至于讓資源消耗失控“配置好網(wǎng)絡(luò)環(huán)境”才是真正的分水嶺——不是能ping通就行而是要讓每臺機器的/etc/hosts、ifconfig輸出、route -n路由表、防火墻狀態(tài)全部處于可預(yù)測、可驗證、可回溯的狀態(tài)。后面你會看到很多所謂“集群搭建失敗”90%卡在ssh node2連不上而根源往往是VMware的虛擬交換機vmnet8被Windows Hyper-V服務(wù)劫持導致NAT模式下DHCP分配異常。這不是Hadoop的問題是虛擬化層的隱性依賴。我們接下來要做的就是把這一層依賴徹底顯性化、可控化。2. VMware網(wǎng)絡(luò)模式選型實戰(zhàn)為什么橋接模式在這里是“偽分布式陷阱”剛接觸虛擬化的人常有個誤區(qū)既然要“像真實服務(wù)器一樣”那肯定選“橋接模式Bridged”讓虛擬機直接獲取局域網(wǎng)IP和宿主機平起平坐。聽起來很美但用在三節(jié)點Hadoop集群上它會制造一個極其隱蔽的“偽分布式陷阱”。我們來算一筆賬。假設(shè)你的宿舍WiFi路由器分配的是192.168.1.x網(wǎng)段子網(wǎng)掩碼255.255.255.0。當你把三臺虛擬機都設(shè)為橋接模式它們會從路由器DHCP池里各自領(lǐng)一個IP比如node1192.168.1.101node2192.168.1.102node3192.168.1.103。表面上看ping 192.168.1.102能通ssh node2也能連Hadoop配置文件里寫fs.defaultFShdfs://192.168.1.101:9000似乎也沒問題。但問題出在HDFS的底層設(shè)計邏輯上DataNode向NameNode注冊時上報的是自己hostname -i解析出的IP地址。而hostname -i返回什么它取決于/etc/hosts里怎么配。如果你沒動過hosts文件它默認只映射127.0.0.1 localhost那么hostname -i就會去查DNS而你的路由器DNS大概率不會把node2反向解析成192.168.1.102——它可能返回空或者返回一個完全無關(guān)的IP。結(jié)果就是NameNode的日志里反復(fù)刷著2024-04-15 10:23:41,221 WARN org.apache.hadoop.hdfs.server.datanode.DataNode: Problem connecting to server: node2/127.0.0.1:9000你明明ping node2是通的NameNode卻固執(zhí)地連127.0.0.1因為DataNode告訴它“我的IP是127.0.0.1”。這不是配置錯誤是橋接模式下網(wǎng)絡(luò)身份與邏輯身份的割裂。解決方案放棄橋接改用NAT模式自定義子網(wǎng)。VMware默認的NAT網(wǎng)絡(luò)vmnet8使用192.168.171.0/24網(wǎng)段但它自帶的DHCP服務(wù)經(jīng)常抽風分配的IP不穩(wěn)定。我的做法是關(guān)閉vmnet8的DHCP手動規(guī)劃一個干凈子網(wǎng)比如192.168.200.0/24并給每臺虛擬機靜態(tài)分配IP。具體操作路徑VMware Workstation → 編輯 → 虛擬網(wǎng)絡(luò)編輯器 → 選擇VMnet8NAT模式→ 取消勾選“使用本地DHCP服務(wù)”→ 子網(wǎng)IP改為192.168.200.0 → 子網(wǎng)掩碼255.255.255.0 → NAT設(shè)置里保留默認網(wǎng)關(guān)192.168.200.2。這樣所有虛擬機都通過同一個NAT網(wǎng)關(guān)上網(wǎng)彼此之間二層互通且IP完全可控。提示不要用192.168.1.x或192.168.0.x這類常見家用網(wǎng)段避免和宿主機WiFi沖突。192.168.200.x是個安全的選擇Windows防火墻默認放行這個范圍的入站連接。為什么NAT模式反而更“真實”因為生產(chǎn)環(huán)境中的大數(shù)據(jù)集群節(jié)點間通信從來不是靠公網(wǎng)IP直連而是走內(nèi)網(wǎng)VLAN。NAT模式下的vmnet8虛擬交換機本質(zhì)上就是一個隔離的二層廣播域完美模擬了IDC機柜內(nèi)TOR交換機的角色。你甚至可以在這個網(wǎng)段里額外加一臺CentOS虛擬機當NTP服務(wù)器用chrony同步三節(jié)點時間——這才是Hadoop要求的“集群時間一致性”的落地方式而不是靠宿主機Windows時間服務(wù)瞎湊合。3. 三臺虛擬機的標準化初始化從ISO安裝到SSH免密登錄的完整閉環(huán)很多教程到這里就開始貼Hadoop配置文件了但跳過虛擬機初始化環(huán)節(jié)等于在流沙上蓋樓。我見過太多人卡在ssh node2提示“Permission denied (publickey)”折騰半天才發(fā)現(xiàn)是root密碼沒設(shè)、SELinux開著、或者sshd_config里禁用了密碼登錄。所以我們必須建立一套可復(fù)現(xiàn)、可驗證的初始化流水線。以下步驟我在某實驗室的20臺學生機上批量驗證過耗時控制在12分鐘以內(nèi)。3.1 操作系統(tǒng)選型與最小化安裝選用CentOS 7.9 Minimal ISO非GUI版原因有三一是內(nèi)核版本3.10.0足夠新支持Hadoop 3.x所需的所有cgroup特性二是Minimal版默認不裝X Window、NetworkManager等干擾項systemctl list-units --typeservice里只有37個活躍服務(wù)排查網(wǎng)絡(luò)問題時日志干凈三是社區(qū)支持周期長直到2024年6月才EOL學習期內(nèi)無后顧之憂。安裝時注意分區(qū)方案選“自動分區(qū)”但務(wù)必勾選“加密/home分區(qū)”——這不是為了安全而是強制系統(tǒng)生成/etc/crypttab從而確保dracut在initramfs階段正確加載LVM模塊避免后續(xù)升級內(nèi)核后無法啟動的尷尬。3.2 網(wǎng)絡(luò)配置固化安裝完成后第一件事不是裝Java而是固化網(wǎng)絡(luò)。編輯/etc/sysconfig/network-scripts/ifcfg-ens33網(wǎng)卡名可能為eth0用ip link確認TYPEEthernet PROXY_METHODnone BROWSER_ONLYno BOOTPROTOstatic DEFROUTEyes IPV4_FAILURE_FATALno IPV6INITyes IPV6_AUTOCONFyes IPV6_DEFROUTEyes IPV6_FAILURE_FATALno IPV6_ADDR_GEN_MODEstable-privacy NAMEens33 UUIDxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx DEVICEens33 ONBOOTyes IPADDR192.168.200.101 NETMASK255.255.255.0 GATEWAY192.168.200.2 DNS1114.114.114.114 DNS28.8.8.8關(guān)鍵點在于ONBOOTyes和BOOTPROTOstatic。很多初學者裝完系統(tǒng)發(fā)現(xiàn)ifconfig沒顯示IP就是因為沒改這個。改完執(zhí)行systemctl restart network然后立刻驗證# 必須全部通過才算成功 ping -c 3 192.168.200.2 # 能通NAT網(wǎng)關(guān) ping -c 3 192.168.200.102 # 能通其他節(jié)點先配好node2的IP nslookup node1 # 能解析主機名3.3 SSH免密登錄的工業(yè)級實現(xiàn)Hadoop要求Master能無密碼SSH到所有Slave。網(wǎng)上教程教ssh-copy-id但這是個半吊子方案——它只傳公鑰不處理權(quán)限、不校驗known_hosts、不統(tǒng)一密鑰類型。我們的做法是在Masternode1上生成ed25519密鑰比rsa2048更安全更快然后用scp推送到所有節(jié)點并嚴格設(shè)置權(quán)限# 在node1上執(zhí)行 ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519 -N -C hadoop-cluster # 創(chuàng)建authorized_keys并設(shè)置權(quán)限 cat ~/.ssh/id_ed25519.pub ~/.ssh/authorized_keys chmod 700 ~/.ssh chmod 600 ~/.ssh/authorized_keys # 推送到node2和node3 for host in node2 node3; do scp -o StrictHostKeyCheckingno ~/.ssh/id_ed25519.pub $host:/tmp/id_ed25519.pub ssh $host mkdir -p ~/.ssh cat /tmp/id_ed25519.pub ~/.ssh/authorized_keys chmod 700 ~/.ssh chmod 600 ~/.ssh/authorized_keys done注意StrictHostKeyCheckingno是為了跳過首次連接的yes/no確認但僅限學習環(huán)境。生產(chǎn)環(huán)境必須手動驗證指紋。最后驗證ssh node2 hostname應(yīng)直接返回node2且無任何密碼提示。如果失敗立刻檢查/var/log/secure里sshd的報錯90%是~/.ssh目錄權(quán)限不對必須700或authorized_keys文件權(quán)限不對必須600。這套初始化流程的價值在于它把“環(huán)境差異”壓縮到極致。當三臺虛擬機都完成上述步驟后它們之間的唯一區(qū)別只有IP地址和hostname。這意味著你在node1上寫的Hadoop配置復(fù)制到node2/node3只需改兩行而不是逐個調(diào)試。這才是“可復(fù)現(xiàn)學習”的基石。4. Hadoop 3.3.6單點偽分布到三節(jié)點集群的演進式配置從NameNode格式化到Y(jié)ARN資源調(diào)度驗證現(xiàn)在虛擬機網(wǎng)絡(luò)通了SSH也好了終于可以碰Hadoop了。但別急著下載二進制包——先理解一個關(guān)鍵事實Hadoop沒有“集群安裝包”只有“單機解壓即用包”。所謂集群是通過配置文件把多個單機實例邏輯串聯(lián)起來的結(jié)果。這意味著你必須先在一個節(jié)點上跑通偽分布式Pseudo-Distributed再把它“克隆”到其他節(jié)點最后用配置文件織成網(wǎng)絡(luò)。這個漸進過程能幫你吃透每個配置項的真實作用。4.1 Java環(huán)境與Hadoop解壓的硬性約束Hadoop 3.3.6官方明確要求Java 8u191或Java 11。我推薦用OpenJDK 11因為CentOS 7.9的yum源里就有執(zhí)行yum install java-11-openjdk-devel即可。驗證命令必須是java -version # 輸出應(yīng)含11.0.x echo $JAVA_HOME # 必須指向/usr/lib/jvm/java-11-openjdk-xxx很多教程漏掉第二步結(jié)果Hadoop啟動腳本找不到Java。$JAVA_HOME必須在/etc/profile.d/java.sh里全局設(shè)置內(nèi)容為export JAVA_HOME/usr/lib/jvm/java-11-openjdk-$(arch) export PATH$JAVA_HOME/bin:$PATH然后source /etc/profile.d/java.sh。Hadoop二進制包從官網(wǎng)下載hadoop-3.3.6.tar.gz解壓到/opt/hadoop并創(chuàng)建軟鏈接/opt/hadoop/current指向它——這個軟鏈接很重要未來升級Hadoop時只需改鏈接不用動所有配置路徑。4.2 核心配置文件的“最小必要集”Hadoop有7個XML配置文件但學習初期只需動4個core-site.xml定義HDFS的默認文件系統(tǒng)URIhdfs-site.xml定義NameNode和DataNode的存儲路徑、副本數(shù)mapred-site.xml定義MapReduce運行框架為YARNyarn-site.xml定義ResourceManager和NodeManager的地址其他如hadoop-env.sh只需改JAVA_HOMEworkers文件列出所有DataNode主機名即node2、node3。重點來了這些文件里不能出現(xiàn)IP地址必須用hostname。比如core-site.xml里property namefs.defaultFS/name valuehdfs://node1:9000/value !-- 不是hdfs://192.168.200.101:9000 -- /property為什么因為Hadoop內(nèi)部RPC通信用的是hostname做服務(wù)發(fā)現(xiàn)IP只是傳輸層載體。如果這里寫IP當NameNode向DataNode下發(fā)Block位置時DataNode會嘗試用IP去連但/etc/hosts里沒配IP到hostname的映射就會失敗。4.3 從偽分布到集群的三步驗證法第一步在node1上只啟動HDFSNameNode DataNode執(zhí)行hdfs namenode -format # 格式化只執(zhí)行一次 start-dfs.sh # 啟動 hdfs dfsadmin -report # 查看DataNode是否注冊成功此時jps應(yīng)看到NameNode和DataNode兩個Java進程。如果DataNode沒起來看logs/hadoop-root-datanode-node1.log90%是/opt/hadoop/data目錄權(quán)限不對必須是hadoop用戶可讀寫。第二步把/opt/hadoop整個目錄打包用scp推送到node2和node3并在兩臺機器上執(zhí)行# 在node2/node3上 chown -R hadoop:hadoop /opt/hadoop su - hadoop -c /opt/hadoop/current/bin/hdfs --daemon start datanode注意--daemon start是Hadoop 3的新語法舊教程的hadoop-daemon.sh start datanode已廢棄。此時回到node1執(zhí)行hdfs dfsadmin -report應(yīng)看到2個Live DataNodenode1和node2。第三步加入YARN。編輯yarn-site.xml關(guān)鍵配置property nameyarn.resourcemanager.hostname/name valuenode1/value /property property nameyarn.nodemanager.aux-services/name valuemapreduce_shuffle/value /property然后在node1上執(zhí)行start-yarn.sh。驗證命令yarn node -list -all # 應(yīng)顯示2個RUNNING NodeManager yarn top # 實時查看資源使用至此一個功能完備的三節(jié)點Hadoop集群就跑起來了。你可以上傳一個10MB的文本文件跑個WordCounthdfs dfs -mkdir -p /input hdfs dfs -put /tmp/input.txt /input/ yarn jar /opt/hadoop/current/share/hadoop/mapreduce/hadoop-mapreduce-examples-3.3.6.jar wordcount /input /output hdfs dfs -cat /output/part-r-00000如果輸出里有hadoop 123這樣的統(tǒng)計行恭喜你親手織出的第一張數(shù)據(jù)處理網(wǎng)已經(jīng)可以收發(fā)數(shù)據(jù)包了。5. 集群健康度自檢清單5個命令定位90%的“集群看起來正常但作業(yè)跑不動”問題集群啟動后jps全綠hdfs dfsadmin -report顯示2個DataNode在線yarn node -list也顯示RUNNING但你提交一個簡單的WordCount作業(yè)卻卡在ACCEPTED狀態(tài)半天不動——這種“看起來正常實則癱瘓”的狀態(tài)是學習者最抓狂的時刻。根據(jù)我在某公司大數(shù)據(jù)平臺組駐場支持的經(jīng)驗這類問題90%源于五個被忽略的細節(jié)。我把它們編成一份自檢清單每次作業(yè)卡住按順序執(zhí)行這5個命令基本能定位根因。5.1 檢查NameNode安全模式Safe ModeHDFS啟動后默認進入安全模式等待足夠多DataNode注冊并上報Block報告。如果只有一臺DataNode它可能需要30秒才能完成注冊但如果有兩臺NameNode會等所有DataNode都上報期間拒絕寫操作。執(zhí)行hdfs dfsadmin -safemode get # 返回In safe mode即未退出 hdfs dfsadmin -safemode wait # 阻塞等待退出學習時可用如果長時間不退出看logs/hadoop-root-namenode-node1.log里是否有BLOCK* processReport相關(guān)日志。沒有說明DataNode根本沒連上NameNode回到網(wǎng)絡(luò)配置環(huán)節(jié)。5.2 檢查DataNode磁盤空間與Block上報DataNode注冊成功不代表它能存數(shù)據(jù)。執(zhí)行hdfs dfsadmin -report | grep -A 5 Live datanodes重點關(guān)注Configured Capacity配置容量和DFS Remaining剩余空間。如果DFS Remaining接近0說明磁盤滿了。但更隱蔽的問題是DataNode的dfs.datanode.data.dir指向的目錄其父路徑/opt/hadoop/data可能被root占用因為hdfs namenode -format是用root執(zhí)行的。解決方法chown -R hadoop:hadoop /opt/hadoop/data su - hadoop -c hdfs --daemon restart datanode5.3 檢查YARN ResourceManager資源視圖作業(yè)卡在ACCEPTED大概率是ResourceManager沒給ApplicationMaster分配容器。執(zhí)行yarn scheduler -status # 查看Scheduler類型應(yīng)為CapacityScheduler yarn top | head -10 # 查看實時資源Total vCores, Total Memory如果Total vCores顯示0說明NodeManager沒起來。檢查/opt/hadoop/logs/yarn-*-nodemanager-*.log常見錯誤是Failed to initialize container executor根源是/etc/passwd里hadoop用戶UID小于1000CentOS默認普通用戶從1000開始而YARN默認禁止低UID用戶運行容器。解決方案編輯/etc/passwd把hadoop用戶的UID改成1001然后重啟NodeManager。5.4 檢查MapReduce Shuffle服務(wù)端口ApplicationMaster啟動后會向NodeManager申請容器運行Mapper而Mapper需要連接ShuffleHandler服務(wù)默認端口13562。執(zhí)行netstat -tuln | grep 13562 # 在node2/node3上執(zhí)行應(yīng)看到0.0.0.0:13562如果沒有說明mapred-site.xml里mapreduce.shuffle.port沒配或者NodeManager啟動時沒加載mapreduce_shuffle服務(wù)。檢查yarn-site.xml中yarn.nodemanager.aux-services值是否為mapreduce_shuffle注意下劃線不是短橫線。5.5 檢查HDFS客戶端與服務(wù)端的RPC協(xié)議兼容性最詭異的問題作業(yè)能在node1上跑通但yarn jar命令從node2提交就失敗報錯Call From node2/192.168.200.102 to node1:9000 failed on connection exception。這通常不是網(wǎng)絡(luò)不通而是HDFS客戶端版本和服務(wù)端不一致。執(zhí)行hadoop version # 在node1和node2上分別執(zhí)行必須完全一致如果node2上顯示Hadoop 2.10.2說明你誤裝了舊版Hadoop。解決方案刪掉/opt/hadoop重新解壓3.3.6包并確保/opt/hadoop/current軟鏈接指向正確版本。這份清單的價值在于它把抽象的“集群健康”拆解成5個可執(zhí)行、可驗證、有明確預(yù)期輸出的原子操作。你不需要理解YARN的ApplicationMaster生命周期只要記住“ACCEPTED卡住→先看yarn top→再看netstat→最后看hadoop version”就能在3分鐘內(nèi)定位80%的問題。這才是工程化學習的核心——用確定性操作對抗不確定性故障。6. 學習路徑延伸建議從Hadoop集群到Spark/Flink的平滑過渡實踐當你能把三節(jié)點Hadoop集群跑通WordCount并用hdfs dfs -ls /和yarn application -list熟練管理作業(yè)后下一步不是立刻上Spark而是先做一件被99%教程忽略的事用Hadoop原生工具深入探查數(shù)據(jù)流轉(zhuǎn)的物理路徑。這是建立“數(shù)據(jù)基礎(chǔ)設(shè)施直覺”的關(guān)鍵跳板。比如執(zhí)行完WordCount后不要急著刪/output目錄。先進入NameNode的元數(shù)據(jù)目錄默認/opt/hadoop/name/current/用hdfs oev工具反編譯edits日志hdfs oev -p XML -i /opt/hadoop/name/current/edits_0000000000000000001-0000000000000000002 -o /tmp/edits.xml打開/tmp/edits.xml你能清晰看到CREATE、CLOSE、RENAME等操作序列——原來/output/part-r-00000這個文件是先以臨時名/output/_temporary/0/_attempt_xxx創(chuàng)建計算完成后才重命名為最終路徑。這個重命名操作在HDFS里是一次元數(shù)據(jù)變更不涉及數(shù)據(jù)塊移動。這種認知會讓你在后續(xù)學Spark時立刻明白為什么spark.sql(create table t as select * from s)比df.write.saveAsTable(t)快得多——前者是純元數(shù)據(jù)操作后者要觸發(fā)HDFS的rename。再比如用hdfs fsck /output -files -blocks -locations命令你能看到每個輸出文件對應(yīng)的Block ID、所在DataNode的IP和磁盤路徑。你會發(fā)現(xiàn)同一個Block可能同時存在于node2和node3的/opt/hadoop/data/current/BP-xxx/current/finalized/subdir0/subdir0/下——這就是HDFS副本機制的物理體現(xiàn)。當你轉(zhuǎn)到Spark看到spark.default.parallelism200就能立刻聯(lián)想到如果HDFS只有2個DataNode每個節(jié)點最多承載100個Task并發(fā)讀取Block再多就產(chǎn)生跨節(jié)點網(wǎng)絡(luò)傳輸性能反而下降。基于這個認知基礎(chǔ)向Spark過渡就非常自然下載spark-3.4.1-bin-hadoop3.tgz解壓后只需配置SPARK_DIST_CLASSPATH$(hadoop classpath)讓Spark能加載HDFS客戶端jar。然后寫一個極簡的WordCountfrom pyspark.sql import SparkSession spark SparkSession.builder \ .appName(WordCount) \ .master(yarn) \ .getOrCreate() rdd spark.sparkContext.textFile(hdfs://node1:9000/input/) words rdd.flatMap(lambda line: line.split()).map(lambda word: (word, 1)) counts words.reduceByKey(lambda a, b: a b) counts.saveAsTextFile(hdfs://node1:9000/spark-output/)注意.master(yarn)——Spark Driver會向YARN ResourceManager申請資源而Executor進程就運行在node2/node3的NodeManager容器里。你甚至可以用yarn top實時看到Spark Application占用了多少vCore和內(nèi)存這和之前跑MapReduce作業(yè)的監(jiān)控體驗完全一致。最后提醒一個血淚教訓不要在學習初期就碰Flink。Flink的State BackendRocksDB、Checkpoint機制、Exactly-Once語義都建立在對HDFS文件系統(tǒng)事務(wù)特性的深度理解上。我見過太多人Hadoop的hdfs dfs -du -s /都搞不清單位是字節(jié)還是KB就去調(diào)state.backend.rocksdb.predefined-options結(jié)果集群跑兩天就OOM。穩(wěn)扎穩(wěn)打把Hadoop的logs/目錄里每種日志文件namenode.log、datanode.log、yarn-resourcemanager.log都讀一遍搞懂每一行ERROR前面的時間戳、進程ID、線程名代表什么你才算真正拿到了大數(shù)據(jù)世界的入門鑰匙。