為什麼在中國搞不出 Spark 和 Hadoop 這種東西？

01-02

先問是不是，再問為什麼，不要耍流氓！
國內hadoop類似產品不止一個吧，估計還勝過現在的hadoop，現在hadoop可不是啥核心科技
----------------------------------
我是一名CS學生，我想聽聽對題目問題的看法。我很好奇是哪些本質的東西決定了在美國搞出了這些東西，在中國就沒有出現。我能想到的原因就是：我覺得國內的互聯網環境更關心怎麼賺錢怎麼快速迭代產品，而對於技術創新投入不夠。

上周去深圳參加了ECUG的十周年盛會，工程師的盛會是沒有紅毯沒有香檳的，只有純凈水和小麵包，然後就是幾百人坐下來聽技術大牛們做分享。

ECUG是個民間組織，關注的是雲計算前沿技術的經驗分享和分散式開發、運維的最佳實踐。

Home - 實效雲計算用戶組(ECUG)

每年會選在一個地方舉行，今年是在深圳舉辦，贊助方還是七牛雲存儲。會議內容就是請各個領域的專家做技術分享。

兩天的時間裡我聽了十多個演講，其中有兩個給我留下深刻印象，一個是劉奇老師的TiDB，一個是Luke Han老師的Apache Kylin。

TiDB是分散式資料庫，Kylin是分散式分析引擎，都是屬於大數據云計算領域的基礎設施項目。

這兩個項目有很多共同點：

他們都是中國人主導的項目，由中國人發起，設計，運營，並且貢獻了大多數代碼，

他們都是開源的全球化項目，代碼都是開放的，有中英文文檔，項目的用戶和參與者來自世界各個國家。

他們都是由商業化的公司在運作的項目

TiDB是 PingCAP

Kylin是Kyligence Home - Kyligence Inc.，同時它還是Apache基金會的項目Apache Kylin | Home

這不是某幾個個人的業餘作品，是一群對技術有追求的人的事業。

商業化的運作保證了項目的資金和人員的穩定性，收入主要來自捐贈和技術諮詢服務。

我舉這兩個例子是想說明，有些事情在起變化。過去二十年我所參與了解的中國技術圈，基本都是應用開發為主，基礎技術都是來自國外，大多是美國，普通工程師是面向SDK API編程，高手也就是讀懂別人的項目做些局部優化和定製，很少有自己創新的東西，很長時間中國開源屆也就靠LVS等項目撐撐面子。

但是最近幾年不一樣了，國人主導的開源項目真實如雨後春筍般出現。尤其在一些比較熱門前沿的領域，比如前端開發，Vue，Electron等。

所謂厚積薄發，美國人引領全球IT技術那是他們從二戰就開始積累的結果，而那時候中國人還在戰亂和饑荒裡面掙扎。經過30多年的經濟建設，終於產生了那麼一批人，他們有足夠深厚的技術積累，有豐富的項目經驗，有廣闊的技術視野，並且有一定的經濟基礎，可以投入到他們熱愛的純技術領域，可以幾年不求短期回報地去打磨技術。

查下歷史可以看到，Hadoop立項是2006年，理論基礎來自2003年google的論文，而google能發布這樣的理論想必也經歷了多年的研究，這是紮實的理論和多年工程積累的結果。

中國如果想有類似的項目，10年的積累是必不可少的。

相信還有很多類似的項目在發展在成長，過去幾年國內開源技術領域創新有個小爆發，原因我覺得就是70後到了四十不惑，80後到了三十而立，而部分90後已經吃喝不愁了，改革開放後受教育的幾代人成長起來了。而這只是剛剛開始，後面的發展可能會超乎大家的想像，等到90後都四十不惑的時候，中國成為全球技術創新的發源地也不是不可能的。

如果你年輕，有想法，對技術有追求，可以去參與這樣的項目，向前輩大牛學習，開拓視野提升技術能力。PingCap 和 Kylin都在招人，也招實習生。

一句話總結是：那個年代中國高校和公司確實搞不出hadoop/spark. 現在估計問題不大，但已經沒必要了，因為目前大家關注別的東西，例如AI。

先說下歷史。

04年MapReduce（MR）論文橫空出世，那時候MR已經在G內部用了一段時間。論文的內容基本上是：瞧，我做了忒nb的東西，說幾點讓你們瞻仰下。學術界和工業界一片嘩然，太big data了，只能點贊。

隨後MR團隊的人出走yahoo，用java重寫了一個叫hadoop的東西。雖然一開始不那麼好用，但大家也沒別的選擇。所以各個公司紛紛跳坑，10年前後每個公司都樂此不疲的講我們有多大多大的hadoop集群，每天處理多少PB的數據。

