我是小白我怕誰

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

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

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

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

敏而好學，不恥下問

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

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

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

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

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

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

效率優先，中文至上

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

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

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

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

流行的就是最好的

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

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

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

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

我們的征途，是星辰大海

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

業務太煩，瑣事太多，沒有時間學習。

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

系統很成熟了，沒有什么可做的了。

做的事沒挑戰，發揮不出我的能力。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

謎之問題的謎之解決方式

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

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

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

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

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

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

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

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

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

在類似這些工作方面，往往就沒有表現出應有的執著了。

勤奮好學，但是回頭即忘

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

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

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

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

總結

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

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

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

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

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

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

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