2025年大數(shù)據(jù)考試試題及答案1.單項選擇題（每題2分，共20分）1.1在Hadoop生態(tài)中，負責資源管理與任務調(diào)度的組件是A.HDFS?B.YARN?C.MapReduce?D.Hive答案：B1.2下列哪種存儲格式最節(jié)省磁盤空間且支持謂詞下推A.JSON?B.CSV?C.ORC?D.SequenceFile答案：C1.3SparkCore默認的序列化方式是A.JavaSerializable?B.Kryo?C.ProtocolBuffers?D.Avro答案：A1.4在Flink的時間語義中，EventTime依賴于A.系統(tǒng)時鐘?B.數(shù)據(jù)自帶時間戳?C.攝取時間?D.處理時間答案：B1.5若某電商表user_order(order_id,user_id,amount,order_time)需要按user_id做分桶，同時按order_time做范圍分區(qū)，最合適的Hive建表方式是A.CLUSTEREDBY(user_id)SORTEDBY(order_time)?B.PARTITIONEDBY(order_time)CLUSTEREDBY(user_id)C.DISTRIBUTEBY(user_id)SORTBY(order_time)?D.CLUSTEREDBY(order_id)INTO256BUCKETS答案：B1.6在Kafka2.8之后，若將__consumer_offsets的副本因子設(shè)置為3，則最少需要多少臺物理機才能保證高可用A.1?B.2?C.3?D.4答案：C1.7使用HBaseRowkey設(shè)計避免熱點，下列方案無效的是A.反轉(zhuǎn)時間戳?B.加鹽隨機前綴?C.哈希散列?D.自增ID答案：D1.8在Presto中，下列SQL語句能被CBO優(yōu)化器自動改寫的是A.SELECTFROMtWHERErand()<0.1?B.SELECTcount()FROMtGROUPBYuser_idHAVINGcount()>100C.SELECTFROMtJOIN(SELECTmax(dt)FROMt)tmpONt.dt=tmp.dt?D.SELECTFROMtORDERBYrand()LIMIT10答案：C1.9某集群每日新增原始日志2TB，壓縮比1:5，保留30天，采用三副本，則存儲量約為A.12TB?B.36TB?C.60TB?D.360TB答案：B1.10在數(shù)據(jù)湖Iceberg中，實現(xiàn)行級更新需要依賴A.CopyonWrite?B.MergeonRead?C.WriteAheadLog?D.LSMTree答案：B2.多項選擇題（每題3分，共15分，多選少選均不得分）2.1下列屬于FlinkCheckpoint持久化到HDFS的必要配置A.state.backend?B.state.checkpoints.dir?C.jobmanager.execution.failoverstrategy?D.erval答案：ABD2.2關(guān)于數(shù)據(jù)傾斜，正確的說法有A.可以通過兩階段聚合緩解?B.必然導致OOM?C.SparkSQL可用hints指定分發(fā)鍵?D.Hive可用skewjoin優(yōu)化答案：ACD2.3在ClickHouse中，MergeTree引擎支持A.主鍵索引?B.數(shù)據(jù)分區(qū)?C.數(shù)據(jù)副本?D.事務回滾答案：ABC2.4下列算法可用于文本主題聚類A.Kmeans?B.LDA?C.DBSCAN?D.Word2Vec答案：ABC2.5關(guān)于數(shù)據(jù)血緣，技術(shù)實現(xiàn)層面可采集A.SQL解析?B.日志埋點?C.字節(jié)碼注入?D.Gitdiff答案：ABC3.填空題（每空2分，共20分）3.1SparkRDD的五大特性中最能體現(xiàn)容錯的是________。答案：血統(tǒng)關(guān)系（Lineage）3.2在HDFS寫數(shù)據(jù)時，客戶端首先與________節(jié)點通信獲取block位置。答案：NameNode3.3KafkaProducer保證冪等性需要設(shè)置參數(shù)________為true。答案：enable.idempotence3.4若某表在Hive中以dt為分區(qū)，則SQL語句SELECTFROMtWHEREdtBETWEEN'20250601'AND'20250607'會觸發(fā)________分區(qū)裁剪。答案：動態(tài)3.5FlinkCEP庫中，模式序列后跟.oneOrMore表示________量詞。答案：貪婪3.6在數(shù)據(jù)治理評級國標GB/T360732018中，數(shù)據(jù)質(zhì)量評價維度不包括________（答任意一個非維度詞）。答案：可回溯（或其他非官方維度）3.7使用Zookeeper實現(xiàn)Leader選舉，臨時節(jié)點類型為________。答案：EPHEMERAL_SEQUENTIAL3.8在Presto中，計算精確去重需使用聚合函數(shù)________。答案：count(DISTINCT)3.9在SparkStructuredStreaming中，將連續(xù)處理模式切換為微批需設(shè)置參數(shù)________。答案：trigger(ProcessingTime)3.10數(shù)據(jù)湖三劍客通常指Delta、Iceberg與________。答案：Hudi4.判斷題（每題1分，共10分，正確寫“T”，錯誤寫“F”）4.1ORC文件一旦寫入便不可追加。答案：T4.2Flink的keyBy等價于SQL的GROUPBY。答案：F4.3HBase中列族數(shù)量越多，隨機讀性能越高。答案：F4.4在SparkMLlib中，ALS算法只能處理顯式反饋。答案：F4.5Kafka的partition數(shù)只能增加不能減少。答案：T4.6HiveonTez執(zhí)行計劃比HiveonMR默認減少磁盤落地次數(shù)。答案：T4.7ClickHouse的JOIN默認采用hashjoin算法。答案：T4.8數(shù)據(jù)倉庫分層中，DWD層應保持與源系統(tǒng)同構(gòu)。答案：F4.9GBDT算法對特征縮放敏感。答案：F4.10在數(shù)據(jù)治理中，主數(shù)據(jù)管理僅關(guān)注主鍵唯一性。答案：F5.簡答題（封閉型，每題6分，共18分）5.1簡述MapReduce中Shuffle階段的三次排序及其作用。答案：第一次排序發(fā)生在map端溢寫時，按分區(qū)號升序、key升序排序，保證同一分區(qū)數(shù)據(jù)相鄰；第二次排序在reduce端合并溢寫文件時，再次按key排序，使得reduce函數(shù)接收有序輸入；第三次排序在reduce函數(shù)內(nèi)部，若使用二次排序（GroupingComparator），可對復合key進一步排序，實現(xiàn)自定義分組邏輯，提升迭代計算效率。5.2列舉SparkSQL實現(xiàn)列式掃描的三種優(yōu)化技術(shù)并一句話說明原理。答案：1.向量化讀?。阂淮涡越鈮翰⒔獯a一批行，降低CPU消耗；2.列索引跳過：利用Parquet/Orc的列統(tǒng)計信息跳過無關(guān)rowgroup；3.謂詞下推：將過濾條件推至存儲層，減少IO。5.3寫出Flink實現(xiàn)端到端exactlyonce語義的兩條核心機制。答案：1.分布式快照機制：通過barrier對齊，定期將算子狀態(tài)異步寫入共享存儲；2.兩階段提交：預提交階段將結(jié)果寫入外部系統(tǒng)但不提交，待checkpoint完成后再統(tǒng)一提交，失敗則回滾。6.簡答題（開放型，每題8分，共16分）6.1某視頻平臺每日產(chǎn)生千億級播放日志，需在5分鐘內(nèi)完成實時DAU統(tǒng)計，并支持歷史回溯修正。請給出技術(shù)架構(gòu)要點并說明如何權(quán)衡時效性與準確性。答案：采用Kafka+Flink+ClickHouse架構(gòu)。日志經(jīng)Kafka按user_id分區(qū)，F(xiàn)link作業(yè)設(shè)置30秒checkpoint，使用RockDBStateBackend存儲去重bitmap，輸出每30秒粒度去重uv到ClickHouse分布式表；同時寫入Iceberg原始日志，離線Spark作業(yè)每小時回溯合并，修正因延遲到達數(shù)據(jù)造成的uv誤差。權(quán)衡：實時層容忍0.1%誤差，離線層保證100%準確，通過Iceberg的mergeonread修正，實時層不阻塞，離線層可重算。6.2某銀行核心交易系統(tǒng)計劃引入數(shù)據(jù)湖統(tǒng)一存儲歷史流水，監(jiān)管要求保存15年且不可篡改。請給出存儲方案、合規(guī)措施及成本優(yōu)化策略。答案：存儲：采用Hudi+OSS對象存儲，桶開啟WORM（一次寫入多次讀取）策略，設(shè)置合規(guī)保留鎖；數(shù)據(jù)按年分區(qū)、月桶，使用Parquet+ZSTD壓縮。合規(guī)：利用Hudi的commit時間線作為不可變?nèi)罩?，定期將commit元數(shù)據(jù)寫入?yún)^(qū)塊鏈錨定，生成哈希指紋；同時通過KMS加密，密鑰由監(jiān)管方托管。成本：冷熱分層，近一年存標準OSS，1–5年存低頻，5年以上存歸檔；采用Hudiclustering合并小文件，降低存儲碎片；對敏感字段按列加密，減少加密開銷；利用OSS回源功能，查詢歸檔數(shù)據(jù)時自動解凍，降低實時查詢成本。7.計算題（共25分）7.1（8分）某電商大促，0點瞬間并發(fā)寫入訂單表，MySQL單行大小0.5KB，預估峰值QPS20萬，持續(xù)300秒。若采用Kafka做緩沖，單partition極限吞吐10MB/s，問至少需要多少partition？答案：每秒數(shù)據(jù)量=2000000.5KB=100MB/s；單partition10MB/s，需100/10=10partition；考慮副本無額外寫入吞吐，答案10個。7.2（9分）給定用戶行為表behavior(uid,item_id,cate_id,ts)，數(shù)據(jù)量100億行，存儲為ORC，壓縮后單文件256MB，共3900個文件。現(xiàn)需統(tǒng)計每個cate_id的UV，使用SparkSQL，集群executor共400核，每個executor4核、8GB內(nèi)存。默認每task處理128MB，估算并行度并給出調(diào)優(yōu)步驟。答案：總輸入數(shù)據(jù)3900256MB≈1TB；默認split大小128MB，則maptask數(shù)≈1TB/128MB=8192；集群并發(fā)task數(shù)=400核，每核1task→400；并行度不足，需提高并發(fā)：1.調(diào)小split為64MB，task數(shù)翻倍至16384；2.調(diào)整spark.sql.shuffle.partitions=1600，使reduce并行度為1600；3.開啟AQE，將運行時小分區(qū)合并，避免過多空跑；4.啟用bloomfilter，先對cate_id做mapsidecombine，減少shuffle量。7.3（8分）某推薦模型需計算用戶向量與商品向量的余弦相似度，用戶向量u維度512，商品向量v維度512，已歸一化。若使用Spark批量計算1億用戶與100萬商品的Top50相似，估算中間結(jié)果數(shù)據(jù)量并給出降維思路。答案：中間結(jié)果若全量計算，需1e81e64字節(jié)=400PB，不可行。降維：1.采用局部敏感哈希（LSH）將512維向量映射至20位hash，分桶數(shù)2^20≈1e6，每用戶只需與同桶商品計算，候選集降至1e8100=1e10，再按相似度排序取Top50；2.使用PCA將512維降至64維，減少計算量8倍；3.引入乘積量化，將64維向量每8維聚類256中心，用code表示，相似度近似計算，內(nèi)存降約16倍；最終中間結(jié)果約1e8100504字節(jié)≈2TB，可在百核集群完成。8.綜合分析題（共26分）8.1（14分）某市交通管理局擬建設(shè)“智慧信號燈”項目，需融合出租車GPS、公交車GPS、地鐵閘機、天氣、節(jié)假日、大型活動等多源數(shù)據(jù)，實現(xiàn)區(qū)域級5分鐘粒度擁堵預測，并給出信號配時建議。請完成以下任務：（1）畫出數(shù)據(jù)鏈路圖，注明采集、傳輸、存儲、計算、應用五層。（2）給出實時特征工程方案，需包含至少三種時間窗口。（3）預測模型選型及理由。（4）給出灰度上線與效果評估方法。答案：（1）采集層：出租車GPS通過車載終端→4G→Kafkatopicgps_taxi；公交車GPS→topicgps_bus；地鐵閘機→topicmetro_flow；天氣→RESTAPI→topicweather；節(jié)假日活動→人工錄入→MySQL→CDC→topicdim_event。傳輸層：Kafka集群三副本，設(shè)置retention7天。存儲層：原始數(shù)據(jù)入Hudi數(shù)據(jù)湖，分區(qū)字段dt=yyyyMMdd/hh；特征層用ClickHouse存寬表，按region+minute分區(qū)。計算層：FlinkCEP做異常事件檢測，F(xiàn)linkSQL做5分鐘窗口聚合，輸出至Redis供API調(diào)用。應用層：WebSocket推送配時方案至信號機，同時大屏展示。（2）實時特征：1.滑動窗口5分鐘，計算區(qū)域平均速度、流量；2.跳動窗口1小時，統(tǒng)計同比、環(huán)比；3.會話窗口（gap30秒）檢測擁堵事件持續(xù)時長；4.累計窗口全天，計算日累計流量；5.天氣特征用全局窗口，每5分鐘關(guān)聯(lián)最新天氣。（3）模型：采用XGBoost回歸，輸出未來5分鐘擁堵指數(shù)；理由：特征維度<100，樣本量百萬級，樹模型可解釋性強，方便調(diào)參；同時用FlinkML在線推理，延遲<1秒。（4）灰度：選2個區(qū)共80路口，按路口隨機分實驗組（AI配時）與對照組（固定配時），持續(xù)2周；評估指標：平均通行時間下降率、停車次數(shù)下降率、擁堵指數(shù)RMSE；采用雙重差分法剔除天氣等外部因素，顯著性檢驗p<0.05視為有效。8.2（12分）某云廠商推出ServerlessSpark，按DBU（DatabricksUnit）計費，1DBU=0.4元，每DBU提供2核8GB資源，運行1小時。用戶A每日凌晨運行一批SQL，輸入數(shù)據(jù)2TB，ORC格式，默認壓縮，共需8000核時完成?，F(xiàn)給出三種優(yōu)化方案：方案甲：開啟自適應執(zhí)行（AQE），減少小分區(qū)，核時降至6000；方案乙：采用ZSTD壓縮，數(shù)據(jù)量降至1.2TB，核時降至5000；方案丙：使用物化視圖，預先聚合，輸入數(shù)據(jù)降至200GB，核時降至1200。請計算各方案單日成本，并從性價比、維護復雜度、數(shù)據(jù)新鮮度三維度給出選型建議。答案：成本：甲：6000核時÷2核/DBU=3000DBU→30000.4=1200元；乙：5000÷2=2500DBU→1000元；丙：1200÷2=600DBU→240元。選型：性價比：丙最優(yōu)，成本降低80%，且資源釋放快；維護復雜度：甲無需額外維護；乙需全局改表并重新寫入；丙需建立物化視圖、管理刷新策略，復雜度最高；數(shù)據(jù)新鮮度：甲、乙均基于原始數(shù)據(jù)，可做到T+0；丙若采用每日刷新，則延遲1天，若采用流式刷新，則延遲5分鐘，但增加流作業(yè)成本。綜合：若業(yè)務允許分鐘級延遲，選丙+流式刷新；若需絕對T+0且人力有限，選甲；若存儲費用遠高于計算，可選乙以降低后續(xù)日常計算量。9.設(shè)計題（共20分）9.1設(shè)計一套“零ETL”實時數(shù)倉方案，使業(yè)務庫MySQL的訂單表可直接在BI工具中做OLAP分析，要求：（1）延遲<30秒；（2）支持維表變更同步；（3）支持數(shù)據(jù)回滾到任意一秒；（4）給出表結(jié)構(gòu)、主鍵設(shè)計、索引、物化視圖、權(quán)限控制。答案：架構(gòu)：MySQL→Debezium→Kafka→ClickHouseMaterializedMySQL引擎→BI。表結(jié)構(gòu)：訂單表order_main(id,user_id,sku_id,price,status,create_time,update_time)主鍵id；維表dim_sku(sku_id,sku_name,cate_id)主鍵sku_id；ClickHouse中order_main使用ReplacingMergeTree，版本字段update_time，去重依據(jù)id；dim_sku使用CollapsingMergeTree，增加sign列，1表示插入、1表示刪除。索引：order_main按(dt,update_time)分區(qū)，(dt=toYYYYMM(create_time))；排序鍵(id,update_time)；維表按sku_id排序。物化視圖：創(chuàng)建MVorder_daily_aggENGINE=SummingMergeTree，按(dt,cate_id,status)聚合，列sum_price、count_star，刷新間隔10秒。數(shù)據(jù)回滾：ClickHouse提供30秒粒度快照，利用Kafkacompactedtopic保留7天，通過指定offset回放；結(jié)合GitOps保存每快照的建表語句，做到schema回滾。權(quán)限：BI層通過ClickHouse的SQLACL，列級別屏蔽price；利用RLS行級安全，僅允許查看本部門數(shù)據(jù)；Kafka層使用SASL/SCRAM，Debezium使用SSL加密。10.論述題（共16分）10.1結(jié)合“數(shù)據(jù)要素市場化”背景，論述大數(shù)據(jù)技術(shù)在數(shù)據(jù)確權(quán)、定價、交易、流通全生命周期中的作用、風險及治理對策，要求引用近兩年真實政策或案例，不少于600字。答案：2022年12月，《中共中央