企业官网建设流程全解析

简介：本资源是林子雨《大数据技术原理与应用》课程配套的权威测试题集，面向高校大数据、计算机及相关专业本科生及自学者，用于课后巩固、章节自测与期末复习。全卷共58页，覆盖大数据概述、Hadoop架构、云计算、物联网、数据特征与产业生态等核心章节，题型丰富，含单选、多选两大类，每题均标注知识点出处与能力指向，如信息化三次浪潮辨析、HDFS与MapReduce职责区分、PaaS与IaaS服务边界判断等，便于精准查漏补缺。资源为1个76KB的Word文档（.docx），结构清晰、排版规范，可直接打印或导入学习系统使用。目前已有5641人下载学习，内容紧扣教材逻辑，题目设计兼具基础性与思辨性，是检验大数据技术体系理解深度与知识迁移能力的高效自测工具。

1. 这份58页的《大数据技术原理应用》测试题，不是刷题资料，而是打开大数据底层认知的一把密钥

你有没有试过：花一整天搭好 Hadoop 伪分布式环境，start-dfs.sh启动后jps看到 NameNode 和 DataNode 都在，但hdfs dfs -ls /却报Connection refused？或者明明hdfs getconf -namenodes显示地址正确，core-site.xml里fs.defaultFS也配对了，就是连不上——最后发现是etc/hosts里 localhost 解析被改成了 127.0.0.2？这种“配置全对、逻辑自洽、但就是不 work”的黑匣子时刻，在大数据入门阶段高频出现。而这份林子雨《大数据技术原理应用》测试题.docx，表面看是58页单选+多选题，实则是一张高度结构化的底层机制反向索引图：它不教你怎么敲命令，而是用500+道题的密集设问，把 HDFS 的块定位逻辑、NameNode 的元数据快照机制、ZooKeeper 在 HBase 三层寻址中的不可替代性、CAP 定理在真实集群故障时的取舍现场……全部拆解成可验证、可证伪、可回溯的判断支点。比如第3章单选第6题问“FsImage 文件记录了每个块具体被存储在哪个数据节点吗？”，答案是“错误”——这直接指向 HDFS 元数据分层设计的本质：FsImage 只存 namespace 树和 inode，真正 block→DataNode 的映射关系由内存中实时维护的blocksMap承载，且只在心跳上报时动态更新。没有这道题，你可能永远意识不到：HDFS 的“高可用”不是靠 FsImage 备份实现的，而是靠 NameNode 内存状态 + EditLog 持久化 + SecondaryNameNode 定期合并三者协同完成的脆弱平衡。它解决的不是“怎么考过”，而是“为什么必须这么设计”。

2. HDFS 的块抽象与元数据分层：为什么64MB是默认块大小，以及FsImage和EditLog如何协作维持一致性

2.1 块大小不是拍脑袋定的：64MB背后是磁盘寻道、网络吞吐与任务调度的三角权衡

HDFS 默认块大小在早期版本（如 Hadoop 1.x）中为 64MB，后续版本升至 128MB 或更高，这个数字绝非随意设定。它本质是在三个物理约束之间找平衡点：

• 磁盘寻道成本：机械硬盘平均寻道时间约 10ms，而顺序读取 64MB 数据（按 100MB/s 吞吐）仅需约 640ms。若块太小（如 4KB），寻道时间占比飙升，I/O 效率断崖下跌；
• 网络传输开销：HDFS 设计目标是“移动计算而非移动数据”。一个 MapReduce 任务处理一个 block，若块太小，TaskTracker 需频繁拉取大量小块，TCP 连接建立/关闭、序列化反序列化开销剧增；
• NameNode 内存压力：每个 block 在 NameNode 内存中至少占用 150 字节元数据（含 block ID、长度、校验和等）。假设总数据量 1PB，若块大小为 64MB，则 block 总数 ≈ 1600 万；若降为 1MB，则 block 数暴增至 10 亿——NameNode 内存将直接 OOM。

提示：Hadoop 2.x 后默认调至 128MB，正是因 SSD 普及降低了寻道影响，而万兆网络普及提升了单次传输吞吐，使得更大块成为可能。但核心逻辑未变：块大小是存储介质性能、网络带宽、JVM 内存三者的函数。

