HDFS
把大文件切成块，摊在几百台机器上的文件系统
HDFS 是 Hadoop 的地基。它不追求“快”，追求“大”：一个文件被切成 128MB 的块，每块存三份散在不同机器上，任何一台机器坏了数据都还在。代价是不能随机改文件，只能追加和覆盖。
它解决什么问题
数据到了 TB、PB 级，一台机器的硬盘装不下，而且硬盘坏了数据就没了。普通文件系统没法跨机器拼成一个目录。
真实场景：典型场景：业务库每天凌晨导出几亿条订单明细到 HDFS，Hive、Spark 直接读这些文件做报表，原始文件保留 30 天。
核心概念
每个概念一句话 + 一个类比。点击卡片看更详细的解释。
Block
文件被切成固定大小的块（默认 128MB），是存储和计算的最小单位
类比：把一本厚书拆成若干册，每册单独存放和借阅
看概念详情NameNode
记住“哪个文件的哪个块在哪几台机器上”，本身不存数据
类比：图书馆的检索台，只告诉你书在几号书架
看概念详情DataNode
真正存块的工作机器，定期向 NameNode 汇报自己有哪些块
类比：一排排书架，书实际放在这里
看概念详情Replication
每个块存几份，默认 3 份，坏一台机器不影响读取
类比：重要合同复印三份，分别放三个抽屉
看概念详情机架感知
副本尽量放在不同机架，整个机架断电也不丢数据
类比：备份不放同一个保险柜，也不放同一个房间
看概念详情数据流转动画
跟着步骤看一条数据从进入系统到被处理完的完整路径，可以暂停、重播和调速。
一个 300MB 文件是怎么写进 HDFS 的
← 左右滑动查看完整流程图 →
300MB 的文件按 128MB 切成 3 块（128 + 128 + 44），块是存储和计算的最小单位。
提示：注意：客户端只跟 NameNode 要位置，真正的数据流直接走 DataNode，NameNode 不转发数据。 悬停图中的节点可以看概念解释。
优劣势
短句说清适合什么、不适合什么，选型时先看这一栏。
- 容量可以线性扩展，加机器就加容量
- 三副本 + 机架感知，坏机器是常态而不是事故
- 吞吐极高，适合一次写、多次读的大文件
- 和 Hive / Spark / HBase 天然打通，是生态底座
- 不支持随机修改，只能追加（append）或覆盖
- 小文件是灾难：每个文件每个块都占 NameNode 内存
- NameNode 单点（虽然有 HA，但运维复杂）
- 不适合低延迟随机读写，那是 HBase / ClickHouse 的活
常见使用场景
每个场景都配一句「为什么用它」。
离线数仓的原始层
业务库每天同步到 HDFS，作为 ODS 层原始数据长期保留。
为什么用它：存得下、成本低、随时能重跑，原始数据是最后一道保险。
日志归档
Nginx / 应用日志按天写进 HDFS，保留半年以上。
为什么用它：一次写入几乎不再改，正好是 HDFS 最擅长的模式。
作为 HBase / Spark 的存储层
HBase 的 HFile、Spark 的 shuffle 临时数据都落在 HDFS 上。
为什么用它：不用自己实现分布式存储，直接复用副本和容错能力。
常见问题
上手第一个月最容易卡住的地方。
Q1为什么块大小是 128MB，不是 4KB？
块越大，NameNode 需要记的元数据越少，磁盘顺序读的比例越高。128MB 是“寻址时间只占传输时间 1%”的经验值。块太小会让 NameNode 内存爆掉，块太大则并行度不够、小任务浪费。
Q2NameNode 挂了数据会丢吗？
数据不会丢，DataNode 上的块还在，但集群没法读写——因为没人知道块在哪。生产必须做 NameNode HA（Active/Standby + JournalNode），并定期做 fsimage 备份。
Q3小文件问题到底怎么解决？
一个 1KB 的文件也占一个块、一条元数据，1000 万个小文件能压垮 NameNode。办法：写入前合并（HAR / SequenceFile / ORC / Parquet）、用 Spark 重写压缩、或者上 Ozone / 对象存储。
Q4HDFS 能当数据库用吗？
不能。它不支持随机修改、不支持低延迟、没有事务和索引。要按 key 随机读写用 HBase，要做聚合分析用 ClickHouse / Doris，HDFS 只负责“存住”。