我是小白我怕誰

要想成為一名糟糕的大數(shù)據(jù)平臺開發(fā)工程師，首先你得干上這行，怎么入門不重要，重要的是自我修養(yǎng)要從入門抓起。

大數(shù)據(jù)開發(fā)如何入門？在各種論壇或技術會議中，時不時地會有人問起這個問題。而提問者的問法往往也很類似：對大數(shù)據(jù)開發(fā)很感興趣，想學大數(shù)據(jù)，但不知道該怎么入門？應該學些什么呢？

對于這個問題，我也總能估計到提問者的預期答案。應該包括一串技能清單，以及回答問題者自身的成功實踐示范：先看什么書，再學什么課程，然后搭建一個什么系統(tǒng)。最好列一個完整的學習計劃和清單，要是還有各種職位需求的市場調研和薪資待遇的統(tǒng)計分析那就更完美了。

至于搞清楚自己到底喜歡什么，為什么喜歡，很重要嗎？讓專家來替自己做主，直接告訴自己該學什么，效率豈不是更高？

敏而好學，不恥下問

學什么的問題解決了，下面來解決怎么學的問題。

遇到問題前先思考一下，看一下文檔，讀點代碼，分析一下日志？不存在的。都什么年代了，社交為王。微信里加了這么多大數(shù)據(jù)群組干嗎用的？“討論”問題??！“敏”而好學，快就一個字！

要是有人膽敢拿出“如何問一個好問題”這樣的垃圾文章出來敷衍這樣好學的同學，那就是傲驕。往往會被這位同學反駁：問一下不可以嗎？你懂還是不懂？懂就回答，不懂就不要胡說！古人云：不恥下問，你能有回答的機會就是你的榮幸！

那么，如果想在這個領域長期耕耘下去，這樣做靠不靠譜呢？據(jù)說大數(shù)據(jù)平臺相關開發(fā)工作，面對的問題往往是復雜的，需要從業(yè)人員具備良好的學習總結和推理分析能力。如果不具備主動學習和思考的習慣，聽說也就幾乎不可能成為這個領域的專家？

在這些同學看來，這種言論簡直就是妖言惑眾。事實勝于雄辯，明明有好多公司，有很多同學，在日常工作中就是這么做的。他們也搭過集群，復制粘貼過代碼，寫過ETL程序，遇上過“特別復雜”的難題，比如集群莫名其妙起不來了之類的，百度一下專家推薦的配置參數(shù)或者搜索一下出錯信息就搞定了，還經常寫點“我司數(shù)據(jù)平臺的踩坑經驗和實戰(zhàn)的分享”，你就說牛不牛吧！

什么？這種情況長久不了，這類工作遲早會被替代，尤其是在偏底層的基礎平臺開發(fā)工作環(huán)境中？那得多久的將來??？至于AWS和阿里云平臺上的標準化服務，沒聽過，我們要有自主知識產權啊！

效率優(yōu)先，中文至上

能百度就不谷歌；能找到不知道誰寫的搭建筆記，就堅決不讀官網(wǎng)的向導文章。要是還有手把手的教學視頻，那就更好了。

集群如何調優(yōu)？問題如何解決？根據(jù)錯誤信息，搜索踩坑指南，別管花多少時間，在多么不起眼的博客也要搜出來。至于官網(wǎng)的問題FAQ或性能調優(yōu)指南，抱歉，沒時間看。至于郵件列表和Jira，那是什么東西？

怎么，這么做不行嗎？有些同學可能回答，這也沒啥大不了，不是看不懂英文，但是還是更習慣看中文，如果不到山窮水盡，能用中文就用中文唄。

或許你總能給自己找到這么做的充分理由，但除非你想永遠玩別人早就玩剩下的東西，否則，還是應該盡可能接觸第一手資訊。覺得英語水平差，看英文文檔代價很高嗎？實際上，篩選過時或錯誤信息的代價可能更高。

