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