這些年秋招季我經常會翻到一些舊筆記恰好整理到了當時參加唯品會2019秋招數據開發崗的完整復盤。那會兒數據開發這個崗位還沒有現在這么“卷”但考察的深度和方向已經非常明確SQL是基本功離線數倉是主線實時計算是加分項。如果你正準備投遞數據開發崗或者正在糾結怎么準備大廠數據崗面試這篇文章基本能幫你把考察重點、面試套路和實戰避坑一次性理清。我先把結論放在前面唯品會數據開發崗的考察風格屬于典型的“電商大廠通用型”——不考偏題怪題但特別重視你對數據倉庫建模的理解、對Hive/Spark等離線計算引擎的掌握深度以及能不能把業務問題翻譯成技術方案。筆試會卡一輪SQL和算法技術面會深挖項目里的數倉分層、數據傾斜、指標一致性這些細節。下面我按時間線把整個流程拆開講。1. 崗位畫像與考察節奏先搞清楚他們要什么樣的人1.1 數據開發崗在電商大廠到底做什么投簡歷之前我建議你先想明白一件事數據開發崗和數據分析崗、大數據平臺開發崗是有本質區別的。很多同學投遞時容易混淆結果面試時答非所問。從唯品會這類電商公司的組織架構來看數據開發崗的核心職責可以概括為三塊離線數倉建設負責從業務庫、日志、第三方渠道把數據同步到數倉然后完成ODS、DWD、DWS、ADS各層級的建模、清洗、加工最終產出供BI報表、數據分析師、算法團隊使用的數據表。數據服務與保障保證數據任務按時產出、數據質量可靠包括調度系統的維護、任務血緣管理、數據對賬、異常監控告警。實時計算開發隨著業務對時效性的要求提高數據開發崗需要承擔一部分實時鏈路建設比如Flink/Spark Streaming消費Kafka做實時大屏、實時特征、實時報表。也就是說你不僅要會寫SQL還要懂調度、懂存儲、懂引擎原理甚至要懂一點業務指標口徑。面試官考察的就是你“能不能獨立把一個數據需求從取數到建模再到上線跑通”。1.2 2019秋招的考察節奏與環節分布我當年的整個流程是這樣的網申投遞、在線筆試、技術一面、技術二面、HR面Offer審批。不同批次可能略有差異但整體結構差異不大。這里說一下筆試環節的通過率感受。數據開發崗的筆試會同時考到四類內容計算機基礎數據結構、Java/Python基礎、操作系統、網絡、SQL編程題、大數據組件原理、少量數倉建模設計題。其中SQL題占比最高大概能到40%左右其次是大數據組件Hadoop/Hive/Spark原理約30%剩下的是算法編程和計算機基礎。所以如果你準備時間有限優先攻克SQL和Hive/Spark原理這兩塊決定了你筆試能不能過線。2. 筆試真題復盤SQL和數倉基礎是最大分水嶺2.1 高頻SQL題型窗口函數是必拿分項唯品會筆試里的SQL題難度中等偏上考的不是簡單select而是實際業務中高頻使用的分析場景。我復盤下來最常出現的題型有以下幾類每一類我都會附上核心解法和示例。第一類分組TopN問題比如“統計每個品類下銷量最高的前3個商品”。這類題的核心就是row_number() over(partition by ... order by ...)然后再套一層子查詢把rn過濾出來。當年考的一道題大概是這樣的-- 表結構orders(order_id, product_id, category_id, sales_amount) -- 需求統計每個品類下銷售額排名前3的商品 SELECT category_id, product_id, sales_amount FROM ( SELECT category_id, product_id, sales_amount, ROW_NUMBER() OVER(PARTITION BY category_id ORDER BY sales_amount DESC) AS rn FROM orders ) t WHERE t.rn 3;這里有個細節值得注意如果業務上存在銷售額并列的情況用ROW_NUMBER還是RANK要取決于需求。ROW_NUMBER是唯一遞增編號同分也會分出先后RANK同分會重復排名且后續排名會跳躍DENSE_RANK同分重復但后續排名不跳躍。面試官很可能會追問這個問題你得能說清楚三者的差別和適用場景。第二類連續登錄問題比如“找出連續登錄3天及以上的用戶”。標準的解法是使用lag或lead窗口函數或者用date_sub(login_date, rn)構造連續分組。-- 表結構user_login(user_id, login_date) -- 思路登錄日期減去行號若日期是連續的差值相同 SELECT user_id FROM ( SELECT user_id, login_date, DATE_SUB(login_date, ROW_NUMBER() OVER(PARTITION BY user_id ORDER BY login_date)) AS grp FROM user_login ) t GROUP BY user_id, grp HAVING COUNT(*) 3;這道題的變形很多比如“連續7天”“連續30天”“連續活躍用戶數”解法套路都一樣但需要你理解為什么date_sub之后分組能保持連續。這個原理如果說不清楚面試官會懷疑你是背題。第三類留存率與復購率計算這類題非常貼近電商業務。比如“計算每日新增用戶的次日留存率”。核心是自關聯或者left join按用戶首次活躍日期分組SELECT t1.first_date, COUNT(DISTINCT t1.user_id) AS new_users, COUNT(DISTINCT t2.user_id) AS retention_users, COUNT(DISTINCT t2.user_id) / COUNT(DISTINCT t1.user_id) AS retention_rate FROM ( SELECT user_id, MIN(login_date) AS first_date FROM user_act GROUP BY user_id ) t1 LEFT JOIN user_act t2 ON t1.user_id t2.user_id AND t2.login_date DATE_ADD(t1.first_date, 1) GROUP BY t1.first_date;這種題在筆試里不是讓你真去跑而是考察你的邏輯是否清晰先找新增再找次日有回訪的用戶最后算比率。做題時注意兩個坑一是分母要去重二是LEFT JOIN避免把新增用戶過濾掉。2.2 數倉建模設計題星型模型、雪花模型與拉鏈表除了SQL筆試還會出現簡答/設計題常見場景是“請為一個電商平臺設計訂單事實表和商品維度表并說明模型選型理由”。這一塊我當時的回答思路可以給你參考選星型模型還是雪花模型核心看維度的規范化和查詢性能的平衡。星型模型維度表冗余、層次扁平適合OLAP查詢SQL寫起來簡單join次數少雪花模型維度表做了規范化拆分消除冗余但增加了join層級。互聯網數倉里星型模型更主流因為查詢性能和易用性優先。事實表設計要區分事務事實表和周期快照事實表。訂單累計快照、每日庫存快照用周期快照表交易流水、點擊日志用事務事實表。拉鏈表是一個非常高頻的考點用于記錄維度屬性隨時間的變化。比如用戶等級、商品價格如果直接覆蓋更新就丟失歷史于是設計start_date和end_date兩個字段配合daily分區表做全量比對更新。筆試里會讓你設計表結構和更新邏輯你要能寫出“開鏈、關鏈、新增”三步SQL。當時筆試還考了一道很有意思的題給定一份用戶訂單明細統計“每個用戶首次下單到第二次下單的平均間隔天數”。這題其實就是lead窗口函數取下一次下單時間再datediff計算間隔最后取均值。這類題看起來復雜拆解后就是窗口函數聚合很考察基本功。2.3 算法編程題以LeetCode中等難度為主數據開發崗的算法題不會像后端開發那樣出hard難題但中等難度的題目還是需要準備的。我當時碰到的是“給定一個無序數組求最長連續序列的長度”核心思路是去重后用HashSet從每個連續序列的起點開始遍歷時間復雜度O(n)。def longestConsecutive(nums): nums set(nums) max_len 0 for num in nums: if num - 1 not in nums: cur num length 1 while cur 1 in nums: cur 1 length 1 max_len max(max_len, length) return max_len刷題建議以LeetCode Top100里涉及數組、哈希表、字符串、鏈表的題目為主排序和雙指針也要熟。筆試平臺一般是牛客網模式上可能不是leetcode那種核心代碼模式而是需要自己處理輸入輸出這點提前練一練省得考場上手忙腳亂。3. 技術面核心環節離線鏈路與實時計算考察實錄3.1 Hive必問點存儲格式、分區分桶、UDF通過筆試之后我進入了一面這輪主要考察的是大數據基礎功底。面試官從Hive開始問起層層遞進。他先問“你用過哪些Hive文件存儲格式分別有什么優缺點”這個問題看似基礎但能把兩者區別講清楚的人其實不多。我的回答思路是TextFile是默認的純文本格式可讀性好但壓縮率和查詢性能都很差Parquet是列式存儲按列壓縮在查詢只需要部分列時能大幅減少IOORC也是列式存儲在Hive生態里壓縮比和查詢性能通常更好但Parquet在Spark生態中的兼容性更通用。所以具體選型要看技術棧——如果公司以Hive為主ORC很常見如果以Spark為主Parquet更穩妥。接著他拋出一個非常典型的業務問題“一張訂單表每天幾千萬條查詢某個用戶最近10筆訂單很慢怎么優化”這題考察的就是分區和分桶。我的回答分三步第一按日期做分區裁剪查詢時限定最近一個月分區把掃描數據量降下來第二如果經常按user_id查詢可以對user_id做分桶讓同一個用戶的數據落在同一個桶內查詢時直接定位到桶第三在桶內字段上建排序結合bucket pruning進一步提升效率。然后面試官又追問了UDF的開發流程。UDF分三類UDF一對一、UDAF多對一聚合函數、UDTF一對多行轉列。我當時手寫過身份證號解析的UDF就順帶介紹了繼承UDF類、重寫evaluate方法、打包上傳、create temporary function注冊的完整過程。3.2 Spark考察重點寬窄依賴、shuffle調優、內存模型Hive之后自然而然地進入Spark。面試官問的第一個問題很有代表性“Spark寬依賴和窄依賴的區別以及為什么窄依賴可以流水線執行”我當時的回答窄依賴是指父RDD每個分區最多被子RDD的一個分區使用比如map、filter、union子RDD可以直接在父RDD分區上原地計算無需shuffle寬依賴是指父RDD每個分區可能被子RDD的多個分區使用典型是groupByKey、reduceByKey、join父分區的數據需要跨節點重新分發也就是shuffle。shuffle要落盤、要網絡傳輸是Spark作業性能瓶頸的根源所以優化shuffle是Spark調優的核心目標。緊接著他問“你線上Spark任務遇到過數據傾斜嗎怎么定位和解決的”這是我強烈建議重點準備的題因為幾乎必考。我復盤了一個真實案例現象是跑一個訂單維度的聚合任務其他executor幾十秒跑完某個executor跑了半小時最后OOM。定位思路是先看Spark UI上的Stage耗時再通過查看每個task處理的數據量發現某個task的輸入數據量是其他task的幾十倍基本確認key分布嚴重不均。解決方案我說了三個過濾臟數據如果傾斜的key是空值或無明顯業務意義的數據比如空字符串、未知ID可以單獨過濾或加隨機前綴后再打散處理加隨機前綴兩階段聚合對傾斜key先加隨機數前綴進行第一輪局部聚合再去掉前綴做第二輪全局聚合。適用于聚合類操作對join類問題無效廣播小表如果大表join小表時出現傾斜可以map端廣播小表避免shuffle。然后他讓我背一下Spark on YARN的資源分配參數和內存模型。這部分如果沒實際調優過很容易慌我列一下參數和含義spark.executor.memory控制executor堆內內存spark.executor.memoryOverhead控制堆外內存默認是堆內存的10%用于JVM本身、字符串常量池、網絡緩沖等spark.executor.cores控制executor的CPU核數spark.executor.instances控制executor數量。內存模型上Spark 1.6之后引入了統一內存管理堆內分為Storage內存、Execution內存和保留區域Storage和Execution可以互相借用避免出現一邊空間浪費一邊GC頻繁的問題。3.3 Flink與實時計算Time、Watermark、Exactly-Once二面的時候面試官突然切到了實時計算。他問的是“你用過Flink嗎簡單講講Flink和Spark Streaming的區別。”這題很考察認知廣度。我的回答是Spark Streaming是基于微批的準實時計算把流數據切成一個個小批次處理吞吐量高但延遲在秒級典型延遲在幾百毫秒到秒級Flink是真正的流式計算引擎事件逐條處理延遲可以做到毫秒級并且支持基于事件時間(event time)的窗口計算天然契合對亂序數據有要求的場景。另外Flink在狀態管理、精確一次語義(Exactly-Once)方面做得更徹底。然后他追問Watermark的作用。我用了一個通俗的類比來解釋Watermark是“我等多長時間就不再等了”的標記。比如事件時間是12:00的窗口允許亂序5秒鐘那么當Watermark推進到12:00:05時就觸發計算12:00那個窗口的結果。如果一條遲到數據在Watermark之后才到達就只能被丟棄或進入側輸出流。實際項目中要結合業務容忍度來設置亂序時間太短會導致結果不準太長會延遲出結果。那輪面試快結束時他問我“你們實時任務怎么保證數據不丟不重”我說我們用的Kafka Flink方案Kafka的offset由Flink checkpoint機制管理開啟exactly-once模式后Flink會把狀態和offset一起做快照發生故障時從最近一次checkpoint恢復配合Kafka consumer事務性寫入可以做到端到端精確一次。不過這需要上下游都支持事務或冪等寫入否則只能做到至少一次(at-least-once)下游需要做去重。3.4 手寫SQL環節從數據傾斜到指標設計二面里還有個手寫SQL環節面試官在白板上出了幾道題。其中最讓我印象深刻的一道是“統計連續7天有購買行為的用戶且這7天每天的購買金額都大于100元”。這道題把連續性問題條件過濾窗口函數結合在了一起。我的解法思路是先用where過濾掉金額≤100的記錄再按用戶分組用date_sub(login_date, row_number())構造連續組最后having count(*) 7。關鍵在于“先過濾再算連續”如果先算連續再過濾邏輯就完全錯了。另一個手寫題是“計算某品類商品的GMV周同比”要求考慮節假日調整。這個題目本質上在考察數據分析思維周同比是指本周累計GMV相對上周同期的變化但遇到春節、雙11這類大促周期簡單周同比會失真應該用活動周期對齊再比較。面試官借此考察你是不是只懂技術、不懂業務這個表達很重要。4. 面試中的高頻追問與答題思路4.1 “講一下你簡歷里這個項目”的正確打開方式技術面一定會讓你介紹項目。我踩過很大的一個坑是第一次面試時把項目描述得像流水賬——先做了什么后做了什么最后實現了什么。面試官根本不感興趣。后來我總結了一套“項目講述公式”業務背景放在第一句用一句話說清楚這個項目解決了什么問題然后是技術架構用三到五句話說明數據從哪來、經過哪些環節、最后落到哪里接著是你具體負責的模塊要精確到表怎么設計、任務怎么寫、參數怎么調最后留一個鉤子主動拋出你在項目中遇到的一個難題和解決過程引導面試官往你熟悉的方向問。以我當時做的“用戶行為分析數倉”項目為例我會這樣講業務背景是App端每日產生大量埋點日志業務方需要按小時維度查看用戶轉化漏斗但原有流程是日志落HDFS后第二天跑批時效性不夠。所以我在ODS層直接對接Kafka實時接入DWD層做清洗和session劃分DWS層做小時級聚合再通過預聚合結果供前端大屏查詢。項目中最棘手的問題是session劃分時存在大量超長session我用“間隔30分鐘無操作則切分”的策略處理并用Hive/Spark優化了session劃分任務的數據傾斜。這樣一講面試官會主動問你session劃分的細節和傾斜優化正好踩在你的準備范圍內。4.2 數據質量與指標一致性大廠面試的隱藏考點這類問題不會直接問“你怎么保障數據質量”而是會通過場景題出現比如“運營反饋昨天報表的GMV和財務部對不上你怎么排查”“你的數倉里訂單金額字段有的表叫order_amount有的表叫pay_amount怎么統一”“凌晨3點調度任務失敗了第二天早上才發現怎么避免”我的回答思路通常包含四個層面數據質量校驗在任務里加入數據量波動監控比如昨日分區行數相比前日波動超過20%則任務報警關鍵指標設置閾值校驗比如訂單金額不為負。指標口徑登記建立指標字典每個指標必須有統一定義。比如“GMV”指用戶支付成功的訂單金額包含退款但在統計周期內尚未退款的訂單而“實付金額”是扣除退款后的凈額。這些口徑一定要在需求評審階段對齊并在代碼注釋和元數據系統里登記。對賬機制核心報表每天與業務庫進行對賬Kafka實時鏈路會有實時與離線數據交叉比對如果實時結果與離線結果偏差超過閾值立即觸發告警。鏈路監控用調度平臺自帶的任務依賴和告警功能設置任務失敗自動重跑和電話/短信告警配合數據質量平臺做表級和字段級血緣追蹤。4.3 大廠面試的軟技能業務理解與溝通表達最后想提醒一點數據開發崗不是純技術崗。面試官非常看重你能不能聽懂業務方說什么。這輪面試里有個問題是“如果商品運營想分析‘高價值用戶’的購買偏好你怎么定義高價值用戶”如果只回答“根據消費金額排序取前20%”那只是及格水平。更好的回答是先問清楚高價值用戶是看近30天消費金額、消費頻次、還是用戶生命周期價值(LTV)不同業務目標下定義完全不同。先確認口徑再談實現這本身就是數據開發的基本工作方式。5. 秋招投遞與面試節奏的實操建議5.1 簡歷怎么寫能更匹配數據開發崗簡歷這塊我給出三個具體建議。第一項目經歷中一定要有明確的“數量級”——比如“處理日均5億條日志數據”“數倉共2000張表”“調度任務3000個”面試官對數字非常敏感沒有數量級描述會讓人覺得項目是玩具項目。第二技術棧要寫出“熟練、掌握、了解”的邊界不要全部寫成精通。面試官如果發現你寫了“精通Spark”卻又答不出shuffle原理反而會扣分。第三把“業務結果”寫進簡歷比如“通過口徑統一將報表差錯率從5%降到0.5%”——這種描述能有效區分你和其他候選人。5.2 時間線管理提前批、正式批與內推渠道當時我投遞的是秋招提前批這類批次的優勢是流程快、競爭相對小部分公司提前批不通過還能轉正式批。建議你重點關注幾個時間節點7月到8月是提前批開放期9月到10月是正式批集中筆試期。內推不是必須的但有內推可以讓簡歷優先被看到避免簡歷石沉大海。找內推的渠道一般是牛客網、公眾號、學長學姐、以及各大技術社區的內推帖注意別為了內推泄露個人敏感信息。5.3 心態調整與多線面試的經驗秋招最崩潰的不是某一場面試掛了而是連續一周每天都有筆試面試時間根本排不開。我的做法是每周固定半天完整刷題其余碎片時間只看牛客網的面經和錯題把每一輪的面試題目及時復盤記到備忘錄里避免同一類問題在下一場面試里再卡殼為了應對不同公司的流程沖突可以禮貌地和HR溝通調整面試時間絕大多數公司都能協調。說實話我當時也在很多公司面試時遇到過答不上來的題。回頭來看面試官有時候并不是想等你一個完美答案而是在看你怎么思考、怎么溝通、怎么在不會的情況下給出合理的分析路徑。數據開發崗尤甚——這個崗位每天面對的是臟數據、延遲任務、口徑爭議解決問題的思路比答案本身更重要。你如果能把這個態度表現出來面試就已經成功了一大半。5.4 關于Offer選擇的個人體會最后再多說一句當年我糾結很久的事數據開發崗最后拿到幾個Offer時怎么選。除了看薪資我更建議你關注三件事第一團隊使用的技術棧是否足夠主流如果還在用純MapReduce寫數倉那你的成長速度會受影響第二數倉建設是否已經有完整規范還是處于“人肉取數加工廠”階段這決定了你進去后是寫代碼還是寫臨時SQL第三實時鏈路是否已經落地如果有機會在生產環境接觸Flink對你后續的職業發展加成會很明顯。數據開發這個崗位門檻不高但天花板很高。筆試面試只是第一關真正拉開差距的是你進入崗位后能不能從“會寫SQL”升級到“會設計數倉”再到“能推動數據規范和數據質量建設”的人。這個成長路徑比秋招本身更值得提前想清楚。 唯品會數據開發崗秋招面試復盤：SQL、數倉與實時計算全解析
這些年秋招季我經常會翻到一些舊筆記恰好整理到了當時參加唯品會2019秋招數據開發崗的完整復盤。那會兒數據開發這個崗位還沒有現在這么“卷”但考察的深度和方向已經非常明確SQL是基本功離線數倉是主線實時計算是加分項。如果你正準備投遞數據開發崗或者正在糾結怎么準備大廠數據崗面試這篇文章基本能幫你把考察重點、面試套路和實戰避坑一次性理清。我先把結論放在前面唯品會數據開發崗的考察風格屬于典型的“電商大廠通用型”——不考偏題怪題但特別重視你對數據倉庫建模的理解、對Hive/Spark等離線計算引擎的掌握深度以及能不能把業務問題翻譯成技術方案。筆試會卡一輪SQL和算法技術面會深挖項目里的數倉分層、數據傾斜、指標一致性這些細節。下面我按時間線把整個流程拆開講。1. 崗位畫像與考察節奏先搞清楚他們要什么樣的人1.1 數據開發崗在電商大廠到底做什么投簡歷之前我建議你先想明白一件事數據開發崗和數據分析崗、大數據平臺開發崗是有本質區別的。很多同學投遞時容易混淆結果面試時答非所問。從唯品會這類電商公司的組織架構來看數據開發崗的核心職責可以概括為三塊離線數倉建設負責從業務庫、日志、第三方渠道把數據同步到數倉然后完成ODS、DWD、DWS、ADS各層級的建模、清洗、加工最終產出供BI報表、數據分析師、算法團隊使用的數據表。數據服務與保障保證數據任務按時產出、數據質量可靠包括調度系統的維護、任務血緣管理、數據對賬、異常監控告警。實時計算開發隨著業務對時效性的要求提高數據開發崗需要承擔一部分實時鏈路建設比如Flink/Spark Streaming消費Kafka做實時大屏、實時特征、實時報表。也就是說你不僅要會寫SQL還要懂調度、懂存儲、懂引擎原理甚至要懂一點業務指標口徑。面試官考察的就是你“能不能獨立把一個數據需求從取數到建模再到上線跑通”。1.2 2019秋招的考察節奏與環節分布我當年的整個流程是這樣的網申投遞、在線筆試、技術一面、技術二面、HR面Offer審批。不同批次可能略有差異但整體結構差異不大。這里說一下筆試環節的通過率感受。數據開發崗的筆試會同時考到四類內容計算機基礎數據結構、Java/Python基礎、操作系統、網絡、SQL編程題、大數據組件原理、少量數倉建模設計題。其中SQL題占比最高大概能到40%左右其次是大數據組件Hadoop/Hive/Spark原理約30%剩下的是算法編程和計算機基礎。所以如果你準備時間有限優先攻克SQL和Hive/Spark原理這兩塊決定了你筆試能不能過線。2. 筆試真題復盤SQL和數倉基礎是最大分水嶺2.1 高頻SQL題型窗口函數是必拿分項唯品會筆試里的SQL題難度中等偏上考的不是簡單select而是實際業務中高頻使用的分析場景。我復盤下來最常出現的題型有以下幾類每一類我都會附上核心解法和示例。第一類分組TopN問題比如“統計每個品類下銷量最高的前3個商品”。這類題的核心就是row_number() over(partition by ... order by ...)然后再套一層子查詢把rn過濾出來。當年考的一道題大概是這樣的-- 表結構orders(order_id, product_id, category_id, sales_amount) -- 需求統計每個品類下銷售額排名前3的商品 SELECT category_id, product_id, sales_amount FROM ( SELECT category_id, product_id, sales_amount, ROW_NUMBER() OVER(PARTITION BY category_id ORDER BY sales_amount DESC) AS rn FROM orders ) t WHERE t.rn 3;這里有個細節值得注意如果業務上存在銷售額并列的情況用ROW_NUMBER還是RANK要取決于需求。ROW_NUMBER是唯一遞增編號同分也會分出先后RANK同分會重復排名且后續排名會跳躍DENSE_RANK同分重復但后續排名不跳躍。面試官很可能會追問這個問題你得能說清楚三者的差別和適用場景。第二類連續登錄問題比如“找出連續登錄3天及以上的用戶”。標準的解法是使用lag或lead窗口函數或者用date_sub(login_date, rn)構造連續分組。-- 表結構user_login(user_id, login_date) -- 思路登錄日期減去行號若日期是連續的差值相同 SELECT user_id FROM ( SELECT user_id, login_date, DATE_SUB(login_date, ROW_NUMBER() OVER(PARTITION BY user_id ORDER BY login_date)) AS grp FROM user_login ) t GROUP BY user_id, grp HAVING COUNT(*) 3;這道題的變形很多比如“連續7天”“連續30天”“連續活躍用戶數”解法套路都一樣但需要你理解為什么date_sub之后分組能保持連續。這個原理如果說不清楚面試官會懷疑你是背題。第三類留存率與復購率計算這類題非常貼近電商業務。比如“計算每日新增用戶的次日留存率”。核心是自關聯或者left join按用戶首次活躍日期分組SELECT t1.first_date, COUNT(DISTINCT t1.user_id) AS new_users, COUNT(DISTINCT t2.user_id) AS retention_users, COUNT(DISTINCT t2.user_id) / COUNT(DISTINCT t1.user_id) AS retention_rate FROM ( SELECT user_id, MIN(login_date) AS first_date FROM user_act GROUP BY user_id ) t1 LEFT JOIN user_act t2 ON t1.user_id t2.user_id AND t2.login_date DATE_ADD(t1.first_date, 1) GROUP BY t1.first_date;這種題在筆試里不是讓你真去跑而是考察你的邏輯是否清晰先找新增再找次日有回訪的用戶最后算比率。做題時注意兩個坑一是分母要去重二是LEFT JOIN避免把新增用戶過濾掉。2.2 數倉建模設計題星型模型、雪花模型與拉鏈表除了SQL筆試還會出現簡答/設計題常見場景是“請為一個電商平臺設計訂單事實表和商品維度表并說明模型選型理由”。這一塊我當時的回答思路可以給你參考選星型模型還是雪花模型核心看維度的規范化和查詢性能的平衡。星型模型維度表冗余、層次扁平適合OLAP查詢SQL寫起來簡單join次數少雪花模型維度表做了規范化拆分消除冗余但增加了join層級。互聯網數倉里星型模型更主流因為查詢性能和易用性優先。事實表設計要區分事務事實表和周期快照事實表。訂單累計快照、每日庫存快照用周期快照表交易流水、點擊日志用事務事實表。拉鏈表是一個非常高頻的考點用于記錄維度屬性隨時間的變化。比如用戶等級、商品價格如果直接覆蓋更新就丟失歷史于是設計start_date和end_date兩個字段配合daily分區表做全量比對更新。筆試里會讓你設計表結構和更新邏輯你要能寫出“開鏈、關鏈、新增”三步SQL。當時筆試還考了一道很有意思的題給定一份用戶訂單明細統計“每個用戶首次下單到第二次下單的平均間隔天數”。這題其實就是lead窗口函數取下一次下單時間再datediff計算間隔最后取均值。這類題看起來復雜拆解后就是窗口函數聚合很考察基本功。2.3 算法編程題以LeetCode中等難度為主數據開發崗的算法題不會像后端開發那樣出hard難題但中等難度的題目還是需要準備的。我當時碰到的是“給定一個無序數組求最長連續序列的長度”核心思路是去重后用HashSet從每個連續序列的起點開始遍歷時間復雜度O(n)。def longestConsecutive(nums): nums set(nums) max_len 0 for num in nums: if num - 1 not in nums: cur num length 1 while cur 1 in nums: cur 1 length 1 max_len max(max_len, length) return max_len刷題建議以LeetCode Top100里涉及數組、哈希表、字符串、鏈表的題目為主排序和雙指針也要熟。筆試平臺一般是牛客網模式上可能不是leetcode那種核心代碼模式而是需要自己處理輸入輸出這點提前練一練省得考場上手忙腳亂。3. 技術面核心環節離線鏈路與實時計算考察實錄3.1 Hive必問點存儲格式、分區分桶、UDF通過筆試之后我進入了一面這輪主要考察的是大數據基礎功底。面試官從Hive開始問起層層遞進。他先問“你用過哪些Hive文件存儲格式分別有什么優缺點”這個問題看似基礎但能把兩者區別講清楚的人其實不多。我的回答思路是TextFile是默認的純文本格式可讀性好但壓縮率和查詢性能都很差Parquet是列式存儲按列壓縮在查詢只需要部分列時能大幅減少IOORC也是列式存儲在Hive生態里壓縮比和查詢性能通常更好但Parquet在Spark生態中的兼容性更通用。所以具體選型要看技術棧——如果公司以Hive為主ORC很常見如果以Spark為主Parquet更穩妥。接著他拋出一個非常典型的業務問題“一張訂單表每天幾千萬條查詢某個用戶最近10筆訂單很慢怎么優化”這題考察的就是分區和分桶。我的回答分三步第一按日期做分區裁剪查詢時限定最近一個月分區把掃描數據量降下來第二如果經常按user_id查詢可以對user_id做分桶讓同一個用戶的數據落在同一個桶內查詢時直接定位到桶第三在桶內字段上建排序結合bucket pruning進一步提升效率。然后面試官又追問了UDF的開發流程。UDF分三類UDF一對一、UDAF多對一聚合函數、UDTF一對多行轉列。我當時手寫過身份證號解析的UDF就順帶介紹了繼承UDF類、重寫evaluate方法、打包上傳、create temporary function注冊的完整過程。3.2 Spark考察重點寬窄依賴、shuffle調優、內存模型Hive之后自然而然地進入Spark。面試官問的第一個問題很有代表性“Spark寬依賴和窄依賴的區別以及為什么窄依賴可以流水線執行”我當時的回答窄依賴是指父RDD每個分區最多被子RDD的一個分區使用比如map、filter、union子RDD可以直接在父RDD分區上原地計算無需shuffle寬依賴是指父RDD每個分區可能被子RDD的多個分區使用典型是groupByKey、reduceByKey、join父分區的數據需要跨節點重新分發也就是shuffle。shuffle要落盤、要網絡傳輸是Spark作業性能瓶頸的根源所以優化shuffle是Spark調優的核心目標。緊接著他問“你線上Spark任務遇到過數據傾斜嗎怎么定位和解決的”這是我強烈建議重點準備的題因為幾乎必考。我復盤了一個真實案例現象是跑一個訂單維度的聚合任務其他executor幾十秒跑完某個executor跑了半小時最后OOM。定位思路是先看Spark UI上的Stage耗時再通過查看每個task處理的數據量發現某個task的輸入數據量是其他task的幾十倍基本確認key分布嚴重不均。解決方案我說了三個過濾臟數據如果傾斜的key是空值或無明顯業務意義的數據比如空字符串、未知ID可以單獨過濾或加隨機前綴后再打散處理加隨機前綴兩階段聚合對傾斜key先加隨機數前綴進行第一輪局部聚合再去掉前綴做第二輪全局聚合。適用于聚合類操作對join類問題無效廣播小表如果大表join小表時出現傾斜可以map端廣播小表避免shuffle。然后他讓我背一下Spark on YARN的資源分配參數和內存模型。這部分如果沒實際調優過很容易慌我列一下參數和含義spark.executor.memory控制executor堆內內存spark.executor.memoryOverhead控制堆外內存默認是堆內存的10%用于JVM本身、字符串常量池、網絡緩沖等spark.executor.cores控制executor的CPU核數spark.executor.instances控制executor數量。內存模型上Spark 1.6之后引入了統一內存管理堆內分為Storage內存、Execution內存和保留區域Storage和Execution可以互相借用避免出現一邊空間浪費一邊GC頻繁的問題。3.3 Flink與實時計算Time、Watermark、Exactly-Once二面的時候面試官突然切到了實時計算。他問的是“你用過Flink嗎簡單講講Flink和Spark Streaming的區別。”這題很考察認知廣度。我的回答是Spark Streaming是基于微批的準實時計算把流數據切成一個個小批次處理吞吐量高但延遲在秒級典型延遲在幾百毫秒到秒級Flink是真正的流式計算引擎事件逐條處理延遲可以做到毫秒級并且支持基于事件時間(event time)的窗口計算天然契合對亂序數據有要求的場景。另外Flink在狀態管理、精確一次語義(Exactly-Once)方面做得更徹底。然后他追問Watermark的作用。我用了一個通俗的類比來解釋Watermark是“我等多長時間就不再等了”的標記。比如事件時間是12:00的窗口允許亂序5秒鐘那么當Watermark推進到12:00:05時就觸發計算12:00那個窗口的結果。如果一條遲到數據在Watermark之后才到達就只能被丟棄或進入側輸出流。實際項目中要結合業務容忍度來設置亂序時間太短會導致結果不準太長會延遲出結果。那輪面試快結束時他問我“你們實時任務怎么保證數據不丟不重”我說我們用的Kafka Flink方案Kafka的offset由Flink checkpoint機制管理開啟exactly-once模式后Flink會把狀態和offset一起做快照發生故障時從最近一次checkpoint恢復配合Kafka consumer事務性寫入可以做到端到端精確一次。不過這需要上下游都支持事務或冪等寫入否則只能做到至少一次(at-least-once)下游需要做去重。3.4 手寫SQL環節從數據傾斜到指標設計二面里還有個手寫SQL環節面試官在白板上出了幾道題。其中最讓我印象深刻的一道是“統計連續7天有購買行為的用戶且這7天每天的購買金額都大于100元”。這道題把連續性問題條件過濾窗口函數結合在了一起。我的解法思路是先用where過濾掉金額≤100的記錄再按用戶分組用date_sub(login_date, row_number())構造連續組最后having count(*) 7。關鍵在于“先過濾再算連續”如果先算連續再過濾邏輯就完全錯了。另一個手寫題是“計算某品類商品的GMV周同比”要求考慮節假日調整。這個題目本質上在考察數據分析思維周同比是指本周累計GMV相對上周同期的變化但遇到春節、雙11這類大促周期簡單周同比會失真應該用活動周期對齊再比較。面試官借此考察你是不是只懂技術、不懂業務這個表達很重要。4. 面試中的高頻追問與答題思路4.1 “講一下你簡歷里這個項目”的正確打開方式技術面一定會讓你介紹項目。我踩過很大的一個坑是第一次面試時把項目描述得像流水賬——先做了什么后做了什么最后實現了什么。面試官根本不感興趣。后來我總結了一套“項目講述公式”業務背景放在第一句用一句話說清楚這個項目解決了什么問題然后是技術架構用三到五句話說明數據從哪來、經過哪些環節、最后落到哪里接著是你具體負責的模塊要精確到表怎么設計、任務怎么寫、參數怎么調最后留一個鉤子主動拋出你在項目中遇到的一個難題和解決過程引導面試官往你熟悉的方向問。以我當時做的“用戶行為分析數倉”項目為例我會這樣講業務背景是App端每日產生大量埋點日志業務方需要按小時維度查看用戶轉化漏斗但原有流程是日志落HDFS后第二天跑批時效性不夠。所以我在ODS層直接對接Kafka實時接入DWD層做清洗和session劃分DWS層做小時級聚合再通過預聚合結果供前端大屏查詢。項目中最棘手的問題是session劃分時存在大量超長session我用“間隔30分鐘無操作則切分”的策略處理并用Hive/Spark優化了session劃分任務的數據傾斜。這樣一講面試官會主動問你session劃分的細節和傾斜優化正好踩在你的準備范圍內。4.2 數據質量與指標一致性大廠面試的隱藏考點這類問題不會直接問“你怎么保障數據質量”而是會通過場景題出現比如“運營反饋昨天報表的GMV和財務部對不上你怎么排查”“你的數倉里訂單金額字段有的表叫order_amount有的表叫pay_amount怎么統一”“凌晨3點調度任務失敗了第二天早上才發現怎么避免”我的回答思路通常包含四個層面數據質量校驗在任務里加入數據量波動監控比如昨日分區行數相比前日波動超過20%則任務報警關鍵指標設置閾值校驗比如訂單金額不為負。指標口徑登記建立指標字典每個指標必須有統一定義。比如“GMV”指用戶支付成功的訂單金額包含退款但在統計周期內尚未退款的訂單而“實付金額”是扣除退款后的凈額。這些口徑一定要在需求評審階段對齊并在代碼注釋和元數據系統里登記。對賬機制核心報表每天與業務庫進行對賬Kafka實時鏈路會有實時與離線數據交叉比對如果實時結果與離線結果偏差超過閾值立即觸發告警。鏈路監控用調度平臺自帶的任務依賴和告警功能設置任務失敗自動重跑和電話/短信告警配合數據質量平臺做表級和字段級血緣追蹤。4.3 大廠面試的軟技能業務理解與溝通表達最后想提醒一點數據開發崗不是純技術崗。面試官非常看重你能不能聽懂業務方說什么。這輪面試里有個問題是“如果商品運營想分析‘高價值用戶’的購買偏好你怎么定義高價值用戶”如果只回答“根據消費金額排序取前20%”那只是及格水平。更好的回答是先問清楚高價值用戶是看近30天消費金額、消費頻次、還是用戶生命周期價值(LTV)不同業務目標下定義完全不同。先確認口徑再談實現這本身就是數據開發的基本工作方式。5. 秋招投遞與面試節奏的實操建議5.1 簡歷怎么寫能更匹配數據開發崗簡歷這塊我給出三個具體建議。第一項目經歷中一定要有明確的“數量級”——比如“處理日均5億條日志數據”“數倉共2000張表”“調度任務3000個”面試官對數字非常敏感沒有數量級描述會讓人覺得項目是玩具項目。第二技術棧要寫出“熟練、掌握、了解”的邊界不要全部寫成精通。面試官如果發現你寫了“精通Spark”卻又答不出shuffle原理反而會扣分。第三把“業務結果”寫進簡歷比如“通過口徑統一將報表差錯率從5%降到0.5%”——這種描述能有效區分你和其他候選人。5.2 時間線管理提前批、正式批與內推渠道當時我投遞的是秋招提前批這類批次的優勢是流程快、競爭相對小部分公司提前批不通過還能轉正式批。建議你重點關注幾個時間節點7月到8月是提前批開放期9月到10月是正式批集中筆試期。內推不是必須的但有內推可以讓簡歷優先被看到避免簡歷石沉大海。找內推的渠道一般是牛客網、公眾號、學長學姐、以及各大技術社區的內推帖注意別為了內推泄露個人敏感信息。5.3 心態調整與多線面試的經驗秋招最崩潰的不是某一場面試掛了而是連續一周每天都有筆試面試時間根本排不開。我的做法是每周固定半天完整刷題其余碎片時間只看牛客網的面經和錯題把每一輪的面試題目及時復盤記到備忘錄里避免同一類問題在下一場面試里再卡殼為了應對不同公司的流程沖突可以禮貌地和HR溝通調整面試時間絕大多數公司都能協調。說實話我當時也在很多公司面試時遇到過答不上來的題。回頭來看面試官有時候并不是想等你一個完美答案而是在看你怎么思考、怎么溝通、怎么在不會的情況下給出合理的分析路徑。數據開發崗尤甚——這個崗位每天面對的是臟數據、延遲任務、口徑爭議解決問題的思路比答案本身更重要。你如果能把這個態度表現出來面試就已經成功了一大半。5.4 關于Offer選擇的個人體會最后再多說一句當年我糾結很久的事數據開發崗最后拿到幾個Offer時怎么選。除了看薪資我更建議你關注三件事第一團隊使用的技術棧是否足夠主流如果還在用純MapReduce寫數倉那你的成長速度會受影響第二數倉建設是否已經有完整規范還是處于“人肉取數加工廠”階段這決定了你進去后是寫代碼還是寫臨時SQL第三實時鏈路是否已經落地如果有機會在生產環境接觸Flink對你后續的職業發展加成會很明顯。數據開發這個崗位門檻不高但天花板很高。筆試面試只是第一關真正拉開差距的是你進入崗位后能不能從“會寫SQL”升級到“會設計數倉”再到“能推動數據規范和數據質量建設”的人。這個成長路徑比秋招本身更值得提前想清楚。