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

本質

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

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

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

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

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

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

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

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

coding老王，專業打代碼三十年。