企业官网建设流程全解析

简介：《大数据技术原理应用》测试题文档面向高校大数据课程学习者、期末复习与基础面试备考人群，围绕教材核心章节梳理单选、多选两类客观题，并附参考答案，便于快速自测与查漏补缺。压缩包内共1个docx文件，约76KB，文档篇幅58页，题目按章节组织，重点覆盖大数据概述、信息化浪潮、云计算与物联网、Hadoop处理架构，以及HDFS、MapReduce、YARN等组件的功能与特性。内容既有概念辨析，也涉及产业链环节、服务模式和技术要点，适合课堂练习后对照答案复盘，或用于考前集中刷题。已有5638人学习下载，说明其在课程配套练习中具有一定参考价值。读者可借此梳理知识框架、定位易错概念，并形成较完整的章节复习线索。

1. 大数据到底是什么：一场「数据量超过工具能力」的错位

「大数据」这个词被用得太多，以至于很多人以为它是某种具体的新技术。其实它更像一次错位：手机、传感器、交易记录每天产生海量数据，而一台服务器、一张关系表已经接不住了。打个比方，原本一家人的食材用一个冰箱就够，现在变成每天几百车食材送进来——问题不在于食材本身，而在于仓库、搬运、分拣整套体系都得重新设计。大数据技术就是这套重新设计出来的体系：怎么存得下、怎么算得动、怎么在机器坏了的时候不出事。这份按六个章节组织的自测题库，恰好把这条链路拆成了一道道能验证对错的选择题，从浪潮背景一直排到云数据库。

2. 大数据技术栈在解决什么：存得下、算得动、还得不出事

2.1 三次信息化浪潮：被解决的问题和被制造出来的问题

理解大数据，绕不开一个背景：信息化浪潮已经走过三轮，每一轮解决的矛盾和制造的新矛盾都不一样。第一次浪潮以个人计算机为代表，核心解决的是信息处理——把纸上的东西搬进机器里算；第二次浪潮以互联网为代表，核心解决的是信息传输——把算好的东西送出去；到了第三次浪潮，物联网、云计算、大数据一起登场，要面对的是前两轮攒下来的副产品：信息爆炸。

这个顺序值得停下来想一想。前两轮浪潮其实一直在「降低数据产生的门槛」：个人计算机让录入变便宜，互联网让分享变便宜，传感器和移动设备让自动采集变便宜。门槛越低，数据量越滚越大，最后就成了一个和原来完全不同的量级。原来「先存下来慢慢算」的套路，在这个量级下会直接卡死——存储装不下，计算跑不完，机器一坏数据就没了。

所以第三次浪潮里出现的那几项技术不是凭空造出来的，它们是被同一个问题逼出来的：数据量级跨过某条线之后，原来的单机体系整体失效。这段背景在题库里体现得很直接，第一道题考的就是「浪潮解决什么问题」，而它同时也是后面所有概念的地基——不知道问题从哪来，就分不清 HDFS 为什么要切成块、HBase 为什么要放弃表连接。

2.2 存储与管理：大数据技术栈的第一层地基

大数据技术要干的事，拆开来其实是三层。第一层是数据存储和管理，用分布式文件系统、数据仓库、关系数据库等手段，把结构化、半结构化、非结构化的海量数据安稳地放进去；第二层是处理和分析，用分布式并行编程模型配合机器学习和数据挖掘算法，把数据变成结论；第三层是隐私与安全，构建数据保护体系，防止数据被滥用。

这三层是有顺序的。没有存储，处理无从谈起；没有处理，存储只是一堆占地方的字节。很多人初学时会跳过第一层直接去看算法，结果在实际场景里频繁碰壁——因为绝大多数失败不是因为算法不够聪明，而是因为数据压根没能稳定落盘、没能被高效读取。

打个比方，第一层是建粮仓，第二层是建面粉厂。粮仓没建好，面粉厂再先进也只能空转。而「分布式」这三个字，正是第一层最关键的特征：它不追求单台机器多强，而是把成千上万台普通机器拼成一个集群，用数量换容量和吞吐。这也是为什么大数据技术反复强调「兼容廉价硬件」——如果非要靠昂贵的小型机，这套体系就没有存在意义了。

