核心結論
HDFS 設計定位是**一次寫入、多次讀取**的大數據吞吐場景，為實現高吞吐、高容錯、低成本，在 CAP 定理下選擇 **CP（一致性+分區容忍）**，犧牲了隨機寫入的可用性與靈活性。
架構層面原因
- Block 級追加寫入：數據以 128MB/256MB Block 存儲，DataNode 只支持流式追加，不支持隨機定位修改。
- NameNode 元數據管理：文件創建、重命名、Block 映射由 NameNode 串行化管理，隨機寫將引入極大的鎖競爭與元數據更新壓力。
- 副本一致性協議：Pipeline 複寫機制要求順序寫入所有副本，隨機寫需協調多副本並發修改，極難保證強一致。
- 校驗和機制：每個 Block 有 CRC32 校驗，隨機修改需重新計算校驗和並驗證所有副本，開銷巨大。
設計思想權衡
- 大順序讀優於小隨機讀：MapReduce/Spark 掃描 TB 級數據，順序讀帶寬可達 GB/s，隨機寫會破壞局部性。
- 廉價硬件容錯：商用服務器+普通硬盤，通過副本冗餘實現高可用，隨機寫會放大硬盤尋道延遲，壽命縮短。
- 簡化協議減少 Bug：只支持創建、追加、刪除、重命名，狀態機簡單，易於形式化驗證與運維。
業界變通方案
- HBase / Apache Kudu：在 HDFS 之上構建 LSM-Tree 或列存引擎，支持隨機讀寫、ACID 事務。
- HDFS Append（有限支持）：
FileSystem.append() 允許文件末尾追加，但不支持中間修改，且需啟用 dfs.support.append。
- 覆蓋重寫：讀取舊文件 → 內存修改 → 寫入新文件 → 原子重命名替換，適合小文件、低頻更新。
理解 HDFS 的設計初衷，才能在技術選型時避免「拿錘子找釘子」的誤區。