流行的就是最好的

什么技術熱門就學什么，不管自己行不行，先看賺不賺錢。

這種現(xiàn)象不只在大數(shù)據(jù)領域存在，在各個技術領域都存在，從這幾年我所接觸的求職者的求職意愿上就能很明顯地看出來。

無論校招還是社招，無論是剛從別的方向轉行想做大數(shù)據(jù)，還是在大數(shù)據(jù)領域內已經有過一些簡單業(yè)務開發(fā)經驗的同學，幾乎90%以上的應聘者都會把自己將來的工作和實時計算掛上鉤，越是“初生牛犢”越是積極?？刹?，不玩Spark，不玩Flink，還怎么跟上時代，大家都說Hadoop已經被淘汰了！

其實蹭熱點本身問題不大，不過要想長期發(fā)展，關鍵是你本身也要具備相應的實力，大家都想做的事，你憑什么能比得過別人，就算現(xiàn)在沒問題，過幾年等該領域成熟了呢？與其研究哪里是熱點，不如想想自己適合做什么樣的工作，如何讓自己在技術的變革中持續(xù)成長。

我們的征途，是星辰大海

也有同學會說，我并不是跟風追熱點，只是當前的工作真的不適合我，我希望去做更有價值、更有挑戰(zhàn)的事。為什么現(xiàn)在的工作不合適呢？ 比如：

業(yè)務太煩，瑣事太多，沒有時間學習。

干了很長時間，重復勞動，沒有成長的空間。

系統(tǒng)很成熟了，沒有什么可做的了。

做的事沒挑戰(zhàn)，發(fā)揮不出我的能力。

做的事太普通，覺得沒前途。

問題太多，團隊技術水平太差。

總之，就是我行，但是，這事不行、環(huán)境不行，所以我要換方向、我要換地方。

誠然，上述情況未必不客觀，很可能也是這些同學在工作過程中的真實感受。但我敢說，如果這就是全部原因，那么，有一多半問題的根源不在環(huán)境，而在我們自身。因為上述情況只是問題和現(xiàn)象，不是答案和原因。

瑣事太多，重復勞動太多？有沒有思考過如何化繁為簡，還是只會用體力勞動代替腦力勞動？

系統(tǒng)成熟，沒什么可做的？是系統(tǒng)真的完美無瑕了，還是我們坐井觀天，眼界太低，不知道該如何改進？

做的事沒挑戰(zhàn)，做的事太普通？是事情本身太普通，還是做事的目標和方法太普通？

問題太多？是同事能力太差，還是自己只會頭痛醫(yī)頭，解決問題不徹底，又或者是沒有能力推進復雜問題的解決？

當然，每個人都希望在一個最好的環(huán)境中工作，這并沒有錯，但如果你只是單純地回避問題，而未曾解決過這些問題，那么在新的環(huán)境中，你早晚還是會遇上同樣的問題。

書中自有顏如玉，熱衷閱讀代碼

有些同學，特別是經常和開源相關組件打交道的同學，會特別喜歡閱讀代碼。

閱讀代碼，當然沒錯，說實話，愛讀代碼的同學現(xiàn)在也不好找了。但是，過猶不及，畢竟閱讀和熟悉代碼只是手段，而非最終目的。遺憾的是，有時候，很多同學往往并沒有認識到這一點。

這些同學很可能慣性地認為，只有依靠完全徹底地理解代碼，才能得到第一手資料，才能更好地評估實施方案。

而事實上往往事與愿違，一方面，你可能迷失在一些無關痛癢的局部細節(jié)上；另一方面，你可能忽視了真正需要盡早找出答案的問題。

實際上，這也是一種用戰(zhàn)術上的勤快來掩蓋戰(zhàn)略上的懶惰的行為表現(xiàn)。因為閱讀代碼可能是程序員最習慣做的事。但是，采用其他可能的方式去評估或熟悉一個未知的系統(tǒng)呢？

