這是個老生常談的話題，大家是不是看到這個文章標題就快吐了，本來想著手寫一些有技術深度的東西，但是看到太多童鞋卡在入門的門檻上，所以還是打算總結一下入門經驗。這種標題真的真的在哪裡都可以看得到，度娘一搜就是幾火車皮，開啟一看都是千篇一律的“workcount”、“quickstart”，但是這些對於初學者來說還差的太多，這些東東真的只是spark的冰山一角，摸著這些石頭過河的話，彎路太多、暗礁湧動，一個不留神就掉河裡了。希望我這篇文章能讓大家看到些不一樣的地方。文章分五個部分，包括官網、blog(特指某sdn)、書籍、原始碼、視訊五個角度，多視角分享一下對於初學者而言在選擇學習方法時改如何取捨。

之所以說奇葩，是因為大家都是相互抄啊抄，這個在某sdn特別流行，知乎上已經有關於這個的吐槽了，國內的技術論壇跟國外還差幾條街，Stack Overflow上關於各種疑難雜症的回答都非常專業，但是國內鮮有這樣的大型平臺。如果大家要通過某sdn的技術部落格學習spark，那坑真是太多，大家能碰到及時更新並且分析深入、全面且合理的博主的概率真是太低。首先在資訊大爆炸時代，人人都是資訊源，部落格太多太多，這是資訊太多帶給學習者的困擾。其次在移動網際網路時代，大家的學習時間也都被碎片化了，估計大家大部分時間都被手機佔據，很少有人願意花時間坐在電腦前認真的看技術論壇上的部落格了，所以微信的技術公眾號才能大行其道。但是，現在的技術公眾號也是太多太多，所以大家要平時留意優秀的技術部落格，積累優秀公眾號就跟學習一門技術一樣，是一個積累的過程，不是別人給你推薦幾個就一定是好的。但是不要關注一些大型平臺的官方公眾號，虛的東西太多，沒什麼乾貨。至於個人覺得不錯的spark學習相關的公眾號在這裡就不推薦了，你懂的。。。。

不得不說，spark的官網程式設計手冊，還是特別的好的，更新及時，覆蓋面廣，但是缺點也很明顯，那就是官網的程式設計手冊，其實並不適合初學者。為什麼這麼說，首先，它只給出了程式碼片段，而初學者需要的是一個可以執行起來的工程。初學者往往對spark沒有任何的初始印象，他們需要的是一個有輸入有輸出的直觀的工程，通過這個工程，輸出變成了輸出，他們也就知道spark是幹些什麼的了。誠然，spark最近版本的程式設計手冊給出了編寫spark應用需要的依賴，但問題是很多初學者連maven都沒有用過，他們更不知道這些依賴應該如何使用，也不知道這些依賴和程式碼片段應該如何組合才能構建出一個開發環境來。有些童鞋會說，通過spark-shell可以達到這個目的啊，不需要新增依賴，所見即所得，即寫即用，但問題時，一開始就一直使用spark-shell學習的話，其實不知道現網真正的spark應用都不是通過這種方式提交的，這就在一定程度上誤導了初學者，他們把spark-shell用的很熟，以為這就是spark的常規使用方式了。官網程式設計手冊的第二個問題是，它給出了api的使用方法，卻沒有給出這些api的使用場景，誠然，不能要求程式設計手冊給出應用場景來，但這也正是程式設計手冊不適合初學者的原因，因為如果不瞭解這些api的使用場景，那麼即使手動生成幾個資料，把這些api測試一遍，學習者不會對這些api有什麼印象，更無法激起他們深入學些這些api底層實現的興趣，他們也不會去注意這些api之間的微妙差異，更無法通過api看到spark的全貌來。我到目前為止，在實際專案中沒有使用過的api理解也不是很深刻，只是瞭解一些他們理論上的實現和差異。舉個例子，我們都知道spark的transformation操作是lazy模式，要靠action去啟動，但是如果我的一個應用場景就是沒有transform，那我應該靠那個action來完成這樣一個並行化的處理流程呢？感興趣的可以思考一下這個問題，其實spark提供了api的，但是大家在學習程式設計手冊時往往不會去注意到這個問題。官網程式設計手冊的第三個問題，就是測試資料來源都太簡單，絕大多數都通過一個api生成幾個簡單的數值型別或者字串型別，資料量也很少，但是問題是，我們在實際專案中，spark的輸入資料千差萬別，有些來自檔案比如本地檔案或者HDFS檔案，有些來自其他的DBMS比如mysql等，有些來自網路比如kafka或者flume，有些甚至是spark自己產生的，而如果只是通過api生成資料的方式來描述程式設計過程，其實不利於初學者瞭解spark的真是使用方法。這也就是為什麼很多童鞋說看官網的api手冊看的懂，但是實際專案就比較懵逼的原因了。

看書確實是一個不錯的入門途徑，隨著spark的火熱，現在國內國外的spark書籍也是越來越多，但是往往存在幾個問題。第一，版本老舊。這是沒辦法的事情，spark更新太快，寫本書特別是技術書籍，一般都是以半年為單位，半年後書籍出版時，spark都不知道迭代了多少個小版本了，甚至都可能有大版本的跟新，所以大家選擇書籍時，可以先通過各種渠道打聽一下某本書是基於spark哪個版本寫的。但是也不是說老的版本不能看，如果有沒有跨大的版本，還是有一定參考意義的。這裡給大家普及一下spark的版本號的知識：

