为什么在中国搞不出 Spark 和 Hadoop 这种东西?

理由
举报 取消

先问是不是,再问为什么,不要耍流氓!国内hadoop类似产品不止一个吧,估计还胜过现在的hadoop,现在hadoop可不是啥核心科技———————————-我是一名CS学生,我想听听对题目问题的看法。 我很好奇是哪些本质的东西决定了在美国搞出了这些东西,在中国就没有出现。我能想到的原因就是:我觉得国内的互联网环境更关心怎么赚钱怎么快速迭代产品,而对于技术创新投入不够。

2017年7月9日 10 条回复 1146 次浏览

发起人:李默然 初入职场

it男,擅长各种linux底层、android底层、ios开发。

回复 ( 10 )

  1. 李沐
    理由
    举报 取消

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

  2. 熊辰炎
    理由
    举报 取消

    现在其实没必要再提这个问题了,分布式过了这么多年,早已经不再是简单的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++做了一套内部使用的出来。

    问题其实是,公司有没有对这种没有短期效益,但是长期是一个公司核心竞争力的技术方向的持续投入的决心。

    在云计算越来越重要的今天,现在回过头看看阿里云,再看看百度云,只能是一声叹息。

  3. 姚冬
    理由
    举报 取消

    上周去深圳参加了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都在招人,也招实习生。

  4. 斯图亚特
    理由
    举报 取消

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

    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的成功,技术成功只是基础,非技术的不懈努力才是关键。

  5. Xiaoyu Ma
    理由
    举报 取消

    更新:提了这么多次轮子换来轮子哥一个赞,计划通。

    ————————

    我的看法是 这个是个厚积薄发的事情。就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一个月后去上班。

  6. 桂能
    理由
    举报 取消

    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后面还有什么缺陷,但他发篇论文就算了

  7. RednaxelaFX
    理由
    举报 取消

    不知道题主在关注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抄来的而且一开始还抄得很糟糕。

    后来大家也渐渐的都开始遇到类似的需求的,有能力有野心有耐心的就自己再造一次轮子(例如微软、阿里云、楽天),不然就想办法把开源的改造/配置成适合自己环境使用。

  8. vczh
    理由
    举报 取消

    其实这些东西很多成分都是中国人搞的,就算是比spark早了10年的微软的一摸一样的只给自己用的cosmos,里面也有大量的中国人在做,很多算法也是中国人想出来发了论文的。你要问的是,为什么中国人在中国的公司就搞不出这样的东西,这才是正确的提问方法。

    当然这个问题很简单——你搞出来了就能当老板吗?

  9. 张云聪
    理由
    举报 取消

    这种系统每个大公司都有一堆,只是没有开源,而本问题下一堆人回答的时候各种冷嘲热讽国内大公司水平不行,做不出来这样的系统,讽刺说国内抄都抄不出来的时候,你们真的了解具体的情况吗?

    百度一开始是根据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等一堆系统,这叫国内没有?

    (以上系统名称来自于公开可检索的信息,未涉密:)

    不止百度,基本上大公司都有类似的东西,阿里的飞天,盘古,云梯,腾讯的台风(据说已经死掉了),只不过都不开源…

    也许问题改成为什么国内公司没有开源这样的系统更合适。

    嗯,MR论文发表后,按照MR论文加自己小创新做出来类似MR的系统确实没有提出MR这种创造性工作牛逼,可这里讨论的毕竟只是做出hadoop这类的系统,要知道hadoop也是照着MR论文“抄”出来的。

  10. Ivony
    理由
    举报 取消

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

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

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

我来回答

Captcha 点击图片更换验证码