前言：一个关于"大"的故事

还记得你第一次听到"大数据"这个词是什么时候吗？

反正我记得很清楚——那是在一次技术分享会上，一位架构师大佬在台上慷慨激昂地说："我们的数据量已经达到了PB级别，传统数据库已经无法满足需求了，我们需要引入Hadoop生态……"

当时的我，内心OS是这样的：

"PB是1000TB吗？那得存多少资源啊"

"我们不都是交易和用户数据吗，有这么多数据量吗?"

"Hadoop听说过？不知道好用不，坑多不多"

多年后的今天，当我终于搞懂了这些概念，并且成功地用Hadoop把集群搞崩了几次之后，我觉得是时候写一个系列来帮助大家——从入门到放弃。

本系列计划分三篇：

1. 第一篇（本篇）：Hadoop概述 + HDFS，先搞懂大象长什么样
2. 第二篇：MapReduce，教大象干活
3. 第三篇：YARN + 生态圈，给大象找一群小伙伴

好了，让我们开始吧。

一、先搞清楚：什么是大数据？

在讲Hadoop之前，我们得先搞清楚——什么是"大数据"？

1.1 数据量的进化史

1.2 大数据的4V特征

小草说，大数据最大的特点就是"大"。它有一个经典的"4V"定义，让我用程序员能理解的方式翻译一下：

1.3 传统方案为什么不行了？

让我们来看一个残酷的现实对比：

这时候，一头大象走了过来，它的名字叫——Hadoop。

二、Hadoop：一头来自Yahoo的大象

2.1 Hadoop的身世之谜

🐘 冷知识：Hadoop这个名字来源于Doug Cutting儿子的一个黄色毛绒玩具大象。所以每当你在凌晨三点调试Hadoop集群的时候，记住——你是在伺候一个毛绒玩具。

2.2 Hadoop的核心架构

Hadoop不是一个单独的软件，而是一个生态系统。但它的核心就三个东西：

用人话说就是：

• HDFS：超大号的网盘，可以存海量数据
• MapReduce：把一个大任务拆成很多小任务，分给很多机器一起干
• YARN：包工头，负责分配谁干什么活

本篇我们重点聊HDFS，MapReduce和YARN留给后面两篇。

三、HDFS：一个能存下整个互联网的文件系统

3.1 设计理念：便宜、大碗、不怕坏

HDFS的设计哲学可以用一句话概括：用一堆便宜货干一件牛逼的事。

HDFS的核心设计假设：

3.2 HDFS架构：主从结构

角色说明

NameNode（名字节点）：

• HDFS的"大脑"，存储所有元数据
• 知道每个文件被切成了哪些块
• 知道每个块存在哪些DataNode上
• 单点故障风险：它挂了，整个集群就废了（所以后来有了HA方案）

DataNode（数据节点）：

• HDFS的"苦力"，存储实际数据
• 定期向NameNode汇报自己还活着（心跳）
• 定期汇报自己有哪些Block

Secondary NameNode：

• 不是NameNode的热备份！
• 只是帮NameNode合并编辑日志，减轻负担
• 名字起得很有误导性，很多人第一次都会理解错

3.3 文件是怎么存的？Block机制

当你往HDFS上传一个文件时，发生了什么？

Block的存储策略

每个Block默认存3份（副本因子=3），这3份怎么放也有讲究：

为什么这么放？

这就是所谓的机架感知（Rack Awareness）策略。

3.4 HDFS读写流程详解

写文件流程

读文件流程

注意：Client直接和DataNode交互读写数据，NameNode只负责告诉Client数据在哪。这样NameNode不会成为性能瓶颈。

3.5 HDFS的优缺点

让我们客观地评价一下这头大象：

3.6 小文件问题：HDFS的阿喀琉斯之踵

这个问题太经典了，必须单独拿出来说。

解决方案：

四、HDFS Shell命令：开始调戏大象

理论讲完了，让我们来点实际操作。HDFS提供了类似Linux的shell命令：

4.1 基础命令速查表

# 查看目录
hdfs dfs -ls /
hdfs dfs -ls -R /user  # 递归查看

# 创建目录
hdfs dfs -mkdir /user/joey
hdfs dfs -mkdir -p /user/joey/data/logs  # 递归创建

