简介针对云计算与大数据技术核心知识点整理的习题文档面向物联网、CS及相关专业的初学者和备考者适用于课程复习、期末考核、技能认证或面试准备。整个压缩包仅1个docx文件大小约209KB内容以问答与填空形式系统覆盖云计算基本概念与特点、IaaS/PaaS/SaaS三种服务模式、分布式文件系统与MapReduce基础设施、非结构化与半结构化数据、大数据4V特征、虚拟化原理及常见技术、数据中心发展阶段与选址要素、PUE/DCIE能效指标等关键知识点。题目紧贴教材重点并附带参考答案式解答便于读者自测后对照梳理、查漏补缺从预览内容看还涉及并行计算发展历程与集群分类等拓展问题能帮助深化对整体知识框架的理解。目前已有247人学习下载适合希望快速巩固云计算与大数据基础、提升应试能力的读者。1. 一份习题集把云计算、大数据与仿真连成一条线说实话刚看到这份《云计算与大数据技术应用习题.docx》的时候我以为是那种网上到处都能搜到的填空题合集准备扫两眼就关掉。结果往下翻了几下发现它把云计算概念、大数据特征、虚拟化原理、数据中心能耗指标、并行计算模型、OpenStack 组件、Hadoop 搭建、Spark 生态、Storm 架构和 CloudSim 仿真全串在了一条线上。对正在准备云计算期末考试、大数据课程设计或者刚转岗云计算运维、大数据开发想补一遍底子的从业者来说这份资料能当一份「自检清单」用——先看自己哪些点能答上来哪些点是死记硬背没真正理解的再针对性地把原理补上。下面我按自己的拆解习惯把这份资料里的技术点、可复现步骤和踩过的坑一起梳理出来。2. 云计算、大数据与虚拟化把三个最容易被问懵的概念钉死2.1 云计算的三种定义角度与五大特点资料里对云计算给了一组定义我拆开看其实是三个视角叠加动态扩展的计算模式、按使用量付费的资源共享池、基于互联网的服务交付模式。这三个视角对应了三类人关心的事——架构师关心虚拟化资源的供给和释放财务关心按量计费业务方关心能不能快速拿到资源。五大特点里最容易在面试或考试里被追问的是「资源虚拟化和弹性调度」和「按需分配、按量计费」这俩。前者是技术手段后者是商业模式。很多人把这两点混在一起答面试官一听就知道是背的。正确理解是虚拟化让资源的「逻辑边界」可变弹性调度让资源跟业务负载走按需分配和按量计费是这种技术能力在商业上的兑现方式。另外一个容易被忽略的点是「大规模并行计算能力」——它不是云平台自身的属性而是底层集群规模的体现本质上依赖第 4 章会讲到的并行计算和集群技术。提示答题时把这五个特点按「技术 → 商业」两层组织比逐条背诵更容易拿分。2.2 IaaS、PaaS、SaaS服务模式的边界在哪IaaS、PaaS、SaaS 这三个缩写几乎每份云计算的考卷都有但很多人卡在边界判断上。我习惯用一个类比IaaS 是租毛坯房PaaS 是租精装房但家具自己买SaaS 是拎包入住。对应到资源层面IaaSInfrastructure as a Service提供计算、存储、网络这些基础设施资源用户自己管操作系统和上面的一切PaaSPlatform as a Service提供开发、测试、运行应用程序的平台用户只管自己的代码和数据SaaSSoftware as a Service直接交付完整应用用户连部署都不用管。服务模式用户管理范围云厂商管理范围典型场景IaaS操作系统、运行时、应用、数据虚拟化、服务器、存储、网络自建大数据集群、迁移传统应用PaaS应用、数据平台运行时、中间件、基础设施开发云原生应用、部署微服务SaaS数据使用全套软件与基础设施CRM、在线文档、协同办公2.3 大数据的 4V 特征与价值链为什么价值密度低才是真痛点大数据的 4V——多样性Variety、规模性Volume、快速性Velocity、价值密度低Value——资料里列得很清楚。实操中前三项都有明确的技术方案去应对多样性强依赖非结构化数据处理规模性靠分布式存储快速性靠流处理框架第 4 章的 Spark Streaming、Storm 就是干这个的。真正让项目难做的是「价值密度低」。我做过一个物联网传感器数据清洗的活一天几千万条记录真正对业务有用的可能就几百条。传统思路是「先存下来再说」结果存储成本先爆了。后来学乖了先用流处理做一层过滤只把有特征的数据落盘存储量直接少了两个数量级。这也对应了资料里大数据价值链的三大构成——数据本身、技能与思维——数据的量不是价值能从里面挖出东西才是。2.4 虚拟化技术云计算的底层杠杆资料里对虚拟化的定义是「对计算机资源的抽象」四个理由写得很实在共享资源互不影响、零散资源集中管理、动态调整资源分配、降低运维复杂度。这些理由放到现在做私有云选型时依然成立——我帮客户搭过一套基于 KVM 的虚拟化平台就是冲着前两条去的。常见的虚拟化技术分类要能分清楚CPU 虚拟化、内存虚拟化属于资源级虚拟化全虚拟化和半虚拟化的区别在于客户机操作系统是否需要修改——全虚拟化不需要改半虚拟化需要改且性能更好硬件辅助虚拟化是 CPU 厂商Intel VT-x、AMD-V提供的硬件支持让全虚拟化的性能损耗大幅降低存储虚拟化则把不同厂商、不同接口的存储设备统一成逻辑资源池。这个概念在后文云存储的「基础管理层」里会再次出现值得先记住。3. 数据中心与云存储PUE/DCIE 的计算口径与四层存储模型3.1 数据中心四阶段与选址从巨型机到云时代资料里把数据中心的发展分成四个阶段巨型机时代、微型计算机/PC 时代、互联网时代、云计算与大数据时代。这个演进线的本质是计算中心的「下沉」——从一台机器集中计算到 PC 分散计算再到互联网把分散节点连起来最后云平台把连接后的资源池化。选址四要素——地质条件、气候环境、电力供给、网络带宽——前两个是物理约束后两个是运行约束。实际项目里电力成本往往比硬件成本更早成为瓶颈。贵州能吸引一堆数据中心落地就是因为气候凉爽能省制冷电耗水电资源丰富能压低电力成本这正好对应了 PUE 指标优化的思路。3.2 PUE 与 DCIE两个能耗指标的计算口径PUEPower Usage Effectiveness和 DCIEData Center Infrastructure Efficiency是数据中心能耗评估的一对反指标都是美国绿色网格联盟在 2007 年提出的PUE 数据中心整体能耗 / IT 设备能耗值越接近 1说明越省电实际数据中心一般在 1.2 到 2.0 之间。DCIE IT 设备能耗 / 数据中心整体能耗它是 PUE 的倒数值越高越好。资料里的填空定义容易丢分考场里可以顺手把公式写出来。我见过有人把 PUE 和 DCIE 的分母分子搞反整理成一句话就是PUE 的分母是 IT 设备DCIE 的分子是 IT 设备。一个是「整体是 IT 的多少倍」一个是「IT 占整体的多少比例」方向正好相反。3.3 云存储四层结构模型每一层管什么云存储系统的结构模型有四个层次从下往上分别是存储层、基础管理层、应用接口层、访问层。这个分层思路和我拆过的海量文件存储项目基本一致区别是商用方案每一层都有对应的开源或商业组件。存储层最基础的物理设备层存储设备通过广域网、互联网或 FC 光纤通道互连形成一个海量数据池。难点在于多设备统一管理、状态监控、容量动态扩展。基础管理层最核心也最难实现的一层。通过集群、分布式文件系统、网格计算实现多设备协同对外提供统一服务。可以理解为「把一堆硬盘变成一个文件系统」。应用接口层面向业务的可变部分根据业务类型提供不同的服务接口比如数据存储、数据备份、公共资源使用。访问层面向用户的部分负责访问控制、身份识别与验证、安全隔离。注意答题或做架构设计时最容易漏掉访问层。很多人只记住存储和管理忘了安全隔离和身份认证也是一层职责。3.4 云存储的实现前提与典型应用资料里列了六个实现前提面试常考的是集群/分布式文件系统、重复数据删除、存储虚拟化这三个。重复数据删除的缩减比能从 10:1 到 50:1这让我想起之前做备份系统容量规划时全靠源端重删把存储采购预算压了下来前期不配重删后期扩容成本会非常难看。个人级云存储应用网络存储磁盘、在线编辑器、在线网络游戏和企业级云存储应用空间租赁、远程数据备份及容灾、视频监控在资料里都有展开。做运维的可以把企业级远程容灾这个点记牢——云存储的价值不只是「多一块硬盘」而是让容灾从「自建备机房」变成「租服务」单点故障对业务的影响被转移到服务商侧。4. 并行计算与 OpenStack从设计模型到核心模块的对应关系4.1 并行计算的发展脉络与集群分类资料里捋了一条很清晰的线1972 年伊利诺伊大学的 ILLIAC IV64 个处理器可扩展性好但可编程性差80 年代 MIMD 百花齐放90 年代框架统一为 DSM、MPP、工作站机群 COW21 世纪后走向商品化微处理器互连的集群NOW。这条线的核心矛盾始终没变——可扩展性和可编程性之间的取舍。集群系统的四分类——高可用、负载均衡、高性能、虚拟化——对应着不同的故障处理策略高可用集群解决「坏了怎么办」负载均衡集群解决「多了怎么分」高性能集群解决「快了怎么算」虚拟化集群解决「资源怎么切」。很多人在简历里写「熟悉集群」面试官追问一句「你做的是哪种集群」就卡住了提前分清这四类能少踩这个坑。4.2 四种并行设计模型隐式并行、数据并行、共享变量、消息传递并行计算的设计模型是考试高频点也是理解后面 Hadoop、Spark 架构的钥匙。资料里的四种模型可以这样对应记忆设计模型编程视角适合硬件交互方式典型代表隐式并行写串行代码编译器自动并行化通用 CPU隐式自动并行化编译器数据并行单线程、对数组等聚合结构做并行操作SIMD隐式交互、松散同步HPF共享变量多线程、单一地址空间PVP、SMP、DSM显式同步、隐式通信OpenMP、POSIX消息传递多线程、多地址空间MPP、COW显式通信、显式映射MPI、PVM数据并行和消息传递这两类分别对应了 Spark 和 Hadoop/Storm 的底层思路——Spark 的 RDD 本质是数据并行模型在分布式内存上的实现Hadoop MapReduce 里 map 和 reduce 之间的 shuffle 则是消息传递思想在数据框架里的落地。4.3 OpenStack 核心模块Neutron、Nova、Swift、Cinder 各管什么OpenStack 的组成模块在资料里列了七个大块考试常考的是其中四个。Nova 管计算负责对接 KVM、Xen 等虚拟化接口是 IaaS 的核心Neutron 管网络把网络、子网、端口、路由器抽象成虚拟网络资源让虚拟机实例能挂到虚拟网络上Swift 管对象存储提供简单的 API 存取数据设计目标是大规模数据集的持久性、可用性、并发性Cinder 管块存储供 Nova 管理的虚拟机实例挂载使用实现上常依赖 LVM 技术。Swift 和 Cinder 的区别是高频题。我自己的理解Cinder 像给虚拟机接一块「云硬盘」必须和计算实例绑定生命周期跟着实例走Swift 像一个「对象网盘」用 API 存取适合存图片、备份、日志这类文件不绑定任何计算实例。一个是块设备一个是对象这两者的本质差异比「开源项目名」重要得多。4.4 Spark 与 StormRDD 五特征、运行模式与流处理架构资料里关于 Spark 的三道题——RDD 五大特征、运行模式、生态系统——可以连起来答。RDD 的五个特征分区、Compute 函数、依赖、分区函数、优先位置是一套完整的分布式数据集描述分区决定数据怎么切Compute 决定分区怎么算依赖决定数据怎么恢复分区函数决定数据怎么分优先位置决定任务往哪台机器调度。理解了这五个点Spark 的性能调优就入门了——数据倾斜找分区函数数据恢复找依赖链。Spark 的运行模式按部署规模分级单机上用本地模式跑通逻辑伪分布模式练手集群上用 Standalone 或外接 YARN、Mesos。做课程设计或小项目时本地模式和 Standalone 最常用生产环境基本是 YARN 模式因为可以和已有的 Hadoop 集群共用资源调度。Storm 的架构可以拆成三进程Nimbus、Supervisor、Zookeeper加两组件Spout、Bolt。Nimbus 负责任务分发Supervisor 负责执行Zookeeper 负责协调Spout 是数据源Bolt 是处理逻辑。用一句话记住Nimbus 是大脑Supervisor 是手脚Zookeeper 是神经Spout 进水、Bolt 加工。5. Hadoop 实战与避坑环境搭建、WordCount 测试与五个常见问题5.1 搭建 Hadoop 开发环境八个步骤的顺序逻辑资料里给的 Hadoop 搭建步骤看着简单但每一步都有为什么。我按自己的补全习惯整理成一份可用的命令序列环境假设是 CentOS 7 Hadoop 2.4.1 JDK 1.7用户是 hadoop。# 1. 修改主机名让集群节点有固定的身份标识 hostnamectl set-hostname hadoop-node1 # 2. 修改 IP 并绑定主机名避免后来 IP 变动导致集群节点互访失败 vi /etc/sysconfig/network-scripts/ifcfg-eth0 echo 192.168.1.101 hadoop-node1 /etc/hosts # 3. 关闭防火墙并禁止开机启动否则节点间 RPC 通信会被拦截 systemctl stop firewalld systemctl disable firewalld # 4. 安装 JDK 并配置 JAVA_HOMEHadoop 本身是 Java 写的没有 JDK 起不来 tar -zxvf jdk-7u80-linux-x64.tar.gz -C /usr/local/ echo export JAVA_HOME/usr/local/jdk1.7.0_80 /etc/profile echo export PATH$PATH:$JAVA_HOME/bin /etc/profile source /etc/profile前四步是环境准备核心逻辑是「先有固定身份再开网络通路最后配好运行环境」。防火墙不关或 hosts 不写后面启动 HDFS 时经常出现 DataNode 连不上 NameNode 的情况排查起来非常折腾。# 5. 解压 Hadoop 并修改五个配置文件的路径与参数 tar -zxvf hadoop-2.4.1.tar.gz -C /usr/local/ cd /usr/local/hadoop-2.4.1/etc/hadoop # hadoop-env.sh指定 JDK 路径Hadoop 启动脚本依赖这个变量 echo export JAVA_HOME/usr/local/jdk1.7.0_80 hadoop-env.sh # core-site.xml配置 NameNode 地址HDFS 客户端和 DataNode 都靠它找到主节点 # hdfs-site.xml配置副本数默认 3 份单机测试改 1 份能省空间 # mapred-site.xml指定 MapReduce 跑在 YARN 上否则默认走本地模式 # yarn-site.xml配置 ResourceManager 所在节点五个文件各管一件事hadoop-env.sh 管 JVM 环境core-site.xml 管集群入口hdfs-site.xml 管存储策略mapred-site.xml 管计算框架yarn-site.xml 管资源调度。新手最常见的错误是只改 core-site.xml 就急着启动最后 map 任务跑不起来报错指向「JobTracker 不可用」——因为根本没配 mapred-site.xml。# 6. 格式化 HDFS 文件系统初次使用必做重复执行会清空元数据 hdfs namenode -format # 7. 启动 Hadoop 集群脚本会自动拉起 NameNode、DataNode 和 YARN 相关进程 start-dfs.sh start-yarn.sh # 8. 用 jps 验证进程能看到 NameNode、DataNode、ResourceManager 才算启动成功 jps格式化这一步新手容易在「每次启动前都 format」。但重复格式化会导致 NameNode 的 namespaceID 和 DataNode 不一致DataNode 启动后报错且无法自动注册。判断是否需要格式化的标准很简单只有第一次搭建或元数据彻底损坏时才需要平时启动直接 start-dfs.sh 就行。5.2 WordCount 验证从上传文件到查看结果环境起来之后资料里用 WordCount 做了功能验证完整命令序列如下# 1. 创建输入数据文件两个测试文件模拟不同内容的语料 mkdir /home/hadoop/WordCount echo This is the first hadoop test program! /home/hadoop/WordCount/file1.txt echo This program is not very difficult, but this program is a common hadoop program! /home/hadoop/WordCount/file2.txt # 2. 在 HDFS 上创建输入目录并确认目录存在 hadoop fs -mkdir /input hadoop fs -ls / # 3. 把本地文件上传到 HDFS 的 /input 目录 hadoop fs -put /home/hadoop/WordCount/*.txt /input # 4. 运行官方自带 WordCount 示例注意输入输出目录写全 hadoop jar /usr/local/hadoop-2.4.1/share/hadoop/mapreduce/hadoop-mapreduce-examples-2.4.1.jar wordcount /input /output # 5. 查看输出目录和结果文件 hadoop fs -ls /output hadoop fs -cat /output/part-r-00000注意/output 目录不能提前存在MapReduce 框架不会覆盖已有输出目录存在会直接报错这是官方示例最常见的翻车点。WordCount 的输出是单词 出现次数的格式比如hadoop 2、this 1。如果输出文件里有大量___开头的行说明 map 阶段处理了空行或特殊字符这是数据本身的问题不是框架的问题——拿真实数据跑之前先做清洗。5.3 Hadoop 搭建常见问题排查五个高频现象与解决方案现象 1DataNode 启动后立刻退出日志里报 namespaceID 不一致。原因格式化 NameNode 后重启又重复格式化导致集群 ID 不统一。解决停掉所有进程删除 NameNode 和 DataNode 的元数据目录默认在 /tmp 下或配置的 dfs.name.dir重新执行hdfs namenode -format再 start-dfs.sh。我一般会建议把这个目录固定到 /data/hadoop 这类非临时路径避免系统重启清空 /tmp 导致元数据丢失。现象 2hadoop fs -put上传文件时卡住不动或超时。原因大多是防火墙没关或 hosts 里没配主机名映射导致 RPC 握手失败。解决先确认ping hostname能通再检查防火墙状态如果都正常看 NameNode 的日志常见的是java.net.ConnectException: Connection refused这时要检查 8020 端口是否被监听。现象 3跑 WordCount 时一直卡在 Running Job 状态。原因内存配置不足或 YARN 的 ResourceManager 没起来。解决先用jps确认 ResourceManager 进程存在如果进程在调低 yarn-site.xml 里yarn.nodemanager.resource.memory-mb的值虚拟机的内存设置 2GB 以上比较稳妥。现象 4格式化后 NameNode 起不来日志提示 JAVA_HOME 找不到。原因hadoop-env.sh 里的 JAVA_HOME 写的是相对路径或写错了版本号。解决用echo $JAVA_HOME确认路径再检查 hadoop-env.sh 里是否真的写进去了source之后重启进程。这个坑看似低级但换机器或换 JDK 版本时特别容易发生。现象 5结果文件 part-r-00000 存在但用 cat 查看中文乱码。原因Hadoop 默认输出用 UTF-8终端编码不一致导致的显示问题。解决用hadoop fs -cat /output/part-r-00000 | iconv -f utf-8 -t gbk转换编码或者直接把输出文件拿到本地用文本编辑器打开。这类问题不属于框架 bug但第一次跑通的人最容易在这上面浪费半小时。6. CloudSim 仿真收尾跑通参数调优再验证一遍你前面的理解6.1 CloudSim 仿真步骤与代码要点CloudSim 是墨尔本大学出的云计算仿真框架资料里给了一道完整的仿真题两个数据中心、每个 10 台物理机5 台双核、5 台四核、总共 100 台虚拟机运算能力 100-500 不等、处理 1000 个云任务负载能力 10000-100000。这道题的参数设定很典型——物理机配置不均、虚拟机能力不同、任务负载差异大正好模拟了真实场景的资源调度难题。资料里的代码结构可以整理成一份可运行的骨架。核心的仿真步骤是六步初始化 CloudSim 包、创建数据中心、创建数据中心代理、创建虚拟机与云任务并传给代理、启动仿真、统计结果。关键代码如下// 第一步初始化 CloudSim 包指定用户数和仿真日历 int num_user 1; Calendar calendar Calendar.getInstance(); boolean trace_flag false; CloudSim.init(num_user, calendar, trace_flag); // 第二步创建数据中心这里会构造物理机的 CPU 核心和 MIPS 能力 Datacenter datacenter1 createDatacenter(Datacenter_1); Datacenter datacenter2 createDatacenter(Datacenter_2); // 第三步创建数据中心代理代理负责把任务分配给具体的虚拟机 DatacenterBroker broker new DatacenterBroker(Broker); // 第四步创建虚拟机列表mips 数组逐一指定每台虚拟机的运算能力 int[] mips new int[100]; // 100 台虚拟机每台能力在 100-500 之间 Random random new Random(); for (int i 0; i mips.length; i) { mips[i] 100 random.nextInt(401); // 100 到 500 的随机值 } vmlist createVM(broker.getId(), mips); // 第五步创建云任务列表每个任务的指令长度在 10000 到 100000 之间 long[] cloudlets new long[1000]; for (int i 0; i cloudlets.length; i) { cloudlets[i] 10000 random.nextInt(90001); // 10000 到 100000 } cloudletList createCloudlet(broker.getId(), cloudlets); // 第六步启动仿真并输出结果 CloudSim.startSimulation(); ListCloudlet newList broker.getCloudletReceivedList(); Log.printLine(CloudSimExercise finished!);这段代码里最需要注意的是createDatacenter里物理机的构建逻辑——每台机器要先创建 Pe处理核心列表双核机器放两个 Pe、四核机器放四个 Pe然后封装成 Host 对象加入数据中心。很多人跑这道题时把 Pe 的 MIPS 设成不同值导致双核和四核机器的总计算能力差距比预期大任务分配结果看起来「不合理」其实是物理机建模不严谨。仿真跑完后看两个指标任务完成时间Cloudlet 的 finish time和虚拟机利用率。如果某些虚拟机负载特别重、某些特别闲就要考虑调整 VmAllocationPolicy 策略CloudSim 内置了 Simple 和 TimeShared 等策略换一种可能结论完全不同。这就是仿真实验的价值——不用真搭集群就能先验证调度策略的差异。6.2 一个验证技巧用 CloudSim 的随机参数反推调度逻辑我每次拿到仿真类的课程设计会先跑一遍「全随机参数」的结果再手动固定几组参数对比。比如把 100 台虚拟机的 MIPS 全部固定成 300、把 1000 个任务的负载固定成 50000跑出来的结果一定和随机分布的版本不一样——通过这种对照才能判断代码逻辑是真的正确处理了任务调度还是只是「随机数据碰巧能跑完」。从那以后我做任何仿真类项目都会养成了一个习惯先固定参数跑一次再随机参数跑一次把两份结果放到同一张表里对比。固定参数能验证系统逻辑的正确性随机参数能验证系统的鲁棒性只跑其中任何一个都可能把 bug 当成正常结果。这份习题集里的 CloudSim 代码虽然只是骨架但配合官方 jar 包足够把「数据中心建模 → 虚拟机分配 → 任务调度 → 结果统计」这一整条链路跑通——你前面关于云计算、并行计算、云存储的所有理解最后都能在这套仿真里得到一次闭环验证。希望帮到你。本文还有配套的精品资源点击获取