前言
我努力了這一年，不僅僅是為了逼歲月回頭。
我是年前離職的，沒(méi)想到這個(gè)突如其來(lái)的疫情，完全將面試升級(jí)為地獄難度，焦慮、煩躁、失眠，是過(guò)去一個(gè)月的主旋律。
自四月上旬投第一封簡(jiǎn)歷開始，前一周完全是在欸打，最氣的面試的小公司，還沒(méi)到技術(shù)面，HR對(duì)我說(shuō)了一句：“ 18屆，我們最高只能給11K。” 我：“？？？？”
說(shuō)實(shí)話，我不甘心，真的。畢竟在過(guò)去一年，我很少有早于凌晨睡的，每天堅(jiān)持對(duì)技術(shù)進(jìn)行復(fù)盤，然后不斷的學(xué)習(xí)新東西，我的預(yù)期自然也遠(yuǎn)遠(yuǎn)不止于此。
從一開始的焦慮、迷茫，到對(duì)自己的技術(shù)產(chǎn)生的深深的懷疑。
幸虧，身邊一幫小伙伴互相打氣，然后還有像敖丙（為何丙丙和我一樣大，能這么優(yōu)秀┗|｀O′|┛ ）他的一些工作和生活經(jīng)歷給了我很多共鳴以及給了我一個(gè)努力的方向吧。
接下來(lái)，陸陸續(xù)續(xù)面試了中軟國(guó)際、翼海云峰、華訊方舟、明略科技、賽意信息、浙江大華、中新賽克、華為OD、焦點(diǎn)科技、浩鯨、阿里云…近20家南京/杭州的大中小廠，最終成功上岸，我就大數(shù)據(jù)部分的面試題做一個(gè)總結(jié)，希望能對(duì)大家有所幫助。
一、面試準(zhǔn)備
面試前，我花了很多時(shí)間，對(duì)項(xiàng)目進(jìn)行了梳理，尤其在業(yè)務(wù)數(shù)倉(cāng)的分層和多維數(shù)據(jù)模型設(shè)計(jì)這塊。整個(gè)項(xiàng)目的業(yè)務(wù)流程、數(shù)據(jù)流向我用一張白紙進(jìn)行了梳理，數(shù)據(jù)收集 + 數(shù)倉(cāng)建設(shè)+數(shù)據(jù)建模+數(shù)據(jù)清洗 + 數(shù)據(jù)轉(zhuǎn)換+ 特征提取+算法建模+數(shù)據(jù)展示，我覺(jué)得對(duì)自己做過(guò)或者參與的項(xiàng)目，在準(zhǔn)備面試前，做一次系統(tǒng)的復(fù)盤，是必不可少的。
大數(shù)據(jù)技術(shù)棧 這一塊，可以按照B站某谷的一些視頻進(jìn)行復(fù)習(xí)，畢竟一些理論和架構(gòu)的東西，有時(shí)是需要花時(shí)間記憶和理解的，我放一張圖，大家看看自己能了解多少：
二、Hadoop
1、介紹 MapReduce 的運(yùn)行過(guò)程 ，Suffer 過(guò)程
如果在現(xiàn)場(chǎng)，我可以手繪 MapReduce 從 InputFormat 到 OutputFormat 的流程，一邊畫圖一邊說(shuō)。如果講到環(huán)形緩沖區(qū)那里，是不是有很多調(diào)優(yōu)的方式、combiner 也可以考慮講一下。
2、Hadoop 集群的搭建過(guò)程
至少自己集群的配置、框架的技術(shù)選型是不是都要清楚的明明白白。
3、Hadoop 優(yōu)化
1、HDFS 小文件的影響 、輸入輸入時(shí)的小文件的處理
2、Map 階段 和 Reudce 階段的調(diào)優(yōu)
3、數(shù)據(jù)壓縮（LZO \Snappy） 和 存儲(chǔ)優(yōu)化(Orcfile) 關(guān)于壓縮怎么配的，幾種存儲(chǔ)格式有什么區(qū)別是不是都要搞清楚
4、Hadoop集群HA實(shí)現(xiàn)
5、Hadoop 調(diào)度器
FIFO 、Capacity Scheduler（容量調(diào)度器）和 Fair Sceduler（公平調(diào)度器）三種需要區(qū)分清楚，還有在實(shí)際開發(fā)環(huán)境中，一般不用FIFO哦。
6、Hadoop 解決數(shù)據(jù)傾斜方法
1、提前在 map 進(jìn)行 combine，減少傳輸?shù)臄?shù)據(jù)量
2、導(dǎo)致數(shù)據(jù)傾斜的 key 加鹽、提升 Reducer 并行度 …
7、Hadoop讀文件和寫文件流程
8、Yarn 的 Job 提交流程
步驟很多，理理清楚然后再由條理的進(jìn)行回答。
三、Hive
1、 Hive 和關(guān)系型數(shù)據(jù)庫(kù)比較
數(shù)據(jù)存儲(chǔ)位置、數(shù)據(jù)更新、執(zhí)行延遲、數(shù)據(jù)規(guī)模等方面來(lái)比較。
2、Hive 元數(shù)據(jù)管理
hive表中的數(shù)據(jù)是HDFS上的文件，可是hive怎么知道這些文件的內(nèi)容都對(duì)應(yīng)哪個(gè)字段，對(duì)應(yīng)哪個(gè)分區(qū)呢？就是hive的元數(shù)據(jù)管理著這一切。通常在hive-site.xml中的元數(shù)據(jù)庫(kù)配置成MySQL，替換Derby。
3、有沒(méi)有遇到數(shù)據(jù)傾斜的問(wèn)題（場(chǎng)景、解決方式）
常規(guī)的數(shù)據(jù)解決方式，結(jié)合業(yè)務(wù)，隨便講個(gè)三四種不過(guò)分吧。
4、Hive 兩種類型的權(quán)限控制方式
5、Hive UDF，UDTF，UDAF，窗口函數(shù)（row_number, rank,cube,rollup,lag,lead）
6、Hive 的調(diào)優(yōu)
1、壓縮存儲(chǔ)優(yōu)化
2、表設(shè)計(jì)優(yōu)化
3、SQL參數(shù)優(yōu)化
4、SQL語(yǔ)句優(yōu)化
分四個(gè)方向，大概十幾種優(yōu)化的方式，自己都得做些了解吧
7、Hive 分區(qū)和分桶的區(qū)別，內(nèi)部表和外部表的區(qū)別，怎么進(jìn)行動(dòng)態(tài)分區(qū)
8、Hive 幾種存儲(chǔ)方式的區(qū)別？
ORC：行分塊，列式存儲(chǔ)，壓縮快，存取快，壓縮率最高，RCfile升級(jí)版。 然后再和其他三種存儲(chǔ)方式比較一下。
四、Flume
1、Flume 組成，Put 事務(wù)，Take 事務(wù)
Source、Channel、Sink ，想想Flume的架構(gòu)。
Taildir Source、Memory Channel什么的，各自適合用在什么場(chǎng)景下，有什么區(qū)別。
2、Flume 自定義攔截器
可以在講項(xiàng)目時(shí)講，算是一個(gè)小亮點(diǎn)，可以自定義ETL 攔截器和區(qū)分類型攔截器等等
3、Flume Channel 選擇器
Replicating Channel Selector (default)和Multiplexing Channel Selector
這兩種Selector的區(qū)別是:Replicating 會(huì) 將source過(guò)來(lái)的events發(fā)往所有channel,而
Multiplexing可以選擇該發(fā)往哪些Channel。
4、Flume 調(diào)優(yōu)
要知道flume-ng agent包括source、channel、sink三個(gè)部分，這三部分都運(yùn)行在JVM上，而JVM運(yùn)行在linux操作系統(tǒng)之上。因此，對(duì)于flume的性能調(diào)優(yōu)，就是對(duì)這三部分及影響因素調(diào)優(yōu)。
五、Kafka
1、Kafka 的架構(gòu)
2、關(guān)于 Kafka 為什么這么快
順序?qū)懭?、Memory Mapped Files、零拷貝（Zero Copy）、批量發(fā)送和數(shù)據(jù)壓縮。
3、Kafka 和其他消息隊(duì)列的區(qū)別
4、Kafka 如何保證消息隊(duì)列不丟失？
ACK 機(jī)制 、 設(shè)置分區(qū)、關(guān)閉 unclean leader 選舉等等。
5、Kafka 消息數(shù)據(jù)積壓，Kafka 消費(fèi)能力不足怎么處理
如果是 Kafka 消費(fèi)能力不足，則可以考慮增加 Topic 的分區(qū)數(shù)，并且同時(shí)提升消費(fèi)
組的消費(fèi)者數(shù)量，消費(fèi)者數(shù)=分區(qū)數(shù)。（兩者缺一不可）
如果是下游的數(shù)據(jù)處理不及時(shí)：提高每批次拉取的數(shù)量。批次拉取數(shù)據(jù)過(guò)少（拉取
數(shù)據(jù)/處理時(shí)間<生產(chǎn)速度），使處理的數(shù)據(jù)小于生產(chǎn)的數(shù)據(jù)，也會(huì)造成數(shù)據(jù)積壓。
6、Kafka producer consumer怎么實(shí)現(xiàn)at most once和exactly once（冪等計(jì)算和事務(wù)）
7、Kafka 高可用怎么實(shí)現(xiàn)的？
副本數(shù)據(jù)同步策略、ISR、OSR、Leader 選舉機(jī)制（它的和Zookeeper的半數(shù)選舉機(jī)制可不同哦）。
8、Kafka 數(shù)據(jù)重復(fù)
冪等性+ack-1+事務(wù)
Kafka 數(shù)據(jù)重復(fù)，可以再下一級(jí)：SparkStreaming、redis 或者 hive 中 dwd 層去重，去重的手段：分組、按照 id 開窗只取第一個(gè)值。
六、HBase
1、RowKey 怎么設(shè)計(jì)的？
三個(gè)設(shè)計(jì)原則，id+時(shí)間戳反轉(zhuǎn) 什么的，結(jié)合你的業(yè)務(wù)場(chǎng)景講講。
2、描述 HBase 中 scan 和 get 的功能以及實(shí)現(xiàn)的異同？
3、在HBase 中，是允許設(shè)置多個(gè)列簇的，但是為什么在實(shí)際生產(chǎn)中會(huì)設(shè)置很少的列簇呢？
1、列簇的數(shù)量對(duì)flush的影響
2、列簇的數(shù)量對(duì)split的影響
3、列簇的數(shù)量對(duì)compaction的影響
4、列簇的數(shù)量對(duì)HDFS的影響
5、列簇的數(shù)量對(duì)RegionServer內(nèi)存的影響 。
根據(jù)實(shí)際生產(chǎn)需求，能夠用一個(gè)列簇解決的就盡量用一個(gè)列簇，當(dāng)兩個(gè)列簇的數(shù)量相差懸殊時(shí)，可以將其兩個(gè)列簇的數(shù)據(jù)拆分為兩個(gè)表的單個(gè)列簇。
4、HBase 的存儲(chǔ)格式
HBase中的每張表都通過(guò)行鍵按照一定的范圍被分割成多個(gè)子表（HRegion），默認(rèn)一個(gè)HRegion超過(guò)256M就要被分割成兩個(gè)，由HRegionServer管理，管理哪些HRegion由HMaster分配。
5、HBase 的讀寫流程
6、HBase 的優(yōu)化
1、預(yù)分區(qū)
2、rowkey 優(yōu)化
3、減少 Column Family 數(shù)量
7、關(guān)于HBase 數(shù)據(jù)熱點(diǎn)的問(wèn)題
七、Spark
1、 Spark 有幾種部署方式？請(qǐng)分別簡(jiǎn)要論述
Spark 的運(yùn)行模式有 Local(也稱單節(jié)點(diǎn)模式），Standalone(集群模式），Spark on Yarn(運(yùn)行在Yarn上）有 yarn-client 和 yarn-cluster 兩種模式，主要區(qū)別在于：Driver 程序的運(yùn)行節(jié)點(diǎn)。
2、Spark on yarn cluster 作業(yè)提交的流程
3、Spark 提交作業(yè)參數(shù)
4、如何理解 Spark 中的血統(tǒng)概念（RDD）
5、Spark 調(diào)優(yōu)
coalesce 和 repartition / BroadCast join 廣播 join / 控制 Spark reduce 緩存 調(diào)優(yōu) shuffle / 使用高性能算子 等等。
6、Spark 劃分任務(wù)
RDD任務(wù)切分中間分為：Application、Job、Stage和Task ，再詳細(xì)講述各自的聯(lián)系。
7、Spark 寬窄依賴 ，reducebykey 和 groupbykey 的性能誰(shuí)高？
map、flatmap、union、filter ----> 窄依賴
groupByKey，reduceByKey，sortByKey,join 各種Bykey都是shuffle階段 -----> 寬依賴
reducebyKey會(huì)先在本地機(jī)器上進(jìn)行局部聚合，然后在移動(dòng)數(shù)據(jù)，進(jìn)行全局聚合 —> 性能更好
8、分別簡(jiǎn)述 Spark 中的緩存機(jī)制（cache 和 persist）與checkpoint 機(jī)制，并指出兩者的區(qū)別與聯(lián)系
都是做 RDD 持久化的
cache:內(nèi)存，不會(huì)截?cái)嘌夑P(guān)系，使用計(jì)算過(guò)程中的數(shù)據(jù)緩存。
checkpoint：磁盤，截?cái)嘌夑P(guān)系，在 ck 之前必須沒(méi)有任何任務(wù)提交才會(huì)生效，ck 過(guò)
程會(huì)額外提交一次任務(wù)。
9、Spark 的緩存級(jí)別
memory_only、disk_only、memory_Anddisk_only
像cache() 默認(rèn) memory_only 什么的。
10、某個(gè) task 莫名其妙內(nèi)存溢出的情況
這種情況下去定位出問(wèn)題的代碼就比較容易了。我建議直接看 yarn-client 模式下本地log 的異常棧，或者是通過(guò) YARN 查看 yarn-cluster 模式下的 log 中的異常棧。一般來(lái)說(shuō)，通過(guò)異常棧信息就可以定位到你的代碼中哪一行發(fā)生了內(nèi)存溢出。然后在那行代碼附近找找，一般也會(huì)有 shuffle 類算子，此時(shí)很可能就是這個(gè)算子導(dǎo)致了數(shù)據(jù)傾斜。
但是大家要注意的是，不能單純靠偶然的內(nèi)存溢出就判定發(fā)生了數(shù)據(jù)傾斜。因?yàn)樽约壕?/p>
寫的代碼的 bug，以及偶然出現(xiàn)的數(shù)據(jù)異常，也可能會(huì)導(dǎo)致內(nèi)存溢出。因此還是要按照上面所講的方法，通過(guò) Spark Web UI 查看報(bào)錯(cuò)的那個(gè) stage 的各個(gè) task 的運(yùn)行時(shí)間以及分配的數(shù)據(jù)量，才能確定是否是由于數(shù)據(jù)傾斜才導(dǎo)致了這次內(nèi)存溢出。
11、Spark 數(shù)據(jù)傾斜
使用 Hive ETL 預(yù)處理數(shù)據(jù) 、 過(guò)濾少數(shù)導(dǎo)致傾斜的 key 、 提高 shuffle 操作的并行度 、兩階段聚合（局部聚合+全局聚合） 、 將 reduce join 轉(zhuǎn)為 map join 、使用隨機(jī)前綴和擴(kuò)容 RDD 進(jìn)行 join 等等，方法很多，大家可以再深入的了解。
12、Spark 內(nèi)存溢出
1 加內(nèi)存， 簡(jiǎn)單粗暴
2 將rdd的數(shù)據(jù)寫入磁盤不要保存在內(nèi)存之中
3 如果是collect操作導(dǎo)致的內(nèi)存溢出， 可以增大 Driver的 memory 參數(shù)
13、簡(jiǎn)述 Spark 中共享變量（廣播變量和累加器）的基本原理與用途
累加器（accumulator）是 Spark 中提供的一種分布式的變量機(jī)制，其原理類似于
mapreduce，即分布式的改變，然后聚合這些改變。累加器的一個(gè)常見(jiàn)用途是在調(diào)試時(shí)對(duì)作業(yè)執(zhí)行過(guò)程中的事件進(jìn)行計(jì)數(shù)。而廣播變量用來(lái)高效分發(fā)較大的對(duì)象。
14、簡(jiǎn)述 SparkSQL 中 RDD、DataFrame、DataSet 三者的區(qū)別與聯(lián)系?
15、Spark Streaming 控制每秒消費(fèi)數(shù)據(jù)的速度
通過(guò) spark.streaming.kafka.maxRatePerPartition 參數(shù)來(lái)設(shè)置 Spark Streaming 從 kafka 分區(qū)每秒拉取的條數(shù)。
16、Spark Streaming 背壓機(jī)制
把 spark.streaming.backpressure.enabled 參數(shù)設(shè)置為 ture,開啟背壓機(jī)制后 Spark Streaming 會(huì)根據(jù)延遲動(dòng)態(tài)去 kafka 消費(fèi)數(shù)據(jù),上限由 spark.streaming.kafka.maxRatePerPartition 參數(shù)控制，所以兩個(gè)參數(shù)一般會(huì)一起使用。
17、SparkStreaming 有哪幾種方式消費(fèi) Kafka 中的數(shù)據(jù)，它們之間的區(qū)別是什么？
基于 Receiver 的方式
基于 Direct 的方式 -----> 簡(jiǎn)化并行讀取 高性能
八、數(shù)倉(cāng)
1、數(shù)據(jù)倉(cāng)庫(kù)的模型設(shè)計(jì)
結(jié)合業(yè)務(wù)，對(duì)數(shù)倉(cāng)設(shè)計(jì)的過(guò)程做個(gè)概述，例如我的就是常見(jiàn)的四層的一個(gè)模型，ODS、ODW… 層 ，這其中我對(duì)業(yè)務(wù)數(shù)據(jù)做了哪些操作，都得了然于心吧。
2、數(shù)倉(cāng)質(zhì)量怎么監(jiān)控
數(shù)據(jù)質(zhì)量管理系統(tǒng)，主鍵唯一、非空、數(shù)據(jù)波動(dòng)。
3、業(yè)務(wù)建模、數(shù)據(jù)分析方法
4、有沒(méi)有遇到數(shù)據(jù)傾斜的問(wèn)題（場(chǎng)景、解決方式）
5、數(shù)倉(cāng)規(guī)范設(shè)計(jì)哪些方面(字段、維度，存儲(chǔ)壓縮、數(shù)據(jù)保留機(jī)制)
6、數(shù)倉(cāng)有用到增量表、還是全量表？拉鏈表做過(guò)嗎？
下面是我面試前準(zhǔn)備的一些面試題，大家可以自行查漏補(bǔ)缺。
九、寫在最后
畢業(yè)兩年第一次跳槽，當(dāng)年那只非計(jì)算機(jī)專業(yè)，誤打誤撞進(jìn)了大數(shù)據(jù)門的小白，一路修行，磕磕絆絆。
這中間也曾焦慮過(guò)、失眠，凌晨四點(diǎn)爬起來(lái)Coding，又或者除夕夜那晚我還在肝面試題QAQ。時(shí)間久了也會(huì)自我懷疑，覺(jué)得自己這般努力值得嗎？
但是一方面是對(duì)新技術(shù)的渴望，另一方面是來(lái)自房貸的壓力，像是懸在我頭上的達(dá)摩克里斯之劍，讓我時(shí)刻保持清醒的頭腦，不斷學(xué)習(xí)。
最后，我還是確定了阿里系的Offer。凌晨肝了完了阿里面試官留下的最后的實(shí)驗(yàn)方案——將我的大數(shù)據(jù)項(xiàng)目遷移到阿里云的架構(gòu)方案分析，提交過(guò)去能得到面試官的認(rèn)可，也是非常慶幸的事情。
在馬伯庸 《長(zhǎng)安十二時(shí)辰》里看到一句話，非常喜歡，和大家共勉：
禱以恒切， 盼以喜樂(lè)，苦以堅(jiān)忍，必有所得”。
