1. 大数据技术实战：从选择题到真功夫

看到上面那一大串选择题，你是不是有点头大？这感觉就像学开车，光背交规可不行，不上路永远不知道刹车有多软、方向盘有多重。我干了这么多年大数据，带过不少新人，发现一个通病：原理背得滚瓜烂熟，一到真实项目就懵圈。比如，都知道HDFS是分布式文件系统，但真让你把一个10TB的日志文件从本地传到HDFS，再考虑怎么切分、怎么保证数据不丢，很多人就卡壳了。

所以，这篇指南咱们换个玩法。我们不搞“名词解释大会”，也不搞“选择题海战术”。我们要做的，是把每一个冷冰冰的技术概念，变成一个你亲手可以操作、可以验证、可以踩坑的实战练习。我会带你搭建环境、写代码、跑任务、分析结果，甚至故意设置一些常见的“坑”，让你在解决问题的过程中，真正理解“为什么”。

举个例子，原始题目里问“1PB是多少TB？”（答案是1024）。这知识有用吗？有，但不够。实战中，你更需要知道的是：当老板给你一个1PB的数据集，你该怎么估算存储成本？该用多少台机器？HDFS的块大小设置成128MB还是256MB更划算？数据备份策略怎么定？这些，才是从“知道”到“会用”的关键跨越。

接下来的内容，我会假设你有一台可以操作的Linux服务器（虚拟机就行），咱们从零开始，把大数据技术的核心模块，通过一个个连贯的实战任务串起来。目标很简单：看完之后，你不仅能做对题，更能干好活。

2. 环境搭建与HDFS实战：你的第一个分布式“硬盘”

理论背一百遍，不如动手装一遍。很多初学者倒在了第一步——环境搭建。咱们不用那些一键安装的封装包，就用手动的方式，虽然麻烦点，但你能看清每一个组件是怎么咬合在一起的。

2.1 亲手搭建一个Hadoop伪分布式集群

所谓伪分布式，就是在一台机器上模拟出HDFS的NameNode、DataNode和MapReduce的JobTracker、TaskTracker等角色。这是学习和测试的最佳方式。

首先，确保你的机器有Java环境。然后，我们去Apache官网下载Hadoop 3.x的稳定版本。这里有个小坑：不同版本之间的配置项可能有细微差别，我建议你用和我一样的版本，避免在配置上浪费不必要的时间。

# 1. 下载并解压
wget https://archive.apache.org/dist/hadoop/common/hadoop-3.3.6/hadoop-3.3.6.tar.gz
tar -xzf hadoop-3.3.6.tar.gz -C /usr/local/
cd /usr/local
mv hadoop-3.3.6 hadoop

# 2. 配置环境变量，编辑 ~/.bashrc 文件
export HADOOP_HOME=/usr/local/hadoop
export PATH=$PATH:$HADOOP_HOME/bin:$HADOOP_HOME/sbin
export HADOOP_CONF_DIR=$HADOOP_HOME/etc/hadoop

# 3. 使环境变量生效
source ~/.bashrc

接下来是最关键的配置环节。你需要修改$HADOOP_HOME/etc/hadoop/下的几个核心文件：core-site.xml, hdfs-site.xml, mapred-site.xml, yarn-site.xml。别怕，我带你一个一个过。

core-site.xml里，我们指定HDFS的默认访问地址和临时目录。

<configuration>
    <property>
        <name>fs.defaultFS</name>
        <value>hdfs://localhost:9000</value>
    </property>
    <property>
        <name>hadoop.tmp.dir</name>
        <value>/tmp/hadoop-${user.name}</value>
    </property>
</configuration>

hdfs-site.xml里，配置HDFS的副本数（伪分布式只能设为1）和NameNode、DataNode的数据存储路径。

<configuration>
    <property>
        <name>dfs.replication</name>
        <value>1</value>
    </property>
    <property>
        <name>dfs.namenode.name.dir</name>
        <value>file://${hadoop.tmp.dir}/dfs/name</value>
    </property>
    <property>
        <name>dfs.datanode.data.dir</name>
        <value>file://${hadoop.tmp.dir}/dfs/data</value>
    </property>
</configuration>

配置完成后，执行格式化命令初始化HDFS。注意，这个命令通常只在第一次搭建时执行，重复执行会清空所有数据！

