为什么在中国搞不出 Spark 和 Hadoop 这种东西？ 第1页

写个系统相对容易，但培育一个开源社区非常难，需要花很多的精力，最终还要很多运气的成份。

Hadoop和Spark的成功路线并不相同，但背后都有人在推广社区方面付出的艰苦而旷日持久的努力。

我前些年一直在Facebook的大规模数据存储组，讲一讲我可以接触到的感受。

Hadoop是Yahoo搞出来的，是当时大厂做出的类似系统中唯一一个开源的，应该说这是很有优势的。在大公司大规模试验过，是其他公司选择系统中有很大的优势。但要培养成气候，他们做了很多工作，比如去各个公司演讲推广，去硅谷的各种技术交流活动，很早就开办各种用户组会议，让用户介绍他们的经验等等。另外他们和学术界的合作也在很早期就开始开展。大学的很多研究论文都在比较Hadoop和他们的系统的性能，可见他们在背后做了多少工作。 Hadoop另一个基于是正好一个后来成功的大数据推广的公司Cloudera在那个时候成立了，并顺理成章的选择了在当时刚刚崭露头角还很稚嫩的Hadoop，于是Yahoo和Cloudera构成了这个社区的两个推广者，也是竞争者。这使得这个项目有了很好的先发优势，在未来挑战者面前抢得了很大的先机。讲我了解的Facebook的事情，在Yahoo开源大概几个月的时候，当时Facebook有个跳槽自Yahoo的工程师，将Hadoop系统带到了Facebook。那个时候Facebook已经是个在硅谷很响亮的名字，但远没有几天的技术实力。Hadoop那些人看到非常高兴，为了推广，很乐意给这些用户committer权限，以鼓励使用。可见他们开源方面付出的努力。值得一提的是，这样的开源努力，在多数的公司都是无法得到全力支持的。对于所有员工来说，他们的工作应该是为了公司创造价值，而不是做公益。所以很多时候这些开源项目的推广者也需要搞定很多公司内部的问题，更加困难。

然后说Spark。我的最初的印象来自于

年时候Berkeley研究组和Facebook数据组的交流。那个时候伯克利整个研究组会开车一个多小时来到Facebook，做两三个小时的交流。在我印象中，他们至少来过两次。在每次交流中都试图推广了Spark，那时候还基本是个研究项目。即便这样的介绍，我们也没有引入。你可以想象他们到其他多少类似的公司做了介绍，才换来零星的几个试用者。你可以想象他们早期对推广他们的系统坚持不懈花了多少时间介绍他们的工作。很多人看到Spark今天的风光，没有看到他们早期多少年辛苦广种薄收的耕耘。

很多知友知道我是RocksDB开发组的，在过去的三年多时间里我们一直在努力推进我们的开源项目，我已经深深的感受到了培育一个开源社区的艰辛。我们沿着当年Hadoop开源的经验不断辛苦努力，跑各个公司，办用户组活动，找Percona等公司支持，和主要用户建立联系，参加学术会议，和各大学交流……很多时候挺累的。有很多人会觉得看你们这些人成天上蹿下跳，有人会觉得肯定是公司支持你们专门干这个的，也有人觉得肯定是你们个人喜欢利用这个出风头。其实公司对开源的支持大概仅限于不超过20%的精力，最终对一个项目的考评还是要看对公司内部的贡献。有时候我的确是很喜欢利用交流我们的项目的机会认识更多的工程师，但同时也有很多时候我对交流的对象并不感兴趣，也还是花时间推进。我们这样成长中的专而精的开源项目推广起来尚且如此，Hadoop、Spark这样覆盖面很广的项目，培育社区要花的心血就可想而知了。

所以简单的说，Hadoop、Spark的成功，技术成功只是基础，非技术的不懈努力才是关键。

我是好几个答案里提到的AMPLab孵化的Alluxio这个开源项目的PMC maintainer, 同时之前也在谷歌存储系统组里做过, 算是可以从几个不同角度说一下我的看法吧.

