简介：这是一份面向物联网、云计算与大数据课程学习与复习的习题文档，覆盖云计算定义与特点、IaaS/PaaS/SaaS服务模式、大数据4V特征、虚拟化技术、数据中心选址与PUE/DCIE指标等核心考点，适合高校学生、自考者及备考人员自测与查漏补缺。资源包仅1个docx文件，共209KB，文件按章节归纳核心问题，以问答题形式列出精选知识点并附参考答案，内容包含云计算基础设施、大数据价值链、并行计算与集群等模块，方便随时打开刷题、打印整理或对照教材复盘。该文档已有246人学习浏览，兼具基础概念总结与简答论述训练价值，读者可借助其中的术语解释、关系梳理和开放性思考题，快速建立云计算与大数据知识框架，为后续课程考核、考证准备或项目实践打下扎实基础。
1. 拿到一份《云计算与大数据技术应用习题.docx》，先别急着刷
大多数人的第一反应是打开这份 Word 文档，从头到尾把题目过一遍，觉得“见过的就划掉，没见过的就去查”。这个做法效率很低，因为习题文档的价值不在题目本身，而在出题人的关注点——他反复在题干里出现的名词，才是这门课（或这套题）真正想让你掌握的能力边界。与其逐题做，不如先把文档当作语料库，统计一遍核心术语的密度，弄清这套题是偏云计算架构、偏大数据平台，还是偏数学算法。这份文档的标题里同时出现了“云计算”和“大数据”，意味着考察面横跨 IaaS/PaaS/SaaS 模型和 Hadoop/Spark 生态链，适合正在准备期末考试、毕业设计或技术面试的人。它的用法不是“做完对答案”，而是“当考纲读”。
2. 先用 python-docx 给习题做词频盘点，把出题范围读出来
2.1 提取正文：不要只读标题，题干的定语往往泄露出题人的软件栈
一份 Word 格式的习题集，正文藏在.docx的 XML 结构里，直接复制粘贴也能看，但无法量化。常见做法是用python-docx把段落文本全部取出来，再做一次分词统计。这个动作 5 分钟就能完成，却能立刻告诉你：这套题里出现的是“HDFS”还是“对象存储”，是“虚拟化”还是“容器编排”，是“MapReduce”还是“Spark SQL”。这些词决定了你后续复习要往哪个技术栈倾斜。
from docx import Document from collections import Counter import re doc = Document("云计算与大数据技术应用习题.docx") # 提取所有段落文本，跳过空行 text = "\n".join([p.text for p in doc.paragraphs if p.text.strip()]) print(f"全文字符数: {len(text)}") # 按技术名词列表做精确匹配计数 terms = [ "云计算", "虚拟化", "IaaS", "PaaS", "SaaS", "容器", "Docker", "Kubernetes", "Hadoop", "HDFS", "MapReduce", "Spark", "Hive", "YARN", "数据仓库", "数据湖", "负载均衡", "容灾", "分布式", "集群", "对象存储", "深度学习", "可视化" ] counts = Counter({t: len(re.findall(t, text)) for t in terms}) for term, cnt in counts.most_common(15): print(f"{term}: {cnt} 次")代码逻辑分三段：先遍历doc.paragraphs拿到全部段落文本，剔除空段；再做精确匹配，len(re.findall(t, text))统计每个术语出现的次数；最后按频率降序打印前 15 个。注意，re.findall是统计“出现次数”而不是“题目数量”，一个题干里出现五次“HDFS”也只算五次匹配，这能体现该名词在文档里的密度，但不代表有五道题。如果要精确到“出现在多少道题里”，需要先按题号切分文本，再逐题判断是否包含关键词，那属于下一步的细粒度分析。
2.2 词频结果怎么看：三个信号决定备考优先级
拿到统计结果后，不要只看排名第一的词。重点观察三个信号：第一，云计算侧和大数据侧的词频比例。如果“虚拟化”“IaaS”出现频次明显高于“HDFS”“MapReduce”，说明这套题重架构轻平台；反过来，如果“HDFS”“YARN”密集出现，说明平台运维与集群部署是主线。第二，看“Spark”和“MapReduce”的频次对比。两者都高，说明题目会考“新旧技术对比”这类辨析题；如果只偏向老技术，那大概率来自一本以 Hadoop 为主的教材，Spark 可能只在选择题里出现。第三，看有没有“数据湖”“数据仓库”这类偏应用层的词。出现频次高，意味着题目会涉及数仓建模或 OLAP 场景，而不是纯原理背诵。
2.3 按考点密度圈定章节顺序，别从头刷到尾
习题文档的章节排列顺序，往往和教学顺序一致，不代表和出题权重一致。用词频统计圈出前三个高频主题后，直接跳过低频章节，优先刷高频区。这里有一个容易踩的坑：很多习题文档的“简答题”和“计算题”混排，题干里的名词密度低，但分值高。所以不要只统计名词，还要把“简述”“计算”“论述”“画出”这四类指令词单独拉出来统计一遍，它们决定了你要练“默写定义”还是练“推导过程”。
import re verbs = ["简述", "说明", "请给出", "计算", "推导", "论述", "画出", "比较"] verb_counts = {v: len(re.findall(v, text)) for v in verbs} # 按题型统计题号前缀，例如第1题、第2题这种格式 questions = re.findall(r"第?\s*(\d+)\s*[题、.．]", text) print(f"识别到的题号数量约: {len(questions)}") for v, cnt in verb_counts.items(): if cnt > 0: print(f"{v}: {cnt} 次")这里的verbs列表覆盖了典型试题指令词，第?\s*(\d+)\s*[题、.．]用于粗识别题号。实际使用中，题号格式可能写成“1. ”或“1、”，需要先打开文档目视确认前两题的写法，再调整正则。这个步骤虽然琐碎，但它能把“刷题计划”从感觉变成数据决策——至少你知道哪章最值得花三小时精练。
3. 云计算习题的骨架：IaaS/PaaS/SaaS 三类题目的答题路径
3.1 先分模型再答功能：云基础设施机制的题目千万别写成运维配置
云计算部分的题目，不管题干包装成“某企业需要弹性扩容”还是“请解释云环境的基础构件块”，落点永远是三个服务模型。记住一个判断标准：题目里出现“虚拟机”“网络”“存储”且用户自己管操作系统，就是 IaaS；出现“数据库实例”“应用运行时”且用户只管代码，就是 PaaS；出现“登录即用”的软件能力，就是 SaaS。这个边界搞不清，简答题写的字数再多也拿不到分，因为阅卷老师期待的关键词是“资源抽象级别”而不是“部署命令”。
| 服务模型 | 用户控制范围 | 典型题目题干信号 | 答题落点 |
|---|---|---|---|
| IaaS | 操作系统及以上 | 虚拟机、块存储、VPC、弹性伸缩 | 资源池化、虚拟机监控器、裸金属与虚拟化区别 |
| PaaS | 应用代码及数据 | 中间件、数据库服务、容器平台 | 平台托管、自动扩缩容、开发运维一体化 |
| SaaS | 业务配置及使用 | CRM、在线办公、订阅制 | 多租户隔离、租户间数据隔离策略 |
答题时先点出模型归属，再写该模型对应的基础设施机制。比如“负载均衡”在 IaaS 里是网络层的分发策略，在 PaaS 里是平台内置能力，在 SaaS 里是服务本身的冗余设计。同一个名词，三个模型下答案完全不同，这是习题集最喜欢挖的坑。
3.2 集群部署与云覆盖度：两道高频计算题的通用公式
云计算计算题的常见套路是给一个业务场景，让算“需要多少台云主机”或“集群覆盖度达到多少”。这类题的核心公式只有一个：目标容量除以单节点有效容量，再乘以冗余系数。冗余系数由可用性要求决定，可用性 99.9% 和 99.99% 的系数差一个数量级。
集群部署策略的题目里，常出现“云覆盖度”这个概念，它衡量的是实际分配的云资源占目标配额的比例。公式为：云覆盖度 = 已分配实例数 ÷ 目标配额实例数 × 100%。如果题目给的是核数或内存配额，同理换算。批量计算时可以用一个简单的 bash 脚本：
#!/bin/bash # 云覆盖度批量计算：queues 文件每行格式：实例名 已分配 目标 while read name allocated target; do coverage=$(echo "scale=2; $allocated * 100 / $target" | bc) echo "$name 云覆盖度: ${coverage}%" done < queues.txt脚本用bc做浮点除法，scale=2保留两位小数。注意输入文件里不要有表头行，否则循环第一行会报错；如果文件里有空行，加一行[ -z "$name" ] && continue跳过。这道题的得分点不在计算本身，而在你有没有写“在目标配额不变的情况下，扩大集群规模会降低云覆盖度”这句结论——它考查的是概念理解，不是算数。
3.3 华为云、AWS 或国外平台题：平台名词是幌子，架构原理才是落点
很多习题文档会在题干里直接写“华为云”“AWS”“阿里云”的某个具体产品名。遇到这种题，别慌着去背产品文档，大多数情况下出题人只是借产品名词引出通用概念。比如题干提到华为云的弹性云服务器（ECS），要答的还是 IaaS 的资源池化与计费模型；提到国外云计算平台的 S3 存储桶，考点依然是对象存储的基本特征：扁平命名空间、HTTP 接口访问、最终一致性。明确这一点后，答题时先写通用原理，再补一句“以 XX 平台为例”的对应实现，既显得有实践认知，又不至于被某家平台的封闭细节带偏。
4. 大数据习题的主干：HDFS 与 MapReduce 的推导题要能默写
4.1 HDFS 块大小与副本策略：从参数反推来由，比死记数字有用
大数据部分最常考的题目不是“HDFS 默认块大小是多少”，而是“为什么块大小设计为 128MB”。前者是记忆题，后者是理解题。理解题的答法分三层：第一层说磁盘寻道时间，块越大，寻道时间占传输时间的比例越低；第二层说 NameNode 内存压力，块的数量决定了元数据条目的数量，块越大，元数据越少；第三层说 MapReduce 任务粒度，块太大导致 Map 任务数变少，并行度下降。三层写完，阅卷老师就知道你不是背的。
HDFS 参数相关的题目，可以准备一张自查表，省得临时翻文档：
| 参数项 | 配置位置 | 常见取值 | 考察点 |
|---|---|---|---|
dfs.blocksize | hdfs-site.xml | 128M / 256M | 块大小与寻道时间、元数据开销的关系 |
dfs.replication | hdfs-site.xml | 默认 3 | 副本放置策略：同机架、跨机架 |
dfs.namenode.handler.count | hdfs-site.xml | 默认 10 | NameNode 并发处理能力 |
dfs.datanode.data.dir | hdfs-site.xml | 多盘路径 | 数据目录与磁盘 IO 隔离 |
mapreduce.map.memory.mb | mapred-site.xml | 1024 左右 | 内存超限导致 OOM 的原因 |
凡是出现“集群节点数为 N，副本数为 3，求数据占用空间”这类计算题，直接用原始数据量 × 副本数这个公式，同时注明“不包括校验与快照开销”。如果题目给了机架感知策略，还要额外加上跨机架传输带来的拷贝开销，这是易错点。
4.2 MapReduce 题先画 shuffle，再用最小 Python 代码复现
MapReduce 相关的题目，尤其是简答题，很难用一段文字讲清楚，因为里面涉及排序、分区、溢写、合并、拉取 Fetch 等多个阶段。最靠谱的做法是：先在草稿纸上画出数据流向，从 Map 输出开始，经过 partition → sort → spill → merge → copy → merge → reduce 输入，然后再对着图答题。画图时注意两个关键细节：分区数等于 Reduce 任务数；溢写时会对键做排序，默认按字典序。
如果题目给了 Map 输出的键值对样例，要求模拟 Reduce 阶段的逻辑，可以用一小段 Python 代码来推演结果：
# 模拟 Map 阶段输出：按 key 分组，value 是计数 map_output = [ ("cloud", 1), ("big", 1), ("cloud", 1), ("data", 1), ("big", 1), ("cloud", 1) ] # 分组：key -> list[values] from collections import defaultdict groups = defaultdict(list) for key, value in map_output: groups[key].append(value) # 模拟 Reduce 阶段：按 key 聚合求和 for key in sorted(groups): # 排序过程对应 shuffle 中的 sort total = sum(groups[key]) print(f"{key}\t{total}")这段代码的核心是groups[key].append(value)和sum(groups[key])，分别对应 MapReduce 里的 Shuffle 分组和 Reduce 聚合。sorted(groups)不是必要的，但它模拟了框架默认排序行为，答“输出顺序”类题目时有用。注意，真实的 MapReduce 里 Reduce 的输入已经按 key 排序好，不需要自己再排序；这里排一次是为了输出稳定，方便对照预期结果。
4.3 Spark 与 Hadoop 分水岭：旧题里的“替代关系”考的是场景选择
习题集里常见一类比较题：“Spark 能不能完全替代 MapReduce？”答案是不能，因为两者定位不同。MapReduce 的优点在于稳定、内存占用可控、适合超大规模离线全量计算；Spark 的优势在于内存计算、DAG 调度、适合迭代式计算和交互式查询。答题时给出“场景选型”建议：ETL 清洗用 Spark SQL 更顺手，海量日志的简单计数用 MapReduce 也不会错，但题目如果想考你“为什么 Spark 跑迭代算法更快”，落点一定是 RDD 的血缘关系和内存缓存，而不是 Spark 写得有多简单。这类题对备考大数据技术期末考试和面试都适用，面试官关心的是“你在什么场景下选什么框架”，而不是“你背过几个 Spark 算子”。
5. 用三道收尾动作，把错题刷成技术资产
5.1 错题表：按“读题→写参数→算复杂度→核边界”四步记录
一份习题文档刷完第一遍，错题不用急着重做，先把它做成结构化记录。我一般会在 Markdown 里维护一张表，每道错题占一行，固定四列：读题（题干真正在问什么）、参数（涉及哪些配置项或公式）、复杂度（如果是设计题，估算时间复杂度）、边界（容易被忽略的约束）。这张表的作用是建立“题目 → 考点 → 易错点”的映射，第二次复习时只看这张表的“边界”列就够了。
| 题目编号 | 读题落点 | 关键参数 | 边界条件 |
|---|---|---|---|
| Q17 | 判断服务模型归属 | IaaS / PaaS / SaaS | 题干含“自行安装操作系统”即 IaaS |
| Q34 | HDFS 块大小设计原因 | 寻道时间、元数据 | 块大小与 Map 并行度成反比 |
| Q41 | Spark RDD 依赖类型 | 窄依赖 / 宽依赖 | shuffle 必然产生宽依赖 |
5.2 题后十五分钟：把每个名词挂到真实场景上
做完一套题，最后留十五分钟，把答题里出现过的技术名词逐个问一遍“这在我的服务器上对应哪个组件”。HDFS 对应你机器上的哪个数据目录，YARN 对应哪个资源调度进程，云覆盖度在你的云控制台哪一页能看到。如果当前没有生产环境，就翻一遍现有的大数据集群部署策略文档，把习题里的结论和部署文档里的参数对应上。这一步不是多余，它决定了一份习题文档是“做完就忘”还是“变成经验”。真正有效的复习，不是把题目再做一遍，而是把题目里的抽象结论还原成自己环境里的具体配置。
本文还有配套的精品资源，点击获取
