大資料崗位面試官眼中應聘者如何表現說明其具備「處理大資料(GB TB PB級或以上)的經驗 能力」?

時間 2021-05-31 17:10:21

1樓:

GB級? 我看個小電影都不止了

歸根到底在發現問題、分析問題、解決問題的能力我沒見過專門問大資料處理問題的面試,如果專門問這個的話,估計一般都是團隊缺這方面的人讓你自己講你之前用什麼框架做了什麼事情踩了哪些坑。

問技巧問Knowhow除了裝逼之外沒什麼用,比如我如果問你HyperLogLog,很可能相當多的專案根本不需要用,自然參加面試的人是不太有機會知道的。真要用的時候網上搜一下,知道有這個東西就可以用了,也不太可能自己手寫乙個。

有些問題比如機器的Allocation可能大公司裡資深的員工也沒遇到過

小公司裡的員工可能每天都要解決這些問題

而對於流水線的調優之類的問題可能就相反

如果我是給成熟大資料處理的部門面試的話,

除了考察基礎資質的程式設計和演算法之外,

可能會描述這個部門之前遇到的問題情景來問解決問題的流程方法,比如描述乙個流水線結構,問可以從哪些角度來考慮效能的調優比如描述乙個現象就是流水線經常會掛,問可以從哪些角度來考慮提公升穩定性

2樓:付鵬

不建議取巧地糊弄面試官,有什麼能力不是這裡給幾招就能蒙混過關的。

Hadoop或者Spark的資料處理也沒有那麼強,很多坑基本所有人都會踩到。

簡單說兩點Hadoop。

坑一:reducer資料分布不平均的坑

MapReduce的全流程要搞懂的,如果真的用Hadoop處理過大量資料,幾乎一定會碰到Hadoop自帶Partition的Hash函式不堪用的情況,自己手寫Partition是一定有的。那麼預設Hash是怎麼實現的?你遇到了什麼問題導致Partition給reducer分的不一致?

你怎麼手寫了乙個Partitioner來保證reduce得到的資料量基本上平均?

坑二:長尾reducer的問題

reducer長尾是很典型的大資料量才有的問題,即使有MR實現平行計算的情況下,以key分割資料的MR仍然可能遇到長尾資料分布帶來reducer的長尾,即99%的reducer都執行完了,剩下1%的reducer怎麼也執行不完的情況。

the、a等詞的詞頻遠高於其他詞,導致部分reducer得到的資料遠遠大於其他reducer,當資料量特別大的時候,the、a的資料量也特別大,單機短時間處理不完,就有了長尾的reducer。

這又怎麼處理呢?

上面兩個,都是很常見的場景,處理過大量資料的MR應該都會碰到的。

討論 應聘者如何在面試官中掌握先機?

職場解憂老酒館 1 傾聽 不要搶話 2 事先對公司經營情況做了解和掌握 3 呈現自己的核心價值和專業技能 4 最好帶作品到面試現場,給面試官呈現 公尺奇叔叔 個人愚見,面試的中第乙個問題,往往是介紹自己,看似簡單,其實也是乙個坑,怎麼說都會感覺不是最好,說的太完美有點心虛,說的太簡單又心有不甘,所以...

低水平面試官如何面試高水平應聘者?

豬兒笨笨 首先應該是盡量避免這種情況。我就碰到過這種情況,非常的尷尬。我當時是以乙個資深架構師的身份參加乙個大公司的面試,一共6輪。第一輪和第二輪的面試人員,水平和我差距很大,第一輪只用了5分鐘,他就結束了,然後進入第二輪,同樣沒堅持過10分鐘,第三輪面試官堅持問了三個問題,20分鐘後結束了。我理解...

作為面試官如何判斷應聘者真實的離職原因?

題主的意思是要當面跟你說 前老闆是砂布。看什麼看,你也是 嗎?面試最重要的資訊是 企業傳達 我有什麼條件,要什麼樣的人 面試者傳達 我有什麼能力,需要什麼樣的待遇為啥非要在無關緊要的事情上浪費精力呢? 貝多 有乙個小技巧可以參考,針對每乙份工作進行連環三問,這份工作是怎麼找到的,在開始這份工作前是什...