2.2 FsImage 与 EditLog：HDFS 元数据持久化的双写日志机制

HDFS 的元数据（文件目录树、权限、block 列表等）必须绝对可靠，但全量写入磁盘太慢，全放内存又怕宕机丢失。解决方案是经典的WAL（Write-Ahead Logging）+ Checkpoint组合：

• EditLog：所有元数据变更（如create file,append block,delete file）都先追加写入 EditLog 文件（顺序 I/O，极快）。它是操作日志，记录“做了什么”。
• FsImage：某一时刻的元数据全量快照，是二进制序列化文件。它不记录过程，只存结果状态。
• SecondaryNameNode（SNN）角色：它不是NameNode 的热备！而是定期（默认每小时或 EditLog 达 1GB）执行 checkpoint：
  1. 从 NameNode HTTP GET 下载当前 FsImage 和增量 EditLog；
  2. 在本地内存中将 EditLog 中的操作逐条重放（replay）到 FsImage 上，生成新 FsImage；
  3. 将新 FsImage 上传回 NameNode，替换旧 FsImage，并清空 EditLog。

<!-- core-site.xml 中关键配置 --> <property> <name>fs.defaultFS</name> <value>hdfs://localhost:9000</value> </property> <!-- hdfs-site.xml --> <property> <name>dfs.namenode.name.dir</name> <value>/usr/local/hadoop/hdfs/name</value> <!-- FsImage 存储路径 --> </property> <property> <name>dfs.namenode.edits.dir</name> <value>/usr/local/hadoop/hdfs/edits</value> <!-- EditLog 存储路径 --> </property> <property> <name>dfs.namenode.checkpoint.period</name> <value>3600</value> <!-- checkpoint 间隔秒数 --> </property>

这段配置定义了元数据的物理落盘位置和 checkpoint 触发策略。关键在于：NameNode 启动时，会先加载 FsImage 到内存，再重放 EditLog 中所有未合并的操作，才能恢复完整状态。如果 EditLog 损坏，而 FsImage 又过于陈旧，就可能丢失近期元数据——这正是第3章单选第6题强调“FsImage 不记录 block 存储位置”的深层原因：那个映射关系根本不在 FsImage 里，它只存在于 NameNode 内存的blocksMap结构中，靠 DataNode 心跳动态维护。

2.3 NameNode 单点瓶颈的根源：命名空间限制、性能墙与隔离失效

HDFS 采用单一 NameNode 架构，虽极大简化设计（如第3章多选第8题所述），却带来硬伤：

• 命名空间限制：所有文件/目录元数据都存在一台机器内存里。假设每个文件平均占 500 字节元数据，1 亿文件就需 50GB 内存——远超常规 JVM 堆上限，GC 压力巨大；
• 性能瓶颈：所有客户端元数据请求（open, list, mkdir）都经由 NameNode 序列化处理。高并发下，QPS 成为天花板；
• 隔离问题：不同租户/业务共用同一命名空间，权限模型薄弱（早期仅支持 POSIX 权限），无法实现资源硬隔离。

Hadoop 2.x 引入HA（High Availability）模式应对此问题：部署两个 NameNode（Active/Standby），共享 EditLog（通过 QJM 或 NFS），ZooKeeper 仲裁状态切换。但 HA 并未解决单点扩展性问题，只是提高了可用性。真正的水平扩展方案是 HDFS Federation（联邦），即多个独立的 NameNode 管理不同命名空间（如/user由 NN1 管，/data由 NN2 管），它们共享底层 DataNode 存储池。这解释了为何第2章单选第5题指出 Hadoop1.0 “不支持实时计算”——因为其架构重心全在离线批处理，NameNode 的设计哲学就是“稳”而非“快”。

2.4 避坑：HDFS 启动失败、元数据损坏与块报告异常的典型排查链

现象1：start-dfs.sh后jps显示 NameNode 进程存在，但hdfs dfs -ls /报Connection refused

• 原因：NameNode 进程虽启动，但未成功绑定端口（9000）。常见于core-site.xml中fs.defaultFS地址与hdfs-site.xml中dfs.namenode.http-address解析不一致，或etc/hosts中 localhost 被错误映射到非 127.0.0.1 的 IP。
• 解决：检查logs/hadoop-xxx-namenode-xxx.log，搜索Failed to bind；确认hostname命令输出与etc/hosts中 localhost 行完全匹配；强制echo "127.0.0.1 localhost" >> /etc/hosts并重启。

