文章简介
本文章主要是针对极客时间专栏《大数据经典论文解读》中开篇的大数据生态演化介绍文章的整理笔记，方便记忆一些基础知识。
大数据技术的核心理念
“大数据”技术的核心理念是非常清晰的，基本上可以被三个核心技术理念概括：
- 能够伸缩到一千台服务器以上的分布式数据处理集群的技术；
- 这上千个节点的集群是采用廉价的 PC 架构搭建起来的；
- 把数据中心当作是一台计算机。
如下图所示：
分别对应着服务器规模、服务器架构、编程模型三个层面的要求。
三驾马车和基础设施
作为一个搜索引擎，Google 在数据层面，面临着比任何一个互联网公司都更大的挑战，因为其它公司都只需要存储自己网站相关的数据，而 Google 则需要抓取所有网站的网页数据并存下来，存下来后还需要针对网页数据进行深度挖掘，不断迭代计算，同时针对不断增长的搜索请求，还需要有响应迅速的在线服务。 因此，在面对存储、计算和在线服务的三类需求时，Google 分别在 2003、2004 以及 2006 年抛出了三篇重磅论文，GFS、MapReduce 和 BigTable。 值得一说的是，GFS 和 MapReduce 处理的都是数据顺序读写问题，两者都没有办法解决好数据的高性能随机读写问题，而 BigTable 是直接使用 GFS 作为底层存储，来做好集群的分片调度，以及利用 MemTable + SSTable 的底层存储格式，来解决大集群、机械硬盘下的高性能的随机读写问题。 三者的技术优缺点介绍如下：
三篇论文其实还依赖了两个基础设施：
- 分布式锁，解决数据一致性问题，2006 年 Google 发表了实现了 Paxos 算法的 Chubby 分布式锁服务的论文；
- 数据序列化以及分布式系统通信问题，可以参考 Facebook 在 2007 年发表的 Thrift 的相关论文。 简介如下：
OLAP 和 OLTP 数据库
三驾马车给整个业界带来了火种，但整个大数据领域的进化才刚刚开始。在那个时候，它们都还是很粗糙的系统设计。 先说 MapReduce。 首先是编程模型，MapReduce 作为一个“计算”引擎，其编程模型需要工程师去写程序，上手门槛比较高，且效率低下，它的进化方向是通过一门 DSL，进一步降低门槛。Google 当时发表了 Sawzall(2003年)，Yahoo 实现了 Pig(2006年)，但最终胜出的是 Facebook 在 2009 年发表的 Hive，其通过一门基本上和 SQL 差不多的 HQL，大幅降低了数据处理的门槛，从而成为了大数据数据仓库的事实标准。 其次是执行引擎，Hive 虽然披上了一个 SQL 的皮，但底层仍然是一个个 MapReduce 任务，延时很高，没法作为一个交互式系统给数据分析师用。于是 Google 在 2010 年，发表了 Dremel 交互式查询引擎的论文，采用数据列存储 + 并行数据库的方式，这样 Dremel 不仅有了 SQL 皮，还把 MapReduce 执行引擎替换了。 最后是 多轮迭代问题， 在 MapReduce 模型里，一个 MapReduce 就要读写一次硬盘，而且 Map 和 Reduce 之间的数据通信也是先要落到磁盘上，这样导致稍微复杂一点的 Hive SQL，或者需要进行多次迭代的机器学习算法，都会浪费很多磁盘读写，效率比较慢。于是，2010 年来自 Berkeley 的博士生发表了 Spark 论文，通过把数据放在内存而不是硬盘，大幅提升了分布式数据计算性能。 总结来说，围绕 MapReduce 的问题，Hive、Dremel 和 Spark 分别从“更容易写程序”、“查询响应更快“、”更快的单轮和多轮迭代“的角度，完成了对 MapReduce 的彻底进化。 再说 BigTable。
- 首先是事务问题和 Schema 问题， Google 在 2011 年发表了 Megastore 的论文，在 BigTable 之上实现了类 SQL 的接口，提供了 Schema 和简单的跨行事务。如果说 BigTable 为了伸缩性，放弃了关系型数据库的种种特性，那么 Megastore 就是开始在 BigTable 上逐步弥补关系型数据库的特性。
- 其次是异地多活和跨数据中心问题，Google 在 2012 年发表了 Spanner，能够做到全局一致性。这样就算基本解决了这两个问题，第一次让我们有一个”全球数据库“。
用一张图来总结：
实时数据处理的抽象进化
以上的数据计算都是固定的、预先确定的数据，这种系统都有大到数小时、小到几分钟的数据延时，所以为了解决好数据时效性问题，流式数据处理走上了舞台。
首先是，Yahoo 在 2010 年发表的 S4 的论文，并在 2011 年将其开源。在同一时间，Twitter 工程师开源了 Storm， 并在很长一段时间成为了工业界的事实标准，但其支持的是”At-Least-Once“数据处理模式，因此存在数据重复问题。另外，Storm 作者提出了 Lambda 架构，是基于 Storm 和 MapReduce 的”流批协同“的大数据处理架构。
接着在 2011 年，Linkedin 发表了 Kafka 的论文。最早的 Kafka 其实只是一个”消息队列“，更像是 Scribe 数据传输组件的替代品，但由于 Kafka 发送的消息可以做到”Exactly-Once“，所以大家就考虑用它解决 Storm 解决不好的数据重复问题，于是 Kafka 进化出了 Kafka Streams 这样的实时数据处理方案。在 2014 年，Kafka 的作者提出了 Kappa 架构，可以称之为第一代”流批一体“的大数据处理架构。
最后，这里看起来大数据的流式处理似乎没有 Google 什么事，但其实，Google 在 2010 年的 OSDI（Operating Systems Design and Implementation）会议上发表了 FlumeJava，FlumeJava 是一个用于并行处理和数据管道的编程模型和库，旨在简化大规模数据处理任务的开发和执行，在 2013 年 10 月的 VLDB（Very Large Data Bases）会议上正式发表了 MillWheel，其旨在提供一个高可用、可扩展且一致性的流式数据处理解决方案，特别适用于处理来自各种数据源的实时数据流，FlumeJava 和 MillWheel 确实并没有像三驾马车的影响力那么大，但在 2015 年，Google 发表了 Dataflow 的模型，可以说是对于流式数据处理模型做出了最好的总结和抽象，一直到现在，Dataflow 就成为了真正的”流批一体“的大数据处理架构，后来的 Flink 和 Apache Beam，则是完全按照 Dataflow 的模型实现的。
用一张图来概括：
总结上面一系列论文的时间线和脉络联系，可以用一张图来表示：
资源调度
随着数据中心的服务器越来越多，我们对于数据一致性的要求也越来越高，为了解决数据一致性问题，我们有了基于 Paxos 协议的分布式锁，但 Paxos 的性能很差，于是有了更进一步的 Multi-Paxos 协议。但 Paxos 协议并不容易理解，于是就有了更容易理解的 Raft 算法。容器编排系统 Kubernetes 依赖的分布式键值存储系统 etcd 就是用 Raft 协议实现的。 同时，随着服务器越来越多，原有的系统部署方式也越来越浪费。原先我们一般是一个计算集群独占一系列服务器，但很多时候服务器资源都是闲置的，在大规模集群场景，这种浪费是不可承受的。于是，充分利用硬件资源成为了刚需，这样分布式系统由虚拟机转向了容器，这也是 Kubernetes 系统的由来。
