前言
在写这篇文章之前，断断续续地写过一些大数据组件的历史和它的一些评价，但是感觉不过瘾，历史本来就应该是连续的、有其内在的规律，便想写一篇文章总结大数据技术发展的历史，梳理其脉络，并试图找出其内在的规律，分享给大家。
在国内的大数据社区，大部分开发人员都专注于某一个技术怎么使用，再深入一点，便是这个技术的架构剖析之类的，至于这个技术怎么诞生的，是为了解决什么问题，几乎没有人关心。在某种意义上这种趋势也是对的，毕竟大部分公司内的大部分工程师更多的是完成某项工作，再精细点就是更好地完成某项工作，对应到技术的学习就是技术的使用及其架构的学习。但我认为这是远远不够的，因为某项技术的诞生必然是碰上了什么问题，才会有开发人员想去研究和创造这项技术。
除此以外，技术的发展也不一定是一开始就是选择了正确的方向，而是经过不断的市场竞争和淘汰才在历史中留下了名字。留下名字的技术毕竟只是少数，大部分都淹没在历史的尘埃里了。
闲话少叙，让我们回到大数据技术诞生之初，同样也是计算机之初的“田园时光”。
没有大数据之前
现在回想起来计算机发展初期，那应该是一个美好的时代。彼时的程序员还没被称为“码农”，依然是“科学家”，是科技发展的最前沿。正如很多古代的中国哲学家向往“田园时代”一样，程序员有时也会幻想着回到那个时代，手撸一个操作系统或者是数据库，亦或是对着TCP/IP协议，手写一个实现。对于程序员个人而言，能够写一个数据库、操作系统或者是编程语言，自然是非常美妙的一件事，但是对于整个技术发展却是一件非常痛苦的事。想一想，如果每个程序员都在想着造数据库、操作系统或者是编程语言，这些系统和组件从功能上来说基本上都是一样的，比如数据库的核心功能就是为了存储和搜索数据，无论是做的多么花里胡哨，数据库依然是为了存储和搜索数据，所以对于整个技术发展趋势而言，数据库、操作系统或者是编程这些类型的系统和组件造一遍就好了，然后大家基于这些已经造好的轮子再进行二次开发就好。
不过现在回望历史，若是没有这样一群人，个人计算机也很难发展起来。就像《计算机简史》所说：个人计算机的发展就是属于“怪才的成就--年轻的业余技术爱好者以他们的执着追求和技术才智，完成了所谓专家认为的不可能之事”。我们也不能因为现在的程序员沦为了“码农”，而忽略了当年程序员的惊才絶艳。
“田园”时代
若是从图灵或者是冯若依曼开始聊大数据，那就有点太远了，那还不如直接把标题改为《计算机发展简史》比较好，所以要追述大数据历史还是从个人计算机的发展开始。
在个人计算机刚开始诞生的时候，什么都没有，所拥有的就只有一台机器而已，要想这台机器完成某些功能就必须得自己编程，比如第一台个人计算机“牵牛星 8800”。不过当时能买个人计算机回家的，十有八九都是技术的狂热爱好者，毕竟还没有编程语言、没有数据库，更没有操作系统，有的只是一个输入二进制编码的按钮。
那时的每个程序员都得从零开始，面对最底层的硬件，使用着最原始的手段完成自己小小的爱好。比尔盖茨花了六个礼拜时间写出了 BASIC 编程语言，Eric Schmidt 捣鼓出了 Lex ，Linus Torvalds 在大二就完成了微型操作系统 Linux ，还有小型数据库 dBase。对于程序员而言，能自己写出某一个编程语言、操作系统和数据库，成就感是巨大的，但是个人计算机要发展成每一个普通消费者都能用的个人计算机，就必须要有一个大家公认的组件，把底层的、复杂的、抽象的二进制编码变成一个简单的使用方式。
当然再加上商业利益的推动和市场竞争的搏杀，最终构建了编程语言、操作系统和数据库的生态系统，程序员们不再需要从零开始写代码。其实这也是正常的，计算机领域发展的一个趋势就是层层抽象，专业的事交给专业的工具去干。比如编译器提供了编程语言给使用者，让使用者不用关心汇编语言乃至二进制编码；操作系统提供了各种系统接口，让使用者不再直面底层驱动和复杂的硬件环境；数据库提供了SQL语言，让使用者无需关心数据处理的具体逻辑。
“田园”时代结束的标志就是编程语言、操作系统和数据库的诞生和流行。回到本篇文章，对于大数据技术的发展而言，这三者缺一不可，但其中最重要的就是数据库的发展，毕竟大数据技术脱胎于数据库，大成于分布式系统，最后又回归了数据库系统。
数据库时代
要说大数据的真正起源，必须得提到数据库。无论是移动互联网还是PC因特网，或者是计算机本身，背后都是一群又一群程序员写的程序，而一切程序说到底都还是对数据的处理。如果把数据处理比作一个王国的话，那这个王国的国王就是数据库。
那什么是数据库呢？用最简单的话来说，就是一个用户可以把数据存储在数据库，需要的时候，用户可以告诉数据库，我需要某些数据，然后数据库会自行完成实际的数据处理过程，返回数据给用户。数据库帮程序员把底层复杂的数据处理过程给屏蔽了，程序员只需要关心数据存储和查询就好。
举个简单的例子，在没有数据库之前，程序员为了处理数据，首先需要自行面对操作系统的底层文件系统，不同的操作系统的文件系统的 API 之类是不一样的，且不论文件系统的复杂度，单纯地面对不同的文件系统，程序员就要针对性的开发。其次还需要考虑存储的数据结构、索引结构、文件格式，甚至还需要考虑并发事务、故障恢复等等情况。这难度值逆天啊。因此，数据库诞生了。
数据库与正常的商业软件一样，第一个吃螃蟹的“前浪”最终倒在了沙滩上。那个时候，关系型模型还被认为是“不靠谱的”，最流行的模型是层次模型和网状模型（感兴趣的读者可以上网搜下这两个模型）。经历过激烈的市场竞争和工程实践，大家最后发现关系型模型才是适用于大部分环境的数据库模型。关系型数据库确立了市场垄断地位。
一旦某一个基础软件确立了其垄断地位，然后再围绕其构建庞大的生态系统，那么后来者即使做出了相似的产品，垄断软件的生态系统一样会扼杀掉后来者，除非另辟赛道或者是先行者解决不了某类问题。数据库也是如此，Oracle、DB2等数据库占据了金融、电信等传统企业的大部分份额便可说明这个情况。
回到数据库本身，第一款真正意义上的关系型数据库应该是 IBM 研究院的 SystemR。研究院出来的东西大多都比较“曲高和寡”，没有考虑到大多数人的实际使用感受，比如System R使用的查询语言更像是数学家的玩物，而不是工程师的杰作。上网随便找了张截图，如下：
反正我是看不懂，读者看了这个估计也会比较迷糊，这都是什么玩意？但是不可否认的是，这确实是第一款数据库，相比于之前的状况要好的太多，毕竟只要学会查询语言的语法，就能处理数据了。毕竟没有数据库的时候，还要处理很多复杂的情况，这可比这数学式的查询语言难多了。
System R就像“前浪”，帮大家把路躺平了，证明了关系型模型优于其它的数据库模型，并且在商业上更优异。于是大家一窝蜂而上，Oracle、DB2等等随之登场，各领风骚。此时一门伟大的语言也诞生了，那就是 SQL 。SQL，全称是结构化查询语言，它在某种程度上，SQL 才是数据领域内的“唯一”的统一语言，就像我们国家，虽然各地都有着不同的方言，但是普通话才是全国通用语言，大家都听得懂。SQL亦是如此。
在此，我们要感谢 SQL 的两个发明者 Donald Chamberlin 和 Raymond Boyce 。
SQL 的理论基础就是关系代数。本文不是技术向的科普文，感兴趣的读者可以自行了解下关系代数的理论。SQL 区别于其它语言的一个很重要的特点是它是“声明式”的语言。简单来说，所谓声明式就是使用者只需要告诉计算机他想做什么，剩下的都交给计算机实现。与声明式对应的是命令式语言，命令式语言会告诉计算机它应该按什么步骤实现什么，计算机亦步亦趋即可。大部分编程语言，比如 Java、Python 这些编程语言都是命令式的语言。相比于声明式语言，命令式语言的学习难度更大、更陡峭，这也意味着使用人数很难扩大。因此大家会更喜欢声明式语言。
much of the success of the computer industry depends on developing a class of users other than trained computer specialists.
其实声明式语言和命令式语言的背后，在某种程度上也是 Unix 哲学和数据库哲学两种哲学的观念争斗。Unix 哲学致力于提供简单的工具给使用者，剩下的实现过程则交给使用者，而数据库哲学不一样，它觉得使用者只需要告诉它要做什么就好，实现过程我帮你完成。Unix 哲学相信使用者的能力，而数据库哲学不相信使用者的能力。孰优孰劣，那就看读者自己的判断力了。
数据库作为基础软件，在证明了其能力后，配合 SQL 迎来了它的辉煌时代。那个时候，无论是什么公司，只要你使用信息技术提供商业服务，那就离不开数据库。因为一切应用程序的本质都是在处理数据。
就在数据库的辉煌年代里，一群加利福利亚的年轻人把互联网发明出来了。当时谁也没想到，看似无坚不摧的数据库会被名不见经传的互联网所撼动。
一个崭新的时代即将到来。
Hadoop 时代
揭幕大数据时代
其实大数据这个词很早就出现了，在1983年阿尔温托夫勒写的《第三次浪潮》里就提到过大数据了，并且论断：大数据将是第三次浪潮中的华彩乐章。当然，那个年代大数据就像襁褓中的婴儿距离它改变世界还有很长的路要走，直到有技术有能力处理大规模数据，大数据在这一刻才真正的成为我们口中所说的“大数据”。
让我们回到历史中，上篇提到了互联网时代的到来。互联网，无论是PC互联网还是移动互联网，亦或是以后的物联网，给数据库带来的最大挑战就是数据量：越来越多的数据，多到单机已经无法存储和处理，无论单机的性能有多么强悍，庞大的数据总会吞噬掉其剩余性能。在某种程度上来说，在大数据技术诞生之前，越来越多的数据都是垃圾。是的，无法处理的数据就是一堆垃圾，毕竟高端服务器价格可不便宜。
第一个解决这问题的公司，叫做谷歌。可惜的是，那个时候谷歌没有开源其技术，仅仅只是发表了三篇技术论文，这三篇论文在大数据领域被戏称为“三驾马车”，分别是谷歌文件系统 GFS、MapReduce 和 BigTable。GFS 解决了数据大规模存储的问题，让数据可以几乎无限的增长下去；MapReduce 解决了数据大规模计算的问题，让大规模数据处理成为可能；BigTable 解决了在线实时查询的问题，即使数据量很大，用户也能很快的查询到数据。
在这三篇文章中，最为核心的，或者说最有价值的文章莫过于 GFS 了，因为大数据只有可靠的存储下来，才能谈得上后续的数据处理和查询，所以 GFS 的开源实现 HDFS 依然是大数据领域里的唯一标准。虽然 GFS 很重要，但是在二十一世纪初，MapReduce 才是声音最大，引发争论最多的文章。期间，数据库领域的大牛 David J. DeWitt 和 Michael Stonebraker 写了大名鼎鼎的MapReduce: A major step backwards，指责 MapReduce 放弃了数据库领域辛辛苦苦积累下来的理论精华，而是选择了一种简单粗暴的方式处理数据，岂有此理。关于MapReduce: A major step backwards ，互联网上的解析和评论非常多，本文不再详述，读者可以自行判断。
此时，一切都还是论文，没有落地的产品，直到 Hadoop 出现了。
Hadoop 诞生
前文提到了谷歌仅仅只是发表了论文，而没有开源实现。所以回过头来看，只能说谷歌揭开了大数据时代的帷幕，但是却没有享受到大数据时代带来的巨大红利，可惜可叹。第一个在谷歌之外实现“三驾马车的”公司，也就是第一个吃螃蟹，是雅虎。雅虎当时在学着谷歌做搜索行业，也面临着谷歌一样的问题，互联网上的数据很大、很多，怎么处理它就变成了一个难题。于是雅虎模仿着谷歌的论文弄出了Hadoop，并且以实际的线上业务去测试和完善Hadoop。不得不说，雅虎非常有勇气，要是 Hadoop 出了什么问题，雅虎损失的可是实打实的真金白银。最后，值得敬佩的是，雅虎做了一回“活雷锋”，把 Hadoop 开源了。
一家公司把某个软件开源，特别是大公司把自己内部的核心产品开源，在某种意义上就是通过技术领先优势，抢占市场份额，从而获得制定标准的权利。只有把标准的制定权掌握在手里，一家公司才能尽可能从这个产品和产品对应的市场中获得更大的利益。然而雅虎把 Hadoop 开源了，却没有持续的维护和掌控，导致 Hadoop 成就了 Apache 基金会，而不是雅虎自己。
没有 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 中、如何能以更简单的方式使用 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 的“护城河”体系也就愈发坚不可摧。
后 Hadoop 时代
没有一款产品是永远处在繁荣状态，Hadoop 也一样。
Spark 的故事
在 Hadoop 时代，MapReduce 就饱受着来自传统关系型数据库领域的争议。相比于数据库领域从二十世纪发展到二十一世纪，经历过几十年的理论和技术沉淀，MapReduce 有太多值得说的缺点了。这一场的争议以MapReduce: A major step backwards开始，以 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 所取代了。这种取代可以认为是一款开源产品，光有社区的热情的是不够的，要想持续下去还得需要商业公司的推动，并依赖这款产品产生足够的利益。
开源产品的商业化
Spark 就是一个很好的开源产品商业化的例子。在大数据技术发展的初期，一款开源产品可以凭借着其独特的设计和解决了某一类的痛点问题而发展起来，但是发展起来之后，如何保证产品的不断迭代和更新就成了一个问题？一时的热情终究是不长久的，那么开源产品的商业化就不可避免了。这也是为什么现在的非常流行的开源产品背后都有一家商业公司的原因。
一般来说，如果这款开源产品是某家商业公司研发，并且在公司内部得到了大力的支持，有着稳定的团队维护，那么这款产品就不需要单独成立公司去维护。除了这种情况外，还有一种就是为这款开源产品单独成立一家公司，公司的产品就是这款开源产品，比如 Spark 和Databricks，Kafka 和 Confluent。当然，随着 Hadoop 的发展，Hadoop 也拥有了自己的商业集成商 Cloudera、hortonworks和MapR 。
开启云计算的大门
Hadoop 的诞生的意义不仅仅在于企业拥有了处理数据的能力，更大的意义在于 Hadoop 开启了云计算的大门。什么是云计算呢？
云计算（英语：cloud computing），是一种基于互联网的计算方式，通过这种方式，共享的软硬件资源和信息可以按需求提供给计算机各种终端和其他设备，使用服务商提供的电脑基建作计算和资源。
这是来自维基百科对云计算的定义，从定义中我们可以注意到云计算的很重要的一点就是分布式计算，而分布式计算最重要的技术就来源于 Hadoop 。前面提到过，Hadoop 给分布式计算带来了可靠性和容错性，除此以外，随着 Hadoop 的成熟和 Yarn 的出现，大家发现要完整的运行谷歌的论文里提到的 MapReduce 就必须要有容器化的技术去管理计算机资源，这里的资源包括但不限于CPU、内存等。在2015年，以 Docker 为代表的容器化的技术解决了云计算资源分配的“最后一公里”问题。
MapReduce 的论文实际上解决了云计算发展的所有问题，在某种意义上开启了云计算的大门。可惜的是，谷歌却不是云计算服务，甚至是 Hadoop 的最大获益者。将云计算真正落地，并且从 Hadoop 中攫取了最大的商业利益的是亚马逊/AWS，相比于Hadoop集成商 Cloudera 上市时的市值，亚马逊/AWS 的价值可高多了。
有趣的是，中美两国的云计算领导者都是电商公司（阿里和亚马逊）。云计算，或者是说分布式计算的思想影响了互联网公司的发展，但是云计算生意似乎与互联网公司的基因格格不入。互联网公司发展的一个常见模式是通过产品免费等策略抢占市场，获得尽可能多的用户，最后基于这些用户，从广告商等第三方企业赚钱。在互联网公司看来，用户是产品，是一个个的数据，而云计算却是一门生意，用户是买单方，云计算要服务用户。可能这就是谷歌奠定了云计算的技术基础，而亚马逊成为了云计算领域的领头羊的原因吧。
重回数据库时代
Hadoop 开启大数据时代后，传统的关系型数据库就从时代舞台的中心退居了幕后。等到非关系型数据库的诞生后，人们甚至更激进地提出了“NoSQL”运动，试图抛弃 SQL 及其关系型数据库，但是随着大数据热潮的褪去，非关系型数据库的缺陷渐渐为人所知，人们开始重新审视关系型数据库，并认为“NoSQL”其实是“Not Only SQL”，而不是“No SQL”。
历史上每一次的狂热过后，不仅仅会留下一地鸡毛，同样地也会给世界带来新的东西，带来新的变化。大数据也不例外，它给关系型数据库插上了分布式的翅膀，关系型数据库也和 Hadoop 一样拥有了可扩展的能力，并且还保持着其自身的特性。现在我们就来回顾下这段历史吧。
NoSQL的崛起和关系型数据库的黯然
前面都是在围绕着 Hadoop 去聊大数据技术的发展，但是谷歌在二十一世纪初是发表了三篇论文，谷歌文件系统 GFS 和 MapReduce 奠定了 Hadoop 的基础，BigTable 则开启了大数据技术的另一分支 NoSQL （非关系型）数据库。
聊到 NoSQL 数据库，绕不出去的两篇论文是谷歌的 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 是第一个支持事务性分析的分布式数据库，随之而来的谷歌开发出了 Spanner ，Spanner 是第一款支持全球性事务的事务性分析数据库，其理念影响了 TiDB，CockroachDB 等开源数据库。自此以后，关系型数据库插上了分布式的翅膀。
作为一款新种类的数据库，NewSQL 选择了兼容传统关系型数据库的语言，比如 TiDB 支持 MySQL 协议，CockroachDB 支持 PostgreSQL 协议。这样选择的好处在于可以以一种尽量少的代价去替换原有的关系型数据库，而不是像 NoSQL 那样激进。NewSQL 数据库因为天生带着分布式的特性，所以也是和云计算结合最紧密的数据库。
至于 NewSQL 发展起来的原因，可以引用谷歌 Spanner 论文的一段话，我觉得它很好地诠释了为什么谷歌开启了 NoSQL 时代，却又回归了关系型数据库和 SQL 的怀抱。
While these systems provided some of the benefits of a database system, they lacked many traditional database features that application developers often rely on. A key example is a robust query language, meaning that developers had to write complex code to process and aggregate the data in their applications. As a result, we decided to turn Spanner into a full featured SQL system, with query execution tightly integrated with the other architectural features of Spanner (such as strong consistency and global replication).
结语
大数据技术的发展是就像历史上大多数技术发展史一样：从大数据技术刚开始诞生时，世人对其的惊艳，到大数据技术成熟后带来的狂热，无论什么东西都要用大数据技术实现一遍，再到大数据技术进入了缓慢的成长期，到最后带动了人工智能、新型分布式关系型数据库的革命，进入了下一个纪元，大数据技术本身变成了普惠的基础设施。
未来大数据技术会走向何方，谁又能真正知道呢？就像谷歌发表那三篇关于大数据的论文时，谁又能在当时真正知道这三篇论文影响会如此深远，以至于改变了整个世界？对于我这样一个普通的开发者，所能做的就是写一篇文章回顾那波澜壮阔的大数据技术发展历史。
后记
虽然本文没有牵扯到对未来的推测，但是只有明白了历史，才能知道未来，这也是我写下这篇文章的原因：回顾大数据技术的发展历史，才能更好地寻找下一个技术风口，并发现下一个历史大势，然后顺势而为，把握时代的脉搏，在此之后才能谈得上“个人的奋斗”。
