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