2023年春招騰訊音樂的數(shù)據(jù)工程崗筆試放在第一批說實話這個時間點挺考驗人的。大部分人的春招節(jié)奏還停留在“過完年再說”的狀態(tài)結果招聘流程說開就開不少人是在完全沒準備的情況下被拉進考場的。我身邊就有朋友考完出來直搖頭說題目看著不難但時間根本不夠用SQL剛寫完一大半編程題還沒碰就交卷了。這篇文章我就結合那批筆試的實際考察邏輯聊聊數(shù)據(jù)工程崗的筆試到底在篩什么人、題目背后考的是什么能力、以及怎么在有限時間內把分拿滿。如果你現(xiàn)在正在準備大廠數(shù)據(jù)工程崗的校招筆試或者之后打算投騰訊音樂相關的數(shù)據(jù)崗位這篇文章會把整個筆試的考察框架、實戰(zhàn)策略和容易忽略的細節(jié)拆開講清楚幫你少走彎路。1. 數(shù)據(jù)工程筆試和普通后端/算法筆試篩選邏輯完全不一樣很多人在準備數(shù)據(jù)工程崗筆試的時候容易犯一個方向性的錯誤照著后端開發(fā)崗或算法崗的題庫刷。結果就是選擇題里的JVM調優(yōu)、紅黑樹旋轉看得一頭霧水編程題死磕動態(tài)規(guī)劃最后真正該拿分的SQL反而沒有時間練。1.1 數(shù)據(jù)工程崗考核的三個層次數(shù)據(jù)工程崗日常做什么本質上就三件事把數(shù)據(jù)從A點搬到B點過程中保證數(shù)據(jù)不丟不重不錯把雜亂的數(shù)據(jù)加工成可分析的形態(tài)讓整個數(shù)據(jù)鏈路跑得穩(wěn)、跑得快。因此筆試考的不是某個單一技能而是圍繞這三件事分層次考察。第一層是數(shù)據(jù)基礎能力。SQL是絕對的核心這幾乎是所有數(shù)據(jù)工程崗筆試的共識騰訊音樂也不例外。它考的不只是會不會寫select、join而是能不能處理真實業(yè)務里常見的復雜查詢場景比如連續(xù)登錄、留存計算、同環(huán)比、窗口函數(shù)排序。第二層是大數(shù)據(jù)生態(tài)的知識廣度。數(shù)據(jù)工程離不開分布式計算框架所以Hadoop、Spark、Flink、Kafka這些組件會被反復提及。這個層次的考察方式通常是選擇題或簡答題重點看你是否理解這些組件的基本原理、適用場景和常見問題的排查思路。第三層是編程與工程能力。畢竟數(shù)據(jù)工程師也寫代碼尤其是寫數(shù)據(jù)處理邏輯。筆試里的編程題一般不會出特別偏難怪的算法更多是考察你用代碼解決實際數(shù)據(jù)問題的能力比如解析日志、實現(xiàn)一個簡單的聚合邏輯。1.2 騰訊音樂筆試的風格特點騰訊音樂的筆試整體風格偏向務實或者說“業(yè)務導向”。同一套題里可能會出現(xiàn)某個音樂App的真實業(yè)務場景比如統(tǒng)計某首熱門歌曲的播放量、分析用戶聽歌時長分布讓你在熟悉的業(yè)務背景里完成數(shù)據(jù)處理任務。這種出題方式的好處是它不是死板地考語法而是考你面對真實業(yè)務需求時能不能快速轉化成可執(zhí)行的查詢邏輯。另一個特點是時間緊湊。整個筆試時間一般控制在90到120分鐘但題量并不算少要涵蓋選擇題、SQL題、編程題有時還會有簡答題。如果你在某道SQL題上糾結太久后面的編程題很可能來不及寫。1.3 崗位JD與筆試內容的對應關系投遞崗位的時候可以留意一下JD里的關鍵字。騰訊音樂數(shù)據(jù)工程崗的JD里往往會出現(xiàn)“數(shù)據(jù)倉庫”“ETL”“數(shù)據(jù)質量”“Spark”“Flink”這些詞這些關鍵字基本預告了筆試的重點。如果JD重點提了數(shù)據(jù)倉庫那SQL題大概率考數(shù)倉建模相關的內容比如維度建模、拉鏈表設計如果重點提了實時計算那Flink相關的知識點肯定會出現(xiàn)在選擇題里。拿著JD去反推筆試范圍比漫無目的地刷題高效得多。2. 題型盤點選擇題、SQL題、編程題和場景題各自的考察重點根據(jù)那批筆試的反饋來看題型基本固定但每個題型的側重點和平時刷題的感覺不太一樣。我先逐類拆一遍。2.1 選擇題大數(shù)據(jù)組件原理和基礎知識覆蓋面廣選擇題大概占30%左右的分值覆蓋面非常廣。我印象比較深的幾個方向是這樣Hadoop相關問得最多的就是HDFS讀寫流程、NameNode和DataNode的角色分工、MapReduce的Shuffle過程。比如“HDFS默認副本數(shù)是多少”這種基礎題基本屬于送分題但“MapReduce中Shuffle階段的作用是什么”這種題就需要你真正理解整個計算流程。Spark是選擇題里的重頭戲。RDD、DataFrame、Dataset三者的區(qū)別寬依賴和窄依賴的判斷Stages劃分機制Spark作業(yè)提交流程Client模式與Cluster模式的區(qū)別這些問題反復出現(xiàn)。建議準備的時候重點搞懂“寬依賴和窄依賴如何影響Stage劃分”這個點因為它是很多Spark相關題目的底層邏輯。Flink在騰訊音樂的筆試里出現(xiàn)頻率也不低畢竟音樂平臺的實時推薦、實時榜單都離不開Flink。狀態(tài)管理、Checkpoint機制、事件時間與處理時間的區(qū)別、Watermark的作用這幾個知識點要熟練。有一個很容易考的點是“Flink如何保證精確一次語義”要能說清楚Checkpoint和兩階段提交配合的原理。消息隊列Kafka同樣繞不開。分區(qū)與副本的概念、消費者組如何管理位移、消息會不會丟失生產(chǎn)者、Broker、消費者三個層面分別怎么保證這些需要理解到位。還有一個容易被忽視的點是基礎數(shù)據(jù)結構和計算機網(wǎng)絡。我見過有選擇題考到TCP三次握手、HTTP狀態(tài)碼的含義如果你大學學的東西忘得差不多了建議考前快速過一遍不用太深但基本概念得撿起來。2.2 SQL題筆試題的拉分項也是刷人最狠的部分SQL題往往是整張卷子里分值占比最高的單項而且一旦寫錯幾乎沒有蒙對的概率。那批筆試的SQL題大概有3到4道難度從入門到進階遞進。入門題一般是單表查詢或簡單的兩表連接考最基本的語法比如按某個字段分組統(tǒng)計、過濾條件組合。這類題是送分題但要注意別在細節(jié)上丟分比如COUNT和COUNT(DISTINCT)的區(qū)別、NULL值的處理方式。進階題就開始上難度了。窗口函數(shù)是必考的ROW_NUMBER()、RANK()、DENSE_RANK()三兄弟的區(qū)別、SUM() OVER()跑批計算、LAG()和LEAD()取前后行數(shù)據(jù)這些是最基礎的窗口函數(shù)操作。考法通常是這樣的給你一張用戶聽歌記錄表讓你統(tǒng)計每個用戶聽歌時長的累計值或者找出每個用戶聽得最多的前三首歌。還有一個?？嫉念}型是連續(xù)問題比如統(tǒng)計連續(xù)登錄N天的用戶。這種題用窗口函數(shù)做非常方便核心思路是用日期減去ROW_NUMBER()的序號得到一個分組標識然后按這個標識分組統(tǒng)計。我第一次見到這個思路的時候覺得非常巧妙理解了之后SQL能力會有一個明顯提升。那批筆試里還出現(xiàn)了一道被很多人討論的題統(tǒng)計每分鐘在線聽歌人數(shù)的峰值。這類問題本質上是個時間區(qū)間重疊問題思路是把每條記錄拆成開始事件和結束事件然后用SUM() OVER()做事件流累加峰值就是累加過程中的最大值。這類題在LeetCode上叫“會議室II”或者“卡車占用車位”但套上聽歌場景之后對數(shù)據(jù)工程崗來說更貼切。2.3 編程題難度適中重在實際問題的解決編程題一般有兩道左右可以用Python或Java寫。和算法崗動輒困難難度的動態(tài)規(guī)劃題不同數(shù)據(jù)工程崗的編程題更偏向“用代碼處理實際數(shù)據(jù)”考法通常是給定某種格式的日志文件或數(shù)據(jù)流讓你寫代碼完成某個統(tǒng)計任務。比如給定一個包含用戶ID、歌曲ID、播放時間戳的日志列表統(tǒng)計每首歌的獨立播放用戶數(shù)或者給定一批包含開始時間和結束時間的記錄找出所有存在沖突的時間段。這種題要求你熟悉Python里字典、集合、列表的基本操作能快速把思路轉化成代碼。還有一類題是自選實現(xiàn)某種數(shù)據(jù)結構比如手寫一個帶過期時間的緩存、實現(xiàn)一個簡單的LFU緩存這其實是在考察你對生產(chǎn)環(huán)境中常見問題的理解比如需要緩存熱點歌單數(shù)據(jù)時怎么處理過期和淘汰。需要注意編程題的判題環(huán)境一般比較嚴格你要自己處理輸入輸出格式。很多人不是思路不對而是卡在了輸入輸出的解析上這在平時用LeetCode刷題時不太容易暴露因為LeetCode已經(jīng)把輸入輸出處理好了。2.4 場景題/設計題隱藏在簡答里的加分項有些場次會包含一兩道簡答或場景設計題比如讓你設計一個音樂播放量實時統(tǒng)計方案或者問你“如果數(shù)據(jù)倉庫里某張表的任務失敗了你如何排查”。這類題看起來開放但其實考察的是你對完整數(shù)據(jù)鏈路的理解。設計實時統(tǒng)計方案時可以從數(shù)據(jù)接入Kafka、實時計算Flink、結果存儲Redis或ClickHouse三個層面回答每一步說清楚用的組件和原因。任務失敗排查則可以從調度日志、上游依賴、數(shù)據(jù)傾斜、資源不足幾個方向展開。開放題沒有標準答案但一定要展示出結構化的思維——分步驟、分模塊地組織你的回答讓面試官能通過筆試看到你解決問題的思路這本身就是一種能力證明。3. 做題順序和時間分配決定你能否把會做的題都做完那批筆試最大的坑不是題目難而是時間不夠用。很多人栽在“先做選擇題再做SQL最后做編程題”這個順序上結果選擇題消耗了太多精力SQL沒寫透編程題直接空白。這里我分享一套經(jīng)過驗證的時間分配策略。3.1 拿到試卷先花3分鐘看全貌不要上來就埋頭做題。先花兩三分鐘把整張試卷從頭到尾翻一遍搞清楚每類題有多少道、每道題大概多少分、難度感覺如何。這能幫你在心理上建立一個全局觀知道哪些題是穩(wěn)拿分的、哪些題需要沖刺。一套比較合理的分配方案參考下面這個表格題型建議用時做題策略選擇題20-25分鐘會做的直接選不會的先跳過每道題不超過1分鐘SQL題35-45分鐘先寫有把握的題難題留到最后編程題25-35分鐘至少保證一題完整提交另一題寫出核心思路檢查5-10分鐘重點檢查SQL字段名、表名、邊界條件3.2 做題順序先做最優(yōu)性價比的題我的建議是如果試卷整體題量較大先用幾分鐘快速掃一遍所有SQL題和編程題判斷哪些是自己有把握的優(yōu)先做這些。原因是SQL題和編程題分值高、區(qū)分度強是決定你能否進入面試環(huán)節(jié)的關鍵。選擇題就算全對如果SQL和編程拉胯總分也不會好看。反過來如果SQL和編程答得不錯選擇題錯幾道影響不大。具體操作可以這樣優(yōu)先做所有你一看就有思路的SQL題再回頭做選擇題中會做的題接著做編程題里最有把握的那道最后利用剩余時間去磕難題。這個順序看起來跳來跳去但確實能在有限時間里拿到最多分數(shù)。3.3 編程題的保底策略不追求滿分追求有提交編程題如果完全沒寫基本等于直接放棄一整塊的分。哪怕時間再緊也要保證至少一道題有一個能跑通的版本。一個很實用的保底策略是先把暴力解法寫出來并確保它能正確計算小規(guī)模輸入。很多時候暴力解法能幫你拿到一部分測試用例的分數(shù)而且能在寫的過程中慢慢優(yōu)化思路。另一個策略是如果某道編程題完全沒思路就把你能夠想到的步驟用偽代碼或者注釋寫出來同時給出你的基本思路。這在人工閱卷的情況下有一定概率拿到過程分。我這么說吧筆試不是競賽不是為了拿滿分而是為了在有限時間內證明你具備基本的數(shù)據(jù)處理能力。一道能跑通的簡單題遠比一道寫了一半的難題有價值。4. 幾類高頻SQL題的破題思路從聽懂到能寫對SQL題考來考去翻來覆去就是那幾類經(jīng)典題型。這里我挑了幾個高頻方向把核心思路完整拆解一遍你如果能把這些題型的代碼熟練掌握筆試的SQL部分基本穩(wěn)了。4.1 窗口函數(shù)不只是會寫要理解它的執(zhí)行邏輯窗口函數(shù)是數(shù)據(jù)工程崗SQL題的核心工具。很多看起來復雜的SQL問題一旦想到用窗口函數(shù)解法就變得非常簡潔。窗口函數(shù)的執(zhí)行順序要牢記先WHERE過濾再GROUP BY分組然后窗口函數(shù)計算最后ORDER BY排序。注意WHERE在窗口函數(shù)之前執(zhí)行所以你不能在WHERE里直接使用窗口函數(shù)的別名。以“統(tǒng)計每個用戶聽歌時長的累計值”為例SELECT user_id, song_id, play_ts, SUM(play_duration) OVER (PARTITION BY user_id ORDER BY play_ts ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW) AS cum_duration FROM play_log;這里面有幾個關鍵點PARTITION BY表示按用戶分組ORDER BY表示組內排序ROWS BETWEEN...AND...定義了窗口的范圍。理解這三者的組合關系你就能寫出從累計求和到移動平均的各種查詢。4.2 連續(xù)問題日期減去序號這一步是關鍵“統(tǒng)計連續(xù)登錄N天的用戶”是SQL題里的常青樹它表面上考的是連續(xù)判斷實際考的是你能否用一個巧妙的轉換把連續(xù)問題變成分組問題。核心思路(1) 先用窗口函數(shù)ROW_NUMBER()按用戶分組、按日期排序得到每個用戶每個登錄日期的序號(2) 用登錄日期減去序號得到一個日期值(3) 如果日期是連續(xù)的日期減序號的差值會保持不變所以這個差值就可以作為分組標識。WITH t AS ( SELECT user_id, login_date, DATE_SUB(login_date, INTERVAL ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY login_date) DAY) AS grp FROM login_log ) SELECT user_id, MIN(login_date) AS start_date, MAX(login_date) AS end_date, COUNT(*) AS consecutive_days FROM t GROUP BY user_id, grp HAVING COUNT(*) 3;這個技巧看著簡單但是假如你之前沒接觸過考場上臨時想是很費時間的。建議把它當成一個固定套路來記。4.3 每日活躍/留存率把握住“去重”和“時間偏移”兩個核心統(tǒng)計DAU日活躍用戶的題目在筆試里非常常見因為它直接對應業(yè)務里的核心指標。做題的時候要注意兩點一是去重邏輯同一用戶同一天產(chǎn)生多條記錄應該只算一次二是時間維度的處理按天統(tǒng)計需要注意日期格式的轉換。留存率的計算是另一個高頻題型。以“次日留存率”為例核心方法是把同一用戶的登錄記錄按日期錯位連接找到第T天登錄且第T1天也登錄的用戶數(shù)。SELECT a.login_date, COUNT(DISTINCT b.user_id) / COUNT(DISTINCT a.user_id) AS retention_rate FROM login_log a LEFT JOIN login_log b ON a.user_id b.user_id AND b.login_date DATE_ADD(a.login_date, INTERVAL 1 DAY) GROUP BY a.login_date;如果把DATE_ADD(a.login_date, INTERVAL 1 DAY)改成INTERVAL 7 DAY或INTERVAL 30 DAY就能分別得到7日留存和30日留存。這類題目不復雜但細節(jié)很關鍵比如JOIN條件里必須限定日期偏移否則會出現(xiàn)數(shù)據(jù)膨脹的問題。4.4 時間區(qū)間重疊峰值在線人數(shù)的經(jīng)典解法統(tǒng)計“在線用戶峰值”或“會議室最大使用數(shù)量”這類問題在數(shù)據(jù)工程筆試里被改編成“每分鐘在線聽歌人數(shù)峰值”出現(xiàn)的概率很高。這類題的核心解法非常巧妙把每一條記錄拆成兩個事件一個開始事件1一個結束事件-1然后按時間順序做累計求和。WITH events AS ( SELECT user_id, start_time AS ts, 1 AS delta FROM play_log UNION ALL SELECT user_id, end_time AS ts, -1 AS delta FROM play_log ) SELECT ts, SUM(delta) OVER (ORDER BY ts) AS concurrent_cnt FROM events ORDER BY ts;然后再取出concurrent_cnt的最大值就是峰值。這個思路在很多真實場景里都能用到比如并發(fā)任務數(shù)統(tǒng)計、直播間同時在線人數(shù)等。理解了事件流累加這個底層邏輯這類題就都通了。5. 踩坑記錄和復盤方法細節(jié)決定最終成績最后這部分我想聊聊那些容易被忽略、但實際考試中非常致命的細節(jié)。這些內容沒有多少技術含量可一旦踩中很可能讓你前功盡棄。5.1 環(huán)境準備筆試平臺的隱藏坑筆試用的在線OJ平臺和本地IDE差別很大。第一個坑是代碼自動補全的缺失。在本地IDE里寫SQL習慣了自動提示表名和字段名到了在線平臺手寫SQL經(jīng)常會因為拼錯字段名而報錯。第二個坑是本地驗證和在線評判的差異。平臺一般提供本地自測用例但通過自測不代表最終能拿滿分因為測試數(shù)據(jù)里會有一些你沒考慮到的邊界情況。一個值得養(yǎng)成的習慣是在正式筆試前用?？途W(wǎng)或賽碼網(wǎng)刷幾套在線編程題提前適應這些平臺的輸入輸出格式和評判規(guī)則。尤其是輸入輸出解析不同平臺之間的規(guī)范可能不太一樣但一旦適應了就不至于在考場上糾結“這行字符串到底要不要去掉末尾的回車”。5.2 做題過程中的低級錯誤SQL題最容易犯的低級錯誤包括JOIN條件漏寫、GROUP BY字段不完整、COUNT和SUM的語義混淆、NULL值處理不當。這些錯誤在本地試數(shù)據(jù)量小的時候不容易暴露一旦跑到全量數(shù)據(jù)上就會出現(xiàn)結果偏差。編程題更容易栽在邊界條件上比如空列表輸入、單元素列表、數(shù)字溢出等。寫代碼的時候可以給自己一分鐘的時間專門想想“如果輸入是空的我這代碼跑不跑得通”這個習慣能幫你避免很多無謂的失分。另外讀題一定要讀完整特別是題目最后幾行對輸出格式的要求。每年都有人因為輸出格式不符合要求而丟掉一整道題的分數(shù)格式問題最可惜。5.3 考后一定要復盤筆試結束不等于學習結束。無論這次筆試的結果如何考后復盤都是提升能力最有效的方式。建議趁熱打鐵把考場上沒能做出來的題重新做一遍對照題目回憶自己的思路卡在哪里是知識點沒掌握還是時間分配出了問題。復盤時可以把所有錯題按題型歸檔比如“SQL-連續(xù)問題”“SQL-留存率”“編程-區(qū)間重疊”“選擇題-Flink”。春招期間要投的公司往往不止一家騰訊音樂的筆試真題就是最好的練兵場把每場筆試里的錯題都變成自己的彈藥庫下一場筆試的勝算才會明顯提升。根據(jù)我自己的經(jīng)驗數(shù)據(jù)工程崗的筆試到最后拼的其實不是智商而是你是否對常見題型足夠熟悉。熟練度這東西只能在反復練習中積累。把高頻題型的套路吃透再養(yǎng)成規(guī)范的做題習慣拿到面試機會并沒有想象中那么難。