2026年大数据考试试题及标准答案

2026年大数据考试试题及标准答案一、单项选择题（每题2分，共20分）1.在HDFS中，默认的块大小为A.32MBB.64MBC.128MBD.256MB答案：C2.SparkCore默认的序列化方式是A.Java序列化B.Kryo序列化C.Avro序列化D.ProtocolBuffers答案：A3.在Kafka2.8之后，移除ZooKeeper依赖的组件是A.ProducerB.ConsumerC.KraftControllerD.SchemaRegistry答案：C4.下列哪一项不是Hive支持的文件存储格式A.ORCB.ParquetC.JSOND.HFile答案：D5.Flink的Checkpoint机制基于哪种一致性快照算法A.Two-PhaseCommitB.Chandy-LamportC.PaxosD.Raft答案：B6.在HBase中，用于定位Region的元数据表是A..META.B.-ROOT-C.hbase:metaD.zookeeper答案：C7.若某列的基数（cardinality）极低，最适合的压缩编码是A.DeltaB.Run-LengthC.DictionaryD.Bit-Packing答案：B8.在ClickHouse中，最适合做高并发点查的引擎是A.MergeTreeB.SummingMergeTreeC.LogD.TinyLog答案：A9.下列关于数据湖的说法正确的是A.仅支持结构化数据B.必须预先定义SchemaC.支持Schema-on-ReadD.不支持ACID事务答案：C10.GDPR中“被遗忘权”对应的数据治理活动是A.数据脱敏B.数据销毁C.数据加密D.数据分级答案：B二、多项选择题（每题3分，共15分，多选少选均不得分）11.以下哪些属于Flink的Time概念A.EventTimeB.IngestionTimeC.ProcessingTimeD.WindowTime答案：ABC12.在SparkSQL中，Catalyst优化器包含哪些阶段A.AnalysisB.LogicalPlanOptimizationC.PhysicalPlanningD.CodeGeneration答案：ABCD13.关于HDFS联邦（Federation）特性，正确的有A.多个NameNode共享同一DataNode存储B.每个NameNode管理独立的命名空间C.支持跨NameNode的Block移动D.需客户端挂载表（ViewFS）访问答案：ABD14.以下哪些操作会触发Spark的ShuffleA.reduceByKeyB.groupByKeyC.mapD.distinct答案：ABD15.数据仓库分层架构中，通常包含A.ODSB.DWDC.DWSD.ADS答案：ABCD三、填空题（每空2分，共20分）16.在Kafka中，消费者组再均衡（rebalance）的触发条件包括________、________、________。答案：消费者加入、消费者退出、订阅主题分区数变化17.Spark的RDD依赖分为________依赖和________依赖。答案：窄、宽18.HBase中RowKey设计需遵循________、________、________三原则。答案：长度原则、散列原则、唯一原则19.在Hive中，函数regexp_extract(str,regex,idx)若idx为0，则返回________。答案：完整匹配子串20.Flink的Checkpoint超时参数在flink-conf.yaml中的键为________。答案：execution.checkpointing.timeout四、判断题（每题1分，共10分，正确打“√”，错误打“×”）21.ORC文件格式支持谓词下推（PredicatePushdown）。答案：√22.SparkStreaming的微批次间隔越短，延迟一定越低，吞吐一定越高。答案：×23.ClickHouse的ReplacingMergeTree会在后台自动去重。答案：√24.HDFS的ErasureCoding比三副本策略节省50%以上存储空间。答案：√25.Kafka的Producer发送消息时，若acks=0则一定不丢数据。答案：×26.HiveonTez执行引擎支持DAG级优化。答案：√27.Flink的KeyBy操作会触发Shuffle。答案：√28.在数据湖Iceberg中，Snapshot过期后数据文件立即物理删除。答案：×29.SparkSQL的窗口函数over()子句必须包含partitionby。答案：×30.HBase的Coprocessor可在RegionServer端执行自定义逻辑。答案：√五、简答题（每题8分，共24分）31.简述Lambda架构与Kappa架构的核心差异，并给出各自适用场景。答案：Lambda同时维护批处理层与速度层，保证最终一致性但运维复杂；Kappa仅保留流处理层，通过重放消息队列实现离线计算，简化架构。Lambda适用于已存在大量批处理资产且对延迟要求不极端的场景；Kappa适用于事件可重放、实时与离线逻辑一致且希望降低运维成本的场景。32.说明SparkSQL中BroadcastJoin的触发条件及调优思路。答案：触发条件：小表大小低于参数spark.sql.autoBroadcastJoinThreshold（默认10MB），且被广播到各Executor后内存充足。调优思路：1)确认小表真实大小（压缩后、过滤后）；2)适当提高阈值但不超过Executor内存的10%；3)使用hint/+broadcast(a)/强制广播；4)避免大表被误判，关闭自动广播并手动指定；5)监控Driver端内存防止广播变量过大导致OOM。答案：触发条件：小表大小低于参数spark.sql.autoBroadcastJoinThreshold（默认10MB），且被广播到各Executor后内存充足。调优思路：1)确认小表真实大小（压缩后、过滤后）；2)适当提高阈值但不超过Executor内存的10%；3)使用hint/+broadcast(a)/强制广播；4)避免大表被误判，关闭自动广播并手动指定；5)监控Driver端内存防止广播变量过大导致OOM。33.描述HDFS写数据流程中Packet队列与ACK队列的作用，并说明数据节点故障时的处理机制。答案：客户端将数据切分为Packet，先放入dataQueue，按Pipeline发送给DataNode；每个DataNode收到后写入磁盘并转发给下游，同时将ACK返回客户端，ACK信息进入ackQueue。若某DataNode故障，客户端移除该节点，剩余节点组成新Pipeline，NameNode后续通过副本监控线程发现副本不足，选择新节点复制块，保证副本数。六、计算题（共3题，共31分）34.（9分）某电商公司使用Spark对60GB用户日志进行ETL，集群共10节点，每节点4核16GB。原始任务使用200个分区，运行耗时45分钟。优化后，将分区数调整为400，并启用Kryo序列化，运行耗时降至28分钟。已知Sparkstage中，ShuffleRead总量为120GB，ShuffleWrite总量为100GB。（1）计算优化前后平均每个分区的数据量，并说明为何减少分区数据量能缩短耗时。（2）估算Kryo序列化带来的网络与磁盘IO节省比例（给出计算过程）。答案：（1）优化前：60GB/200=307MB/分区；优化后：60GB/400=153MB/分区。分区数据量减半，减少单个任务GC压力与Spill次数，提升CPU利用率，同时增加并行度，故耗时下降。（2）Java序列化对象膨胀约2.5倍，Kryo约1.1倍，节省比例=(2.5−1.1)/2.5=56%。ShuffleWrite100GB×56%=节省56GB磁盘与网络传输；ShuffleRead120GB×56%=节省67.2GB。35.（10分）某Topic在Kafka有6个分区，生产者每秒写入3000条消息，每条消息1KB，副本因子3，保留7天。计算：（1）每秒写入字节量；（2）7天总存储量（不含压缩）；（3）若开启Snappy压缩，压缩比0.3，实际磁盘占用多少？答案：（1）3000×1KB=3MB/s；（2）3MB/s×86400s×7=1.8144TB；（3）1.8144TB×0.3=0.54432TB≈544GB。36.（12分）Flink作业消费Kafka，并行度为12，Checkpoint间隔5分钟，恰好一次语义，状态后端使用RocksDB增量Checkpoint。某天作业失败恢复时发现最后一个成功Checkpoint为t0，之后KafkaTopic新增分区2个。（1）恢复时如何分配新的Kafka分区到12个并行度，保证负载均衡？（2）若每个并行度状态大小为800MB，增量Checkpoint平均产出200MB，上传到S3带宽为100MB/s，计算单次Checkpoint上传耗时；（3）说明新增分区后如何重新触发Savepoint并平滑扩容至16并行度。答案：（1）总分区=原分区+2，使用Flink的KafkaPartitionDiscoverer，在恢复时调用FlinkKafkaConsumer#setPartitionDiscoveryInterval，发现新分区后通过Rescale模式重新分配，采用round-robin：新分区P_new1→mod12=10，P_new2→mod12=11。（2）增量数据200MB×12=2.4GB，带宽100MB/s，耗时2.4GB/100MB/s=24s。（3）步骤：1)暂停外部数据流入（Kafka暂停生产或作业置为STOP_FROM_SAVEPOINT）；2)触发Savepoint：bin/flinksavepoint<jobId>targetPath；3)取消作业；4)修改并行度为16重新提交：bin/flinkrun-s<savepointPath>-p16app.jar；5)Flink通过StateRepartitioning将800MB×12状态重新哈希到16并行度，每个新并行度约600MB，完成平滑扩容。七、综合分析题（共30分）37.某省政务大数据平台日均接入原始数据8TB，包含结构化业务库、半结构化日志、非结构化扫描件。平台采用Lambda架构：批层使用HiveonTez，速度层使用Flink+Kafka，服务层使用HBase+Presto。近半年出现以下问题：A.凌晨批作业经常因NameNodeRPC队列打满失败；B.Flink作业偶发Checkpoint超时，导致Kafka消费位点回退，重复写入HBase；C.用户通过Presto查询HBase，大表全表扫描超时；D.扫描件经OCR后写入HDFS，小文件数达3.2亿，占块数却不足10%，NameNode内存占用过高。请给出系统性优化方案，要求：（1）针对A，给出至少两条可落地的HDFS参数级优化；（2）针对B，从Flink端到端一致性角度，给出KafkaProducer、FlinkCheckpoint、HBaseSink三阶段配置级优化；（3）针对C，给出Presto+HBase的索引级与SQL级优化；（4）针对D，给出小文件合并的在线+离线双轨方案，并估算合并后NameNode内存节省比例。答案：（1）HDFS参数优化：①提高NameNodehandler数：node.handler.count=200×(1+log2(节点数))，现集群80节点，可设1200；②启用RPCFairCallQueue：node.rpc.backoff.enable=true，node.rpc.queue.impl=org.apache.hadoop.ipc.FairCallQueue，node.rpc.num.response.queues=8；③调整块报告间隔：ervalMsec=21600000（6h），减少峰值RPC。（2）Flink端到端一致性：①KafkaProducer设置enable.idempotence=true，transactional.id前缀统一，acks=all；②FlinkCheckpoint：开启Exactly-Once，checkpoint间隔设为30s，超时10min，min-pause=20s，enable.unaligned-checkpoints=true防止背压超时；③HBaseSink使用Two-PhaseCommit：继承TwoPhaseCommitSinkFunction，在preCommit阶段将数据刷写到HBase的临时列族，commit阶段批量移动至正式列族，若失败则回滚删除临时数据；同时设置Flink的state.backend.incremental=