hdfs namenode -format

然后，启动HDFS的所有服务：

start-dfs.sh

用jps命令查看Java进程，如果看到NameNode、DataNode和SecondaryNameNode，恭喜你，你的分布式“硬盘”已经启动成功了！你可以通过浏览器访问 http://localhost:9870 来查看HDFS的Web管理界面，是不是比想象中直观？

2.2 HDFS Shell实战：像操作本地文件一样操作海量数据

现在，你的HDFS就像一个刚格式化的移动硬盘，里面是空的。我们来学习怎么用它。HDFS提供了一套和Linux Shell非常类似的命令，前面选择题里也考到了。

任务一：上传本地文件并验证副本机制

1. 在本地创建一个测试文件 test_data.txt，里面随便写点内容。
2. 在HDFS上创建一个目录 /user/your_username/input。

   hdfs dfs -mkdir -p /user/$(whoami)/input
   

3. 将本地文件上传到HDFS。

   hdfs dfs -put ./test_data.txt /user/$(whoami)/input/
   

4. 查看文件是否上传成功，并检查其详细信息。

   hdfs dfs -ls /user/$(whoami)/input
   hdfs dfs -du -h /user/$(whoami)/input # 查看文件大小
   

这里有个关键点：我们之前设置dfs.replication=1，所以这个文件在HDFS里只有1个副本。在生产环境中，这通常是3。你可以试着修改配置为3，然后重新上传文件（需要先停止服务，删除HDFS上的旧文件，再重启上传），观察Web界面上“Live Nodes”里不同DataNode上的块分布情况。这个动手过程，比你死记“HDFS默认副本数是3”要深刻得多。

任务二：模拟数据节点故障 HDFS的高容错性怎么体现？我们来模拟一下。首先，用hdfs dfsadmin -report查看当前数据节点的状态。然后，找到你的DataNode进程ID，用kill -9命令强行杀掉它。稍等片刻，再去刷新Web界面或再次执行报告命令，你会发现系统依然可用（因为NameNode还在），并且会报告有一个节点死掉了。如果你设置了多个副本，即使一个节点挂了，数据也不会丢失。这就是分布式系统“不怕死”的魅力。

通过这两个实战任务，你对HDFS的理解就不再是“一个分布式文件系统”这么简单了。你会明白，它如何组织目录树（命名空间），数据如何被切分成块（Block），这些块又如何被分散存储和备份。下次再看到关于NameNode、DataNode职责的题目，你脑子里浮现的会是具体的Web界面和命令行操作，而不是抽象的定义。

3. MapReduce深度解析：从WordCount到自定义业务逻辑

MapReduce是大数据处理的“老黄牛”，虽然现在Spark等框架更火，但它的编程模型是基石。很多面试官喜欢问MapReduce，不是要你用，而是要看你是否理解这种“分而治之”的思想。

3.1 解剖WordCount：理解Map和Reduce的血液流动

原始题目里给出了WordCount的例子，我们直接来写一个能跑的。用Java写一个完整的MapReduce程序，包括Mapper、Reducer和Driver。

import java.io.IOException;
import java.util.StringTokenizer;
import org.apache.hadoop.conf.Configuration;
import org.apache.hadoop.fs.Path;
import org.apache.hadoop.io.IntWritable;
import org.apache.hadoop.io.Text;
import org.apache.hadoop.mapreduce.Job;
import org.apache.hadoop.mapreduce.Mapper;
import org.apache.hadoop.mapreduce.Reducer;
import org.apache.hadoop.mapreduce.lib.input.FileInputFormat;
import org.apache.hadoop.mapreduce.lib.output.FileOutputFormat;

public class WordCount {