比如詳細閱讀官方文檔，進行功能驗證和Demo測試，對類似系統(tǒng)進行橫向比較，收集他人踩坑經驗，尋找問題的其他可能解決途徑等，這些工作往往有可能更加快速全面地幫你了解一個系統(tǒng)，并做出合理的方案設計。但是這么做會涉及持續(xù)的思考、分析、判斷和嘗試的過程，所以有時候很多同學往往不愿意在這上面多費力氣。

謎之問題的謎之解決方式

相比閱讀代碼的執(zhí)著，很多同學在分析問題時的表現(xiàn)卻往往與之相反。

分布式環(huán)境下的問題往往錯綜復雜，如果一個問題不是明顯的確定性邏輯錯誤，而是跑得慢、性能差、莫名其妙地隨機崩潰、超時等，不少同學很容易就快速陷入迷茫中。而為了將自己從迷茫中掙脫出來，往往會在問題排查過程中，輕易地將某些故障的現(xiàn)象歸結為故障的原因，進而以治標不治本的方式來解決問題。

做得好一點的代碼流派的同學則可能在排查問題過程中，發(fā)現(xiàn)一個Error或Warning日志，還會去閱讀相關的代碼，最后花幾天時間閱讀完代碼，可能分析出了什么流程會打印出這個Error日志，但卻不知道或者解釋不了為什么當時程序會走到這個流程，同樣也就排查不下去了。

上述情況，通常還是方法論問題，不知道如何把握問題的重點，在問題自身信息尚未收集清楚的時候，就過早地聚焦在某個收益未知的現(xiàn)象上。而對于進一步的動作，比如：

質疑問題，考證現(xiàn)象，現(xiàn)有的結論是否站得住腳，是否還有疑點。

能否再多方面收集一些信息，或者換一個角度，嘗試用別的方式分析問題。

能否想辦法復現(xiàn)問題，或者學習新的技能解鎖進一步分析問題的能力。

能否改進日志，爭取下一次問題出現(xiàn)時能收集到更多信息。

在自以為修復問題后，能否針對性地進行后續(xù)的監(jiān)控分析，看看是否真的解決了問題。

在類似這些工作方面，往往就沒有表現(xiàn)出應有的執(zhí)著了。

勤奮好學，但是回頭即忘

作為一個有夢想的工程師，你一定會去關注新技術。

如果方法得當，在短期內依靠深入閱讀文檔、翻閱核心代碼等手段，你往往可以快速地在幾天內對一個系統(tǒng)形成基本的認知。

只可惜，大數(shù)據(jù)領域的技術日新月異，加上很多系統(tǒng)相對復雜的架構特點，決定了這些新技術往往信息量不小，如果你沒有真正深入地實踐過，通常很難形成有效的長期知識記憶?？赡茉龠^一個月，你剛掌握的內容就都忘得一干二凈了。

花費的精力就要產生價值，做好留存工作，在一個需要長期積累的領域，很多時候可能比拉新更加重要，將來的激活成本也會低很多。

總結

反面視角談完了，再從正面雞湯的角度總結一下吧：

有“錢途”的方向，未必適合你，除非你具備戰(zhàn)勝80%以上的跟風者的能力。

“快速”學習的結果通常是欲速則不達，請學會思考，請閱讀第一手資料。

閱讀代碼很重要，但比閱讀代碼更重要的是閱讀問題。

知識面決定了你的廣度，但信息不等于知識面，人云亦云的概念一錢不值。

在抱怨工作之前，先審視自身問題，畢竟改變自己更加容易，也更普遍有效。

最后再補充一句在食品安全反偽科學中常說的一句話：“脫離劑量談毒性，都是耍流氓”。上述所有問題，并無絕對的對錯，重要的是對程度的把握，你是否認清了自己的目標，你所做的事情與你想要的結果是否能夠匹配。