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