你為什么從后端開發(fā)（JAVA/golang）轉(zhuǎn)到大數(shù)據(jù)開發(fā)（Hadoop/Spark）？這個問題有點難回答。作為過路人，試著回答。無論是Java、go還是Hadoop spark，都沒有本質(zhì)的區(qū)別。它

你為什么從后端開發(fā)（JAVA/golang）轉(zhuǎn)到大數(shù)據(jù)開發(fā)（Hadoop/Spark）？

這個問題有點難回答。作為過路人，試著回答。

無論是Java、go還是Hadoop spark，都沒有本質(zhì)的區(qū)別。它們都是針對特定業(yè)務(wù)場景的開發(fā)服務(wù)。

比如Java go主要用于業(yè)務(wù)開發(fā)，比如各種業(yè)務(wù)系統(tǒng)的后臺，各種應(yīng)用或者PC服務(wù)，比如淘寶。要解決的主要矛盾是實現(xiàn)業(yè)務(wù)需求，要提高規(guī)模。矛盾在于如何解決并發(fā)、流量、服務(wù)管理、容量擴展、存儲和災(zāi)難恢復(fù)等問題。

Hadoop spark是為了解決大數(shù)據(jù)問題而產(chǎn)生的，解決問題的場景是圍繞大數(shù)據(jù)的存儲和計算而產(chǎn)生的。當(dāng)業(yè)務(wù)規(guī)模不上來時，數(shù)據(jù)的存儲和計算都不是問題，比如用戶行為的統(tǒng)計、點擊、用戶分析等。這些大數(shù)據(jù)框架根本不需要。通常，一臺機器就可以做到。如果一臺機器可以做到這一點，它當(dāng)然不需要多臺機器分布式。

當(dāng)業(yè)務(wù)規(guī)模擴大時，單臺機器或。即使是多機的，沒有這些大數(shù)據(jù)包，從頭開始構(gòu)建輪子也是不明智和經(jīng)濟的。例如，這家餐館過去常常雇人洗碗。如果餐館生意好一點，可以通過雇傭更多的人來做。經(jīng)過發(fā)展，生意越來越好。研究發(fā)現(xiàn)，直接購買洗碗機或外包給洗碗機公司，效率更高，質(zhì)量更好。我們的生意也一樣。當(dāng)我們擴大規(guī)模時，我們必須將這些Hadoop spark用于大數(shù)據(jù)。又快又好。

說了這么多，基本上是基于業(yè)務(wù)規(guī)模。與其無緣無故地轉(zhuǎn)向，不如有轉(zhuǎn)向的動力。

另一方面，對于個人來說，等待業(yè)務(wù)再次改變有點晚了。當(dāng)技術(shù)出現(xiàn)時，它是對個人技術(shù)洞察力的一次巨大考驗。畢竟，一個人的經(jīng)驗是有限的。選擇一種天花板高、應(yīng)用廣泛的技術(shù)路線是非常重要的。提前學(xué)習(xí)布局。2010年，在Hadoop剛剛興起的時候，如果你對Hadoop數(shù)字很熟悉，也很專業(yè)，比如成為Hadoop的提交者，那么毫無疑問，它一定是業(yè)界的一頭大牛。阿里巴巴、百度和騰訊隨意進入。所以你看，選擇和努力一樣重要。

一個是業(yè)務(wù)需求，另一個是個人技術(shù)見解和高級布局。hadoopspark在相當(dāng)長的一段時間內(nèi)一直是一種需求量很大的技術(shù)。然而，經(jīng)過近10年的發(fā)展，大數(shù)據(jù)如今已經(jīng)遍地開花。例如，弗林克有取代火花的傾向。

總之，我們應(yīng)該向內(nèi)看業(yè)務(wù)需要，向外看行業(yè)需要。

歡迎關(guān)注代碼老王，他已經(jīng)專業(yè)玩代碼30年了。

Spark支持通過GO語言編寫程序嗎？

最新的官方API接口不支持go。