  // Mapper类
  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());
        // 输出中间键值对，如 <"hello", 1>
        context.write(word, one);
      }
    }
  }

  // Reducer类
  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;
      // 对同一个key（单词）的所有value（1）进行求和
      for (IntWritable val : values) {
        sum += val.get();
      }
      result.set(sum);
      // 输出最终结果，如 <"hello", 5>
      context.write(key, result);
    }
  }

  // Driver：作业配置和提交
  public static void main(String[] args) throws Exception {
    Configuration conf = new Configuration();
    Job job = Job.getInstance(conf, "word count");
    job.setJarByClass(WordCount.class);
    job.setMapperClass(TokenizerMapper.class);
    job.setCombinerClass(IntSumReducer.class); // 使用Combiner优化，在Map端先做一次局部聚合
    job.setReducerClass(IntSumReducer.class);
    job.setOutputKeyClass(Text.class);
    job.setOutputValueClass(IntWritable.class);
    // 输入输出路径从命令行参数获取
    FileInputFormat.addInputPath(job, new Path(args[0]));
    FileOutputFormat.setOutputPath(job, new Path(args[1]));
    System.exit(job.waitForCompletion(true) ? 0 : 1);
  }
}

把代码编译打包成JAR文件，比如wordcount.jar。然后，用我们之前上传到HDFS的文本文件作为输入，运行这个作业。

hadoop jar wordcount.jar WordCount /user/your_username/input /user/your_username/output

运行完成后，去HDFS的output目录查看结果文件part-r-00000。你会看到每个单词及其出现的次数。这个过程看似简单，但请你思考几个问题：

1. 如果你的输入文件有10个，会被分成几个Map任务？这由什么决定？（提示：InputFormat和InputSplit）
2. job.setCombinerClass(IntSumReducer.class)这行代码起了什么作用？如果不用Combiner，网络传输的数据量会有什么变化？
3. 最终输出文件为什么叫part-r-00000？如果Reduce任务有多个，输出文件会是什么样子？

3.2 超越WordCount：设计一个简单的数据清洗任务

只会词频统计可不够。假设你有一份用户行为日志，格式混乱，包含无效数据。你的任务是：过滤掉所有不符合格式的行，并统计每个用户ID的访问次数。日志格式假设为：时间戳,用户ID,操作,页面，例如 2023-10-01 10:00:00,user123,click,homepage。

这个任务需要你：

1. 在Mapper中，解析每一行，检查字段数量是否为4，时间戳格式是否大致正确（可以用正则表达式简单判断），用户ID是否非空。只有通过检查的记录，才输出<用户ID, 1>。
2. 在Reducer中，进行求和统计。

这个练习能让你掌握如何在Map阶段进行数据清洗和过滤，这是实际ETL（抽取、转换、加载）过程中非常常见的操作。写完这个程序并运行成功，你对MapReduce编程模型的理解就上了一个台阶。你会明白，Mapper不只是做拆分，还可以做复杂的判断；Reducer也不只是求和，还可以连接、排序等。更重要的是，你体会到了“移动计算比移动数据更划算”这一核心思想——计算逻辑被分发到存有数据的节点上去执行。

4. HBase与NoSQL实战：告别关系型思维

当你的数据没有固定的表结构，或者需要高速随机读写时，就该HBase上场了。它被称作“面向列的数据库”，但我觉得更准确的理解是“一个有序的、多维度的映射表”。

4.1 HBase快速入门：存储和查询网页索引

我们模拟一个简单的网页索引存储场景。每行数据是一个网页，行键（RowKey）可以用“域名+反转的URL”构成，例如“com.example.www:/page/index.html”。这样，同一个网站的页面会在物理上存储在一起。列族（Column Family）可以设计为“info”（存储标题、抓取时间）和“content”（存储关键词、摘要）。

首先，启动HBase（需要先确保HDFS和ZooKeeper已运行）。然后进入HBase Shell：

hbase shell

创建一张表：

create 'webpage', 'info', 'content'

插入一些数据：

put 'webpage', 'com.example.www:/index.html', 'info:title', 'Example Homepage'
put 'webpage', 'com.example.www:/index.html', 'info:fetch_time', '2023-10-01'
put 'webpage', 'com.example.www:/index.html', 'content:keywords', 'example test homepage'
put 'webpage', 'com.example.another:/about.html', 'info:title', 'About Us'

现在，执行查询：

# 获取整行数据
get 'webpage', 'com.example.www:/index.html'
# 只获取特定列族
get 'webpage', 'com.example.www:/index.html', 'info'
# 扫描表，限定起始行键
scan 'webpage', {STARTROW => 'com.example'}

