大数据相关技术的核心理念与历史发展

大数据经典论文阅读梳理【第一期】

大家好，我是IT一氪的作者凌天，我是一名入门快两年的大数据开发工程师。
我之前是一名Java开发，大学毕业后转岗到大数据开发，在这快两年的时间里，我学习并使用了不少大数据组件，成为了一名合格的API调用开发工程师，足以应对工作中的大部分需求。
当我开始回顾从转岗到现在，除了被996榨干并发福的身体，其他大数据知识并没多少，简单来说就是，就是什么都能聊上两句，但什么都只能聊那两句。
为了能多聊上几句，我决定进行正本清原，梳理大数据技术的核心理念与历史发展，阅读Google在大数据领域经典的三篇论文，此专栏记录我对这些论文的阅读梳理。
第一期先来梳理大数据相关技术的核心理念与历史发展，之后再进入相关论文的阅读。

一、大数据技术的核心理念

什么是大数据技术？
随着互联网科技的发展，全球数据量呈爆炸式增长，传统的数据处理软件不足以应对这么大量、这么复杂的数据，这时为了解决这些问题新出现的能够应对处理海量、复杂的数据，就称之为大数据技术。

那么我认为大数据技术的关键核心理念就有以下两点：
1、能利用廉价服务器搭建的可伸缩的分布式存储与计算的集群技术
在大数据理念出来之前，传统的数据库技术已经在尝试处理海量数据，这些数据库单个集群往往只能达到几十台服务器。而在Google发布了《Google File System》后，我们才第一次看到单个集群可存在数千台服务器。集群规模上去了，也就把数据存储与计算的能力提高了一个新台阶，让我们能够处理TB、PB级别的数据存储计算。
大数据技术想要得到广泛的应用，就不能使用向神威、银河那样的超算，也不能使用那些昂贵、专属的硬件，必须上基于中小公司能使用的起的普通的廉价的服务器。
2、大数据集群要能当作一台计算机使用
大数据技术的目标是实现开发者把集群当作一台“虚拟计算机”使用，开发者不必操心系统的可用性、数据一致性等问题。

	传统技术	大数据技术	解决的问题
集群规模	至多几十台服务器	成百上千，上万台	集群服务器规模数量级上的道理一个提升
服务器硬件类型	专用硬件：大型机、小型机 专用设备：RAID磁盘阵列	廉洁的pc、服务器普通的硬盘，无需RAID	降低了硬件成本
开发	自己处理分布式、容错等	当作是一台计算机使用	降低开发的复杂性

二、大数据技术的来龙去脉

需求起源

大数据领域的蓬勃发展，都来源自于Google的真实需求，Google作为一个搜索引擎，在数据层面需要抓取所有网站的网页数据存储下来。
目前我们所用到的大数据技术，大部分都是来自于Google公开发表的论文，然后再演变为一个一个的开源系统。可以说，Google是大数据领域的火种散播者。

三架马车

面对存储、计算、在线服务这三个需求，Google先后在2003、2004、2006年发布了《Google File System》、《Google Mapreduce》、《Goolgle Bigtable》三篇论文，这三篇论文奠定了后来大数据技术发展的基础。

《Google File System》主要解决数据的存储问题，作为一个上千节点的分布式文件系统，Google能够轻易将所有的数据存储下来。
数据存储下来后，为了发挥数据的价值，就需要基于这些数据进行各种各样的计算，于是《Google Mapreduce》就出场了，通过借鉴Lisp，Google利用简单的Map和Reduce两个函数对海量数据计算做了一个抽象，让处理数据的人不再需要深入掌握分布式系统的开发。
GFS存储数据，MapReduce处理数据，因为所有的数据都是顺序读写，系统的吞吐量都没问题，但是这样就没有办法解决好随机读写问题。面对这个问题，《Goolgle Bigtable》就站了出来，它直接使用GFS作为底层存储，来做好集群的分片调度，以及利用MemTable+SSTable的底层存储格式，来解决大数据、机械硬盘下的高性能随机读写问题。