10年spark論文出來。之前matei已經折騰了好一陣子（既在UCB也在facebook（還是twitter？）），論文之前也被拒了好幾次，理由是「不就是in-memory hadoop？貢獻不大啊」

但接下來amplab做了個很明智的決定，僱傭全職碼農提升spark代碼質量，大量的開meetup來培訓用戶，目標很明確，就是要挖走現有hadoop用戶。

所以spark在大數據最火的那幾年迅速積攢了大量用戶。

技術上為什麼國內那個年代不行

04年到10年，整個國內系統方向實力是比較差的。例如OSDI/SOSP上論文基本靠MSRA撐著，但MSRA那種用大量實習生來堆工作量的做法明顯不適合其他公司和高校。

一個系統最難的是在設計上。這個完全不是科學，純粹是藝術和哲學。好的架構和介面設計是成功的一半，但那個年代學術界系統方向不興旺，間接的導致了公司對通用系統架構不熱衷。

我在國內公司（百度，msra）和美國公司（G，amazon）都呆過，整體而言不覺得國內程序員比美國弱，但架構師這種需要長時間的培養的關鍵人物國內還是缺的。

後期度廠朝著向G學習的風氣，開始大量投人造輪子。那段時間我剛好在度廠的商務搜索部門，也圍觀了一些事情。我感覺不是技術上有問題，而是非技術上的原因。

非技術上原因

非技術上最重要的是生態圈，包括活躍的開發者，大量的用戶，文檔，有問題可以通過網路獲得及時幫助。

試想你是一個用戶，你花一個小時寫個map寫個reduce然後提交，雖然處理幾十TB的數據需要好幾個小時，但鮮有出錯，出錯了搜下error估計可以得到個答案。但這個時候有個人說，來用下我們新開發的系統，至少比hadoop快三倍，但你需要幫我們踩踩坑，有問題告訴我們，我們盡量解決。所以一是讓機器跑10個小時，二是讓你自己折騰10個小時，那麼明顯絕大部分人會選一。

所以當年即使百度造的輪子更塊更好，但公司內部就那麼兩大用戶（搜索和廣告）和幾十個小用戶，那麼獲得前期嘗鮮用戶的困難度是很大的。而且那個時間公司不斷的買新機器，換更快的，所以即使現在不能跑的大任務，等幾天就好了。

生態圈的建設不是一天兩天的事情，通常需要好幾年的持續投入。首先國內高校很難做這個事情，需要大量人力和資金。而公司相對來說產品更加優先，那個時期，國內公司基本都是試圖在產品上超越美國公司，但並不重視系統架構。

再軟軟的舉個mxnet的例子。mx雖然看上去項目就是開發不到兩年，但好幾年前就開始了相關項目，例如cxxnet和minerva，的開發。用戶也是慢慢的積累起來，聽大家的反饋，利用有限的人力做呼聲最好的特性。在這一點上，需要的是時間和耐心。

現在國內有能力做一流的系統

國內這幾年技術發展挺迅猛。例如mxnet的用戶群大部分是來自國內。我個人感覺國內用戶更願意嘗試新東西，做事情也更加迅速。雖然說mxnet很多開發者人都不在國內，不過我覺得美國提供的東西更多是自由的時間可以做自己想做的事情，而不是這邊有多少大牛可以請教有多少技術可以直接用。

同時大家也看到了生態圈的紅利，例如hadoop和android，所以很多公司都大力支持做自己的平台。雖然不是那麼普遍，但我接觸也有好幾家年輕公司有這個計划了。

當正如樓上所說的，hadoop/spark已經在那裡了，重新招個輪子成功的概率太少，所以大家應該把目光放在別的地方。

但反過來說，國內做生態圈的一個劣勢是在語言上。例如我們已經看見用中文提issue，雖然我們是能看中文，但英文還是通用語言，用中文導致其他人覺得這個生態區太封閉。也有用非常不禮貌的英文，通常是中文的直譯，用中文說沒問題，但讀英語覺得特別彆扭。

我也聽到傳言說美國幾大主流開源社區對接受純由在中國的開發者開發的軟體還是有偏見，文化和溝通是主要的原因。

目前我們也正在讓mxnet加入apache software foundation，去體驗下主流開源社區的開發，過一陣子可以分享我們經驗。

PS. 看見大家都在說我們有XXX比hadoop快。其實對於開源軟體來說，性能重要，倒不是最關鍵，我認為設計理念，用戶多少，影響面更重要。類似Hadoop/spark的輪子各大公司也是一把一把，哪個不比他們快個好幾倍？但是不開源的話其實也沒得什麼比，即使開源了沒健康社區也是很難活長久。

現在其實沒必要再提這個問題了，分散式過了這麼多年，早已經不再是簡單的Hadoop的事情了。國內各家大公司和一些專門做這個創業公司都有更好的解決方案。