请特别注意：HBase的scan操作如果没设好STARTROW和STOPROW，可能会触发全表扫描，性能极差。这就是为什么RowKey设计是HBase性能优化的生命线。通过这个简单的例子，你可以直观地感受到HBase的数据模型和操作方式，与MySQL等关系型数据库的INSERT、SELECT截然不同。

4.2 HBase vs. RDBMS：在实战中体会差异

回到原始题目，它考察了HBase和关系数据库的区别。光背“数据模型不同”、“存储模式不同”太抽象。我们来做两个对比实验：

实验一：动态扩展列 在HBase中，给webpage表新增一列info:language，直接插入数据即可，表结构无需预定义。

put 'webpage', 'com.example.www:/index.html', 'info:language', 'en'

而在MySQL中，你需要先执行ALTER TABLE webpage ADD COLUMN language VARCHAR(10);。对于亿级大表，这是一项非常重的操作。

实验二：稀疏存储 假设只有少数页面有content:summary（摘要）这个字段。在HBase中，没有这个字段的行，就完全不存储，节省空间。在关系数据库中，即使该字段为NULL，也会占用存储位置（取决于具体数据库的实现）。你可以通过HBase Shell的count和describe命令，以及HDFS上查看HBase表目录的大小，来感性认识这种稀疏性。

通过动手操作，你会深刻理解NoSQL的“Schema-less”（无模式或弱模式）和“最终一致性”等概念。当你的应用需要处理海量、多变的半结构化数据（比如用户行为日志、物联网传感器数据）时，你会第一时间想到HBase这类工具，而不是试图用关系型数据库去硬扛。

5. Spark核心实战：让大数据处理“飞”起来

如果说MapReduce是重型卡车，那Spark就是跑车。它基于内存计算，速度更快，编程模型也更灵活。我们通过一个完整的Spark应用来感受它的威力。

5.1 用Spark SQL分析电商数据

假设我们有一份电商订单数据的JSON文件，结构如下：

{"order_id": "1001", "user_id": "u123", "amount": 150.5, "category": "electronics", "timestamp": "2023-10-01 10:00:00"}
{"order_id": "1002", "user_id": "u456", "amount": 89.9, "category": "books", "timestamp": "2023-10-01 10:05:00"}

我们的任务是：找出消费金额最高的前3个品类，并计算每个用户的平均订单金额。用Spark SQL来做会非常优雅。

首先，启动spark-shell（确保Spark已安装配置好）。然后一步步操作：

// 1. 创建SparkSession，这是Spark SQL的入口
val spark = SparkSession.builder().appName("EcommerceAnalysis").master("local[*]").getOrCreate()
import spark.implicits._

// 2. 从JSON文件创建DataFrame（可以替换成HDFS路径，如 hdfs://localhost:9000/data/orders.json）
val ordersDF = spark.read.json("file:///path/to/orders.json")

// 3. 将DataFrame注册为一个临时视图，以便用SQL查询
ordersDF.createOrReplaceTempView("orders")

// 4. 执行SQL查询：消费金额最高的前3个品类
val topCategories = spark.sql("""
  SELECT category, SUM(amount) as total_amount
  FROM orders
  GROUP BY category
  ORDER BY total_amount DESC
  LIMIT 3
""")
topCategories.show()

// 5. 执行SQL查询：每个用户的平均订单金额
val avgPerUser = spark.sql("""
  SELECT user_id, AVG(amount) as avg_amount, COUNT(order_id) as order_count
  FROM orders
  GROUP BY user_id
  ORDER BY avg_amount DESC
""")
avgPerUser.show()

// 6. （进阶）使用DataFrame API完成同样的任务，更函数式
val topCategoriesDF = ordersDF.groupBy("category").agg(sum("amount").as("total_amount")).orderBy(desc("total_amount")).limit(3)
topCategoriesDF.show()

运行这段代码，你会立刻看到结果。对比一下，如果用MapReduce来实现同样的分析，你需要写多少Mapper和Reducer？Spark的抽象层次更高，它让你用类似操作本地集合（或者写SQL）的方式去处理分布式数据，生产力提升不是一点半点。

5.2 理解RDD、DataFrame和Dataset：Spark的三驾马车

原始题目里提到了RDD的转换（Transformation）和动作（Action）。我们通过一个例子来厘清它们的关系，并对比RDD和DataFrame。

任务：过滤出金额大于100的电子产品订单，并统计数量。

