大数据技术试题及答案

大数据技术试题及答案一、单项选择题（共10题，每题1分，共10分）以下选项中，不属于大数据经典4V核心特性的是A.数据体量巨大，可达到PB甚至EB级别B.数据生成和处理的速度要求快，需满足高吞吐场景C.数据的价值密度极高，单位数据中蕴含的直接价值远高于传统小数据D.数据类型多样，包含结构化、半结构化、非结构化等多种格式答案：C解析：大数据的4V特性分别是体量巨大（Volume）、处理速度快（Velocity）、类型多样（Variety）、价值密度低但整体价值高（Value），C选项表述的价值密度极高和知识点完全相反，其余三个选项都是4V特性的准确描述。目前主流稳定版本的HDFS分布式文件系统，默认的数据块大小为A.32MBB.64MBC.128MBD.256MB答案：C解析：HDFS设计大分块机制是为了减少寻址开销、提升大文件存储效率，当前主流版本默认块大小为128MB，早期初代版本默认块为64MB，32MB和256MB都不是通用版本的默认配置。MapReduce编程模型中，Shuffle阶段的核心作用是A.把Map任务的输出数据按照指定规则进行分区、排序、合并后传递给Reduce任务B.负责提交整个MapReduce作业到集群的资源调度节点C.实现分布式集群节点之间的心跳状态检测D.对Reduce任务的最终输出结果进行持久化存储答案：A解析：Shuffle是MapReduce连接Map和Reduce阶段的核心流程，负责数据的分区排序等操作，B选项是作业提交客户端的功能，C选项是HDFSNameNode的功能，D选项是Reduce任务执行完成后的后续操作，都不属于Shuffle阶段的作用。以下大数据生态中的组件，属于面向列存储的分布式NoSQL数据库的是A.HBaseB.MySQLC.HiveD.PostgreSQL答案：A解析：HBase是典型的分布式面向列存储的NoSQL数据库，适合海量非结构化、半结构化数据的实时随机读写场景，MySQL和PostgreSQL是传统关系型数据库，Hive是基于HDFS的数据仓库工具，本身不提供实时读写的数据库能力。Spark大数据计算框架的核心基础抽象概念是A.关系型数据库表B.弹性分布式数据集（RDD）C.键值对存储模型D.流数据事件窗口答案：B解析：RDD全称为弹性分布式数据集，是Spark框架提出的核心基础抽象，具备不可变、可分区、支持并行操作的特性，其余选项都不是Spark独有的核心基础抽象。大数据生态中，专门负责集群资源统一管理和调度的组件是A.FlumeB.KafkaC.YARND.Sqoop答案：C解析：YARN是Hadoop生态的资源调度核心组件，负责统一分配集群的CPU、内存等计算资源，Flume是日志采集组件，Kafka是消息队列组件，Sqoop是关系型数据库和HDFS之间的数据迁移组件。大数据预处理环节中，数据清洗操作的核心目标是A.将不同来源的数据源合并为统一的数据集B.剔除数据集中的缺失值、重复值、异常值等脏数据，提升数据质量C.将原始数据转换为适合后续计算模型输入的格式D.压缩数据集规模，在保留核心信息的前提下减少后续计算开销答案：B解析：数据清洗的核心目标就是处理脏数据提升质量，A选项是数据集成的目标，C选项是数据变换的目标，D选项是数据归约的目标。以下场景中，最适合使用实时流计算技术处理的是A.统计电商平台过去一个月的全站用户消费总额报表B.离线分析全站近三年的用户行为数据生成用户画像C.实时监测金融交易流水的异常行为，及时拦截欺诈交易D.批量归档全年的历史日志数据到冷存储介质答案：C解析：流计算适合低延迟的实时数据处理场景，金融交易实时风控符合该特征，其余三个场景都属于离线批量计算的适用场景。数据仓库分层架构中，ODS操作数据层的核心作用是A.存储经过高度汇总统计的最终业务报表数据B.直接对接外部数据源，几乎不做加工地同步原始全量数据C.存储经过清洗转换后的统一标准化中间层数据D.专门存储面向特定业务主题建模生成的宽表数据答案：B解析：ODS层是数据仓库的最底层，作用是留存原始同步过来的全量数据，不对数据做深度加工，方便后续追溯原始数据来源，其余三个选项分别对应应用层、DWD明细层、DWS汇总层的功能。大数据场景下数据脱敏操作的核心目的是A.提升数据计算的运行速度B.避免敏感个人信息在数据流转、使用过程中泄露，保障数据安全C.提升数据的存储压缩比D.让数据格式统一适配所有大数据组件的输入要求答案：B解析：数据脱敏是通过替换、掩码等方式隐藏身份证、手机号等敏感信息，核心作用是保障数据使用过程中的隐私安全，其余选项都不是数据脱敏的设计目标。二、多项选择题（共10题，每题2分，共20分）以下选项中，属于主流大数据分布式计算框架的有A.MapReduceB.SparkC.传统单机版MySQLD.Flink答案：ABD解析：MapReduce、Spark、Flink都是业内广泛使用的分布式大数据计算框架，C选项的传统单机版MySQL是单节点关系型数据库，不属于分布式计算框架，是错误选项。HDFS分布式文件系统的核心守护进程包括A.NameNodeB.DataNodeC.SecondaryNameNodeD.关系型数据库代理进程答案：ABC解析：HDFS的核心进程中，NameNode负责元数据管理，DataNode负责实际存储块数据，SecondaryNameNode负责辅助NameNode合并编辑日志生成镜像文件，D选项的关系型数据库代理进程不属于HDFS的原生组件。大数据数据预处理阶段的常见核心操作步骤包括A.数据清洗B.数据集成C.数据变换D.数据归约答案：ABCD解析：以上四个选项都是大数据预处理的标准流程，数据清洗处理脏数据，数据集成合并多源数据，数据变换转换数据格式，数据归约精简数据集规模，全部属于核心操作。Spark框架支持的运行部署模式包括A.本地单机运行模式B.Standalone独立集群运行模式C.YARN集群资源调度运行模式D.完全离线无网络的单机软盘运行模式答案：ABC解析：Spark原生支持本地模式、Standalone独立集群模式、YARN调度模式、Kubernetes调度模式等多种部署模式，D选项的软盘运行模式完全不符合Spark的运行依赖要求，是无效的错误选项。以下属于典型的非结构化数据的有A.平台用户上传的短视频文件B.用户在社交平台发布的纯文本评论C.数据库中存储的用户手机号字段D.城市道路监控抓拍的图片文件答案：ABD解析：非结构化数据是没有固定预定义数据结构的文件类数据，短视频、纯文本评论、监控图片都属于非结构化数据，C选项数据库中固定字段的用户手机号属于结构化数据。以下关于Kafka消息队列组件的描述，正确的有A.是分布式的高吞吐量消息发布订阅系统B.可以作为大数据采集环节的缓冲层，削峰填谷避免上游日志流量直接打垮后续计算节点C.不支持数据持久化，收到消息后必须立刻消费否则会永久丢失D.采用分区副本的机制保障消息存储的高可用答案：ABD解析：Kafka支持将消息持久化到磁盘，可以自定义消息保留时长，不会出现未消费立刻丢失的情况，其余三个选项都是Kafka的正确特性描述。大数据数仓分层架构设计能够带来的优势包括A.每一层职责清晰，降低数据开发的重复工作量B.数据血缘链路可追溯，出现问题可以快速定位异常发生的环节C.完全消除所有数据计算环节的资源开销D.不同层之间解耦，某一层的逻辑变更不会直接影响其他层的正常运行答案：ABD解析：数仓分层设计不可能完全消除计算开销，反而会因为多了中间层计算增加少量的资源消耗，C选项的描述是完全错误的，其余三个选项都是分层架构的核心优势。大数据场景下常见的资源调度策略包括A.FIFO先进先出调度策略B.公平调度策略C.容量调度策略D.随机抽签调度策略答案：ABC解析：YARN等调度框架原生支持FIFO、公平调度、容量调度三种主流调度策略，随机抽签调度完全没有公平性和资源利用率保障，不属于大数据集群的合法调度策略。以下属于大数据治理体系核心覆盖内容的有A.数据元数据管理B.数据质量校验规则制定C.数据权限分级管控D.完全消除所有数据的存储需求答案：ABC解析：大数据治理不可能消除数据存储需求，反而要配合存储生命周期管理合理规划存储资源，D选项描述错误，其余三个选项都是数据治理的核心组成部分。Flink流计算框架具备的核心特性包括A.支持精确一次（Exactly-Once）的数据一致性语义保障B.原生支持事件时间语义，能够处理乱序的流数据C.支持窗口计算机制，可自定义不同时长的统计窗口D.完全无法支持批处理场景，只能处理流数据答案：ABC解析：当前Flink已经实现了批流一体的能力，既可以处理流数据也可以处理批量离线数据，D选项的描述错误，其余三个选项都是Flink的核心优势特性。三、判断题（共10题，每题1分，共10分）HDFS分布式文件系统是专门为高吞吐大文件存储场景设计的，不适合低延迟的大量小文件随机访问场景。答案：正确解析：HDFS的设计目标是支持TB、PB级别的大文件高吞吐读写，大量小文件会占用NameNode的大量元数据内存，随机访问需要频繁寻址会大幅降低性能，因此不适合低延迟小文件访问场景。RDD弹性分布式数据集具备可修改的特性，开发者可以直接修改RDD中存储的任意元素数据。答案：错误解析：RDD的核心特性之一是不可变性，一旦生成就不允许被修改，所有对RDD的操作都只能生成新的RDD，这种设计可以降低分布式并行计算的一致性复杂度。Hive数据仓库工具可以将编写的类SQL语句自动转换为MapReduce、Spark等分布式计算任务运行，降低大数据开发的学习门槛。答案：正确解析：Hive的核心定位是让熟悉SQL的开发者无需编写复杂的分布式计算代码，通过类SQL语句自动转译生成分布式计算任务，大幅降低大数据离线开发的成本。大数据场景下的价值密度极低，意味着海量的原始数据完全没有任何可挖掘的价值。答案：错误解析：大数据的价值密度低指的是单位体积的原始数据中有效信息占比不高，但是当数据体量足够大时，整体累计的总价值非常高，并非完全没有挖掘价值。YARN调度框架中，ResourceManager是整个集群的全局资源管理者，负责接收客户端的作业提交请求并分配资源。答案：正确解析：YARN架构中ResourceManager是全局的核心管理节点，负责整个集群的资源分配和作业调度，NodeManager是每个节点上的代理进程，负责管理本机的计算资源。数据可视化的核心作用是把大数据分析的结果转换为人类更容易理解的图表、大屏等形式，降低数据结果的解读门槛。答案：正确解析：复杂的大数据分析结果直接以表格形式呈现很难被业务方快速理解，数据可视化通过直观的图形化展示方式，可以大幅提升数据结果的信息传递效率。分布式系统CAP理论中，C代表一致性、A代表可用性、P代表分区容错性，分布式系统可以同时满足C、A、P三个全部特性。答案：错误解析：CAP理论已经证明，分布式系统在出现网络分区的场景下，无法同时保证一致性和可用性，只能在CP和AP之间做权衡，不可能同时满足三个特性。Sqoop组件的核心功能是实现传统关系型数据库和大数据生态分布式存储系统之间的批量数据迁移。答案：正确解析：Sqoop专门针对关系型数据库和HDFS、Hive、HBase等大数据组件之间的双向数据迁移做了优化，是传统数据库对接大数据平台的常用工具。流计算处理的所有数据都是有界数据集，数据的总量是固定的，处理完成后任务就会自动结束退出。答案：错误解析：流计算处理的是无界的持续生成的数据流，理论上数据会源源不断地流入系统，任务会一直保持运行状态持续处理新到的数据，批计算才是处理有界固定数据集的。大数据平台的权限管控机制只需要管控用户的读取数据权限，完全不需要管控用户提交计算任务的资源配额权限。答案：错误解析：如果不对用户提交计算任务的资源配额做管控，个别用户提交的超大计算任务会占用全部集群资源，导致其他正常业务的任务无法运行，因此资源配额管控是权限体系的重要组成部分。四、简答题（共5题，每题6分，共30分）简述大数据技术栈从下到上的核心分层架构。答案：第一，数据采集层，负责对接分散在各个业务系统的多源数据，包括日志采集、数据库增量/全量采集、网络爬虫采集等不同的采集工具，完成各类异构数据的汇聚；第二，分布式存储层，负责将采集到的海量数据持久化存储，包含分布式文件系统、分布式NoSQL数据库等不同的存储组件，适配不同类型数据的存储需求；第三，资源调度层，负责统一管理整个集群的CPU、内存、磁盘等硬件资源，为上层的计算任务分配资源，保障多任务并行运行时的资源公平分配；第四，分布式计算层，包含批计算、流计算、交互式计算等不同类型的计算引擎，支持不同时效要求的数据处理逻辑开发；第五，数据治理与中台层，负责统一管控全链路数据的元数据、数据质量、数据权限，搭建统一的公共数据模型，避免重复开发；第六，数据应用层，面向最终业务场景输出BI报表、用户画像、推荐系统、风控系统等具体的业务应用，实现大数据的业务价值落地。解析：该架构是业内大数据平台的通用分层标准，每一层都有明确的职责边界，层与层之间通过标准化的接口交互，方便后续的组件迭代升级，不会因为某一个组件的替换影响全链路的正常运行。简述HBase分布式数据库的核心适用场景。答案：第一，超高并发的海量数据实时随机读写场景，比如亿级用户规模的平台，需要在毫秒级别查询到指定用户的历史行为记录，HBase的低延迟特性可以很好地满足需求；第二，高吞吐的大规模批量数据写入场景，比如每秒数万条的监控数据、日志数据实时入库，HBase的分布式架构可以横向扩展节点承载超高的写入吞吐量；第三，支持超大规模稀疏表存储的场景，当数据表的列数高达数万甚至数十万，绝大多数行的列值都是空值的稀疏场景下，HBase面向列的存储特性可以极大节省存储空间，避免传统关系型数据库存储稀疏表带来的大量空值空间浪费；第四，需要支持动态灵活扩展列的场景，业务迭代过程中需要频繁新增数据列，无需提前做复杂的表结构变更操作，HBase可以原生支持动态列的扩展。解析：HBase的特性完全针对传统关系型数据库难以支撑的海量非结构化数据场景做优化，和传统关系型数据库形成能力互补，在社交平台、物联网监控、实时风控等领域被广泛使用。简述大数据开发过程中数据血缘的核心作用。答案：第一，支持数据问题快速溯源，当业务报表出现数据错误的时候，可以顺着血缘链路反向追溯数据从采集、加工到最终输出的全链路流转过程，快速定位异常发生的具体环节，大幅缩短问题排查时间；第二，支持变更影响范围评估，当开发者需要修改某一张中间表的加工逻辑时，可以顺着血缘链路正向梳理所有依赖该表的下游任务、下游报表，避免出现逻辑变更后未通知到下游导致的业务故障；第三，支撑数据资产的价值盘点，通过血缘关系可以清晰统计每一个数据节点的下游依赖数量，判断该数据节点的实际业务价值，清理没有任何下游依赖的冗余无效任务，减少不必要的计算资源浪费；第四，满足合规审计要求，在数据隐私相关的合规监管场景下，通过血缘链路可以清晰展示敏感数据的全流转路径，证明数据的使用完全符合合规要求。解析：数据血缘是大数据治理体系的核心基础能力，完整的血缘链路是实现高质量数据运维、高效数据迭代的必要前提。简述批计算和流计算两种大数据处理模式的核心差异。答案：第一，处理的数据集特性不同，批计算处理的是有界数据集，所有待处理的数据是预先全部存在的，数据总量固定，流计算处理的是无界数据集，数据持续不断地流入系统，没有明确的结束点；第二，处理的延迟要求不同，批计算对处理延迟没有高要求，通常处理耗时可以是分钟级、小时级甚至天级，流计算要求低延迟，通常需要在秒级甚至毫秒级的时间内完成新到数据的处理并输出结果；第三，任务运行生命周期不同，批计算任务处理完所有数据之后就会自动结束释放集群资源，流计算任务需要长期持续运行，实时等待新数据流入，一般不会主动退出；第四，容错处理机制不同，批计算的容错机制相对简单，任务出错后直接重新跑一遍全部数据即可，流计算因为数据持续流入，需要通过精确一次语义、检查点机制等复杂的容错策略保障数据处理的一致性，避免重跑带来的重复计算问题。解析：批计算和流计算各有适用场景，近年批流一体技术的成熟让同一套计算引擎可以同时高效支持两种处理模式，大幅降低了平台架构的复杂度。简述大数据集群常见的性能优化方向。答案：第一，集群硬件层面优化，针对不同组件的特性适配不同硬件配置，比如为NameNode配置更大的内存存储元数据，为计算节点配置高转速固态硬盘提升磁盘IO性能，为大流量的日志采集链路配置更高带宽的网卡；第二，系统层面优化，关闭不需要的系统服务，调整Linux系统的文件句柄上限、网络连接参数，避免大数据进程运行时出现资源限制报错；第三，组件参数层面优化，根据集群的硬件规模调整HDFS块大小、YARN单个节点的可用内存和CPU核数、Spark计算任务的并行度等核心参数，充分利用集群硬件资源；第四，业务逻辑层面优化，优化大数据开发的SQL逻辑，避免出现数据倾斜、全表笛卡尔积等不合理的代码写法，减少不必要的shuffle操作，提升单个任务的运行效率。解析：大数据集群性能优化是一个从底层硬件到上层业务逻辑逐层迭代的过程，需要结合实际的业务运行情况逐步调整，没有通用的万能优化方案。五、论述题（共3题，每题10分，共30分）结合实际业务实例，论述批流一体大数据架构的核心优势和落地实施要点。答案：首先是核心论点，批流一体架构通过统一的引擎同时支持离线批处理和实时流处理，解决了传统Lambda架构需要同时维护两套独立技术栈带来的开发成本高、数据口径不一致的痛点。论据部分，传统的Lambda架构中，业务方为了获取实时数据结果会用流计算引擎开发一套实时逻辑，同时为了修正实时计算的误差、输出更准确的全量结果，又要用批计算引擎开发一套完全独立的离线计算逻辑，两套逻辑使用不同的开发语言、不同的技术组件，不仅重复开发工作量大，还经常出现实时离线数据统计口径不一致，业务方不知道该信哪一个数据的问题。某头部电商平台落地批流一体架构的实际案例中，平台原本用Storm做实时交易金额统计，用MapReduce做离线日交易金额统计，经常出现实时累计值和离线日统计值有差异的问题，业务运营团队经常花费大量时间核对数据差异。在替换为基于Flink的批流一体架构之后，整个统计逻辑只用开发一套代码，既可以作为流任务持续实时统计当天的交易金额输出实时大屏，也可以作为批任务在每天凌晨对前一天的全量交易数据重新跑一遍生成准确的日统计结果，因为代码逻辑完全一致，彻底解决了口径不一致的问题，同时原先需要两个开发人员分别维护两套任务，现在只需要一个开发人员维护同一套逻辑，人力成本下降了接近一半。落地实施要点第一，优先选择原生支持批流一体语义的成熟引擎，避免使用需要二次改造的老旧组件，减少架构适配的工作量；第二，统一批流计算的元数据体系，实时数据和离线数据都使用统一的表定义、统一的维度字典表，从根源上避免口径差异；第三，配套开发统一的任务运维管控平台，同时支持批任务的周期调度和流任务的状态监控，不用分别维护两套运维体系。最终结论是批流一体架构是当前大数据平台架构的主流发展方向，能够大幅降低平台的运维成本和开发成本，提升数据的一致性保障能力。解析：该论述从传统架构的痛点切入，结合真实电商业务的落地实例做佐证，论点论据完整清晰，覆盖了架构优势、实际落地效果、实施要点三个核心维度，符合大数据架构的实际发展趋势。结合零售行业的数据治理落地实例，论述大数据治理的核心价值和落地过程中常见痛点的解决方案。答案：核心论点是大数据治理的核心价值不是做一堆没有实际用处的文档制度，而是通过数据的标准化管控，打破企业内部各业务部门之间的数据孤岛，把数据从零散的资源转化为可复用的资产，真正支撑业务效率提升。论据部分，某大型连锁零售企业在没有做数据治理之前，线下20多个区域门店分别有自己的业务系统，每个系统统计“活跃用户”的定义都不一样，有的定义是近30天下过单的用户，有的定义是近7天到店消费过的用户，总部想要统计全国的活跃用户总数，各个部门提交上来的报表数据差异超过30%，完全无法支撑管理决策。同时不同部门各自开发自己的数仓任务，同一个“用户年龄维度表”被重复开发了十几次，存储资源浪费严重。后来该企业启动大数据治理项目，第一步先统一制定全公司层面的核心数据指标规范，明确所有和用户、订单相关的核心指标的统计口径、计算逻辑、责任人，全公司所有部门都必须按照统一的口径生成数据；第二步搭建统一的元数据管理平台，梳理清楚全量数据的血缘链路，清理了超过40%完全没有任何下游依赖的冗余无效任务，节省了近一半的存储和计算资源开销；第三步建立分级数据权限管控体系，普通业务人员只能访问和自己业务相关的脱敏数据，既满足了业务部门的数据使用需求，也避免了敏感用户隐私数据泄露的风险。落地过程中的常见痛点和解决方案，第一个痛点是业务部门觉得数据治理是纯技术部门的事，参与度极低，解决方案是成立跨部门的指标委员会，由业务方和技术方共同参与指标口径的评审，确定下来的口径由双方共同认可，避免后续业务方质疑数据结果不对；第二个痛点是数据治理的效果很难快速体现，管理层看不到价值不愿意持续投入，解决方案是优先从业务痛点最高的场景切入，比如先把全公司最核心的TOP20指标的口径统一，快速解决管理层最头疼的报表数据不一致问题，让业务方快速看到治理的实际收益