其實如果問的是七八年前中國為什麼沒有搞出來Hadoop的話，那還是一個很值得思索的問題。

Google的Map/Reduce論文發表於2004年。2007年作為其開源版本的Hadoop 初版發布。

那時候Hadoop是真的一線技術，它的發布可以說正式揭開了現在（隨便去一個澡堂都能聽到有人聊的）「大數據」時代的序幕。

那時候Baidu非常認真的要自己搞一套分散式系統出來。可能你現在不信，但是那會百度還是非常有技術追求的，還在非常猛的正面剛Google。那時候Hadoop剛開源，只有Java版本，大規模集群和大吞吐量的支持也沒有現在這麼的好。而且剛release的開源軟體拿在線上用就純粹是折磨oncall工程師。

於是07年的時候，Baidu決定自己上，從底層的分散式系統，到頂層的Map/Reduce API，全自己造。什麼Java Python，那都不efficient，直接上純C，C++都不用的。

公司的投入非常大，從MSRA挖來了一個非常有名的做分散式的學者帶隊，從各個技術部門（那會主要是PS和ECOM）抽調了主力技術骨幹（都是表現非常好的T5，T6）成立了專門的項目組。當時全百度的開發可能也就兩百三百人，這個項目一下就從裡面徵調了幾十個有經驗的主力出來，可想而知這個力度有多大。項目組從leader到一線開發都非常有激情，畢竟在做世界領先的開創性的技術，整個項目組狂加班。當時幾乎普天12層西側每天晚上都是亮著的。

過了一兩年後基本都做出來了，性能跟Hadoop比也差不多，在我看來真心是非常了不起，非常值得敬佩。但是恐怕除了那時候在Baidu的老人，現在已經沒幾個人還知道Pyramid了。為什麼呢？

Baidu的另一撥人拿Hadoop的代碼來包裝了一下，用C重寫了API，然後陸續用C重寫了一些性能模塊，最後在跟Pyramid的競爭中以微弱優勢獲勝。一方面是性能上的穩定性可能好一些，畢竟重新造輪子需要時間更長。另一方面Hadoop的部門更大，所以用的人更多。最後可能也是最重要的，高層並不覺得自己原創一個跟拿開源的抄一個出來有什麼優勢，即使兩者目前性能差不多，不如用開源的，於是就。。。後來Pyramid那些精英工程師們就基本都走了。

所以說其實即使是放在當年剛剛有Hadoop的時候，那套東西也並不是那麼的難。國內能做出來的人還是有不少的。後來我在MSRA的組的幾個人就拿C++做了一套內部使用的出來。

問題其實是，公司有沒有對這種沒有短期效益，但是長期是一個公司核心競爭力的技術方向的持續投入的決心。

在雲計算越來越重要的今天，現在回過頭看看阿里雲，再看看百度雲，只能是一聲嘆息。

寫個系統相對容易，但培育一個開源社區非常難，需要花很多的精力，最終還要很多運氣的成份。

Hadoop和Spark的成功路線並不相同，但背後都有人在推廣社區方面付出的艱苦而曠日持久的努力。

我前些年一直在Facebook的大規模數據存儲組，講一講我可以接觸到的感受。

Hadoop是Yahoo搞出來的，是當時大廠做出的類似系統中唯一一個開源的，應該說這是很有優勢的。在大公司大規模試驗過，是其他公司選擇系統中有很大的優勢。但要培養成氣候，他們做了很多工作，比如去各個公司演講推廣，去矽谷的各種技術交流活動，很早就開辦各種用戶組會議，讓用戶介紹他們的經驗等等。另外他們和學術界的合作也在很早期就開始開展。大學的很多研究論文都在比較Hadoop和他們的系統的性能，可見他們在背後做了多少工作。 Hadoop另一個基於是正好一個後來成功的大數據推廣的公司Cloudera在那個時候成立了，並順理成章的選擇了在當時剛剛嶄露頭角還很稚嫩的Hadoop，於是Yahoo和Cloudera構成了這個社區的兩個推廣者，也是競爭者。這使得這個項目有了很好的先發優勢，在未來挑戰者面前搶得了很大的先機。講我了解的Facebook的事情，在Yahoo開源大概幾個月的時候，當時Facebook有個跳槽自Yahoo的工程師，將Hadoop系統帶到了Facebook。那個時候Facebook已經是個在矽谷很響亮的名字，但遠沒有幾天的技術實力。Hadoop那些人看到非常高興，為了推廣，很樂意給這些用戶committer許可權，以鼓勵使用。可見他們開源方面付出的努力。值得一提的是，這樣的開源努力，在多數的公司都是無法得到全力支持的。對於所有員工來說，他們的工作應該是為了公司創造價值，而不是做公益。所以很多時候這些開源項目的推廣者也需要搞定很多公司內部的問題，更加困難。