思考1：怎么保障数据一致性？
思考2: 数据如何序列化，分布式系统直接如何通信？

三、MapReduce与Bigtable的进化

MapReduce的进化

MapReduce作为计算引擎，它朝着下面的方式进化
1、编程模型上的进化
MapReduce的编程模型需要程序员去写程序，它的进化方向是通过一门DSL降低写MapReduce的门槛。
虽然Google发表了Sawzall，Yahoo发布了Pig，但是在这个领域第一阶段胜出的是2009年Facebook发布的Hive。Hive通过和SQL差不多的HQL降低了数据处理门槛，只需要通过简单的HQL就能实现MapReduce功能。
2、执行引擎上的优化
Hive虽然披上了SQL的皮，但它底层仍然是一个个MapReduce任务，每一次进行Map与Reduce都存在着大量读写磁盘操作，延时很高，不能直接作为一个交互式系统给数据分析师使用。于是Google在2010年发表交互式查询引擎Dremel的论文，它采用数据列存储+并行数据库的方式提高查询速率，这样Dremel不仅有了SQL的皮，还进一步把MapReduce这个执行引擎给换掉了。
3、多轮迭代问题优化
MapReduce模型上，一次MapReduce操作就要读写一次硬盘，Map与Reduce之间的数据通信，也是要落地到硬盘上的。这样即使上简单的HQL也会浪费很多硬盘读写。
于是2010年MateiZaharis就发表了Spark论文，通过将数据放在内存进行操作，大大提升了分布式数据计算能力。

Hive、Dremel 和 Spark 分别从“更容易写程序”“查询响应更快”“更快的单轮和多轮迭代”的角度,完成了对 MapReduce 的进化。

Bigtable的进化

Bigtable作为一个在线服务数据库，进化路线上这样的：
1、事物问题和Schema问题
Google在2011年发表了Megastore论文，在 Bigtable 之上，实现了类 SQL 的接口，提供了 Schema，以及简单的跨行事务。如果说 Bigtable 为了伸缩性，放弃了关系型数据库的种种特性。那么 Megastore 就是开始在 Bigtable 上逐步弥补关系型数据库的特性。
2、异地多活和数据中心问题
Google在2012年发表Spanner，就能做到全局一致性了。

MapReduce进化是在不断优化 OLAP 类型的数据处理性能
Bigtable的进化是在保障伸缩性的前提下,获得了更多的关系型数据库的能力

四、实时数据处理的进化

从MapReduce到Dremel，查询数据响应时间大大缩短了，但是计算的数据是需要预先计算好的，这样系统查询往往有着大到数小时、小到分钟到数据延时。为了解决好这个文通，流式数据处理就走上了舞台。

• Yahoo在2010年发表了S4论文，并在2011年开源了S4；
• 与此同时，Nathan Marz开源了Storm，并在很长一段时间成为了业界标准，Storm还支持“At Least Once”（至少一次）的数据处理。Nathan Marz还基于Storm和MapReduce提出了最早的**“流批协同”处理架构（也称Lambda架构）；**
• 2011年Jay Krepson发表Kafka论文，可以做到“Exactly Once”（正好一次），为了解决Storm上的数据重复消费问题，于是大家纷纷开始转向Kafka。Kafka也逐步进化出了Kafka Streams这样的事实数据处理方案。2014年Jay Krepson提出第最早的**“流批一体”处理架构（Kappa架构）**；
• 2015年Google发表了DataFlow模型，对流式数据处理模型做了总结和抽象，而后开源的Flink和Beam都是完全按照DataFlow模型实现的

本期就讲到这里，下一期将会对第一架马车《Google File System》论文进行分享
公众号(IT一氪)回复“三架马车”即可获取这三篇论文中文版