HDFS

HDFS（Hadoop Distributed File System）是 Hadoop 的分布式文件系统，负责把海量数据可靠地存在一堆廉价机器上。它的设计目标很明确：用普通商用服务器组成的集群，存下单机装不下的数据，并且允许机器随时坏掉。

• NameNode——管元数据的「账本」。它记录每个文件被切成了哪些块、每个块的副本存在哪些机器上，但不存实际数据。整个集群一个（生产配 HA 双节点），它是 HDFS 的命门：NameNode 挂了，就算数据都在，也没人知道哪个块属于哪个文件。
• DataNode——每台工作节点一个，负责实际存储数据块，并定期向 NameNode 汇报心跳和块列表。
• Block（数据块）——文件被切分的单位，默认 128MB。这个值比普通文件系统的块（4KB）大了几万倍，是刻意为之：块越大，同样的数据量需要的元数据条目越少，NameNode 的内存压力越小；同时顺序读的吞吐也更高。

一、副本机制换可靠性。每个块默认存 3 份，分布在不同机器（通常还跨机架）。任何一台机器挂掉，NameNode 发现副本数不足就自动在别处补一份。代价是存储成本变成三倍，换来的是不用买昂贵的高可靠硬件。

二、一次写入、多次读取。HDFS 只支持追加，不支持随机修改文件中间的内容。这个限制换来了极简的一致性模型和很高的顺序吞吐——而数仓场景本来就是「批量写入、反复扫描」，正好契合。

三、为吞吐而非低延迟设计。它适合一次读几百 MB 做批处理，不适合频繁读取小文件、更不适合毫秒级的随机点查。要点查得上 HBase 之类的系统。

这是 HDFS 上最典型的坑，根因在架构本身：NameNode 把所有元数据放在内存里，一个文件、一个目录、一个块各占约 150 字节。存一个 1GB 的文件占 8 个块，而存一万个 100KB 的小文件要占一万个块——数据量差得远，元数据开销却是上千倍。小文件多到一定程度，NameNode 内存就撑爆了。

连带影响是计算侧：一个小文件通常对应一个 Map Task，一万个小文件就启动一万个 Task，光是启动开销就远超实际计算时间。

HDFS 只负责存。数据怎么算由 MapReduce / Spark 决定，算的时候要多少资源由 YARN 分配。Hive 表的数据本质上就是 HDFS 上某个目录下的一堆文件，分区就是子目录。