实现一个Spark / Hadoop这样的系统到底难不难

实现一个跑toy example的, CS研究生大作业水平. Matei说过当年其实就是在课程大作业里写Spark的雏形的.

实现一个可以性能不错可以在一些特定场景下打败已有系统的, top CS 学校的博士生半年的工作量(就是那些顶会里的paper, 各个都宣称自己能多少倍提速, 但很多你下回来都编译不了).

但是要实现一个系统, 可以在生产环境中让不同用户的环境下都能跑起来, 能跑若干个月不OOM(没有资源泄露), 有相对全面的文档, 有人(义务)在邮件列表里回答问题, 一个团队起码要干2-3年左右的时间. 那为什么要多花这些时间? 难在哪里呢?

创造和维护这样一个规模的系统, 大量的精力和时间要花在在适配各种安全验证协议, 理解和适配各种生态圈里的其他组件 (比如Zookeeper啊, Hive啊), 如何循序渐进的添加新的API / feature而不会一下把兼容性完全破坏掉, 如何设计客户端的API, 如何添加各种不同语言的binding. 这些并不是黑科技甚至没有很多的技术挑战, 纯粹是脏活累活读文档的活, 然而你要运营一个社区, 一个付责任的项目的话, 这些因素可能会比你能实现两倍还是几倍性能提升要重要的多.

同时还要做宣传推广, 开meetup培育用户, 去conference showcase你的优势, 去各大长给tech talk联络感情. 这些都是非常花时间才能让一个项目真正落地的.

Spark / Hadoop是不是黑科技

有深厚的技术沉淀但至少在硅谷完全算不上黑科技. 谷歌内部的各种大杀器分布式系统, 绝大部分不让发paper. GFS 2003年发SOSP paper的时候基本已经退役了, 它下一代的文件系统狗家来人在我们学校的seminar里present过一小点, 当时说要投2012年的OSDI, 后来也没有了下文(据说不让投). 所以真要比黑科技, 讲真谷歌还是像少林寺一样藏着72门绝技, 但外面大多不知道.

中国有没有必要自己去实现一套这样的系统

除非有特定的业务需求已有的这些系统完成不了, 不然真没必要. 见过太多这样的例子了. 自己撸一套固然爽, 但要是最早撸这套系统的人跑了呢? 谁去维护? 谁去升级? 谁去写文档? 相反开源的东西用的人越多, Stack Overflow里越可能找到问题的答案, 求个心安.

中国高校为什么目前孵化不出来Spark

讲真, 在美国也只有一些高校诸如Berkeley, CMU, UIUC经常撸出来业界能用的东西. 我个人觉得这并不是学生的问题. 一是因为是美帝有那么一小撮对业界需求了解深刻且自己也能欣然堆码且enjoy堆码的教授. 国内目前这样的还是少, 这样你很难指望出来一个天才少年自己撸一套东西出来包括知道怎么做社区怎么拉投资怎么做宣传, 很难. 另外李沐也在答案里说了一个原因: AMPLab 是以一个公司的形态在运营啊, 有全职的马工帮着写码审码, 有专门的人维护Jenkins服务保证代码健康 (Alluxio的github至今还在使用AMPLab的Jenkins). 还有AMPLab retreat这种联系工业界和学术界的互动活动. 在那种环境底下, 项目可以得到最好的培养和筛选. 正因为是这样, 我们才看到了 Mesos, Spark 和Alluxio这几个项目被成功的孵化出来.

我的两分钱看法, 以上.

一句话总结是：那个年代中国高校和公司确实搞不出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的轮子各大公司也是一把一把，哪个不比他们快个好几倍？但是不开源的话其实也没得什么比，即使开源了没健康社区也是很难活长久。

总是有人分不清楚搞不出和没搞出的区别。

所以问题修改一下为什么中国没搞出来这俩东西，是不是就客观和简单多了。

当年的Google有钱、有需求、有人才，没搞出才是奇怪的事情吧。

不知道题主在关注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后面还有什么缺陷，但他发篇论文就算了