数据库出现
要说大数据的真正起源，必须得提到数据库。无论是移动互联网还是PC因特网，或者是计算机本身，背后都是一群又一群程序员写的程序，而一切程序说到底都还是对数据的处理。如果把数据处理比作一个王国的话，那这个王国的国王就是数据库。
那什么是数据库呢？用最简单的话来说，就是一个用户可以把数据存储在数据库，需要的时候，用户可以告诉数据库，我需要某些数据，然后数据库会自行完成实际的数据处理过程，返回数据给用户。数据库帮程序员把底层复杂的数据处理过程给屏蔽了，程序员只需要关心数据存储和查询就好。
数据库与正常的商业软件一样，第一个吃螃蟹的“前浪”最终倒在了沙滩上。那个时候，关系型模型还被认为是“不靠谱的”，最流行的模型是层次模型和网状模型。经历过激烈的市场竞争和工程实践，大家最后发现关系型模型才是适用于大部分环境的数据库模型。
一旦某一个基础软件确立了其垄断地位，然后再围绕其构建庞大的生态系统，那么后来者即使做出了相似的产品，垄断软件的生态系统一样会扼杀掉后来者，除非另辟赛道或者是先行者解决不了某类问题。数据库也是如此，Oracle、DB2等数据库占据了金融、电信等传统企业的大部分份额便可说明这个情况。
回到数据库本身，第一款真正意义上的关系型数据库应该是 IBM 研究院的 SystemR。研究院出来的东西大多都比较“曲高和寡”，没有考虑到大多数人的实际使用感受，比如System R使用的查询语言更像是数学家的玩物，而不是工程师的杰作，普通人很难学习，但是不可否认的是，这确实是第一款数据库，相比于之前的状况要好的太多，毕竟只要学会查询语言的语法，就能处理数据了。
System R就像“前浪”，帮大家把路躺平了，证明了关系型模型优于其它的数据库模型，并且在商业上更优异。于是大家一窝蜂而上，Oracle、DB2等等随之登场，各领风骚。由此催生出一门伟大的语言——SQL 。在某种程度上，SQL 才是数据领域内的“唯一”的统一语言。SQL 区别于其它语言的一个很重要的特点是它是“声明式”的语言。简单来说，所谓声明式就是使用者只需要告诉计算机他想做什么，剩下的都交给计算机实现。与声明式对应的是命令式语言，命令式语言会告诉计算机它应该按什么步骤实现什么，计算机亦步亦趋即可。大部分编程语言，比如 Java、Python 这些编程语言都是命令式的语言。相比于声明式语言，命令式语言的学习难度更大、更陡峭，这也意味着使用人数很难扩大。因此大家会更喜欢声明式语言。
数据库作为基础软件，在证明了其能力后，配合 SQL 迎来了它的辉煌时代。那个时候，无论是什么公司，只要你使用信息技术提供商业服务，那就离不开数据库。因为一切应用程序的本质都是在处理数据。
Hadoop诞生
互联网与物联网的发展，给数据库带来的最大挑战就是数据量：越来越多的数据，多到单机已经无法存储和处理，无论单机的性能有多么强悍，庞大的数据总会吞噬掉其剩余性能。在某种程度上来说，在大数据技术诞生之前，越来越多的数据都是垃圾，因为大部分数据无法处理。
第一个解决这问题的公司，是Google在2003年发表了三篇技术论文，这三篇论文在大数据领域被戏称为“三驾马车”，分别是GFS、MapReduce 和 BigTable。GFS 解决了数据大规模存储的问题，让数据可以几乎无限的增长下去；MapReduce 解决了数据大规模计算的问题，让大规模数据处理成为可能；BigTable 解决了在线实时查询的问题，即使数据量很大，用户也能很快的查询到数据。
Google仅仅只是发表了论文，而没有开源实现。雅虎参考Google的论文弄出了Hadoop，以实际的线上业务去测试和完善Hadoop，并把 Hadoop 开源了，这可是了不得的大事，因为有了 Hadoop，企业便不再依赖于昂贵的高端的硬件机器，只需要廉价的计算机也能完成以往在高端的硬件机器上完成的事，在某种程度上，甚至更好。从此以后，企业累积的数据不再是“垃圾”，摇身一变成了金矿，企业可以持续地从数据中挖掘出有价值的东西。
平心而论，刚开源的 Hadoop 不仅仅安装部署麻烦，而且使用起来也非常困难。比如用户仅仅想要统计整个文件的数量，还要为此专门写一堆 Map 和 Reduce 函数和代码。然而这些都不重要，重要的是Hadoop解决了一个非常重要的问题，重要到使用体验不佳这些都变成了小问题。
Hadoop的成功
在某种程度上，Hadoop 已经成为了大数据领域里的事实标准。现在回过头来看，Hadoop 为什么最终会成功呢？
- 首先应该是时机出现的好，Hadoop 出现的时候，企业面临着空有庞大的数据却无法处理的问题被Hadoop 以一种简单粗暴的方式解决了。
- 其次是开源，因为 Hadoop 是开源的，所以使用 Hadoop 的公司不用担心这项技术会被其它公司卡脖子，并且开源社区的帮助，使得Hadoop从一个粗糙的玩具变成一个商业可用的产品。
- 最后是商业价值，Hadoop 可以帮助企业分析和处理庞大的数据，并且从中获得了巨大的商业利润。
最终这三个因素帮助 Hadoop 构建了“生产-市场-研发”的正向循环。Hadoop 能产生巨大的商业价值，促使企业投入精力不断地改进它，Hadoop 的易用性、可靠性和性能也不断地提高，然后 Hadoop 占据的市场份额进一步提高，Hadoop 就成功了。
在 Hadoop 成功后，也构建了一套属于自己的周边的技术生态、用户生态和商业生态，形成了强大的“护城河”体系。
Hadoop的生态体系
Hadoop 解决了最核心的问题，但不是所有的问题。比如如何将数据导入导出到 Hadoop 中、如何能以更简单的方式使用 Hadoop、如何处理实时的数据以及如何以更廉价高效的方式存储数据等等。围绕着这些问题，开源爱好者和企业构建一整套的技术框架，从而形成了 Hadoop 的技术生态，而这些技术生态的诞生促使了更多的用户依赖于 Hadoop，越来越多的用户和相应的需求（不是所有企业技术都很强）让这些开源技术有了变现的价值，也就有了一系列的以这些技术为核心的商业公司。
前文提过原生的 Hadoop 特别难用，为了统计某个文本的数量，要写很多行的代码去实现 Map 函数和 Reduce 函数。这在一定程度上限制了 Hadoop 的发展，毕竟不是每一个企业都有着很庞大的程序员团队。第一个解决着这问题的是 Facebook 公司，它给出的方案就是大名鼎鼎的 Hive。虽说初期的 Hive 代码写的特别烂，但扛不住使用简单啊。复杂的代码变成了简单的 SQL 语句，谁不喜欢？使用 SQL 在某种程度上也意味着 Hadoop 不再局限于程序员的小圈子里了，而是能推广到数据分析师乃至财务分析人员，只要会两句简单的 SQL 就能玩转大数据。因此，Hive 实现了和 Hadoop 同样的成功，成为了大数据领域里不可替代的产品。后续所有的 SQL-on-Hadoop 项目都不得不兼容 Hive 语法。
类似的产品还有 Kafka。Kafka 不像 Hive 发展到后期，因为其设计上的缺陷导致 Hive 慢的问题迟迟无法解决，Presto、Impala 这类交互式查询类的产品开始侵占 Hive 的市场空间，Kafka 在 Hadoop 体系里基本上没有什么替代品，只要牵扯到实时数据的传输和交换，唯一的选择就只有 Kafka 一个。属于天时（Kafka 出现的时候，还没有分布式的实时数据传输产品）、地利（来自于领英这样的大公司，并且设计理念超前）、人和（后续 Kafka 的开发者们及时创建了公司，从而有了稳定的研发和更新团队）三者兼备的产品。当然，随着 Hadoop 的成长和 Hive 、Kafka 这一类的周边产品越来越多，Hadoop 的“护城河”体系也就愈发坚不可摧。
Spark的故事
Spark 诞生于加州大学伯克利学院的 AMP 实验室，与大多数开源软件来自于工业界不一样，Spark 是来自于学术界的产品。Spark 吸收了数据库领域和 MapReduce 的精华，并同时抛弃了两者的缺点，算是从零开始构建了一款大数据计算引擎。在某种意义上来说，Spark 的诞生提醒了人们，大数据分析和处理领域不仅仅只能有 MapReduce 一种方式，传统的关系型数据库领域里好的东西也可以借鉴进来，大数据计算引擎迎来了百花齐放、百家争鸣的年代，Impala、Presto、Flink 等产品喷涌而出。
Spark 算是技术和商业结合的最好的一款产品了。首先，Spark 在与 MapReduce 的竞争中，没有纠结于 Spark 本身的设计理念相比于 MapReduce 是多么的优秀，而是关注于当时 MapReduce 难以解决的机器学习的问题。原生的 MapReduce 因为其设计理念的问题，导致像机器学习这种需要很多数据迭代的情况，处理起来相当麻烦，而 Spark 通过 DAG （有向无环图）的设计解决了这个问题，吸引了一大波人，就算是完成产品的冷启动了。其次，Spark 开发者们的眼光非常独特，比如Spark Streaming、Dataframe 这种拳头产品层出不穷，解决了很多痛点问题，极大地扩展了 Spark 的应用场景，并形成了和 Hadoop 一样的生态体系。最后就是Spark 开发者们及时成立了公司，让 Spark 有了稳定的研发团队。
可以这么说，在后 Hadoop 时代，MapReduce 基本上已经被 Spark 所取代了。这种取代可以认为是一款开源产品，光有社区的热情的是不够的，要想持续下去还得需要商业公司的推动，并依赖这款产品产生足够的利益。
NoSQL的崛起和关系型数据库的黯然
聊到 NoSQL 数据库，绕不出去的两篇论文是Google的 BigTable 和亚马逊的 Dynamo。BigTable 和 Dynamo 很像，都是键值存储系统，有着良好的可扩展性和大数据量下的优秀的查询性能，并且在架构设计上都是颠覆性的：简单来说，BigTable 的数据存储模型是基于排序做的，Dynamo 是基于哈希实现的。两者的架构给当时的互联网圈子带来的震撼是相当大的，人们发现，原来数据库还可以这么玩！
NoSQL 诞生的意义不同于 Hadoop ，Hadoop 由于自身的设计哲学，在大规模数据的分析和处理（OLAP）上特别擅长，但是对于追求并发、对时延特别敏感的商业交易型查询（OLTP）上几乎一无建树。在商业交易型查询领域，传统的关系型数据库依然占据着几乎所有的份额。BigTable 意义就在于撼动了关系型数据库在商业交易型查询领域的份额。
以 BigTable 和 Dynamo 为首的 NoSQL 运动轰轰烈烈开始了，互联网的技术领域出现了各式各样的如何用 NoSQL 数据库解决之前关系型数据库无法解决的问题的文章，仿佛 NoSQL 就是“万能解药”。
NoSQL 的问题
随着开发者使用 NoSQL 的时间长了，他们渐渐的发现 NoSQL 有着很多缺陷。每一种 NoSQL 数据库都有着自己独特的查询方式，这意味着开发者需要学习更多的语言；应用程序连接每一种 NoSQL 数据库都会使用到各种不同的代码；大部分 NoSQL 数据的生态圈都不完善，需要开发者自己去构建相应的数据处理工具或者是可视化工具。
除此以外，大部分 NoSQL 数据库都不支持各种复杂数据操作，比如传统关系型数据库发展了很久的 Join （连接两张表）技术，NoSQL 数据库是不支持的，如果想实现复杂的数据操作就必须让应用层去处理这些逻辑，而不是交由数据库完成。这大大的加重了程序员的负担。
有些 NoSQL 数据库已经想明白了 SQL 的重要性，试图在此之上添加类似 SQL 的语法，比如 Cassandra 的 CQL 和 ElasticSearch 的 EQL ，但是相对于传统关系型数据库的 SQL 语言，它们是不完整的，功能也相当有限。
越来越多的程序员不满于 NoSQL 的这些缺陷，并试图找到 SQL 和 NoSQL 之间的一个完美平衡。幸运的是，他们找到了，这就是 NewSQL。
NewSQL的崛起
NewSQL 作为新的数据库不仅仅拥有着 NoSQL 良好的扩展性，而且也拥有着 SQL 这样的语言特性和像关系型数据库一样支持事务。在2008年，Brown，MIT，CMU联合开发出的 H-Store 是第一个支持事务性分析的分布式数据库，随之而来Google开发出了 Spanner ，Spanner 是第一款支持全球性事务的事务性分析数据库，其理念影响了 TiDB，CockroachDB 等开源数据库。自此以后，关系型数据库插上了分布式的翅膀。
作为一款新种类的数据库，NewSQL 选择了兼容传统关系型数据库的语言，比如 TiDB 支持 MySQL 协议，CockroachDB 支持 PostgreSQL 协议。这样选择的好处在于可以以一种尽量少的代价去替换原有的关系型数据库，而不是像 NoSQL 那样激进。NewSQL 数据库因为天生带着分布式的特性，所以也是和云计算结合最紧密的数据库。
至于 NewSQL 发展起来的原因，可以引用Spanner 论文的一段话，我觉得它很好地诠释了为什么Google开启了 NoSQL 时代，却又回归了关系型数据库和 SQL 的怀抱。
