個人觀點，不喜勿噴。

這個得看個人的職業規劃吧，服務端開發和大資料開發，各有特點，側重點也不一樣，沒有好壞優劣之分，但是服務端開發或多或少得用到一些大資料相關的知識

這個題目有點難答。作為過來人，試著回答下。

本質

無論是java還是go，還是Hadoop spark，並沒有本質區別，它們都是為特定業務場景開發服務的。

比如java go之類的，主要用於業務開發，比如各種業務系統，各種app或者pc服務的後臺，比如淘寶的後臺。主要解決的矛盾是實現業務需求，規模上來後。矛盾就是如何解決併發，流量，服務治理，擴容，儲存，容災這類問題。

而Hadoop spark是解決大資料問題而產生的，它們解決問題的場景是圍繞大資料的儲存，計算而產生的。當業務規模沒有上來的時候，資料儲存和計算都不是問題，比如統計使用者的行為點選等等，使用者分析，根本不需要這些大資料框架，往往單機就能搞定，單機能搞定的，肯定不需要多機分散式了。

當業務規模上來後，單機或者說。即使是多機，不用這些大資料套件，從頭造輪子，很不可取和經濟。好比原來餐館是僱人洗盤子，餐館生意好了些，再僱多幾個人，也能搞定。經過發展，生意越來越好了，發現直接購買洗碗機或者外包給洗碗公司，效率更高質量又好。放在我們的業務上也一樣，規模上來後，就必須用上這些為大資料而生的Hadoop spark了，發現用了又快又好。

說了這麼多，本質上來講，是根據業務規模來轉的。而不是無緣無故轉的，有需求才有轉的動機。

另一個方面，對於個人來說，等待業務需要再來轉，未免有點遲了。在技術出現的時候，非常考驗個人技術洞察力，一個人的經歷畢竟有限。選一門技術天花板高，未來使用廣的技術路線就非常重要了，提前佈局學習。在2010年那會兒，Hadoop剛興起的時候，那時候你如果對Hadoop數字熟悉並專攻，比如成為Hadoop commiter，可以毫無疑問的說，一定是行業大牛了，阿里百度騰訊隨便進了。所以你看，選擇和努力同樣重要。

為什麼轉，一個是業務需要，一個是個人技術洞察力，提前佈局。Hadoop spark在相當長時間內，都是需求很旺的技術了，只不過，經過近10年的發展，現在大資料這塊，基本是百花齊放了。比如flink，有取代spark的趨勢了。

總結下，向內看業務需要，向外看行業需要。