企业官网建设流程全解析

简介：这份《大数据技术原理和应用操作》试卷A卷及答案面向大数据专业学生、考研复习者及准备Hadoop生态认证的开发者，用于检验对HDFS架构、MapReduce流程、Zookeeper、Hive、Sqoop、Flume等核心组件的掌握程度。试卷按单选、多选、判断、填空、简答五种题型编排，覆盖Hadoop集群部署、Zookeeper选举机制、Sqoop数据导入导出、Hive表插入、大数据应用场景等高频考点，并附有完整参考答案与简答要点，方便对照自测与查漏补缺。资源为1个PDF文件，资源包大小仅196KB，内容紧凑可直接打印使用，适合题库训练或考前突击。已有1450人下载学习，题目设置注重理论联系实践，对理解大数据技术原理、熟悉集群操作命令和搭建流程均有实用参考价值。

1. 一份大数据试卷能暴露什么：用这套A卷给知识体系做个扫描

去年给一个刚转行大数据开发的新同事做集群摸底，我先让他做了一套题，再安排他上机操作。结果很有意思：考前背了三天命令的人，单选题做得全对，真到了用jps排查进程、解释 Shuffle 为什么影响性能的时候，反而卡了壳。这套《大数据技术原理和应用操作》试卷 A 卷，正好覆盖了 HDFS 主从架构、Zookeeper 选举、Hive 安装模式、Flume 的 event 模型、Sqoop 导入导出这些大数据入门必碰的知识点，单选、多选、判断、填空、简答五种题型都有。它不教你如何安装部署集群，但能帮你快速扫出知识体系里的盲区，适合备考、面试前自测，也适合带新人的老手拿来做一次基础摸底。下面我把每类考点拆开，讲清楚为什么这么答，以及答完之后怎么到集群上验证。

2. Hadoop 核心概念：从主从架构、进程变迁到配置文件目录

这套卷子里，单选题前十题里有一半在考 Hadoop 的架构、进程、配置目录和部署细节。这些知识点看似基础，实际上一线运维最先接触的就是它们。集群起不来、配置文件改错、进程名对不上，都跟这几分有关。

2.1 HDFS 主从架构与 Block 副本数：为什么默认是 3 份

HDFS 采用的是主从架构，单选第 3 题选 B。NameNode 是 Master，负责管理文件系统的命名空间和元数据；DataNode 是 Slave，真正存储数据块；SecondaryNameNode 负责定期合并元数据镜像，它不是热备节点。很多人把 SecondaryNameNode 当成 NameNode 的备份，这是理解偏差。

主从架构带来的一个直接问题是单点故障，这也是简答题第 4 题的考点。当 NameNode 宕机，客户端就没办法获取文件地址映射，整个 HDFS 就不可访问。判断一个节点是否正常，最直接的方式是使用jps：

jps -l # 期望看到 NameNode、DataNode、SecondaryNameNode # 以及 ResourceManager、NodeManager（YARN 相关）

jps -l会列出当前机器上所有 Java 进程，-l参数会输出完整主类名，避免看到的是别的 Java 程序。如果jps里看不到 NameNode，先用ps -ef | grep java补查一下，确认是进程真的没起来，还是jps因为权限看不到别人启动的进程。

Block 默认保存 3 份，单选第 8 题选 A。这个 3 是hdfs-site.xml里dfs.replication的默认值。为什么是 3 份而不是 2 份或 4 份？常见的考虑是：一份本地副本、一份同机架副本、一份跨机架副本，兼顾容错和带宽消耗。如果副本数设成 2，机器故障时数据丢失的概率明显上升；设成 4，存储开销增大，写数据的网络开销也跟着涨。生产环境里，冷数据调到 2、热点数据调到 3 是常见做法。

修改已有文件的副本数不需要改配置文件，直接执行：

hdfs dfs -setrep -R 2 /user/hadoop/data # -R 表示递归，对目录下所有文件生效 # 2 表示把副本数调整为 2 份

注意-setrep只对已存在的文件生效，改配置文件里的dfs.replication只影响后续新写入的文件。如果你发现某个目录下的文件副本数一直降不下来，优先检查是不是文件还在写入中，或者 DataNode 数量本身不够。

