今天我要介绍的这个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又会有什么影响呢？