大數據實踐總結－－－一點思考

本文算是一個階段總結吧！總算是把MapReduce給搞完了。細想這三週來的收穫，可能除了代碼，更多的是邏輯上的提升吧！下邊就以以前只會理論時的一些問題來開啓本文吧！

1，大數據架構師，產品經理須要寫代碼嗎？

  須要，只不過寫代碼的程度不一樣。大數據架構師要詳細瞭解大數據的各個模塊功能，相關的接口參數。能夠說，架構師要對代碼有很詳細的瞭解。大數據的相關工做中，架構，開發，運維都須要寫代碼。但每一個人寫的代碼內容也不相同。對於一個IT公司來講，這三塊主要是主開發人員，對代碼經驗都有很大要求。

  產品經理，主要是研究客戶需求。對於一個團隊來講，一個好的產品基本定型了這個公司的將來。他能夠會代碼，也能夠不會，但最好會點。要把握一個產品的運營，營銷，各個環節。因此，產品經理最好是從代碼工程師出來的，這樣跟代碼開發人員溝通起來也會方便一些。

2，MapReduce的代碼須要一一來寫嗎？

  不必定。天下文章一大抄。而代碼這一塊，在會了基本的語法，嵌套，循環以後，你能夠去套用別人好的代碼。多去看其餘人的代碼，多看優質代碼，這樣不光是優化了你代碼邏輯，也便於你寫出更優質的代碼。好的代碼自身就是註釋。

  曾經就發現，本身要寫10多行才能實現的功能，有的人一行代碼就能夠實現。發現對於對方非常佩服。後來就明白了爲何，IT公司在招聘的時候必定要招有相關代碼經驗的人。這樣會更便於團隊合做及代碼修改。

3，售前解決方案跟產品經理的關係，如何轉型？

  其實是在不一樣行業的兩種叫法，售前解決方案主要是在傳統行業的一個職位名稱。而產品經理則是互聯網行業的一個稱謂。傳統行業用的都是一些現成的技術架構來解決曾經存在的問題。而互聯網行業的一些業務問題是以前未曾見到過的，這就要用到互聯網的一種思路。而軟件工程裏的模塊化思惟又是解決這種問題的有效利器。

  互聯網行業不少時候都是一種精英思惟，一我的要會不少方面的東西，既要會網絡，又要會編程，還要懂點產品的營銷，相關活動的策劃等等。而傳統行業，人員分工特別精細，每個人的螺絲釘思惟很嚴重。這在新形勢下是很受挑戰的。如何快速學習，快速將新知識，新技術應用到業務場景併產生相應功效。這一點，是傳統行業的人須要思考的。

4，大數據的技術難學嗎？

   實際上，這個問題問了等於白問。任何技術問題的解決都是要經歷一個過程的。不是說你寫一個解決方案，我照着抄寫下來就能夠了。

   在搭建虛擬機環境的過程，就遇到了不少問題。多去思考這些問題的成因，先本身去尋找解決的辦法。有別人的代碼，也要在讀懂的基礎上修改幾個關鍵參數。看是否可以達到相應的效果。多去討論，多去看相關的貼子。多去寫技術總結，或者以教促學，這些辦法都是不少的梳理你的技術思惟的過程。

5，將來五年後，這個行業會怎麼樣？作這份工做會不會沒飯吃？

   實際上，這個問題曾經也糾結過本身很長時間。開始寫代碼後，才慢慢明白。還得出了一個很簡單的結論：與其糾結，不如實幹！有的時候，人擔憂的東西過多，就會讓你在現實的狀況下裹足不前。

   有人說，如今須要Python比較多,Java需求減小了,我要學Python.或者說要去學IOS或Andior.實際上，技術老是在更新換代，你如今學的東西老是會過期，你去看一看曾經的CCIE如今又都在作什麼呢？不要過多的糾結於將來。多去把當下想學的東西弄明白。