# 上传文件
hdfs dfs -put localfile.txt /user/joey/
hdfs dfs -copyFromLocal bigdata.csv /user/joey/data/

# 下载文件
hdfs dfs -get /user/joey/result.txt ./
hdfs dfs -copyToLocal /user/joey/data/ ./local_dir/

# 查看文件内容
hdfs dfs -cat /user/joey/hello.txt
hdfs dfs -tail /user/joey/bigfile.log  # 看最后1KB
hdfs dfs -head /user/joey/bigfile.log  # 看开头

# 删除
hdfs dfs -rm /user/joey/temp.txt
hdfs dfs -rm -r /user/joey/old_data/  # 递归删除
hdfs dfs -rm -skipTrash /user/joey/trash.txt  # 跳过回收站直接删

# 移动/重命名
hdfs dfs -mv /user/joey/old.txt /user/joey/new.txt

# 复制
hdfs dfs -cp /user/joey/data.txt /user/backup/

# 查看文件大小
hdfs dfs -du -h /user/joey/  # 人类可读格式
hdfs dfs -df -h  # 查看HDFS容量

# 修改副本数
hdfs dfs -setrep -w 2 /user/joey/data.txt

# 查看文件状态
hdfs dfs -stat "%F %u:%g %b %y %n" /user/joey/test.txt

4.2 管理命令

# 查看集群状态
hdfs dfsadmin -report

# 安全模式操作
hdfs dfsadmin -safemode get     # 查看是否在安全模式
hdfs dfsadmin -safemode enter   # 进入安全模式
hdfs dfsadmin -safemode leave   # 离开安全模式

# 刷新节点
hdfs dfsadmin -refreshNodes

# 检查文件系统健康
hdfs fsck /
hdfs fsck /user/joey -files -blocks -locations  # 详细信息

五、HDFS的高可用（HA）方案

前面说了，NameNode是单点故障。那怎么办？Hadoop 2.0引入了HA方案：

核心组件说明：

故障切换流程：

六、HDFS Federation：联邦机制

当数据量大到一个NameNode也扛不住时（元数据太多），就需要Federation了：

Federation的思路就是：横向扩展NameNode，每个NameNode管理一部分命名空间，但共享同一批DataNode。

七、本篇小结

让我们用一张图总结一下今天学到的内容：

八、写在最后

到这里，Hadoop系列的第一篇就结束了。我们认识了这头来自Yahoo的大象，了解了它的设计哲学，深入研究了HDFS这个分布式文件系统。

说实话，HDFS的设计理念在今天看来依然很优雅：

• 用便宜的硬件做可靠的存储——这种"穷人思维"反而是最实用的
• 数据冗余保证可靠性——不怕坏，大不了再复制一份
• 计算向数据移动——山不过来，我就过去

下一篇，我们将学习如何让这头大象干活——MapReduce计算框架。

预告一下下一篇的内容：

• MapReduce的编程模型
• Word Count是怎么被Map和Reduce的
• Shuffle过程详解（重点！）
• MapReduce的优化技巧

如果你现在已经感觉到了一丝丝头疼，那恭喜你——你正式踏上了大数据的不归路。

下一篇见！🐘

本文作者：一个在HDFS上丢过数据的程序员

上一次丢数据原因：以为Secondary NameNode是热备

下期预告：《大数据之Hadoop从入门到放弃(二)——MapReduce：教大象干活》

附录：常见面试题

既然都学了，顺便准备一下面试吧：

1. HDFS的Block大小为什么是128MB而不是更小？

   减少寻址时间占比。如果Block太小，寻址时间就会占传输时间的大头，效率低下。

2. NameNode的SafeMode是什么？

   启动时的只读模式，等待DataNode汇报Block信息，达到最小副本要求后自动退出。

3. HDFS的副本放置策略是什么？

   第一副本放本地/随机节点，第二副本放同机架不同节点，第三副本放不同机架。

4. Secondary NameNode的作用是什么？

   定期合并FsImage和EditLog，减轻NameNode重启时的恢复时间，不是热备！

5. HDFS不适合存什么样的数据？

   大量小文件、需要低延迟访问的数据、需要频繁修改的数据。

参考资料

• 《Hadoop权威指南》
• 《大数据Hadoop 3.x分布式处理实战》
• 小草说----大数据和机器学习为什么这样火
• 尚硅谷Hadoop教程