时至今日，大数据已无处不在，所有行业都在经受大数据的洗礼。但同时我们也发现，不同于传统关系型数据库的表模型，现实世界是非常丰富、高维且相互关联的。此外，我们一旦理解了大数据的演进历程以及对数据库进阶的强需求，就会真正理解为什么“图”无处不在，以及为什么它会具有可持续的竞争优势，并最终成为新一代主流数据库标准。

大数据的发展方兴未艾。我们通常把大数据元年定为2012年，但是大数据相关技术的出现远早于2012年。例如Apache Hadoop是由Yahoo！在2006年发布并捐赠给Apache基金会的，而Hadoop这个项目肇始则是受到了谷歌2003年的GFS（Google File System，谷歌文件系统）与2004年的MapReduce两篇论文的启发。如果我们再往前追溯，那么GFS与MapReduce之所以能出现是因为谷歌的互联网搜索引擎业务的发展，而其搜索引擎最核心的技术大概要属PageRank算法了。以谷歌联合创始人Larry Page名字命名（且与Web Page一语双关）的PageRank算法是一种典型的图算法。很显然，我们回到了终点，它同时还是起点——大数据技术的发展竟然源自一种图计算技术，而它的发展趋势也伴随着图计算技术的全面发展——从大数据到快数据，最终到深数据（图数据）​。

从宏观来看，大数据的发展史基本上就是数据科技（Data Technology）的发展史，纵观过去近半个世纪的发展历程，大体可以分为三个阶段：

1）以关系型数据库为核心的传统数据库时代（1975年至今）​。

2）以非关系型数据库框架涌现为代表的时代（2010年至今）​。

3）超越关系或非关系型数据库的新时代——后关系型数据库时代（2015年后）​。

这三个阶段都产生了用于高效进行数据库、数据仓库查询与计算的查询语言，对应关系如下：

·关系型数据库：SQL。

·非关系型数据库：NoSQL。

·后关系型数据库时代：NewSQL、GQL……

如果按每个阶段所对应的数据特征和维度来衡量，可以这样解读图1-19：

·关系型数据库=数据、前大数据时代

·非关系型数据库=大数据、快数据时代

·后关系型数据库时代=深数据、图数据时代

显然，每一代都是对前一代的超越。当我们说大数据的时候，它包含了数据时代的特征，但是又出现了IBM提出的被业界广泛传播的）4V特性，即Volume（规模）​、Variety（多样性）​、Velocity（时效性、速度）和Veracity（真实性）​。

在深数据时代，在4V基础上还要加上“深度关联关系”​（Deep penetration and correlation）这一条，可以总结为：4V+D。

为什么我们会这么在意数据之间的关联关系，而且是深度关联关系呢？有两个维度可以很好地解释各行各业遇到的挑战。

·商业维度：关联关系＝商业价值；

·技术维度：传统数据库＜＞关联发现的能力。

随着大数据的发展，越来越多维度的数据被采集，而越来越多的商用场景需要分析这些多维的数据，例如反洗钱、反欺诈这类的风控场景，以及智能推荐、营销、用户行为模式分析的场景，只有将数据以网络的方式组合起来并深度分析它们之间的关联关系，我们才能摆脱之前传统数据库算力缺失的束缚——传统架构无法通过多表关联来快速发现实体之间的深层关联关系。

还以上面提到的Hadoop为例，在Yahoo！内部孵化Hadoop项目的2004—2006年间，并行于Hadoop还有其他的海量数据处理项目，在2004年的时候，Yahoo！仍旧拥有世界上最大的服务器集群，有数万台Apache Web服务器，每天生产的海量Web日志需要被分析处理。有趣的是，从分布式系统的处理能力（数据吞吐率、操作延时、功能性等）上来看，Hadoop较其他系统而言并没有优势（需要澄清的一点是，Hadoop创立伊始的目标就是用一堆廉价、低配置的机器来分布式地处理数据，它从来不是高效的，很多所谓的分布式系统都缺乏高效、及时处理数据的能力）​，这直接导致了Yahoo！在2006年初决定把在内部找不到出路的Hadoop项目捐献给Apache基金会开源社区。这件事情告诉我们，一个有内在生命力、高性能、能创造巨大商业价值的系统，几乎是不会被开源的。当然，从另一个维度来分析，Hadoop解决了数据量与数据多样性存储和分析的问题，尤其对低配置机器的集群化利用，是Hadoop最大的优势，但是它在数据的处理速度和深度方面则极度欠缺。

2014年，Apache Spark横空出世，很显然Spark背后的加州大学Berkeley分校的开发团队对于业界广为诟病的Hadoop性能问题颇有心得，在分布式系统处理性能上，通过内存加速的Spark可以达到Hadoop的100倍，Spark还集成了GraphX等组件来实现一些图分析能力，例如PageRank（网页排序）​、Connected Component（连通子图）​、TriangleCounting（三角形计算）等。Spark相对于Hadoop框架而言，在速度上有很大进步，特别是对浅层的图计算与分析颇有意义。然而Spark过于学院派的设计思路导致系统不可以实时更新，也就是说不善于处理动态、实时变化的数据集，这样就限定了它只能作为一款仅具有离线分析能力的OLAP系统。距离我们所说的实时、动态、深数据处理的终极目标仍有很大的差距。

所谓深数据，就是在最短时间内通过挖掘多层、多维数据间的关联关系，挖掘出数据间所蕴藏的价值。特别是在这个数据互联的时代，可以以一种通用的方式实现深数据关联分析与计算的平台就是笔者一直强调的主角——图数据库。在不同的场景下，我们也称其为图分析系统、图中台、图计算引擎等。

所有的这些其实都是指一件事——按照图论的方式构造关联数据所形成的高维网络，并在其上进行计算与分析。例如鲁汶（Louvain）社区识别算法在实时图数据库上运行后，隶属于不同社区的实体间所构成的社区通过3D可视化的方式直观地呈现在我们面前，如图1-20所示。你无法从其他类型的NoSQL、大数据框架或关系型数据库中找到类似的实时、深度数据关联的解决办法，即便存在，那个方法的代价肯定不小，而且不会以一种通用化的方式完成。

也就是说，每当业务诉求改变的时候，就需要大幅调整底层架构来支撑，这种模式如何能够有长久的生命力呢？键值存储、列数据库、Hadoop分布式计算或Spark集群计算、MongoDB文档数据库在处理数据关联问题上都是不完善的。正是以上提到的这些瓶颈和挑战，才使图数据库得以诞生并蓬勃发展。

·  END ·