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