2025年大數(shù)據(jù)工程師考試試題及答案一、單項(xiàng)選擇題（每題2分，共20分）1.以下關(guān)于HDFS默認(rèn)塊大小的描述，正確的是（）A.16MBB.32MBC.64MBD.128MB答案：D2.下列Spark操作中，屬于轉(zhuǎn)換（Transformation）操作的是（）A.collect()B.reduce()C.groupByKey()D.count()答案：C3.Kafka中，消費(fèi)者組（ConsumerGroup）的主要作用是（）A.提高生產(chǎn)者的發(fā)送吞吐量B.實(shí)現(xiàn)消息的廣播與負(fù)載均衡C.保證消息的順序性D.減少Broker的存儲(chǔ)壓力答案：B4.數(shù)據(jù)傾斜（DataSkew）最可能導(dǎo)致的問題是（）A.計(jì)算任務(wù)超時(shí)B.數(shù)據(jù)丟失C.存儲(chǔ)成本增加D.網(wǎng)絡(luò)帶寬浪費(fèi)答案：A5.Flink中，事件時(shí)間（EventTime）的語義依賴于（）A.處理時(shí)間（ProcessingTime）B.水?。╓atermark）C.檢查點(diǎn)（Checkpoint）D.窗口（Window）答案：B6.HBase中，RegionServer負(fù)責(zé)管理的核心組件是（）A.HMasterB.RegionC.ZooKeeperD.WAL（預(yù)寫日志）答案：B7.數(shù)據(jù)湖（DataLake）與數(shù)據(jù)倉庫（DataWarehouse）的主要區(qū)別在于（）A.數(shù)據(jù)存儲(chǔ)格式B.數(shù)據(jù)結(jié)構(gòu)化程度C.查詢性能D.數(shù)據(jù)來源數(shù)量答案：B8.ClickHouse中，適合高頻寫入、低頻查詢場(chǎng)景的表引擎是（）A.MergeTreeB.LogC.ReplacingMergeTreeD.Distributed答案：B9.以下不屬于Kudu核心特性的是（）A.支持ACID事務(wù)B.高并發(fā)隨機(jī)讀C.列式存儲(chǔ)D.實(shí)時(shí)寫入與實(shí)時(shí)查詢答案：A（Kudu支持有限事務(wù)，非完整ACID）10.機(jī)器學(xué)習(xí)模型訓(xùn)練中，使用SparkMLlib的Pipeline時(shí)，特征工程階段的Transformer需要（）A.調(diào)用fit()方法生成模型B.直接調(diào)用transform()方法處理數(shù)據(jù)C.與Estimator交替使用D.僅用于測(cè)試集處理答案：B二、填空題（每題2分，共20分）1.Hadoop生態(tài)中，負(fù)責(zé)資源管理的組件是________。答案：YARN2.SparkRDD的持久化級(jí)別中，MEMORY_AND_DISK_SER表示________。答案：數(shù)據(jù)先存內(nèi)存，內(nèi)存不足時(shí)溢寫磁盤，且數(shù)據(jù)序列化存儲(chǔ)3.Kafka的消息偏移量（Offset）由________維護(hù)。答案：消費(fèi)者（或消費(fèi)者組）4.Flink的狀態(tài)后端（StateBackend）支持的三種類型是：MemoryStateBackend、FsStateBackend和________。答案：RocksDBStateBackend5.Hive的元數(shù)據(jù)存儲(chǔ)通常使用________數(shù)據(jù)庫（填寫常見選型）。答案：MySQL6.數(shù)據(jù)治理的核心目標(biāo)是保障數(shù)據(jù)的________、完整性和可用性。答案：準(zhǔn)確性（或一致性）7.實(shí)時(shí)計(jì)算中，窗口（Window）的常見類型包括時(shí)間窗口、計(jì)數(shù)窗口和________。答案：會(huì)話窗口（SessionWindow）8.分布式事務(wù)解決方案中，Seata的AT模式依賴于________實(shí)現(xiàn)數(shù)據(jù)回滾。答案：全局鎖（或回滾日志）9.數(shù)據(jù)脫敏的常見方法包括匿名化、________和掩碼處理。答案：泛化（或隨機(jī)化）10.機(jī)器學(xué)習(xí)中，處理類別不平衡數(shù)據(jù)的常用方法有過采樣、欠采樣和________。答案：調(diào)整類別權(quán)重（或使用代價(jià)敏感學(xué)習(xí)）三、簡(jiǎn)答題（每題8分，共40分）1.簡(jiǎn)述Hive與SparkSQL在執(zhí)行引擎上的主要差異。答案：Hive基于MapReduce引擎，將SQL轉(zhuǎn)換為多個(gè)MapReduce任務(wù)，通過YARN調(diào)度，適合離線批量處理，但任務(wù)啟動(dòng)開銷大、延遲高；SparkSQL基于Spark的內(nèi)存計(jì)算引擎，將SQL轉(zhuǎn)換為RDD/Dataset的DAG執(zhí)行計(jì)劃，支持內(nèi)存迭代計(jì)算和緩存，任務(wù)執(zhí)行效率更高，且支持實(shí)時(shí)查詢（如SparkStreaming結(jié)合）和交互式分析。2.說明Kafka如何保證消息的可靠性（至少列出3點(diǎn)機(jī)制）。答案：（1）生產(chǎn)者確認(rèn)（ACK機(jī)制）：生產(chǎn)者發(fā)送消息時(shí)，可設(shè)置ACK=0（不確認(rèn)）、1（Leader確認(rèn)）、-1（ISR全確認(rèn)），ACK=-1時(shí)可靠性最高；（2）Broker持久化：消息寫入磁盤（通過分段日志+索引），結(jié)合副本機(jī)制（ISR中的Follower同步），避免單節(jié)點(diǎn)故障；（3）消費(fèi)者偏移量提交：消費(fèi)者手動(dòng)或自動(dòng)提交消費(fèi)偏移量，避免重復(fù)消費(fèi)或數(shù)據(jù)丟失；（4）日志壓縮（LogCompaction）：對(duì)相同Key的消息保留最新值，防止日志無限增長(zhǎng)導(dǎo)致的存儲(chǔ)問題。3.數(shù)據(jù)傾斜的檢測(cè)方法及解決思路（至少3種）。答案：檢測(cè)方法：（1）觀察任務(wù)執(zhí)行日志，查看各Reducer/Task的運(yùn)行時(shí)間，若某任務(wù)耗時(shí)遠(yuǎn)高于其他，可能存在傾斜；（2）統(tǒng)計(jì)Key的分布，通過GROUPBYKeyCOUNT()定位高頻Key；（3）監(jiān)控集群指標(biāo)（如CPU、內(nèi)存），傾斜任務(wù)所在節(jié)點(diǎn)資源占用異常。解決思路：（1）業(yè)務(wù)側(cè)優(yōu)化：拆分高頻Key（如添加隨機(jī)前綴），分散到多個(gè)任務(wù)處理；（2）參數(shù)調(diào)優(yōu)：增大Reducer數(shù)量，或調(diào)整Spark的shuffle分區(qū)數(shù)（spark.sql.shuffle.partitions）；（3）算法優(yōu)化：使用Map端聚合（如Hive的mapjoin、Spark的broadcastjoin）避免Shuffle；（4）存儲(chǔ)層優(yōu)化：預(yù)聚合傾斜Key的數(shù)據(jù)，減少計(jì)算時(shí)的壓力。4.簡(jiǎn)述Flink的狀態(tài)管理機(jī)制（包括狀態(tài)類型和存儲(chǔ)方式）。答案：Flink的狀態(tài)分為算子狀態(tài)（OperatorState）和鍵值狀態(tài)（KeyedState）。算子狀態(tài)與算子實(shí)例綁定（如Kafka消費(fèi)者的分區(qū)偏移量），支持列表狀態(tài)（ListState）、聯(lián)合列表狀態(tài)（UnionListState）等；鍵值狀態(tài)與Key綁定（需KeyBy操作），支持值狀態(tài)（ValueState）、列表狀態(tài)（ListState）、映射狀態(tài)（MapState）等。狀態(tài)存儲(chǔ)依賴狀態(tài)后端：MemoryStateBackend將狀態(tài)存內(nèi)存（測(cè)試用）；FsStateBackend將元數(shù)據(jù)存內(nèi)存、狀態(tài)存分布式文件系統(tǒng)（如HDFS）；RocksDBStateBackend將狀態(tài)存本地RocksDB數(shù)據(jù)庫（適合大狀態(tài)場(chǎng)景）。狀態(tài)通過檢查點(diǎn)（Checkpoint）實(shí)現(xiàn)持久化，故障時(shí)可恢復(fù)。5.數(shù)據(jù)治理中的主數(shù)據(jù)管理（MasterDataManagement，MDM）主要包含哪些內(nèi)容？答案：主數(shù)據(jù)管理是對(duì)企業(yè)核心業(yè)務(wù)實(shí)體（如客戶、產(chǎn)品、供應(yīng)商）的統(tǒng)一管理，內(nèi)容包括：（1）主數(shù)據(jù)標(biāo)準(zhǔn)制定：定義主數(shù)據(jù)的字段、格式、業(yè)務(wù)規(guī)則（如客戶ID的唯一性）；（2）主數(shù)據(jù)整合：通過ETL或MDM平臺(tái)，合并多源系統(tǒng)的主數(shù)據(jù)，消除沖突（如同一客戶在不同系統(tǒng)的不同編碼）；（3）主數(shù)據(jù)共享：建立主數(shù)據(jù)中心庫，提供API或服務(wù)供各業(yè)務(wù)系統(tǒng)調(diào)用，確保全局一致性；（4）主數(shù)據(jù)生命周期管理：覆蓋創(chuàng)建、更新、歸檔、刪除的全流程，記錄變更日志；（5）主數(shù)據(jù)質(zhì)量監(jiān)控：通過規(guī)則校驗(yàn)（如完整性、準(zhǔn)確性）和血緣分析，保障主數(shù)據(jù)質(zhì)量。四、編程題（每題10分，共20分）1.用SparkSQL編寫代碼，處理用戶行為日志表（user_behavior），計(jì)算“次日留存率”。表結(jié)構(gòu)：user_id（用戶ID，長(zhǎng)整型）、event_time（事件時(shí)間，時(shí)間戳）、event_type（事件類型，字符串）。要求：（1）提取用戶首次活躍日期（首次訪問日期）；（2）計(jì)算首次活躍后次日（+1天）再次活躍的用戶數(shù)；（3）輸出格式：首次活躍日期、總用戶數(shù)、次日留存用戶數(shù)、留存率（保留4位小數(shù)）。答案：```scalaimportorg.apache.spark.sql.functions._importorg.apache.spark.sql.expressions.scalalang.typed//讀取用戶行為日志表valuserBehavior=spark.table("user_behavior")//步驟1：提取用戶首次活躍日期valfirstActive=userBehavior.select(col("user_id"),to_date(from_unixtime(col("event_time"))).as("active_date")).groupBy("user_id").agg(min("active_date").as("first_active_date"))//步驟2：關(guān)聯(lián)用戶所有活躍日期，篩選次日活躍記錄valuserActive=userBehavior.select(col("user_id"),to_date(from_unixtime(col("event_time"))).as("active_date")).distinct()//去重同一用戶同一天的多次活躍valretentionData=firstActive.join(userActive,firstActive("user_id")===userActive("user_id"),"left").withColumn("is_second_day",when(userActive("active_date")===date_add(firstActive("first_active_date"),1),1).otherwise(0))//步驟3：按首次活躍日期聚合計(jì)算留存率valretentionResult=retentionData.groupBy("first_active_date").agg(countDistinct("user_id").as("total_users"),sum("is_second_day").as("retained_users")).withColumn("retention_rate",round(col("retained_users").divide(col("total_users")),4)).orderBy("first_active_date")retentionResult.show()```2.用Flink編寫實(shí)時(shí)計(jì)算程序，統(tǒng)計(jì)“每10分鐘內(nèi)，各商品分類的點(diǎn)擊量”，要求使用滑動(dòng)窗口（滑動(dòng)步長(zhǎng)5分鐘），并輸出結(jié)果到Kafka。已知：-輸入流：Kafka主題“user_clicks”，格式為JSON（字段：user_id,item_id,category_id,click_time（時(shí)間戳））；-輸出主題：“category_click_stats”，格式為CSV（category_id,click_count,window_start,window_end）。答案：```javaimportmon.eventtime.;importmon.serialization.SimpleStringSchema;importorg.apache.flink.connector.kafka.source.KafkaSource;importorg.apache.flink.connector.kafka.sink.KafkaSink;importorg.apache.flink.streaming.api.datastream.DataStream;importorg.apache.flink.streaming.api.environment.StreamExecutionEnvironment;importorg.apache.flink.streaming.api.windowing.assigners.SlidingEventTimeWindows;importorg.apache.flink.streaming.api.windowing.time.Time;importorg.apache.flink.util.Collector;importcom.fasterxml.jackson.databind.JsonNode;importcom.fasterxml.jackson.databind.ObjectMapper;publicclassCategoryClickStats{publicstaticvoidmain(String[]args)throwsException{StreamExecutionEnvironmentenv=StreamExecutionEnvironment.getExecutionEnvironment();env.setParallelism(4);//1.讀取Kafka輸入流KafkaSource<String>kafkaSource=KafkaSource.<String>builder().setBootstrapServers("kafka-broker:9092").setTopics("user_clicks").setGroupId("flink-category-stats-group").setValueOnlyDeserializer(newSimpleStringSchema()).build();DataStream<String>clickStream=env.fromSource(kafkaSource,WatermarkStrategy.forBoundedOutOfOrderness(Duration.ofSeconds(5)),"KafkaInput");//2.解析JSON并提取事件時(shí)間和分類IDDataStream<CategoryClick>parsedStream=clickStream.map(value->{ObjectMappermapper=newObjectMapper();JsonNodenode=mapper.readTree(value);longclickTime=node.get("click_time").asLong();StringcategoryId=node.get("category_id").asText();returnnewCategoryClick(categoryId,clickTime);}).assignTimestampsAndWatermarks(WatermarkStrategy.<CategoryClick>forBoundedOutOfOrderness(Duration.ofSeconds(5)).withTimestampAssigner((event,timestamp)->event.clickTime));//3.定義滑動(dòng)窗口（窗口大小10分鐘，滑動(dòng)步長(zhǎng)5分鐘）DataStream<String>resultStream=parsedStream.keyBy(event->event.categoryId).window(SlidingEventTimeWindows.of(Time.minutes(10),Time.minutes(5))).aggregate(newCategoryClickAggregate(),newWindowResultFunction());//4.輸出到KafkaKafkaSink<String>kafkaSink=KafkaSink.<String>builder().setBootstrapServers("kafka-broker:9092").setRecordSerializer(newKafkaRecordSerializationSchemaBuilder<String>().setTopic("category_click_stats").setValueSerializationSchema(newSimpleStringSchema()).build()).build();resultStream.sinkTo(kafkaSink).name("KafkaOutput");env.execute("Real-timeCategoryClickStatistics");}//自定義POJO類publicstaticclassCategoryClick{publicStringcategoryId;publiclongclickTime;publicCategoryClick(StringcategoryId,longclickTime){this.categoryId=categoryId;this.clickTime=clickTime;}}//自定義聚合函數(shù)（統(tǒng)計(jì)點(diǎn)擊次數(shù)）publicstaticclassCategoryClickAggregateimplementsAggregateFunction<CategoryClick,Long,Long>{@OverridepublicLongcreateAccumulator(){return0L;}@OverridepublicLongadd(CategoryClickvalue,Longaccumulator){returnaccumulator+1;}@OverridepublicLonggetResult(Longaccumulator){returnaccumulator;}@OverridepublicLongmerge(Longa,Longb){returna+b;}}//自定義窗口結(jié)果函數(shù)（格式化輸出）publicstaticclassWindowResultFunctionimplementsWindowFunction<Long,String,String,TimeWindow>{@Overridepublicvoidapply(StringcategoryId,TimeWindowwindow,Iterable<Long>aggregateResult,Collector<String>out){longclickCount=aggregateResult.iterator().next();StringwindowStart=String.valueOf(window.getStart());StringwindowEnd=String.valueOf(window.getEnd());out.collect(String.format("%s,%d,%s,%s",categoryId,clickCount,windowStart,windowEnd));}}}```五、綜合分析題（20分）某電商公司計(jì)劃構(gòu)建大數(shù)據(jù)平臺(tái)，需處理以下場(chǎng)景：-業(yè)務(wù)系統(tǒng)日志（如用戶點(diǎn)擊、下單、支付）：日均數(shù)據(jù)量500GB，實(shí)時(shí)性要求高（延遲<5秒）；-業(yè)務(wù)數(shù)據(jù)庫（MySQL）增量數(shù)據(jù)：日均變更量100GB，需同步到分析庫；-歷史訂單數(shù)據(jù)：總量10TB，需支持復(fù)雜OLAP查詢（如多表關(guān)聯(lián)、分組聚合）；-機(jī)器學(xué)習(xí)需求：需基于用戶行為、訂單、商品等數(shù)據(jù)訓(xùn)練推薦模型。請(qǐng)?jiān)O(shè)計(jì)該平臺(tái)的技術(shù)架構(gòu)，并說明各組件的選型及作用（需涵蓋數(shù)據(jù)采集、存儲(chǔ)、計(jì)算、應(yīng)用層）。答案：技術(shù)架構(gòu)設(shè)計(jì)如下（分層說明）：1.數(shù)據(jù)采集層-業(yè)務(wù)日志采集：使用Flume或Logstash實(shí)時(shí)采集服務(wù)器日志，發(fā)送至Kafka消息隊(duì)列（選型Kafka，原因：高吞吐量、支持消息持久化和多消費(fèi)者訂閱，滿足5秒內(nèi)的實(shí)時(shí)性要求）；-數(shù)據(jù)庫增量同步：使用Canal（針對(duì)MySQL）解析Binlog，捕獲增量變更，通過Kafka傳輸（Canal支持準(zhǔn)實(shí)時(shí)同步，延遲可控制在毫秒級(jí)，適合業(yè)務(wù)數(shù)據(jù)庫的增量同步需求）；-歷史數(shù)據(jù)導(dǎo)入：通過Sqoop將MySQL歷史訂單數(shù)據(jù)批量導(dǎo)入HDFS或Hive（Sqoop支持關(guān)系型數(shù)據(jù)庫與Hadoop生態(tài)的高效遷移）。2.數(shù)據(jù)存儲(chǔ)層-實(shí)時(shí)數(shù)據(jù)存儲(chǔ)：Kafka作為實(shí)時(shí)數(shù)據(jù)緩沖區(qū)（保留7天日志，支持實(shí)時(shí)計(jì)算任務(wù)訂閱）；-原始數(shù)據(jù)存儲(chǔ)：HDFS存儲(chǔ)全量原始日志和歷史訂單數(shù)據(jù)（HDFS適合海量非結(jié)構(gòu)化/半結(jié)構(gòu)化數(shù)據(jù)的低成本存儲(chǔ)，支持高容錯(cuò)）；-實(shí)時(shí)計(jì)算中間存儲(chǔ)：Kudu存儲(chǔ)實(shí)時(shí)聚合的用戶行為指標(biāo)（如實(shí)時(shí)點(diǎn)擊量），支持快速更新和隨機(jī)讀（Kudu兼容Spark/Flink，適合實(shí)時(shí)OLAP場(chǎng)景）；-