顺带把云计算的三种服务模式说清楚，因为这里是初学者最容易混淆的地方：SaaS是软件即服务，直接给你能用的成品；PaaS是平台即服务，给你的是操作系统和围绕特定应用的必需服务，让你在上面部署自己的东西；IaaS是基础设施即服务，把计算资源和存储资源作为服务出租。三层从「成品」到「半成品」再到「原材料」，抽象程度依次下降，用户要自己干的活依次增多。至于承载这一切的云计算数据中心，它是云计算的重要载体，为各种平台和应用提供运行支撑环境，而不是企业内部随便摆的一台中心服务器。

2.3 计算模式与产业边界：流计算、批处理、图计算分别在干什么

数据存进去之后，接下来是算。大数据的计算模式不是一种，而是几种并存的，各自对应不同的数据形态和时效要求。

批处理面对的是已经落盘的、大规模的历史数据，特点是一次性处理很大的量，允许等待。它适合做统计报表、离线分析这类「结果晚一点没关系」的任务。流计算面对的是源源不断进来的数据流，要求边到边算，典型场景是实时监控和实时告警。图计算面对的则是数据之间高度关联的结构，处理的是点和边的关系，而不是一行一行的记录。

这三种模式经常被拿来对比，但它们的区别不在于谁更先进，而在于数据是「存量」还是「增量」、是「独立记录」还是「互相关联」。存量的、互不相关的记录交给批处理最划算；增量的、要求立刻出结果的交给流计算；关系复杂的交给图计算。搞混这一点，就会出现「用批处理去做实时告警」这种既慢又费资源的翻车方案。

再往外看一层，还有一个概念需要厘清：大数据产业。它指的是一切与支撑大数据组织管理和价值发现相关的企业经济活动的集合。这句话的关键在「支撑」和「组织管理」上——直接提供智能交通、智慧医疗这类行业应用的企业，属于应用方；提供数据分享平台、数据分析平台、数据租售平台的企业，属于服务方；提供分布式计算、数据挖掘、统计分析等服务的企业，属于技术方。它们共同构成了产业链，而产业链通常被拆成数据源层、数据分析层、数据应用层等环节。

最后说说发展历程。大数据的演进一般被划为萌芽期、大规模应用期和成熟期三个阶段，并不存在什么「迷茫期」——这个词是干扰项，但它挺形象地描述了不少人的学习状态：概念听了一堆，却串不成线。串成线的关键，是把「浪潮→存储→计算→产业」这条因果链接上，而不是背名词。

3. Hadoop 与 HDFS：一个管仓库、一个管搬运的分工体系

3.1 Hadoop 的两个核心设计：一个负责存，一个负责算

如果只能记住 Hadoop 的一件事，那就是它的核心设计只有两条：为海量数据提供存储的 HDFS，和对数据进行计算的 MapReduce。其他组件都是围绕这两件事长出来的配套。

这套设计要解决的问题，和前面说的「单机失效」是同一个问题。既然一台机器存不下、算不完，那就把文件切开放到很多台机器上（HDFS 干的活），再把计算任务也拆开送到数据所在的机器上去算（MapReduce 干的活）。这里有个很关键的思想：把计算搬到数据旁边，而不是把数据搬到计算旁边。数据动辄以 TB 计，搬数据的成本远高于搬一段几百 KB 的程序。

Hadoop 之所以能流行，靠的是一组很朴素的特性和对比出来的优势：高可靠性、高容错性、高可扩展性、成本低、支持多种编程语言、能运行在 Linux 平台上。它为用户提供了系统底层细节透明的分布式基础架构，具有良好的跨平台特性，可以部署在廉价的计算机集群中，也因此长期被视为行业里大数据处理的事实标准。它的整体性能主要受 CPU 性能、内存、网络和存储容量这几个因素共同制约——注意是「共同」，任何一项成为短板，整体都会被拖住。

