简介这份共58页的题库型复习资料围绕林子雨《大数据技术原理应用》教材整理面向高校大数据课程学习者及任课教师可用于章节自测、课堂练习与期末备考。压缩包内仅含1个docx文件大小约76KB以单项选择题和多项选择题为主题目按“大数据概述”“Hadoop处理架构”等章节组织便于按知识点检索和集中练习。内容覆盖三次信息化浪潮、数据存储与管理、流计算、大数据产业链、云计算服务模式、物联网层次与关键技术等基础概念并延伸至Hadoop高可靠、高容错、低成本等特性以及HDFS、MapReduce、YARN、DataNode的职责划分多数题目附有选项和参考答案适合边练边核对概念掌握情况。已有5634人学习下载适合需要系统梳理知识框架、刷题查漏补缺的本科生、自学者和任课教师参考。1. 大数据到底是什么为什么一套测试题能当「知识地图」用想象你要给一座城市做体检水管、电网、路网、垃圾处理每一项都得单独看但只看其中任何一项都说不清这座城市到底健不健康。大数据也是这么一摊事——它不是一个软件也不是一门编程语言而是一整套从「把数据存下来」到「把数据算出结果」的工程体系。刚接触「大数据技术原理与应用」这门课的人最常见的困惑往往不是某个知识点太难而是 Hadoop、HDFS、HBase、NoSQL、云计算、物联网这些词单个都认识凑在一起就分不清谁管谁、谁替代谁。一份按章节组织的配套测试题恰好就是这座城市的索引地图它不教你怎么开车但会告诉你每条路通向哪里。先把名词各自的岗位职责搞明白比背下任何一个标准答案都值钱。2. 三次信息化浪潮与大数据的技术版图先分清「存储、计算、应用」三件事2.1 三次信息化浪潮每一步解决的都是上一步留下的麻烦把信息化浪潮理解成「人类处理信息的三个动作」会好记很多先学会处理和计算再学会传输和连接最后被自己造出来的数据量淹了。第一次浪潮的主角是个人计算机要解决的是信息处理问题——让信息不再只躺在纸上而是能被机器算。第二次浪潮的主角是互联网要解决的是信息传输问题——让一台机器上的信息能跑到另一台机器上而且跑得又快又便宜。第三次浪潮面对的是前两步的副作用人人都能算、处处都能联网之后信息开始爆炸于是要解决信息爆炸问题标志性技术是物联网、云计算和大数据。这里有个特别容易翻车的地方很多人一看到「互联网」就顺手选进第三次浪潮。按这套题的设定互联网是第二次浪潮的代表第三次浪潮对应的是物联网、云计算、大数据这三样。原因也不难想——互联网本身解决的是「连起来传」而浪潮三要解决的是「传过来的东西太多怎么办」。判断一个技术属于哪次浪潮看的不是它新不新而是它主要对付的是处理、传输还是爆炸。提示答这类题时把选项往「处理 / 传输 / 爆炸」三个筐里一放基本不会错。2.2 4V 与两大核心技术大数据的「体检表」和「左右手」大数据的四个特征业内常说的「4V」是大量化、快速化、多样化、价值密度比较低。前三个好理解第四个最容易被误解成「没价值」——恰恰相反它说的是总价值很高但价值像沙子里的金粒单位体积里的含量低得靠一整套方法去淘。这就是为什么大数据离不开计算框架不是数据值钱是「淘」的能力值钱。支撑这套体系的技术最核心的两项是分布式存储和分布式处理。一台机器装不下就把文件切成块分散到成百上千台机器上存一台机器算不完就把计算任务拆开分发到这些机器上并行算。前面提到的「数据循环层」「集中式存储」这类词都是拿来凑选项的干扰项听着顺耳但没有对应实体。再往下拆大数据技术通常被分成几个功能层面存储和管理分布式文件系统、数据仓库、关系数据库负责接住结构化、半结构化、非结构化数据、处理和计算分布式并行编程模型配合机器学习、数据挖掘算法、隐私与安全保护数据和个人信息、实时计算用流计算系统接住实时采集的数据并立刻处理。流计算专门对付「流数据」和针对大规模数据批量处理的批处理不是一回事和大规模图结构数据的图计算也不是一回事。2.3 产业链四层谁在淘金谁在卖铲子「大数据产业」这个词听起来很宏大它的定义其实相当具体一切与支撑大数据的组织管理和价值发现相关的企业经济活动的集合。关键词是「支撑」和「价值发现」——只要你的生意是帮着把数据管起来或者把价值挖出来就算在这个产业里。产业链一般被拆成数据源层、数据分析层、数据应用层这几段从数据产生到被加工分析再到变成智能交通、智慧医疗、智能物流、智能电网这类具体行业应用。题目里那个「数据循环层」就是这个链条上不存在的环节属于典型的造词干扰项——读起来很顺但产业链里没有这一环。这里有个认知上的分水岭提供行业应用的企业、提供数据分享或租售平台的企业、提供分布式计算和统计分析服务的企业都只是产业里的某一段谁也不能单独代表整个产业。就像你不能说「卖铲子的就是整个矿业」。2.4 云计算和物联网为什么总跟大数据绑在一起出现因为这三者是同一次浪潮里互相喂饭的三兄弟。物联网负责采集云计算负责提供算力和存储大数据负责从里面挖东西。云计算的三种服务模式要分清**基础设施即服务IaaS**是把计算资源和存储当作服务出租**平台即服务PaaS**是把操作系统和围绕特定应用的必需服务打包提供**软件即服务SaaS**是把软件部署在集中系统上让用户从本地或远程直接使用。云计算的几项关键技术包括分布式存储、虚拟化、分布式计算和多租户。注意这类题里偶尔会出现选项描述和名称对不上的情况比如把「基础设施出租」那句写到了平台层下面。遇到这种题看定义句本身别只记字母——这也是后面要讲的「别只背答案」的原因。数据中心是云计算的重要载体为各种平台和应用提供运行支撑环境它既不是企业内部一台中心服务器也不是每家企业都得自己建一个。物联网由感知层、网络层、处理层、应用层构成关键技术是识别与感知、网络与通信、数据挖掘与融合。智能物流、智能安防、环保监测都算物联网应用而「数据清洗」是数据加工环节的动作不属于物联网应用。3. Hadoop 与 HDFS为什么要把文件切开存、把计算挪到数据旁边3.1 Hadoop 到底解决了什么一台机器扛不住之后Hadoop 最初并不是冲着「大数据」这个名头去的它脱胎于一个开源搜索引擎项目里的小工具后来被捐给开源组织慢慢长成了今天的样子。它的价值主张非常朴素用一堆便宜的机器干原来只有昂贵大机器才能干的事。它的特性可以概括成几条高可靠性、高可扩展性、高容错性、成本低、能跑在 Linux 上、支持多种编程语言。注意最后一条很多人以为 Hadoop 只认 Java其实它支持多种语言写作业「只支持少数几种编程语言」是错误说法。把 Hadoop 的组件按代际分开看脉络就清楚了。1.0 时代的三大件是 HDFS管存、MapReduce管算、Common管公共工具其中计算部分由 JobTracker 协调任务、TaskTracker 执行任务。2.0 时代把资源调度这块拆出来做成 YARN出现了 ResourceManager 和 NodeManager 两个新角色JobTracker 和 TaskTracker 退出舞台。所以问「哪个不是 Hadoop 1.0 的组件」答案就是 YARN——它是后来才有的。至于「Hadoop 的大数据层功能」一般指数据挖掘、离线分析、BI 分析这些偏批处理的事实时计算不在其中。这也是理解整个生态的关键Hadoop 的强项是「大批量、能等」不是「立刻要」。3.2 HDFS 的主从结构NameNode 管账本DataNode 管货架把一个 HDFS 集群想成一家连锁仓库。NameNode是总部的账本管理员它不碰货只管记录有哪些目录、有哪些文件、每个文件被切成几块。DataNode是各地仓库的货架真正存数据块、按调度存取数据、定期向总部汇报自己这儿放了哪些块。这套结构最核心的一点是账本和货是分开的。账本元数据常驻 NameNode 内存所以查「这个文件在哪」非常快货在 DataNode 的磁盘上所以能存得很多。SecondaryNameNode是最容易被误解的角色。它做的事是帮 NameNode 收集文件系统运行的状态信息把 FsImage 和 EditLog 合并从而缩短 NameNode 重启的时间。它通过 HTTP GET 的方式从 NameNode 拉取这两个文件到本地目录。它是 HDFS 架构的组成部分但它一般只跑在一台机器上不是并行跑在多台上也不是 NameNode 的热备——NameNode 挂了它顶不上去。还有一个身份问题客户端严格来说不算 HDFS 的一部分。它是一个库暴露 HDFS 的文件系统接口支持打开、读取、写入这些常见操作是用户操作 HDFS 最常用的方式部署时一般都会提供。3.3 块、副本、FsImage 与 EditLog三个最容易被问倒的细节先说块。HDFS 把文件切成固定大小的数据块存放这套题里给的默认值是 64MB属于早期版本的默认后来的版本常见 128MB。做题时按题目给的来理解概念时记住一点就够这个块比磁盘的块大得多而且大小可配置。采用抽象的块概念带来三个明显好处支持大规模文件存储一个文件可以比任何单块磁盘都大、简化系统设计不用管文件边界怎么和磁盘对齐、适合数据备份按块复制比按文件复制灵活。它带来的不是「强大的跨平台兼容性」那是另一个维度的事。再说元数据。NameNode 里保存两个核心数据结构FsImage镜像文件和EditLog编辑日志。FsImage 维护文件系统树以及树中所有文件和文件夹的元数据包含所有目录和文件 inode 的序列化形式但它不记录每个块具体存在哪个数据节点上——块的物理位置是 DataNode 启动后汇报上来的属于运行时信息。EditLog 则记录每一次改动操作。所以「FsImage 记录了每个块存在哪个 DataNode」这句话是错的这是经典陷阱。最后说副本。HDFS 靠多副本增强可靠性常见配置是每个块存三份。多副本的三个好处加快数据传输速度可以从离得近的副本读、容易检查数据错误副本之间比对、保证数据可靠性坏一份还有别的。# 在 HDFS 上建目录并把本地日志文件放进去 hdfs dfs -mkdir -p /demo/input hdfs dfs -put ./access.log /demo/input/ # 查看这个文件被切成了几个块、每块多大、分别落在哪些 DataNode 上 hdfs fsck /demo/input/access.log -files -blocks -locations第一条-mkdir -p的意思是递归建目录父目录不存在会自动创建。第二条-put把本地文件上传到 HDFS此时文件会被按块大小切开。第三条fsck是文件系统检查命令-files列出文件、-blocks列出块信息、-locations列出每个块所在的 DataNode。当你想验证「块」和「副本」到底是怎么落地的这条命令比看十页讲义都直观。3.4 HDFS 的局限它天生不适合干哪些活HDFS 的设计目标很明确兼容廉价硬件、支持流式数据读写、支持大数据集、采用简单的文件模型。它一开始就没打算做一个「通用文件系统」所以有几处天生短板。第一不适合低延迟数据访问。它面向的是「一次读一大片」的吞吐型场景不是「毫秒级查一条」的随机访问。第二无法高效存储大量小文件。每个文件、每个块在 NameNode 内存里都要占一条记录小文件一多账本先撑爆。第三不支持多用户写入及任意修改文件只能追加不能改中间某一段。另外只设置唯一一个 NameNode 虽然简化了设计也带来了四类局限命名空间的限制、性能瓶颈、隔离问题、集群可用性问题。这四条正是后来 HDFS 高可用方案要解决的问题。理解了这些「不能」你才能明白为什么后面会冒出来 HBase、NoSQL 这些东西——它们不是重复造轮子而是冲着 HDFS 干不了的活去的。4. HBase 与 NoSQL为什么「关系数据库不够用」不是一句口号4.1 关系数据库在 Web 2.0 时代的三处不适应关系数据库有两个引以为傲的东西完善的事务机制和高效的查询机制。它们在传统企业应用里是宝贝到了 Web 2.0 场景却有点尴尬。尴尬在三点。第一海量数据管不住数据规模剧增时单机关系数据库的扩展性和性能都吃紧。第二高并发扛不住传统数据库的强事务保证在高并发下代价很高。第三高可扩展性和高可用性难做想加机器不是插上就行。更微妙的是需求本身变了。Web 2.0 网站通常不要求严格的数据库事务不要求严格的读写实时性也通常不包含大量复杂的 SQL 查询——换句话说关系数据库最值钱的两项能力在这里恰好不是刚需反而成了负担。有人会说那就上 MySQL 集群。可集群本身也有麻烦部署、管理、配置复杂主备之间一般是异步复制系统压力大要加机器时牵涉数据重新划分某个数据库组压力过大时还要把部分数据迁出去。这些运维层面的坑不是一句「加机器」能盖过去的。这就是 HBase 出场的理由。Hadoop 能解决大规模数据的离线批量处理但 MapReduce 的高延迟机制让它应付不了实时处理需求HDFS 面向批量访问不是随机访问传统关系数据库在数据结构变化时通常要停机维护空列还浪费存储空间。三件事叠加就逼出了一个新物种。4.2 HBase 的数据模型用「四维坐标」定位一个格子HBase 的底层参考了一套分布式存储系统对应 HDFS、分布式计算框架对应 Hadoop MapReduce和协调服务对应 Zookeeper的组合最终长成了一个稀疏、分布式、多维的映射表。它的数据模型可以这么理解表由行组成每行由行键标识列被划分成若干个列族列族里的数据再通过列限定符定位每个单元格保存同一份数据的多个版本版本用时间戳索引。所以定位一个单元格靠的是行键 列族 列限定符 时间戳这四个因素这就是所谓的「四维坐标」。题目里那个「关键字」是编出来的干扰项。和关系数据库相比差异不止一处。数据类型上HBase 把数据存为未经解释的字符串不预设类型数据操作上它避免了复杂的表与表之间的关系读写的都是单表存储模式上它是稀疏的、按列族聚集的数据维护上它靠版本和时间戳而不是原地更新。注意HBase 是支持修改操作的「不支持修改」是错误说法它只是用追加新版本的方式实现修改。4.3 三层寻址与 Region一条数据到底怎么被找到数据分散在上千台机器上HBase 怎么知道去哪台找答案是三层定位结构。最上面是Zookeeper它记录-ROOT-表的位置。中间是-ROOT-表它记录.META.表的 Region 位置。最下面是.META.表它保存所有用户数据表的 Region 位置信息。客户端拿到位置后还会缓存以减少往返次数同时要处理缓存失效的问题。为了加速寻址.META.表的全部 Region 通常都放在内存里。还有一个前提要记牢-ROOT-表本身只有一个 Region不能有多个。Region是 HBase 里数据分布的基本单位。同一个 Region 不会被拆到多个 Region 服务器上。Region 服务器内部的核心是 Store每个 Store 对应一个列族写入先进内存再刷写成 StoreFileStoreFile 数量太多会影响查找速度所以要合并而合并很耗费资源通常等数量达到阈值才启动。每个 Region 服务器还有自己的一个HLog文件用来在出问题时恢复数据。分布式环境必须考虑出错Zookeeper 会实时监测每个 Region 服务器的状态一旦某台机器失效Master 会先把上面遗留的 HLog 处理掉再把 Region 迁移到别处。Master 主服务器的职责也常被考在 Region 分裂或合并后重新调整分布、迁移失效 Region 服务器上的 Region、管理用户对表的增删改查、在不同 Region 服务器之间做负载均衡。说它「不支持负载均衡」是错的。访问 HBase 的接口不少原生 Java API 适合 MapReduce 作业并行批处理表数据HBase Shell 适合管理Thrift Gateway 和 REST Gateway 适合其他异构系统在线访问Pig 适合做数据统计。性能监视工具也有多种可选包括自带的管理页面以及一些第三方监控系统。# 建表表名 列族。列族必须在建表时定下来之后改动代价很大 create sensor, info, stat # 写入行键 列族:列限定符 值。时间戳由系统自动补上 put sensor, row-001, info:temp, 26.5 # 按行键区间扫描。注意这是行键范围不是按列值过滤 scan sensor, {STARTROW row-001, STOPROW row-009}第一行create里sensor是表名后面两个是列族名。第二行put展示了四维坐标里的前三维修怎么写第四维时间戳由系统打。第三行的STARTROW和STOPROW是左闭右开的行键区间。这段命令最能说明 HBase 的一个本质它只有针对行键的索引访问方式要么按单个行键、要么按行键区间、要么全表扫描没有按时间戳直接查的入口也没有关系数据库那种随意组合条件的查询能力。4.4 NoSQL 的四大类型与三大基石NoSQL 不是「不用 SQL」而是「不把关系模型当唯一答案」。它的几个共性特点是灵活的可扩展性、灵活的数据模型、与云计算紧密融合缺点是数据存储规模并非无限、缺乏统一的理论基础、复杂查询性能不高。按数据模型分四大类型键值数据库扩展性和灵活性好、大量写操作时性能高但存不了结构化信息条件查询效率低列族数据库容易分布式扩展、复杂性低、功能较少且大多不支持强事务一致性文档数据库性能好、灵活性高、数据结构灵活但缺乏统一的查询语法文档之间也通常不支持事务图数据库专门处理高度关联的数据适合社交网络、模式识别、依赖分析、推荐系统和路径寻找灵活性高、支持复杂图算法但复杂性高、能支撑的数据规模有限。题目里那个「时间戳数据库」是不存在的类型。三大基石是CAP、最终一致性、BASE。CAP 说的是分布式系统里一致性、可用性、分区容忍性三者不能同时满足只能在 CA、CP、AP 三条路里选其中一致性指任何一个读操作总能读到之前完成的写操作的结果可用性指能快速获取数据分区容忍性指网络分区导致部分节点失联时系统仍能运行。而关系数据库的 ACID 四性是原子性、一致性、隔离性、持久性。注意「隔离性」这一条很多干扰项会把它换成「间断性」读着顺但根本不是这个词。5. 常见误区与易混概念五组「看着像、其实不是」的考点5.1 易混点分布式存储和分布式处理是一回事吗为什么混这两个词经常成对出现还都带「分布式」很容易被当成同一件事的两种叫法。加上 Hadoop 一个框架里同时提供了 HDFS 和 MapReduce更容易糊成一团。怎么区分看它解决的是「放哪儿」还是「怎么算」。分布式存储回答的是数据放在哪、怎么切、怎么备份、怎么读回来代表是 HDFS分布式处理回答的是任务怎么拆、怎么并行、怎么汇总代表是 MapReduce。这两个是大数据技术的两大核心缺一不可但职责完全不重叠。一个粗略的判断法如果这个组件关心「块、副本、节点磁盘」它属于存储侧如果关心「作业、任务、调度、结果合并」它属于计算侧。5.2 易混点HDFS 的块和磁盘的块是同一个东西吗为什么混都叫「块」都是把数据切成固定大小的一段名字撞车得太彻底。怎么区分磁盘块是硬件和操作系统层面的概念目的是让寻址和读写更高效HDFS 的块是文件系统层面的抽象单位目的是简化系统设计、支持超大文件、方便备份。两者大小差着好几个数量级——磁盘块通常只有几 KBHDFS 的块是几十 MB 起步。更关键的是后果不同磁盘块选多大影响的是一次 I/O 的效率HDFS 块选多大影响的是 NameNode 要维护多少条元数据块越小文件被切得越碎、账本压力越大。所以「把块调小一点是不是更灵活」这个想法在 HDFS 上恰恰是反的。5.3 易混点SecondaryNameNode 是 NameNode 的备胎吗为什么混名字里带「Second」中文又译成「第二名称节点」听起来就像个副手随时准备接班。怎么区分它的实际工作是「帮手」不是「替补」。它定期把 NameNode 的 FsImage 和 EditLog 拉过来合并产出一份更紧凑的镜像从而缩短 NameNode 重启时的恢复时间。它一般部署在一台机器上不是并行跑在多台上它不对外提供任何读写服务NameNode 宕机时它顶不上去。把它当备份是这类题里最常见的一次翻车。5.4 易混点CAP 是不是「三选三」BASE 是不是「不要一致性」为什么混CAP 常被简化成一句「只能三选二」听起来像做选择题BASE 里的「最终一致性」听起来又像「暂时不一致也行」很容易被理解成放弃一致性。怎么区分CAP 的前提是「发生网络分区时」。没有分区的时候一致性和可用性是可以同时要的一旦分区出现才必须在 C 和 A 之间取舍。所以 CA、CP、AP 是三种设计取向不是三个打分项。BASE 指的是基本可用、软状态、最终一致它放弃的是「强一致」而不是「一致」——系统最终还是要收敛到一致状态只是允许中间有一段时间不一致。把「最终」两个字去掉意思就全变了。5.5 易混点数据量大就等于大数据吗为什么混字面意思太直白量大自然而然就是大数据好像没什么可争的。怎么区分量大只是四个特征里的一个。真正的分水岭在于另外三条数据来得快不快快速化、类型杂不杂多样化、单位体积里能淘出的价值高不高价值密度低。一堆结构整齐、增长缓慢、查起来简单的历史订单哪怕有几十 TB用传统关系数据库照样能对付反过来每秒涌进来的、格式五花八门的传感数据哪怕总量不大也逼得你上流式计算。判断要不要上大数据技术问的应该是「现有工具处理起来是不是又慢又贵又难扩」而不是「我有多少 TB」。6. 什么时候该刷这套题、什么时候别指望它这套资料最适合的场景是「学过一遍、需要把散落的概念焊成结构」的时候。它的价值不在于那一行行 ABCD而在于它按章节把知识点排了一遍第一章把浪潮、4V、产业链、云计算物联网铺开第二章到第四章顺着 Hadoop、HDFS、HBase 往下走第五章收在 NoSQL 的理论基石上。你顺着做一遍等于有人替你把这门课的地图描了一次哪里断线一目了然。场景适合程度说明期末复习前自查薄弱章节很适合按章刷错哪章补哪章效率最高面试前快速回忆术语体系适合名词定义、组件职责这类问题命中率高想搞懂某个机制的运行细节不太适合题目只给结论不给推导过程想动手搭环境跑任务不适合这是概念题不是操作手册想直接背答案应付考试谨慎部分选项描述与通行定义有出入背错更麻烦最容易踩的坑是把「做对」当成「学会」。这套题里有不少题是纯记忆型的比如某个组件叫什么、某个层次包含哪几项选对了不代表你理解它为什么存在。真正值得花时间的是那些「下列哪项不属于」的题——排除项往往是命题人故意放进去的近似概念搞清楚它为什么被排除比记住正确答案收获大得多。我自己的血泪经验是这样的第一次刷的时候我追求速度一晚上刷完五章正确率还不错心里挺美。结果隔了一周再问自己「为什么 HDFS 不能存大量小文件」脑子里只剩一句「因为不好」具体不好在哪完全说不上来。后来我改了个笨办法——每道题先不看选项自己用一句话把答案写出来再和选项对照凡是写不出来的说明那块知识是空的不是记性问题。这个习惯坚持下来之后类似的题基本不会再翻车。从那以后我每次碰这类测试资料都强制自己先写答案再看选项宁可慢一半。所以更靠谱的用法是把它当体检单不当药方。查出来哪一章虚就回去补那一章的概念和场景等你能对着目录把每章的核心问题讲给一个完全不懂的人听这套题才算真的用透了。希望帮到你。本文还有配套的精品资源点击获取