寫在前面:我是「雲祁」,一枚熱愛技術、會寫詩的巨量資料開發猿。暱稱來源於王安石詩中一句
[ 雲之祁祁,或雨於淵 ]
,甚是喜歡。
寫部落格一方面是對自己學習的一點點總結及記錄,另一方面則是希望能夠幫助更多對巨量資料感興趣的朋友。如果你也對資料中臺、資料建模、資料分析以及Flink/Spark/Hadoop/數倉開發
感興趣,可以關注我的動態 https://blog.csdn.net/BeiisBei ,讓我們一起挖掘資料的價值~
每天都要進步一點點,生命不是要超越別人,而是要超越自己! (ง •_•)ง
活著就意味必須要做點什麼,請好好努力。
我是年前離職的,沒想到這個突如其來的疫情,完全將面試升級為地獄難度,焦慮、煩躁、失眠,是過去一個月的主旋律。
自四月上旬投第一封簡歷開始,前一週完全是在欸打,最氣的面試的小公司,還沒到技術面,HR對我說了一句:「 18屆,我們最高只能給11K。」 我:「????」
說實話,我不甘心,真的。畢竟在過去一年,我很少有早於凌晨睡的,每天堅持對技術進行復盤,然後不斷的學習新東西,我的預期自然也遠遠不止於此。
從一開始的焦慮、迷茫,到對自己的技術產生的深深的懷疑。
幸虧,身邊一幫小夥伴互相打氣,然後還有像敖丙(為何丙丙和我一樣大,能這麼優秀┗|`O′|┛ )他的一些工作和生活經歷給了我很多共鳴以及給了我一個努力的方向吧。
接下來,陸陸續續面試了中軟國際、翼海雲峰、華訊方舟、明略科技、賽意資訊、浙江大華、中新賽克、華為OD、焦點科技、浩鯨、阿里雲…近20家南京/杭州的大中小廠,最終成功上岸,我就巨量資料部分的面試題做一個總結,希望能對大家有所幫助。
面試前,我花了很多時間,對專案進行了梳理,尤其在業務數倉的分層和多維資料模型設計這塊。整個專案的業務流程、資料流向我用一張白紙進行了梳理,資料收集 + 數倉建設+資料建模+資料淨化 + 資料轉換+ 特徵提取+演演算法建模+資料展示,我覺得對自己做過或者參與的專案,在準備面試前,做一次系統的覆盤,是必不可少的。
巨量資料技術棧 這一塊,可以按照B站某谷的一些視訊進行復習,畢竟一些理論和架構的東西,有時是需要花時間記憶和理解的,我放一張圖,大家看看自己能瞭解多少:
1、介紹 MapReduce 的執行過程 ,Shuffle 過程
如果在現場,我可以手繪 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 提交流程
步驟很多,理理清楚然後再由條理的進行回答。
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升級版。 然後再和其他三種儲存方式比較一下。
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的效能調優,就是對這三部分及影響因素調優。
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 開窗只取第一個值。
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 資料熱點的問題
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、數倉有用到增量表、還是全量表?拉連結串列做過嗎?
下面是我面試前準備的一些面試題,大家可以自行查漏補缺。
Interview Summary |
---|
Hadoop 相關面試題總結 |
Hive 相關面試題總結 |
Hive 基礎知識及優化總結 |
HBase 相關面試題總結 |
Spark 相關面試題總結 |
Flume 相關面試題總結 |
Kafka 相關面試題總結 |
Flume 企業真實面試經驗 |
畢業兩年第一次跳槽,當年那隻非計算機專業,誤打誤撞進了巨量資料門的小白,一路修行,磕磕絆絆。
這中間也曾焦慮過、失眠,凌晨四點爬起來Coding,又或者除夕夜那晚我還在肝面試題QAQ。時間久了也會自我懷疑,覺得自己這般努力值得嗎?但是一方面是對新技術的渴望,另一方面是來自房貸的壓力,像是懸在我頭上的達摩克里斯之劍,讓我時刻保持清醒的頭腦,不斷學習。
馬伯庸 《長安十二時辰》裡看到一句話,非常喜歡,和大家共勉:
「禱以恆切, 盼以喜樂,苦以堅忍,必有所得」。