提示：Hadoop 的版本差异是必考点，也是必错的点。1.0 的组件是 HDFS 和 MapReduce；2.0 在两者之外增加了 YARN，并把原来 MapReduce 里的 JobTracker、TaskTracker 换成 ResourceManager、NodeManager。看到 YARN 就该意识到这是 2.0 的语境。

3.2 NameNode 与 DataNode：一个记目录，一个放实物

HDFS 采用的是主从结构模型，集群里的节点分成主节点和从节点两类。这个结构很像一家连锁仓库：有一个总调度室专门记「什么东西放在哪个仓库的哪个货架」，而实际堆放货物的是分布在各处的仓库。

总调度室就是名称节点 NameNode，它负责存储元数据——文件系统树、目录和文件的信息。仓库就是数据节点 DataNode，它负责存储被拆分的数据块，根据客户端或名称节点的调度进行数据的存储和检索，并定期向名称节点汇报自己所存储的块的列表。

元数据具体放在两个地方：FsImage和EditLog。FsImage 用于维护文件系统树以及树中所有文件和文件夹的元数据，包含所有目录和文件 inode 的序列化形式；但它不记录每个块具体存储在哪个数据节点上——这个映射关系是 DataNode 启动后上报、由 NameNode 在内存中维护的。EditLog 则记录的是各种更新操作。两者配合，NameNode 重启时才能把状态还原出来。

还有一个常被误解的角色：SecondaryNameNode。它不是热备，也不是第二名称节点接管者，它的作用是帮助 NameNode 收集文件系统运行的状态信息，保存元数据的备份，从而减少名称节点重启的时间。它通过 HTTP GET 的方式从 NameNode 获取 FsImage 和 EditLog 并下载到本地目录，一般是运行在单台机器上的。

只设一个名称节点，简化了系统设计，但也带来了四个明显的局限：命名空间的限制、性能的瓶颈、隔离问题、集群的可用性。这四条正是后续一系列改进方案的出发点。

3.3 块与副本：为什么要故意把文件切碎存三份

HDFS 把文件切成固定大小的块来存储。早期默认块大小是 64MB，后来普遍调大到 128MB。这个「块」是抽象出来的概念，带来的好处很明确：支持大规模文件存储、简化系统设计、适合数据备份。它让一个超大的文件可以均匀铺到很多台机器上，也让存储管理有了统一的计量单位。

块只是第一步，真正保证不丢数据的是多副本。默认情况下每块存三份，分散在不同节点上。好处有三个：加快数据传输速度（可以从最近的副本读）、容易检查数据错误（副本之间可以互相校验）、保证数据可靠性（坏一份还有两份）。HDFS 也因此设计了相应的容错机制，覆盖数据节点出错、数据出错、名称节点出错这几种情况。

下面这段代码把「切块 + 副本」的存储账算清楚，顺便解释为什么小文件是 HDFS 的痛点：

# 用最小模型估算 HDFS 的存储占用 BLOCK_SIZE = 128 * 1024 * 1024 # 单个块大小，128MB（早期版本为 64MB） REPLICATION = 3 # 默认副本数，一份数据存三份 NAMENODE_MEM_PER_BLOCK = 150 # 元数据占用的近似字节数（仅示意） def estimate(file_size, block_size=BLOCK_SIZE, rep=REPLICATION): # 向上取整得到块数量：一个文件至少占 1 个块 blocks = max(1, -(-file_size // block_size)) # 实际磁盘占用 = 块数 × 块大小 × 副本数（最后一块也按整块计） disk = blocks * block_size * rep meta = blocks * NAMENODE_MEM_PER_BLOCK return blocks, disk, meta big, disk_big, meta_big = estimate(2 * 1024 * 1024 * 1024) # 一个 2GB 的大文件 small, disk_small, meta_small = estimate(10 * 1024) # 一万个 10KB 的小文件 print(big, disk_big, meta_big) # 16 块，磁盘约 6GB，元数据很小 print(small, disk_small, meta_small) # 每个文件各占 1 块，磁盘被放大上千倍

