2025年大數(shù)據(jù)工程師大數(shù)據(jù)處理技術(shù)檢驗(yàn)考試試題及答案解析一、單項(xiàng)選擇題（每題2分，共20分）1.在Hadoop生態(tài)中，負(fù)責(zé)集群資源統(tǒng)一管理與調(diào)度的組件是A.HDFS??B.YARN??C.MapReduce??D.Hive答案：B解析：YARN（YetAnotherResourceNegotiator）將資源管理與作業(yè)調(diào)度/監(jiān)控分離，成為Hadoop2.x后的核心。2.Spark中下列哪一類(lèi)操作會(huì)觸發(fā)Job提交A.map??B.filter??C.reduceByKey??D.persist答案：C解析：reduceByKey屬于行動(dòng)（Action）操作，會(huì)觸發(fā)DAG調(diào)度器生成Job；map、filter為轉(zhuǎn)換（Transformation）操作，僅構(gòu)建DAG。3.Kafka保證分區(qū)有序性的機(jī)制是A.消費(fèi)者組再均衡??B.分區(qū)副本同步??C.每條消息順序追加寫(xiě)日志??D.零拷貝傳輸答案：C解析：同一分區(qū)內(nèi)消息按追加順序?qū)懭罩疚募?，消費(fèi)者按偏移量順序拉取，天然有序。4.Flink的Checkpoint機(jī)制基于哪種分布式快照算法A.TwoPhaseCommit??B.ChandyLamport??C.Paxos??D.Raft答案：B解析：Flink采用異步屏障快照（ABS）實(shí)現(xiàn)ChandyLamport分布式快照，保證ExactlyOnce。5.在HDFS寫(xiě)入流程中，客戶端首先請(qǐng)求A.DataNode列表??B.塊報(bào)告??C.租約恢復(fù)??D.名稱節(jié)點(diǎn)分配新塊答案：D解析：客戶端通過(guò)RPC請(qǐng)求NameNode分配新塊，NameNode返回可寫(xiě)入的DataNode管線。6.使用Parquet格式存儲(chǔ)的最大優(yōu)勢(shì)是A.支持事務(wù)??B.列式壓縮與謂詞下推??C.高并發(fā)寫(xiě)??D.支持Update語(yǔ)法答案：B解析：Parquet采用列存，壓縮比高，且支持列裁剪、謂詞下推，顯著減少磁盤(pán)IO。7.下列關(guān)于數(shù)據(jù)傾斜描述正確的是A.只會(huì)發(fā)生在Reduce階段??B.可通過(guò)兩階段聚合緩解??C.與分區(qū)函數(shù)無(wú)關(guān)??D.增加節(jié)點(diǎn)可徹底解決答案：B解析：兩階段聚合（局部聚合+全局聚合）可將熱點(diǎn)Key拆散，降低傾斜。8.HBase中用于實(shí)現(xiàn)多版本并發(fā)控制的維度是A.Column??B.Timestamp??C.Rowkey??D.Region答案：B解析：同一單元格可保留多版本，以timestamp區(qū)分，默認(rèn)按降序存儲(chǔ)。9.在SparkSQL中，將DataFrame注冊(cè)為全局臨時(shí)視圖的API是A.createTempView??B.createOrReplaceTempView??C.createGlobalTempView??D.registerTable答案：C解析：createGlobalTempView把視圖注冊(cè)到系統(tǒng)數(shù)據(jù)庫(kù)global_temp，跨SparkSession可見(jiàn)。10.若Flink作業(yè)并行度為6，KafkaTopic分區(qū)數(shù)為3，則消費(fèi)該Topic時(shí)默認(rèn)并發(fā)度為A.3??B.6??C.2??D.18答案：A解析：FlinkKafkaSource并發(fā)度不能超過(guò)分區(qū)數(shù)，否則有空閑Subtask，故取min(并行度,分區(qū)數(shù))=3。二、多項(xiàng)選擇題（每題3分，共15分；多選少選均不得分）11.以下屬于Hive支持的文件存儲(chǔ)格式有A.TextFile??B.ORC??C.Avro??D.JSON??E.SequenceFile答案：ABCE解析：Hive原生支持Text/ORC/Avro/SequenceFile，JSON需借助SerDe，非原生“格式”。12.關(guān)于SparkRDD的窄依賴，正確的有A.父RDD每個(gè)分區(qū)最多被子RDD一個(gè)分區(qū)使用??B.支持流水線執(zhí)行??C.發(fā)生故障只需重算丟失分區(qū)??D.包含groupByKey??E.包含union答案：ABCE解析：groupByKey屬于寬依賴；union為窄依賴，無(wú)shuffle。13.下列哪些指標(biāo)可直接反映Flink作業(yè)反壓A.backPressureTimeMsPerSecond??B.idleTimeMsPerSecond??C.numRecordsInPerSecond??D.checkpointDuration??E.networkBuffers答案：ABE解析：FlinkWebUI通過(guò)backPressureTimeMsPerSecond、idleTimeMsPerSecond及networkBuffers用量判斷反壓。14.在HDFS聯(lián)邦（Federation）架構(gòu)中，正確的是A.多個(gè)NameNode共享DataNode存儲(chǔ)??B.每個(gè)NameNode管理獨(dú)立命名空間??C.通過(guò)ZooKeeper實(shí)現(xiàn)HA??D.支持跨命名空間Rename??E.客戶端通過(guò)掛載表訪問(wèn)答案：ABE解析：聯(lián)邦僅拆分命名空間，DataNode共享；跨命名空間Rename不支持；HA由QJM或NFS實(shí)現(xiàn)，非ZK直接完成。15.以下屬于KafkaProducer保證冪等性的配置有A.enable.idempotence=true??B.acks=all??C.retries>0??D.max.in.flight.requests.per.connection≤5??E.compression.type=snappy答案：ABCD解析：冪等需同時(shí)滿足enable.idempotence=true、acks=all、retries>0且inflight≤5（2.4+可自動(dòng)調(diào)整）。三、填空題（每空2分，共20分）16.HDFS默認(rèn)塊大小為_(kāi)_______MB，若集群主要存儲(chǔ)海量小文件，應(yīng)________NameNode內(nèi)存。答案：128；增加解析：小文件導(dǎo)致NameNode元數(shù)據(jù)膨脹，需調(diào)大JVM堆或合并文件。17.Spark任務(wù)調(diào)度中，將Stage劃分為T(mén)ask的最小單位是________，其數(shù)量等于該Stage末層RDD的________。答案：Task；分區(qū)數(shù)解析：每個(gè)分區(qū)對(duì)應(yīng)一個(gè)Task，由TaskScheduler分發(fā)。18.Flink窗口函數(shù)中，________窗口按固定間隔滑動(dòng)，________窗口按元素?cái)?shù)量觸發(fā)。答案：滑動(dòng)；計(jì)數(shù)解析：滑動(dòng)時(shí)間窗口（SlidingTimeWindow）與計(jì)數(shù)窗口（CountWindow）為兩種典型類(lèi)型。19.Kafka消息體保存在磁盤(pán)上的文件后綴為_(kāi)_______，索引文件后綴為_(kāi)_______。答案：.log；.index解析：分區(qū)目錄下按segment存儲(chǔ)，.log存消息，.index存偏移量索引。20.在Hive中，將查詢結(jié)果寫(xiě)入本地目錄/opt/dt的語(yǔ)句需加關(guān)鍵字________與________。答案：local；directory解析：insertoverwritelocaldirectory'/opt/dt'select…21.HBase行鍵設(shè)計(jì)應(yīng)避免________熱點(diǎn)，常用手段包括________散列或反轉(zhuǎn)。答案：Region；前綴解析：?jiǎn)握{(diào)遞增Rowkey易造成Region熱點(diǎn)，加鹽或反轉(zhuǎn)可打散。22.SparkSQL的Catalyst優(yōu)化器核心步驟包括解析→________→________→代碼生成。答案：邏輯優(yōu)化；物理優(yōu)化解析：Analyzer→Optimizer→Planner→WholeStageCodegen。23.使用FlinkCEP庫(kù)檢測(cè)“連續(xù)三次登錄失敗”模式，需指定________量詞，模式名設(shè)為_(kāi)_______。答案：times(3)；loginFail解析：Pattern.begin("loginFail").where(…).times(3).within(Time.minutes(5))。24.在YARN容量調(diào)度器中，隊(duì)列資源搶占功能需開(kāi)啟參數(shù)________，搶占策略默認(rèn)為_(kāi)_______。答案：yarn.resourcemanager.scheduler.monitor.enable；proportional解析：開(kāi)啟搶占后，按比例回收超額資源。25.若Parquet文件采用字典編碼，字典頁(yè)上限條目數(shù)由參數(shù)________控制，默認(rèn)________條。答案：parquet.dictionary.page.size；1048576解析：超過(guò)閾值則自動(dòng)回退為普通編碼。四、判斷題（每題1分，共10分；正確寫(xiě)“T”，錯(cuò)誤寫(xiě)“F”）26.Spark的mapPartitionsWithIndex算子可獲取分區(qū)編號(hào)。答案：T解析：函數(shù)簽名(index,iterator)=>iterator，可訪問(wèn)index。27.HDFS支持文件隨機(jī)修改某一行。答案：F解析：HDFS一次寫(xiě)多次讀，不支持隨機(jī)修改，只能追加或重寫(xiě)。28.Flink的ProcessFunction可注冊(cè)定時(shí)器，但無(wú)法訪問(wèn)狀態(tài)。答案：F解析：ProcessFunction擁有Context，可讀寫(xiě)狀態(tài)并注冊(cè)事件/處理時(shí)間定時(shí)器。29.Kafka消費(fèi)者提交偏移量至__consumer_offsetsTopic。答案：T解析：內(nèi)部Topic保存消費(fèi)組偏移，默認(rèn)50分區(qū)。30.HiveonTez執(zhí)行引擎可將多個(gè)MR作業(yè)合并為單一DAG。答案：T解析：Tez避免中間結(jié)果落盤(pán)，提升性能。31.在SparkStreaming中，DStream的foreachRDD運(yùn)行在Driver端。答案：T解析：foreachRDD為輸出操作，函數(shù)體在Driver執(zhí)行，可再對(duì)RDD調(diào)用行動(dòng)操作。32.HBase的RegionServer宕機(jī)后，其負(fù)責(zé)的所有Region立即不可用。答案：F解析：ZooKeeper檢測(cè)到宕機(jī)，HMaster觸發(fā)恢復(fù)，Region在10–30秒內(nèi)重新上線。33.ORC文件中的StripeFooter保存列統(tǒng)計(jì)信息，用于謂詞下推。答案：T解析：StripeFooter包含列級(jí)min/max、sum、nullcount等，加速掃描。34.Flink的Checkpoint屏障（Barrier）由Source算子注入。答案：T解析：Source在數(shù)據(jù)流中周期性地插入Barrier，觸發(fā)分布式快照。35.使用Spark的repartition(1)后，數(shù)據(jù)傾斜問(wèn)題一定解決。答案：F解析：repartition(1)將數(shù)據(jù)合并為單分區(qū)，可能引入新熱點(diǎn)，且并行度驟降。五、簡(jiǎn)答題（共35分）36.（封閉型，8分）描述MapReduce作業(yè)從提交到結(jié)束的完整生命周期，并指出YARN在此過(guò)程中的作用。答案：1)客戶端向ResourceManager(RM)申請(qǐng)作業(yè)ID；2)客戶端將作業(yè)資源（jar、切片信息、配置）上傳至HDFS；3)RM在NodeManager(NM)上啟動(dòng)ApplicationMaster(AM)；4)AM向RM注冊(cè)并請(qǐng)求資源容器；5)RM分配容器后，AM在對(duì)應(yīng)NM啟動(dòng)YARNChild進(jìn)程執(zhí)行Map/Reduce任務(wù)；6)任務(wù)通過(guò)心跳向AM匯報(bào)進(jìn)度；7)作業(yè)完成后AM向RM注銷(xiāo)，釋放資源。YARN作用：統(tǒng)一資源管理與調(diào)度，解耦計(jì)算框架與基礎(chǔ)設(shè)施，實(shí)現(xiàn)多租戶共享集群。37.（開(kāi)放型，10分）某電商公司每日產(chǎn)生500GB用戶行為日志，需實(shí)時(shí)計(jì)算5分鐘滑動(dòng)窗口內(nèi)的UV，請(qǐng)給出基于Flink的端到端技術(shù)方案，含數(shù)據(jù)源、維表關(guān)聯(lián)、去重策略、狀態(tài)后端、Checkpoint配置及結(jié)果輸出，并說(shuō)明如何保障ExactlyOnce。答案：數(shù)據(jù)源：KafkaTopicbehavior，分區(qū)60，保留3天。維表：MySQL存儲(chǔ)用戶畫(huà)像，通過(guò)Flink異步I/O（AsyncDataStream）關(guān)聯(lián)，緩存5秒TTL。去重：采用ValueState保存Bitmap（RoaringBitmap），key為window_end，value為uidBitmap；窗口觸發(fā)時(shí)輸出基數(shù)。狀態(tài)后端：RocksDBStateBackend，增量Checkpoint，10MB閾值，開(kāi)啟本地恢復(fù)。Checkpoint：間隔1分鐘，超時(shí)3分鐘，最大并發(fā)1，啟用對(duì)齊超時(shí)5秒，失敗時(shí)作業(yè)不重啟。輸出：ClickHouse本地表，使用ReplacingMergeTree，按(window_end,uid)去重。ExactlyOnce保障：1)KafkaSource開(kāi)啟checkpoint，提交偏移量至CKP；2)ClickHouseSink采用TwoPhaseCommit，預(yù)提交數(shù)據(jù)寫(xiě)入臨時(shí)分區(qū)，CKP完成時(shí)原子move；3)若CKP失敗，作業(yè)回滾至最近一次成功快照，臨時(shí)分區(qū)數(shù)據(jù)未對(duì)外可見(jiàn)。38.（封閉型，7分）寫(xiě)出SparkSQL中Bucket與Sort合并優(yōu)化的兩個(gè)必要條件，并解釋其如何減少Shuffle。答案：條件：1)兩表joinkey與bucketkey完全一致；2)兩表bucket數(shù)量成倍數(shù)關(guān)系且sortkey與joinkey相同。原理：a)相同bucketkey的數(shù)據(jù)已位于同一節(jié)點(diǎn)，無(wú)需再按joinkeyshuffle；b)每個(gè)bucket內(nèi)部已按sortkey排序，可直接使用SortMergeJoin，避免額外排序階段；結(jié)果：Shuffle數(shù)據(jù)量降為0，僅傳輸少量統(tǒng)計(jì)信息。39.（開(kāi)放型，10分）某HBase表存儲(chǔ)訂單數(shù)據(jù)，Rowkey設(shè)計(jì)為“userId_timestamp”，查詢場(chǎng)景包括：A.單用戶最近10筆訂單；B.單用戶某時(shí)間段訂單；C.全表統(tǒng)計(jì)每日訂單量。請(qǐng)指出當(dāng)前Rowkey導(dǎo)致的瓶頸，并給出三種改進(jìn)方案，分別說(shuō)明優(yōu)缺點(diǎn)。答案：瓶頸：userId遞增，同一用戶數(shù)據(jù)集中，Region熱點(diǎn)；且全表掃描需過(guò)濾大量無(wú)關(guān)行。方案1：Rowkey=userId_reverse(timestamp)優(yōu)：將最近數(shù)據(jù)分散到不同Region，寫(xiě)熱點(diǎn)緩解；缺：范圍掃描需客戶端拼接reverse區(qū)間，實(shí)現(xiàn)復(fù)雜。方案2：Rowkey=shard(2位)+userId+timestamp，shard=userId%100優(yōu)：預(yù)分區(qū)100個(gè)Region，寫(xiě)壓力均勻；缺：同一用戶數(shù)據(jù)分散，場(chǎng)景A需并發(fā)100次掃描再歸并，讀放大。方案3：保留原Rowkey，增加預(yù)分區(qū)+salting，同時(shí)建二級(jí)索引表，索引key=date+userId+origRowkey優(yōu)：寫(xiě)熱點(diǎn)消除，支持按日期統(tǒng)計(jì)；缺：雙寫(xiě)帶來(lái)一致性問(wèn)題，需維護(hù)索引，寫(xiě)入延遲增加10%。六、應(yīng)用題（共50分）40.（計(jì)算類(lèi)，15分）某Spark作業(yè)讀取HDFS上1TB文本文件（每行64字節(jié)），執(zhí)行wordcount后輸出到HDFS，集群配置：200節(jié)點(diǎn)，每節(jié)點(diǎn)16核64GB，HDFS塊大小256MB，副本數(shù)2。(1)計(jì)算輸入切片數(shù)；(2)若設(shè)置spark.sql.shuffle.partitions=800，估算Shuffle寫(xiě)磁盤(pán)數(shù)據(jù)量；(3)指出可能的性能瓶頸并提出兩項(xiàng)調(diào)優(yōu)措施。答案：(1)切片數(shù)=1TB/256MB≈4096個(gè)Map任務(wù)；(2)假設(shè)唯一單詞數(shù)1億，平均單詞長(zhǎng)度7字符，排序索引額外開(kāi)銷(xiāo)30%，則Shuffle數(shù)據(jù)≈1億×(7+8+4)×1.3≈2.47GB，其中8為count長(zhǎng)整型，4為哈希指針；(3)瓶頸：小文件過(guò)多導(dǎo)致任務(wù)啟動(dòng)開(kāi)銷(xiāo)；Shuffle文件數(shù)800×200=16萬(wàn)，隨機(jī)讀放大。調(diào)優(yōu)：a)合并小文件，讀取前運(yùn)行coalesce(2048)減少M(fèi)ap任務(wù)；b)開(kāi)啟spark.shuffle.service.enabled，使用ExternalShuffleService，降低Executor磁盤(pán)壓力；c)提高press=true，采用zstd壓縮，減少寫(xiě)放大。41.（分析類(lèi)，15分）給出一段FlinkSQL連續(xù)查詢：CREATETABLEsource_kafka(user_idSTRING,priceINT,proc_timeASPROCTIME())WITH(...);CREATETABLEsink_mysql(user_idSTRINGPRIMARYKEY,total_priceBIGINT)WITH(...);INSERTINTOsink_mysqlSELECTuser_id,SUM(price)astotal_priceFROMsource_kafkaGROUPBYuser_id;運(yùn)行后發(fā)現(xiàn)MySQL結(jié)果行數(shù)持續(xù)增長(zhǎng)，而非預(yù)期“每個(gè)用戶一行”。請(qǐng)分析原因并給出修正方案。答案：原因：未定義更新策略，F(xiàn)link將每條增量聚合結(jié)果作為Append模式寫(xiě)入，MySQL主鍵沖突后插入新行，導(dǎo)致重復(fù)。修正：1)在sink_mysql表定義增加'updatemode'='upsert'；2)源表增加watermark定義，使用窗口或聲明changelog；3)若需實(shí)時(shí)累計(jì)，則sink主鍵必須唯一，F(xiàn)linkSQL需使用upsertkafkaconnector或Ret