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