这段逻辑说明了两个参数的含义。BLOCK_SIZE决定了切块粒度，块越大，块数量越少，元数据压力越小，但单块传输的粒度也越粗；REPLICATION决定了容错能力和存储成本的平衡，三份意味着实际占用是原始数据的三倍。函数里的max(1, ...)是关键：无论文件多小，都至少占一个块，最后一块不满也按整块计。

于是小文件的问题就暴露出来了：一万个 10KB 的文件，逻辑上只有约 100MB，实际却要占掉一万个整块再乘三份，磁盘被严重放大，而 NameNode 还要为每一个块维护元数据，内存压力陡增。这就是为什么 HDFS无法高效存储大量小文件。它的另外两个经典局限是不适合低延迟数据访问（面向批量吞吐而非随机读）和不支持多用户写入及任意修改文件。加上前面说的主从结构，这几条合起来就是 HDFS 的适用边界。

4. HBase 与 NoSQL：关系数据库为什么在数据暴涨后「让位」

4.1 关系数据库在数据量剧增后卡在哪

关系数据库流行了很多年，有完善的关系代数理论作基础，有严格的标准，还手握两个引以为傲的特性：完善的事务机制和高效的查询机制。事务的 ACID 四性——原子性、一致性、隔离性、持久性——保证了数据不会算到一半就变成半截状态；索引机制则让复杂查询跑得飞快。

问题在于，这两个王牌到了 Web 时代变成了鸡肋。海量数据的管理需求它接不住，高并发需求它接不住，高可扩展性和高可用性它同样接不住。更具体地说，Web 系统通常不要求严格的数据库事务，不要求严格的读写实时性，也很少包含大量复杂的 SQL 查询——也就是说，它花了大力气提供的能力，用户根本用不上，而用户真正需要的横向扩展能力，它偏偏给不了。

横向扩展恰恰是 NoSQL 的强项。RDBMS 需要预先定义数据库模式，严格遵守数据定义，结构一变往往要停机维护，空列还白占存储空间；NoSQL 一般不存在固定的数据库模式，可以自由灵活地定义并存储各种不同类型的数据，加机器就能扩容。代价是它没有统一的理论基础，很多产品没有面向复杂查询的索引，复杂查询性能不高。

至于 HBase 这类系统为什么必须存在，原因可以归结成四条：Hadoop 能很好地解决大规模数据的离线批量处理，但受限于 MapReduce 的高延迟机制，满足不了实时处理需求；HDFS 面向批量访问模式，不是随机访问模式；传统通用关系型数据库在数据规模剧增时，扩展性和性能都会崩；而且关系数据库在数据结构变化时需要停机维护，空列浪费存储空间。这四条合起来，就是 HBase 的生存空间。

4.2 HBase 的四维坐标与三层寻址

HBase 采用表来组织数据，表由行和列组成，列被划分为若干个列族。每个表由若干行组成，每行由行键标识；列族里的数据通过列限定符定位；每个单元格保存着同一份数据的多个版本，这些版本用时间戳索引。行键、列族、列限定符、时间戳这四项合起来，就是一个单元格的「四维坐标」——要定位一格数据，四个维度缺一不可。

这个模型和关系数据库的差别很大。HBase 采用了更简单的数据模型，把数据存储为未经解释的字符串，操作上不存在复杂的表与表之间的关系，在设计上就刻意避免了连接。它只有针对行键的一个索引，所以访问一张表只有三种可行方式：通过单个行键访问、通过一个行键的区间访问、全表扫描。「通过时间戳直接访问」是行不通的——时间戳是用来区分同一单元格的多个版本的，不是入口。

由于只有一个索引，HBase 把「怎么快速找到数据」这件事交给了三层寻址结构：Zookeeper 文件记录 -ROOT- 表的位置信息；-ROOT- 表记录 .META. 表的 Region 位置信息；.META. 表保存了所有用户数据表的 Region 位置信息。这个链条有个重要特点：-ROOT- 表只能有一个 Region，不能有多个；而 .META. 表的全部 Region 会被保存在内存中，以加快访问速度。为了进一步加速，客户端还会缓存位置信息，同时必须解决缓存失效的问题。

