不必繞彎子直接說結論這套京東2018秋招數據開發工程師筆試題放在今天依然有很高的參考價值尤其是準備大廠數據崗位面試的朋友值得拿它做一次系統性自測。原因很簡單——數據開發這個崗位的考察范圍這么多年核心框架沒有變SQL功底、數倉建模思維、Hadoop生態理解、Java與算法底子、以及把業務問題翻譯成數據方案的能力。題目形態會變但底層考察點高度穩定。這篇文章不打算只把題干復述一遍。我按自己的理解把這套題拆成幾個能力維度挑幾道典型題目做完整拆解再延伸一下從筆試到面試的備考路線。無論你是準備校招、跳槽還是想驗證一下自己的知識體系有沒有短板按這個思路走一遍會很有收獲。1. 這張卷子到底在考什么拆解數據開發崗位的四大能力象限先聊一個很多人會忽略的問題數據開發工程師的筆試看起來題目零散其實每個板塊都在精準地篩人。京東這套題從整體結構看主要落在四個象限里。1.1 SQL和數據倉庫大題的主戰場SQL不是簡單的“會不會寫”而是考察你在數據量爆炸的情況下能不能寫出正確且高效的查詢。筆試里的大題幾乎清一色是SQL場景題給你幾張業務表讓你統計留存率、復購率、Top N、連續登錄天數這類指標。這類題表面考語法實際考三件事第一你能不能看懂業務表結構快速建立字段之間的關聯關系第二你會不會用窗口函數、CASE WHEN、多表關聯這些核心工具組合解題第三你的查詢方案在數據量大的情況下能不能跑得動。我當時復習時的一個感受是前期刷題很容易陷入“為了寫對而寫對”寫完一提交通過了就不再管了。后來發現這是個大坑——筆試判卷雖然看結果但面試官面試時一定會追問“你這個SQL在大數據量下有什么風險”“還有沒有更優寫法”。所以準備的時候每道題都該問自己一句如果這張表有十億行我的寫法還能不能撐住。1.2 Hadoop生態從背概念到畫數據流數據開發崗位筆試幾乎必考Hadoop生態但考察深度越來越偏向“理解原理”而非“背誦定義”。比如MapReduce的shuffle過程、Hive的架構、HBase的讀寫路徑、Zookeeper的角色與選舉機制。背概念為什么不夠用因為筆試題目會換著花樣考。一個常見問法是給你一個業務場景讓你設計一套從數據采集到數據落地的完整流程并說明每一步選型理由。這已經不是“什么是Hive”這種題了而是考察你有沒有真正理解每個組件能解決什么問題、瓶頸在哪里、組件之間怎么配合。我的建議是不用急著背幾十個組件先把一條主線理清楚數據從哪里來采集——放在哪里存儲——怎么處理計算——怎么服務業務查詢/OLAP。每個環節的主流組件、核心原理、優缺點以及組件之間的替代關系這些理清了大部分Hadoop生態的題都能應對。1.3 Java與算法容易被忽視的“內功”數據開發工程師日常主要寫SQL和Shell但筆試偏偏喜歡考Java基礎和算法題原因很直接——大廠要篩出那些具備扎實編程底子的人而不是只會套模板的“SQL boy”。Java部分常考的知識點包括集合類源碼原理HashMap的put流程、擴容機制、并發與多線程synchronized與ReentrantLock的區別、線程池參數含義、JVM內存區域劃分與GC基本策略。算法部分則主要集中在數組、鏈表、字符串、二叉樹、動態規劃、排序這幾個常規類別上。很多數據方向的同學覺得算法是后端崗位才需要準備的這是誤解。筆試環節算法的占比可能不高但只要出了一道分值往往不小。而且根據我的經驗技術面、總監面都有可能出現手撕代碼環節算法不準備后續面試會非常被動。1.4 業務場景與數據建模思維這是最容易丟分、也最考區分度的部分。京東是電商公司它的數據場景天然豐富用戶、商品、訂單、交易、物流、營銷每個環節都有大量經典分析需求。題型通常是這樣給你一個業務問題比如“分析近期某品類商品的銷售情況”讓你結合可用數據、明確分析思路、設計指標體系、規劃數據表結構。這已經超出了一道SQL題或者一道概念題的范圍它要求你具備數據產品思維——能理解業務方的真實訴求能拆解問題能落到具體的數據方案上。我遇到不少基礎很好的候選人在這個板塊丟分。原因是他們習慣做“給定表和需求寫SQL”的題目一旦需求變成開放式的就不知道從哪里下手。破解方法也很簡單平時多接觸業務多思考數據模型為什么這樣設計刷題時遇到開放題不要急著看答案先自己寫分析框架。2. 幾道值得反復咀嚼的原題附帶完整解析題目的具體表述會因年份批次略有出入但考察點高度一致。以下我用同類型的場景來還原并給出完整解法思路。2.1 經典SQL窗口函數題連續登錄N天的用戶場景是這樣有一張用戶登錄日志表login_log包含user_id和login_date兩個字段要求統計連續登錄3天及以上的用戶數。再復雜一點的版本會要求統計每個用戶最長連續登錄天數。第一步要建立“每個用戶每天只有一條記錄”的假設所以先對原始表按user_id、login_date去重這一步很多人的答案漏掉會直接導致結果錯誤。第二步是核心技巧對每個用戶按登錄日期排序用日期減去排序序號得到一個日期差字段。因為連續登錄的日期差是相同的不連續的日期差會跳變。再按user_id和日期差分組統計組內記錄數就能得到每一段連續登錄的時長。能寫出這個思路說明你已經吃透了窗口函數和日期計算的配合。但一個更優的解法是用lag函數通過lag(login_date, 1) over (partition by user_id order by login_date)構造上一行的登錄日期再判斷當前日期與上一行日期的差值是否為1標記出連續區間的斷點。這種寫法在理解上稍微繞一點但在某些數據量極大的場景下中間結果的行數會少很多。我建議兩個方法都掌握。筆試時用自己最熟練的面試被追問時可以主動提一下“另一個方案是使用lag函數”面試官會認為你確實理解多種解法的適用邊界。2.2 數據傾斜場景設計題Reduce階段不均衡Hadoop/Spark場景題里數據傾斜是最高頻的考點。典型問法跑一個join任務其中一個表里某個key的數據量特別大導致大部分數據都跑到同一個Reduce上任務嚴重拖慢你怎么解決。這類題的常規解法有以下幾個層級第一層過濾異常數據。如果是業務上的臟數據或者無效數據比如用戶ID為空的記錄直接過濾掉這一步往往能解決絕大部分傾斜問題。第二層加隨機前綴。把傾斜的key打散比如給傾斜key的值拼一個隨機數1到n然后對另一個表的關聯字段也做相應擴展通過“膨脹”小表來實現數據分散。代價是計算量增加但能有效避免單點壓力。第三層兩階段聚合也就是局部聚合加全局聚合。先給key加隨機前綴做一次預聚合去掉前綴后再做一次全局聚合。這個方法特別適合count、sum這類聚合型傾斜。第四層從源頭優化。如果傾斜是Join引起的大key與小表關聯可以考慮將小表廣播到每個節點用MapJoin代替ReduceJoin從根本上避免shuffle。面試時不能只說一個方案而是要說清楚先定位傾斜發生在哪個階段、傾斜的key是什么類型然后根據不同原因選擇不同方案。這才是考察的真正意圖。2.3 Hive全排序order by與sort by的區別SQL中order by很好理解全表排序。但在Hive里order by會強制走一個Reduce全量數據在一個節點上完成排序數據量一大基本跑不動。所以Hive里更常用sort by它在每個Reduce內部排序多個Reduce之間不保證全局有序。有一個很經典的組合distribute by sort by。比如需要按日期分區輸出且每個分區內有序可以distribute by日期字段sort by排序字段。這樣每個日期對應的數據會進入同一個Reduce并在該Reduce內完成排序兼顧了效率與局部有序性。筆試經常在這個點上設置陷阱直接讓你用order by實現全排序然后問如果數據量達到TB級怎么辦。如果基礎不牢很容易直接寫上order by完全沒有意識到這個方案在大數據量下根本跑不起來。所以這類題的真實考察點不是你能不能寫出排序SQL而是你知不知道Hive的底層執行機制。再延伸一個點如果只是去重用distinct或group by都行但數據量大的情況下group by配合適當的分桶往往更高效因為它天然可以并行去重。很多人在這類題目上失分不是不會寫而是不知道不同寫法在引擎內部執行路徑差異很大。2.4 Java基礎與HashMap源碼數據崗筆試題Java部分最常見的一道題是HashMap的底層數據結構是什么put一個key-value時發生了什么什么時候觸發擴容為什么容量是2的冪次底層數據結構數組加鏈表鏈表長度超過8且數組長度超過64時鏈表會轉為紅黑樹。put流程先對key做hash高低位異或后計算數組下標如果有沖突用equals比較key相同就覆蓋不同就掛在鏈表或紅黑樹上。擴容機制默認初始容量16負載因子0.75當元素個數超過容量乘以負載因子時擴容為原來的2倍。為什么容量必須是2的冪次因為計算下標用的是(n - 1) hash只有當n是2的冪次時n減1的二進制才是全1hash值與它做位與運算才能均勻落在數組區間內同時這個操作比取模運算更快。面試官還可能追加追問為什么不直接使用hashcode作為下標因為hashcode是int類型取值范圍很大無法直接映射到數組上需要二次處理。這也是為什么需要先擾動異或高低位再位運算定位下標。這些問題看著基礎但能深入講透的人并不多。背會一個流程容易能把每一步的“為什么”解釋清楚才算真正掌握。3. 從筆試題延伸到面試環節你還需要準備這些筆試通過只是第一關緊接著的技術面往往圍繞筆試內容展開追問。很多候選人筆試分數不錯但一到面試就露餡。3.1 簡歷項目與筆試知識點的對應關系面試官拿到你的簡歷后會挑一個你最熟悉的項目然后層層深挖。但深挖的方向往往和筆試知識點高度重合——你做完一個離線數倉項目他一定會問你的數據清洗怎么做Hive調優做過哪些數倉分層有哪幾層每層怎么劃分遇到過數據傾斜嗎怎么解決的所以在準備面試時不要孤立地回顧項目而要把項目的每一個技術決策都跟筆試知識點掛鉤。比如簡歷里寫了“使用Hive進行ETL”就要準備好回答Hive執行引擎、分區與分桶的區別、小文件問題、UDF編寫方法等延伸問題。一個實用的準備方法把你項目里用到的每一個組件列出來再為每個組件寫下3到5個常見的追問方向逐條準備答案。這個過程能暴露大量知識盲區比盲目刷題有效得多。3.2 數據倉庫維度建模必問清單數倉建模是數據開發面試的核心面試點也是筆試開放性大題常在的背景。面試官偏好考查維度和事實表的區別、星型模型和雪花模型的區別、緩慢變化維的處理方式。維度表存儲描述性信息事實表存儲度量值。星型模型適合查詢性能要求高的場景維度表直接與事實表關聯結構簡單、冗余可控雪花模型將維度表規范化拆分減少冗余但會增加關聯層級查詢性能相對下降。對于絕大多數業務場景星型模型是首選。緩慢變化維是另一個高頻考點。最常用的是SCD2——在維度表里增加生效日期、失效日期、當前標識三個字段歷史記錄和當前記錄并存能夠完整追蹤變化軌跡。但它的代價是下游取數邏輯變復雜維度表數據量也會膨脹。很多人只記住了“SCD2能記錄歷史變化”但答不出“什么業務場景適合SCD2什么場景用SCD1就夠”“維度表膨脹后的處理策略有哪些”深度不夠。3.3 手撕代碼的常見變形手撕代碼不必追求刷完上千道題把高頻類型練熟更重要。數據崗的算法題通常不會太難LeetCode中等難度基本夠用。重點放在以下幾類數組與雙指針類比如兩數之和、三數之和、合并兩個有序數組鏈表類比如反轉鏈表、判斷是否有環、找中間節點字符串類比如最長公共前綴、無重復字符的最長子串二叉樹類比如層序遍歷、最近公共祖先動態規劃類比如爬樓梯、最長遞增子序列、背包問題原型。寫代碼時注意幾點先和面試官確認輸入輸出與邊界條件再動手寫完不要急著說“OK了”自己走一遍簡單測試用例最后用自然語言講一遍你的復雜度和優化空間。很多候選人代碼寫對了但因為只講了“我是這么寫的”沒有講“為什么這么寫”分還是上不去。3.4 開放題的回答思路開放題在數據崗面試里幾乎必出比如如果讓你設計一個訂單分析系統你怎么做或者某品類銷量下降你會如何排查原因這類題沒有標準答案但有一個比較穩妥的回答結構先明確問題邊界再拆解影響面再給出數據方案最后說明落地路徑。以“銷量下降”為例先限定品類、地區、時間范圍拆解影響因素包括流量側曝光、點擊、轉化、商品側價格、庫存、差評、渠道側活動、投放、競品側對應每個因素規劃需要哪些數據再基于數據倉庫設計出指標看板或專題分析定位真正的下降原因。核心是結構化思維。答得簡潔、層次清楚、能落地比給出一個看似完美的方案更重要。因為面試官要的不是正確答案而是你處理模糊業務問題的思維方式。4. 備戰這種筆試按這個路線走比較穩最后聊一聊備考路線這部分是純個人經驗分享不帶通用模板的“權威性”但都是我實際走下來覺得有效的方法。4.1 時間分配建議如果你的復習時間有四周我的建議是這樣分配第一周重點過SQL和數據倉庫理論把所有常用窗口函數、聚合函數、表關聯方式用熟第二周集中刷Hadoop生態的基礎原理重點理解MapReduce、Hive、Spark的執行流程不要只背概念第三周補Java基礎與算法優先復習HashMap/HashSet源碼原理、多線程基礎以及LeetCode高頻題第四周全身心投入到開放題和項目梳理把簡歷里面每一個項目都寫成可以應對深挖的版本。這個順序的邏輯是SQL和數倉是立身之本先解決生態原理決定你能不能回答“為什么這么選型”是區分度所在Java和算法是隱性淘汰項不能留明顯短板最后一周的開放題和項目梳理是把前面所有知識點串聯起來的關鍵。4.2 我自己踩過的坑第一個坑刷SQL題時只看答案不練。早期我遇到不會的題就直接翻題解看完覺得自己懂了但到筆試現場稍微一變體就卡住。后來改成每個題目先獨立思考30分鐘再對比題解效果完全不一樣。第二個坑背原理不畫圖。學MapReduce時把流程背得滾瓜爛熟但面試官讓我畫一下數據流的走向一下子就蒙了。原理類知識點一定要動手畫圖把每個階段輸入輸出畫清楚畫過一遍才算真正理解。第三個坑不重視小文件問題。筆試時覺得自己把SQL寫對就萬事大吉了完全沒考慮生產環境里小文件過多導致NameNode壓力、Spark任務調度變慢的問題。現在只要涉及Hive表設計我都會主動提一下文件格式、壓縮方式、小文件合并策略這個意識在面試中非常加分。第四個坑臨時抱佛腳準備系統設計題。數據開發面試很可能會問到“你怎么設計一個數據平臺”這類系統設計題如果只是臨時背幾篇面經很難把存儲、調度、計算、服務幾個環節講順。建議提前畫一版自己理解的數據平臺架構圖并把每個環節的選型理由想清楚。4.3 實用資源與自測方法SQL練習方面除了常規的刷題網站強烈建議自己造數據練手。可以設計一個簡單的電商模型自己造幾張表用戶表、訂單表、商品表把銷售分析、留存分析、復購分析這些常見需求全部寫一遍SQL。這個過程非常貼近真實工作。原理學習方面Hadoop生態不需要抱著厚重的書啃先看官方文檔的核心篇或者直接看各個組件的架構設計類文章抓住“組件解決什么問題、核心架構是什么、關鍵流程有哪些”這幾個點即可。算法方面建議按標簽集中刷題而不是隨機亂刷。每天一類比如今天只做鏈表、明天只做二叉樹。控制在這個強度兩周就能覆蓋大部分高頻考點。最后提供兩個自測方法一是限時模擬給自己一次性做完整套題嚴格卡時間檢驗自己在筆試狀態下的真實水平二是講題復述把你做過的每道題用口述的方式講給朋友聽或者對著錄音講如果講不出來說明你還沒有真正理解。這個方法尤其適用于SQL題和數倉建模題。準備數據開發崗位的筆試和面試本質上是一個把零散知識點織成網的過程。單個知識點不難難的是當你面對一道綜合題時能不能快速定位它考的是哪幾個點、它們之間如何聯動。京東這套題的價值就在于覆蓋面廣、貼近業務、深度和廣度兼顧。如果你能把本文提到的幾個維度全部吃透再借這套題做一個自我檢驗我相信你會對自己的狀態有一個非常清晰的認識。最后再分享一個我的切身體會不要只盯著“通過筆試”這個目標。真正讓你在后來的面試中脫穎而出的往往是那些你為了通過筆試而認真研究過的“為什么”。對每一個關鍵知識點多問一句“為什么”再深挖一層這既是一種備考策略也是數據開發這個職業本身最需要的能力。