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

本質(zhì)

無論是java還是go，還是Hadoopspark，并沒有本質(zhì)區(qū)別，它們都是為特定業(yè)務(wù)場景開發(fā)服務(wù)的。

比如javago之類的，主要用于業(yè)務(wù)開發(fā)，比如各種業(yè)務(wù)系統(tǒng)，各種app或者pc服務(wù)的后臺，比如淘寶的后臺。主要解決的矛盾是實現(xiàn)業(yè)務(wù)需求，規(guī)模上來后。矛盾就是如何解決并發(fā)，流量，服務(wù)治理，擴(kuò)容，存儲，容災(zāi)這類問題。

而Hadoopspark是解決大數(shù)據(jù)問題而產(chǎn)生的，它們解決問題的場景是圍繞大數(shù)據(jù)的存儲，計算而產(chǎn)生的。當(dāng)業(yè)務(wù)規(guī)模沒有上來的時候，數(shù)據(jù)存儲和計算都不是問題，比如統(tǒng)計用戶的行為點擊等等，用戶分析，根本不需要這些大數(shù)據(jù)框架，往往單機(jī)就能搞定，單機(jī)能搞定的，肯定不需要多機(jī)分布式了。

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

說了這么多，本質(zhì)上來講，是根據(jù)業(yè)務(wù)規(guī)模來轉(zhuǎn)的。而不是無緣無故轉(zhuǎn)的，有需求才有轉(zhuǎn)的動機(jī)。

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

為什么轉(zhuǎn)，一個是業(yè)務(wù)需要，一個是個人技術(shù)洞察力，提前布局。Hadoopspark在相當(dāng)長時間內(nèi)，都是需求很旺的技術(shù)了，只不過，經(jīng)過近10年的發(fā)展，現(xiàn)在大數(shù)據(jù)這塊，基本是百花齊放了。比如flink，有取代spark的趨勢了。

總結(jié)下，向內(nèi)看業(yè)務(wù)需要，向外看行業(yè)需要。

coding老王，專業(yè)打代碼三十年。