大家好，我是魚皮。因為種種原因，最近我接手了組內(nèi)部分大數(shù)據(jù)開發(fā)工作，對我來說是一個幾乎完全陌生的領(lǐng)域；大學(xué)雖然也自學(xué)過，但也都是淺嘗輒止，面對企業(yè)項目還是有點虛的，所以最近抽了很多時間在自學(xué)大數(shù)據(jù)，很少寫文章了。

現(xiàn)在算下來做大數(shù)據(jù)工作也一個多月了，今天給大家分享一下我從后臺開發(fā)無縫轉(zhuǎn)行到大數(shù)據(jù)的學(xué)習(xí)過程、工作心得、以及自己對后臺和大數(shù)據(jù)這兩個崗位的看法。

自學(xué)過程

其實工作中很難有機會利用上班時間去學(xué)習(xí)，感覺會有種摸魚的負罪感。而且雖然說我接手了大數(shù)據(jù)的工作，但并不是說就不做后臺開發(fā)，我還要接著維護之前負責(zé)的系統(tǒng)。所以基本只能下班后每天擠時間學(xué)一會兒，周末再多一點。

在工作中學(xué)習(xí)的心態(tài)和在學(xué)校那會兒還是很不一樣的。在學(xué)校的時候時間多，一套教程能完整看完，看完后還能自己再做點兒東西；但在工作中學(xué)習(xí)有點趕鴨子上架，需求已經(jīng)排給你了，不能拖延。

所以接手工作第一天就直接上手看代碼，我就看別人怎么寫，然后復(fù)制粘貼過來自己修改一下，能運行就問題不大。但是你不知道別人為什么要這么寫，所以哪里看不懂呢我就去網(wǎng)上查、零零散散學(xué)一點，下班再看教程把這些知識串起來。

看教程的時候我也全程 1.5 倍速，忽略了像環(huán)境搭建、課后練習(xí)之類的章節(jié)（工作中環(huán)境別人都搭好了、做需求本身就是練習(xí)嘛）更多的是去了解框架的原理和開發(fā)經(jīng)驗，比如 Spark 的任務(wù)提交流程、Shuffle 過程、調(diào)優(yōu)手段等等。因為自己記性比較差吧，所以也整理了下自學(xué)筆記。

我個人感覺如果已經(jīng)有一定開發(fā)經(jīng)驗了，用這種帶著目的去方式學(xué)習(xí)可能會更快一點。就比如你想做一個聊天軟件，那你可以針對性地去學(xué)即時通訊相關(guān)的技術(shù)。工作之后，我學(xué)新技術(shù)時也會思考能否運用到自己的項目中。

工作心得

記得我在學(xué)校第一次學(xué)大數(shù)據(jù)的時候感覺這東西老牛逼了，但實際工作后發(fā)現(xiàn)，并沒有我想的那么復(fù)雜和高深，只是換了一種搬磚的方式而已。。。因為現(xiàn)在拜這個 Spark SQL 之類的牛逼框架所賜，實際工作就是根據(jù)需求寫 SQL 跑數(shù)據(jù)，說白了就是 SQL Boy。而且有一些優(yōu)秀的產(chǎn)品懂 SQL，他直接在需求文檔上就把你需要的 SQL 寫好了，你甚至都不用思考邏輯，就復(fù)制粘貼 SQL 到代碼里就行。

有同學(xué)會說大數(shù)據(jù)開發(fā)還要建設(shè)數(shù)倉、搞分層、搞資源的分配，但問題是等我接手開發(fā)的時候，前人都已經(jīng)把這些建設(shè)好了呀。就跟造車一樣，別人把車殼子都搭好了，我在車底擰螺絲不就行了么？

雖然聽我描述挺簡單，但自從做了大數(shù)據(jù)開發(fā)后，我下班時間會比平時更晚。不是因為開發(fā)很難，而是因為調(diào)試程序麻煩、很費時間。

因為啥呢？

首先要計算的數(shù)據(jù)量非常大，很多任務(wù)基本都是要 幾千核 CPU、幾個 T 的內(nèi)存去計算幾個小時才能完成；還有就是每個組的資源是有限的，就分給你那些 CPU 和內(nèi)存，資源不夠你自己想辦法。

想起之前一些同學(xué)的吐槽：說什么 SQL 竟然能運行超過 1 分鐘？對大數(shù)據(jù)離線計算來說，這真的是家常便飯了。

在這種情況下，先不說我們有足夠的資源去測試啊，有的時候線上任務(wù)的資源都不夠，Leader 還經(jīng)常要去借資源。