现象2：NameNode 启动卡在Loading image from ...阶段，日志无报错但进程不响应

• 原因：FsImage 文件损坏或格式不兼容（如从 Hadoop 3.x 拷贝 FsImage 到 Hadoop 2.x 环境）。
• 解决：使用hdfs oiv -i fsimage_0000000000000000000 -o fsimage.txt -p Indented命令尝试离线解析 FsImage。若报Invalid magic number，说明版本不匹配；若解析成功但内容为空，说明文件已损毁，需从 SecondaryNameNode 备份恢复或重建。

现象3：DataNode 正常启动，但hdfs dfsadmin -report显示 Live datanodes = 0

• 原因：NameNode 与 DataNode 的clusterID不一致。常见于格式化 NameNode（hdfs namenode -format）后未同步清理 DataNode 的current/VERSION文件。
• 解决：查看 NameNodelogs/hadoop-xxx-namenode-xxx.log中clusterID字段；对比 DataNodedata/current/VERSION中clusterID；若不一致，手动修改 DataNode 的 VERSION 文件，或删除整个data目录后重启 DataNode。

现象4：客户端能ls，但put文件时报File could only be replicated to 0 nodes instead of minReplication(1)

• 原因：DataNode 未向 NameNode 注册成功，或 NameNode 认为该 DataNode 磁盘空间不足/处于 decommission 状态。
• 解决：检查hdfs dfsadmin -report输出，确认 Live datanodes 数量及剩余空间；查看 DataNode 日志中是否有Registration successful字样；检查dfs.datanode.du.reserved配置是否过大导致可用空间计算为负。

现象5：hdfs fsck /报告大量MISSINGblocks，但hdfs dfs -ls文件列表正常

• 原因：DataNode 已宕机或网络隔离，其上存储的 blocks 未被 NameNode 收到心跳，触发副本缺失检测。但文件元数据仍在，故ls可见。
• 解决：启动宕机 DataNode；若永久丢失，执行hdfs fsck / -delete清理元数据中已不存在的 block 引用，避免 NameNode 内存持续增长。

3. HBase 的三层寻址与 Region 分裂：为什么-ZERO-表只能有一个Region，以及HLog如何保障崩溃恢复

3.1 ZooKeeper、-ROOT-、.META.：HBase 的三级缓存式寻址体系

HBase 是一个稀疏、分布、多维的排序映射表，其核心挑战是如何在海量 Region（数据分片）中，以 O(1) 时间定位任意 rowkey 对应的 RegionServer。它放弃传统数据库的全局索引，转而构建一套层级化、客户端缓存、服务端兜底的寻址机制：

• ZooKeeper 文件：存储-ROOT-表所在的 RegionServer 地址（固定路径/hbase/root-region-server）。这是整个寻址链的根证书，所有客户端首次连接必查此处。
• -ROOT- 表：一个特殊的 HBase 表，只包含一行一列，记录.META.表的 Region 信息（即.META.表本身的位置）。它被设计为永远只有一个 Region（第4章单选第9题考点），且该 Region 永远不会分裂——因为一旦分裂，寻址链就断裂了。其 Region 信息被客户端缓存，且由 ZooKeeper 实时监听变更。
• .META. 表：记录所有用户表的 Region 位置信息。每个 Region 在 .META. 中是一行，rowkey 为table_name,start_key,region_id，列族info下存server（RegionServer 地址）和regioninfo（Region 元数据）。当用户表 Region 分裂时，.META. 表会新增一行。

注意：第4章单选第6题指出“Zookeeper 文件记录了用户数据表的 Region 位置信息”是错误的。ZK 只管-ROOT-，.META.才管用户表。这个分层设计让客户端只需缓存两级（ZK +-ROOT-），就能快速定位.META.，再查.META.得到最终 Region，大幅降低 NameNode（HDFS）压力。

3.2 Region 分裂：HBase 自动伸缩的原子操作与 .META. 表更新时机

Region 是 HBase 的数据分发单元。当一个 Region 大小超过阈值（默认 10GB），它会自动分裂为两个子 Region。这个过程必须原子、幂等、可恢复，否则会导致数据丢失或寻址混乱：

