★ FEATURED ARTICLE 简介本资源是林子雨《大数据技术原理与应用》课程配套的权威测试题集面向高校大数据、计算机及相关专业本科生及自学者用于课后巩固、章节自测与期末复习。全卷共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 与 EditLogHDFS 元数据持久化的双写日志机制HDFS 的元数据文件目录树、权限、block 列表等必须绝对可靠但全量写入磁盘太慢全放内存又怕宕机丢失。解决方案是经典的WALWrite-Ahead Logging Checkpoint组合EditLog所有元数据变更如create file,append block,delete file都先追加写入 EditLog 文件顺序 I/O极快。它是操作日志记录“做了什么”。FsImage某一时刻的元数据全量快照是二进制序列化文件。它不记录过程只存结果状态。SecondaryNameNodeSNN角色它不是NameNode 的热备而是定期默认每小时或 EditLog 达 1GB执行 checkpoint从 NameNode HTTP GET 下载当前 FsImage 和增量 EditLog在本地内存中将 EditLog 中的操作逐条重放replay到 FsImage 上生成新 FsImage将新 FsImage 上传回 NameNode替换旧 FsImage并清空 EditLog。!-- core-site.xml 中关键配置 -- property namefs.defaultFS/name valuehdfs://localhost:9000/value /property !-- hdfs-site.xml -- property namedfs.namenode.name.dir/name value/usr/local/hadoop/hdfs/name/value !-- FsImage 存储路径 -- /property property namedfs.namenode.edits.dir/name value/usr/local/hadoop/hdfs/edits/value !-- EditLog 存储路径 -- /property property namedfs.namenode.checkpoint.period/name value3600/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 引入HAHigh Availability模式应对此问题部署两个 NameNodeActive/Standby共享 EditLog通过 QJM 或 NFSZooKeeper 仲裁状态切换。但 HA 并未解决单点扩展性问题只是提高了可用性。真正的水平扩展方案是 HDFS Federation联邦即多个独立的 NameNode 管理不同命名空间如/user由 NN1 管/data由 NN2 管它们共享底层 DataNode 存储池。这解释了为何第2章单选第5题指出 Hadoop1.0 “不支持实时计算”——因为其架构重心全在离线批处理NameNode 的设计哲学就是“稳”而非“快”。2.4 避坑HDFS 启动失败、元数据损坏与块报告异常的典型排查链现象1start-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并重启。现象2NameNode 启动卡在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 备份恢复或重建。现象3DataNode 正常启动但hdfs dfsadmin -report显示 Live datanodes 0原因NameNode 与 DataNode 的clusterID不一致。常见于格式化 NameNodehdfs 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配置是否过大导致可用空间计算为负。现象5hdfs 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下存serverRegionServer 地址和regioninfoRegion 元数据。当用户表 Region 分裂时.META. 表会新增一行。注意第4章单选第6题指出“Zookeeper 文件记录了用户数据表的 Region 位置信息”是错误的。ZK 只管-ROOT-.META.才管用户表。这个分层设计让客户端只需缓存两级ZK -ROOT-就能快速定位.META.再查.META.得到最终 Region大幅降低 NameNodeHDFS压力。3.2 Region 分裂HBase 自动伸缩的原子操作与 .META. 表更新时机Region 是 HBase 的数据分发单元。当一个 Region 大小超过阈值默认 10GB它会自动分裂为两个子 Region。这个过程必须原子、幂等、可恢复否则会导致数据丢失或寻址混乱分裂准备RegionServer 检测到 Region 过大选定 split point通常取中间 rowkey创建两个子 Region 的临时目录如regionA_A,regionA_BHLog 切分将原 Region 的 HLog 按 rowkey 范围切分为两份分别归属两个子 RegionStoreFile 切分对每个 Store列族下的 StoreFile用 split point 二分查找将 key-value 按范围写入对应子 Region 的临时 StoreFile.META. 更新这是关键一步RegionServer 向 Master 发送 split 请求Master 验证后原子性地在 .META. 表中插入两行新记录子 Region 的 start/end key 和 server并删除原 Region 记录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 HLogWALHBase 崩溃恢复的生命线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 积压的根因诊断现象1start-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 配置一致。现象2hbase 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强制重新分配。现象3RegionServer 日志频繁出现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 个以内。现象4HBase 写入延迟突增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.enabledtrue需 HBase 2.0。现象5hbase 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 选择 CP4.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 打开 RegionRegionServer 成功打开后才删除该节点。任何环节失败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 集群脑裂、数据不一致与配置误用的血泪经验现象1MongoDB 副本集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 同步。现象2Cassandra 集群中cqlsh执行SELECT * FROM table WHERE keyxxx返回空但nodetool getendpoints keyspace table xxx显示该 key 应在某节点上原因读取一致性级别consistency level设置过高如QUORUM而该 key 所在的副本节点恰好宕机或响应超时导致查询失败。解决降低一致性级别如ONE进行调试检查nodetool status确认所有节点 UP执行nodetool repair修复数据不一致。现象3Redis Cluster 中SET key value成功但GET key返回 nil且CLUSTER KEYSLOT key显示 key 应在另一节点原因客户端未开启集群模式如 Jedis 需new JedisCluster(...)仍用单节点连接导致请求被转发到错误节点而该节点无此 key。解决客户端必须使用支持 Redis Cluster 的驱动确认redis-cli -c带 -c 参数才能正确重定向检查CLUSTER NODES输出确认 slot 分配无误。现象4Elasticsearch 集群健康状态为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 }增加数据节点数量。现象5HBasescan查询结果重复或遗漏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.javahadoop-mapreduce-project/hadoop-mapreduce-client/hadoop-mapreduce-client-core/src/main/java/org/apache/hadoop/mapreduce/下的JobSubmitter.java和YARNRunner.java。重点看NameNode的构造函数——它初始化了FSNamesystem元数据核心、FSEditLogEditLog 管理器、FSImage快照管理器。第3章单选第5题“NameNode 的主要功能是什么”答案是“存储元数据”。直奔FSNamesystem.java搜索getFileInfo、getListing方法看它们如何从dirINodeDirectory树和blocksMapBlockManager中获取数据。你会发现blocksMap是一个LightWeightGSetBlock, 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章核心准备单机 Hadoop 2.10.0hdfs namenode -format初始化制造故障hdfs dfs -put test.txt /上传一个文件hdfs fsck /确认 healthykill -9 $(jps | grep NameNode | awk {print $1})强杀 NameNode观察现象hdfs dfs -ls /报Connection refusedhdfs dfsadmin -report无输出恢复元数据进入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 操作在其中手动恢复hdfs namenode -importCheckpoint需先配置dfs.namenode.checkpoint.dir指向 SNN 备份目录或直接cpSNN 的 FsImage 到 NameNode 目录覆盖重启验证本文还有配套的精品资源点击获取
阅读完成 · 觉得有帮助？