在物理实现上，HBase 由三个主要功能组件构成：链接到每个客户端的库函数、一个Master 主服务器、许多个Region 服务器。Master 负责表和 Region 的管理工作：在 Region 分裂或合并后重新调整 Region 的分布，对失效的 Region 服务器上的 Region 进行迁移，管理用户对表的增删改查操作，并负责不同 Region 服务器之间的负载均衡。Region 服务器这边，每个服务器都有自己的HLog 文件，用于保证分布式环境下出错时的数据恢复；每次刷写都会生成一个新的 StoreFile，数量太多会影响查找速度，所以只有数量达到阈值才启动合并，而合并本身是比较耗费资源的操作。

访问接口也不止一种：Native Java API 适合 MapReduce 作业并行批处理表数据，HBase Shell 适合日常管理，Thrift Gateway 和 REST Gateway 适合其他异构系统在线访问，而 Pig 则适合做数据统计。性能监视方面，自带的状态页面以及一些集群监控和指标系统都能接进来。

4.3 NoSQL 的四种类型与 CAP、BASE 三大基石

NoSQL 不是一种数据库，而是一类数据库的统称。它们的共同特点是灵活的可扩展性、灵活的数据模型、与云计算紧密融合，而不是「存储规模有限」。

四种类型没有优劣，只有匹配度。社交网络、模式识别、依赖分析、推荐系统、路径寻找这类问题天然适合图数据库；日志采集和计数类场景用键值型更划算；需要灵活字段的业务用文档型更顺手；而数据量极大、写入极密集、查询模式简单的场景，列族型就是标准答案。

撑起整个 NoSQL 世界的是三大基石：CAP、最终一致性、BASE。CAP 说的是分布式系统里一致性、可用性、分区容忍性三者不可兼得，只能选两个重点：CA 强调一致性和可用性、放弃分区容忍性；CP 强调一致性和分区容忍性、放弃可用性；AP 强调可用性和分区容忍性、放弃一致性。这里的「一致性」是指任何一个读操作总是能读到之前完成的写操作的结果，「可用性」是指快速获取数据，「分区容忍性」是指当系统中一部分节点无法和其他节点通信时，分离出来的系统仍能正常运行。

BASE 则是这套取舍在工程上的落法：基本可用、软状态、最终一致。它承认「强一致」的代价太高，转而追求「过一会儿一定对上」。理解了这一层，再看很多 NoSQL 产品的设计选择就不会觉得奇怪——它们宁可在某一瞬间返回旧数据，也不愿意为了等一个全局一致而把整个系统锁住。

5. 常见易混概念：几组看起来像、其实不是一回事的东西

5.1 易混点一：SecondaryNameNode 是 NameNode 的热备份

为什么混：名字里带了个 Secondary，直觉上就会理解成「第二台，主备关系」。加上它确实会保存元数据备份，更容易让人以为 NameNode 一挂它就能顶上。

怎么区分：看它到底在做什么。它做的是周期性合并 FsImage 和 EditLog、帮助 NameNode 收集文件系统运行状态信息、缩短名称节点重启时间，本质上是一个「助手」。它不做实时接管，也不承担客户端请求的响应。而且要记住一个反直觉的事实：它一般是运行在单台机器上的，不是并行跑在多台机器上。判断这类问题有个简单办法——问一句「它能不能独自响应写请求」，答案是不能，那就不是热备。

5.2 易混点二：HBase 的 HLog 和 HDFS 的副本是一回事

为什么混：两者都跟「防止数据丢失」有关，都出现了「多一份」的意思，容易糊成一团。

怎么区分：看防的是什么错、防在哪一层。HDFS 的副本防的是节点或磁盘坏了导致块丢失，做法是把同一块数据放到不同机器上，属于存储层的冗余。HBase 的 HLog 防的是写入过程中进程崩溃导致内存里的数据还没落盘就没了，做法是先把写操作顺序记到日志文件里，属于写入路径上的日志。每个 Region 服务器配一个 HLog 文件，Zookeeper 会实时监测各 Region 服务器的状态，一旦发现故障，Master 会先处理该服务器上遗留的 HLog 文件，把其中的操作重放回来。简单说：副本是「多存一份成品」，HLog 是「先记一笔草稿」。

