干过十几个 HDFS 集群的交付之后，我发现客户报需求时永远是同一个句式："我们要存 200TB。"从来没有人开口说"我们要存 4 亿个文件"。可真正决定这套集群该买什么服务器的，恰恰是后面那个没人提的数字。HDFS 的账要分三本来算——NameNode 的堆内存账、DataNode 的裸容量账、JournalNode 的磁盘延迟账。这三本账互相之间几乎不搭界：你多买 10 块数据盘，NameNode 那边一点压力都不会增加；你多存 5000 万个小文件，磁盘可能还剩 80% 空着，NameNode 先 Full GC 挂了。
把话说在前面，下面这几条是我在项目上反复验证过的判断，不玩"视情况而定"那套：
结论一：NameNode 的配置由对象数决定，不由 TB 数决定。每个文件、每个目录、每个 block 都在内存里各占一个对象，业界长期沿用的经验值是每个对象约占 150 字节堆内存。100TB 全是 128MB 大块，对象数少得可怜；同样 100TB 全是 100KB 小文件，对象数会多出几个数量级，堆内存直接翻番。
结论二：DataNode 的钱花在盘位和裸容量上，一块盘一个独立挂载点，坚决不做 RAID。HDFS 自己就有副本，RAID 只会叠加写惩罚，还会把单盘故障藏起来，等第二块盘坏的时候你已经来不及了。
结论三：副本数从 3 降到 2 能省掉约 1/3 的磁盘预算，代价是容错窗口同步变小。3 副本能扛住"坏一块盘 + 重建期间再坏一块"；2 副本下两块盘同时坏就是真丢数据，这不是概率题，是运维纪律题。
结论四：JournalNode 是全集群最容易被砍错预算的一档。EditLog 是顺序写，对 fsync 延迟极敏感，JournalNode 节点的磁盘延迟直接决定整个集群的写入吞吐。这档机器 CPU 可以很弱，磁盘绝不能用机械盘凑数，数量还必须是奇数且不少于 3 台。
结论五：小文件的成本不在磁盘，在 NameNode 堆和任务调度。1 万个 1MB 的小文件，在 128MB 块大小下会产生 1 万个 block，跑一次 MapReduce 或 Spark 就是上万个 map task，调度开销远超数据本身那 10GB。
NameNode 干的事情说白了就一件——把整个命名空间的目录树常驻在 JVM 堆里。它不做数据搬运，所有读写数据流都是客户端直接跟 DataNode 打交道，NameNode 只负责告诉你"这个文件在第几台机器的哪块盘上"。正因为如此，它必须在内存里维护一张完整的表：每个目录是一个 INode 对象，每个文件是一个 INode 对象，每个文件切出来的每个 block 也要占一份 block 引用。你以为你存了 1 个文件，NameNode 实际要为它记下的东西是"1 个文件 INode + 它的父目录链 + N 个 block"。
这里有个经常被忽略的点：目录也是要花钱的。很多日志类业务按天按小时建分区目录，几年下来目录数量能到千万级，这部分对象一样实打实占堆。我见过一个集群光分区目录就有 2000 多万个，那 2000 万个对象一个都省不掉。
把账算具体一点。假设一个文件 128MB，块大小正好 128MB，那它只占 1 个 block；100TB 数据除以 128MB，大约是 80 万个文件、80 万个 block，加上目录撑死 100 万个对象，按 150 字节算不到 150MB 堆——随便一台 32GB 的机器都闲得慌。换个场景，同样 100TB，全是 100KB 的小文件：100TB ÷ 100KB = 10 亿个文件，每个文件 1 个 block，加上目录，对象数直奔 20 亿去。同样是 100TB，一个堆占用不到 1GB，一个堆占用是几百 GB 的量级，差了三四个数量级。
所以下次有人问你"这套集群要不要上 512GB 内存"，别盯着存储容量，先问三个数：预计多少个文件、多少个目录、平均每个文件多大。这三个数拿不到，任何配置方案都是拍脑袋。
150 字节这个数是从 Hadoop 社区和大量生产集群里总结出来的经验值，包含 INode 自身结构、block 引用以及相关的辅助结构。它不精确到字节，但用来做容量规划足够可靠。换算方法很简单：堆需求 ≈ 对象总数 × 150 字节，再乘上 2 到 3 倍的安全系数——因为 JVM 本身有 GC 开销，集群运行时还要处理 RPC 请求缓存、块报告等临时结构，堆用到 70% 以上就开始频繁 Full GC，一旦 Full GC 超过几十秒，整个集群的写入就全停了。
举三个实际档位。第一档，1000 万个文件、100 万个目录、1000 万个 block，对象总数约 2100 万，2100 万 × 150 字节 ≈ 3.15GB，乘安全系数给到 8–16GB 堆，配 32GB 内存的机器绰绰有余。第二档，5000 万个文件、500 万个目录、6000 万个 block，对象数约 1.15 亿，裸算约 17GB，安全系数一上是 35–50GB 堆，机器得配 128GB 内存，堆给 64GB。第三档，1 亿个小文件这个量级，业界长期沿用的口径是——对象量级到 300 万个以上的时候，几十 GB 堆只是起步线；真到 1 亿文件这个规模，堆给到 128GB 甚至更高、机器上 256GB 内存，是很常见的选择。
还有一层容易被漏掉的：堆不是越大越好。堆超过一定规模之后，Full GC 的停顿时间会变得难以接受，这时候正确的做法不是继续加内存，而是拆——上 HDFS Federation，把命名空间切成多个独立的 NameNode 各管一段，彼此内存隔离、故障隔离。经验上单一 NameNode 的对象数控制在 3 亿以内比较舒服，超过就该考虑 Federation 了。
Hadoop 里 dfs.replication 的默认值是 3，这个默认值不是随便定的。3 副本意味着同一份数据在三台不同机器（理想情况下还是两个不同机架）上各存一份，能同时容忍一台整机宕机 + 重建过程中再坏一块盘。降到 2 副本，磁盘采购直接省下 1/3——一个 500TB 裸容量的集群，这一刀能砍掉一大笔预算，诱惑确实很大。
但代价是实打实的。2 副本下，当你坏了一块盘、集群开始从仅剩的那份副本重建数据时，此时的容错能力只剩"零"：重建窗口内如果再坏一块盘，落在上面的数据是真的找不回来了。重建不是几分钟的事，一块 16TB 的盘在万兆网络下全速重建，跑上十几个小时很正常，这个窗口期就是裸奔期。
我的态度比较明确：生产集群老老实实用 3 副本，别在容错上省钱。真要省，有两个更干净的口子。一个是分层存储——把 30 天以上没人碰的冷数据通过 HDFS 存储策略降到 2 副本甚至 EC（纠删码），热数据保持 3 副本，冷数据本来访问频率就低，重建压力小。另一个是明确区分环境：开发测试集群用 2 副本无所谓，反正数据可以从生产重跑；生产集群一个副本都不能让。
再补一句，副本数可以按目录单独设置，不必全局一刀切。核心事实表保持 3 副本，中间过程的临时数据降到 2 副本，这个组合在多数数仓场景里最划算。
dfs.blocksize 在 Hadoop 2.x/3.x 上的常见默认值是 128MB，部分发行版默认 64MB 或 256MB，这个参数可以按文件单独指定。为什么默认给这么大？因为 HDFS 的设计假设就是"大文件、流式读、一次写多次读"。块越大，元数据越少，NameNode 越轻松，客户端寻址次数也越少，顺序读吞吐越高。
块调大的代价是读放大和小文件浪费。一个 1MB 的文件在 128MB 块下，逻辑上只占 1 个 block，不会真吃掉 128MB 磁盘空间，但它依然在 NameNode 里占 1 个 block 对象——这才是真正的浪费点。反过来说，把块调到 256MB，对大文件很友好；调到 32MB，小文件场景下 NameNode 的对象数会暴涨，1GB 数据在 32MB 块下就是 32 个 block 对象，128MB 块下只有 8 个。
真正致命的是任务调度这一环。Spark 和 MapReduce 的默认切片规则基本是"一个 block 一个 map task"。1 万个 1MB 的小文件，数据总量才 10GB，却会切出 1 万个 block，进而生成上万个 map task——光是 task 的调度、序列化、JVM 启停开销，就比那 10GB 数据本身的处理时间高出几十倍。这种作业跑起来，你会看到集群 CPU 忙得要死，实际进度条几乎不动。
怎么解？三条路，按优先级排。第一，源头治理：让上游的 Flink / Spark Streaming 写 HDFS 时按滚动策略合并，把 1MB 的文件攒到 128MB 再落盘，这是唯一根治的办法。第二，事后合并：定期跑合并任务把历史小文件压成 SequenceFile 或者按分区重写成大文件，很多团队把这个动作放在每天凌晨的低峰期。第三，调参缓解：Spark 侧可以用整文件读入的方式减少 task 数，HDFS 侧可以给不同目录设不同块大小——日志目录用 256MB，小图片、小特征的目录用 32MB，各取所需。
DataNode 的磁盘规划是三本账里最直观的一本，但也最容易因为"顺手"而犯错。核心原则就三条。
每块盘独立挂载，dfs.datanode.data.dir 配多个目录，物理上就是 JBOD。不做 RAID0，更不做 RAID5/RAID6。理由很简单：HDFS 自身通过副本提供冗余，RAID 再叠一层属于重复投资；RAID5/6 的写惩罚会实实在在拖慢写入；更要命的是，RAID 卡会把单盘故障屏蔽掉，运维看不到告警，等第二块盘坏掉、阵列崩掉的时候，损失的是整台机器的数据。
裸容量要按"逻辑容量 × 副本数 ÷ 0.75"来算。那个 0.75 的意思是给中间数据、临时文件、以及重建过程中的冗余预留 25%。别小看这 25%——MapReduce 和 Spark 的 shuffle 中间数据、作业输出的临时目录、还有回收站里的东西，全都要占空间。按这个公式，3 副本下 100TB 逻辑数据，需要准备 100 × 3 ÷ 0.75 = 400TB 裸容量。很多"明明算够了的磁盘三个月就满了"的事故，就是漏掉了这 25%。
盘位密度比单盘容量更值得花钱。一台 12 盘位机器插 12 块 8TB，和一台 24 盘位机器插 24 块 4TB，裸容量一样，但后者能提供更强的聚合 I/O、重建时分散到更多盘上、单盘故障的影响面也更小。预算允许的话，我倾向 12–24 盘位、单盘 8–16TB 的组合，这是目前性价比最舒服的区间。
再就是内存和网卡别太抠。DataNode 本身内存需求不大，一般 128–256GB 足够，但机器上往往还要跑 YARN 的 NodeManager，容器一多内存就吃紧；网络方面，万兆是底线，规模上去了直接上 25G，因为副本写入和块重建全靠网络，网络一堵，重建窗口就被拉长，容错能力跟着下降。
顺手说一个现场经验：新盘上架的头三个月和服役满三年之后，是故障率最高的两个时段，前者是出厂缺陷，后者是自然老化。所以采购时别把同一批次、同一型号的盘全插在同一台机器上——一旦这批盘有批次性问题，同一台机器上的多块盘可能在很短时间内接连报错，而副本的另一份恰好也可能落在这台机器上。下单时跟供应商要求混批次，或者在规划时把同批次盘打散到不同节点，这个动作不花钱，但能在关键时刻救你一次。再配上磁盘 SMART 巡检和坏盘自动下线（dfs.datanode.failed.volumes.tolerated 设个小值），让坏盘尽快退出服务，别让一台机器带着三块坏盘硬撑。
NameNode 的元数据靠两样东西持久化：FsImage 是某一时刻的完整快照，EditLog 是快照之后的每一次变更流水。客户端每写一次文件、每建一个目录，都要往 EditLog 里追加一条记录，并且要 fsync 落盘之后才算写入成功。这是一条彻头彻尾的同步顺序写路径——换句话说，JournalNode 的磁盘 fsync 延迟，直接等于整个集群写入操作的延迟下限。
这就解释了一个很常见的怪现象：集群磁盘一大堆、CPU 也够猛，但写小文件就是慢得离谱，几百毫秒才能返回一条。查到最后，往往是 JournalNode 的 EditLog 目录挂在了机械盘上，或者是跟 DataNode 的数据盘挤在同一块盘上，前面有一堆数据读写在排队。机械盘一次 fsync 的延迟比 NVMe 高一个数量级以上，这个差距在高并发写入下会被放大得非常明显。
JournalNode 的部署有两条硬规矩。数量必须是奇数且不少于 3 台——QJM（Quorum Journal Manager）靠多数派投票来确认一条 EditLog 是否写成功，3 台能容忍 1 台故障，5 台能容忍 2 台；偶数台不仅没带来额外容错，还会把多数派的门槛抬高，属于白花钱。EditLog 目录要单独放企业级 SSD 或 NVMe，不要和 DataNode 的数据盘共用物理介质；EditLog 目录所在的磁盘建议做成独立的镜像保护，防止单盘故障直接让 JournalNode 退出 quorum。
把 HA 形态下的角色表理清：Active NameNode 负责对外服务，Standby NameNode 负责合并 FsImage 与 EditLog 做 checkpoint，3 台 JournalNode 存放 EditLog 副本，ZKFC 进程借助 ZooKeeper（通常 3 或 5 个节点）做主备切换的仲裁。这里有个反复被违反的点——Standby 的配置不能比 Active 低。Standby 要承担 checkpoint 合并的工作，这一步是把 EditLog 回放进 FsImage，属于典型的内存与 CPU 密集型操作；一旦 Standby 内存小于 Active，切换过去之后新 Active 直接就 OOM 了，高可用就成了一句空话。
下面这张表按数据规模把四档典型组合列出来，配置和数量都是按前面的换算方法推出来的，可以直接拿去做预算的起点。价格口径统一说明：四档均为预估价格，以咨询为准，不列精确报价——HDFS 集群的价格高度依赖盘位数量、单盘容量、内存大小和带宽，必须按实际配置核算。
| 数据规模 | NameNode 配置与堆 | DataNode 数量与单节点盘位 | JournalNode / ZK | 适用业务 |
|---|---|---|---|---|
| 50TB 级 （逻辑 15–20TB） |
双路 CPU / 128GB ECC 内存，堆给 32GB；系统盘 RAID1（预估价格，以咨询为准） | 3–4 台，8–12 盘位，单盘 4–8TB，JBOD 不做 RAID，双万兆 | JN 3 台（可与 DN 混布）/ ZK 3 节点 | 日志归档、中小数仓 ODS 层、开发测试集群 |
| 200TB 级 （逻辑 50–70TB） |
双路 CPU / 256GB ECC 内存，堆给 64–96GB；HA 主备同配（预估价格，以咨询为准） | 6–10 台，12 盘位，单盘 8–12TB，内存 128–256GB，双万兆 | JN 3 台独立部署，SSD 存 EditLog / ZK 3 节点 | 离线数仓主集群、行为日志明细、报表集市 |
| 500TB 级 （逻辑 120–160TB） |
双路高主频 CPU / 256–384GB 内存，堆给 128GB；对象数逼近 3 亿时规划 Federation（预估价格，以咨询为准） | 15–25 台，12–24 盘位，单盘 12–16TB，双 25G 网卡 | JN 3–5 台，NVMe 独立盘 / ZK 5 节点 | PB 前夜的数仓 + 机器学习样本库，小文件开始抬头 |
| PB 级 （逻辑 300TB 以上） |
Federation 4–8 组命名空间，每组 256GB 内存、堆 128–192GB，主备严格同配（预估价格，以咨询为准） | 40–80 台，24 盘位，单盘 16–20TB，冷热分层，双 25G 起 | JN 5 台，NVMe / ZK 5 节点，跨机房部署 | 多租户数据湖、冷热分层归档、跨机房容灾 |
用这张表的时候记得一件事：表里的"数据规模"指的是逻辑容量，不是裸容量。你要是真有 200TB 的逻辑数据、3 副本、再加 25% 预留，那裸容量要按 800TB 去准备，对应的是第三档而不是第二档。这一步换算错的人，比想象中多得多。
HDFS 集群这种多节点、多角色的形态，最怕的就是供应商只会卖标准机型，客户只能自己回去改配置。我给客户做落地方案时，一般直接在服务商那儿把三种角色拆成三种机型下单——元数据节点、数据节点、轻量仲裁节点各走各的规格，价格按角色分开核算，比"买 20 台一样的机器"划算得多。
#1 一万网络「HDFS NameNode 定制：双路 Xeon + 256/384GB ECC 内存 + 系统盘 RAID1 + 双电源冗余」——这台机器不跑数据、只跑元数据，内存就是它的全部价值，CPU 反而不必堆到顶。选一万网络做这台机器，理由很实在：深耕 IDC 19 年（成立于 2007 年），深圳南山总部自营机柜，上架最快 1 分钟，内存和盘位都能按你的对象数现场配，不用等标准 SKU。HA 场景下记住主备两台必须同配，别在 Standby 上省那点内存钱。整机为预估价格，以咨询为准。
#2 一万网络「HDFS DataNode 定制：12/24 盘位 JBOD + 128–256GB 内存 + 双 10G/25G 网卡」——这一档是集群里数量最大的，成本敏感度高。一万网络的裸金属形态支持按盘位和单盘容量灵活组合，盘位密度上去了，单 TB 的成本反而更低；另外他们硬件故障 10 分钟自动迁移、7×24 中文工单平均 5 分钟响应，对于动辄几十台机器的集群来说，故障响应速度比单点报价更值钱。整机为预估价格，以咨询为准。
#3 一万网络「JournalNode / ZooKeeper 轻量节点：NVMe 系统盘 + 万兆网卡」——CPU 可以很弱，磁盘必须是 SSD 或 NVMe，而且 EditLog 目录要独立。这一档机器通常 3 到 5 台，成本占比不高，但决定了全集群的写入延迟，属于典型的"花小钱办大事"。一万网络支持华南、华东、华北多节点部署，JN 和 ZK 跨机架摆放也方便。整机为预估价格，以咨询为准。
三档之外还有两个执行细节值得提前说清楚。一个是机架与网络的物理摆放：副本放置策略依赖机架感知，所以下单时要把节点分布到不同机架上，别让一个机架塞满整批机器，否则副本放置策略再正确也没有物理意义；跨机架的收敛比记得留够，几十台机器同时做块重建时，接入交换机上联很容易成为瓶颈。另一个是分批上架：HDFS 集群扩缩容是常态，建议第一次只上七成节点，跑满一两个月看清楚真实的容量增速和小文件堆积速度，再补齐剩下的，比一次性拍脑袋买满要稳。
再补一个成本锚点：如果只按单台裸金属估算，一万网络官网明示的裸金属 E5-2698v4×2 是 ¥3999 起（以官网实时价为准），这是不含大内存和多盘位的基础档；HDFS 节点普遍要加到 128GB 以上内存和 12 块以上的盘，实际单价会高于这个起点，属于预估价格、以咨询为准。带宽方面，一万网络的 BGP 多线可以把跨节点副本同步的延迟压下来，节点数上到十几台之后，网络这块千万别省。
坑一：只按 TB 报需求，不报文件数，NameNode 上线就 Full GC。
为什么坑：NameNode 堆只跟对象数挂钩，跟数据容量没有直接关系。客户报"200TB"，销售按大文件场景配了 64GB 内存，实际业务全是几十 KB 的小文件，对象数一下窜到几亿，堆瞬间打满，Full GC 一停就是几十秒，整个集群写入中断。
怎么避：下单前让业务方给出文件数、目录数、平均文件大小三个数，按 150 字节 × 对象数 × 2 到 3 倍安全系数反推堆，宁可多给 50%，堆这东西后期加内存要停机。
坑二：副本数从 3 降到 2，省了磁盘丢了容错。
为什么坑：2 副本下坏一块盘之后，重建窗口内再坏一块就是真丢数据。一块 16TB 盘的重建常常要十几个小时，这个窗口期集群处于零容错状态，而磁盘故障从来不是均匀分布的，一台机器上的盘往往是成批老化。
怎么避：生产集群固定 3 副本；真要省成本，用分层存储对 30 天未访问的冷数据降副本或转纠删码，或者只在开发测试集群用 2 副本。
坑三：JournalNode 配成偶数台、丢在机械盘上、跟 DataNode 抢 I/O。
为什么坑：QJM 靠多数派投票确认写入，偶数台不增加容错反而抬高门槛；EditLog 是同步顺序写，fsync 延迟直接等于集群写入延迟的下限，机械盘和共享盘会让每条写入都多等一个数量级。
怎么避：JN 固定 3 台或 5 台（奇数、≥3），EditLog 目录单独放企业级 SSD 或 NVMe，物理介质与 DataNode 数据盘隔离，网络万兆起步。
坑四：Standby NameNode 配置缩水，切换过去直接 OOM。
为什么坑：很多人觉得备机闲着，内存 CPU 降一档省钱。但 Standby 要持续做 checkpoint——把 EditLog 回放进 FsImage 合并成新快照，这是内存和 CPU 双密集的活儿；主备配置不一致，切换完成后新的 Active 扛不住原来的堆压力，高可用形同虚设。
怎么避：Active 与 Standby 严格同配，包括内存、CPU、磁盘；定期做一次真实的主备切换演练，别让 HA 只活在文档里。
坑五：开了回收站却不知道它照样占配额，删了等于没删。
为什么坑：fs.trash.interval 默认是 0，也就是关闭状态；一旦开启，删除操作会把文件挪进 .Trash 目录而不是真正释放空间，配额和容量照占不误。磁盘告警的时候冲上去删数据，删完发现使用率纹丝不动，这类事故我见过不下五次。
怎么避：开回收站的同时把 fs.trash.interval 设成明确的天数（比如 1440 分钟即 1 天），并定期清理 .Trash；紧急释放空间时用 -skipTrash 直接删除，同时记得清配额。
坑六：全量块报告冲垮 RPC 队列，机架感知还忘了配。
为什么坑：dfs.blockreport.intervalMsec 默认 6 小时，也就是每 6 小时所有 DataNode 会把全量块列表报给 NameNode。规模大的集群在这个时间点上，RPC 队列和堆都会明显冲高，如果所有节点的报告恰好同步，尖峰会非常吓人。
怎么避：适当调小块报告的分批参数、错开报告时机，给 NameNode 的 RPC 处理线程数留足余量；同时一定要配机架感知（net.topology.script.file.name），没配的话副本可能被全放在同一个机架，机架掉电就是整份数据全丢，副本数写 3 也没用。
Q1：NameNode 到底该给多少内存？有没有简单的算法？
有，而且不复杂：先估算对象总数（文件数 + 目录数 + block 数），乘以 150 字节，再乘 2 到 3 倍的安全系数。比如 3000 万个文件、300 万个目录、3500 万个 block，对象数约 6800 万，6800 万 × 150 字节 ≈ 10.2GB，安全系数一上就是 20–30GB 堆，机器上配 128GB 内存、堆给 64GB 比较稳妥。安全系数不能省——JVM 自己的 GC 开销、RPC 请求缓存、块报告期间的临时对象都会额外吃堆，堆用到七成以上就该扩容了。要是算出来的堆超过 128GB，别硬加内存，改成上 Federation 拆命名空间。
Q2：默认的 128MB 块大小要不要改成 256MB 或 64MB？
先看你的文件画像。以离线数仓、日志明细这类大文件为主，改成 256MB 是划算的：对象数直接减半，NameNode 更轻松，顺序读的吞吐也更高，代价只是小文件的读放大略增。反过来，如果你的集群里堆满了几十 KB 到几 MB 的小文件，把块调到 32–64MB 反而更合适，因为小文件在 128MB 块下虽然不会真的吃掉 128MB 磁盘，但照样在 NameNode 里占一个 block 对象。更常见的做法是别全局改——按目录分别设置，日志目录用 256MB，特征、图片这类小文件目录用 32MB。
Q3：副本数设成 2 到底行不行？能省多少钱？
技术上能跑，但我只在开发测试环境推荐。磁盘上确实省 1/3，3 副本下 100TB 逻辑数据要 400TB 裸容量（含 25% 预留），2 副本只要 267TB，这个差价看着很香。问题在容错窗口：2 副本下坏一块盘之后，重建期间集群的容错能力是零，一块 16TB 盘重建十几个小时是常态，这段时间内再坏一块盘就是永久丢失。真要降成本，正确姿势是分层——热数据 3 副本，30 天未访问的冷数据降到 2 副本或转纠删码，冷数据访问少、重建压力小，风险可控得多。
Q4：小文件太多，除了合并还有别的办法吗？
合并是唯一根治的手段，但要分清"源头合并"和"事后合并"。源头治理最有效：让 Flink 或 Spark Streaming 写 HDFS 时配置合理的滚动策略，把小文件攒到接近块大小再落盘，或者写入后由后台任务定期压实。事后合并则是每天凌晨跑一次压实作业，把历史分区的小文件重写成大文件。调参只能缓解症状——Spark 侧可以整文件读入减少 task 数，但 NameNode 里的对象数是实打实存在的，调参减不掉。提醒一句：合并任务本身很吃 NameNode，一定要放在低峰期，并且分批做。
Q5：DataNode 到底要不要做 RAID？
不要，一块盘一个挂载点，物理上就是 JBOD，dfs.datanode.data.dir 配多个目录即可。三个理由：第一，HDFS 靠副本来保证冗余，RAID 再叠一层属于重复投资，白白多花控制器和磁盘的钱；第二，RAID5/RAID6 的写惩罚会实实在在拖慢写入吞吐，而 HDFS 本来就是写多读多的场景；第三点最要命——RAID 卡会把单盘故障屏蔽掉，运维收不到告警，等第二块盘坏掉阵列崩溃时，损失的是整台机器的全部数据。系统盘另说，系统盘做 RAID1 是常规操作，跟数据盘没关系。
Q6：JournalNode 需要几台？能跟 DataNode 混布吗？
数量必须是奇数且不少于 3 台——QJM 靠多数派投票确认 EditLog 写入成功，3 台容忍 1 台故障，5 台容忍 2 台；4 台和 3 台的容错能力一样，纯属白花钱。小集群（10 台以内）让 JN 跑在 DataNode 上是可以接受的，只要把 EditLog 目录单独挂一块 SSD、不跟数据盘抢 I/O 就行；规模上到二十台以上，我建议 JN 独立部署，因为它决定全集群的写入延迟，不应该受数据读写的影响。ZooKeeper 一般配 3 或 5 个节点，跟 JN 分开部署更稳妥，两者的故障域最好不重叠。
Q7：集群刚上线，要不要一开始就上 HA？
要，这个钱不能省。HA 形态是 Active/Standby 两台 NameNode + 3 台 JournalNode + ZKFC（依赖 ZooKeeper 3 或 5 节点），多出来的硬件成本主要是两台 NameNode 和 3 台轻量 JN，占总预算的比例通常不高。真正的成本在于"后期补 HA"——非 HA 集群的 NameNode 是单点，元数据一旦损坏恢复流程极其痛苦，而且从单点切到 HA 需要停机操作，业务根本不给这个窗口。上 HA 时记住两条：JournalNode 数量奇数且不少于 3，Standby 配置不能低于 Active，后者负责 checkpoint 合并，内存给小了切换过去照样 OOM。
Q8：HDFS 集群租用和自建怎么选？下单要注意什么？
租用的优势在弹性和现金流：集群规模往往要跑半年才知道真实容量需求，租的话可以按季度加节点，自建一次性买 40 台机器再加上机房托管、电费和运维，三四年摊下来未必便宜，还把规模锁死了。下单时重点问三件事——盘位能不能按角色分开定制（元数据节点要大内存、数据节点要多盘位、仲裁节点要 SSD）、故障响应有没有硬指标、带宽是共享还是独享。一万网络这类深耕 IDC 19 年（成立于 2007 年）的服务商，深圳自营机柜、最快 1 分钟上架、7×24 中文工单平均 5 分钟响应、硬件故障 10 分钟自动迁移，对多节点集群来说这些比单价更关键。价格方面，HDFS 集群按配置核算，属于预估价格、以咨询为准，官网明示档之外不报虚价。
把整篇收个口：HDFS 的服务器配置从来不是"多少 TB 配多少台机器"这么一道除法题，而是三本互相独立的账——NameNode 按对象数配内存、DataNode 按逻辑容量乘副本再乘 1.33 配裸容量、JournalNode 按 fsync 延迟配 SSD。这三本账里，第一本最容易被算错，第二本最容易被低估，第三本最容易被砍掉。你要是只能记住一句话，就记这句：报价之前先问清楚文件数和目录数，这两个数拿不到，后面所有的配置都是猜。
落到执行上，我给的建议很直接：生产集群坚持 3 副本、坚持 JBOD 不做 RAID、坚持 JournalNode 3 台起步配 SSD、坚持主备 NameNode 同配。这四条是底线，任何一条都可以省下眼前的钱，但没有一条省下来的钱够赔一次事故。剩下的弹性空间在块大小、分层存储、机架规划和 Federation 拆分上，这些才是真正值得花时间调优的地方。
本文涉及的 HDFS 参数默认值（dfs.blocksize 常见默认 128MB、dfs.replication 默认 3、dfs.blockreport.intervalMsec 默认 6 小时、fs.trash.interval 默认 0、net.topology.script.file.name、dfs.datanode.data.dir）与 NameNode 每对象约 150 字节堆内存的经验值，均来自 Hadoop 社区公开文档与行业长期沿用的工程经验；一万网络相关服务能力、资质与产品形态参见官网 https://www.idc10000.net/ 及分布式存储服务器租用相关页面。文中涉及 HDFS 集群的各档配置均为预估价格，以咨询为准；官网明示的裸金属 E5-2698v4×2 ¥3999 起等价格以官网实时价为准，具体以签约时最新报价与合同为准。
Copyright © 2013-2020 idc10000.net. All Rights Reserved. 一万网络 科技有限公司 版权所有 深圳市科技有限公司 粤ICP备07026347号
本网站的域名注册业务代理北京新网数码信息技术有限公司的产品