1. 分裂准备：RegionServer 检测到 Region 过大，选定 split point（通常取中间 rowkey），创建两个子 Region 的临时目录（如regionA_A,regionA_B）；
2. HLog 切分：将原 Region 的 HLog 按 rowkey 范围切分为两份，分别归属两个子 Region；
3. StoreFile 切分：对每个 Store（列族）下的 StoreFile，用 split point 二分查找，将 key-value 按范围写入对应子 Region 的临时 StoreFile；
4. .META. 更新：这是关键一步！RegionServer 向 Master 发送 split 请求，Master 验证后，原子性地在 .META. 表中插入两行新记录（子 Region 的 start/end key 和 server），并删除原 Region 记录；
5. Region 打开：子 Region 在各自 RegionServer 上打开，开始提供服务。

// HBase 源码中 MetaTableAccessor.java 片段（简化） public static void splitRegionInMeta(Connection conn, byte[] parentRegionName, byte[] regionAName, byte[] regionBName, byte[] splitRow, ServerName serverA, ServerName serverB) throws IOException { // 1. 获取 .META. 表引用 Table metaTable = conn.getTable(TableName.META_TABLE_NAME); // 2. 构建 parent Region 的 Delete 操作 Delete parentDelete = new Delete(parentRegionName); // 3. 构建 regionA 的 Put 操作 Put regionAPut = new Put(regionAName); regionAPut.addColumn(HConstants.CATALOG_FAMILY, HConstants.REGIONINFO_QUALIFIER, ...); regionAPut.addColumn(HConstants.CATALOG_FAMILY, HConstants.SERVER_QUALIFIER, ...); // 4. 构建 regionB 的 Put 操作（同理） // 5. 执行原子批量操作：删除 parent + 插入 A + 插入 B metaTable.batch(Arrays.asList(parentDelete, regionAPut, regionBPut), null); }

这段代码揭示了分裂的核心：.META.表的更新必须是单次 batch 操作，确保要么全部成功，要么全部失败。若在步骤4失败，Master 会重试；若 RegionServer 在步骤5前崩溃，Master 会通过定时巡检发现“孤儿 Region”，触发 assign 流程。这正是第4章多选第9题提到“合并操作比较耗费资源，只有数量达到阈值才启动”的底层逻辑——分裂/合并是昂贵的元数据操作，必须严格控制频率。

3.3 HLog（WAL）：HBase 崩溃恢复的生命线

HBase 的写操作是“先写 HLog，再写 MemStore”。HLog 是 Write-Ahead Log，每个 RegionServer 维护一个 HLog 文件（第4章多选第9题）。它的存在解决了分布式系统最棘手的问题：节点宕机时，尚未 flush 到磁盘的 MemStore 数据如何恢复？

• 写入流程：客户端put(rowkey, value)→ RegionServer 将 KV 追加写入 HLog（同步刷盘）→ 再写入对应 Region 的 MemStore（内存）→ 返回 success；
• 崩溃恢复：若 RegionServer 宕机，Master 会将其上所有 Region 重新分配给其他 RS。新 RS 在打开这些 Region 前，必须先重放（replay）原 RS 的 HLog，将其中属于本 Region 的 KV 重新写入 MemStore，再 flush 到 HFile，确保数据不丢。

关键点：HLog 是按 RegionServer 级别共享的，不是每个 Region 一个日志。因此重放时需过滤出本 Region 的条目。这也是 HLog 文件名包含serverName-timestamp的原因（如hlog.123456789），便于故障时定位。

3.4 避坑：HBase 启动失败、Region 分裂卡死与 HLog 积压的根因诊断

现象1：start-hbase.sh后jps显示 HMaster 进程存在，但hbase shell连接超时，hbase hbck报ERROR: KeeperErrorCode = ConnectionLoss

• 原因：HBase 依赖 ZooKeeper 协调，ZK 服务未启动或 HBase 配置的 ZK 地址（hbase.zookeeper.quorum）与实际不符。
• 解决：确认zkServer.sh status；检查hbase-site.xml中hbase.zookeeper.quorum是否指向正确的 ZK 集群地址（非 localhost）；若为单机，确保hbase.zookeeper.property.clientPort与 ZK 配置一致。