2.2 Hadoop2.x 的进程变迁：JobTracker/TaskTracker 为什么退出历史舞台

单选第 5 题问 Hadoop2.x 独有的进程，答案是 NodeManager。要理解这个答案，得知道 Hadoop 1.x 和 2.x 在架构上的差别。

Hadoop 1.x 里，JobTracker 同时负责资源管理和作业调度，TaskTracker 在 Slave 节点上执行 Map 和 Reduce 任务。JobTracker 的压力非常大，而且它有单点问题，成了整个集群的瓶颈。Hadoop 2.x 引入 YARN 之后，职责被拆开了：ResourceManager 管资源，每个作业的调度交给 ApplicationMaster，节点上的执行进程叫 NodeManager。对照关系如下：

所以 NodeManager 是 Hadoop2.x 相对于 1.x 独有的进程，单选第 5 题选 C。ResourceManager 和 NameNode 一样属于 Master 角色，DataNode 和 NodeManager 属于 Slave 角色，这些角色的对应关系在多选题里也会反复出现。

还有一个关联考点是多选第 8 题的 Google 三驾马车：MapReduce、GFS、BigTable。Hadoop 生态里的 MapReduce、HDFS、HBase 分别对应这三个设计思路，理解了这层对应关系，很多题目不用背也能推出来。

2.3 配置文件目录与自定义配置：bin 和 etc 不能记混

单选第 6 题问存放 Hadoop 配置文件的目录，答案是 etc。这是一个看起来简单、实际非常容易记混的点。Hadoop 解压目录下有三个目录经常被搞混：

• bin：存放hdfs、yarn、mapred这些可执行命令
• sbin：存放start-dfs.sh、stop-dfs.sh等管理脚本
• etc：存放所有配置文件

判断题第 8 题说“在 Hadoop 的解压目录下的 bin 目录，存放的是 Hadoop 的配置文件”，这句话是错的，配置文件在 etc 目录下。实际查看目录结构的时候，可以用find命令确认：

find $HADOOP_HOME -maxdepth 3 -type d | grep -E '/(bin|sbin|etc)$' # bin 放可执行文件，sbin 放管理脚本，etc 放配置文件

多选第 4 题问自定义配置时编辑哪些文件，正确答案是 A、B、C、D 全选，也就是core-site.xml、hdfs-site.xml、mapred-site.xml、yarn-site.xml这四个文件。每个文件管的事不一样，记清楚它们在排障时能少走弯路：

查看当前生效配置是排查问题的第一步，不要凭记忆猜参数：

cat $HADOOP_HOME/etc/hadoop/hdfs-site.xml | grep -v '<!--'

实际使用中，改完配置文件必须重启对应服务才会生效，这个动作经常被忽略。另外，改hdfs-site.xml里的dfs.namenode.name.dir这种关键路径时，要确认目录权限正确，否则 NameNode 会启动失败。

2.4 Shuffle 与 static：两个容易被忽略的细节

单选第 9 题问决定整个 MapReduce 程序性能高低的阶段，答案是 Shuffle。很多人凭直觉选 MapTask 或 ReduceTask，实际上真正影响性能的关键在 Shuffle 阶段：Map 端输出要经过分区、排序、溢写，Reduce 端要拉取数据、合并、再次排序，这些操作跨节点进行，涉及大量的磁盘 I/O 和网络传输。

相比之下，分片和格式化数据源只是准备工作，MapTask 的计算是局部处理，ReduceTask 的计算量往往不大，瓶颈几乎都出在数据怎么从 Map 端传到 Reduce 端。这也是为什么调优 MapReduce 程序时，先看 Shuffle 相关参数，比如mapreduce.reduce.shuffle.parallelcopies（Reduce 端并行拉取 Map 输出的线程数）和缓冲区大小。

单选第 10 题问固定 IP 地址时路由协议怎么配，答案是 static。这个知识点在考试里是送分题，在实际部署里却非常关键——集群节点 IP 如果不固定，NameNode 和 DataNode 之间的地址就会乱套。Linux 网卡配置的常见做法是：

vi /etc/sysconfig/network-scripts/ifcfg-ens33 # BOOTPROTO=static # IPADDR=192.168.1.110 # GATEWAY=192.168.1.1 # DNS1=114.114.114.114 systemctl restart network

