60 lines
7.9 KiB
Markdown
60 lines
7.9 KiB
Markdown
|
# 067 | Hadoop三国之吴国MapR
|
|||
|
|
|||
|
今天我要介绍的这个Hadoop发行商是MapR。它算得上是一家特立独行的公司,它实力很强,但却比较少去参与争斗,所以我们把它称作“吴国”吧。
|
|||
|
|
|||
|
MapR成立于2009年,由CEO约翰 · 施罗德(John Schroeder)和CTO斯里瓦斯(M. C. Srivas)创立。到2016年的时候,施罗德卸任CEO,做了执行主席(Executive Chairman),斯里瓦斯则去了Uber。为什么CEO和CTO下台的下台,去Uber的去Uber,这是个有意思的问题;我留到文章最后来说。
|
|||
|
|
|||
|
先从MapR这个名字聊起,它是MapReduce的缩写。在心理学上有这样一个说法:人们总是会在潜意识里面,流露出对自己不擅长的东西的关注。从这一点上来看,MapR这个公司拿了MapReduce来做商标,而事实上它擅长的也的确不是MapReduce。
|
|||
|
|
|||
|
**MapR的Hadoop发行版和其他公司很不一样,它是一个挂着Hadoop外壳,但是夹杂着自己私货的版本。**
|
|||
|
|
|||
|
MapR的联合创始人兼CTO曾经在谷歌的文件系统组做过经理,所以他很强烈地认为Hadoop的文件系统是个“渣子”。于是这个CTO用很低廉的薪资在印度雇用了一群程序员,重构了一个文件系统。这个文件系统据说有比Hadoop的文件系统优越无数倍的性能、稳定性、安全性,等等。
|
|||
|
|
|||
|
**而MapR的Hadoop版本,简单一点来说,就是把Hadoop里面的文件系统替换成了自己的这个不开放源代码的文件系统,同时又做了很多工作,让这个文件系统和现有的Hadoop体系兼容**。这种兼容性在我看来其实挺难做的,但是MapR号称是做到了。
|
|||
|
|
|||
|
本着在文件系统道路上越走越远的想法,MapR踏出了第二步:瞄准了在Hadoop生态圈里非常重要的NoSQL产品HBase。
|
|||
|
|
|||
|
HBase的大名可谓众人皆知,但是因为HBase受到了Hadoop文件系统本身的一些限制,以及设计与底层的存储分离得太厉害,其性能一直不是很好。
|
|||
|
|
|||
|
**MapR的下一步做法是改变文件系统,在文件系统内实现对HBase的支持,并且提供HBase的接口给上层应用。这样用户其实不需要额外装HBase,就自然而然地拥有了HBase的功能。**
|
|||
|
|
|||
|
**这还没完,MapR在自我改造的道路上越走越远。它们又瞄准了Kafka——这个在Hadoop系统里面做数据交换的重要服务。**MapR的做法还是继续改改改,改它的文件系统,让文件系统又拥有了Kafka的功能。于是,用户们不需要安装,就可以使用Kafka了。
|
|||
|
|
|||
|
**没错,就是这样。这个创业公司凭借一己之力,集聚了一群程序员,挑战了全世界,重新实现了这么多的功能,然后再包装进自己的发行版卖给客户。更重要的是这些重新实现的功能,据说性能上要好很多。**而开源的东西,按照MapR的说法,实在是只能凑合着用。怎么样也比不上MapR的高大上。
|
|||
|
|
|||
|
MapR的说法是,这种做法不只实现了同样的东西,而且做得更好、更高效。“更快、更高、更强”是每个人追求的目标,如果后面再加个“更便宜”,那就太完美了。
|
|||
|
|
|||
|
**只是MapR的这套系统本身以赚钱为目的,和“便宜”是没有什么关系了:MapR的系统卖得比其他人的系统都贵,因为他们觉得自己的系统更好。**
|
|||
|
|
|||
|
**此外,但凡是存储相关的功能,MapR都重新实现了一遍,其他部分则选用开源的,这就导致了两个问题。**
|
|||
|
|
|||
|
第一,那些开源的东西在这个文件系统下的兼容性需要仔细测试。所以很多时候你会发现,只有伴随着MapR的发行版一同发行的开源工具,才能在MapR的文件系统上很好地工作,而外部下载的就不能保证这一点了。
|
|||
|
|
|||
|
第二,就是客户有顾虑。客户会想:你的系统是自己实现的,如果我上了你的“贼船”,再想回头去用Cloudera的,就不太可能了吧?因为你的数据存储,对别人来说就是不透明的,迁移起来会有障碍。为了避免被“绑”在MapR的战车上,还是不要买你家的东西吧?
|
|||
|
|
|||
|
这其实很考验市场人的宣传功力。 当然MapR的宣传队伍不是吃素的,他们把自己的系统定义为“二进制代码无差别兼容”。简单一点来说就是,在其他的Hadoop发行版和MapR之间,可以互换模块随便运行。
|
|||
|
|
|||
|
这个口号看上去很美好,但实际测试的时候往往就是另一番景象了。这个所谓的“二进制代码无差别兼容”,从来没有真正实现过。不过,倒是很多人在宣传的时候说“我们就是Hadoop,没有兼容性问题”。这个Hadoop发行版终究没能成功开疆拓土,在美国以外地区几乎没有什么人用。
|
|||
|
|
|||
|
**相对于存储系统,MapR在系统的执行方面就显得没这么自信了。MapR有关执行的部分,比如说MapReduce,或者在MapReduce之上开发的各种查询语言——如HIVE、PIG等,都是直接用开源的。不过,MapR对开源社区的贡献是有目共睹得低。**
|
|||
|
|
|||
|
MapR主导了一个开源项目Apache Drill的开发。大概在2013年的时候MapR的人来找过我,我和当时的Drill项目负责人聊过以后,感觉对方对很多问题都还没想清楚,所以没有去MapR工作。
|
|||
|
|
|||
|
后来Drill的发展也并不顺利,再后来变更了主要负责人,项目也慢慢起来了,参与进来的公司越来越多。再后来,伴随着MapR创始人的下野,Drill的人也跑去开了个创业公司。我个人对于这个创业公司的前景不是特别看好,主要还是感觉Drill这个产品不是很出彩。
|
|||
|
|
|||
|
Drill这个东西是开源的,但是MapR这个企业对于好东西,往往都不开源。因此,我们难免要仔细审视一下Drill。至于Drill发展至今又是个什么境况,我就不妄加评论了。
|
|||
|
|
|||
|
**MapR的融资过程比较有意思,前后融了好几轮,最后一轮时,谷歌旗下的风险投资部门Google Venture投了钱。为什么说有意思呢?因为谷歌很少在Hadoop的相关领域撒很多钱,比如在Cloudera上投入就不多。**
|
|||
|
|
|||
|
我想,可能谷歌从来都没有看好过Hadoop的文件系统,或者Hadoop整个生态圈。但是对于凭一己之力去重写文件系统的公司,并且其创始人还是从谷歌出来的,知道Hadoop内部是怎么做的,可能就刮目相看了。谷歌也许认为这样的公司有可能成功,所以才投入了很多钱。
|
|||
|
|
|||
|
**MapR的生意很有意思。它真正的客户量很少,可能连Cloudera的10%都不到。但是很奇怪,MapR和Cloudera在营收上差不多。也就是说,MapR的每个客户,贡献给它的钱都要多很多。**这到底是什么原因导致的呢?因为客户上了MapR的“贼船”下不来,而不得不继续使用?还是这家公司的产品真的受有钱公司的欢迎?我无法去辨别。
|
|||
|
|
|||
|
**MapR的CTO兼联合创始人,在2016年离开MapR成了Uber的首席数据架构师。**创始人下台或者离职,显然不是什么好事情。那么,这个印度人为什么放着自己好好的公司不做,非要跑去Uber呢?
|
|||
|
|
|||
|
**我想不外乎两个可能性:一是自己做得没兴趣,不想做下去了,二是资本的力量进来了。**也许CTO觉得钱赚得不够多,不是上市的好时期,而资本没有这个耐心继续等下去,因此就只能把“拦路虎”清掉了。我想,第二个原因可能性更大。
|
|||
|
|
|||
|
但是我们必须要提醒大家的是,MapR的这套发行版能够出来,这位CTO功不可没。离开了他,MapR是不是依然具备继续前进的能力呢?这就留给时间来检验吧。
|
|||
|
|
|||
|
不知道MapR到底什么时候要上市,也不知道上市以后会采取什么举措,但这种创始人离职的现象,也许不是一个好的信号。我很难理解一个创始人需要在公司上市前夕,离开自己辛苦创业的公司这种情境。我只能说,要么是公司层面的问题,要么就是资本的力量太强大了。你认为,这对MapR又会有什么影响呢?
|
|||
|
|