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