RDD方式：

val ordersRDD = spark.sparkContext.textFile("file:///path/to/orders.json")
val filteredRDD = ordersRDD.map(line => {
  // 这里需要手动解析JSON，比较麻烦
  // 假设我们用一个简单的库解析出对象order
  // val order = parseJson(line)
  // (order.category, order.amount)
}).filter { case (category, amount) => category == "electronics" && amount > 100 }

val count = filteredRDD.count() // 这是一个Action，会触发真正的计算
println(s"High-value electronics orders: $count")

RDD提供了最基础、最灵活的操作，但你需要自己处理数据的序列化、优化等细节。

DataFrame方式：

val filteredDF = ordersDF.filter($"category" === "electronics" && $"amount" > 100)
val count = filteredDF.count() // 同样是一个Action

DataFrame带有Schema信息（知道每一列的名字和类型），Spark的Catalyst优化器可以对其执行计划进行优化，比如谓词下推、列裁剪等，性能通常比直接操作RDD更好。而且代码简洁得多。

通过这个对比练习，你就能明白为什么Spark社区推荐使用DataFrame/Dataset API。你也会理解“惰性求值”（Lazy Evaluation）——直到调用count()、show()、collect()这类Action操作时，前面定义的filter、groupBy等Transformation才会被真正执行。这种机制让Spark有机会对整个计算流程进行全局优化。

6. 流计算初探：用Structured Streaming处理实时数据

大数据处理不仅有“过去时”（批处理），还有“现在进行时”（流处理）。我们用一个简单的网络日志监控场景来体验流计算。

假设有一个服务器在实时产生访问日志，格式为：时间戳,IP地址,请求路径,状态码。我们想实时统计每分钟每个状态码出现的次数。

Spark Structured Streaming使得流处理可以和批处理用几乎相同的API来实现。

val spark = SparkSession.builder().appName("LogStreaming").master("local[*]").getOrCreate()
import spark.implicits._

// 1. 定义输入源，模拟一个读取目录下新增文本文件的流
val lines = spark.readStream
  .format("text")
  .option("maxFilesPerTrigger", 1) // 每次处理一个文件，模拟流
  .load("file:///path/to/log_stream/") // 生产环境可能是Kafka等消息队列

// 2. 解析数据
val logsDF = lines.as[String].map(line => {
  val parts = line.split(",")
  (parts(0), parts(3)) // (timestamp_minute, status_code) 这里简化了时间戳处理
}).toDF("minute", "status_code")

// 3. 定义流式计算：按分钟和状态码分组计数
val windowedCounts = logsDF.groupBy(window($"minute", "1 minute"), $"status_code").count()

// 4. 定义输出（Sink），这里输出到控制台
val query = windowedCounts.writeStream
  .outputMode("complete") // 每次输出完整的聚合结果
  .format("console")
  .start()

query.awaitTermination()

运行这个程序，然后往监控的目录里不断追加新的日志文件（或者用tail -f模拟），你会在控制台看到每分钟更新一次的统计结果。这就是流计算：数据像水流一样进来，计算持续进行，结果不断更新。

通过这个例子，你可以对比一下它和前面批处理Spark SQL代码的相似度——核心逻辑几乎一样，只是read变成了readStream，write变成了writeStream。这就是Spark“批流一体”的优势。同时，你也要思考流处理特有的挑战：如何处理迟到数据？如何保证 exactly-once（精确一次）的语义？这些是深入流计算领域必须面对的问题。

从HDFS搭建到MapReduce编程，从HBase操作到Spark分析，再到最后的流处理，我们完成了一个完整的大数据技术栈闭环练习。每一个环节，我都刻意避开了单纯的概念复述，而是设计了可以动手、可以观察、可以调试的实战任务。技术的学习，尤其是大数据这种实践性极强的领域，“做”永远比“看”和“背”更有效。当你亲手调通一个Hadoop集群，当你写的第一个WordCount程序跑出结果，当你用Spark SQL瞬间分析完百万行数据，那种理解是深入骨髓的。希望这份指南能成为你大数据实战之路的第一块坚实垫脚石，而不仅仅是另一份需要背诵的题集。遇到问题多查文档、多搜社区、多动手试错，这才是工程师成长的快车道。