所以我們每個大任務(wù)什么時候執(zhí)行都得安排好，上午跑 A、下午跑 B。想要調(diào)試呢，就只能見縫插針，比如我中午吃飯前，看看現(xiàn)在資源利用率沒那么滿，我就趕緊跑個測試任務(wù)，觀察一下；晚上睡覺前，看看這會兒其他同事沒跑任務(wù)，那我趕緊測試，還得熬夜觀察一下。大家誰要跑大任務(wù)的測試之前，最好在群里打個招呼：這個集群我占用了，大家先等會兒。

當(dāng)然我們也一直在對任務(wù)進行優(yōu)化，不斷地緩解上面這些情況。不過目前感覺我還是經(jīng)驗不足，很多時候都是 Leader 找到了優(yōu)化思路，然后我按他的思路去改代碼。所以還是得持續(xù)學(xué)習(xí)吧。

下班晚還有一個原因就是跨語言開發(fā)的成本。我之前寫 Java 比較多，現(xiàn)在開發(fā)大數(shù)據(jù)用 Scala 和 Python，我就對自己很不自信了。比如有一次看到同事之前在代碼中寫了個 if 1 == 1 ，于是我復(fù)制粘貼的時候也把這個 1 == 1 一起站過來了，都不敢刪掉，生怕出什么問題。后來問同事說可能是當(dāng)時為了測試方便吧，把 1 改成 0 就可以忽略底下那部分代碼，像這樣：

if 1 == 0:
  do_something()

這樣就不用把代碼注釋掉了。

優(yōu)雅，太優(yōu)雅了?。ㄓ靡粋€變量來判斷感覺會更可讀一些）

后臺 VS 大數(shù)據(jù)

都說隔行如隔山，我卻覺得后臺和大數(shù)據(jù)開發(fā)有很多相似之處。比如：

• 都是寫代碼、都可以復(fù)制粘貼
• 都需要明確需求、都側(cè)重于理解邏輯
• 開發(fā)流程基本一致，都要測試驗證后再上線
• 都需要比較強的 SQL 能力
• 都注重時間、空間、穩(wěn)定性的優(yōu)化等等

也有很多同學(xué)問我啊，比較糾結(jié)大數(shù)據(jù)和后臺開發(fā)選哪個，這兩個工作體驗下來，我還是更傾向于后臺開發(fā)的，感覺個人發(fā)揮和思考的空間會多一些。

個人感覺大數(shù)據(jù)開發(fā)有一點點機械，從需求和實現(xiàn)上來看，基本都比較明確，產(chǎn)品要這些字段，你就給我寫 SQL 輸出這些字段，做完不會有太大的成就感；從技術(shù)上看，很多東西框架都幫你搞定了，調(diào)優(yōu)方法也相對比較固定，要想自己大刀闊斧改造幾乎是不可能的，除非你學(xué)的很深很深，導(dǎo)致大多數(shù)同學(xué)要么是 SQL Boy 要么是 SQL 之父（大牛）。

但后臺開發(fā)的變數(shù)可能更多一些，你有機會去擴展需求、提出見解，也可以設(shè)計不同的方案去實現(xiàn)需求，和產(chǎn)品一起把系統(tǒng)做的更好，會有一種積累帶來的成就感；從技術(shù)上來看，后端相關(guān)的技術(shù)多種多樣，數(shù)據(jù)庫、緩存、隊列、網(wǎng)關(guān)等等，你有很多的學(xué)習(xí)空間，而且每學(xué)一個知識基本都是有機會運用的，可以逐步提升。

當(dāng)然無論你選哪個工作，都要持續(xù)提升知識廣度、思維深度、認知高度，多站在上層、宏觀的角度去看待問題，而不要只滿足于在車底擰螺絲吧。共勉！

總之我覺得有機會嘗試不同的工作還是挺好的，我也又復(fù)習(xí)了像 Scala、Python 這種語言，拓寬了邊界和視野、積累很多經(jīng)驗。學(xué)習(xí)大數(shù)據(jù)的過程中也給了我一些后臺開發(fā)的思考和啟發(fā)，后面給大家分享一下。

當(dāng)然了，以上只是我自己的感受啊，僅僅是記錄一下，供大家參考，也許我的心態(tài)和看法會隨著未來的工作而發(fā)生變化吧~

最近每天我都會在自己的 編程知識星球 里寫工作日記，給大家分享工作心得和工作中用到的技術(shù)知識（已經(jīng)堅持快 20 天了）。感興趣的同學(xué)歡迎加入，和 8700 多名小伙伴一起交流學(xué)習(xí)。我每天都在更新星球里的學(xué)習(xí)資料、項目源碼、求職信息，也在持續(xù)回答星球里小伙伴的問題、幫忙修改簡歷，歡迎大家~ 可以訪問 https://yupi.icu 來了解詳情。