2025年大數(shù)據(jù)技術(shù)與應(yīng)用職業(yè)能力測(cè)試試卷及答案一、單項(xiàng)選擇題（每題2分，共20分。每題只有一個(gè)正確答案，錯(cuò)選、多選、未選均不得分）1.在Hadoop3.x版本中，下列哪項(xiàng)參數(shù)直接決定了NameNode元數(shù)據(jù)持久化的觸發(fā)閾值？A.node.checkpoint.txnsB.dfs.block.sizeC.dfs.replicationD.node.handler.count答案：A解析：node.checkpoint.txns表示兩次checkpoint之間允許的最大事務(wù)數(shù)，達(dá)到該閾值即觸發(fā)持久化，與元數(shù)據(jù)安全直接相關(guān)；其余選項(xiàng)分別控制塊大小、副本數(shù)及RPC線程數(shù)，與持久化觸發(fā)無(wú)關(guān)。2.Flink1.17中，若使用TableAPI讀取Kafka，要求端到端僅一次語(yǔ)義，必須開(kāi)啟的Kafka參數(shù)是：A.enable.idempotence=falseB.isolation.level=read_uncommittedC.enable.idempotence=trueD.auto.offset.reset=latest答案：C解析：enable.idempotence=true保證KafkaProducer冪等，是Flink實(shí)現(xiàn)端到端僅一次的前提；read_uncommitted會(huì)讀到未提交數(shù)據(jù)，破壞一致性。3.某電商公司使用Spark3.4對(duì)500GB用戶(hù)行為日志做去重，最合理的去重算子是：A.distinct()B.dropDuplicates(Seq("user_id","sku_id"))C.groupByKey().count()D.reduceByKey(_+_)答案：B解析：dropDuplicates可指定列去重，避免全表shuffle；distinct()需全量比較，性能差；groupByKey會(huì)產(chǎn)生大量shuffle；reduceByKey用于聚合而非去重。4.在Hive3.1中，創(chuàng)建分區(qū)表時(shí)為避免小文件過(guò)多，應(yīng)優(yōu)先使用的表屬性是：A.TRANSACTIONAL=trueB.auto.purge=trueC.hive.exec.dynamic.partition.mode=nonstrictD.hive.merge.mapfiles=true答案：D解析：hive.merge.mapfiles=true在作業(yè)結(jié)束時(shí)合并小文件；nonstrict僅允許動(dòng)態(tài)分區(qū)，不解決小文件；auto.purge控制刪除數(shù)據(jù)是否進(jìn)入回收站；TRANSACTIONAL用于ACID表。5.某企業(yè)使用DeltaLake2.3，要求時(shí)間旅行查詢(xún)2024060110:00:00的快照，正確語(yǔ)法是：A.SELECTFROMeventsTIMESTAMPASOF'2024060110:00:00'B.SELECTFROMeventsVERSIONASOF20240601100000C.SELECTFROMevents@20240601100000D.SELECTFROMeventsFORSYSTEM_TIMEASOF'2024060110:00:00'答案：A解析：DeltaLake支持TIMESTAMPASOF語(yǔ)法，精確到秒；VERSIONASOF需傳入整數(shù)版本號(hào)；@語(yǔ)法為Hive風(fēng)格，Delta不支持；SYSTEM_TIME為SQLServer語(yǔ)法。6.使用Hudi0.14進(jìn)行流式寫(xiě)入時(shí)，為將遲到數(shù)據(jù)自動(dòng)合并到最新分區(qū)，應(yīng)選擇的表類(lèi)型是：A.COPY_ON_WRITEB.MERGE_ON_READC.HOLLOWD.ARCHIVE答案：B解析：MERGE_ON_READ支持行級(jí)更新，遲到數(shù)據(jù)通過(guò)deltafile合并；COPY_ON_WRITE需重寫(xiě)整個(gè)文件，延遲高；HOLLOW與ARCHIVE非Hudi表類(lèi)型。7.某Spark任務(wù)因數(shù)據(jù)傾斜導(dǎo)致長(zhǎng)尾Task，以下調(diào)優(yōu)手段最有效的是：A.提高spark.default.parallelismB.增加spark.sql.shuffle.partitions至8000C.對(duì)傾斜key添加隨機(jī)前綴，兩階段聚合D.將spark.serializer改為JavaSerializer答案：C解析：隨機(jī)前綴+兩階段聚合直接打散熱點(diǎn)key；單純?cè)黾臃謪^(qū)數(shù)無(wú)法解決傾斜；serializer僅影響序列化性能。8.在Presto0.28查詢(xún)Iceberg表時(shí)，若要利用分區(qū)裁剪，WHERE條件必須包含：A.分區(qū)列的等值或范圍過(guò)濾B.任意列的LIKE過(guò)濾C.分區(qū)列的CAST表達(dá)式D.分區(qū)列的UDF包裝答案：A解析：Iceberg通過(guò)分區(qū)值元數(shù)據(jù)裁剪文件，需顯式過(guò)濾分區(qū)列；CAST或UDF會(huì)阻斷裁剪。9.某Kafka集群版本3.5，topic有6分區(qū)，Producer端acks=all，min.insync.replicas=2，當(dāng)2個(gè)broker宕機(jī)時(shí)，該topic可用性為：A.全部分區(qū)可讀寫(xiě)B(tài).部分分區(qū)可讀，不可寫(xiě)C.全部分區(qū)不可讀寫(xiě)D.部分分區(qū)可寫(xiě)，不可讀答案：B解析：剩余broker數(shù)=1<min.insync.replicas，ISR為空，Producer收到NOT_ENOUGH_REPLICAS，寫(xiě)入失??；但Consumer仍可拉取歷史數(shù)據(jù)。10.使用ClickHouse23.5做實(shí)時(shí)漏斗分析，最佳表引擎是：A.MergeTreeB.SummingMergeTreeC.AggregatingMergeTreeD.MaterializedView答案：C解析：AggregatingMergeTree支持預(yù)聚合狀態(tài)（如uniqCombinedState），配合物化視圖實(shí)現(xiàn)高效漏斗；MergeTree需全量掃描；Summing僅支持?jǐn)?shù)值求和。二、多項(xiàng)選擇題（每題3分，共15分。每題至少有兩個(gè)正確答案，多選、少選、錯(cuò)選均不得分）11.關(guān)于Spark3.4AdaptiveQueryExecution（AQE），以下說(shuō)法正確的是：A.運(yùn)行時(shí)可動(dòng)態(tài)合并相鄰小分區(qū)B.可自動(dòng)選擇BroadcastJoinC.需將spark.sql.adaptive.enabled設(shè)為trueD.可在任務(wù)提交前生成最終物理計(jì)劃答案：A、B、C解析：AQE在運(yùn)行時(shí)收集統(tǒng)計(jì)信息，動(dòng)態(tài)合并分區(qū)、切換Join策略；D錯(cuò)誤，AQE特性即“運(yùn)行時(shí)”優(yōu)化，非提交前。12.在Flink1.17中，以下哪些機(jī)制共同保障ExactlyOnce？A.Checkpoint屏障B.兩階段提交SinkC.Kafka事務(wù)ProducerD.Eventtime水位線答案：A、B、C解析：屏障對(duì)齊+分布式快照實(shí)現(xiàn)內(nèi)部一致性；兩階段提交+Kafka事務(wù)保證外部系統(tǒng)僅一次；水位線用于時(shí)間語(yǔ)義，與一致性無(wú)關(guān)。13.使用HDFSFederation架構(gòu)的優(yōu)勢(shì)包括：A.單NameNode內(nèi)存瓶頸緩解B.支持跨NameNode的副本自動(dòng)平衡C.客戶(hù)端需手動(dòng)指定NameSpaceD.DataNode可同時(shí)向多個(gè)NameBlockPool匯報(bào)答案：A、D解析：Federation通過(guò)多NameNode分?jǐn)傇獢?shù)據(jù)；DataNode共享存儲(chǔ)，向多池匯報(bào)；副本平衡仍在單池內(nèi)完成；客戶(hù)端通過(guò)ViewFS透明訪問(wèn)，無(wú)需手動(dòng)指定。14.關(guān)于數(shù)據(jù)湖Iceberg的隱藏分區(qū)（HiddenPartitioning），正確的是：A.用戶(hù)無(wú)需顯式寫(xiě)出分區(qū)列B.分區(qū)值由Iceberg自動(dòng)計(jì)算并寫(xiě)入元數(shù)據(jù)C.支持時(shí)間列按小時(shí)分區(qū)D.修改分區(qū)策略需重寫(xiě)全部數(shù)據(jù)答案：A、B、C解析：隱藏分區(qū)通過(guò)配置轉(zhuǎn)換函數(shù)（如hour(ts)）自動(dòng)生成分區(qū)值；修改策略?xún)H需元數(shù)據(jù)操作，無(wú)需重寫(xiě)數(shù)據(jù)。15.在構(gòu)建實(shí)時(shí)數(shù)倉(cāng)時(shí)，以下哪些技術(shù)組合可實(shí)現(xiàn)Lambda架構(gòu)的“速度層”？A.Flink+Kafka+RedisB.SparkStructuredStreaming+DeltaLakeC.Flume+HDFS+HiveD.Storm+Cassandra答案：A、B、D解析：速度層需低延遲；Flume+Hive為批線，延遲高，不適合作速度層。三、判斷題（每題1分，共10分。正確打“√”，錯(cuò)誤打“×”）16.Spark3.x的WholestageCodegen技術(shù)可將多個(gè)物理算子編譯為單段Java字節(jié)碼，從而顯著減少虛函數(shù)調(diào)用。答案：√解析：Wholestage生成手寫(xiě)風(fēng)格代碼，減少Row對(duì)象及虛函數(shù)開(kāi)銷(xiāo)，提升CPU效率。17.HBase2.5中，若使用AsyncBufferMutator批量寫(xiě)入，設(shè)置writeBufferSize=0表示禁用緩沖區(qū)。答案：×解析：writeBufferSize=0表示立即刷寫(xiě)，但緩沖區(qū)仍存在，非禁用。18.Kafka的LeaderEpoch機(jī)制可解決因Leader切換導(dǎo)致的高水位截?cái)嗖灰恢聠?wèn)題。答案：√解析：LeaderEpoch通過(guò)單調(diào)遞增的epoch+offset對(duì)，保證副本重啟后正確截?cái)唷?9.ClickHouse的ReplacingMergeTree引擎可保證查詢(xún)時(shí)自動(dòng)返回最新版本，無(wú)需FINAL關(guān)鍵字。答案：×解析：ReplacingMergeTree后臺(tái)合并才去重，查詢(xún)需顯式加FINAL或依賴(lài)聚合函數(shù)argMax。20.DeltaLake的OPTIMIZE命令在運(yùn)行時(shí)會(huì)對(duì)表加EXCLUSIVE鎖，阻塞并發(fā)寫(xiě)入。答案：√解析：OPTIMIZE重寫(xiě)文件，需排他鎖；可通過(guò)ZOrdering減少重寫(xiě)范圍，但鎖仍存在。21.Flink的Savepoint與Checkpoint底層格式完全一致，可直接互換使用。答案：×解析：Savepoint含更多元數(shù)據(jù)（如算子ID），且不支持增量；格式不兼容。22.Hive3.0引入的LLAP（LowLatencyAnalyticalProcessing）通過(guò)守護(hù)進(jìn)程緩存列數(shù)據(jù)，提升交互式查詢(xún)性能。答案：√解析：LLAP在YARN容器外長(zhǎng)期存活，緩存+索引+向量化，降低延遲。23.Presto的CostbasedOptimizer（CBO）需手動(dòng)運(yùn)行ANALYZE收集統(tǒng)計(jì)信息，否則無(wú)法使用。答案：√解析：PrestoCBO依賴(lài)表/列統(tǒng)計(jì)，缺失時(shí)回退規(guī)則優(yōu)化。24.在SparkStructuredStreaming中，Watermark延遲時(shí)間必須大于或等于Trigger間隔，否則可能丟數(shù)據(jù)。答案：×解析：Watermark與Trigger無(wú)強(qiáng)制大小關(guān)系；延遲小于Trigger會(huì)導(dǎo)致窗口提前關(guān)閉，但非必然丟數(shù)據(jù)。25.Hudi的Clustering操作可將小文件合并并排序，同時(shí)更新對(duì)應(yīng)列統(tǒng)計(jì)索引。答案：√解析：Clustering重寫(xiě)文件布局，同步更新col_stats索引，加速查詢(xún)。四、填空題（每空2分，共20分）26.在Spark3.4中，通過(guò)設(shè)置spark.sql.adaptive.coalescePartitions.minPartitionNum=____，可控制AQE合并后的最小分區(qū)數(shù)，避免過(guò)度合并導(dǎo)致并行度不足。答案：1解析：設(shè)為1表示允許合并到單個(gè)分區(qū)，但通常結(jié)合集群核數(shù)設(shè)為200~400。27.Flink1.17的Checkpoint超時(shí)參數(shù)____默認(rèn)值為10分鐘，若作業(yè)狀態(tài)過(guò)大需調(diào)大。答案：checkpoint.timeout解析：超時(shí)未完成會(huì)觸發(fā)失敗策略，影響可用性。28.Kafka3.5的__tocol.version__參數(shù)用于控制Broker間通信協(xié)議版本，滾動(dòng)升級(jí)時(shí)應(yīng)先升級(jí)代碼再提升該版本。答案：tocol.version解析：保證新舊Broker兼容，避免協(xié)議不匹配。29.HDFS的____命令可顯示塊與DataNode的映射關(guān)系，常用于排查塊缺失。答案：hdfsfsckblockslocations解析：fsck輸出塊ID、主機(jī)列表，定位損壞。30.ClickHouse的____引擎支持主鍵稀疏索引，按mark_number定位granule，實(shí)現(xiàn)跳表掃描。答案：MergeTree解析：MergeTree家族共享稀疏索引機(jī)制。31.DeltaLake的____文件記錄事務(wù)日志，采用JSON格式，按序遞增。答案：_delta_log解析：_delta_log目錄下.json文件構(gòu)成時(shí)間旅行基礎(chǔ)。32.Iceberg的____元數(shù)據(jù)表可查看所有數(shù)據(jù)文件的路徑、分區(qū)值及記錄數(shù)。答案：files解析：SELECTFROMcatalog.db.table.files提供文件級(jí)洞察。33.Presto的____函數(shù)可將JSON字符串轉(zhuǎn)為MAP(VARCHAR,JSON)，用于半結(jié)構(gòu)化分析。答案：json_parse解析：json_parse返回JSON類(lèi)型，可進(jìn)一步CAST成MAP。34.Spark3.4的____特性可在Driver端捕獲SQLUI的Plan圖，生成SVG文件離線查看。答案：spark.sql.planChangeLog.level=WARN解析：結(jié)合spark.sql.planChangeLog.buffersize輸出圖。35.Hudi的____視圖類(lèi)型提供讀優(yōu)化查詢(xún)，僅暴露列式基文件，延遲最低。答案：ReadOptimized解析：對(duì)比Snapshot視圖，跳過(guò)log文件，犧牲實(shí)時(shí)性。五、簡(jiǎn)答題（每題10分，共30分）36.某互聯(lián)網(wǎng)公司使用Flink1.17消費(fèi)Kafka，進(jìn)行10分鐘滾動(dòng)窗口UV計(jì)算，結(jié)果寫(xiě)入Redis。上線后發(fā)現(xiàn)窗口結(jié)束時(shí)UV值偶現(xiàn)跳變，請(qǐng)分析可能原因并給出排查步驟與解決方案。答案與解析：原因：（1）Kafka分區(qū)消費(fèi)延遲不均：某并發(fā)Subtask消費(fèi)滯后，導(dǎo)致窗口觸發(fā)時(shí)部分?jǐn)?shù)據(jù)未到達(dá)；（2）Watermark生成策略過(guò)于激進(jìn)，使用ProcessingTime語(yǔ)義而非EventTime，遲到數(shù)據(jù)被丟棄；（3）Redis寫(xiě)入未做冪等，同一窗口多次觸發(fā)（如allowedLateness>0）導(dǎo)致累加；（4）Checkpoint與窗口觸發(fā)競(jìng)爭(zhēng)，作業(yè)失敗后從Checkpoint恢復(fù)，窗口狀態(tài)重復(fù)計(jì)算。排查步驟：1.查看FlinkWebUI的Kafkalag曲線，確認(rèn)是否存在長(zhǎng)尾Subtask；2.檢查Watermark生成代碼，是否使用BoundedOutOfOrderness且最大延遲<實(shí)際遲到時(shí)間；3.打印窗口觸發(fā)日志，對(duì)比Redis寫(xiě)入Key的TTL與窗口endtime，確認(rèn)是否重復(fù)寫(xiě)入；4.開(kāi)啟FlinkCheckpoint歷史，觀察失敗恢復(fù)點(diǎn)與窗口觸發(fā)時(shí)間是否重疊。解決方案：a.調(diào)大Watermark延遲至業(yè)務(wù)可容忍的最大亂序時(shí)間；b.使用EventTime+allowedLateness(1min)+sideOutput，將超遲數(shù)據(jù)旁路輸出，避免跳變；c.Redis寫(xiě)入采用SETNXEX命令，窗口ID作為Key，確保冪等；d.啟用ExactlyOnceSink，如Redisson+Redis事務(wù)或Flink兩階段提交；e.對(duì)Kafka分區(qū)做keyBy重組，避免數(shù)據(jù)傾斜導(dǎo)致的滯后。37.描述如何使用Spark3.4+DeltaLake2.3構(gòu)建近實(shí)時(shí)數(shù)倉(cāng)的MERGEINTOpipeline，要求支持CDC變更、分區(qū)自動(dòng)合并、歷史版本回滾，并給出核心代碼片段與調(diào)優(yōu)參數(shù)。答案與解析：架構(gòu)：MySQL→Debezium→Kafka→SparkStructuredStreaming→DeltaLake→BI核心代碼：```scalavaldeltaTable=DeltaTable.forPath(spark,"/data/ods_user")streamDF.writeStream.format("delta").outputMode("append").option("checkpointLocation","/check/ods_user").trigger(Trigger.ProcessingTime("2minutes")).foreachBatch{(batch:DataFrame,batchId:Long)=>deltaTable.as("t").merge(batch.as("s"),"t.id=s.idANDt.ts<s.ts").whenMatched("s.op='DELETE'").delete().whenMatched().updateAll().whenNotMatched().insertAll().execute()}.start()```調(diào)優(yōu)參數(shù)：spark.sql.files.maxRecordsPerFile=10000000//控制單文件大小約128MBspark.databricks.delta.merge.repartitionBeforeWrite.enabled=true//避免小文件spark.databricks.delta.optimizeWrite.enabled=truespark.databricks.delta.autoCompact.enabled=truespark.sql.shuffle.partitions=800//按核數(shù)2~3歷史回滾：```sqlRESTORETABLEdelta.`/data/ods_user`VERSIONASOF892```38.某金融公司使用ClickHouse23.5做風(fēng)控明細(xì)查詢(xún)，表結(jié)構(gòu)為(Replicated)MergeTree，按event_time分區(qū)，主鍵(user_id,event_time)?，F(xiàn)發(fā)現(xiàn)查詢(xún)某用戶(hù)最近30天記錄耗時(shí)5秒，請(qǐng)給出全鏈路優(yōu)化方案，目標(biāo)<500ms。答案與解析：瓶頸分析：1.分區(qū)過(guò)多：按天分區(qū)導(dǎo)致30個(gè)分區(qū)，并行掃描開(kāi)銷(xiāo)大；2.主鍵排序鍵不合理：event_time放末尾，無(wú)法利用跳數(shù)索引；3.未使用采樣或投影；4.磁盤(pán)為HDD，隨機(jī)讀高；5.查詢(xún)語(yǔ)句未加limit，返回?cái)?shù)千萬(wàn)行。優(yōu)化步驟：（1）改分區(qū)策略：改用toYYYYMM(event_time)月分區(qū)，減少分區(qū)數(shù)至1；（2）調(diào)整排序鍵：(user_id,toStartOfHour(event_time),event_time)，確保user_id在前，事件時(shí)間有序；（3）添加跳數(shù)索引：```sqlALTERTABLErisk.eventsADDINDEXidx_userTYPEbloom_filterGRANULARITY3```（4）啟用prewhere自動(dòng)下推：setoptimize_move_to_prewhere=1；（5）建物化視圖做預(yù)聚合：```sqlCREATEMATERIALIZEDVIEWrisk.events_mvENGINE=SummingMergeTreePARTITIONBYtoYYYYMM(event_time)ORDERBY(user_id,toStartOfDay(event_time))ASSELECTuser_id,toStartOfDay(event_time)asday,count()ascnt,sum(amount)assum_amtFROMrisk.eventsGROUPBYuser_id,day```（6）硬件升級(jí)：SSDNVMe，提高隨機(jī)讀至1GB/s；（7）查詢(xún)改寫(xiě)：```sqlSELECTFROMrisk.eventsWHEREuser_id=123ANDevent_time>=now()INTERVAL30DAYORDERBYevent_timeDESCLIMIT1000SETTINGSmax_threads=8,max_memory_usage=10000000000```經(jīng)測(cè)試，QPS由5s降至380ms，滿(mǎn)足SLA。六、綜合應(yīng)用題（共25分）39.某市政府搭建城市大腦項(xiàng)目，需整合交通、氣象、輿情三類(lèi)數(shù)據(jù)，日均增量5TB，峰值QPS8萬(wàn)，要求秒級(jí)預(yù)警、分鐘級(jí)分析、永久保存原始數(shù)據(jù)。請(qǐng)?jiān)O(shè)計(jì)端到端大數(shù)據(jù)架構(gòu)，涵蓋采集、存儲(chǔ)、計(jì)算、治理、可視化、安全、容災(zāi)七個(gè)維度，給出技術(shù)選型、部署拓?fù)?、關(guān)鍵參數(shù)、成本估算，并論證為何淘汰Lambda架構(gòu)。答案與解析：1)采集層：?交通：MQTT網(wǎng)關(guān)+FlinkCDC接入信號(hào)機(jī)日志；?氣象：RESTful爬蟲(chóng)+KafkaConnect；?輿情：Flume監(jiān)聽(tīng)微博API→Kafka。統(tǒng)一Topic命名：{source}.{biz}.{ds}，保留3天，壓縮LZ4。