现象2：hbase shell中list命令返回空，但hbase hbck -details显示大量DEPLOYED但NOT_IN_META的 Region

• 原因：.META.表损坏或未加载，导致 Master 无法从 .META. 读取用户表 Region 信息，但 RegionServer 仍持有 Region 状态。
• 解决：执行hbase hbck -repair（慎用！）或更安全的hbase hbck -fixMeta重建 .META. 表；若无效，需从备份恢复 .META. 表，或手动hbase org.apache.hadoop.hbase.util.HBaseFsck -fixAssignments强制重新分配。

现象3：RegionServer 日志频繁出现Too many store files，且major_compact后很快又触发 minor_compact

• 原因：MemStore flush 频率过高（hbase.hregion.memstore.flush.size过小）或 compaction 策略不当（hbase.hstore.compactionThreshold过低），导致 StoreFile 数量失控，查询需遍历过多文件，性能骤降。
• 解决：增大hbase.hregion.memstore.flush.size（如从 128MB 调至 256MB）；调高hbase.hstore.compactionThreshold（如从 3 调至 5）；监控hbase.regionserver.storefileCount指标，确保稳定在 5-10 个以内。

现象4：HBase 写入延迟突增，hbase.regionserver.hlog.syncer线程 CPU 占用 100%

• 原因：HLog 同步刷盘（sync）阻塞。常见于磁盘 I/O 瓶颈（HLog 与 DataNode 共用磁盘）、或hbase.regionserver.hlog.blocksize设置过大导致单次 sync 时间过长。
• 解决：将 HLog 目录（hbase.wal.dir）挂载到独立 SSD；减小hbase.regionserver.hlog.blocksize（如从 128MB 降至 64MB）；启用异步刷盘（hbase.regionserver.hlog.async.writer.enabled=true，需 HBase 2.0+）。

现象5：hbase hbck -summary显示HOLE（空洞）Region，即某段 rowkey 范围无任何 Region 覆盖

• 原因：Region 分裂过程中 Master 或 RegionServer 崩溃，导致 .META. 表中该范围的 Region 记录丢失，但数据文件（HFile）仍存在。
• 解决：执行hbase hbck -fixHdfsHoles修复 HDFS 中的空洞；再执行hbase hbck -fixMeta重建 .META. 中的缺失记录；最后hbase hbck -repair强制 assign。

4. CAP 定理在 NoSQL 系统中的落地：为什么 MongoDB 默认不保证强一致性，而 HBase 选择 CP

4.1 CAP 三选二不是理论游戏：它直接决定数据库的 API 行为与故障表现

CAP 定理（2000年 Brewer 提出，2002年 Gilbert & Lynch 证明）指出：在分布式数据存储系统中，Consistency（一致性）、Availability（可用性）、Partition Tolerance（分区容忍性）三者不可兼得，最多满足其二。关键在于，“P” 是前提——现代分布式系统必须容忍网络分区（P），因此实际抉择只剩CP 或 AP。这份测试题第5章多选第8、9题正是对此的精准考察。

• CP 系统（如 HBase、MongoDB 的 majority write concern）：当网络分区发生时，系统宁可拒绝部分请求（牺牲 A），也要保证所有节点看到的数据是一致的（C）。例如 HBase 的put操作，若多数 RegionServer 不可达，写入会失败并抛出NotServingRegionException。
• AP 系统（如 Cassandra、DynamoDB 的 eventual consistency）：当分区发生时，系统保证所有请求都能得到响应（A），但不同节点的数据可能暂时不一致，最终通过后台同步达成一致（E）。例如 Cassandra 的QUORUM读写，只要多数节点响应即返回，不保证读到最新写入。

注意：第5章单选第8题指出“NoSQL 在可用性方面优于 RDBMS”是错误的。RDBMS（如 MySQL 主从）在单点故障时也可通过 VIP 切换实现高可用；NoSQL 的优势在于水平扩展下的高可用，即节点越多，整体可用性越高（冗余度提升），而非单节点可用性更高。

4.2 HBase 的 CP 实现：ZooKeeper 协调 + HLog 强持久化 + Region 分配原子性

HBase 将 CP 保证落实到每一层：

