Hadoop生态圈的另类MapR：造反有理！
虽然MapR的开放核心战略在Hadoop生态系统不再是个另类，但是其融合平台依然独树一帜。虽然数据治理方面仍存在一些不足，但是MapR在总体拥有成本（TCO）方面可能有一个漂亮的故事好讲。
MapR在2011年一举成名以来，就是Hadoop社区的一个另类。当时，Hadoop基本上由脱胎于谷歌研究课题的两大项目来界定：MapReduce和HDFS文件系统，前者将高度线性的大规模并行处理引入到大数据，后者则可以处理PB级的数据。而在那时，Hadoop被定义为是一种Apache开源平台。
无论彼时还是现在，MapR向世人传达的一种讯息就是，开源技术并不总是足以让它成为企业级解决方案的最后一英里。它的战略并不是非同寻常――它体现了开放核心理念（open core），即用专有的增值服务来补充开源技术。它先是对Apache Hadoop的支柱之一：文件系统使出了一拳，MapR用自己的文件系统（MapR-FS）取代了HDFS，提供了HDFS所没有的更新和删除功能。
MapR这个造反派日益进入了主流，但是未必以随波逐流的方式进入主流。相反，业界的其余厂商最终拥抱同样的开放核心模式，但是以各自的方法来实现这个模式。Cloudera一开始就奉行开放核心理念，但是与MapR不同，它专注于独特的内容，而不是运行时环境（比如，用于监控、数据治理、SQL优化和加密密钥管理）。Hortonworks堪称是百分之百开源的典范，它最近采取了一种更从实用而不是从道义或意识形态考虑出发的战略，先是与AtScale、Syncsort和Pivotal签署了几项OEM协议，后来更坚决地划清了界限，推出了其特殊的Hortonworks Data Cloud for AWS，换用了亚马逊S3云存储。
MapR刚办完了有史以来的首届分析师大会，这对一家传统上业务经营不为外界所知的公司来说堪称里程碑。它已确立了稳固的基础，其客户群中40%是从Cloudera和Hortonworks挖过来的，其订阅服务已获得了99%的续约率，订阅服务每年的增长率通常高达35%。与Cloudera一样，MapR也预测，到2017年至2018年会实现收支平衡，首发上市（IPO）已提上日程。
它号称其产品是一款融合数据平台（Converged Data Platform），这种平台在同一个集群上支持数据流、交互式处理和批处理，实际上使Lambda架构扁平化。这家公司强调，其平台不是分散的部分，而是文件、表和数据流引擎源自通用的构建模块。这包括NFS和与Posix兼容的MapR-FS文件系统，而MapR的NoSQL数据库（MapR-DB）表共同驻留在该文件系统上。又由于MapR领导的开源Drill项目，你可以使用同样的查询引擎来处理SQL数据和JSON数据。
那些构建模块旨在完成最初的开源Hadoop项目技术http://www.zdnet.com/的事业。与HDFS相比，MapR-FS支持更新和删除，让存储系统占用的空间要紧凑得多。而万一你想要同时跨多个数据中心及/或云运行，取代HDFS NameNode的一种分布式元数据管理系统使得时间点快照和多主（multi-master）复制成为了可能。它还能够控制数据布置，这为需要以物理方式隔离特定数据池的客户带来了优点。最后，MapR声称其文件系统的扩展性要强得多，能够支持的文件数量至少比HDFS多100倍。
虽然MapR最初支持它以自己的专有方法实现的HBase，因而消除了地区服务器，也不需要精简操作，但是它又增添了自己的替代方案：MapR-DB，它声称MapR-DB提供了比HBase更高的可靠性、比MongoDB更强的可扩展性以及比Cassandra更好的一致性。
说到分布式PubSub消息队列，MapR也与假想的对手较量。虽然Apache Kafka已从数据平台和数据流引擎提供商都得到了广泛的第三方支持，但MapR推出了自己的替代方案：MapR Streams，它也驻留在文件系统和NoSQL数据库所在的同一个集群上。相比之下，Kafka需要单独的集群。这给了扁平化架构另外一个打击。
另外，考虑到融合主题，MapR还声称把分析和操作处理结合起来，这不足为奇。没错，它们是在同一个集群上运行，但不是使用同样的存储引擎；分析仍是Hadoop文件系统的天下，而操作处理局限于NoSQL数据库――不过你可以针对这两者使用Drill查询。MapR声称将分析和操作应用结合起来的说辞很平常。
像Oracle和IBM DB2这些家喻户晓的品牌用放在一起的内存列式存储区来处理这个问题，而像MemSQL和Splice Machine这些新兴的事务系统提供Spark接口。对知名的NoSQL数据库：MongoDB、Couchbase和Cassandra来说也是如此。
MapR还坚持认为：融合平台对物联网来说同样更高效，因为它意味着减少了与不同集群之间的往返次数，以便对数据执行聚合、数据流、解析、分析和持久化等操作。但是融合平台对物联网这种分布式使用场合而言很有限，因为物联网数据的分散特性和带宽限制预示着在边缘处进行过滤、预处理和聚合。问题在于，MapR会不会步亚马逊的后尘，在边缘处提供一种类似Greengrass的预处理工具。
在像美国运通（American Express）这些需要Spark的那种类型的分析性能的客户面前，MapR已取得了相当大的进展――大概比Spark出现早五年。它还需要能够原地更新文件，但是当时像Isilon这些商用文件系统无力处理大规模并行数据访问。
仍有一个很大的缺口需要MapR来补上――竞争对手Cloudera和Hortonworks在数据治理和安全方面要积极主动得多。虽然融合平台为第三方加密或保护数据提供了一个共同的目标，但是MapR还没有为数据恢复、审计、数据沿袭、元数据管理和策略执行提供自己的解决方案。
作为造反者的状态意味着，MapR必须证明自己是有理有据的。其底层组件不同于核心的Apache Hadoop堆栈。但是在API层面，它们相互兼容，这意味着你可以在MapR和与之竞争的Hadoop平台之间移动文件，并运行同样的Spark作业。
而回到我们最初的那一点：MapR的做法与这个领域的其他厂商不再大不一样。但是甭提开放核心在当前得到了接受，哪怕开源或标准的存在也不能保证互操作性。比如说，在Hadoop领域，至少有十几种交互式SQL引擎――而在SQL关系数据库领域，那就更不用说了，种类还要繁多。
不过，即便MapR宣传高性能或融合等优点有多好，其程度总归是有限的。在Spark（MapR支持它）的时代下，Hadoop上的实时性能并非不同寻常。而融合平台的优点可能并不适合所有场景。不管你的平台性能有多出色，如果你拥有要求很高的争夺资源的工作负载，比如高度复杂的批作业，涉及实时并发运行的数十PB的数据，或者运行智慧城市的持续的物联网应用，那么在单独的集群上运行它们可能仍然具有优势。
而作为造反派，有时候另辟蹊径的优势是有限制的。以Kafka为例：由于日益得到第三方支持，MapR Streams会被束之高阁吗？当然了，你可以使用单独的Kafka集群来运行MapR，但是那样的话，你也就失去了拥有这个融合平台的一部分优点。
不过，由于其融合平台，这个造反派还留有一手：总体拥有成本（TCO）值得关注。如果你有一个可用少得多的基础设施来运行工作负载的平台，那么集群就会紧凑得多。当然了，硬件很便宜，但是东西太便宜了反而会变得很昂贵。
相关阅读：