3. 大数据1.0：Hadoop生态系统的诞生，MapReduce与HDFS如何改变数据处理方式
聊到数据网格，很多人会直接跳到数据湖、湖仓一体这些概念。但我个人习惯，还是得先把时间拨回到2006年左右。那时候，我们面对的数据量开始变得“不友好”了——单台机器的硬盘装不下，单颗CPU算不完。
我记得当时在做一个日志分析项目，每天产生的Web日志大概有几百GB。用传统的关系型数据库？导入一次要十几个小时，查询一个简单的PV/UV统计，跑完天都黑了。说白了，那时候的存储和计算，都卡在“单机瓶颈”上。
Hadoop的出现，本质上就干了两件事：把存储拆开，把计算也拆开。你想想看，既然一台机器搞不定，那就让一群机器一起干。这就是Hadoop的核心思想——分布式。
3.1 HDFS：把文件拆成“积木块”
HDFS（Hadoop Distributed File System）是Hadoop的存储层。它解决了一个很朴素的问题：怎么把一个大文件存到一堆廉价的服务器上？
答案是：切块。
一个1TB的文件，在HDFS里会被切成固定大小的块（默认128MB）。然后这些块被分散存储到集群的不同节点上。而且，每个块默认会有3个副本，分别放在不同的机架上。
核心设计理念：
- 块大小（128MB/256MB）： 远大于普通文件系统的4KB。为什么？因为HDFS假设文件很大，大块可以减少元数据量，让NameNode（元数据管理节点）能管理更多文件。
- 副本机制（默认3副本）： 一台机器挂了，数据不会丢。系统会自动从其他副本恢复。
- 一次写入，多次读取： HDFS不支持随机修改。你写进去的文件，只能追加或读取。这设计看着笨，但保证了高吞吐。
我在项目中遇到过一个问题：有人把HDFS当普通文件系统用，频繁地创建小文件（比如几KB的日志）。结果NameNode的内存直接爆了。因为每个文件、每个块都要在NameNode内存里占一条记录（约150字节）。几千万个小文件，内存根本扛不住。
避坑指南： 我曾经因为没控制小文件数量，导致NameNode GC（垃圾回收）长达几分钟，整个集群几乎瘫痪。后来我们强制要求：所有写入HDFS的数据，要么合并成大文件，要么使用HBase这类NoSQL数据库。
3.2 MapReduce：把计算“搬”到数据上
有了HDFS存数据，怎么算？传统思路是把数据拉到计算节点。但数据量太大，网络带宽是瓶颈。
MapReduce换了个思路：把计算程序分发到存数据的节点上。这就是“移动计算而非移动数据”的经典原则。
一个MapReduce作业分两个阶段：
- Map阶段： 每个节点读取自己本地HDFS块上的数据，处理成键值对。这个过程是并行的，互不干扰。
- Reduce阶段： 把Map输出的键值对，按照Key进行分组、聚合、排序，然后输出最终结果。
举个例子，统计一个10TB文本文件中每个单词出现的次数：
// Mapper：读取一行，拆分成单词，输出 (word, 1)
public static class TokenizerMapper
extends Mapper<Object, Text, Text, IntWritable>{
private final static IntWritable one = new IntWritable(1);
private Text word = new Text();
public void map(Object key, Text value, Context context
) throws IOException, InterruptedException {
StringTokenizer itr = new StringTokenizer(value.toString());
while (itr.hasMoreTokens()) {
word.set(itr.nextToken());
context.write(word, one);
}
}
}
// Reducer：对同一个单词的所有1进行求和
public static class IntSumReducer
extends Reducer<Text,IntWritable,Text,IntWritable> {
private IntWritable result = new IntWritable();
public void reduce(Text key, Iterable<IntWritable> values,
Context context
) throws IOException, InterruptedException {
int sum = 0;
for (IntWritable val : values) {
sum += val.get();
}
result.set(sum);
context.write(key, result);
}
}这段代码看着简单，但背后发生的事情很复杂：
- Map任务启动时，会优先调度到存有对应数据块的节点上（数据本地性）。
- Map输出会先写到本地磁盘，然后由系统进行Shuffle（洗牌），把相同Key的数据发送到同一个Reduce节点。
- Reduce节点从多个Map节点拉取数据，排序后合并，最后输出到HDFS。
个人经验： 我刚开始写MapReduce时，总觉得Shuffle阶段是个黑盒。后来调优时发现，很多性能问题都出在Shuffle上。比如Map输出太大导致网络拥堵，或者Reduce拉取数据超时。说白了，MapReduce的瓶颈往往不在计算逻辑，而在数据搬运的效率。
3.3 Hadoop生态的“三驾马车”
HDFS和MapReduce是Hadoop的核心。但光有这两个还不够。在实际项目中，我们很快发现：
- 写MapReduce太麻烦，每个逻辑都要写Mapper和Reducer。
- MapReduce作业之间的依赖管理很原始。
- 非结构化数据（比如JSON、图片）处理起来不方便。
于是，Hadoop生态里又长出了几个关键组件：
| 组件 | 定位 | 我眼中的价值 |
|---|---|---|
| Hive | 数据仓库工具，把SQL翻译成MapReduce | 让数据分析师不用写Java，用SQL就能查大数据。虽然慢，但门槛低了很多。 |
| Pig | 数据流脚本语言 | 比MapReduce更简洁，适合ETL流程。不过后来被Spark和Hive SQL取代了。 |
| HBase | 面向列的NoSQL数据库 | 解决了HDFS不能随机读写的问题。适合实时查询场景，比如用户画像、订单状态。 |
嗯，这里要注意。Hive虽然好用，但它本质上是把SQL翻译成MapReduce作业。这意味着，一个简单的SQL查询，背后可能跑着好几个MapReduce任务。延迟很高，分钟级是常态。所以Hive只适合离线分析，不适合实时查询。
3.4 Hadoop 1.0的局限：为什么我们需要下一代？
Hadoop 1.0确实改变了大数据处理的方式。但它的问题也很明显：
- MapReduce太慢： 每个作业都要读写磁盘（Map输出写磁盘，Reduce输入读磁盘）。对于迭代计算（比如机器学习），这种设计简直是灾难。
- 资源管理粗放： 早期的Hadoop采用“槽位”机制（Map Slot / Reduce Slot）。一个槽位只能跑一个任务，即使这个任务只用了一半内存，其他任务也不能用。资源利用率很低。
- 编程模型单一： 除了MapReduce，你很难在Hadoop上跑其他计算模型（比如图计算、流计算）。
我记得有一次，我们跑一个需要迭代100次的机器学习算法。用MapReduce实现，每次迭代都是一个独立的作业，中间结果都要写HDFS。跑一次要十几个小时。那时候我就想，肯定有更好的办法。
这些局限，直接催生了Spark、Flink、YARN等新一代技术。但这是后话了。
3.5 本章小结：一张图看懂Hadoop 1.0
下面这张图，是我自己总结的Hadoop 1.0核心架构。你可以看到，数据从产生到最终被分析，经历了哪些环节。
这张图里，数据从左边进入HDFS，然后被MapReduce拉取计算，最终通过Hive等工具输出结果。整个过程是“批处理”模式——数据先存好，再慢慢算。这种模式虽然慢，但它第一次让“处理PB级数据”变成了可能。
Hadoop 1.0的意义，不在于它有多快，而在于它证明了：用一堆廉价机器，也能搞定超级计算机才能干的事。这个思想，一直影响到后来的数据网格架构——数据不应该被锁在某个“中心化”的仓库里，而是应该分布在各个域，按需计算。