然後說Spark。我的最初的印象來自於2010-2011年時候Berkeley研究組和Facebook數據組的交流。那個時候伯克利整個研究組會開車一個多小時來到Facebook，做兩三個小時的交流。在我印象中，他們至少來過兩次。在每次交流中都試圖推廣了Spark，那時候還基本是個研究項目。即便這樣的介紹，我們也沒有引入。你可以想像他們到其他多少類似的公司做了介紹，才換來零星的幾個試用者。你可以想像他們早期對推廣他們的系統堅持不懈花了多少時間介紹他們的工作。很多人看到Spark今天的風光，沒有看到他們早期多少年辛苦廣種薄收的耕耘。

很多知友知道我是RocksDB開發組的，在過去的三年多時間裡我們一直在努力推進我們的開源項目，我已經深深的感受到了培育一個開源社區的艱辛。我們沿著當年Hadoop開源的經驗不斷辛苦努力，跑各個公司，辦用戶組活動，找Percona等公司支持，和主要用戶建立聯繫，參加學術會議，和各大學交流……很多時候挺累的。有很多人會覺得看你們這些人成天上躥下跳，有人會覺得肯定是公司支持你們專門干這個的，也有人覺得肯定是你們個人喜歡利用這個出風頭。其實公司對開源的支持大概僅限於不超過20%的精力，最終對一個項目的考評還是要看對公司內部的貢獻。有時候我的確是很喜歡利用交流我們的項目的機會認識更多的工程師，但同時也有很多時候我對交流的對象並不感興趣，也還是花時間推進。我們這樣成長中的專而精的開源項目推廣起來尚且如此，Hadoop、Spark這樣覆蓋面很廣的項目，培育社區要花的心血就可想而知了。

所以簡單的說，Hadoop、Spark的成功，技術成功只是基礎，非技術的不懈努力才是關鍵。

更新：提了這麼多次輪子換來輪子哥一個贊，計劃通。

------------------------

我的看法是這個是個厚積薄發的事情。就hadoop和spark這樣系統類平台類的東西，比很多其他領域更需要積累。國內相關產業起步晚了不少年，因此人和環境都暫時弱於美帝。並不是說國內做不出來，應該說的是出於種種原因，可能國內只有少數公司有造大輪子的能力，並且他們未必選擇開源，你看不到影響。而高校偏弱，要做到AMPLab造Spark那樣，還需要時間提升。

首先要說的是，Hadoop本身並不直接是一個創新產物。它是基於Google的系列論文照著擼的。而Spark背後不得不說有微軟Dryad和Google FlumeJava的影子。甚至Dryad，MapReduce，GFS本身，又怎麼可能是拍腦袋想出來的？系統軟體領域，是需要深厚積累的。這種積累是有一群人在做相關前沿科研；也是有Google這樣聚集了無數最優秀大腦，擁有獨步天下的規模和場景，在諸多領域敢讓天下一先的公司；甚至是在業內相當數量如我這般只是湊合的碼農，但碰巧搞過相關的事情。只有這個積累深了，氣氛到了，才會出現真的創新，這些創新也往往不是開天闢地，而是在既有成果上的不斷改良，而這種改良可能恰恰觸及了爆點。

你要創業或者起個野心勃勃的開源項目，試想如果你在灣區，你在F1論文發表的第二天，就在朋友聚會上聽Google工作的隔壁鄰居跟你討論，F1/Spanner忒牛了，我們組用了好幾年了，用完牙都不疼了；也許我們可以複製一套的讓大家都用得上，我們要Make America Great Again！於是你們在圈子裡招兵買馬：你發小王二麻子是MySQL組的Principal Engineer，而他老婆的小姨的二叔是Cassandra的核心工程師之一。總之湊齊這麼一個班子，你發現似乎成事的可能性大多了。

以上情形暫時很難在國內發生。

不開玩笑說，隨便翻一下，Hive論文的一作在Oracle做了6年；Impala的主架構來自F1/Spanner團隊；Tez團隊有微軟Dryad的工程師坐鎮。至於其他各種灣區平台類創業公司里的相關領域直接對口的行業老鳥，不知凡幾。而這些團隊本身又讓一批新人變老鳥，他們將接過造輪子的火炬，生生不息。

因為老鳥多，因此擼起來不太難。我見過中型公司深度微軟用戶因為MS砍了Dryad憤而招人自己仿製的；我在美國讀書時也有同學是資料庫行業多年老鳥，博士轉分散式，兩者結合平台創業做的風生水起；哪怕當時我所在的創業公司其實也自己悶了一套Hadoop（僅僅為了自己用，做出來性能也的確比社區快不少），因為有老手帶隊做架構：MapReduce和調度系統的架構師是原IBM的分散式系統Tech Lead，做的東西現在是BigInsight一部分，而SQL部分是Google的一個做編譯器和分散式計算的Staff Eng和Informatica的Principal打的基礎。