注意网卡名字不一定是ens33，CentOS 7 和 CentOS 8 的命名规则有差异，先执行ip addr确认实际网卡名。改BOOTPROTO之后如果不重启网络服务，新配置不会生效。这个细节在考试里只是一个选项，在部署虚拟机集群时是会让你翻车的点。

3. 生态组件考点：Zookeeper、Hive、Flume、Sqoop 的运作细节

试卷的多选、填空和简答题大量涉及 Hadoop 周边组件。这些组件平时用得不少，但如果不刻意梳理，很容易出现“命令会敲、原理说不清”的情况。

3.1 Zookeeper 的 get 命令与选举状态机

单选第 1 题问获取 Zookeeper 所包含信息的 Shell 命令，答案是 get。Zookeeper 的命令行里，ls是列出子节点，get是获取指定节点的数据和元信息，两者差别很明显。区分不清楚，多半是因为把 Zookeeper 的ls和 Linux 的ls混在一起了。

实际操作中，连接 Zookeeper 集群后用get查看配置节点是高频操作：

$ZOOKEEPER_HOME/bin/zkCli.sh -server node01:2181 # 连接成功后执行：get /myapp/config # 返回节点数据 + 事务ID、版本号等元信息

参数-server指定 Zookeeper 服务器地址，端口默认是 2181。get返回的内容里除了业务数据，还有czxid、mzxid、version这些元信息，这些字段在做分布式锁、配置变更排查时很有用。

多选第 6 题考 Zookeeper 选举的四种状态，答案是竞选状态、随从状态、观察状态、领导者状态，对应源码里的LOOKING、FOLLOWING、OBSERVING、LEADING。选举机制判断题里说“采用 FastLeaderElection 算法，投票数大于半数则胜出”，按教材口径是对的。但要注意，FastLeaderElection 只是 ZAB 协议里的一种选举实现，Zookeeper 还出现过其他选举算法，严格说“实际上就是 FastLeaderElection”这个表述并不完全严谨。考试按卷面答案答，到了生产环境排查选主问题时，要结合日志看具体走的是哪条路径。

3.2 Hive 安装模式与插入语法：嵌入、本地、远程怎么选

填空第 3 题问 Hive 的安装模式，答案是嵌入模式，另外两种是本地模式和远程模式。这三种模式的区别在于元数据存储位置：

嵌入模式用的是 Derby，配置最简单，但只支持一个会话连接，多人同时用就会报锁冲突。本地模式和远程模式都依赖 MySQL 存储元数据，差别在于 MetaStore 服务跑在哪里。实际生产中基本都用远程模式，把 MetaStore 拆出来独立部署，不然频繁的元数据读写会拖垮 HiveServer2。

简答题第 1 题问启动 Hive 的方式，参考答案是bin/hive和bin/hiveserver2。这是两种启动入口：bin/hive是命令行交互接口，适合临时查询；bin/hiveserver2是启动一个常驻服务，客户端通过beeline连上去执行 SQL，这是实际项目里最常用的方式。

多选第 10 题考 Hive 插入数据时insert之后跟什么关键字，正确答案是 into 和 overwrite。两者的区别用一段 SQL 就能说清：

INSERT OVERWRITE TABLE dwd_orders PARTITION (dt='2024-01-01') SELECT order_id, user_id, amount FROM ods_orders WHERE dt='2024-01-01'; -- OVERWRITE 会先清空目标分区再把数据写进去 -- INTO 是追加写入，不清空已有数据

实际开发里，INSERT OVERWRITE用于每天重建分区表，INSERT INTO用于增量追加。如果把OVERWRITE用错地方，会把整张表的历史数据覆盖掉，这个操作的破坏性很大，执行前一定先确认分区条件写对了。

3.3 Flume 的 event 模型与 Channel 缓冲：一次收集的完整链路

填空第 1 题问 Flume 核心流程里收集的数据汇集到哪里，答案是缓冲通道，也就是 Channel。Flume 的三段式结构是 Source、Channel、Sink：Source 从数据源采集数据，Channel 做缓冲，Sink 把数据写到目的地。

简答题第 3 题问什么是 event，参考答案是“Flume 内部数据传输的基本单元，一个完整的 event 包含 headers 和 body”。headers 里存一些标识信息，body 里才是真正收集到的数据。理解 event 模型，才知道为什么 Flume 能支持多级 Agent 串联——每一级之间传递的就是 event。