• ZooKeeper 仲裁：Master 选举、Region 分配、-ROOT-/.META. 位置变更，全部通过 ZooKeeper 的 ZAB 协议保证强一致性。ZK 的create /hbase/master是 EPHEMERAL 节点，Master 宕机后 ZK 自动删除，触发新 Master 选举。
• HLog 强持久化：如前所述，所有写入必须先同步刷盘 HLog，确保即使 RegionServer 瞬间宕机，数据也不丢。这是 C（一致性）的物理基础。
• Region 分配原子性：Region 的 assign/unassign 操作，通过 ZooKeeper 的create /hbase/region-in-transition/regionName临时节点实现。Master 创建该节点后，才通知 RegionServer 打开 Region；RegionServer 成功打开后，才删除该节点。任何环节失败，Master 都能通过扫描/hbase/region-in-transition恢复状态。

# 查看 HBase 的 ZooKeeper 状态（需 zkCli.sh） [zk: localhost:2181(CONNECTED) 0] ls /hbase # 输出包含：master, region-in-transition, rs, table, zookeeper... [zk: localhost:2181(CONNECTED) 1] get /hbase/master # 返回当前 Active Master 的 serverName 和启动时间戳

这段 ZooKeeper 交互证明：HBase 的“一致性”不是靠算法推演，而是靠 ZK 这个外部强一致协调器，将分布式状态变更转化为原子的 ZNode 操作。

4.3 MongoDB 的 AP 倾向：默认的 majority write concern 与 read concern 可配置性

MongoDB 默认配置是writeConcern: {w: 1}（仅主节点确认）和readConcern: "local"（读本地最新），这本质上是 AP 模式：主节点宕机，从节点可能丢失未复制的写入，但读写请求仍可继续。但 MongoDB 的精妙之处在于可配置的 CAP 权衡：

• 强一致性（CP）：设置writeConcern: {w: "majority"}，写入需多数节点（含主）确认才返回；readConcern: "majority"，读取只返回已被多数节点确认的数据。此时若网络分区，少数派节点将拒绝读写，保证 C。
• 高可用（AP）：保持默认w: 1，写入主节点即成功；readPreference: secondaryPreferred，优先从从节点读，即使主节点宕机也能读。

第5章单选第7题指出 MongoDB “可以实现替换完成的文档”是正确的，这源于其文档模型：db.collection.replaceOne({name: "A"}, {name: "A", age: 30})是原子操作，无需事务。而关系型数据库的 UPDATE 需要锁表/行，是 CP 模式下高延迟的根源之一。

4.4 避坑：NoSQL 集群脑裂、数据不一致与配置误用的血泪经验

现象1：MongoDB 副本集（Replica Set）中，Primary 宕机后，两个 Secondary 同时被选为 Primary（脑裂）

• 原因：仲裁节点（Arbiter）缺失或网络分区导致多数派无法形成。例如 3 节点集群（1 Primary + 2 Secondary），若 Primary 与一个 Secondary 网络隔离，剩余两个节点（1 Secondary + 1 Arbiter）可能自认为多数，各自选举为 Primary。
• 解决：确保副本集节点数为奇数（3/5/7）；必须部署 Arbiter（轻量级节点，只参与投票）；配置settings.chainingAllowed: false禁止 Secondary 从其他 Secondary 同步，强制都从 Primary 同步。

现象2：Cassandra 集群中，cqlsh执行SELECT * FROM table WHERE key=xxx返回空，但nodetool getendpoints keyspace table xxx显示该 key 应在某节点上

• 原因：读取一致性级别（consistency level）设置过高（如QUORUM），而该 key 所在的副本节点恰好宕机或响应超时，导致查询失败。
• 解决：降低一致性级别（如ONE）进行调试；检查nodetool status确认所有节点 UP；执行nodetool repair修复数据不一致。

现象3：Redis Cluster 中，SET key value成功，但GET key返回 nil，且CLUSTER KEYSLOT key显示 key 应在另一节点

• 原因：客户端未开启集群模式（如 Jedis 需new JedisCluster(...)），仍用单节点连接，导致请求被转发到错误节点，而该节点无此 key。
• 解决：客户端必须使用支持 Redis Cluster 的驱动；确认redis-cli -c（带 -c 参数）才能正确重定向；检查CLUSTER NODES输出，确认 slot 分配无误。