美帝架構師們二十年前在折騰資料庫引擎，分散式計算的時候，我們的程序員大多才開始寫VB6，更別提當年寫過VB6的人都不如美帝多。我們的老鳥程序員並不是不聰明，只是由於行業起步晚太多，能撐場子的人丁稀少。比比灣區的生態，國內造輪子的圈子太小了。因此造輪子變得更加困難。

國內並非沒有大神和老鳥，只是數量比起灣區要少很多。看看BAT不惜血本從美帝搬人回國，其實也許灣區一個初創公司只需要情懷和不知道啥時候能兌現的期權就能勾引到他們。這點上說，造輪子的活在國內成本老高了。並不是說不可能，只是會難不少。

再說學界，資料庫祖師爺級大牛Michael Stonebraker（說通俗的話，他是Vertica，PostgreSQL背後的人）和他的小夥伴們寫了本小紅書嘲諷大數據行業把他們研究幾十年的東西拿來包裝，笑稱自己原來研究了大數據好些年了。其實所謂大數據很多工程上的東西的確是相關領域研究早已成熟多年的東西，並不是一夜之間被「發明」出來的。因此Spark團隊出自伯克利這樣的CS牛校非常正常（而且AMPLab的總監其實是Stonebraker的徒孫）。除去Berkeley，北美很多學校都在不同方向有很長期的積累。拋開積累不談，偏工程類的科研領域，很多時候是非常依賴業界互動的，甚至有些行業業界領先於學校科研。而國內計算機產業遠遠晚於美帝，順帶也會影響科研的高度。Spark能大面積推開，Mesos能直接在Twitter等大廠紮根，除了Berkeley的超強光環加成，也是因為這樣的科研團隊本就不封閉，並和業界的聯繫非常緊密。這些用戶都為項目帶來莫大的助推，也讓實驗室的聲名大噪。說來說去，UC Berkeley的AMPLab造Spark，Mesos，Alluxio等，並且成功推廣，並不是很令人驚訝的事情，國內高校一時半會沒法比，甚至世界範圍能匹敵的也很少。

這樣也帶來一個惡性循環，就是造輪子的生意，在國內很難做，多數公司並不會選擇這麼玩，而高校很難懟個真能用的東西出來，太難了。小輪子還好，複雜的平台和框架沒有熟練工坐鎮，要走太多彎路。因此並不是一個很划算的投資。所以國內也缺少這樣的氛圍，搞這個的就更稀少了，也許有人擼過輪子，但一轉眼發現沒那麼多需求，只好默默轉行去做別的了。所以造輪子的人沒法持續造輪子，不斷減少；想造輪子的公司找不到人；投資人找不到能投的輪子公司；造輪子的人就進一步轉行流失。惡性循環。

再說和開源社區的對接。開源也是情懷，國內公司普遍情懷不足。據我所知國內公司原本大多和社區並沒有什麼往來。也並不會經營和造勢營建社區。因為這個直觀上說並不給公司帶來利益，而宣傳效應又並不是那麼直接和明顯，外帶還需要特別花精力整理維護（否則開源還不如不開）。

其實想想如果當時百度自己的MapReduce能開源，好好經營社區，現在未必不能成氣候。而其他幾個大廠，哪家沒有一些黑科技（比如我後來呆的網易研究院有自己的分散式存儲／資料庫等，網易有道也自己擼過Hadoop），如果他們換個選擇，也許有不同結果。參與開源社區，共建社區再到影響社區甚至自己就是社區，這也是要一步一步來的。好在現在漸漸大家意識到了，情況略有改觀。

不說大廠，單說創業的話，開源和商業並不抵觸，但是也需要探索一些成熟的商業模式來變現。如果業界有相當成熟的經驗來運作開源商業化，這類廠商也會更多起來。當然這個其實國內國外都一樣，只是我感覺灣區的投資人對技術因素更為推崇，有更高的容忍度，純技術類的創業更有機會拿到投資。

說了這麼多廢話，如果你還是CS學生，那我想說稍稍等等就好。中國現在大概是除了美帝之外IT行業最發達的地方了。已經越來越多碼農投身造輪子的事業了，我們這些人，如若能持續奮鬥在壘代碼第一線，保持著造輪子的心，三五年後（其實也許更短），諸位如果想要投資輪子，你就能很方便找到一群老鳥扯大旗開工了。而你也會發現。中國公司在開源社區的參與度和話語權越來越大，更方便擴大影響帶來商業上成功。