一个最简单的 Flume Agent 配置长这样：

a1.sources = r1 a1.channels = c1 a1.sinks = k1 a1.sources.r1.type = spooldir a1.sources.r1.spoolDir = /data/logs a1.channels.c1.type = memory a1.channels.c1.capacity = 1000 a1.sinks.k1.type = hdfs a1.sinks.k1.hdfs.path = /flume/events

spooldir类型的 Source 会监控目录下新增的文件，memory类型的 Channel 把 event 缓存在内存里，capacity控制缓存容量，Sink 类型是 HDFS，把数据写到指定路径。这套配置对应填空题里的“数据源（Source）→ 缓冲通道（Channel）→ 接收器（Sink）”结构。Channel 还有一个file类型，落盘保存，可靠性更高但吞吐量相对低，生产环境的取舍就是在这两者之间做权衡。

填空第 10 题里 Flume 分两个版本，答案是 Flume-og 和 Flume-ng。Flume-og 是旧版，Flume-ng 是重构后的版本，现在用的都是 Flume-ng 这一支。遇到老文档里的 Flume-og 配置不要直接照搬，两者的 Source 和 Sink 类型命名有不少差异。

3.4 Sqoop 的导入导出参数：import 和 export 之外还有什么

多选第 7 题问 Sqoop 指令的参数，正确答案是 import 和 export。题干里的 output、input 是干扰项，Sqoop 命令里根本没有这两个子命令。实际用 Sqoop 从 MySQL 导数据到 HDFS，一条命令就能说明白：

sqoop import \ --connect jdbc:mysql://node01:3306/bigdata \ --username root \ --password 123456 \ --table orders \ --target-dir /user/hive/warehouse/orders \ --m 4 \ --fields-terminated-by '\t' # --connect 指定 JDBC 连接串 # --m 4 表示用 4 个 MapTask 并行导入 # --fields-terminated-by 指定写入 HDFS 后的字段分隔符

--m 4这个参数最容易踩坑：并行度过高，MySQL 会被压垮；表没有主键时，还要额外加--split-by order_id指定分片列，否则任务直接报错。export是反向操作，把 HDFS 上的数据写回关系型数据库，参数和 import 类似，只是--table和--target-dir的含义对调。

填空第 8 题问部署 Sqoop 时，在sqoop-env.sh配置文件里需要添加哪个环境，答案是 Hadoop。这个文件里要配置HADOOP_HOME，Sqoop 启动时才能找到 Hadoop 的相关库。如果这个环境变量没配好，执行sqoop import时最常见的报错就是找不到 Hadoop 类库，或者 HDFS 地址无法解析。

4. 把试卷知识点变成上机验证：jps 排查、WordCount 与 crontab 实操

做题只能检验记忆，命令行才能检验理解。这套卷子里不少题目，其实都能变成一条具体的验证命令。把答案拿到集群上跑一遍，比反复背十遍管用。

4.1 用 jps 检查 Namenode 是否正常：从考试答案到排障入口

简答题第 5 题问如何检查 NameNode 是否正常运行，参考答案是使用jps命令。这道题按 6 分简答的标准，只答jps三个字母是拿不满分的。完整做法是：

jps -l # 能看到 NameNode 进程说明进程还活着 # 但“活着”不等于“健康” hdfs dfsadmin -report # 关注 Live datanodes 数量 # 以及每个 DataNode 的剩余空间

jps只能判断进程是否存在，NameNode 进程在，不代表集群正常。实际排查中，jps看到 NameNode 存在，但客户端一直报连接超时，这时候要看 NameNode 的日志：

tail -100 $HADOOP_HOME/logs/hadoop-hadoop-namenode-*.log

这套卷子里填空第 9 题考“什么时候说明 Hadoop 集群格式化成功”，答案是出现successfully formatted。这个知识点也跟 NameNode 排查相关：格式化成功只是第一步，格式化完之后还要启动 HDFS、确认 DataNode 注册上来，整个集群才真正可用。强烈不建议随便执行hdfs namenode -format，它会清空 NameNode 上的元数据，生产环境里执行之前一定要确认这是一台全新的机器，否则等于把整个集群的数据目录清掉，这是很多新手踩过的血泪坑。