现象4：Elasticsearch 集群健康状态为yellow，_cat/shards显示大量UNASSIGNEDshards

• 原因：副本分片（replica shard）无法分配，常见于磁盘空间不足（cluster.routing.allocation.disk.threshold_enabled: true）、或节点数少于副本数（如 2 节点集群，number_of_replicas: 1，则每个 shard 最多 1 个 replica，但要求 2 个节点都存活才能分配）。
• 解决：清理磁盘或调整cluster.routing.allocation.disk.watermark.low；临时减少副本数PUT /_settings { "number_of_replicas": 0 }；增加数据节点数量。

现象5：HBasescan查询结果重复或遗漏，hbase hbck -details显示SPLITTING状态的 Region

• 原因：Region 正在分裂，但 .META. 表未及时更新，导致客户端从旧 Region 读取到部分数据，又从新 Region 读取到另一部分，造成重复或遗漏。
• 解决：等待分裂完成（观察hbase hbck -details中状态变为DEPLOYED）；或执行hbase hbck -fixSplitParents强制清理分裂残留；生产环境应避免在业务高峰执行 major_compact。

5. 从测试题到源码：如何用这58页题库反向驱动 Hadoop/HBase 源码阅读与实验验证

5.1 以题为索引，定位 Hadoop 源码中的关键类与方法

这份测试题的价值，远不止于“知道答案”。它的每一道题，都是通向 Hadoop/HBase 源码的精确坐标。例如：

• 第2章单选第2题：“Hadoop 框架中最核心的设计是什么？”
  答案指向HDFS和MapReduce。立刻去 GitHub 查看 apache/hadoop 仓库：hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/下的NameNode.java和DataNode.java；hadoop-mapreduce-project/hadoop-mapreduce-client/hadoop-mapreduce-client-core/src/main/java/org/apache/hadoop/mapreduce/下的JobSubmitter.java和YARNRunner.java。重点看NameNode的构造函数——它初始化了FSNamesystem（元数据核心）、FSEditLog（EditLog 管理器）、FSImage（快照管理器）。

• 第3章单选第5题：“NameNode 的主要功能是什么？”
  答案是“存储元数据”。直奔FSNamesystem.java，搜索getFileInfo、getListing方法，看它们如何从dir（INodeDirectory树）和blocksMap（BlockManager）中获取数据。你会发现blocksMap是一个LightWeightGSet<Block, BlockInfoContiguous>，而BlockInfoContiguous类里有getDatanode(int index)方法——这就是 block→DataNode 映射的内存实现，印证了“FsImage 不存此映射”的结论。

• 第4章单选第6题：“Zookeeper 文件记录了用户数据表的 Region 位置信息？”
  答案是“错误”。立刻去 HBase 源码 apache/hbase 的hbase-server/src/main/java/org/apache/hadoop/hbase/zookeeper/下，看ZKUtil.java和ZooKeeperWatcher.java。搜索ROOT_REGION_SERVER常量，你会发现它只用于读取-ROOT-表位置，而.META.表位置存储在/hbase/meta-region-serverZNode 中——这才是真正的用户表寻址入口。

5.2 用最小实验验证题干结论：亲手制造一次 NameNode 故障

理论终需实践验证。以下是一个 10 分钟可完成的实验，直击第3章核心：

1. 准备：单机 Hadoop 2.10.0，hdfs namenode -format初始化；
2. 制造故障：hdfs dfs -put test.txt /上传一个文件；hdfs fsck /确认 healthy；kill -9 $(jps | grep NameNode | awk '{print $1}')强杀 NameNode；
3. 观察现象：hdfs dfs -ls /报Connection refused；hdfs dfsadmin -report无输出；
4. 恢复元数据：进入hadoop/hdfs/name/current/目录，ls -l查看fsimage_*和edits_*；hdfs oiv -i fsimage_0000000000000000000 -o fsimage.txt -p Indented解析 FsImage，确认文件存在；hdfs oev -i edits_0000000000000000001-0000000000000000002 -o edits.txt解析 EditLog，确认test.txt的 create 操作在其中；
5. 手动恢复：hdfs namenode -importCheckpoint（需先配置dfs.namenode.checkpoint.dir指向 SNN 备份目录），或直接cpSNN 的 FsImage 到 NameNode 目录覆盖；
6. 重启验证：

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