spark書籍的第二個問題是，大家要清楚這本書是怎麼分類的，怎麼講呢？從橫向來看，spark有非常多的用途，比如可以用於ETL、實時處理、資料分析、資料探勘、機器學習，那麼spark書籍也需要從這個角度去分類。那麼從縱向來看，有spark原理講解的、實戰的、原始碼分析的，這又是另外一個分類視角了。個人認為最好的途徑是：如果有非常實際的橫向需求，比如要做資料分析，那麼就從資料分析相關的spark書籍入手，不要一開始就去看原理性的東西，因為你從實際需求入手的話，過段時間你就會非常想了解底層原理了，在這種內在需求的推動下，這時再去看原理相關的書籍效果就會非常好。如果沒有實際的橫向需求，那就只能從原理性的書籍入手了。看書的另外一個誤區就是很多人覺得看一遍就行了，其實很多技術書籍需要反覆的看反覆的體會，不要覺得自己看書要看好幾遍才能理解是自己笨，從而自欺欺人不去複習。

其實很不推薦初學者一開始就去看原始碼，這往往是一個性價比比較低的入門方法，我知道一個剛剛畢業幾個月的童鞋，花了幾個月看spark原始碼，給spark原始碼添加了80%的中文註釋，但是當我問他一些spark使用和非常常用的優化時，他卻一個都回答不上來。大家覺得這樣一種狀態，去面試，能拿到好的offer嗎？我換工作時去參加面試，並沒有被問到什麼spark原始碼的東西，可以說基本沒人問，因為面試官非常清楚一個事實，那就是誰都能把spark原始碼看個一知半解，但是這樣的人並不能代表他能用spark開發出高效的分散式應用來，而這種能力的培養，必須是有實際的專案實踐經驗才行。國內目前95%的公司對spark的使用都停留在應用層面，只要能使用開源spark寫出高效的應用即可，對原始碼的閱讀只可能是一個加分項，因為他們希望你通過原始碼閱讀加深優化spark分散式應用的方法的理解和加快問題定位，並沒有希望你能通過spark原始碼閱讀能對spark進行二次開發。spark原始碼的閱讀確實很有必要，但絕對不是在剛剛開始學習的時候，這點大家切雞切雞！我在2013年初次接觸spark時，公司是對spark有二次開發需求的，那時就很盲目的閱讀了很多spark core部分的原始碼，但是對spark api的使用卻非常非常初級，很不利於對spark整體體系或者大資料整體架構的理解。走了這樣的彎路，希望初學者能吸取這樣的教訓。

為了體驗一把初學者，我特意買了tensorflow的視訊，但是發現實在是看不下去，分析了一下原因，主要是第一，我已經有了多年的工作經驗，很多基礎的東西其實不需要聽，但是培訓機構為了考慮初學者以及課程完整性，會加入非常多的基礎知識，比如語言基礎，環境搭建等。建議有一定基礎的朋友，這些東西可以直接跳過，聽他講根本沒有自己實際操作來的快。第二，視訊一般都會宣稱自己有實戰專案，但是這其實是一個挺搞笑的事情，實戰實戰，是聽出來的嗎？實戰一定要自己動手操作，自己解決專案中遇到的問題，這才是實戰，視訊中最多也就是應用場景介紹而已。一句話，沒有老闆催的東西，都不叫實戰。即使你按照視訊中的案例操作一遍，遇到實際專案還是懵逼狀態。spark的api是固定的，但是應用場景千變萬化，只有實際專案才能從本質上提升一個人的spark能力。看視訊真心不如看書和實操，很多初學者甚至已經入門的童鞋，覺得看視訊很輕鬆，但是這就跟減肥機構騙女人吃減肥藥去減肥一樣，這些女人一般比較懶，想通過捷徑去減肥，殊不知靠減肥藥其實沒有效果，對很多女人來說都是心理安慰而已，真正的減肥要考堅持鍛鍊和有效的食物熱量控制，是個艱苦卓絕的過程。這跟學習一門技術是一個道理。

講了這麼多，怎麼沒有給出解決方案來？原因就是，學習spark沒有固定套路可走，任何一種方法都是優點和缺點並存，而且每個人的基礎是不同的，要給出一套通用的解決方案其實是一種不負責任的行為，我上邊講這麼多隻是為了提醒大家。大家唯一要做的事，就是不要在猶豫不決了，spark是絕對是未來大資料的基礎，火的一塌糊塗，多少人因為spark發家致富了。手頭有什麼就拿起什麼來，有視訊就看視訊，有書就看書，開始搭環境寫程式碼，一個字“開幹！”，各種方法都嘗試一下，過上一段時間，你從各個方面學習的點滴spark知識就會連成一片，從而達到融會貫通的效果。我見過很多人成功轉行大資料，靜下心來自己訂製學習計劃、準備面試、入職、專案實戰、進階、再學習、再實戰、再進階，自己給自己形成一個良性迴圈！

更多精彩內容，請關注spark技術學院，bat一線工程師和你互動，一起學習spark，一起迎接大資料時代！