據(jù)開發(fā)筆試題拆解：從日志處理到集群部署)
1. 一套校招大數(shù)據(jù)筆試題背后到底在篩什么人每年秋招季都能看到大量XX公司XX崗位筆試題在各種群里流傳。我見過太多人拿到題先問答案是什么我卻想先問一句出題人到底想通過這套題篩出什么樣的人拿iHandy2019校招大數(shù)據(jù)開發(fā)工程師這套題來說它不像社招那樣追著源碼問也不會像ACM那樣硬摳算法但它很典型地反映了一類移動互聯(lián)網公司對校招數(shù)據(jù)崗的真實期待——不是要你背出Flink源碼的細節(jié)而是要看你能不能在這個數(shù)據(jù)量級飛速膨脹的環(huán)境里用最穩(wěn)妥的技術棧把活干完、干對、干明白。iHandy是什么體量的公司做海外工具類、內容類App起家用戶量以億計日活數(shù)據(jù)千萬級甚至上億。這種業(yè)務形態(tài)決定了它的數(shù)據(jù)團隊每天面對的不是幾百MB的Excel而是源源不斷的埋點日志、業(yè)務庫Binlog、服務器監(jiān)控指標。這些數(shù)據(jù)要經過采集、清洗、入倉、建模、報表、算法特征提取這一整條鏈路任何一個環(huán)節(jié)出錯輕則報表對不上重則影響買量決策、廣告收入計算。所以筆試題目設計的核心邏輯就一句話用最小的成本判斷你有沒有生產環(huán)境的直覺。什么意思我給你拆開講。比如一道題問Spark任務的并行度怎么設置沒有生產經驗的人會默寫上跟核數(shù)一致但有經驗的人會反問數(shù)據(jù)量多少數(shù)據(jù)傾斜有沒有Shuffle分區(qū)數(shù)跟下游文件的關聯(lián)是什么這套題不是考你背參數(shù)而是考你在真實場景里會不會做權衡。再比如說日志處理。移動互聯(lián)網公司最不缺的就是日志用戶點擊、啟動、崩潰、購買行為全部以日志形式落盤。誰能在有限資源里把億級日志處理得又快又準誰就是數(shù)據(jù)團隊想要的人。這套題里如果出現(xiàn)用Java編寫Spark處理日志這類題一點都不奇怪——它就是業(yè)務場景的微縮版。從熱搜詞也能看出來大數(shù)據(jù)開發(fā)、大數(shù)據(jù)架構、Spark日志處理、集群部署、數(shù)據(jù)質量這些詞高頻出現(xiàn)說明行業(yè)對這些方向的人才需求是持續(xù)且明確的。作為校招生你不需要在每一個方向都是專家但你需要對這些詞背后的工程問題有完整的認知框架。我在后面幾節(jié)里會結合這類題目常見的幾個考察方向逐一拆解題目背后的出題意圖、答題思路以及那些老師沒教過、但面試官默認你會的行業(yè)常識。這樣你看完這篇再去做任何一家公司的大數(shù)據(jù)開發(fā)筆試題至少能知道每道題在問什么以及考官想聽什么答案。2. 從Java寫Spark處理日志看這道常青題怎么答才不丟分2.1 為什么日志處理題年年出現(xiàn)大數(shù)據(jù)校招筆試里日志處理基本是必出題。原因特別樸素日志是離數(shù)據(jù)工程師最近的數(shù)據(jù)形態(tài)。每天零點過后全公司的App用戶行為日志、業(yè)務服務日志、系統(tǒng)運行日志都會匯聚到數(shù)據(jù)平臺。你早上一來打開告警群看到的就是昨日日志處理任務運行時長超時數(shù)據(jù)產出延遲某個埋點字段解析失敗。日復一日你其實就是在跟日志較勁。所以筆試里出現(xiàn)用Java編寫Spark處理日志數(shù)據(jù)這類題本質上是把日常工作抽象成了考試題。它考察的能力很明確你會不會用Java寫Spark作業(yè)你知不知道日志數(shù)據(jù)常見的格式和坑你有沒有處理過臟數(shù)據(jù)、字段缺失、類型異常這些問題你寫的代碼有沒有生產意識比如設置合理的分區(qū)數(shù)、避免OOM、考慮增量還是全量我見過很多候選人代碼寫得挺漂亮但一跑真實數(shù)據(jù)就崩。問題不在語法在于他從來沒見過真實日志長什么樣。2.2 一道經典真題的完整答題過程假設題目是這樣的有一批用戶行為日志每一行是JSON格式包含userId、action、timestamp、pageId、deviceType等字段請用Java編寫Spark程序統(tǒng)計每天每個頁面的獨立訪客數(shù)UV和訪問次數(shù)PV結果輸出到HDFS并按PV倒序排列。很多人拿到這題直接開寫。但我想先說一句先別急著寫代碼先想清楚你會在生產環(huán)境怎么做這件事。第一步讀數(shù)據(jù)。日志放在HDFS上日期作為分區(qū)目錄比如/data/logs/dt20240601。你用Spark讀的時候是讀整個目錄還是讀具體日期生產上通常跑定時調度傳入日期參數(shù)只讀當天的分區(qū)。第二步解析。日志是JSON格式你可以在Java里用Fastjson或Jackson解析也可以用Spark自帶的from_json函數(shù)。筆試手寫代碼的話用Fastjson最直觀。第三步指標計算。PV好算每條日志count一下就行。UV要去重用approxCountDistinct還是countDistinct這里有個考點UV通常很大精確去重在數(shù)據(jù)量上來以后會非常耗時生產環(huán)境一般用HyperLogLog這類近似算法誤差在1%以內性能卻快幾個數(shù)量級。答題時說清楚這個選擇比代碼寫對更讓面試官眼前一亮。第四步結果寫出。分區(qū)數(shù)多少文件大小多少如果結果很小coalesce(1)減少小文件如果結果很大保持合理分區(qū)數(shù)。這些都是生產環(huán)境的真實考量。我給出一個可直接參考的Java版本實現(xiàn)import com.alibaba.fastjson.JSONObject; import org.apache.spark.api.java.JavaPairRDD; import org.apache.spark.api.java.JavaRDD; import org.apache.spark.sql.SparkSession; import scala.Tuple2; import java.util.Arrays; public class LogAnalyzer { public static void main(String[] args) { String inputPath args[0]; String outputPath args[1]; SparkSession spark SparkSession.builder() .appName(UserActionLogAnalyzer) .enableHiveSupport() .getOrCreate(); JavaRDDString lines spark.read().textFile(inputPath).javaRDD(); // 解析JSON過濾臟數(shù)據(jù) JavaPairRDDString, String pageUserRDD lines.mapToPair(line - { try { JSONObject obj JSONObject.parseObject(line); String pageId obj.getString(pageId); String userId obj.getString(userId); if (pageId null || userId null) { return null; } return new Tuple2(pageId, userId); } catch (Exception e) { return null; // 臟數(shù)據(jù)跳過 } }).filter(tuple - tuple ! null); // PV統(tǒng)計 JavaPairRDDString, Long pvRDD pageUserRDD .mapToPair(tuple - new Tuple2(tuple._1, 1L)) .reduceByKey(Long::sum); // UV統(tǒng)計先按(pageId, userId)去重再統(tǒng)計 JavaPairRDDString, Long uvRDD pageUserRDD .distinct() .mapToPair(tuple - new Tuple2(tuple._1, 1L)) .reduceByKey(Long::sum); // 按PV倒序排序 ListTuple2String, Long pvList pvRDD.collect(); // 實際生產用sortByKey或DataFrame API排序 // 這里簡化為輸出到文件 pvRDD.mapToPair(Tuple2::swap) .sortByKey(false) .mapToPair(Tuple2::swap) .saveAsTextFile(outputPath /pv); uvRDD.saveAsTextFile(outputPath /uv); spark.stop(); } }這段代碼在考試里夠用但我要特別說明幾個生產環(huán)境里真正重要、也是面試官真正想聽的細節(jié)一是臟數(shù)據(jù)處理。真實日志里總有幾行JSON解析失敗、userId為空、字段類型錯亂。代碼里catch (Exception e) { return null; }就是干這個的。你要能主動說出解析失敗的數(shù)據(jù)我選擇丟棄并記錄告警如果丟棄率超過閾值就要排查埋點問題這句話能體現(xiàn)你的工程思維。二是數(shù)據(jù)傾斜。熱門頁面的日志量可能是冷門頁面的成百上千倍reduceByKey時一個Key的數(shù)據(jù)量巨大會導致單個Task跑很久。生產上要預見這個問題答題時主動提到加鹽、兩階段聚合等手段會明顯加分。三是結果文件數(shù)量問題。saveAsTextFile默認分區(qū)數(shù)跟最后一個RDD的分區(qū)數(shù)一致如果最后分區(qū)數(shù)幾百個會產生幾百個小文件HDFS NameNode壓力很大下游Hive查詢也會變慢。按PV排序輸出前應該coalesce(1)或repartition(合適的數(shù)量)。能主動講出這一點的人真的不多。2.3 這類題目的延伸追問預備筆試之后通常還有面試面試官大概率會順著日志題往下追問如果日志量每天增加一倍你的作業(yè)怎么擴容如果某個字段的解析邏輯變了老數(shù)據(jù)和新數(shù)據(jù)怎么兼容如果下游報表要求凌晨6點前產出你的作業(yè)運行時間超過窗口怎么辦埋點上報的日志有延遲凌晨統(tǒng)計時還有一部分數(shù)據(jù)沒到齊怎么辦這些問題沒有標準答案但都在考察你有沒有真實面對過數(shù)據(jù)是臟的、系統(tǒng)是不完美的、時間是緊張的這三種狀態(tài)。準備面試時把歷年真題里的日志題都拿出來順著這幾個方向想一想比多刷十道算法題有用得多。3. 大數(shù)據(jù)收集與質量保證題目里最簡單、卻最能拉開差距的一塊熱搜詞里有一句很扎眼的話對于大數(shù)據(jù)而言最基本、最重要的要求就是減少錯誤、保證質量。那么大數(shù)據(jù)收集的...。這多半是某個知識平臺上的問題標題但正好戳中了校招筆試里最容易被忽視、也最能體現(xiàn)功底的考察方向。3.1 減少錯誤、保證質量在大數(shù)據(jù)場景下到底指什么很多校招生對數(shù)據(jù)質量的理解停留在數(shù)據(jù)不能錯。但到了生產環(huán)境錯有好多種我隨便列幾個數(shù)據(jù)丟采集端網絡抖動一批日志沒傳上來數(shù)據(jù)重重試機制導致同一條日志被上報了兩次數(shù)據(jù)臟客戶端版本太老埋點事件里混入了格式錯誤的內容數(shù)據(jù)晚本該昨天到的數(shù)據(jù)今天才到齊數(shù)據(jù)不一致兩個部門對同一個指標的統(tǒng)計口徑不一樣報表打架數(shù)據(jù)模型錯事實表和維度表的關聯(lián)鍵有重復導致數(shù)據(jù)膨脹筆試題如果考到數(shù)據(jù)收集大概率會從你怎么設計一套可靠的采集方案或者給你一批臟數(shù)據(jù)你怎么清洗這兩個角度切入。前者考察系統(tǒng)設計后者考察實操能力。3.2 從埋點數(shù)據(jù)看數(shù)據(jù)收集的核心鏈路移動App的數(shù)據(jù)收集鏈路大概是這樣的App端埋點 - 上報隊列 - 網關接收 - Kafka - 實時/離線清洗 - 數(shù)倉入倉筆試考這個鏈路時常見的考點包括傳輸層Kafka在鏈路里扮演什么角色Kafka的定位是削峰填谷。如果客戶端直接寫數(shù)據(jù)庫高峰期可能把庫打爆但有了Kafka這個緩沖層上游流量再大下游消費者都可以按照自己的速度消費。這道題的變體還會問Kafka掛了一個broker消息會丟嗎答案取決于副本因子配置生產環(huán)境一般設3副本允許掛2臺broker不丟數(shù)據(jù)。采集層埋點丟失怎么發(fā)現(xiàn)業(yè)界常用的做法是數(shù)量對賬?？蛻舳嗣看紊蠄笕罩緯r附帶一個event sequence number服務端可以校驗序列號連續(xù)性。離線側還可以做產出監(jiān)控比如昨天PV是1億今天突然變成8000萬監(jiān)控系統(tǒng)自動告警。筆試里你能答出兩邊對賬監(jiān)控告警兩層保障基本就過關了。清洗層臟數(shù)據(jù)怎么處理清洗規(guī)則應該寫死在ETL里而不是靠人工。比如日期字段格式不合法就置空、行為類型不在枚舉范圍內就丟棄、userId為空就歸入未知用戶桶。關鍵是清洗規(guī)則要可追溯每一類被清洗掉的數(shù)據(jù)都要有統(tǒng)計和抽樣日志否則出了問題連鍋都找不到。3.3 數(shù)據(jù)質量題的答題框架面試官如果要考數(shù)據(jù)質量常見的出題方式是你們的報表數(shù)據(jù)跟業(yè)務方自己統(tǒng)計的對不上怎么排查這是一個典型的排查思路題答案可以套用一套固定鏈路先對齊統(tǒng)計口徑。是不是兩邊對活躍用戶的定義不同一邊算啟動過App就算活躍另一邊算有過頁面瀏覽行為才算活躍再對齊時間口徑。一個按東八區(qū)算天另一個按UTC算天數(shù)據(jù)對不上太正常了。第三步查數(shù)據(jù)鏈路。一邊從實時數(shù)倉讀一邊從離線數(shù)倉讀兩邊底層數(shù)據(jù)不一致結果必然不一致。實時和離線的數(shù)據(jù)質量本身就可能不同。第四步是真的查Bug?？纯碋TL代碼有沒有更新后沒測出問題、有沒有上游表結構變更導致下游解析失敗。這個框架的價值在于它向面試官證明你不是上來就翻代碼而是有系統(tǒng)性的排查方法。我在實際工作中處理過太多數(shù)據(jù)對不上的問題超過一半最后查出來是口徑問題不是程序Bug。3.4 關于串口屏往數(shù)據(jù)記錄控件添加一條內容添加不全的延伸思考熱搜詞里有個很特別的問題廣州大彩串口屏往數(shù)據(jù)記錄控件添加一條內容添加不全。乍一看這跟主流大數(shù)據(jù)八竿子打不著。但這類問題恰恰反映了物聯(lián)網/嵌入式場景下小數(shù)據(jù)的常見故障——不是大數(shù)據(jù)量級是大數(shù)據(jù)鏈路最前端的采集環(huán)節(jié)。如果你有幸面試的是一家做IoT數(shù)據(jù)平臺的公司這類問題就可能以場景題出現(xiàn)設備端上報的數(shù)據(jù)不完整你怎么定位是設備端問題、網關問題還是平臺解析問題排查思路其實是相通的先在鏈路各節(jié)點加日志和數(shù)據(jù)快照然后做分段對比找到第一個數(shù)據(jù)變短的節(jié)點再針對該節(jié)點的處理邏輯做代碼審查。這個方法論跟處理幾億條日志數(shù)據(jù)質量問題的思路一模一樣。所以別小看熱搜詞里那些犄角旮旯的關聯(lián)問題——它們反映的往往不是問題本身而是大數(shù)據(jù)從采集到應用的完整鏈條中某個環(huán)節(jié)的真實痛點。你在筆試答題時能體現(xiàn)出我理解全鏈路而不只是會寫SQL就已經跑贏大部分候選人了。4. 大數(shù)據(jù)架構和集群部署題從一套架構設計題反推復習重點4.1 大數(shù)據(jù)架構題到底在問什么校招筆試出現(xiàn)大數(shù)據(jù)架構相關的題通常不是讓你畫一張完整的Lambda架構圖而是給你一個具體場景讓你選技術方案。常見問法是這樣的業(yè)務方需要實時看到今天的銷售額又要支持昨天之前的歷史數(shù)據(jù)分析你怎么設計數(shù)據(jù)架構數(shù)據(jù)中心每天產生10TB日志要求保留30天供分析查詢響應時間要在秒級你怎么選型數(shù)據(jù)量增長很快當前Hadoop集群磁盤使用率已經85%怎么擴容在線擴容還是冷熱分離這些題沒有唯一答案但能看出一個人有沒有完整的數(shù)據(jù)平臺認知。拿熱搜詞里那條大數(shù)據(jù)集群部署策略來說校招筆試可能會拆成幾道小題NameNode和DataNode分別部署在什么類型的機器上ZooKeeper集群最少要幾臺為什么Kafka的broker和ZooKeeper部署在一起行不行這些問題的核心只有一個——你是否理解不同組件對硬件資源的需求差異。我列一張表你在復習時可以對照著看組件主要消耗資源部署建議NameNode內存存元數(shù)據(jù)大內存機器如256GB內存SSDDataNode磁盤、I/O大容量HDD即可追求吞吐ResourceManager內存、CPU中等配置即可高可用要兩臺ZooKeeperCPU、網絡3臺或5臺小機器IO要求高Kafka Broker磁盤I/O、網絡多塊SSD做消息日志存儲HBase RegionServer內存、I/O內存要大最好配NVMe SSDFlink TaskManager內存、CPU按內存/CPU配比計算槽位數(shù)大部分校招生對這張表沒有概念或者說只記住了NameNode要內存大這句話但不知道為什么要大。NameNode把整個文件系統(tǒng)的目錄樹和文件塊位置信息都放在內存里文件數(shù)越多內存占用越大。一個文件塊默認128MB的元數(shù)據(jù)大約150字節(jié)如果是1億個文件光元數(shù)據(jù)就要15GB內存再加上堆內其他開銷和堆外內存64GB的機器都不一定夠用。這就是為什么生產環(huán)境超大集群要引入NameNode聯(lián)邦或HDFS Router來橫向擴展元數(shù)據(jù)能力。4.2 集群部署策略的考察點與答題重點集群部署題從實際操作角度來說最常見的是在線擴容和高可用配置兩個方向。在線擴容考的是你對數(shù)據(jù)均衡的理解。新增DataNode節(jié)點后HDFS不會自動把老節(jié)點數(shù)據(jù)搬到新節(jié)點需要手動執(zhí)行hdfs balancer而且balancer默認帶寬只有1MB/s需要調大參數(shù)。部署時如果不管磁盤數(shù)據(jù)平衡老節(jié)點磁盤很快被打滿新節(jié)點閑著集群整體可用容量反而下降。答題時能主動說出擴容后要關注balance這個操作細節(jié)就會顯得很有實戰(zhàn)經驗。高可用配置考的是腦裂問題的理解。Hadoop NameNode高可用依賴ZooKeeper和JournalNodeActive NameNode和Standby NameNode之間通過JournalNode同步元數(shù)據(jù)編輯日志。實際生產中可能出現(xiàn)Active節(jié)點假死網絡抖動、JVM長時間GCZooKeeper這邊判定它掛了讓Standby切換成Active但老Active其實還活著于是出現(xiàn)兩個Active——這就是腦裂。答案是靠Fencing機制舊的Active會被強制隔離SSH殺進程、或者調用隔離腳本只有確保舊Active不再使用共享資源新Active才能安全接管。校招題如果問到HA你能答出腦裂要靠Fencing機制解決這一層已經比很多工作一兩年的人強了。4.3 基于大語言模型的非結構化數(shù)據(jù)理解這類新考點最近的熱搜詞里還出現(xiàn)了一條很有意思的基于大語言模型的云盤非結構化數(shù)據(jù)理解與內容生成方法。這類技術方向放在2019年還是科幻小說但放到現(xiàn)在它已經變成了真實的數(shù)據(jù)架構考題方向。校招筆試題如果往這個方向延伸很可能不是考模型本身而是考數(shù)據(jù)架構怎么配合非結構化數(shù)據(jù)文檔、圖片、視頻怎么統(tǒng)一接入數(shù)倉對象的元數(shù)據(jù)文件類型、大小、存儲位置、所屬用戶放哪里大模型推理結果怎么回流是寫回源數(shù)據(jù)系統(tǒng)還是單獨建特征庫內容生成的結果怎么評估質量這四個問題本質上還是在考數(shù)據(jù)鏈路設計能力。你不需要真的訓過大模型但你要能說出非結構化數(shù)據(jù)要先做元數(shù)據(jù)抽取再做內容理解最后把結果回流到檢索系統(tǒng)或推薦系統(tǒng)這個閉環(huán)。面試官聽到你講出這個閉環(huán)就會知道你對技術趨勢有敏感度而且對數(shù)據(jù)架構有整體認知。4.4 Avue-Data數(shù)據(jù)大屏這類前端部署題怎么應對熱搜詞里avue-data數(shù)據(jù)大屏前端是怎么部署的也是個有意思的問題。很多人會問這是前端題關大數(shù)據(jù)什么事其實它考的是數(shù)據(jù)產品化的最后一公里。數(shù)據(jù)大屏就是把數(shù)倉里的指標通過可視化方式展示出來。筆試里如果出這類題核心考點通常是大屏數(shù)據(jù)從哪來直接查數(shù)據(jù)庫還是查預聚合的API實時大屏用WebSocket還是輪詢大屏數(shù)據(jù)量很大時前端會不會卡死要不要服務端做聚合有一次我面一個候選人他說他做過數(shù)據(jù)大屏被問到數(shù)據(jù)量到10萬條以上圖表卡頓怎么辦他沒答上來。其實答案不復雜大屏展示的是趨勢和概覽沒必要把每條明細都推到前端服務端按分鐘聚合出幾百個點就夠了。真正需要明細下鉆的再按需加載。能答到這層的人說明他考慮的不只是怎么把組件跑起來而是這個系統(tǒng)在真實量級下能不能扛住。5. 從DataX到Dinky數(shù)據(jù)集成與開發(fā)工具類題目的復習方向5.1 為什么筆試會考工具組件有熱搜詞問大數(shù)據(jù)組件dinky下載大數(shù)據(jù)集群部署策略這一類關鍵詞直指筆試中的工具題。校招筆試考工具不是為了讓你報出版本號而是考察兩件事你知道這個工具解決什么問題、在鏈路里處于什么位置你上手用過沒有遇到報錯時能不能定位大數(shù)據(jù)開發(fā)崗位日常接觸的工具有一大把數(shù)據(jù)集成有DataX、Flink CDC、Canal調度有Azkaban、DolphinScheduler、Airflow數(shù)倉建模有Hive、Spark SQL查詢引擎有Presto、Doris、ClickHouse開發(fā)輔助有Dinky這種Flink SQL開發(fā)平臺。任何一個工具拿出來都能出一套面試題但校招筆試通常只考兩類選型類和應用類。5.2 工具選型題的通用答題框架MySQL數(shù)據(jù)實時同步到數(shù)據(jù)倉庫你會用什么工具——這是典型的數(shù)據(jù)集成選型題。筆試題答這題建議按這個框架展開第一步確認需求邊界。同步是全量還是增量實時還是離線數(shù)據(jù)量多大目標庫是什么第二步列舉可選方案。全量離線可以用DataX增量實時且有主鍵變更捕獲需求用Flink CDC或Canal監(jiān)聽Binlog如果只是分鐘級延遲的準實時也可以用DataX配周期調度。第三步給出理由。比如選Flink CDC可以說它能精確讀取Binlog支持斷點續(xù)傳配合Flink的實時計算能力可以直接做清洗和寬表加工選Canal則更輕量適合單純把Binlog轉發(fā)到Kafka的場景。第四步指出風險。Binlog開啟會增加數(shù)據(jù)庫主庫的壓力大事務會導致Binlog膨脹源庫表結構變更會導致同步任務報錯這些都需要有應對預案。哪怕你沒實際配過這些工具能按這個邏輯把答案組織完整筆試這題也能拿到大部分分數(shù)。5.3 工具的坑面試官真正想問的工具題的高級考法是直接給你一個報錯場景問你怎么排查。比如DataX同步任務一直報java.sql.SQLException: Data too long for column怎么處理這個問題我在工作里真的遇到過。原因通常是源庫字符集和目標庫字符集不一致或者目標表字段長度定義比源庫小。排查思路是打開DataX日志找到具體是哪一列、哪一行的數(shù)據(jù)然后對比源表和目標表的字段定義。再比如Dinky上提交Flink SQL作業(yè)狀態(tài)一直顯示RUNNING但數(shù)據(jù)不更新這個問題的排查鏈路是先看TaskManager日志有沒有輸出再看Kafka消費組的Lag是不是為0最后看Watermark有沒有推進。如果Watermark不推進說明上游事件時間停滯要么是數(shù)據(jù)源本身沒有新數(shù)據(jù)要么是空閑數(shù)據(jù)源沒設withIdleness。能答出這個排查順序說明你對實時計算是有實操經驗的。5.4 學習工具組件的高效路徑我的建議是不要一個個工具孤立地去學按一條主鏈路串起來學。我整理了一條復習主線校招生照著走覆蓋面會比零散刷題好得多數(shù)據(jù)采集Canal/Flink CDC、DataX、Flume 消息隊列Kafka重點分區(qū)、副本、消費組、消息不丟不重 實時計算Flink重點窗口、狀態(tài)、檢查點、Watermark 離線計算Spark重點RDD/DataFrame、Shuffle、調優(yōu) 數(shù)倉存儲Hive重點分區(qū)、分桶、ORC/Parquet、小文件 查詢引擎Presto/ClickHouse/Doris重點適用場景區(qū)別 調度DolphinScheduler/Azkaban重點任務依賴、失敗重試 開發(fā)平臺Dinky重點Flink SQL開發(fā)、作業(yè)提交每一個組件先搞清楚三件事它解決什么問題、它上下游是什么、它最容易出問題的點是什么。這三個問題搞清楚了不管是筆試客觀題還是面試主觀題你都能有自己的判斷而不是死記硬背。6. 做題時的通用提分策略從會做到答得出彩6.1 大數(shù)據(jù)的題答案在權衡不在正確很多校招生做題有個習慣非黑即白必須選一個對的。但大數(shù)據(jù)開發(fā)的筆試題幾乎沒有標準答案只有更合適的方案。我給你舉一個經典例子。題目問實時計算你選Flink還是Spark Streaming很多人的回答是Flink更先進所以選Flink。但換個場景公司已有的技術棧是Spark團隊對Spark更熟實時性要求是分鐘級而不是秒級數(shù)據(jù)量也沒有大到Flink才能扛住的水平。這時候Spark Streaming就是更務實的選擇。Flink和Spark Streaming的區(qū)別維度FlinkSpark Streaming計算模型真正的流式計算微批處理延遲毫秒級秒級狀態(tài)管理原生支持狀態(tài)大依賴外部存儲狀態(tài)能力弱精確一次語義內置支持需要配合業(yè)務邏輯實現(xiàn)學習成本較高基于Spark生態(tài)熟悉你答題時應該先說我會根據(jù)場景選再把場景拆開講延遲要求、狀態(tài)規(guī)模、團隊技術棧、上下游生態(tài)。而不是一上來就宣布哪個好。能體現(xiàn)權衡思維的人分數(shù)一定高。6.2 關鍵詞敏感度訓練從題目里抓真實需求我這些年帶過不少新人發(fā)現(xiàn)一個共性做題時只看到題面看不到題面背后的業(yè)務需求。比如有一道題問有一個訪問日志表每天有幾十億條記錄需要查詢某個用戶在某個時間段內的訪問明細怎么優(yōu)化如果只看到JSON解析SQL查詢這些技術詞你就只會給出最簡單的方案。但你把關鍵詞拆開看幾十億條意味著要分區(qū)、分桶某個用戶意味著查詢條件高度選擇性強適合用分區(qū)裁剪謂詞下推某個時間段意味著時間字段應該作為分區(qū)鍵明細查詢意味著需要支持點查和范圍查可以考慮用HBase或Druid或者用ClickHouse的跳數(shù)索引。你如果平時有意識地訓練自己從題面關鍵詞反推業(yè)務場景這個能力碰到偏題怪題就不會慌。你還可以反向思考如果你是出題人你會在哪個環(huán)節(jié)埋業(yè)務陷阱6.3 答題的書面表達讓面試官一眼看到關鍵詞筆試通常有時間限制尤其是客觀題主觀題混合的卷子。主觀題答的時候我建議你用關鍵詞前置的寫法。比如題目問請簡述Flink的CheckPoint機制你不要上來就長篇大論地講原理而是先寫CheckPoint是Flink保證故障恢復后狀態(tài)一致性的核心機制核心要素包括Barrier對齊、狀態(tài)快照、State Backend、恢復流程、端到端精確一次。然后再展開講每個要素。面試官閱卷時第一眼掃到的就是這些關鍵詞你的答案在大批量卷子里就會顯得很懂。用這種方式答題還有一個額外好處即使你展開部分寫得不太完整關鍵詞已經幫你把基本分拿到手了。我當年自己校招時也是用這個方法主觀題部分從來沒低于過80%的得分率。6.4 考前必須準備的幾類萬能素材大數(shù)據(jù)開發(fā)筆試有幾類問題出現(xiàn)的概率極高我建議考前就把這幾類素材準備好說清楚你做過的一個數(shù)據(jù)項目包含數(shù)據(jù)量、技術棧、處理鏈路、遇到的最大問題、你怎么解決的、最后效果如何。這個準備充分了能應對一半以上的主觀題。說清楚Spark和Flink的區(qū)別不只是計算模型還有狀態(tài)管理、精確一次、容錯機制、適用場景。說清楚Hive和數(shù)倉的分層思想ODS、DWD、DWS、ADS每一層干什么為什么要這樣分。說清楚一條數(shù)據(jù)從產生到報表展示的全過程哪一步會發(fā)生數(shù)據(jù)問題哪一步最耗時哪一步最容易出瓶頸這四個素材準備完你會發(fā)現(xiàn)筆試主觀題基本就是素材的排列組合。與其臨時抱佛腳刷一百道題不如先把這幾個核心故事打磨成自己的標準答案。7. 寫在最后一套真題之外的備考建議回到iHandy2019校招這套題。說實話這類公司出的筆試題難度不在于題目本身有多深而在于題面很業(yè)務跟學校里教的算法操作系統(tǒng)數(shù)據(jù)庫完全是兩套話語體系。如果你還在用刷LeetCode和背操作系統(tǒng)八股的方式準備大數(shù)據(jù)崗大概率會吃大虧。我給校招生的建議是準備大數(shù)據(jù)開發(fā)崗筆試先建認知框架再填充細節(jié)。認知框架就是我在前幾節(jié)反復強調的那條鏈路——采集、傳輸、存儲、計算、調度、應用你要能閉著眼把這條鏈路畫出來并且標出每一環(huán)的主流組件和核心問題。細節(jié)填充就是把每個組件的關鍵原理、典型場景、常見故障想清楚。我自己當年面試時吃過一個虧問Kafka為什么快我只答了順序寫磁盤但面試官緊接著問順序寫為什么比隨機寫快那么多我楞住了。其實是機械硬盤尋道時間和操作系統(tǒng)頁緩存的問題這個知識點我明明學過但在面試的壓力下沒串起來。從那以后我養(yǎng)成一個習慣**學每一個技術點都問自己三個問題——它在全鏈路里的位置是什么它的核心設計解決什么問題如果它壞了會怎樣**這三個問題串起來知識就不是孤島。最后再分享一個實戰(zhàn)小技巧。如果你拿到一套歷年真題先別急著做花半小時把每道題考察的知識點標出來然后統(tǒng)計頻率。你會發(fā)現(xiàn)80%的分數(shù)集中在20%的知識點上Spark算子與調優(yōu)、Flink狀態(tài)與容錯、Kafka消息可靠性、Hive與數(shù)倉建模、數(shù)據(jù)傾斜處理。把這20%知識點吃透剩下的20%即使答不全總分也不會差。這套方法不只在iHandy幾乎所有大數(shù)據(jù)開發(fā)崗的筆試題都適用。希望這篇拆解能幫你少走一些彎路。數(shù)據(jù)開發(fā)這一行入門靠基礎走得遠靠的是對全鏈路的理解和解決問題的能力。筆試只是第一關把每一次答題都當成一次完整的工程思考你收獲的會遠超一個offer。祝順利。 校招大數(shù)據(jù)開發(fā)筆試題拆解：從日志處理到集群部署
1. 一套校招大數(shù)據(jù)筆試題背后到底在篩什么人每年秋招季都能看到大量XX公司XX崗位筆試題在各種群里流傳。我見過太多人拿到題先問答案是什么我卻想先問一句出題人到底想通過這套題篩出什么樣的人拿iHandy2019校招大數(shù)據(jù)開發(fā)工程師這套題來說它不像社招那樣追著源碼問也不會像ACM那樣硬摳算法但它很典型地反映了一類移動互聯(lián)網公司對校招數(shù)據(jù)崗的真實期待——不是要你背出Flink源碼的細節(jié)而是要看你能不能在這個數(shù)據(jù)量級飛速膨脹的環(huán)境里用最穩(wěn)妥的技術棧把活干完、干對、干明白。iHandy是什么體量的公司做海外工具類、內容類App起家用戶量以億計日活數(shù)據(jù)千萬級甚至上億。這種業(yè)務形態(tài)決定了它的數(shù)據(jù)團隊每天面對的不是幾百MB的Excel而是源源不斷的埋點日志、業(yè)務庫Binlog、服務器監(jiān)控指標。這些數(shù)據(jù)要經過采集、清洗、入倉、建模、報表、算法特征提取這一整條鏈路任何一個環(huán)節(jié)出錯輕則報表對不上重則影響買量決策、廣告收入計算。所以筆試題目設計的核心邏輯就一句話用最小的成本判斷你有沒有生產環(huán)境的直覺。什么意思我給你拆開講。比如一道題問Spark任務的并行度怎么設置沒有生產經驗的人會默寫上跟核數(shù)一致但有經驗的人會反問數(shù)據(jù)量多少數(shù)據(jù)傾斜有沒有Shuffle分區(qū)數(shù)跟下游文件的關聯(lián)是什么這套題不是考你背參數(shù)而是考你在真實場景里會不會做權衡。再比如說日志處理。移動互聯(lián)網公司最不缺的就是日志用戶點擊、啟動、崩潰、購買行為全部以日志形式落盤。誰能在有限資源里把億級日志處理得又快又準誰就是數(shù)據(jù)團隊想要的人。這套題里如果出現(xiàn)用Java編寫Spark處理日志這類題一點都不奇怪——它就是業(yè)務場景的微縮版。從熱搜詞也能看出來大數(shù)據(jù)開發(fā)、大數(shù)據(jù)架構、Spark日志處理、集群部署、數(shù)據(jù)質量這些詞高頻出現(xiàn)說明行業(yè)對這些方向的人才需求是持續(xù)且明確的。作為校招生你不需要在每一個方向都是專家但你需要對這些詞背后的工程問題有完整的認知框架。我在后面幾節(jié)里會結合這類題目常見的幾個考察方向逐一拆解題目背后的出題意圖、答題思路以及那些老師沒教過、但面試官默認你會的行業(yè)常識。這樣你看完這篇再去做任何一家公司的大數(shù)據(jù)開發(fā)筆試題至少能知道每道題在問什么以及考官想聽什么答案。2. 從Java寫Spark處理日志看這道常青題怎么答才不丟分2.1 為什么日志處理題年年出現(xiàn)大數(shù)據(jù)校招筆試里日志處理基本是必出題。原因特別樸素日志是離數(shù)據(jù)工程師最近的數(shù)據(jù)形態(tài)。每天零點過后全公司的App用戶行為日志、業(yè)務服務日志、系統(tǒng)運行日志都會匯聚到數(shù)據(jù)平臺。你早上一來打開告警群看到的就是昨日日志處理任務運行時長超時數(shù)據(jù)產出延遲某個埋點字段解析失敗。日復一日你其實就是在跟日志較勁。所以筆試里出現(xiàn)用Java編寫Spark處理日志數(shù)據(jù)這類題本質上是把日常工作抽象成了考試題。它考察的能力很明確你會不會用Java寫Spark作業(yè)你知不知道日志數(shù)據(jù)常見的格式和坑你有沒有處理過臟數(shù)據(jù)、字段缺失、類型異常這些問題你寫的代碼有沒有生產意識比如設置合理的分區(qū)數(shù)、避免OOM、考慮增量還是全量我見過很多候選人代碼寫得挺漂亮但一跑真實數(shù)據(jù)就崩。問題不在語法在于他從來沒見過真實日志長什么樣。2.2 一道經典真題的完整答題過程假設題目是這樣的有一批用戶行為日志每一行是JSON格式包含userId、action、timestamp、pageId、deviceType等字段請用Java編寫Spark程序統(tǒng)計每天每個頁面的獨立訪客數(shù)UV和訪問次數(shù)PV結果輸出到HDFS并按PV倒序排列。很多人拿到這題直接開寫。但我想先說一句先別急著寫代碼先想清楚你會在生產環(huán)境怎么做這件事。第一步讀數(shù)據(jù)。日志放在HDFS上日期作為分區(qū)目錄比如/data/logs/dt20240601。你用Spark讀的時候是讀整個目錄還是讀具體日期生產上通常跑定時調度傳入日期參數(shù)只讀當天的分區(qū)。第二步解析。日志是JSON格式你可以在Java里用Fastjson或Jackson解析也可以用Spark自帶的from_json函數(shù)。筆試手寫代碼的話用Fastjson最直觀。第三步指標計算。PV好算每條日志count一下就行。UV要去重用approxCountDistinct還是countDistinct這里有個考點UV通常很大精確去重在數(shù)據(jù)量上來以后會非常耗時生產環(huán)境一般用HyperLogLog這類近似算法誤差在1%以內性能卻快幾個數(shù)量級。答題時說清楚這個選擇比代碼寫對更讓面試官眼前一亮。第四步結果寫出。分區(qū)數(shù)多少文件大小多少如果結果很小coalesce(1)減少小文件如果結果很大保持合理分區(qū)數(shù)。這些都是生產環(huán)境的真實考量。我給出一個可直接參考的Java版本實現(xiàn)import com.alibaba.fastjson.JSONObject; import org.apache.spark.api.java.JavaPairRDD; import org.apache.spark.api.java.JavaRDD; import org.apache.spark.sql.SparkSession; import scala.Tuple2; import java.util.Arrays; public class LogAnalyzer { public static void main(String[] args) { String inputPath args[0]; String outputPath args[1]; SparkSession spark SparkSession.builder() .appName(UserActionLogAnalyzer) .enableHiveSupport() .getOrCreate(); JavaRDDString lines spark.read().textFile(inputPath).javaRDD(); // 解析JSON過濾臟數(shù)據(jù) JavaPairRDDString, String pageUserRDD lines.mapToPair(line - { try { JSONObject obj JSONObject.parseObject(line); String pageId obj.getString(pageId); String userId obj.getString(userId); if (pageId null || userId null) { return null; } return new Tuple2(pageId, userId); } catch (Exception e) { return null; // 臟數(shù)據(jù)跳過 } }).filter(tuple - tuple ! null); // PV統(tǒng)計 JavaPairRDDString, Long pvRDD pageUserRDD .mapToPair(tuple - new Tuple2(tuple._1, 1L)) .reduceByKey(Long::sum); // UV統(tǒng)計先按(pageId, userId)去重再統(tǒng)計 JavaPairRDDString, Long uvRDD pageUserRDD .distinct() .mapToPair(tuple - new Tuple2(tuple._1, 1L)) .reduceByKey(Long::sum); // 按PV倒序排序 ListTuple2String, Long pvList pvRDD.collect(); // 實際生產用sortByKey或DataFrame API排序 // 這里簡化為輸出到文件 pvRDD.mapToPair(Tuple2::swap) .sortByKey(false) .mapToPair(Tuple2::swap) .saveAsTextFile(outputPath /pv); uvRDD.saveAsTextFile(outputPath /uv); spark.stop(); } }這段代碼在考試里夠用但我要特別說明幾個生產環(huán)境里真正重要、也是面試官真正想聽的細節(jié)一是臟數(shù)據(jù)處理。真實日志里總有幾行JSON解析失敗、userId為空、字段類型錯亂。代碼里catch (Exception e) { return null; }就是干這個的。你要能主動說出解析失敗的數(shù)據(jù)我選擇丟棄并記錄告警如果丟棄率超過閾值就要排查埋點問題這句話能體現(xiàn)你的工程思維。二是數(shù)據(jù)傾斜。熱門頁面的日志量可能是冷門頁面的成百上千倍reduceByKey時一個Key的數(shù)據(jù)量巨大會導致單個Task跑很久。生產上要預見這個問題答題時主動提到加鹽、兩階段聚合等手段會明顯加分。三是結果文件數(shù)量問題。saveAsTextFile默認分區(qū)數(shù)跟最后一個RDD的分區(qū)數(shù)一致如果最后分區(qū)數(shù)幾百個會產生幾百個小文件HDFS NameNode壓力很大下游Hive查詢也會變慢。按PV排序輸出前應該coalesce(1)或repartition(合適的數(shù)量)。能主動講出這一點的人真的不多。2.3 這類題目的延伸追問預備筆試之后通常還有面試面試官大概率會順著日志題往下追問如果日志量每天增加一倍你的作業(yè)怎么擴容如果某個字段的解析邏輯變了老數(shù)據(jù)和新數(shù)據(jù)怎么兼容如果下游報表要求凌晨6點前產出你的作業(yè)運行時間超過窗口怎么辦埋點上報的日志有延遲凌晨統(tǒng)計時還有一部分數(shù)據(jù)沒到齊怎么辦這些問題沒有標準答案但都在考察你有沒有真實面對過數(shù)據(jù)是臟的、系統(tǒng)是不完美的、時間是緊張的這三種狀態(tài)。準備面試時把歷年真題里的日志題都拿出來順著這幾個方向想一想比多刷十道算法題有用得多。3. 大數(shù)據(jù)收集與質量保證題目里最簡單、卻最能拉開差距的一塊熱搜詞里有一句很扎眼的話對于大數(shù)據(jù)而言最基本、最重要的要求就是減少錯誤、保證質量。那么大數(shù)據(jù)收集的...。這多半是某個知識平臺上的問題標題但正好戳中了校招筆試里最容易被忽視、也最能體現(xiàn)功底的考察方向。3.1 減少錯誤、保證質量在大數(shù)據(jù)場景下到底指什么很多校招生對數(shù)據(jù)質量的理解停留在數(shù)據(jù)不能錯。但到了生產環(huán)境錯有好多種我隨便列幾個數(shù)據(jù)丟采集端網絡抖動一批日志沒傳上來數(shù)據(jù)重重試機制導致同一條日志被上報了兩次數(shù)據(jù)臟客戶端版本太老埋點事件里混入了格式錯誤的內容數(shù)據(jù)晚本該昨天到的數(shù)據(jù)今天才到齊數(shù)據(jù)不一致兩個部門對同一個指標的統(tǒng)計口徑不一樣報表打架數(shù)據(jù)模型錯事實表和維度表的關聯(lián)鍵有重復導致數(shù)據(jù)膨脹筆試題如果考到數(shù)據(jù)收集大概率會從你怎么設計一套可靠的采集方案或者給你一批臟數(shù)據(jù)你怎么清洗這兩個角度切入。前者考察系統(tǒng)設計后者考察實操能力。3.2 從埋點數(shù)據(jù)看數(shù)據(jù)收集的核心鏈路移動App的數(shù)據(jù)收集鏈路大概是這樣的App端埋點 - 上報隊列 - 網關接收 - Kafka - 實時/離線清洗 - 數(shù)倉入倉筆試考這個鏈路時常見的考點包括傳輸層Kafka在鏈路里扮演什么角色Kafka的定位是削峰填谷。如果客戶端直接寫數(shù)據(jù)庫高峰期可能把庫打爆但有了Kafka這個緩沖層上游流量再大下游消費者都可以按照自己的速度消費。這道題的變體還會問Kafka掛了一個broker消息會丟嗎答案取決于副本因子配置生產環(huán)境一般設3副本允許掛2臺broker不丟數(shù)據(jù)。采集層埋點丟失怎么發(fā)現(xiàn)業(yè)界常用的做法是數(shù)量對賬?？蛻舳嗣看紊蠄笕罩緯r附帶一個event sequence number服務端可以校驗序列號連續(xù)性。離線側還可以做產出監(jiān)控比如昨天PV是1億今天突然變成8000萬監(jiān)控系統(tǒng)自動告警。筆試里你能答出兩邊對賬監(jiān)控告警兩層保障基本就過關了。清洗層臟數(shù)據(jù)怎么處理清洗規(guī)則應該寫死在ETL里而不是靠人工。比如日期字段格式不合法就置空、行為類型不在枚舉范圍內就丟棄、userId為空就歸入未知用戶桶。關鍵是清洗規(guī)則要可追溯每一類被清洗掉的數(shù)據(jù)都要有統(tǒng)計和抽樣日志否則出了問題連鍋都找不到。3.3 數(shù)據(jù)質量題的答題框架面試官如果要考數(shù)據(jù)質量常見的出題方式是你們的報表數(shù)據(jù)跟業(yè)務方自己統(tǒng)計的對不上怎么排查這是一個典型的排查思路題答案可以套用一套固定鏈路先對齊統(tǒng)計口徑。是不是兩邊對活躍用戶的定義不同一邊算啟動過App就算活躍另一邊算有過頁面瀏覽行為才算活躍再對齊時間口徑。一個按東八區(qū)算天另一個按UTC算天數(shù)據(jù)對不上太正常了。第三步查數(shù)據(jù)鏈路。一邊從實時數(shù)倉讀一邊從離線數(shù)倉讀兩邊底層數(shù)據(jù)不一致結果必然不一致。實時和離線的數(shù)據(jù)質量本身就可能不同。第四步是真的查Bug?？纯碋TL代碼有沒有更新后沒測出問題、有沒有上游表結構變更導致下游解析失敗。這個框架的價值在于它向面試官證明你不是上來就翻代碼而是有系統(tǒng)性的排查方法。我在實際工作中處理過太多數(shù)據(jù)對不上的問題超過一半最后查出來是口徑問題不是程序Bug。3.4 關于串口屏往數(shù)據(jù)記錄控件添加一條內容添加不全的延伸思考熱搜詞里有個很特別的問題廣州大彩串口屏往數(shù)據(jù)記錄控件添加一條內容添加不全。乍一看這跟主流大數(shù)據(jù)八竿子打不著。但這類問題恰恰反映了物聯(lián)網/嵌入式場景下小數(shù)據(jù)的常見故障——不是大數(shù)據(jù)量級是大數(shù)據(jù)鏈路最前端的采集環(huán)節(jié)。如果你有幸面試的是一家做IoT數(shù)據(jù)平臺的公司這類問題就可能以場景題出現(xiàn)設備端上報的數(shù)據(jù)不完整你怎么定位是設備端問題、網關問題還是平臺解析問題排查思路其實是相通的先在鏈路各節(jié)點加日志和數(shù)據(jù)快照然后做分段對比找到第一個數(shù)據(jù)變短的節(jié)點再針對該節(jié)點的處理邏輯做代碼審查。這個方法論跟處理幾億條日志數(shù)據(jù)質量問題的思路一模一樣。所以別小看熱搜詞里那些犄角旮旯的關聯(lián)問題——它們反映的往往不是問題本身而是大數(shù)據(jù)從采集到應用的完整鏈條中某個環(huán)節(jié)的真實痛點。你在筆試答題時能體現(xiàn)出我理解全鏈路而不只是會寫SQL就已經跑贏大部分候選人了。4. 大數(shù)據(jù)架構和集群部署題從一套架構設計題反推復習重點4.1 大數(shù)據(jù)架構題到底在問什么校招筆試出現(xiàn)大數(shù)據(jù)架構相關的題通常不是讓你畫一張完整的Lambda架構圖而是給你一個具體場景讓你選技術方案。常見問法是這樣的業(yè)務方需要實時看到今天的銷售額又要支持昨天之前的歷史數(shù)據(jù)分析你怎么設計數(shù)據(jù)架構數(shù)據(jù)中心每天產生10TB日志要求保留30天供分析查詢響應時間要在秒級你怎么選型數(shù)據(jù)量增長很快當前Hadoop集群磁盤使用率已經85%怎么擴容在線擴容還是冷熱分離這些題沒有唯一答案但能看出一個人有沒有完整的數(shù)據(jù)平臺認知。拿熱搜詞里那條大數(shù)據(jù)集群部署策略來說校招筆試可能會拆成幾道小題NameNode和DataNode分別部署在什么類型的機器上ZooKeeper集群最少要幾臺為什么Kafka的broker和ZooKeeper部署在一起行不行這些問題的核心只有一個——你是否理解不同組件對硬件資源的需求差異。我列一張表你在復習時可以對照著看組件主要消耗資源部署建議NameNode內存存元數(shù)據(jù)大內存機器如256GB內存SSDDataNode磁盤、I/O大容量HDD即可追求吞吐ResourceManager內存、CPU中等配置即可高可用要兩臺ZooKeeperCPU、網絡3臺或5臺小機器IO要求高Kafka Broker磁盤I/O、網絡多塊SSD做消息日志存儲HBase RegionServer內存、I/O內存要大最好配NVMe SSDFlink TaskManager內存、CPU按內存/CPU配比計算槽位數(shù)大部分校招生對這張表沒有概念或者說只記住了NameNode要內存大這句話但不知道為什么要大。NameNode把整個文件系統(tǒng)的目錄樹和文件塊位置信息都放在內存里文件數(shù)越多內存占用越大。一個文件塊默認128MB的元數(shù)據(jù)大約150字節(jié)如果是1億個文件光元數(shù)據(jù)就要15GB內存再加上堆內其他開銷和堆外內存64GB的機器都不一定夠用。這就是為什么生產環(huán)境超大集群要引入NameNode聯(lián)邦或HDFS Router來橫向擴展元數(shù)據(jù)能力。4.2 集群部署策略的考察點與答題重點集群部署題從實際操作角度來說最常見的是在線擴容和高可用配置兩個方向。在線擴容考的是你對數(shù)據(jù)均衡的理解。新增DataNode節(jié)點后HDFS不會自動把老節(jié)點數(shù)據(jù)搬到新節(jié)點需要手動執(zhí)行hdfs balancer而且balancer默認帶寬只有1MB/s需要調大參數(shù)。部署時如果不管磁盤數(shù)據(jù)平衡老節(jié)點磁盤很快被打滿新節(jié)點閑著集群整體可用容量反而下降。答題時能主動說出擴容后要關注balance這個操作細節(jié)就會顯得很有實戰(zhàn)經驗。高可用配置考的是腦裂問題的理解。Hadoop NameNode高可用依賴ZooKeeper和JournalNodeActive NameNode和Standby NameNode之間通過JournalNode同步元數(shù)據(jù)編輯日志。實際生產中可能出現(xiàn)Active節(jié)點假死網絡抖動、JVM長時間GCZooKeeper這邊判定它掛了讓Standby切換成Active但老Active其實還活著于是出現(xiàn)兩個Active——這就是腦裂。答案是靠Fencing機制舊的Active會被強制隔離SSH殺進程、或者調用隔離腳本只有確保舊Active不再使用共享資源新Active才能安全接管。校招題如果問到HA你能答出腦裂要靠Fencing機制解決這一層已經比很多工作一兩年的人強了。4.3 基于大語言模型的非結構化數(shù)據(jù)理解這類新考點最近的熱搜詞里還出現(xiàn)了一條很有意思的基于大語言模型的云盤非結構化數(shù)據(jù)理解與內容生成方法。這類技術方向放在2019年還是科幻小說但放到現(xiàn)在它已經變成了真實的數(shù)據(jù)架構考題方向。校招筆試題如果往這個方向延伸很可能不是考模型本身而是考數(shù)據(jù)架構怎么配合非結構化數(shù)據(jù)文檔、圖片、視頻怎么統(tǒng)一接入數(shù)倉對象的元數(shù)據(jù)文件類型、大小、存儲位置、所屬用戶放哪里大模型推理結果怎么回流是寫回源數(shù)據(jù)系統(tǒng)還是單獨建特征庫內容生成的結果怎么評估質量這四個問題本質上還是在考數(shù)據(jù)鏈路設計能力。你不需要真的訓過大模型但你要能說出非結構化數(shù)據(jù)要先做元數(shù)據(jù)抽取再做內容理解最后把結果回流到檢索系統(tǒng)或推薦系統(tǒng)這個閉環(huán)。面試官聽到你講出這個閉環(huán)就會知道你對技術趨勢有敏感度而且對數(shù)據(jù)架構有整體認知。4.4 Avue-Data數(shù)據(jù)大屏這類前端部署題怎么應對熱搜詞里avue-data數(shù)據(jù)大屏前端是怎么部署的也是個有意思的問題。很多人會問這是前端題關大數(shù)據(jù)什么事其實它考的是數(shù)據(jù)產品化的最后一公里。數(shù)據(jù)大屏就是把數(shù)倉里的指標通過可視化方式展示出來。筆試里如果出這類題核心考點通常是大屏數(shù)據(jù)從哪來直接查數(shù)據(jù)庫還是查預聚合的API實時大屏用WebSocket還是輪詢大屏數(shù)據(jù)量很大時前端會不會卡死要不要服務端做聚合有一次我面一個候選人他說他做過數(shù)據(jù)大屏被問到數(shù)據(jù)量到10萬條以上圖表卡頓怎么辦他沒答上來。其實答案不復雜大屏展示的是趨勢和概覽沒必要把每條明細都推到前端服務端按分鐘聚合出幾百個點就夠了。真正需要明細下鉆的再按需加載。能答到這層的人說明他考慮的不只是怎么把組件跑起來而是這個系統(tǒng)在真實量級下能不能扛住。5. 從DataX到Dinky數(shù)據(jù)集成與開發(fā)工具類題目的復習方向5.1 為什么筆試會考工具組件有熱搜詞問大數(shù)據(jù)組件dinky下載大數(shù)據(jù)集群部署策略這一類關鍵詞直指筆試中的工具題。校招筆試考工具不是為了讓你報出版本號而是考察兩件事你知道這個工具解決什么問題、在鏈路里處于什么位置你上手用過沒有遇到報錯時能不能定位大數(shù)據(jù)開發(fā)崗位日常接觸的工具有一大把數(shù)據(jù)集成有DataX、Flink CDC、Canal調度有Azkaban、DolphinScheduler、Airflow數(shù)倉建模有Hive、Spark SQL查詢引擎有Presto、Doris、ClickHouse開發(fā)輔助有Dinky這種Flink SQL開發(fā)平臺。任何一個工具拿出來都能出一套面試題但校招筆試通常只考兩類選型類和應用類。5.2 工具選型題的通用答題框架MySQL數(shù)據(jù)實時同步到數(shù)據(jù)倉庫你會用什么工具——這是典型的數(shù)據(jù)集成選型題。筆試題答這題建議按這個框架展開第一步確認需求邊界。同步是全量還是增量實時還是離線數(shù)據(jù)量多大目標庫是什么第二步列舉可選方案。全量離線可以用DataX增量實時且有主鍵變更捕獲需求用Flink CDC或Canal監(jiān)聽Binlog如果只是分鐘級延遲的準實時也可以用DataX配周期調度。第三步給出理由。比如選Flink CDC可以說它能精確讀取Binlog支持斷點續(xù)傳配合Flink的實時計算能力可以直接做清洗和寬表加工選Canal則更輕量適合單純把Binlog轉發(fā)到Kafka的場景。第四步指出風險。Binlog開啟會增加數(shù)據(jù)庫主庫的壓力大事務會導致Binlog膨脹源庫表結構變更會導致同步任務報錯這些都需要有應對預案。哪怕你沒實際配過這些工具能按這個邏輯把答案組織完整筆試這題也能拿到大部分分數(shù)。5.3 工具的坑面試官真正想問的工具題的高級考法是直接給你一個報錯場景問你怎么排查。比如DataX同步任務一直報java.sql.SQLException: Data too long for column怎么處理這個問題我在工作里真的遇到過。原因通常是源庫字符集和目標庫字符集不一致或者目標表字段長度定義比源庫小。排查思路是打開DataX日志找到具體是哪一列、哪一行的數(shù)據(jù)然后對比源表和目標表的字段定義。再比如Dinky上提交Flink SQL作業(yè)狀態(tài)一直顯示RUNNING但數(shù)據(jù)不更新這個問題的排查鏈路是先看TaskManager日志有沒有輸出再看Kafka消費組的Lag是不是為0最后看Watermark有沒有推進。如果Watermark不推進說明上游事件時間停滯要么是數(shù)據(jù)源本身沒有新數(shù)據(jù)要么是空閑數(shù)據(jù)源沒設withIdleness。能答出這個排查順序說明你對實時計算是有實操經驗的。5.4 學習工具組件的高效路徑我的建議是不要一個個工具孤立地去學按一條主鏈路串起來學。我整理了一條復習主線校招生照著走覆蓋面會比零散刷題好得多數(shù)據(jù)采集Canal/Flink CDC、DataX、Flume 消息隊列Kafka重點分區(qū)、副本、消費組、消息不丟不重 實時計算Flink重點窗口、狀態(tài)、檢查點、Watermark 離線計算Spark重點RDD/DataFrame、Shuffle、調優(yōu) 數(shù)倉存儲Hive重點分區(qū)、分桶、ORC/Parquet、小文件 查詢引擎Presto/ClickHouse/Doris重點適用場景區(qū)別 調度DolphinScheduler/Azkaban重點任務依賴、失敗重試 開發(fā)平臺Dinky重點Flink SQL開發(fā)、作業(yè)提交每一個組件先搞清楚三件事它解決什么問題、它上下游是什么、它最容易出問題的點是什么。這三個問題搞清楚了不管是筆試客觀題還是面試主觀題你都能有自己的判斷而不是死記硬背。6. 做題時的通用提分策略從會做到答得出彩6.1 大數(shù)據(jù)的題答案在權衡不在正確很多校招生做題有個習慣非黑即白必須選一個對的。但大數(shù)據(jù)開發(fā)的筆試題幾乎沒有標準答案只有更合適的方案。我給你舉一個經典例子。題目問實時計算你選Flink還是Spark Streaming很多人的回答是Flink更先進所以選Flink。但換個場景公司已有的技術棧是Spark團隊對Spark更熟實時性要求是分鐘級而不是秒級數(shù)據(jù)量也沒有大到Flink才能扛住的水平。這時候Spark Streaming就是更務實的選擇。Flink和Spark Streaming的區(qū)別維度FlinkSpark Streaming計算模型真正的流式計算微批處理延遲毫秒級秒級狀態(tài)管理原生支持狀態(tài)大依賴外部存儲狀態(tài)能力弱精確一次語義內置支持需要配合業(yè)務邏輯實現(xiàn)學習成本較高基于Spark生態(tài)熟悉你答題時應該先說我會根據(jù)場景選再把場景拆開講延遲要求、狀態(tài)規(guī)模、團隊技術棧、上下游生態(tài)。而不是一上來就宣布哪個好。能體現(xiàn)權衡思維的人分數(shù)一定高。6.2 關鍵詞敏感度訓練從題目里抓真實需求我這些年帶過不少新人發(fā)現(xiàn)一個共性做題時只看到題面看不到題面背后的業(yè)務需求。比如有一道題問有一個訪問日志表每天有幾十億條記錄需要查詢某個用戶在某個時間段內的訪問明細怎么優(yōu)化如果只看到JSON解析SQL查詢這些技術詞你就只會給出最簡單的方案。但你把關鍵詞拆開看幾十億條意味著要分區(qū)、分桶某個用戶意味著查詢條件高度選擇性強適合用分區(qū)裁剪謂詞下推某個時間段意味著時間字段應該作為分區(qū)鍵明細查詢意味著需要支持點查和范圍查可以考慮用HBase或Druid或者用ClickHouse的跳數(shù)索引。你如果平時有意識地訓練自己從題面關鍵詞反推業(yè)務場景這個能力碰到偏題怪題就不會慌。你還可以反向思考如果你是出題人你會在哪個環(huán)節(jié)埋業(yè)務陷阱6.3 答題的書面表達讓面試官一眼看到關鍵詞筆試通常有時間限制尤其是客觀題主觀題混合的卷子。主觀題答的時候我建議你用關鍵詞前置的寫法。比如題目問請簡述Flink的CheckPoint機制你不要上來就長篇大論地講原理而是先寫CheckPoint是Flink保證故障恢復后狀態(tài)一致性的核心機制核心要素包括Barrier對齊、狀態(tài)快照、State Backend、恢復流程、端到端精確一次。然后再展開講每個要素。面試官閱卷時第一眼掃到的就是這些關鍵詞你的答案在大批量卷子里就會顯得很懂。用這種方式答題還有一個額外好處即使你展開部分寫得不太完整關鍵詞已經幫你把基本分拿到手了。我當年自己校招時也是用這個方法主觀題部分從來沒低于過80%的得分率。6.4 考前必須準備的幾類萬能素材大數(shù)據(jù)開發(fā)筆試有幾類問題出現(xiàn)的概率極高我建議考前就把這幾類素材準備好說清楚你做過的一個數(shù)據(jù)項目包含數(shù)據(jù)量、技術棧、處理鏈路、遇到的最大問題、你怎么解決的、最后效果如何。這個準備充分了能應對一半以上的主觀題。說清楚Spark和Flink的區(qū)別不只是計算模型還有狀態(tài)管理、精確一次、容錯機制、適用場景。說清楚Hive和數(shù)倉的分層思想ODS、DWD、DWS、ADS每一層干什么為什么要這樣分。說清楚一條數(shù)據(jù)從產生到報表展示的全過程哪一步會發(fā)生數(shù)據(jù)問題哪一步最耗時哪一步最容易出瓶頸這四個素材準備完你會發(fā)現(xiàn)筆試主觀題基本就是素材的排列組合。與其臨時抱佛腳刷一百道題不如先把這幾個核心故事打磨成自己的標準答案。7. 寫在最后一套真題之外的備考建議回到iHandy2019校招這套題。說實話這類公司出的筆試題難度不在于題目本身有多深而在于題面很業(yè)務跟學校里教的算法操作系統(tǒng)數(shù)據(jù)庫完全是兩套話語體系。如果你還在用刷LeetCode和背操作系統(tǒng)八股的方式準備大數(shù)據(jù)崗大概率會吃大虧。我給校招生的建議是準備大數(shù)據(jù)開發(fā)崗筆試先建認知框架再填充細節(jié)。認知框架就是我在前幾節(jié)反復強調的那條鏈路——采集、傳輸、存儲、計算、調度、應用你要能閉著眼把這條鏈路畫出來并且標出每一環(huán)的主流組件和核心問題。細節(jié)填充就是把每個組件的關鍵原理、典型場景、常見故障想清楚。我自己當年面試時吃過一個虧問Kafka為什么快我只答了順序寫磁盤但面試官緊接著問順序寫為什么比隨機寫快那么多我楞住了。其實是機械硬盤尋道時間和操作系統(tǒng)頁緩存的問題這個知識點我明明學過但在面試的壓力下沒串起來。從那以后我養(yǎng)成一個習慣**學每一個技術點都問自己三個問題——它在全鏈路里的位置是什么它的核心設計解決什么問題如果它壞了會怎樣**這三個問題串起來知識就不是孤島。最后再分享一個實戰(zhàn)小技巧。如果你拿到一套歷年真題先別急著做花半小時把每道題考察的知識點標出來然后統(tǒng)計頻率。你會發(fā)現(xiàn)80%的分數(shù)集中在20%的知識點上Spark算子與調優(yōu)、Flink狀態(tài)與容錯、Kafka消息可靠性、Hive與數(shù)倉建模、數(shù)據(jù)傾斜處理。把這20%知識點吃透剩下的20%即使答不全總分也不會差。這套方法不只在iHandy幾乎所有大數(shù)據(jù)開發(fā)崗的筆試題都適用。希望這篇拆解能幫你少走一些彎路。數(shù)據(jù)開發(fā)這一行入門靠基礎走得遠靠的是對全鏈路的理解和解決問題的能力。筆試只是第一關把每一次答題都當成一次完整的工程思考你收獲的會遠超一個offer。祝順利。