4.2 手动跑一次 WordCount，验证 _SUCCESS 与 part-r-00000

判断题第 4 题说“Hadoop 集群执行完 MapReduce 程序后，会输出 _SUCCESS 和 part-r-00000 结果文件”，这句话是对的，但实际跑的时候有个细节容易被忽略：_SUCCESS文件出现只代表作业框架执行完了，不代表结果一定正确。

手动执行一次 WordCount，把所有环节看一遍：

hadoop jar \ $HADOOP_HOME/share/hadoop/mapreduce/hadoop-mapreduce-examples-*.jar \ wordcount /input /output hdfs dfs -ls /output # 期望看到 _SUCCESS 和 part-r-00000

part-r-00000里的r表示这个文件来自 Reduce 端输出，00000是分区编号。如果作业只有 Map 没有 Reduce，输出文件会叫part-m-00000。作业结束后，先hdfs dfs -cat /output/part-r-00000看一下内容，确认结果不是空文件，再去做下一步数据处理。

很多时候 MapReduce 进度条显示map 100% reduce 100%，但part-r-00000是空的，原因多半是输入路径下没有匹配到数据，或者过滤条件把数据全滤掉了。考试里这道判断题容易选错，就是因为只记住了“有输出文件”这个现象，没理解_SUCCESS和实际结果文件之间的区别。

4.3 crontab 5 段表达式与 Hadoop HA：两个高频考的边界问题

多选第 5 题考 crontab 表达式，参考答案里有一个说法是“crontab 表达式是由 6 个参数决定”，这个说法在 Linux 实战里很容易让你翻车。Linux 系统自带的 crontab 标准是 5 段：分、时、日、月、周。所谓 6 段，通常是某些教程把“秒”位也算进去了，但 Linux 的 cron 默认不支持秒级调度。

crontab -e 0 2 * * * /opt/scripts/data_clean.sh >> /var/log/data_clean.log 2>&1 # 字段依次是：分 时 日 月 周 # 上面表示每天凌晨 2 点整执行一次数据清洗脚本

如果真要做秒级调度，常见做法不是硬凑 6 段，而是用循环加sleep，或者改用支持秒级调度的调度平台。考试答题按卷面答案走，但到了集群上写定时任务，以 Linux 实际行为为准，这是书本和实战的一个典型差异点。

判断题第 9 题考 Hadoop HA，题干说“启动两台或两台以上机器充当 NameNode，避免一台 NameNode 节点发生故障导致整个集群不可用”，这句话按教材口径是对的。不过这里有一条边界：光启动两台 NameNode 不算完整的 HA，还得配置 JournalNode 共享编辑日志、配置 ZKFC 做自动故障转移，同一时刻只有一台 Active、一台 Standby。如果两台 NameNode 同时进入 Active 状态，会造成脑裂，反而比单点更危险。

5. 避坑指南：这套试卷里几个容易答错、容易跟实战冲突的知识点

这套卷子整体质量不错，但有那么几道题，答案和实战细节之间有落差，或者本身就是容易混淆的知识点。我把最常见的几个坑列出来，每条按“现象 → 原因 → 解决”梳理一遍。

5.1 判断题第 8 题：bin 目录里到底放的是什么

现象：不少人认为 Hadoop 的配置文件放在 bin 目录下，导致判断题第 8 题答错。
原因：解压目录下目录太多，bin 和 etc 的名字一混就乱。bin 里装的是hdfs、yarn这些可执行命令，配置文件全部在etc/hadoop下，而sbin里装的是启动/关闭脚本。
解决：用find把目录结构列出来，看一次就忘不掉：

find $HADOOP_HOME -maxdepth 3 -type d | grep -E '/(bin|sbin|etc)$'

这三个目录的用途要记成一组，bin对应可执行命令，sbin对应管理脚本，etc对应配置文件。排障时要找配置先看etc，要找启动脚本先进sbin，这个顺序能省很多时间。

5.2 Windows 平台运行 Hadoop：为什么“配完就能跑”是错的

