大数据技术详解比较分析！

1. Hadoop 的神话正在破灭

IBM leads BigInsights for Hadoop out behind barn. Shots heard

IBM has announced the reTIrement of the basic plan for its data analyTIcs software platform， BigInsights for Hadoop.

The basic plan of the service will be reTIred in a month， on December 7 of this year.

“IBM把BigInsights for Hadoop牵到牧棚后面，只听一声枪响…”

这个是前不久英国知名媒体The Register对IBM 产品BigInsights产品下线的报道。

BigInsights 是IBM在Apache Hadoop上增加了不少IBM分析技术能力后形成的一个大数据分析产品。 在面临近乎2年的前途未卜的窘境之后，IBM终于决定将其关闭。

无独有偶，前不久Gartner的一篇文章也指出 “70%以上的Hadoop部署未能天线的业务价值…”

Hadoop大数据是怎么了呢？

我们从DBMS数据库管理系统的角度，来剖析下常见产品的能力：RDBMS，MPP，Hadoop，NoSQL以及NewSQL。 这几类产品对数据处理的能力各有什么样的特点？

2. 常见几种数据技术比较

我们首先试图对大数据这个被第一滥用的名词来统一一下概念。按照Gartner的说法，大数据具备以下几个特征（3个V）：

Volume： 数据量够大

Velocity： 数据访问并发够高，够实时

Variety： 数据的类型多

从另一方面讲，大数据也是数据，对常规数据的管理离不开我们熟悉的ACID事务性来保证对数据操作时候的原子性，一致性，隔离性和持久性。有了这个几个衡量标准以后，我们可以来对上述几个产品列表比较一下。

9. MongoDB vs. HBase

事实上HBase正式作为一个NoSQL通常是Hadoop生态系统里用来支持操作型大数据的实时读写需求的。可惜HBase 是个扶不起的刘阿斗，跟着Hadoop的大旗沾了不少光，用起来问题一堆：

1、原生不支持二级索引，只能通过主键访问。社区实现的二级索引功能支持和数据更新有时延，导致头疼的一致性问题

2、宽表模型概念拗考，难于理解并且要求实现建模，不够灵活

3、数据类型低级，只支持比特流，开发很不友好

4、支持程序语言种类少（Java，Thrift， RESTful API）

5、集群结构复杂，有8种不同类型节点

6、无一致性快照功能

7、需要定时compact，对持续读写场景影响很大

因为这些原因，HBase只能在真的是超级大量数据的场景下才值得去忍受着种种不便去使用。和HBase相比，MongoDB也有一些自己的不足：

1、多表事务还在研发中，导致对原子性要求较高需要回滚的时候只能通过变通手段来实现，增加了开发复杂度（所有NoSQL基本都不支持事务）

2、常为读性能优化而鼓励冗余，但是又不提供这些冗余数据变化时候的自动同步

但是MongoDB在取悦开发者，提高开发效率上可是做的淋漓尽致：支持数十种程序语言；有最大的开发社区；JSON文档模型是个程序员都懂，API式管理数据库，非常自然；支持二级索引，关系型数据库的复杂查询基本都能支持；MEAN stack，全JS开发；无须ORM，减少服务层和持久化层的摩擦；动态模型，无须显式建模，适合快速开发；傻瓜式水平扩展。正是这些原因，DBTA 2017年的“读者最喜欢的数据库”里面，MongoDB傲视群雄，夺得了桂冠。

除上述之外，基于分片机制的自动扩容的机制更可以支持数以百TB级的业务数据量；异构数据库实时同步工具可以把来自于数十个业务系统库内的数据同步到数据服务层，并提供秒级的数据一致；在同步过程中实现数据模型转换，快速搭建服务；批量方式或者连接器方式直接接受来自Hadoop集群的分析结果，如个性化标签及推荐信息等，提高Hadoop的可操作性 等等优势。

RBS银行在2015年就开始实施了这样的DaaS架构，短短两年时间，RBS声称已经获得了以下的价值：

1、降低的成本：数百万欧元的Coherence及Oracle商业授权的节省

2、简化的技术栈：一套方案已经支持了数十个数据应用

3、开发加速：新应用上线时间从12个月到数个星期

与此类似的成功案例还有巴克莱银行，Vodafone电信公司等，均是在其数字化转型中经过审慎评估，选择了操作性强，易用性高，分布式能力可靠的MongoDB作为其新一代数据服务平台。

11. 结语

每一种技术都有它的应用场景，在这篇文章里我们想要讨论的是一种操作型大数据解决方案，所以我们花了不少笔墨在NoSQL并认为MongoDB是一个非常不错的选择。NewSQL或许会是一个潜在的选择，如果不是因为现在它还没发展成熟。况且，NewSQL对半结构化、非结构化数据的需求支持估计也还是无法很好满足， 所以我们拭目以待。最后，在做一个大型决策的时候，我们要充分考虑到企业对技术能力的需求，把需求列出来，然后对照数据产品各自的长短板，有理论有方法的进行选型，并对最后2-3个选择进行POC验证，最终确定合适的方案。