大数据不只是Hadoop！

不少人认为，大数据就是Hadoop，其实这里存在着认知错误，但这种论调似乎在业界颇有市场，因为Hadoop真的很火爆，尽管许多人并不清楚Hadoop到底是什么，可以用来做什么，但是如果某种大数据技术不和Hadoop沾边儿，客户、投资人甚至自己的团队可能都会对该技术的前景持迟疑的态度。
首先我们需要了解大数据处理的发展历程中形成了哪些主要的流派与生态系统。
从20世纪90年代到今天，面向海量数据的处理与分析经历了如下的3个主要阶段：

关系型数据库一统天下的时代（1990—现今）
Hadoop与NoSQL并驾齐驱的时代（2006—现今）
NewSQL横空出世的时代（2010—现今）

下图展示了这四大类大数据技术沿时间横轴的发展历程。

（1）关系型数据库时代

在上篇文章《大数据从何而来？》中，我们提到过关系型数据库自从20世纪70年代出生即飞快地一统江湖，到了21世纪的第一个十年内已经发展为一个庞大的生态系统。其中商业关系型数据库三强为：Oracle、DB2、SQL Server，这三者的市场份额已经超过85%，再次印证了在科技行业，不能进入前三名意味着无足轻重的江湖地位；相对商业版本而言的开源关系型数据库前三甲是MySQL（含MariaDB）、PostgreSQL与SQLite。
随着互联网企业的兴起，以关系型数据库为代表的这些传统的数据存储、处理、分析与管理的架构遇到的挑战越来越大，它们普遍地在数据处理类型上，超大数据集的处理能力上都遇到瓶颈，因此业界在2004—2010年前后开始迅速推出了一些解决方案。比较典型的有Hadoop与NoSQL两大系列。

（2）Hadoop vs NoSQL时代
最早由Yahoo!开源的Hadoop项目，是受到了谷歌公司2003年、2004年公布的谷歌文件系统（GFS）与MapReduce计算架构的启发（很多人把Hadoop看作开源的GFS+MapReduce）。Hadoop对应着谷歌技术的两大组件是HDFS与MapReduce，一个负责海量数据存储（可扩展性、容错性），一个负责对海量数据的分布式处理（新的编程范式）。
Hadoop出现之后迅速得到了业界的强烈支持，出现了一批围绕Hadoop软件架构的商业公司，其中最知名的当属Cloudera和Hortonworks。Hadoop项目在Apache软件基金会的管理下也很快形成了一套颇为完整的可匹敌商业解决方案的软件框架。
另一阵营的大数据解决方案则是No SQL（Not—Only—SQL或者是Non-Relational）。NoSQL具有如下两大特点：

· 大多支持类SQL的查询方式来对其访问
· 绝大多数系统一定程度上牺牲了数据的一致性来实现可用性与扩展性

NoSQL的阵营玩家如此之多，按照数据库引擎分类的话可以分为如下5大类。

·列、宽列数据库（WideColumn）：Cassandra、HBase、HyperTable等。
·文档数据库（Document-based）：MongoDB、CouchDB等。
·键值数据库（Key-Value）：CouchDB、Dynamo、Redis等。
·图数据库（Graph）：Neo4j、JanusGraph、Ultipa Graph、Tigergraph等。
·多模数据库（Multi-Model）：Arrange、OrientDB、MarkLogic等。

它们各自的侧重点与设计理念不尽相同，但都可以看作是对传统关系型数据库的逻辑简化（做减法）或增强化（做加法）。
有的NoSQL数据库为了追求高性能全部在内存中运行，如Gemfire、SAP HANA都部署在内存中形成了基于内存的数据处理网格（In Memory Data Grid，IMDG）。

**大数据的发展方向是从大数据到快数据，再到深数据。所谓深数据在本质上是对数据间的深度的关联关系的挖掘，而当这种网络化、社交化、实体链接化等关联关系的挖掘需求被实时化的时候，这个挑战就是典型的图数据库所应对的。**有研究表明未来的十年内，图数据库的发展会以关系型数据库的4倍的速率增长，而采用图数据库的企业会增长50—100倍之多，并有40%—50%的SQL负载会转移到图数据库上来处理。

（3）New SQL时代
Hadoop与No SQL阵营之外，近几年又涌现了一批着重于实现数据一致性同时兼顾数据可用性与扩展性的系统，从最早的学院派的H-Store，到谷歌的Spanner以及后来的SAP HANA等等，它们通常可以同时具有OLAP（OnLine Analytics Processing）与OLTP（OnLine Transaction Processing）系统的功能，前者在Hadoop与NoSQL阵营中都能找对应的解决方案，但是后者涉及大规模分布式条件下（例如，跨数据中心，甚至是跨大洋的分布式系统）交易处理的实时性与一致性，因此实现的难度也更大。

最近几年来，兼具能力的数据库不再局限于New SQL，甚至业界并没有很多人会把New SQL单独提出来，而是有一些No SQL类的数据库宣称可以同时支持在线的分析（OLAP）与事务性处理（OLTP）。值得指出的是，尽管OLAP所代表的意思是Online Analytics Processing, 但是在New SQL概念出现前，几乎所有的OLAP系统都等同于批处理、线下处理系统，这听起来有些名不符实，但是这是个现实的情况。随着架构（算力）、数据结构、算法等的不断提升，那些之前无法做到在线、实时处理的海量数据可以被新型的No SQL类数据库所实时处理时，这些No SQL在本质上已经与New SQL无二了。业界近两年来出现的Tigergraph, PingCAP, Ultipa Graph等都属于致力于融合OLAP与OLTP的实时No SQL数据库 ，或称之为New SQL。

最后，需要指出，RDBMS、Hadoop与NoSQL并非非此即彼的关系，在实践中，它们经常会一起出现从而构成一个混搭的系统，并发挥着各自的强项，这一点是需要我们注意的。

[注释]
注释1：OLAP
OnLine Analytical Processing既在线分析处理，通常OLAP因经常面向全量数据，计算量巨大而导致时延较长，因此很多人把OLAP等同于高延时批处理+静态数据处理。尽管，这么理解并不准确。在批处理时延中，T+1时延指的就是OLAP系统需要连夜运行到第二天才能结束。而T+0通常指的是当天（小时级时延）可以分析、运算完毕。
注释2：OLTP
Online Transactional Processing既在线事物（交易）处理。OLTP相对于OLAP系统有两点不同。1. 低时延，OLTP系统通常是实时性的，例如典型的交易处理系统要求低时延、高并发；2. 数据一致性，交易处理系统尤其会强调对于系统的数据一致性要求，特别是当系统有高并发的读写，例如增删查改操作时的系统中的数据一致性要求。
HTAP
Hybrid Transactional & Analytical Processing指的是在一套系统内可以同时支持OLAP+OLTP，既同时支持这两类业务场景。通常是在一套分布式集群内不同的实例来支撑不同的OLAP或OLTP的需求。

·文/ 老孙（孙宇熙：云计算、大数据、高性能存储与计算系统架构专家 ）
·END·