總之，情況會變好。我們可以選的是，為造輪子的浪漫事業添一塊磚。

PS：所以當我看到PingCAP這樣的公司，我基本會有種敬仰感動的心情並投一分簡歷然後爭取滾去幫他們壘代碼。

利益相關，接了PingCAP Offer一個月後去上班。

不知道題主在關注Hadoop和Spark時有沒有關注過同性質的其它開源或閉源項目。

既然把Hadoop和Spark放在一起說，就假定題主說的Hadoop是指狹義的Hadoop的MapReduce部分吧。

國內外做Hadoop-clone的項目恐怕還不少，題主或許只是沒聽說或沒關注過而已。

國內就舉一例：阿里雲做的「飛天」項目起初可以說是想用C++來重寫一個跟Hadoop類似的計算框架，後來幾經磨難總算上了線，現在在阿里在各種因素的推動下擠掉了Hadoop成為阿里內統一的分散式計算平台的底層。

然後舉個日本的例子。題主或許沒有關注過，楽天也自己研發過分散式計算框架，而且還是用Ruby實現的。項目名是ROMA/Fairy，分別對應Google原版概念中的GFS/MapReduce，分別負責存儲和計算。

然後更實用的，微軟自己做的Cosmos前面已經有回答提到了，題主也可以關注一下。

我覺得並沒有什麼特別「本質」的東西導致美國發明了原版MapReduce和後來克隆出來的Hadoop。

原版MapReduce感覺是天時地利人和——在那個時間點Google有足夠的數據量、有足夠的業務需求、有足夠高端的人才，眾多因素結合起來讓它先有了實用的MapReduce型分散式計算平台。

硬要說，最初的Hadoop也是從原版MapReduce抄來的而且一開始還抄得很糟糕。

後來大家也漸漸的都開始遇到類似的需求的，有能力有野心有耐心的就自己再造一次輪子（例如微軟、阿里雲、楽天），不然就想辦法把開源的改造/配置成適合自己環境使用。

1.沒有錢，沒有錢，沒有錢，那些說技術上簡單的都是沒有搞過系統的，阿里搞的飛天花了多少錢有人知道么，一年不低於十億，你為什麼要花這麼多錢造個hadoop

2.複雜度很高，計算機科學本質上就是複雜度的事情，一方面是技術上，一方面是組織上，技術這個東西，單獨看一個點都簡單，但是如果你要組合成一個系統，隨著技術棧的深入和規模化的深入，最後會變成細節的泥潭，最典型的例子就是那麼多人噴的通用資料庫，看看現在oracle的開發進展，代碼規模多大，編譯一次多長時間，bug是不是會不收斂，網上一堆牛，要約寫編譯器的那些牛，但你要讓他牽頭搞個通用資料庫，一樣死的很難看

3.機會，如果你要平地起高樓寫一個hadoop, 最好是在他第一個版本發布的時候，整個系統沒有那麼複雜，spark就是這樣，它完全不理會hadoop的資源管理，只關注計算框架，內存管理和failover。如果你要平地寫個hadoop2.0，你基本上怎麼追都追不上了，當然，這個實際上也就是飛天的雄心壯志，可是你們沒有看到飛天追了七年追的那麼幸苦，而且你要是一定講飛天贏過hadoop,現在還太早，機會只有一成都不到，很簡單，飛天搞的半拉子的時候，投進去的錢都是沉沒成本，但是飛天穩定運行了，阿里沒有再投技術的意願了，現在想的更多的是飛天上的業務了，當然還有一個原因，就是飛天的人也不知道下一步要往哪走，spark抄完了還能抄誰呢，阿里不是改變技術邊界的公司。而且即便知道要動什麼，也不敢下手呀，比如sql解析要改，文件系統要該，分散式索引要加，元數據管理要重構，事務系統要加上，這些沒什麼人敢動，我曾經跟一個同事吃法的時候，他跟我說要是我能把索引做起來，就算給我個p9我都嫌少

4.spark不簡單，也不是你隨便想想能想出來的，用內存只是一種感覺，感覺有時候講都講不清，更不用說做了，計算機歷史上有著超級多的事後看起來極其簡單，但是當上帝之手揭開面紗之前，你就是想不到的事情，比如神經網路的反向傳播演算法，比如kmp演算法，比如r樹。spark那個小組在數據處理方面有很多年的積澱，所以他們瞄準幾個關鍵問題，第一是框架，第二是cache,第三是failover,這三個事情顯然是想了很久很久最後才確定了的，然後解決方案也漂亮，所以他可以寫很少的代碼，做很漂亮的事情，如果你覺得spark很簡單，那你能告訴我spark後面會是什麼系統。