5.3 易混点三：CAP 是「三个都要，只是性能差一点」

为什么混：很多系统宣传自己「同时满足一致性和可用性」，听多了就以为 CAP 是一个可以全选的选项，只是代价高低的问题。

怎么区分：CAP 是取舍关系，不是性能调优关系。当网络分区发生时，你要么选择继续响应请求（放弃一致性），要么选择拒绝服务以保证数据一致（放弃可用性），中间没有第三条路。所谓「三个都要」在分区真的发生时是不成立的。工程上的做法是先选好站位，再用最终一致性去补体验：先保证系统活着、能响应，再让数据在很短的时间窗口内对齐。看到一款产品声称三样全占，先问它在网络分区期间的行为是什么，答案往往就露馅了。

5.4 易混点四：Hadoop 1.0 和 2.0 只是版本号不同

为什么混：版本升级听起来像是修修补补，无非是性能好一点、bug 少一点。

怎么区分：看组件构成。Hadoop 1.0 的组件只有 HDFS 和 MapReduce，资源调度和计算任务是绑在一起的；Hadoop 2.0 增加了 YARN，把资源管理这件事单独抽出来，同时把 JobTracker、TaskTracker 换成了 ResourceManager、NodeManager。这不是优化，是架构拆分——原来「一个人又管派活又管干活」，现在「专门有人管派活」。所以凡是提到 ResourceManager 和 NodeManager 的题，语境一定是 2.0；凡是提到 JobTracker 协调计算任务、TaskTracker 执行指派任务的，语境是 1.0。另外注意，DataNode、SecondaryNameNode 这些角色在两个版本里都存在，不能拿它们来判断版本。

6. 什么时候该用这套知识：一份判断清单与三条边界

学完这些概念，最实际的问题不是「能不能背下来」，而是「拿到一个场景，该怎么选」。下面这张表可以当作第一道筛子：

再往下是三条边界，比表格更值得记住。

第一条：数据量没到那个量级，别硬上分布式。分布式体系天生带着调度、通信、一致性维护的额外开销，几百 MB 的数据放进一个集群里跑，多半比单机慢，还多了一堆运维工作。判断标准不是「大数据这个词很热」，而是「单机是否真的接不住」。很多项目早期就上集群，最后发现真正的问题是索引没建好。

第二条：需要强事务的场景，别指望 NoSQL 救场。涉及资金、库存、订单状态这类必须原子完成的操作，NoSQL 的最终一致性意味着中间会有一段时间的数据不一致，业务上很难接受。CAP 里选择 AP 是有代价的，代价就在这里。反过来，如果业务本身对短暂不一致不敏感——比如点赞数、浏览计数——那强一致就是白花钱。

第三条：别用 OLTP 的思路去设计分析型系统。分析型任务的查询模式千变万化，往往要全表扫描、要大范围聚合，这跟 HBase 那种「按行键取一行」的模型完全不搭。它的单行键索引在这种负载下几乎帮不上忙，最后只能退化成全表扫描。这类需求应该交给批处理体系，而不是硬塞进一个擅长随机读写的库。

我自己刚开始接触这块时就翻过车：拿到一个「要存几千万条记录」的需求，第一反应是找个分布式数据库装上，结果数据规模其实一台普通服务器加好索引就能扛，反倒是那套集群的运维成本把整个项目拖了两个月。从那以后我每次做技术选型，都会强制走一遍「数据量到底多大、查询模式到底是什么、能不能接受短暂不一致」这三个问题，答不上来就先不动手。

这份按六章组织的自测题库之所以有用，就在于它把上面这些判断点都变成了可以逐条核对的问题——从浪潮背景、Hadoop 架构、HDFS 的块与副本，到 HBase 的四维坐标、NoSQL 的类型与 CAP，再到云数据库，每一道题背后都是一个具体的边界。拿它当自测清单过一遍，比反复看概念解释更能暴露自己哪一块是「以为懂了、其实混着」。需要的朋友可以取来对着做一遍，错的那几道，往往就是你真正该补的地方。希望帮到你。

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