HDFS 的来历：一篇论文的克隆，和一串不得不

Google 没有做 Hadoop，也没有做 HDFS。 Google 做的是 GFS，2003 年论文发表，从未开源，后继者在 Google 内部叫 Colossus。开源世界拿到的，是对论文的克隆，不是那个系统本身。

克隆是怎么来的。 Doug Cutting 在做网络搜索引擎 Nutch，需要 GFS 论文和 MapReduce 论文里说的那两样东西，就照着论文实现了它们：文件系统那部分成了 HDFS，计算那部分成了 MapReduce。2006 年，这对东西从 Nutch 里拆出来成为独立项目 Hadoop——名字来自他儿子的玩具大象。Yahoo 随后雇了他并资助 Hadoop，论文克隆就这样成了业界默认的大数据文件系统。

为什么非有它不可：动机链。 每一步都逼出下一步，一旦接受第一步，后面就省不掉。

第 1 步：单机两头都不够。 一块盘装不下数据，一台机器读得也不够快。顺序带宽大约 100MB/s 时，读 1TB 要数小时。容量和带宽，单机两头都垮。

第 2 步：切开，摊到很多台便宜机器上。 数据切成片、摊开，就有了并行带宽：很多块盘一起读。但切开本身又造出一个新问题。

第 3 步：得有人记得每片在哪。 文件一旦散开，没有一台 DataNode 知道整个文件。于是必须有一个专职记账者，只管文件到片、片到机器的地图。这就是 NameNode，也是 HDFS 为什么会有一个逻辑上的单一权威。

第 4 步：便宜机器天天坏。 便宜机器的意义就是可以坏，所以只存一份的片一定会丢。答案是跨机器、跨机架复制：每块都存好几份，一台机器死掉只是补副本的活，不是丢数据。

相关。 第 3 步的记账者见 namenode；第 4 步的复制运转见 datanode-heartbeat-and-death；片的大小见 block-size-and-metadata-math。