5大學，總得來說，中國的大學在計算機方面離老美還是有點距離，當然，工業屆也不能倖免，那些寫著爛代碼的碼農用不著天天嘲笑大學裡不會寫code的大學生，你會的，人家花一個月也能會，我知道知乎上有大神，但是如果你看整個面，就知道大部分碼農其實寫code寫的很爛，只是人力而已，所以這裡呼應前面說的組織的複雜度，這不是說碼農沒有追求獨立思考的想法，而是他們的工作不需要獨立思考。大學呢，大學的工作沒有做系統的需求呀，今天中國的好大學在計算機科學某個點上的工作並不差，但是整個系統這種事情，原則上跟大學的利益是背馳的，大學也許能有人會去想明白spark後面還有什麼缺陷，但他發篇論文就算了

其實這些東西很多成分都是中國人搞的，就算是比spark早了10年的微軟的一摸一樣的只給自己用的cosmos，裡面也有大量的中國人在做，很多演算法也是中國人想出來發了論文的。你要問的是，為什麼中國人在中國的公司就搞不出這樣的東西，這才是正確的提問方法。

當然這個問題很簡單——你搞出來了就能當老闆嗎？

這種系統每個大公司都有一堆，只是沒有開源，而本問題下一堆人回答的時候各種冷嘲熱諷國內大公司水平不行，做不出來這樣的系統，諷刺說國內抄都抄不出來的時候，你們真的了解具體的情況嗎？

百度一開始是根據Google MapReduce論文搞了一套自主研發的，自認為優於hadoop的系統，但最終被另一個推廣hadoop的組擊敗，擊敗的原因主要原因非技術因素：

第一個原因是大部分人寧願選用開源的，一、在網上更容易找到資料二、這樣更就算跳槽也比使用內部系統更有資本。

第二個原因是推廣hadoop的組更可以專註於解決用戶遇到的問題，而自研的系統則還需要抽出一大部分人力進行研發。

於是，hadoop在廠內擊敗了自研系統，但就我所遇到的當時處在hadoop組，作為勝利者的一方的人，說起成功的原因時，也從來沒有提過技術因素是一個原因。

百度的hadoop是用的社區最初的0.1.0還是0.2.0版本來著，當時是有一定原因的，hadoop當時也特別不成熟，在百度這麼大的數據量上，hadoop各種抗不住，於是百度內部對hadoop框架做了各種改進，但當時大家認為反饋回社區一比較浪費時間，二對公司沒太大收益，於是公司hadoop與開源hadoop差別越來越大，基本上就完全不是同一套系統了，甚至有用戶吐槽我們，說我們除了名字和hadoop一樣，沒什麼一樣了。

前期與社區分開確實有許多好處，目前卻已經帶來了許多沉重的代價。

百度新MRShuffle機制dce-shuffle，向量計算引擎dvce，流式計算的dstream，tm，parameter server架構機器學慣用的elf等一堆系統，這叫國內沒有？