现象：判断题第 10 题说“安装配置 Windows 平台 Hadoop，配置后直接运行是没有问题的”，答案是错的。实际在 Windows 上执行hadoop命令，经常报错Failed to locate the winutils binary in the Hadoop distribution。
原因：Hadoop 发行包里不包含 Windows 本地库，运行 HDFS 客户端需要winutils.exe。没有这个文件，Hadoop 在 Windows 上就起不来。
解决：要么下载对应版本的winutils.exe放到 Hadoop 的bin目录下，并配好HADOOP_HOME环境变量；要么按判断题第 6 题的路子，用虚拟机或 Docker 跑 Linux 环境。我在 Windows 上调试过两次，每次都折腾半天，后来统一用 Linux 虚拟机，再也没碰过这个坑。

5.3 多选第 8 题：Worker 和 HMaster 为什么不能选

现象：多选第 8 题里，“Hadoop 集群包含 Worker 节点”和“Hadoop 集群包含 HMaster 节点”这两项很容易被一起选上。
原因：Hadoop 官方文档里没有 Worker 这个标准角色，Worker 是 Spark 等框架的叫法；HMaster 是 HBase 的进程，不属于 Hadoop 集群。
解决：记角色对照表——Hadoop 集群的 Master 节点上跑 NameNode 和 ResourceManager，Slave 节点上跑 DataNode 和 NodeManager。看到 Worker 先想 Spark，看到 HMaster 先想 HBase，就不会被干扰项带偏。

5.4 crontab 到底是 5 段还是 6 段：答案与实战的冲突

现象：多选第 5 题的参考答案里包含“crontab 表达式是由 6 个参数决定”，但 Linux 系统自带的 crontab 标准字段是 5 个。
原因：部分教材把带秒位的表达式也当作 crontab 来讲，而 Linux 的 cron 默认是分、时、日、月、周这 5 段，没有秒位。
解决：答题按卷面答案来，写定时任务按 Linux 实际行为来。生产环境里写 crontab 时，如果发现任务没有按预期执行，先检查是不是把 6 段当成 5 段写了，多出来的一位数会被当作分字段，任务执行时间会完全错乱。

5.5 填空题的术语口径：嵌入模式、链接克隆这类词不能换

现象：填空题第 3 题填“内嵌模式”，第 4 题填“链式克隆”，意思差不多，但拿不到分。
原因：这套卷子的答案以教材术语为准，嵌入模式对应 Embedded，链接克隆对应 Linked Clone，表述必须一致。
解决：多选、填空这类客观题，踩分点就是标准术语。复习的时候把“嵌入模式、本地模式、远程模式”“完整克隆、链接克隆”这类固定搭配当成专有名词记，别用自己习惯的说法替换。

6. 用三遍刷题法把这份试卷变成学习路线图

拿到这份试卷，最有效的用法不是背答案，而是当自测工具用。我建议你按三遍来刷，每一遍的目的都不一样。

第一遍盲答，不翻任何资料，把不确定的题目标出来。这一步是为了暴露盲区，不是为了得分。做完之后统计一下，错题集中在哪个章节：如果 HDFS 相关的题错得多，说明架构理解要补；如果 Zookeeper、Flume 这些组件题错得多，说明生态组件只停留在会用命令的层面。

第二遍对照参考答案，逐题核对。重点不是看对错，而是看那些“蒙对”的题。蒙对的题比做错的题更危险，因为你会以为自己掌握了，实际上换个问法就露馅。核对的时候，把判断题第 8 题、多选第 5 题这类和实战有出入的题单独标出来，以命令行实际行为为准，参考教材口径理解卷面答案。

第三遍把错题迁移成上机任务。每道错题对应一条命令或一套配置，这一步是把死知识变成活技能的关键：

第三遍做完，这套试卷才真正变成了你的知识地图。剩下的错题不要只记答案，把每道题背后的知识点连成一条线，比如从 HDFS 主从架构延伸到 HA 的 Active/Standby，再延伸到 Zookeeper 的选举机制，这样一条线下来，几个组件之间的关系就串起来了。

从那以后，我每次带新人或者自己换一套集群，都会强制走一遍“先盲答、再验证、后迁移”这三遍刷题流程。尤其是第三遍，错了多少题不重要，重要的是把每道错题变成一条能敲进终端的命令。这套 A 卷适合拿来做这件事，希望帮到你。

本文还有配套的精品资源，点击获取