據(jù)開發(fā)筆試：SQL、數(shù)倉(cāng)與組件考點(diǎn)全拆解)
這份卷子的標(biāo)題是“浩鯨科技2020屆數(shù)據(jù)開發(fā)類C卷”乍一看像一份過期資料但如果你正在準(zhǔn)備數(shù)據(jù)開發(fā)相關(guān)崗位的筆試面試我建議你耐著性子往下看。數(shù)據(jù)開發(fā)這個(gè)崗位核心考察的東西三五年內(nèi)基本不會(huì)變尤其是SQL、數(shù)倉(cāng)理論、大數(shù)據(jù)組件原理這三板斧。我從2019年校招開始接觸這類題也幫人改過不少筆試答案發(fā)現(xiàn)大多數(shù)人的復(fù)習(xí)方向都有問題——花大把時(shí)間刷算法題結(jié)果栽在一道看似簡(jiǎn)單的SQL窗口函數(shù)上或者在“為什么數(shù)倉(cāng)要分層”這種送分題上答得毫無(wú)層次。2020屆的C卷放在今天來(lái)看反而是一種很好的“基準(zhǔn)測(cè)試”它告訴你一家做電信行業(yè)數(shù)字化服務(wù)的公司在招數(shù)據(jù)開發(fā)時(shí)到底想要什么樣的人。下面我把這套卷子背后的考察邏輯、常見考點(diǎn)、容易翻車的地方以及備考路線一次性拆透。1. 先看這張卷子的出題背景浩鯨是誰(shuí)數(shù)據(jù)開發(fā)崗在招誰(shuí)1.1 浩鯨科技是做什么的很多考生拿到卷子根本不看公司上來(lái)就做這其實(shí)是大忌。浩鯨科技前身是中興軟創(chuàng)后來(lái)接受了阿里投資改名浩鯨科技。它主要做電信運(yùn)營(yíng)商相關(guān)的業(yè)務(wù)支撐系統(tǒng)、數(shù)據(jù)中臺(tái)、經(jīng)營(yíng)分析系統(tǒng)簡(jiǎn)單說(shuō)就是幫運(yùn)營(yíng)商管好“家底”讓每一條用戶通話記錄、每一筆流量訂單、每一個(gè)用戶畫像都能被采集、清洗、加工、分析最終變成報(bào)表和決策依據(jù)。這也決定了它招“數(shù)據(jù)開發(fā)”的時(shí)候考的東西一定和純互聯(lián)網(wǎng)公司有所差別。電信行業(yè)的數(shù)據(jù)鏈路長(zhǎng)、數(shù)據(jù)量大、口徑復(fù)雜所以筆試?yán)锎蟾怕蕰?huì)出現(xiàn)SQL題、數(shù)倉(cāng)分層設(shè)計(jì)、Hadoop/Hive/Spark原理以及少量Java或者Linux基礎(chǔ)。你如果只準(zhǔn)備算法很容易翻車。1.2 2020屆、C卷這兩個(gè)詞背后的校招邏輯“2020屆”對(duì)應(yīng)的是2019年秋招那一批也就是疫情前最后一批相對(duì)正常的校招。那時(shí)候大數(shù)據(jù)開發(fā)崗位已經(jīng)非常熱門但還沒到后來(lái)“一問全是數(shù)據(jù)開發(fā)”的程度。很多公司同一場(chǎng)筆試會(huì)出A、B、C多套卷目的是防止相鄰座位互相抄襲或者按崗位方向做區(qū)分。所以“C卷”本身并不代表難度分級(jí)它只說(shuō)明這是一套平行卷。不過這也透露一個(gè)信息你拿到的題目很可能和網(wǎng)上流傳的A卷、B卷不一樣但考察范圍高度重合。換句話說(shuō)你不能靠背題來(lái)通過必須把知識(shí)點(diǎn)本身吃透。1.3 數(shù)據(jù)開發(fā)與后端開發(fā)、算法工程師的邊界這道題我必須先說(shuō)清楚因?yàn)楹芏嗳撕?jiǎn)歷上寫“大數(shù)據(jù)開發(fā)”其實(shí)腦子里想的是“后端開發(fā)”或者“算法崗”。數(shù)據(jù)開發(fā)的工作重心在數(shù)據(jù)倉(cāng)庫(kù)建設(shè)、ETL調(diào)度、數(shù)據(jù)管道、數(shù)據(jù)質(zhì)量保障、BI報(bào)表支持核心工具是SQL、Hive、Spark、調(diào)度平臺(tái)而不是高并發(fā)微服務(wù)也不是模型調(diào)參。所以筆試的科目配比會(huì)明顯偏向數(shù)據(jù)側(cè)。C卷里如果出現(xiàn)Java題大概率也是基礎(chǔ)語(yǔ)法、集合、并發(fā)中的基礎(chǔ)概念不會(huì)讓你手寫紅黑樹。如果你把大量時(shí)間花在二叉樹遍歷和動(dòng)態(tài)規(guī)劃上那就走偏了。數(shù)據(jù)開發(fā)考算法一般到LeetCode簡(jiǎn)單和中度題就夠了重點(diǎn)反而是SQL和數(shù)倉(cāng)。2. 由卷子反推考點(diǎn)數(shù)據(jù)開發(fā)筆試?yán)锓磸?fù)出現(xiàn)的“基本盤”我手上沒有C卷原題但基于浩鯨這類公司數(shù)據(jù)開發(fā)崗位的招聘邏輯以及我見過的多套同類型筆試可以倒推出一個(gè)比較穩(wěn)的考點(diǎn)框架。這套框架不僅適用于浩鯨也適用于大多數(shù)做數(shù)倉(cāng)和大數(shù)據(jù)平臺(tái)的公司。2.1 語(yǔ)言和基礎(chǔ)Java、Linux、計(jì)算機(jī)網(wǎng)絡(luò)很多數(shù)據(jù)開發(fā)筆試尤其是2020屆那種現(xiàn)場(chǎng)筆試會(huì)在前面放十幾道選擇題覆蓋Java基礎(chǔ)、Linux命令、計(jì)算機(jī)網(wǎng)絡(luò)和數(shù)據(jù)庫(kù)基礎(chǔ)。Java部分?？糎ashMap底層結(jié)構(gòu)、ArrayList和LinkedList區(qū)別、線程安全的幾種方式、JVM內(nèi)存區(qū)域劃分。Linux部分?？汲Ｓ妹畹挠猛颈热鐃op、grep、awk、sed、less以及查看磁盤空間、查看端口占用、查看進(jìn)程狀態(tài)的命令。計(jì)算機(jī)網(wǎng)絡(luò)部分基本不會(huì)太深TCP三次握手、HTTP狀態(tài)碼、DNS解析流程算高頻。我給個(gè)建議這一塊不用花大量時(shí)間系統(tǒng)復(fù)習(xí)重點(diǎn)是把高頻考點(diǎn)過一遍。我當(dāng)時(shí)用的是“刷題看錯(cuò)題解析”的方式每天花半小時(shí)持續(xù)十天左右就夠應(yīng)付筆試了。不要一來(lái)就啃《Java編程思想》性價(jià)比太低。2.2 SQL題數(shù)據(jù)開發(fā)的立身之本SQL題是數(shù)據(jù)開發(fā)筆試的絕對(duì)核心占比通常在30%到40%。如果一份筆試卷子滿分100分SQL題拿不到80%的正確率后面面試基本沒底氣。?？嫉腟QL類型包括多表連接inner join、left join、子查詢、聚合函數(shù)與group by、having和where的區(qū)別、行轉(zhuǎn)列列轉(zhuǎn)行、窗口函數(shù)rank、dense_rank、row_number、sum over、日期處理函數(shù)、case when邏輯判斷。舉個(gè)典型題目有一張訂單表orders(order_id, user_id, amount, create_date)要求統(tǒng)計(jì)每個(gè)用戶最近三筆訂單的平均金額。很多人的第一反應(yīng)是limit但正確處理是窗口函數(shù)SELECT user_id, AVG(amount) OVER(PARTITION BY user_id ORDER BY create_date ASC ROWS BETWEEN 2 PRECEDING AND CURRENT ROW) AS avg_amount_recent_3 FROM orders;注意order by create_date ASC當(dāng)前行是最早的不ASC時(shí)當(dāng)前行反而是最早的ROWS BETWEEN 2 PRECEDING AND CURRENT ROW取的是“當(dāng)前行往前兩行加自己”但ASC排序下往前兩行是更早的這會(huì)取到最舊的單子而題目要“最近三筆”。正確做法是先把數(shù)據(jù)按create_date倒序排列或者用ORDER BY create_date DESC配合ROWS BETWEEN CURRENT ROW AND 2 FOLLOWING。我給一個(gè)更穩(wěn)妥的寫法SELECT user_id, AVG(amount) OVER(PARTITION BY user_id ORDER BY create_date DESC ROWS BETWEEN CURRENT ROW AND 2 FOLLOWING) AS avg_amount_recent_3 FROM orders;道理很簡(jiǎn)單在窗口內(nèi)按日期倒序排當(dāng)前行是最新一筆FOLLOWING兩行就是往前數(shù)兩筆。這里有個(gè)最常見的坑窗口函數(shù)里order by的方向和frame的范圍組合很多考生一緊張就寫反。還有一道常見題用戶行為表user_behavior(user_id, action, dt)統(tǒng)計(jì)每天每種行為的用戶數(shù)并輸出當(dāng)天行為量排名前三的組合。用row_number() over(partition by dt order by cnt desc)就能解關(guān)鍵點(diǎn)是先聚合再用窗口函數(shù)順序不能反。2.3 大數(shù)據(jù)組件Hadoop三劍客與Spark這一部分占分通常在20%到30%以簡(jiǎn)答題和場(chǎng)景題為主。HDFS部分?？紨?shù)據(jù)塊默認(rèn)大小、副本機(jī)制、NameNode和DataNode職責(zé)、讀寫流程。讀寫流程可以用生活化類比來(lái)理解把HDFS想象成一個(gè)“先問管家再搬貨”的過程Client先聯(lián)系NameNode確認(rèn)元數(shù)據(jù)再和DataNode建立管道一塊一塊傳。寫的時(shí)候要以packet為單位讀的時(shí)候要就近原則。這些概念不需要背源碼但一定要能用兩三句話說(shuō)清楚。MapReduce部分常考整個(gè)作業(yè)從split到map到shuffle到reduce的過程尤其是shuffle里分區(qū)、排序、溢寫、合并這幾步。面試官很喜歡問“為什么MapReduce很慢”答案是中間結(jié)果要落盤、排序多、進(jìn)程啟動(dòng)開銷大。Hive部分?？糎ive是什么數(shù)據(jù)倉(cāng)庫(kù)工具SQL轉(zhuǎn)MapReduce/Tez/Spark作業(yè)、內(nèi)部表和外部表的區(qū)別、分區(qū)表和分桶表、where和having的區(qū)別順帶SQL也考了。還有一個(gè)經(jīng)典問題為什么Hive能直接用SQL因?yàn)樗裇QL解析成抽象語(yǔ)法樹再轉(zhuǎn)成邏輯計(jì)劃、物理計(jì)劃最后提交到計(jì)算引擎執(zhí)行。Spark部分?？糝DD是什么、transformation和action的區(qū)別、寬依賴和窄依賴、DAG怎么生成、Spark為什么比MapReduce快內(nèi)存計(jì)算、DAG計(jì)算模型、task復(fù)用、多線程。如果C卷有進(jìn)階題還可能考Spark SQL和Hive的對(duì)比。2.4 數(shù)倉(cāng)理論分層和建模是隱性考點(diǎn)很多自學(xué)大數(shù)據(jù)的人容易忽略數(shù)倉(cāng)理論但這恰恰是數(shù)據(jù)開發(fā)筆試的隱性大頭。浩鯨這類做運(yùn)營(yíng)商數(shù)據(jù)平臺(tái)的公司對(duì)數(shù)倉(cāng)分層、主題域劃分、指標(biāo)口徑統(tǒng)一非?？粗亍?shù)倉(cāng)分層必考至少要知道ODS、DWD、DWS、ADS這一套經(jīng)典分層每層的作用要說(shuō)得清楚ODS原始數(shù)據(jù)層原樣落地不做過多的清洗加工保留全量歷史。DWD明細(xì)數(shù)據(jù)層清洗、規(guī)范化、維度退化、拉鏈表處理面向主題組織明細(xì)事實(shí)。DWS匯總數(shù)據(jù)層按維度預(yù)聚合形成寬表復(fù)用于多業(yè)務(wù)場(chǎng)景。ADS應(yīng)用數(shù)據(jù)層面向具體報(bào)表和應(yīng)用直接服務(wù)BI、大屏、經(jīng)營(yíng)分析。為什么分層答案不是“別人都這么分”而是解耦、復(fù)用、統(tǒng)一口徑、方便血緣追溯。一套科學(xué)的分層能讓不同團(tuán)隊(duì)因?yàn)榭趶絾栴}吵架的概率大大降低。維度建模部分常考星型模型和雪花模型區(qū)別、事實(shí)表和維度表區(qū)分。有一類題是給了幾張表讓你判斷哪個(gè)是事實(shí)表哪個(gè)是維度表或者讓你設(shè)計(jì)一個(gè)用戶下單分析的數(shù)據(jù)模型。遇到這種題記住一個(gè)判斷標(biāo)準(zhǔn)事實(shí)表記錄“發(fā)生的事”有數(shù)字度量表會(huì)不斷增長(zhǎng)維度表描述“事物的屬性”比如用戶性別、商品類目、門店名稱通常是緩慢變化的。2.5 代碼與邏輯題手寫WordCount到TopN編程題在C卷里一般一到兩道不會(huì)太難但很考驗(yàn)基本工。最經(jīng)典的是手寫WordCountMapReduce版和Spark版都要會(huì)。MapReduce版的關(guān)鍵是重寫map和reduce方法public static class TokenizerMapper extends MapperObject, Text, Text, IntWritable { private final static IntWritable one new IntWritable(1); private Text word new Text(); public void map(Object key, Text value, Context context) throws IOException, InterruptedException { StringTokenizer itr new StringTokenizer(value.toString()); while (itr.hasMoreTokens()) { word.set(itr.nextToken()); context.write(word, one); } } }Spark版本可以用Scala一行流式寫出來(lái)sc.textFile(input) .flatMap(_.split( )) .map((_, 1)) .reduceByKey(_ _) .sortBy(_._2, ascending false) .take(10)除了WordCountTopN也是高頻題。TopN的關(guān)鍵不在于排序本身而在于怎么減少數(shù)據(jù)傳輸如果數(shù)據(jù)量非常大應(yīng)該在每個(gè)分區(qū)先求局部TopN再匯總求全局TopN。這個(gè)思路在MapReduce和Spark里都適用。邏輯題大概率有一道比如“25匹馬5個(gè)賽道最少比賽幾次找出前三”“燒繩子測(cè)45分鐘”這類題屬于考場(chǎng)上會(huì)就會(huì)、不會(huì)就懵的類型。我建議考前看一遍經(jīng)典智力題的答案不求全背但求有個(gè)印象遇到類似的能順著思路走。3. 最容易翻車的幾類題目踩坑現(xiàn)場(chǎng)與正確的打開方式這一節(jié)我聊的是實(shí)戰(zhàn)中見過的高頻錯(cuò)誤。很多人知識(shí)點(diǎn)都背過但做題時(shí)就是拿不到分原因往往不是不會(huì)而是踩進(jìn)了特定的坑。3.1 窗口函數(shù)和group by放在一起錯(cuò)誤示范與正確寫法窗口函數(shù)是數(shù)據(jù)開發(fā)筆試的分水嶺也是扣分重災(zāi)區(qū)。最常見的錯(cuò)誤是在一個(gè)查詢里先用了group by然后想在select里同時(shí)用窗口函數(shù)結(jié)果發(fā)現(xiàn)字段對(duì)不上。比如題目統(tǒng)計(jì)每個(gè)用戶的訂單總額并計(jì)算所有用戶訂單總額的排名。 錯(cuò)誤寫法SELECT user_id, SUM(amount) AS total_amount, RANK() OVER(ORDER BY total_amount DESC) AS rk FROM orders GROUP BY user_id;很多數(shù)據(jù)庫(kù)會(huì)報(bào)錯(cuò)因?yàn)镾ELECT里窗口函數(shù)引用了別名total_amount而別名的計(jì)算依賴于group by之后的聚合結(jié)果。嚴(yán)格來(lái)說(shuō)有些引擎支持這種寫法比如Hive在某些配置下可以但在筆試中很容易翻車。正確寫法是SELECT user_id, total_amount, RANK() OVER(ORDER BY total_amount DESC) AS rk FROM ( SELECT user_id, SUM(amount) AS total_amount FROM orders GROUP BY user_id ) t;關(guān)鍵心得窗口函數(shù)在邏輯上是在group by聚合之后執(zhí)行的。當(dāng)你要對(duì)聚合結(jié)果繼續(xù)做排序、排名時(shí)一定要先子查詢把聚合結(jié)果算出來(lái)再在外面套窗口函數(shù)。這個(gè)結(jié)構(gòu)幾乎是SQL大題的標(biāo)準(zhǔn)套路。還有一道容易錯(cuò)的題目統(tǒng)計(jì)每個(gè)用戶的首單時(shí)間和最近一單時(shí)間。有些人會(huì)下意識(shí)用group by加min、max但題目可能要求同時(shí)輸出這些日期對(duì)應(yīng)的訂單金額。min日期和訂單金額不能直接放在一起因?yàn)镾QL引擎不知道要保留哪一行。正確做法是用窗口函數(shù)row_number分別按照正序和倒序排篩選出第一行。這類題考察的就是窗口函數(shù)能不能用得靈活。3.2 數(shù)據(jù)傾斜換個(gè)說(shuō)法就認(rèn)不出來(lái)的經(jīng)典題數(shù)據(jù)傾斜是大數(shù)據(jù)崗位面試的常青樹筆試也經(jīng)常出現(xiàn)但換個(gè)場(chǎng)景很多人就懵了。常見題目一個(gè)join任務(wù)卡在99%不動(dòng)可能是什么原因你如何定位和解決定位思路要講清楚先看是不是有個(gè)reduce遲遲不結(jié)束再看是不是有某個(gè)key的數(shù)據(jù)量特別大。如果是Hive作業(yè)可以通過查看Counter確認(rèn)某個(gè)reduce輸入記錄數(shù)異常。解決思路是分情況的如果傾斜是因?yàn)閚ull值導(dǎo)致把null值加上隨機(jī)后綴比如concat(null_, rand())讓它們分散到不同reduce。如果傾斜是因?yàn)槟硞€(gè)熱點(diǎn)key比如某個(gè)爆款商品的訂單量特別大可以對(duì)熱點(diǎn)key打散做兩階段join。第一階段給熱點(diǎn)key加隨機(jī)前綴與另一張表按打散后的key關(guān)聯(lián)第二階段再按真實(shí)key關(guān)聯(lián)。如果是group by傾斜先開啟map端聚合或者設(shè)置hive.groupby.skewindatatrue讓Hive自動(dòng)生成兩階段MR。如果是Spark任務(wù)可以考慮用AQE的自動(dòng)傾斜處理開啟動(dòng)態(tài)優(yōu)化也可以手動(dòng)salting。光背答案容易翻車更好的方式是給一個(gè)具體的例子。我看到有位考生是這樣答的假設(shè)sales表和goods表關(guān)聯(lián)其中爆款商品id888的訂單占了一大半直接join會(huì)導(dǎo)致888這個(gè)key全部落到同一個(gè)reduce。他的方案是在map端識(shí)別出key888復(fù)制成888_0到888_9十個(gè)隨機(jī)key同時(shí)把goods表中id888的記錄也復(fù)制十份加上相同的后綴兩階段join后再去掉后綴合并結(jié)果。這個(gè)回答能拿高分是因?yàn)樗粌H說(shuō)出了方案還說(shuō)出了為什么能解決數(shù)據(jù)傾斜的問題——把本來(lái)集中在一個(gè)節(jié)點(diǎn)的計(jì)算壓力分散到多個(gè)節(jié)點(diǎn)。3.3 Hive和Spark SQL的差異題別只背優(yōu)缺點(diǎn)有一類對(duì)比題最讓人頭疼請(qǐng)說(shuō)說(shuō)Hive和Spark SQL的區(qū)別。很多人會(huì)背“Hive跑MapReduceSpark SQL跑內(nèi)存Spark快”但這只是表面。更高質(zhì)量的回答要提到幾個(gè)層面引擎層面Hive本身不是計(jì)算引擎是數(shù)據(jù)倉(cāng)庫(kù)工具底層可以用MapReduce、Tez或者Spark作為執(zhí)行引擎Spark SQL則是基于Spark核心引擎的查詢模塊走的DAG執(zhí)行計(jì)劃。優(yōu)化器層面Spark SQL有Catalyst優(yōu)化器能做邏輯優(yōu)化、物理優(yōu)化、code generationHive也有CBO但整體優(yōu)化能力在一些復(fù)雜SQL上不如Spark SQL。容錯(cuò)和資源管理Hive的MR模型更成熟穩(wěn)定適合超大離線批處理Spark的stage、task粒度更細(xì)并發(fā)度高但內(nèi)存壓力大需要調(diào)優(yōu)。適用場(chǎng)景Hive更適合遲到數(shù)據(jù)多、凌晨跑批、對(duì)穩(wěn)定性要求極高的場(chǎng)景Spark SQL適合需要快速產(chǎn)出結(jié)果、復(fù)雜邏輯迭代計(jì)算的場(chǎng)景。筆試碰到這種對(duì)比題一定要從不同維度展開不要一句話結(jié)束。重點(diǎn)不是誰(shuí)比誰(shuí)好而是你展現(xiàn)出對(duì)兩個(gè)框架各自適用場(chǎng)景的理解。3.4 數(shù)倉(cāng)分層的“為什么”答不出層次感分層題看起來(lái)很基礎(chǔ)但很多人只會(huì)背“ODS、DWD、DWS、ADS”一旦追問為什么就卡住了。我見過一個(gè)回答讓我印象很深刻他說(shuō)“不分層也能做報(bào)表但所有報(bào)表都要直接讀ODS每個(gè)業(yè)務(wù)線都自己寫一套清洗邏輯。結(jié)果同一個(gè)指標(biāo)銷售部算出來(lái)是1000萬(wàn)市場(chǎng)部算出來(lái)是900萬(wàn)。分層不是強(qiáng)制要求是當(dāng)數(shù)據(jù)規(guī)模和應(yīng)用場(chǎng)景復(fù)雜到一定程度后的必然選擇?！边@個(gè)回答好在它給出了一個(gè)業(yè)務(wù)的視角。建議把分層的價(jià)值總結(jié)成四個(gè)點(diǎn)第一清晰的數(shù)據(jù)邊界和權(quán)限控制不同層對(duì)訪問者有不同權(quán)限第二統(tǒng)一的數(shù)據(jù)口徑指標(biāo)在DWS算一次所有下游復(fù)用第三提高開發(fā)效率減少重復(fù)清洗計(jì)算第四方便數(shù)據(jù)血緣追蹤和問題回溯出錯(cuò)了能快速定位是哪一層的問題。答題時(shí)不要只背概念最好帶一個(gè)實(shí)際場(chǎng)景。比如用戶下單表、支付表、退貨表分散在不同業(yè)務(wù)系統(tǒng)ODS層原樣接入DWD層統(tǒng)一格式化把各種ID統(tǒng)一成用戶IDDWS層按天聚合出每個(gè)地區(qū)每個(gè)品類的GMVADS層直接給大屏顯示。這樣講面試官就知道你真正干過而不是只在書上看過。4. 比刷題更重要的把筆試答案變成面試表達(dá)能力很多考生筆試分很高面試卻表現(xiàn)平平原因是把筆試和面試當(dāng)成了兩件完全不相干的事。實(shí)際上筆試?yán)锏拇鸢妇褪敲嬖囎詈玫乃夭年P(guān)鍵是怎么用。4.1 答題時(shí)的“過程感”讓閱卷人看到你的思路我?guī)腿烁墓P試答案時(shí)發(fā)現(xiàn)很多人在卷面上只寫最后結(jié)果比如SQL只寫一條長(zhǎng)長(zhǎng)的查詢中間所有思考過程都省略了。這會(huì)吃大虧。簡(jiǎn)答題比如“HDFS寫數(shù)據(jù)的流程”不要只寫“Client聯(lián)系NameNode然后寫DataNode”。最好按順序?qū)懬宄﨏lient向NameNode發(fā)起寫請(qǐng)求NameNode檢查文件是否存在、權(quán)限是否足夠Client按數(shù)據(jù)塊大小把文件切分Client向NameNode請(qǐng)求第一個(gè)塊的DataNode列表數(shù)據(jù)以packet為單位按管道方式依次寫入多個(gè)DataNode每個(gè)DataNode寫完本地并校驗(yàn)后ack逐級(jí)返回所有塊寫完后NameNode接收完成確認(rèn)更新元數(shù)據(jù)。這種回答有過程有細(xì)節(jié)閱卷人一眼就能看出你是真懂還是只會(huì)背結(jié)論。筆試不是寫給自己看的是寫給閱卷人看的。你要做的是把腦海里的知識(shí)用文字完整地“播放”一遍。4.2 項(xiàng)目經(jīng)驗(yàn)怎么講才有區(qū)分度面試一定會(huì)問項(xiàng)目。很多人的項(xiàng)目是培訓(xùn)班或者課程設(shè)計(jì)出來(lái)的講起來(lái)全是“實(shí)現(xiàn)了用戶畫像系統(tǒng)”“搭建了數(shù)據(jù)倉(cāng)庫(kù)”聽起來(lái)很空洞。有區(qū)分度的講法一定要包含數(shù)據(jù)量和問題背景。比如“我參與的是一個(gè)日活約500萬(wàn)的電商數(shù)倉(cāng)項(xiàng)目原始數(shù)據(jù)在ODS層一天新增大概1TB。我負(fù)責(zé)DWD層訂單事實(shí)表的建設(shè)期間遇到一個(gè)最大的問題是訂單表和支付表的join在生產(chǎn)環(huán)境發(fā)生了嚴(yán)重的數(shù)據(jù)傾斜某個(gè)大商家的訂單量占了全天的30%。我通過打散熱點(diǎn)key和兩階段join解決了這個(gè)問題把作業(yè)時(shí)長(zhǎng)從40分鐘壓到了18分鐘?！蓖瑯拥捻?xiàng)目加上數(shù)字、加上問題、加上解決方案效果完全不同。面試官想聽到的不是羅列工具而是你在這個(gè)項(xiàng)目里碰到過什么困難怎么定位怎么解決。如果項(xiàng)目是真實(shí)的這些問題一定存在如果是虛構(gòu)的那么就問自己這個(gè)項(xiàng)目中最大的技術(shù)難點(diǎn)是什么如果答不上來(lái)建議不要寫在簡(jiǎn)歷上。4.3 “說(shuō)人話”的能力數(shù)據(jù)開發(fā)面試的隱形考察點(diǎn)數(shù)據(jù)開發(fā)不是純技術(shù)崗位它和數(shù)據(jù)產(chǎn)品、業(yè)務(wù)運(yùn)營(yíng)緊密相連。面試官經(jīng)常會(huì)問“你能不能用通俗的話解釋一下數(shù)據(jù)倉(cāng)庫(kù)為什么要分層”這就是在考察你跨部門溝通的能力。如果只會(huì)背概念很容易被判定為“只能悶頭寫SQL說(shuō)不清業(yè)務(wù)”。更好的回答是“你想象一個(gè)餐廳不做分層的做法是每個(gè)服務(wù)員自己去菜市場(chǎng)買菜、洗菜、切菜、炒菜做完一桌再跑下一桌每個(gè)服務(wù)員都有自己的做法有的咸有的淡。分層的意思就是有人專職買菜、有人專職切配、有人專職掌勺最后出品統(tǒng)一效率也高?！奔夹g(shù)人最忌諱的是“用術(shù)語(yǔ)解釋術(shù)語(yǔ)”。數(shù)據(jù)開發(fā)面試到后半場(chǎng)面試官往往會(huì)故意問一些大白話問題看你能否瞬間切換視角。平時(shí)練習(xí)的時(shí)候建議把每個(gè)核心知識(shí)點(diǎn)都試著講給一個(gè)不懂技術(shù)的人聽講不通說(shuō)明你自己還沒吃透。5. 一份可以直接抄的備考路線時(shí)間分配與自測(cè)清單如果距離筆試還剩一個(gè)月請(qǐng)按下面的節(jié)奏安排比半夜刷一堆算法題要有效得多。5.1 第一階段打底SQL、Java和Linux前十天把重心放在SQL上每天至少4道SQL題。不要只看題解要親手在環(huán)境里跑一遍。沒有大數(shù)據(jù)環(huán)境也沒關(guān)系本地裝個(gè)MySQL或者SQLite練基本查詢窗口函數(shù)用PostgreSQL或者SQL Server的在線練習(xí)環(huán)境都可以。SQL語(yǔ)感這種事沒有捷徑只有多寫。Java和Linux這段時(shí)間穿插復(fù)習(xí)每天半小時(shí)。Java重點(diǎn)看HashMap、ArrayList、線程、JVM分區(qū)Linux重點(diǎn)看文件操作、進(jìn)程管理、磁盤網(wǎng)絡(luò)、權(quán)限相關(guān)命令。不求面面俱到但高頻題必須會(huì)。5.2 第二階段主攻組件原理與數(shù)倉(cāng)設(shè)計(jì)第二個(gè)十天進(jìn)入大數(shù)據(jù)組件。HDFS讀寫流程、MapReduce Shuffle、Hive架構(gòu)和內(nèi)部外表區(qū)別、Spark RDD寬窄依賴和作業(yè)執(zhí)行流程這幾個(gè)必須能默寫出來(lái)。數(shù)倉(cāng)方面重點(diǎn)準(zhǔn)備分層架構(gòu)、事實(shí)表維度表、星型模型雪花模型、拉鏈表、緩慢變化維。其中拉鏈表是很多考官愛問的知識(shí)點(diǎn)因?yàn)槿粘?shù)倉(cāng)開發(fā)確實(shí)會(huì)用到而且能考察你對(duì)“全量快照對(duì)存儲(chǔ)消耗太大”這個(gè)問題的理解。這個(gè)階段可以動(dòng)手做一個(gè)小項(xiàng)目練手不用很復(fù)雜自己造幾十萬(wàn)條訂單數(shù)據(jù)用Hive或者Spark做一次數(shù)倉(cāng)分層加工ODS到DWD再到DWS最后統(tǒng)計(jì)出GMV。整個(gè)過程實(shí)操下來(lái)比看十篇教程都有用。5.3 第三階段真題模擬與錯(cuò)題復(fù)盤最后一周進(jìn)入沖刺模式。找2到3套同類型公司的筆試真題嚴(yán)格計(jì)時(shí)做一遍不查資料。做完以后不要只看對(duì)錯(cuò)要把每道錯(cuò)題對(duì)應(yīng)的知識(shí)點(diǎn)標(biāo)出來(lái)回到原理層面重新過一遍。錯(cuò)題復(fù)盤比刷新題重要得多。我當(dāng)年的習(xí)慣是準(zhǔn)備一個(gè)markdown文件命名為“錯(cuò)題.note”每道錯(cuò)題記錄三部分題目是什么、我錯(cuò)在哪、正確答案的核心思路是什么。考前只需要翻這個(gè)文件就夠了。你會(huì)發(fā)現(xiàn)錯(cuò)誤往往高度集中在幾個(gè)知識(shí)點(diǎn)上比如窗口函數(shù)排序方向搞反、shuffle階段記憶混亂、拉鏈表場(chǎng)景不會(huì)判斷。把這些坑填平比做十套新題都有效。5.4 筆試前夜的自查清單臨考前一晚不建議再刷題建議對(duì)著清單自問一遍掃盲窗口函數(shù) rank、dense_rank、row_number 的區(qū)別和寫法能寫對(duì)嗎HDFS 寫入流程能從 Client 請(qǐng)求到 ack 返回完整復(fù)述嗎內(nèi)部表和外部表的區(qū)別刪除表時(shí)數(shù)據(jù)會(huì)不會(huì)消失能一句話說(shuō)清嗎寬依賴和窄依賴怎么區(qū)分分別對(duì)應(yīng)哪些算子數(shù)倉(cāng)分層為什么不是越多越好結(jié)合實(shí)際怎么權(quán)衡手寫 WordCountMapReduce 和 Spark 兩個(gè)版本都能默寫嗎如果一份 SQL 跑得很慢你有排查思路嗎這些問題如果都能順利答出來(lái)筆試基本穩(wěn)了。如果有一兩個(gè)說(shuō)不清恭喜你你找到了考前最需要補(bǔ)的缺口。數(shù)據(jù)開發(fā)筆試說(shuō)白了就是一場(chǎng)“基本功踩坑經(jīng)驗(yàn)”的檢驗(yàn)?；竟Q定你有沒有資格進(jìn)場(chǎng)踩坑經(jīng)驗(yàn)決定你能不能在場(chǎng)上穩(wěn)住不丟分。這張2020屆的C卷雖然年份久遠(yuǎn)但背后考察的能力模型幾乎沒有變化。把上面的東西吃透不管換成A卷還是B卷你都不會(huì)慌。 從浩鯨科技C卷看數(shù)據(jù)開發(fā)筆試：SQL、數(shù)倉(cāng)與組件考點(diǎn)全拆解
這份卷子的標(biāo)題是“浩鯨科技2020屆數(shù)據(jù)開發(fā)類C卷”乍一看像一份過期資料但如果你正在準(zhǔn)備數(shù)據(jù)開發(fā)相關(guān)崗位的筆試面試我建議你耐著性子往下看。數(shù)據(jù)開發(fā)這個(gè)崗位核心考察的東西三五年內(nèi)基本不會(huì)變尤其是SQL、數(shù)倉(cāng)理論、大數(shù)據(jù)組件原理這三板斧。我從2019年校招開始接觸這類題也幫人改過不少筆試答案發(fā)現(xiàn)大多數(shù)人的復(fù)習(xí)方向都有問題——花大把時(shí)間刷算法題結(jié)果栽在一道看似簡(jiǎn)單的SQL窗口函數(shù)上或者在“為什么數(shù)倉(cāng)要分層”這種送分題上答得毫無(wú)層次。2020屆的C卷放在今天來(lái)看反而是一種很好的“基準(zhǔn)測(cè)試”它告訴你一家做電信行業(yè)數(shù)字化服務(wù)的公司在招數(shù)據(jù)開發(fā)時(shí)到底想要什么樣的人。下面我把這套卷子背后的考察邏輯、常見考點(diǎn)、容易翻車的地方以及備考路線一次性拆透。1. 先看這張卷子的出題背景浩鯨是誰(shuí)數(shù)據(jù)開發(fā)崗在招誰(shuí)1.1 浩鯨科技是做什么的很多考生拿到卷子根本不看公司上來(lái)就做這其實(shí)是大忌。浩鯨科技前身是中興軟創(chuàng)后來(lái)接受了阿里投資改名浩鯨科技。它主要做電信運(yùn)營(yíng)商相關(guān)的業(yè)務(wù)支撐系統(tǒng)、數(shù)據(jù)中臺(tái)、經(jīng)營(yíng)分析系統(tǒng)簡(jiǎn)單說(shuō)就是幫運(yùn)營(yíng)商管好“家底”讓每一條用戶通話記錄、每一筆流量訂單、每一個(gè)用戶畫像都能被采集、清洗、加工、分析最終變成報(bào)表和決策依據(jù)。這也決定了它招“數(shù)據(jù)開發(fā)”的時(shí)候考的東西一定和純互聯(lián)網(wǎng)公司有所差別。電信行業(yè)的數(shù)據(jù)鏈路長(zhǎng)、數(shù)據(jù)量大、口徑復(fù)雜所以筆試?yán)锎蟾怕蕰?huì)出現(xiàn)SQL題、數(shù)倉(cāng)分層設(shè)計(jì)、Hadoop/Hive/Spark原理以及少量Java或者Linux基礎(chǔ)。你如果只準(zhǔn)備算法很容易翻車。1.2 2020屆、C卷這兩個(gè)詞背后的校招邏輯“2020屆”對(duì)應(yīng)的是2019年秋招那一批也就是疫情前最后一批相對(duì)正常的校招。那時(shí)候大數(shù)據(jù)開發(fā)崗位已經(jīng)非常熱門但還沒到后來(lái)“一問全是數(shù)據(jù)開發(fā)”的程度。很多公司同一場(chǎng)筆試會(huì)出A、B、C多套卷目的是防止相鄰座位互相抄襲或者按崗位方向做區(qū)分。所以“C卷”本身并不代表難度分級(jí)它只說(shuō)明這是一套平行卷。不過這也透露一個(gè)信息你拿到的題目很可能和網(wǎng)上流傳的A卷、B卷不一樣但考察范圍高度重合。換句話說(shuō)你不能靠背題來(lái)通過必須把知識(shí)點(diǎn)本身吃透。1.3 數(shù)據(jù)開發(fā)與后端開發(fā)、算法工程師的邊界這道題我必須先說(shuō)清楚因?yàn)楹芏嗳撕?jiǎn)歷上寫“大數(shù)據(jù)開發(fā)”其實(shí)腦子里想的是“后端開發(fā)”或者“算法崗”。數(shù)據(jù)開發(fā)的工作重心在數(shù)據(jù)倉(cāng)庫(kù)建設(shè)、ETL調(diào)度、數(shù)據(jù)管道、數(shù)據(jù)質(zhì)量保障、BI報(bào)表支持核心工具是SQL、Hive、Spark、調(diào)度平臺(tái)而不是高并發(fā)微服務(wù)也不是模型調(diào)參。所以筆試的科目配比會(huì)明顯偏向數(shù)據(jù)側(cè)。C卷里如果出現(xiàn)Java題大概率也是基礎(chǔ)語(yǔ)法、集合、并發(fā)中的基礎(chǔ)概念不會(huì)讓你手寫紅黑樹。如果你把大量時(shí)間花在二叉樹遍歷和動(dòng)態(tài)規(guī)劃上那就走偏了。數(shù)據(jù)開發(fā)考算法一般到LeetCode簡(jiǎn)單和中度題就夠了重點(diǎn)反而是SQL和數(shù)倉(cāng)。2. 由卷子反推考點(diǎn)數(shù)據(jù)開發(fā)筆試?yán)锓磸?fù)出現(xiàn)的“基本盤”我手上沒有C卷原題但基于浩鯨這類公司數(shù)據(jù)開發(fā)崗位的招聘邏輯以及我見過的多套同類型筆試可以倒推出一個(gè)比較穩(wěn)的考點(diǎn)框架。這套框架不僅適用于浩鯨也適用于大多數(shù)做數(shù)倉(cāng)和大數(shù)據(jù)平臺(tái)的公司。2.1 語(yǔ)言和基礎(chǔ)Java、Linux、計(jì)算機(jī)網(wǎng)絡(luò)很多數(shù)據(jù)開發(fā)筆試尤其是2020屆那種現(xiàn)場(chǎng)筆試會(huì)在前面放十幾道選擇題覆蓋Java基礎(chǔ)、Linux命令、計(jì)算機(jī)網(wǎng)絡(luò)和數(shù)據(jù)庫(kù)基礎(chǔ)。Java部分?？糎ashMap底層結(jié)構(gòu)、ArrayList和LinkedList區(qū)別、線程安全的幾種方式、JVM內(nèi)存區(qū)域劃分。Linux部分?？汲Ｓ妹畹挠猛颈热鐃op、grep、awk、sed、less以及查看磁盤空間、查看端口占用、查看進(jìn)程狀態(tài)的命令。計(jì)算機(jī)網(wǎng)絡(luò)部分基本不會(huì)太深TCP三次握手、HTTP狀態(tài)碼、DNS解析流程算高頻。我給個(gè)建議這一塊不用花大量時(shí)間系統(tǒng)復(fù)習(xí)重點(diǎn)是把高頻考點(diǎn)過一遍。我當(dāng)時(shí)用的是“刷題看錯(cuò)題解析”的方式每天花半小時(shí)持續(xù)十天左右就夠應(yīng)付筆試了。不要一來(lái)就啃《Java編程思想》性價(jià)比太低。2.2 SQL題數(shù)據(jù)開發(fā)的立身之本SQL題是數(shù)據(jù)開發(fā)筆試的絕對(duì)核心占比通常在30%到40%。如果一份筆試卷子滿分100分SQL題拿不到80%的正確率后面面試基本沒底氣。?？嫉腟QL類型包括多表連接inner join、left join、子查詢、聚合函數(shù)與group by、having和where的區(qū)別、行轉(zhuǎn)列列轉(zhuǎn)行、窗口函數(shù)rank、dense_rank、row_number、sum over、日期處理函數(shù)、case when邏輯判斷。舉個(gè)典型題目有一張訂單表orders(order_id, user_id, amount, create_date)要求統(tǒng)計(jì)每個(gè)用戶最近三筆訂單的平均金額。很多人的第一反應(yīng)是limit但正確處理是窗口函數(shù)SELECT user_id, AVG(amount) OVER(PARTITION BY user_id ORDER BY create_date ASC ROWS BETWEEN 2 PRECEDING AND CURRENT ROW) AS avg_amount_recent_3 FROM orders;注意order by create_date ASC當(dāng)前行是最早的不ASC時(shí)當(dāng)前行反而是最早的ROWS BETWEEN 2 PRECEDING AND CURRENT ROW取的是“當(dāng)前行往前兩行加自己”但ASC排序下往前兩行是更早的這會(huì)取到最舊的單子而題目要“最近三筆”。正確做法是先把數(shù)據(jù)按create_date倒序排列或者用ORDER BY create_date DESC配合ROWS BETWEEN CURRENT ROW AND 2 FOLLOWING。我給一個(gè)更穩(wěn)妥的寫法SELECT user_id, AVG(amount) OVER(PARTITION BY user_id ORDER BY create_date DESC ROWS BETWEEN CURRENT ROW AND 2 FOLLOWING) AS avg_amount_recent_3 FROM orders;道理很簡(jiǎn)單在窗口內(nèi)按日期倒序排當(dāng)前行是最新一筆FOLLOWING兩行就是往前數(shù)兩筆。這里有個(gè)最常見的坑窗口函數(shù)里order by的方向和frame的范圍組合很多考生一緊張就寫反。還有一道常見題用戶行為表user_behavior(user_id, action, dt)統(tǒng)計(jì)每天每種行為的用戶數(shù)并輸出當(dāng)天行為量排名前三的組合。用row_number() over(partition by dt order by cnt desc)就能解關(guān)鍵點(diǎn)是先聚合再用窗口函數(shù)順序不能反。2.3 大數(shù)據(jù)組件Hadoop三劍客與Spark這一部分占分通常在20%到30%以簡(jiǎn)答題和場(chǎng)景題為主。HDFS部分?？紨?shù)據(jù)塊默認(rèn)大小、副本機(jī)制、NameNode和DataNode職責(zé)、讀寫流程。讀寫流程可以用生活化類比來(lái)理解把HDFS想象成一個(gè)“先問管家再搬貨”的過程Client先聯(lián)系NameNode確認(rèn)元數(shù)據(jù)再和DataNode建立管道一塊一塊傳。寫的時(shí)候要以packet為單位讀的時(shí)候要就近原則。這些概念不需要背源碼但一定要能用兩三句話說(shuō)清楚。MapReduce部分常考整個(gè)作業(yè)從split到map到shuffle到reduce的過程尤其是shuffle里分區(qū)、排序、溢寫、合并這幾步。面試官很喜歡問“為什么MapReduce很慢”答案是中間結(jié)果要落盤、排序多、進(jìn)程啟動(dòng)開銷大。Hive部分?？糎ive是什么數(shù)據(jù)倉(cāng)庫(kù)工具SQL轉(zhuǎn)MapReduce/Tez/Spark作業(yè)、內(nèi)部表和外部表的區(qū)別、分區(qū)表和分桶表、where和having的區(qū)別順帶SQL也考了。還有一個(gè)經(jīng)典問題為什么Hive能直接用SQL因?yàn)樗裇QL解析成抽象語(yǔ)法樹再轉(zhuǎn)成邏輯計(jì)劃、物理計(jì)劃最后提交到計(jì)算引擎執(zhí)行。Spark部分?？糝DD是什么、transformation和action的區(qū)別、寬依賴和窄依賴、DAG怎么生成、Spark為什么比MapReduce快內(nèi)存計(jì)算、DAG計(jì)算模型、task復(fù)用、多線程。如果C卷有進(jìn)階題還可能考Spark SQL和Hive的對(duì)比。2.4 數(shù)倉(cāng)理論分層和建模是隱性考點(diǎn)很多自學(xué)大數(shù)據(jù)的人容易忽略數(shù)倉(cāng)理論但這恰恰是數(shù)據(jù)開發(fā)筆試的隱性大頭。浩鯨這類做運(yùn)營(yíng)商數(shù)據(jù)平臺(tái)的公司對(duì)數(shù)倉(cāng)分層、主題域劃分、指標(biāo)口徑統(tǒng)一非?？粗亍?shù)倉(cāng)分層必考至少要知道ODS、DWD、DWS、ADS這一套經(jīng)典分層每層的作用要說(shuō)得清楚ODS原始數(shù)據(jù)層原樣落地不做過多的清洗加工保留全量歷史。DWD明細(xì)數(shù)據(jù)層清洗、規(guī)范化、維度退化、拉鏈表處理面向主題組織明細(xì)事實(shí)。DWS匯總數(shù)據(jù)層按維度預(yù)聚合形成寬表復(fù)用于多業(yè)務(wù)場(chǎng)景。ADS應(yīng)用數(shù)據(jù)層面向具體報(bào)表和應(yīng)用直接服務(wù)BI、大屏、經(jīng)營(yíng)分析。為什么分層答案不是“別人都這么分”而是解耦、復(fù)用、統(tǒng)一口徑、方便血緣追溯。一套科學(xué)的分層能讓不同團(tuán)隊(duì)因?yàn)榭趶絾栴}吵架的概率大大降低。維度建模部分常考星型模型和雪花模型區(qū)別、事實(shí)表和維度表區(qū)分。有一類題是給了幾張表讓你判斷哪個(gè)是事實(shí)表哪個(gè)是維度表或者讓你設(shè)計(jì)一個(gè)用戶下單分析的數(shù)據(jù)模型。遇到這種題記住一個(gè)判斷標(biāo)準(zhǔn)事實(shí)表記錄“發(fā)生的事”有數(shù)字度量表會(huì)不斷增長(zhǎng)維度表描述“事物的屬性”比如用戶性別、商品類目、門店名稱通常是緩慢變化的。2.5 代碼與邏輯題手寫WordCount到TopN編程題在C卷里一般一到兩道不會(huì)太難但很考驗(yàn)基本工。最經(jīng)典的是手寫WordCountMapReduce版和Spark版都要會(huì)。MapReduce版的關(guān)鍵是重寫map和reduce方法public static class TokenizerMapper extends MapperObject, Text, Text, IntWritable { private final static IntWritable one new IntWritable(1); private Text word new Text(); public void map(Object key, Text value, Context context) throws IOException, InterruptedException { StringTokenizer itr new StringTokenizer(value.toString()); while (itr.hasMoreTokens()) { word.set(itr.nextToken()); context.write(word, one); } } }Spark版本可以用Scala一行流式寫出來(lái)sc.textFile(input) .flatMap(_.split( )) .map((_, 1)) .reduceByKey(_ _) .sortBy(_._2, ascending false) .take(10)除了WordCountTopN也是高頻題。TopN的關(guān)鍵不在于排序本身而在于怎么減少數(shù)據(jù)傳輸如果數(shù)據(jù)量非常大應(yīng)該在每個(gè)分區(qū)先求局部TopN再匯總求全局TopN。這個(gè)思路在MapReduce和Spark里都適用。邏輯題大概率有一道比如“25匹馬5個(gè)賽道最少比賽幾次找出前三”“燒繩子測(cè)45分鐘”這類題屬于考場(chǎng)上會(huì)就會(huì)、不會(huì)就懵的類型。我建議考前看一遍經(jīng)典智力題的答案不求全背但求有個(gè)印象遇到類似的能順著思路走。3. 最容易翻車的幾類題目踩坑現(xiàn)場(chǎng)與正確的打開方式這一節(jié)我聊的是實(shí)戰(zhàn)中見過的高頻錯(cuò)誤。很多人知識(shí)點(diǎn)都背過但做題時(shí)就是拿不到分原因往往不是不會(huì)而是踩進(jìn)了特定的坑。3.1 窗口函數(shù)和group by放在一起錯(cuò)誤示范與正確寫法窗口函數(shù)是數(shù)據(jù)開發(fā)筆試的分水嶺也是扣分重災(zāi)區(qū)。最常見的錯(cuò)誤是在一個(gè)查詢里先用了group by然后想在select里同時(shí)用窗口函數(shù)結(jié)果發(fā)現(xiàn)字段對(duì)不上。比如題目統(tǒng)計(jì)每個(gè)用戶的訂單總額并計(jì)算所有用戶訂單總額的排名。 錯(cuò)誤寫法SELECT user_id, SUM(amount) AS total_amount, RANK() OVER(ORDER BY total_amount DESC) AS rk FROM orders GROUP BY user_id;很多數(shù)據(jù)庫(kù)會(huì)報(bào)錯(cuò)因?yàn)镾ELECT里窗口函數(shù)引用了別名total_amount而別名的計(jì)算依賴于group by之后的聚合結(jié)果。嚴(yán)格來(lái)說(shuō)有些引擎支持這種寫法比如Hive在某些配置下可以但在筆試中很容易翻車。正確寫法是SELECT user_id, total_amount, RANK() OVER(ORDER BY total_amount DESC) AS rk FROM ( SELECT user_id, SUM(amount) AS total_amount FROM orders GROUP BY user_id ) t;關(guān)鍵心得窗口函數(shù)在邏輯上是在group by聚合之后執(zhí)行的。當(dāng)你要對(duì)聚合結(jié)果繼續(xù)做排序、排名時(shí)一定要先子查詢把聚合結(jié)果算出來(lái)再在外面套窗口函數(shù)。這個(gè)結(jié)構(gòu)幾乎是SQL大題的標(biāo)準(zhǔn)套路。還有一道容易錯(cuò)的題目統(tǒng)計(jì)每個(gè)用戶的首單時(shí)間和最近一單時(shí)間。有些人會(huì)下意識(shí)用group by加min、max但題目可能要求同時(shí)輸出這些日期對(duì)應(yīng)的訂單金額。min日期和訂單金額不能直接放在一起因?yàn)镾QL引擎不知道要保留哪一行。正確做法是用窗口函數(shù)row_number分別按照正序和倒序排篩選出第一行。這類題考察的就是窗口函數(shù)能不能用得靈活。3.2 數(shù)據(jù)傾斜換個(gè)說(shuō)法就認(rèn)不出來(lái)的經(jīng)典題數(shù)據(jù)傾斜是大數(shù)據(jù)崗位面試的常青樹筆試也經(jīng)常出現(xiàn)但換個(gè)場(chǎng)景很多人就懵了。常見題目一個(gè)join任務(wù)卡在99%不動(dòng)可能是什么原因你如何定位和解決定位思路要講清楚先看是不是有個(gè)reduce遲遲不結(jié)束再看是不是有某個(gè)key的數(shù)據(jù)量特別大。如果是Hive作業(yè)可以通過查看Counter確認(rèn)某個(gè)reduce輸入記錄數(shù)異常。解決思路是分情況的如果傾斜是因?yàn)閚ull值導(dǎo)致把null值加上隨機(jī)后綴比如concat(null_, rand())讓它們分散到不同reduce。如果傾斜是因?yàn)槟硞€(gè)熱點(diǎn)key比如某個(gè)爆款商品的訂單量特別大可以對(duì)熱點(diǎn)key打散做兩階段join。第一階段給熱點(diǎn)key加隨機(jī)前綴與另一張表按打散后的key關(guān)聯(lián)第二階段再按真實(shí)key關(guān)聯(lián)。如果是group by傾斜先開啟map端聚合或者設(shè)置hive.groupby.skewindatatrue讓Hive自動(dòng)生成兩階段MR。如果是Spark任務(wù)可以考慮用AQE的自動(dòng)傾斜處理開啟動(dòng)態(tài)優(yōu)化也可以手動(dòng)salting。光背答案容易翻車更好的方式是給一個(gè)具體的例子。我看到有位考生是這樣答的假設(shè)sales表和goods表關(guān)聯(lián)其中爆款商品id888的訂單占了一大半直接join會(huì)導(dǎo)致888這個(gè)key全部落到同一個(gè)reduce。他的方案是在map端識(shí)別出key888復(fù)制成888_0到888_9十個(gè)隨機(jī)key同時(shí)把goods表中id888的記錄也復(fù)制十份加上相同的后綴兩階段join后再去掉后綴合并結(jié)果。這個(gè)回答能拿高分是因?yàn)樗粌H說(shuō)出了方案還說(shuō)出了為什么能解決數(shù)據(jù)傾斜的問題——把本來(lái)集中在一個(gè)節(jié)點(diǎn)的計(jì)算壓力分散到多個(gè)節(jié)點(diǎn)。3.3 Hive和Spark SQL的差異題別只背優(yōu)缺點(diǎn)有一類對(duì)比題最讓人頭疼請(qǐng)說(shuō)說(shuō)Hive和Spark SQL的區(qū)別。很多人會(huì)背“Hive跑MapReduceSpark SQL跑內(nèi)存Spark快”但這只是表面。更高質(zhì)量的回答要提到幾個(gè)層面引擎層面Hive本身不是計(jì)算引擎是數(shù)據(jù)倉(cāng)庫(kù)工具底層可以用MapReduce、Tez或者Spark作為執(zhí)行引擎Spark SQL則是基于Spark核心引擎的查詢模塊走的DAG執(zhí)行計(jì)劃。優(yōu)化器層面Spark SQL有Catalyst優(yōu)化器能做邏輯優(yōu)化、物理優(yōu)化、code generationHive也有CBO但整體優(yōu)化能力在一些復(fù)雜SQL上不如Spark SQL。容錯(cuò)和資源管理Hive的MR模型更成熟穩(wěn)定適合超大離線批處理Spark的stage、task粒度更細(xì)并發(fā)度高但內(nèi)存壓力大需要調(diào)優(yōu)。適用場(chǎng)景Hive更適合遲到數(shù)據(jù)多、凌晨跑批、對(duì)穩(wěn)定性要求極高的場(chǎng)景Spark SQL適合需要快速產(chǎn)出結(jié)果、復(fù)雜邏輯迭代計(jì)算的場(chǎng)景。筆試碰到這種對(duì)比題一定要從不同維度展開不要一句話結(jié)束。重點(diǎn)不是誰(shuí)比誰(shuí)好而是你展現(xiàn)出對(duì)兩個(gè)框架各自適用場(chǎng)景的理解。3.4 數(shù)倉(cāng)分層的“為什么”答不出層次感分層題看起來(lái)很基礎(chǔ)但很多人只會(huì)背“ODS、DWD、DWS、ADS”一旦追問為什么就卡住了。我見過一個(gè)回答讓我印象很深刻他說(shuō)“不分層也能做報(bào)表但所有報(bào)表都要直接讀ODS每個(gè)業(yè)務(wù)線都自己寫一套清洗邏輯。結(jié)果同一個(gè)指標(biāo)銷售部算出來(lái)是1000萬(wàn)市場(chǎng)部算出來(lái)是900萬(wàn)。分層不是強(qiáng)制要求是當(dāng)數(shù)據(jù)規(guī)模和應(yīng)用場(chǎng)景復(fù)雜到一定程度后的必然選擇?！边@個(gè)回答好在它給出了一個(gè)業(yè)務(wù)的視角。建議把分層的價(jià)值總結(jié)成四個(gè)點(diǎn)第一清晰的數(shù)據(jù)邊界和權(quán)限控制不同層對(duì)訪問者有不同權(quán)限第二統(tǒng)一的數(shù)據(jù)口徑指標(biāo)在DWS算一次所有下游復(fù)用第三提高開發(fā)效率減少重復(fù)清洗計(jì)算第四方便數(shù)據(jù)血緣追蹤和問題回溯出錯(cuò)了能快速定位是哪一層的問題。答題時(shí)不要只背概念最好帶一個(gè)實(shí)際場(chǎng)景。比如用戶下單表、支付表、退貨表分散在不同業(yè)務(wù)系統(tǒng)ODS層原樣接入DWD層統(tǒng)一格式化把各種ID統(tǒng)一成用戶IDDWS層按天聚合出每個(gè)地區(qū)每個(gè)品類的GMVADS層直接給大屏顯示。這樣講面試官就知道你真正干過而不是只在書上看過。4. 比刷題更重要的把筆試答案變成面試表達(dá)能力很多考生筆試分很高面試卻表現(xiàn)平平原因是把筆試和面試當(dāng)成了兩件完全不相干的事。實(shí)際上筆試?yán)锏拇鸢妇褪敲嬖囎詈玫乃夭年P(guān)鍵是怎么用。4.1 答題時(shí)的“過程感”讓閱卷人看到你的思路我?guī)腿烁墓P試答案時(shí)發(fā)現(xiàn)很多人在卷面上只寫最后結(jié)果比如SQL只寫一條長(zhǎng)長(zhǎng)的查詢中間所有思考過程都省略了。這會(huì)吃大虧。簡(jiǎn)答題比如“HDFS寫數(shù)據(jù)的流程”不要只寫“Client聯(lián)系NameNode然后寫DataNode”。最好按順序?qū)懬宄﨏lient向NameNode發(fā)起寫請(qǐng)求NameNode檢查文件是否存在、權(quán)限是否足夠Client按數(shù)據(jù)塊大小把文件切分Client向NameNode請(qǐng)求第一個(gè)塊的DataNode列表數(shù)據(jù)以packet為單位按管道方式依次寫入多個(gè)DataNode每個(gè)DataNode寫完本地并校驗(yàn)后ack逐級(jí)返回所有塊寫完后NameNode接收完成確認(rèn)更新元數(shù)據(jù)。這種回答有過程有細(xì)節(jié)閱卷人一眼就能看出你是真懂還是只會(huì)背結(jié)論。筆試不是寫給自己看的是寫給閱卷人看的。你要做的是把腦海里的知識(shí)用文字完整地“播放”一遍。4.2 項(xiàng)目經(jīng)驗(yàn)怎么講才有區(qū)分度面試一定會(huì)問項(xiàng)目。很多人的項(xiàng)目是培訓(xùn)班或者課程設(shè)計(jì)出來(lái)的講起來(lái)全是“實(shí)現(xiàn)了用戶畫像系統(tǒng)”“搭建了數(shù)據(jù)倉(cāng)庫(kù)”聽起來(lái)很空洞。有區(qū)分度的講法一定要包含數(shù)據(jù)量和問題背景。比如“我參與的是一個(gè)日活約500萬(wàn)的電商數(shù)倉(cāng)項(xiàng)目原始數(shù)據(jù)在ODS層一天新增大概1TB。我負(fù)責(zé)DWD層訂單事實(shí)表的建設(shè)期間遇到一個(gè)最大的問題是訂單表和支付表的join在生產(chǎn)環(huán)境發(fā)生了嚴(yán)重的數(shù)據(jù)傾斜某個(gè)大商家的訂單量占了全天的30%。我通過打散熱點(diǎn)key和兩階段join解決了這個(gè)問題把作業(yè)時(shí)長(zhǎng)從40分鐘壓到了18分鐘?！蓖瑯拥捻?xiàng)目加上數(shù)字、加上問題、加上解決方案效果完全不同。面試官想聽到的不是羅列工具而是你在這個(gè)項(xiàng)目里碰到過什么困難怎么定位怎么解決。如果項(xiàng)目是真實(shí)的這些問題一定存在如果是虛構(gòu)的那么就問自己這個(gè)項(xiàng)目中最大的技術(shù)難點(diǎn)是什么如果答不上來(lái)建議不要寫在簡(jiǎn)歷上。4.3 “說(shuō)人話”的能力數(shù)據(jù)開發(fā)面試的隱形考察點(diǎn)數(shù)據(jù)開發(fā)不是純技術(shù)崗位它和數(shù)據(jù)產(chǎn)品、業(yè)務(wù)運(yùn)營(yíng)緊密相連。面試官經(jīng)常會(huì)問“你能不能用通俗的話解釋一下數(shù)據(jù)倉(cāng)庫(kù)為什么要分層”這就是在考察你跨部門溝通的能力。如果只會(huì)背概念很容易被判定為“只能悶頭寫SQL說(shuō)不清業(yè)務(wù)”。更好的回答是“你想象一個(gè)餐廳不做分層的做法是每個(gè)服務(wù)員自己去菜市場(chǎng)買菜、洗菜、切菜、炒菜做完一桌再跑下一桌每個(gè)服務(wù)員都有自己的做法有的咸有的淡。分層的意思就是有人專職買菜、有人專職切配、有人專職掌勺最后出品統(tǒng)一效率也高?！奔夹g(shù)人最忌諱的是“用術(shù)語(yǔ)解釋術(shù)語(yǔ)”。數(shù)據(jù)開發(fā)面試到后半場(chǎng)面試官往往會(huì)故意問一些大白話問題看你能否瞬間切換視角。平時(shí)練習(xí)的時(shí)候建議把每個(gè)核心知識(shí)點(diǎn)都試著講給一個(gè)不懂技術(shù)的人聽講不通說(shuō)明你自己還沒吃透。5. 一份可以直接抄的備考路線時(shí)間分配與自測(cè)清單如果距離筆試還剩一個(gè)月請(qǐng)按下面的節(jié)奏安排比半夜刷一堆算法題要有效得多。5.1 第一階段打底SQL、Java和Linux前十天把重心放在SQL上每天至少4道SQL題。不要只看題解要親手在環(huán)境里跑一遍。沒有大數(shù)據(jù)環(huán)境也沒關(guān)系本地裝個(gè)MySQL或者SQLite練基本查詢窗口函數(shù)用PostgreSQL或者SQL Server的在線練習(xí)環(huán)境都可以。SQL語(yǔ)感這種事沒有捷徑只有多寫。Java和Linux這段時(shí)間穿插復(fù)習(xí)每天半小時(shí)。Java重點(diǎn)看HashMap、ArrayList、線程、JVM分區(qū)Linux重點(diǎn)看文件操作、進(jìn)程管理、磁盤網(wǎng)絡(luò)、權(quán)限相關(guān)命令。不求面面俱到但高頻題必須會(huì)。5.2 第二階段主攻組件原理與數(shù)倉(cāng)設(shè)計(jì)第二個(gè)十天進(jìn)入大數(shù)據(jù)組件。HDFS讀寫流程、MapReduce Shuffle、Hive架構(gòu)和內(nèi)部外表區(qū)別、Spark RDD寬窄依賴和作業(yè)執(zhí)行流程這幾個(gè)必須能默寫出來(lái)。數(shù)倉(cāng)方面重點(diǎn)準(zhǔn)備分層架構(gòu)、事實(shí)表維度表、星型模型雪花模型、拉鏈表、緩慢變化維。其中拉鏈表是很多考官愛問的知識(shí)點(diǎn)因?yàn)槿粘?shù)倉(cāng)開發(fā)確實(shí)會(huì)用到而且能考察你對(duì)“全量快照對(duì)存儲(chǔ)消耗太大”這個(gè)問題的理解。這個(gè)階段可以動(dòng)手做一個(gè)小項(xiàng)目練手不用很復(fù)雜自己造幾十萬(wàn)條訂單數(shù)據(jù)用Hive或者Spark做一次數(shù)倉(cāng)分層加工ODS到DWD再到DWS最后統(tǒng)計(jì)出GMV。整個(gè)過程實(shí)操下來(lái)比看十篇教程都有用。5.3 第三階段真題模擬與錯(cuò)題復(fù)盤最后一周進(jìn)入沖刺模式。找2到3套同類型公司的筆試真題嚴(yán)格計(jì)時(shí)做一遍不查資料。做完以后不要只看對(duì)錯(cuò)要把每道錯(cuò)題對(duì)應(yīng)的知識(shí)點(diǎn)標(biāo)出來(lái)回到原理層面重新過一遍。錯(cuò)題復(fù)盤比刷新題重要得多。我當(dāng)年的習(xí)慣是準(zhǔn)備一個(gè)markdown文件命名為“錯(cuò)題.note”每道錯(cuò)題記錄三部分題目是什么、我錯(cuò)在哪、正確答案的核心思路是什么。考前只需要翻這個(gè)文件就夠了。你會(huì)發(fā)現(xiàn)錯(cuò)誤往往高度集中在幾個(gè)知識(shí)點(diǎn)上比如窗口函數(shù)排序方向搞反、shuffle階段記憶混亂、拉鏈表場(chǎng)景不會(huì)判斷。把這些坑填平比做十套新題都有效。5.4 筆試前夜的自查清單臨考前一晚不建議再刷題建議對(duì)著清單自問一遍掃盲窗口函數(shù) rank、dense_rank、row_number 的區(qū)別和寫法能寫對(duì)嗎HDFS 寫入流程能從 Client 請(qǐng)求到 ack 返回完整復(fù)述嗎內(nèi)部表和外部表的區(qū)別刪除表時(shí)數(shù)據(jù)會(huì)不會(huì)消失能一句話說(shuō)清嗎寬依賴和窄依賴怎么區(qū)分分別對(duì)應(yīng)哪些算子數(shù)倉(cāng)分層為什么不是越多越好結(jié)合實(shí)際怎么權(quán)衡手寫 WordCountMapReduce 和 Spark 兩個(gè)版本都能默寫嗎如果一份 SQL 跑得很慢你有排查思路嗎這些問題如果都能順利答出來(lái)筆試基本穩(wěn)了。如果有一兩個(gè)說(shuō)不清恭喜你你找到了考前最需要補(bǔ)的缺口。數(shù)據(jù)開發(fā)筆試說(shuō)白了就是一場(chǎng)“基本功踩坑經(jīng)驗(yàn)”的檢驗(yàn)?；竟Q定你有沒有資格進(jìn)場(chǎng)踩坑經(jīng)驗(yàn)決定你能不能在場(chǎng)上穩(wěn)住不丟分。這張2020屆的C卷雖然年份久遠(yuǎn)但背后考察的能力模型幾乎沒有變化。把上面的東西吃透不管換成A卷還是B卷你都不會(huì)慌。