(以上系統名稱來自於公開可檢索的信息，未涉密:http://tech.ifeng.com/a/20141218/40910504_0.shtml)

不止百度，基本上大公司都有類似的東西，阿里的飛天，盤古，雲梯，騰訊的颱風（據說已經死掉了），只不過都不開源…

也許問題改成為什麼國內公司沒有開源這樣的系統更合適。

嗯，MR論文發表後，按照MR論文加自己小創新做出來類似MR的系統確實沒有提出MR這種創造性工作牛逼，可這裡討論的畢竟只是做出hadoop這類的系統，要知道hadoop也是照著MR論文「抄」出來的。

總是有人分不清楚搞不出和沒搞出的區別。

所以問題修改一下為什麼中國沒搞出來這倆東西，是不是就客觀和簡單多了。

當年的Google有錢、有需求、有人才，沒搞出才是奇怪的事情吧。

你算一算牛逼人物幾個是美國人？

圖靈，馮諾依曼，包括後來的一系列，美國人不算多，只不過他們最終都會去美國。

美國的環境待遇都不能算很好，為啥這些人去美國搞事業？

因為別國更爛

搞過，只是不開源而已。企業核心基礎設施，你見過哪些企業會開源？hadoop無非是按照mapreduce的論文做的一個開源實現，而mapreduce一樣沒有開源。再者此類系統與公司的業務關係緊密，真開源出來，其他人也很難用的上。能用的上的大多是業務類似的競爭對手。

還是那句老話：先問是不是，再問為什麼。

當前全時間最熱門的deep learning框架之一，大名鼎鼎的mxnet，核心成員基本都是中國人：Members of DMLC

其實中國人早就逐漸佔領了CS的各種領域，可惜國內的媒體只知道報道花邊八卦和政府醜聞來博取眼球。所以我們應該少看點娛樂新聞，多看paper。

Hadoop和Spark不是什麼高明的東西，只是人家搞的時候，我國在忙著抄人家的開源資料庫來搞國產資料庫呢。不是我們不創新，實在是抄襲工作量太大，忙不過來啊。

。

只是時間的問題，中國經濟和商業還不夠成熟，如果充分競爭，以後這些都會有的。所以，還是先多賺點錢。

別著急，新技術來自於產業前沿，隨著中國互聯網的不斷發展，到最後發現遇到問題沒有可參考的對象時，新技術自然在中國誕生。

經驗夠了年頭夠了的高手都跑去當官了，從此封鍵盤不再寫代碼，你說怎麼做這些東西。。。

首先，開源是不分國界的，論文是不分國界的。任何一個國家出現了某個好用的開源項目，或者牛逼的論文，都是全人類的寶貴財富。當然，通過英語進行社區交流和維護的項目以及英語論文更寶貴一些，畢竟是通用語言。

其次，代碼可以不創新，別人做一個你做個類似的，但論文肯定要創新。

先說代碼。

谷歌做那幾個系統的時候，國內公司的能力和財力確實是不足的，畢竟國內互聯網的發展本來就比美國晚，即使那時候有同樣多的用戶規模也因為經濟水平等原因沒那麼多收入。但等論文出來已經比開始做這個晚了不少時間，等hadoop出來又過了一段時間，嚴格來說那個時候國內的技術能力就算不如美國的公司，照著論文擼個能用的也是可以的（比如有道作為搜索公司也對著論文造輪子，據說沒用hadoop的原因是寫代碼時還沒有hadoop，也可能是hadoop還不成熟，不過這個不重要）。問題是既然已經有了hadoop，對很多公司來說沒必要自己造輪子。對於不滿足於hadoop而選擇自己造輪子的公司來說，在某些公司內比較看中的功能上比開源的強幾乎是肯定的，但又沒公開，所以外面也不知道，給很多人感覺「做不出來」也算正常。

hadoop如此，linux其實也如此。既然有開源的操作系統，一味強調自主知識產權的操作系統意義不能說完全沒有，但也不像想像中的那麼大。

所以看一個東西國內有沒有做出來要看歷史的行程。這個東西以開源的形式出現在地球的時候，無論是哪個國家的，都意味著其他國家做出同樣的東西的概率下降了，因為只要足夠好，那其他人用不著再搞一個…如果第一個開源的在設計上就不能滿足大多數人的需求（可能是權衡利弊的取捨不一樣，可能單純是設計得不夠好），或者這個開源行為商業化利益太重（社區不夠中立），那自然會有下一個，也一樣無所謂哪個國家，依然是人類的寶貴財富。

工程說完了，接下來是設計。照著論文寫代碼比寫論文本身容易很多倍，國內公司寫代碼的能力和對應的業務需求可能將近十年前開始已經追近美國了，到2017已經不比美帝差多少了（但我還不敢說趕上，需要業界大佬親自說才有說服力），但系統設計能力可能依然有差距，這體現在論文或者完全原創的新系統上。但有差距不代表沒機會，只能說是新出現的比如5個方向中有1個是天朝最先搞出來或者最牛逼而剩下是美帝。但有一兩個那就是從0到1了。差距也一樣在縮小。

做事情的能力在逐步追近，這就意味著今後新出現的方向會有更多中國的團隊主導的開源項目出現，以前就有的，天朝公司沒必要再摸一邊石頭過河。所以要比也比新東西，比如深度計算框架啊什麼的。

當然，除了做事情的能力外，還需要吹牛逼的能力。天朝在互聯網產品營銷那塊吹牛逼的能力是不比美帝差的，但純技術這塊吹牛逼的能力還確實有待提高。美帝人民搞開源推廣啊聚會啊各種con啊那是有豐富經驗的，國內這幾年剛剛開始。這體現在搞一個更好的技術出來可能推廣不過一個不那麼好的技術，這個需要碼農和其他工種一起努力。。。

只是說Hadoop和Spark這種分散式計算框架，據我所見所聞，是有的，並且少量國家所有的有大量計算的研究機構及大部分大型涉及大量計算的企業都有。不過確實都沒有開源。

前者所有的框架一般比較陳舊。我所見的一套出在Hadoop之前，其實並不太成熟。在Hadoop出現之後有大量「借鑒」其設計（不過還是有諸多實現是針對其設備所做設計的，最終效能其實比Hadoop還稍微高那麼一點點）。

後者則「借」與研並重，Spark不甚了解不敢妄評，就Hadoop相比有的在設計上更優秀（性能不知道，畢竟沒自己用過）。不過這是人家投了很多錢搞出來的大寶貝，國內企業一般不捨得開源……