這份卷子的標題是“浩鯨科技2020屆數據開發類C卷”乍一看像一份過期資料但如果你正在準備數據開發相關崗位的筆試面試我建議你耐著性子往下看。數據開發這個崗位核心考察的東西三五年內基本不會變尤其是SQL、數倉理論、大數據組件原理這三板斧。我從2019年校招開始接觸這類題也幫人改過不少筆試答案發現大多數人的復習方向都有問題——花大把時間刷算法題結果栽在一道看似簡單的SQL窗口函數上或者在“為什么數倉要分層”這種送分題上答得毫無層次。2020屆的C卷放在今天來看反而是一種很好的“基準測試”它告訴你一家做電信行業數字化服務的公司在招數據開發時到底想要什么樣的人。下面我把這套卷子背后的考察邏輯、常見考點、容易翻車的地方以及備考路線一次性拆透。1. 先看這張卷子的出題背景浩鯨是誰數據開發崗在招誰1.1 浩鯨科技是做什么的很多考生拿到卷子根本不看公司上來就做這其實是大忌。浩鯨科技前身是中興軟創后來接受了阿里投資改名浩鯨科技。它主要做電信運營商相關的業務支撐系統、數據中臺、經營分析系統簡單說就是幫運營商管好“家底”讓每一條用戶通話記錄、每一筆流量訂單、每一個用戶畫像都能被采集、清洗、加工、分析最終變成報表和決策依據。這也決定了它招“數據開發”的時候考的東西一定和純互聯網公司有所差別。電信行業的數據鏈路長、數據量大、口徑復雜所以筆試里大概率會出現SQL題、數倉分層設計、Hadoop/Hive/Spark原理以及少量Java或者Linux基礎。你如果只準備算法很容易翻車。1.2 2020屆、C卷這兩個詞背后的校招邏輯“2020屆”對應的是2019年秋招那一批也就是疫情前最后一批相對正常的校招。那時候大數據開發崗位已經非常熱門但還沒到后來“一問全是數據開發”的程度。很多公司同一場筆試會出A、B、C多套卷目的是防止相鄰座位互相抄襲或者按崗位方向做區分。所以“C卷”本身并不代表難度分級它只說明這是一套平行卷。不過這也透露一個信息你拿到的題目很可能和網上流傳的A卷、B卷不一樣但考察范圍高度重合。換句話說你不能靠背題來通過必須把知識點本身吃透。1.3 數據開發與后端開發、算法工程師的邊界這道題我必須先說清楚因為很多人簡歷上寫“大數據開發”其實腦子里想的是“后端開發”或者“算法崗”。數據開發的工作重心在數據倉庫建設、ETL調度、數據管道、數據質量保障、BI報表支持核心工具是SQL、Hive、Spark、調度平臺而不是高并發微服務也不是模型調參。所以筆試的科目配比會明顯偏向數據側。C卷里如果出現Java題大概率也是基礎語法、集合、并發中的基礎概念不會讓你手寫紅黑樹。如果你把大量時間花在二叉樹遍歷和動態規劃上那就走偏了。數據開發考算法一般到LeetCode簡單和中度題就夠了重點反而是SQL和數倉。2. 由卷子反推考點數據開發筆試里反復出現的“基本盤”我手上沒有C卷原題但基于浩鯨這類公司數據開發崗位的招聘邏輯以及我見過的多套同類型筆試可以倒推出一個比較穩的考點框架。這套框架不僅適用于浩鯨也適用于大多數做數倉和大數據平臺的公司。2.1 語言和基礎Java、Linux、計算機網絡很多數據開發筆試尤其是2020屆那種現場筆試會在前面放十幾道選擇題覆蓋Java基礎、Linux命令、計算機網絡和數據庫基礎。Java部分常考HashMap底層結構、ArrayList和LinkedList區別、線程安全的幾種方式、JVM內存區域劃分。Linux部分常考常用命令的用途比如top、grep、awk、sed、less以及查看磁盤空間、查看端口占用、查看進程狀態的命令。計算機網絡部分基本不會太深TCP三次握手、HTTP狀態碼、DNS解析流程算高頻。我給個建議這一塊不用花大量時間系統復習重點是把高頻考點過一遍。我當時用的是“刷題看錯題解析”的方式每天花半小時持續十天左右就夠應付筆試了。不要一來就啃《Java編程思想》性價比太低。2.2 SQL題數據開發的立身之本SQL題是數據開發筆試的絕對核心占比通常在30%到40%。如果一份筆試卷子滿分100分SQL題拿不到80%的正確率后面面試基本沒底氣。常考的SQL類型包括多表連接inner join、left join、子查詢、聚合函數與group by、having和where的區別、行轉列列轉行、窗口函數rank、dense_rank、row_number、sum over、日期處理函數、case when邏輯判斷。舉個典型題目有一張訂單表orders(order_id, user_id, amount, create_date)要求統計每個用戶最近三筆訂單的平均金額。很多人的第一反應是limit但正確處理是窗口函數SELECT user_id, AVG(amount) OVER(PARTITION BY user_id ORDER BY create_date ASC ROWS BETWEEN 2 PRECEDING AND CURRENT ROW) AS avg_amount_recent_3 FROM orders;注意order by create_date ASC當前行是最早的不ASC時當前行反而是最早的ROWS BETWEEN 2 PRECEDING AND CURRENT ROW取的是“當前行往前兩行加自己”但ASC排序下往前兩行是更早的這會取到最舊的單子而題目要“最近三筆”。正確做法是先把數據按create_date倒序排列或者用ORDER BY create_date DESC配合ROWS BETWEEN CURRENT ROW AND 2 FOLLOWING。我給一個更穩妥的寫法SELECT user_id, AVG(amount) OVER(PARTITION BY user_id ORDER BY create_date DESC ROWS BETWEEN CURRENT ROW AND 2 FOLLOWING) AS avg_amount_recent_3 FROM orders;道理很簡單在窗口內按日期倒序排當前行是最新一筆FOLLOWING兩行就是往前數兩筆。這里有個最常見的坑窗口函數里order by的方向和frame的范圍組合很多考生一緊張就寫反。還有一道常見題用戶行為表user_behavior(user_id, action, dt)統計每天每種行為的用戶數并輸出當天行為量排名前三的組合。用row_number() over(partition by dt order by cnt desc)就能解關鍵點是先聚合再用窗口函數順序不能反。2.3 大數據組件Hadoop三劍客與Spark這一部分占分通常在20%到30%以簡答題和場景題為主。HDFS部分常考數據塊默認大小、副本機制、NameNode和DataNode職責、讀寫流程。讀寫流程可以用生活化類比來理解把HDFS想象成一個“先問管家再搬貨”的過程Client先聯系NameNode確認元數據再和DataNode建立管道一塊一塊傳。寫的時候要以packet為單位讀的時候要就近原則。這些概念不需要背源碼但一定要能用兩三句話說清楚。MapReduce部分常考整個作業從split到map到shuffle到reduce的過程尤其是shuffle里分區、排序、溢寫、合并這幾步。面試官很喜歡問“為什么MapReduce很慢”答案是中間結果要落盤、排序多、進程啟動開銷大。Hive部分常考Hive是什么數據倉庫工具SQL轉MapReduce/Tez/Spark作業、內部表和外部表的區別、分區表和分桶表、where和having的區別順帶SQL也考了。還有一個經典問題為什么Hive能直接用SQL因為它把SQL解析成抽象語法樹再轉成邏輯計劃、物理計劃最后提交到計算引擎執行。Spark部分常考RDD是什么、transformation和action的區別、寬依賴和窄依賴、DAG怎么生成、Spark為什么比MapReduce快內存計算、DAG計算模型、task復用、多線程。如果C卷有進階題還可能考Spark SQL和Hive的對比。2.4 數倉理論分層和建模是隱性考點很多自學大數據的人容易忽略數倉理論但這恰恰是數據開發筆試的隱性大頭。浩鯨這類做運營商數據平臺的公司對數倉分層、主題域劃分、指標口徑統一非常看重。數倉分層必考至少要知道ODS、DWD、DWS、ADS這一套經典分層每層的作用要說得清楚ODS原始數據層原樣落地不做過多的清洗加工保留全量歷史。DWD明細數據層清洗、規范化、維度退化、拉鏈表處理面向主題組織明細事實。DWS匯總數據層按維度預聚合形成寬表復用于多業務場景。ADS應用數據層面向具體報表和應用直接服務BI、大屏、經營分析。為什么分層答案不是“別人都這么分”而是解耦、復用、統一口徑、方便血緣追溯。一套科學的分層能讓不同團隊因為口徑問題吵架的概率大大降低。維度建模部分常考星型模型和雪花模型區別、事實表和維度表區分。有一類題是給了幾張表讓你判斷哪個是事實表哪個是維度表或者讓你設計一個用戶下單分析的數據模型。遇到這種題記住一個判斷標準事實表記錄“發生的事”有數字度量表會不斷增長維度表描述“事物的屬性”比如用戶性別、商品類目、門店名稱通常是緩慢變化的。2.5 代碼與邏輯題手寫WordCount到TopN編程題在C卷里一般一到兩道不會太難但很考驗基本工。最經典的是手寫WordCountMapReduce版和Spark版都要會。MapReduce版的關鍵是重寫map和reduce方法public static class TokenizerMapper extends MapperObject, Text, Text, IntWritable { private final static IntWritable one new IntWritable(1); private Text word new Text(); public void map(Object key, Text value, Context context) throws IOException, InterruptedException { StringTokenizer itr new StringTokenizer(value.toString()); while (itr.hasMoreTokens()) { word.set(itr.nextToken()); context.write(word, one); } } }Spark版本可以用Scala一行流式寫出來sc.textFile(input) .flatMap(_.split( )) .map((_, 1)) .reduceByKey(_ _) .sortBy(_._2, ascending false) .take(10)除了WordCountTopN也是高頻題。TopN的關鍵不在于排序本身而在于怎么減少數據傳輸如果數據量非常大應該在每個分區先求局部TopN再匯總求全局TopN。這個思路在MapReduce和Spark里都適用。邏輯題大概率有一道比如“25匹馬5個賽道最少比賽幾次找出前三”“燒繩子測45分鐘”這類題屬于考場上會就會、不會就懵的類型。我建議考前看一遍經典智力題的答案不求全背但求有個印象遇到類似的能順著思路走。3. 最容易翻車的幾類題目踩坑現場與正確的打開方式這一節我聊的是實戰中見過的高頻錯誤。很多人知識點都背過但做題時就是拿不到分原因往往不是不會而是踩進了特定的坑。3.1 窗口函數和group by放在一起錯誤示范與正確寫法窗口函數是數據開發筆試的分水嶺也是扣分重災區。最常見的錯誤是在一個查詢里先用了group by然后想在select里同時用窗口函數結果發現字段對不上。比如題目統計每個用戶的訂單總額并計算所有用戶訂單總額的排名。 錯誤寫法SELECT user_id, SUM(amount) AS total_amount, RANK() OVER(ORDER BY total_amount DESC) AS rk FROM orders GROUP BY user_id;很多數據庫會報錯因為SELECT里窗口函數引用了別名total_amount而別名的計算依賴于group by之后的聚合結果。嚴格來說有些引擎支持這種寫法比如Hive在某些配置下可以但在筆試中很容易翻車。正確寫法是SELECT user_id, total_amount, RANK() OVER(ORDER BY total_amount DESC) AS rk FROM ( SELECT user_id, SUM(amount) AS total_amount FROM orders GROUP BY user_id ) t;關鍵心得窗口函數在邏輯上是在group by聚合之后執行的。當你要對聚合結果繼續做排序、排名時一定要先子查詢把聚合結果算出來再在外面套窗口函數。這個結構幾乎是SQL大題的標準套路。還有一道容易錯的題目統計每個用戶的首單時間和最近一單時間。有些人會下意識用group by加min、max但題目可能要求同時輸出這些日期對應的訂單金額。min日期和訂單金額不能直接放在一起因為SQL引擎不知道要保留哪一行。正確做法是用窗口函數row_number分別按照正序和倒序排篩選出第一行。這類題考察的就是窗口函數能不能用得靈活。3.2 數據傾斜換個說法就認不出來的經典題數據傾斜是大數據崗位面試的常青樹筆試也經常出現但換個場景很多人就懵了。常見題目一個join任務卡在99%不動可能是什么原因你如何定位和解決定位思路要講清楚先看是不是有個reduce遲遲不結束再看是不是有某個key的數據量特別大。如果是Hive作業可以通過查看Counter確認某個reduce輸入記錄數異常。解決思路是分情況的如果傾斜是因為null值導致把null值加上隨機后綴比如concat(null_, rand())讓它們分散到不同reduce。如果傾斜是因為某個熱點key比如某個爆款商品的訂單量特別大可以對熱點key打散做兩階段join。第一階段給熱點key加隨機前綴與另一張表按打散后的key關聯第二階段再按真實key關聯。如果是group by傾斜先開啟map端聚合或者設置hive.groupby.skewindatatrue讓Hive自動生成兩階段MR。如果是Spark任務可以考慮用AQE的自動傾斜處理開啟動態優化也可以手動salting。光背答案容易翻車更好的方式是給一個具體的例子。我看到有位考生是這樣答的假設sales表和goods表關聯其中爆款商品id888的訂單占了一大半直接join會導致888這個key全部落到同一個reduce。他的方案是在map端識別出key888復制成888_0到888_9十個隨機key同時把goods表中id888的記錄也復制十份加上相同的后綴兩階段join后再去掉后綴合并結果。這個回答能拿高分是因為他不僅說出了方案還說出了為什么能解決數據傾斜的問題——把本來集中在一個節點的計算壓力分散到多個節點。3.3 Hive和Spark SQL的差異題別只背優缺點有一類對比題最讓人頭疼請說說Hive和Spark SQL的區別。很多人會背“Hive跑MapReduceSpark SQL跑內存Spark快”但這只是表面。更高質量的回答要提到幾個層面引擎層面Hive本身不是計算引擎是數據倉庫工具底層可以用MapReduce、Tez或者Spark作為執行引擎Spark SQL則是基于Spark核心引擎的查詢模塊走的DAG執行計劃。優化器層面Spark SQL有Catalyst優化器能做邏輯優化、物理優化、code generationHive也有CBO但整體優化能力在一些復雜SQL上不如Spark SQL。容錯和資源管理Hive的MR模型更成熟穩定適合超大離線批處理Spark的stage、task粒度更細并發度高但內存壓力大需要調優。適用場景Hive更適合遲到數據多、凌晨跑批、對穩定性要求極高的場景Spark SQL適合需要快速產出結果、復雜邏輯迭代計算的場景。筆試碰到這種對比題一定要從不同維度展開不要一句話結束。重點不是誰比誰好而是你展現出對兩個框架各自適用場景的理解。3.4 數倉分層的“為什么”答不出層次感分層題看起來很基礎但很多人只會背“ODS、DWD、DWS、ADS”一旦追問為什么就卡住了。我見過一個回答讓我印象很深刻他說“不分層也能做報表但所有報表都要直接讀ODS每個業務線都自己寫一套清洗邏輯。結果同一個指標銷售部算出來是1000萬市場部算出來是900萬。分層不是強制要求是當數據規模和應用場景復雜到一定程度后的必然選擇。”這個回答好在它給出了一個業務的視角。建議把分層的價值總結成四個點第一清晰的數據邊界和權限控制不同層對訪問者有不同權限第二統一的數據口徑指標在DWS算一次所有下游復用第三提高開發效率減少重復清洗計算第四方便數據血緣追蹤和問題回溯出錯了能快速定位是哪一層的問題。答題時不要只背概念最好帶一個實際場景。比如用戶下單表、支付表、退貨表分散在不同業務系統ODS層原樣接入DWD層統一格式化把各種ID統一成用戶IDDWS層按天聚合出每個地區每個品類的GMVADS層直接給大屏顯示。這樣講面試官就知道你真正干過而不是只在書上看過。4. 比刷題更重要的把筆試答案變成面試表達能力很多考生筆試分很高面試卻表現平平原因是把筆試和面試當成了兩件完全不相干的事。實際上筆試里的答案就是面試最好的素材關鍵是怎么用。4.1 答題時的“過程感”讓閱卷人看到你的思路我幫人改筆試答案時發現很多人在卷面上只寫最后結果比如SQL只寫一條長長的查詢中間所有思考過程都省略了。這會吃大虧。簡答題比如“HDFS寫數據的流程”不要只寫“Client聯系NameNode然后寫DataNode”。最好按順序寫清楚Client向NameNode發起寫請求NameNode檢查文件是否存在、權限是否足夠Client按數據塊大小把文件切分Client向NameNode請求第一個塊的DataNode列表數據以packet為單位按管道方式依次寫入多個DataNode每個DataNode寫完本地并校驗后ack逐級返回所有塊寫完后NameNode接收完成確認更新元數據。這種回答有過程有細節閱卷人一眼就能看出你是真懂還是只會背結論。筆試不是寫給自己看的是寫給閱卷人看的。你要做的是把腦海里的知識用文字完整地“播放”一遍。4.2 項目經驗怎么講才有區分度面試一定會問項目。很多人的項目是培訓班或者課程設計出來的講起來全是“實現了用戶畫像系統”“搭建了數據倉庫”聽起來很空洞。有區分度的講法一定要包含數據量和問題背景。比如“我參與的是一個日活約500萬的電商數倉項目原始數據在ODS層一天新增大概1TB。我負責DWD層訂單事實表的建設期間遇到一個最大的問題是訂單表和支付表的join在生產環境發生了嚴重的數據傾斜某個大商家的訂單量占了全天的30%。我通過打散熱點key和兩階段join解決了這個問題把作業時長從40分鐘壓到了18分鐘。”同樣的項目加上數字、加上問題、加上解決方案效果完全不同。面試官想聽到的不是羅列工具而是你在這個項目里碰到過什么困難怎么定位怎么解決。如果項目是真實的這些問題一定存在如果是虛構的那么就問自己這個項目中最大的技術難點是什么如果答不上來建議不要寫在簡歷上。4.3 “說人話”的能力數據開發面試的隱形考察點數據開發不是純技術崗位它和數據產品、業務運營緊密相連。面試官經常會問“你能不能用通俗的話解釋一下數據倉庫為什么要分層”這就是在考察你跨部門溝通的能力。如果只會背概念很容易被判定為“只能悶頭寫SQL說不清業務”。更好的回答是“你想象一個餐廳不做分層的做法是每個服務員自己去菜市場買菜、洗菜、切菜、炒菜做完一桌再跑下一桌每個服務員都有自己的做法有的咸有的淡。分層的意思就是有人專職買菜、有人專職切配、有人專職掌勺最后出品統一效率也高。”技術人最忌諱的是“用術語解釋術語”。數據開發面試到后半場面試官往往會故意問一些大白話問題看你能否瞬間切換視角。平時練習的時候建議把每個核心知識點都試著講給一個不懂技術的人聽講不通說明你自己還沒吃透。5. 一份可以直接抄的備考路線時間分配與自測清單如果距離筆試還剩一個月請按下面的節奏安排比半夜刷一堆算法題要有效得多。5.1 第一階段打底SQL、Java和Linux前十天把重心放在SQL上每天至少4道SQL題。不要只看題解要親手在環境里跑一遍。沒有大數據環境也沒關系本地裝個MySQL或者SQLite練基本查詢窗口函數用PostgreSQL或者SQL Server的在線練習環境都可以。SQL語感這種事沒有捷徑只有多寫。Java和Linux這段時間穿插復習每天半小時。Java重點看HashMap、ArrayList、線程、JVM分區Linux重點看文件操作、進程管理、磁盤網絡、權限相關命令。不求面面俱到但高頻題必須會。5.2 第二階段主攻組件原理與數倉設計第二個十天進入大數據組件。HDFS讀寫流程、MapReduce Shuffle、Hive架構和內部外表區別、Spark RDD寬窄依賴和作業執行流程這幾個必須能默寫出來。數倉方面重點準備分層架構、事實表維度表、星型模型雪花模型、拉鏈表、緩慢變化維。其中拉鏈表是很多考官愛問的知識點因為日常數倉開發確實會用到而且能考察你對“全量快照對存儲消耗太大”這個問題的理解。這個階段可以動手做一個小項目練手不用很復雜自己造幾十萬條訂單數據用Hive或者Spark做一次數倉分層加工ODS到DWD再到DWS最后統計出GMV。整個過程實操下來比看十篇教程都有用。5.3 第三階段真題模擬與錯題復盤最后一周進入沖刺模式。找2到3套同類型公司的筆試真題嚴格計時做一遍不查資料。做完以后不要只看對錯要把每道錯題對應的知識點標出來回到原理層面重新過一遍。錯題復盤比刷新題重要得多。我當年的習慣是準備一個markdown文件命名為“錯題.note”每道錯題記錄三部分題目是什么、我錯在哪、正確答案的核心思路是什么。考前只需要翻這個文件就夠了。你會發現錯誤往往高度集中在幾個知識點上比如窗口函數排序方向搞反、shuffle階段記憶混亂、拉鏈表場景不會判斷。把這些坑填平比做十套新題都有效。5.4 筆試前夜的自查清單臨考前一晚不建議再刷題建議對著清單自問一遍掃盲窗口函數 rank、dense_rank、row_number 的區別和寫法能寫對嗎HDFS 寫入流程能從 Client 請求到 ack 返回完整復述嗎內部表和外部表的區別刪除表時數據會不會消失能一句話說清嗎寬依賴和窄依賴怎么區分分別對應哪些算子數倉分層為什么不是越多越好結合實際怎么權衡手寫 WordCountMapReduce 和 Spark 兩個版本都能默寫嗎如果一份 SQL 跑得很慢你有排查思路嗎這些問題如果都能順利答出來筆試基本穩了。如果有一兩個說不清恭喜你你找到了考前最需要補的缺口。數據開發筆試說白了就是一場“基本功踩坑經驗”的檢驗。基本功決定你有沒有資格進場踩坑經驗決定你能不能在場上穩住不丟分。這張2020屆的C卷雖然年份久遠但背后考察的能力模型幾乎沒有變化。把上面的東西吃透不管換成A卷還是B卷你都不會慌。