Spark在架构上包括内核部分和4个官方子模块
Spark SQL
Spark Streaming
机器学习库MLlib
图计算库GraphX
由Spark在伯克利的数据分析软件栈BDAS（Berkeley Data Analytics Stack）中的位置可见，Spark专注于数据的计算，而数据的存储在生产环境中往往还是由Hadoop分布式文件系统HDFS承担。
Spark在BDAS中的位置
Spark被设计成支持多场景的通用大数据计算平台，它可以解决大数据计算中的批处理，交互查询及流式计算等核心问题。Spark可以从多数据源的读取数据，并且拥有不断发展的机器学习库和图计算库供开发者使用。数据和计算在Spark内核及Spark的子模块中是打通的，这就意味着Spark内核和子模块之间成为一个整体。Spark的各个子模块以Spark内核为基础，进一步支持更多的计算场景，例如使用Spark SQL读入的数据可以作为机器学习库MLlib的输入。以下列举了一些在Spark平台上的计算场景。
Spark的应用场景举例
之前在大数据概述的课程中我们提到了Hadoop，大数据工程师都非常了解Hadoop MapReduce一个最大的问题是在很多应用场景中速度非常慢，只适合离线的计算任务。这是由于MapReduce需要将任务划分成map和reduce两个阶段，map阶段产生的中间结果要写回磁盘，而在这两个阶段之间需要进行shuffle *** 作。Shuffle *** 作需要从网络中的各个节点进行数据拷贝，使其往往成为最为耗时的步骤，这也是Hadoop MapReduce慢的根本原因之一，大量的时间耗费在网络磁盘IO中而不是用于计算。在一些特定的计算场景中，例如像逻辑回归这样的迭代式的计算，MapReduce的弊端会显得更加明显。
那Spark是如果设计分布式计算的呢？首先我们需要理解Spark中最重要的概念--d性分布数据集（Resilient Distributed Dataset），也就是RDD。
关键词：d性分布数据集RDD
RDD是Spark中对数据和计算的抽象，是Spark中最核心的概念，它表示已被分片（partition），不可变的并能够被并行 *** 作的数据集合。对RDD的 *** 作分为两种transformation和action。Transformation *** 作是通过转换从一个或多个RDD生成新的RDD。Action *** 作是从RDD生成最后的计算结果。在Spark最新的版本中，提供丰富的transformation和action *** 作，比起MapReduce计算模型中仅有的两种 *** 作，会大大简化程序开发的难度。
RDD的生成方式只有两种，一是从数据源读入，另一种就是从其它RDD通过transformation *** 作转换。一个典型的Spark程序就是通过Spark上下文环境（SparkContext）生成一个或多个RDD，在这些RDD上通过一系列的transformation *** 作生成最终的RDD，最后通过调用最终RDD的action方法输出结果。
每个RDD都可以用下面5个特性来表示，其中后两个为可选的：
分片列表（数据块列表）
计算每个分片的函数
对父RDD的依赖列表
对key-value类型的RDD的分片器（Partitioner）（可选）
每个数据分片的预定义地址列表（如HDFS上的数据块的地址）（可选）
虽然Spark是基于内存的计算，但RDD不光可以存储在内存中，根据useDisk、useMemory、useOffHeap, deserialized、replication五个参数的组合Spark提供了12种存储级别，在后面介绍RDD的容错机制时，我们会进一步理解。值得注意的是当StorageLevel设置成OFF_HEAP时，RDD实际被保存到Tachyon中。Tachyon是一个基于内存的分布式文件系统，目前正在快速发展，在这里我们就不做详细介绍啦，可以通过其官方网站进一步了解。
DAG、Stage与任务的生成
Spark的计算发生在RDD的action *** 作，而对action之前的所有transformation，Spark只是记录下RDD生成的轨迹，而不会触发真正的计算。
Spark内核会在需要计算发生的时刻绘制一张关于计算路径的有向无环图，也就是DAG。举个例子，在下图中，从输入中逻辑上生成A和C两个RDD，经过一系列transformation *** 作，逻辑上生成了F，注意，我们说的是逻辑上，因为这时候计算没有发生，Spark内核做的事情只是记录了RDD的生成和依赖关系。当F要进行输出时，也就是F进行了action *** 作，Spark会根据RDD的依赖生成DAG，并从起点开始真正的计算。
逻辑上的计算过程：DAG
有了计算的DAG图，Spark内核下一步的任务就是根据DAG图将计算划分成任务集，也就是Stage，这样可以将任务提交到计算节点进行真正的计算。Spark计算的中间结果默认是保存在内存中的，Spark在划分Stage的时候会充分考虑在分布式计算中可流水线计算（pipeline）的部分来提高计算的效率，而在这个过程中，主要的根据就是RDD的依赖类型。
根据不同的transformation *** 作，RDD的依赖可以分为窄依赖（Narrow Dependency）和宽依赖（Wide Dependency，在代码中为ShuffleDependency）两种类型。窄依赖指的是生成的RDD中每个partition只依赖于父RDD(s) 固定的partition。宽依赖指的是生成的RDD的每一个partition都依赖于父 RDD(s) 所有partition。窄依赖典型的 *** 作有map, filter, union等，宽依赖典型的 *** 作有groupByKey, sortByKey等。可以看到，宽依赖往往意味着shuffle *** 作，这也是Spark划分stage的主要边界。对于窄依赖，Spark会将其尽量划分在同一个stage中，因为它们可以进行流水线计算。
RDD的宽依赖和窄依赖
最后我们再通过下图来详细解释一下Spark中的Stage划分。我们从HDFS中读入数据生成3个不同的RDD，通过一系列transformation *** 作后再将计算结果保存回HDFS。可以看到这幅DAG中只有join *** 作是一个宽依赖，Spark内核会以此为边界将其前后划分成不同的Stage. 同时我们可以注意到，在图中Stage2中，从map到union都是窄依赖，这两步 *** 作可以形成一个流水线 *** 作，通过map *** 作生成的partition可以不用等待整个RDD计算结束，而是继续进行union *** 作，这样大大提高了计算的效率。
Spark中的Stage划分
使用计算机后，随着数据处理量的增长，产生了数据管理技术。
数据管理技术的发展与计算机硬件（主要是外部存储器）系统软件及计算机应用的范围有着密切的联系。
数据管理技术的发展经历了以下四个阶段：人工管理阶段、文件系统阶段、数据库阶段和高级数据库技术阶段。
数据管理的诞生
数据库的历史可以追溯到五十年前，那时的数据管理非常简单。
通过大量的分类、比较和表格绘制的机器运行数百万穿孔卡片来进行数据的处理，其运行结果在纸上打印出来或者制成新的穿孔卡片。
而数据管理就是对所有这些穿孔卡片进行物理的储存和处理。
然而，1950 年雷明顿兰德公司（Remington Rand Inc）的一种叫做Univac I 的计算机推出了一种一秒钟可以输入数百条记录的磁带驱动器，从而引发了数据管理的革命。
1956 年IBM生产出第一个磁盘驱动器—— the Model 305 RAMAC。
此驱动器有50 个盘片，每个盘片直径是2 英尺，可以储存5MB的数据。
使用磁盘最大的好处是可以随机存取数据，而穿孔卡片和磁带只能顺序存取数据。
1951： Univac系统使用磁带和穿孔卡片作为数据存储。
数据库系统的萌芽出现于二十世纪60 年代。
当时计算机开始广泛地应用于数据管理，对数据的共享提出了越来越高的要求。
传统的文件系统已经不能满足人们的需要，能够统一管理和共享数据的数据库管理系统（DBMS）应运而生。
数据模型是数据库系统的核心和基础，各种DBMS软件都是基于某种数据模型的。
所以通常也按照数据模型的特点将传统数据库系统分成网状数据库、层次数据库和关系数据库三类。
最早出现的网状DBMS，是美国通用电气公司Bachman等人在1961年开发的IDS（Integrated Data Store）。
1964年通用电气公司（General ElectricCo.）的Charles Bachman 成功地开发出世界上第一个网状DBMS也即第一个数据库管理系统——集成数据存储（Integrated Data Store IDS），奠定了网状数据库的基础，并在当时得到了广泛的发行和应用。
IDS 具有数据模式和日志的特征，但它只能在GE主机上运行，并且数据库只有一个文件，数据库所有的表必须通过手工编码生成。
之后，通用电气公司一个客户——BF Goodrich Chemical 公司最终不得不重写了整个系统，并将重写后的系统命名为集成数据管理系统（IDMS）。
网状数据库模型对于层次和非层次结构的事物都能比较自然的模拟，在关系数据库出现之前网状DBMS要比层次DBMS用得普遍。
在数据库发展史上，网状数据库占有重要地位。
层次型DBMS是紧随网络型数据库而出现的，最著名最典型的层次数据库系统是IBM 公司在1968 年开发的IMS（Information Management System），一种适合其主机的层次数据库。
这是IBM公司研制的最早的大型数据库系统程序产品。
从60年代末产生起，如今已经发展到IMSV6，提供群集、N路数据共享、消息队列共享等先进特性的支持。
这个具有30年历史的数据库产品在如今的WWW应用连接、商务智能应用中扮演着新的角色。
1973年Cullinane公司（也就是后来的Culli软件公司），开始出售Goodrich公司的IDMS改进版本，并且逐渐成为当时世界上最大的软件公司。
网状数据库和层次数据库已经很好地解决了数据的集中和共享问题，但是在数据独立性和抽象级别上仍有很大欠缺。
用户在对这两种数据库进行存取时，仍然需要明确数据的存储结构，指出存取路径。
而后来出现的关系数据库较好地解决了这些问题。
1970年，IBM的研究员E.F.Codd博士在刊物《munication of the ACM》上发表了一篇名为“A Relational Model of Data for Large Shared Data Banks”的论文，提出了关系模型的概念，奠定了关系模型的理论基础。
尽管之前在1968年Childs已经提出了面向 *** 的模型，然而这篇论文被普遍认为是数据库系统历史上具有划时代意义的里程碑。
Codd的心愿是为数据库建立一个优美的数据模型。
后来Codd又陆续发表多篇文章，论述了范式理论和衡量关系系统的12条标准，用数学理论奠定了关系数据库的基础。
关系模型有严格的数学基础，抽象级别比较高，而且简单清晰，便于理解和使用。
但是当时也有人认为关系模型是理想化的数据模型，用来实现DBMS是不现实的，尤其担心关系数据库的性能难以接受，更有人视其为当时正在进行中的网状数据库规范化工作的严重威胁。
为了促进对问题的理解，1974年ACM牵头组织了一次研讨会，会上开展了一场分别以Codd和Bachman为首的支持和反对关系数据库两派之间的辩论。
这次著名的辩论推动了关系数据库的发展，使其最终成为现代数据库产品的主流。
1969年Edgar F.“Ted” Codd发明了关系数据库。
1970年关系模型建立之后，IBM公司在San Jose实验室增加了更多的研究人员研究这个项目，这个项目就是著名的System R。
其目标是论证一个全功能关系DBMS的可行性。
该项目结束于1979年，完成了第一个实现SQL的 DBMS。
然而IBM对IMS的承诺阻止了System R的投产，一直到1980年System R才作为一个产品正式推向市场。
IBM产品化步伐缓慢的三个原因：IBM重视信誉，重视质量，尽量减少故障；IBM是个大公司，官僚体系庞大，IBM内部已经有层次数据库产品，相关人员不积极，甚至反对。
然而同时，1973年加州大学伯克利分校的Michael Stonebraker和Eugene Wong利用System R已发布的信息开始开发自己的关系数据库系统Ingres。
他们开发的Ingres项目最后由Oracle公司、Ingres公司以及硅谷的其他厂商所商品化。
后来，System R和Ingres系统双双获得ACM的1988年“软件系统奖”。
1976年霍尼韦尔公司(Honeywell)开发了第一个商用关系数据库系统——Multics Relational Data Store。
关系型数据库系统以关系代数为坚实的理论基础，经过几十年的发展和实际应用，技术越来越成熟和完善。
其代表产品有Oracle、IBM公司的 DB2、微软公司的MS SQL Server以及Informix、ADABAS D等等。
1974年IBM的Ray Boyce和Don Chamberlin将Codd关系数据库的12条准则的数学定义以简单的关键字语法表现出来，里程碑式地提出了SQL(Structured Query Language)语言。
SQL语言的功能包括查询、 *** 纵、定义和控制，是一个综合的、通用的关系数据库语言，同时又是一种高度非过程化的语言，只要求用户指出做什么而不需要指出怎么做。
SQL集成实现了数据库生命周期中的全部 *** 作。
SQL提供了与关系数据库进行交互的方法，它可以与标准的编程语言一起工作。
自产生之日起，SQL语言便成了检验关系数据库的试金石，而SQL语言标准的每一次变更都指导着关系数据库产品的发展方向。
然而，直到二十世纪七十年代中期，关系理论才通过SQL在商业数据库Oracle和DB2中使用。
1986年，ANSI把SQL作为关系数据库语言的美国标准，同年公布了标准SQL文本。
SQL标准有3个版本。
基本SQL定义是ANSⅨ3135-89，“Database Language - SQL with Integrity Enhancement”[ANS89]，一般叫做SQL-89。
SQL-89定义了模式定义、数据 *** 作和事务处理。
SQL- 89和随后的ANSⅨ3168-1989，“Database Language-Embedded SQL”构成了第一代SQL标准。
ANSⅨ3135-1992[ANS92]描述了一种增强功能的SQL，叫做SQL-92标准。
SQL-92包括模式 *** 作，动态创建和SQL语句动态执行、网络环境支持等增强特性。
在完成SQL-92标准后，ANSI和ISO即开始合作开发SQL3标准。
SQL3的主要特点在于抽象数据类型的支持，为新一代对象关系数据库提供了标准。
1976年IBM E.F.Codd发表了一篇里程碑的论文“R系统：数据库关系理论”，介绍了关系数据库理论和查询语言SQL。
Oracle的创始人Ellison非常仔细地阅读了这篇文章，被其内容震惊，这是第一次有人用全面一致的方案管理数据信息。
作者E.F.Codd 1966年就发表了关系数据库理论，并在IBM研究机构开发原型，这个项目就是R系统，存取数据表的语言就是SQL。
Ellison看完后，敏锐意识到在这个研究基础上可以开发商用软件系统。
而当时大多数人认为关系数据库不会有商业价值。
Ellison认为这是他们的机会：他们决定开发通用商用数据库系统Oracle，这个名字来源于他们曾给中央情报局做过的项目名。
几个月后，他们就开发了Oracle 1.0。
但这只不过是个玩具，除了完成简单关系查询不能做任何事情，他们花相当长的时间才使Oracle变得可用，维持公司运转主要靠承接一些数据库管理项目和做顾问咨询工作。
而IBM却没有计划开发，为什么蓝色巨人放弃了这个价值上百亿的产品，原因有很多：IBM的研究人员大多是学术出身，他们最感兴趣的是理论，而非推向市场的产品，从学术上看，研究成果应公开发表论文和演讲能使他们成名，为什么不呢？还有一个很主要的原因就是IBM当时有一个销售得还不错的层次数据库产品IMS。
直到1985年IBM才发布了关系数据库DB2 ，Ellision那时已经成了千万富翁。
Ellison曾将IBM 选择Microsoft 的MS-DOS作为IBM-PC机的 *** 作系统比为：“世界企业经营历史上最严重的错误，价值超过了上千亿美元。”IBM发表R系统论文，而且没有很快推出关系数据库产品的错误可能仅仅次之。
Oracle的市值在1996年就达到了280亿美元。
随着信息技术和市场的发展，人们发现关系型数据库系统虽然技术很成熟，但其局限性也是显而易见的：它能很好地处理所谓的“表格型数据”，却对技术界出现的越来越多的复杂类型的数据无能为力。
九十年代以后，技术界一直在研究和寻求新型数据库系统。
但在什么是新型数据库系统的发展方向的问题上，产业界一度是相当困惑的。
受当时技术风潮的影响，在相当一段时间内，人们把大量的精力花在研究“面向对象的数据库系统(object oriented database)”或简称“OO数据库系统”。
值得一提的是，美国Stonebraker教授提出的面向对象的关系型数据库理论曾一度受到产业界的青睐。
而Stonebraker本人也在当时被Informix花大价钱聘为技术总负责人。
然而，数年的发展表明，面向对象的关系型数据库系统产品的市场发展的情况并不理想。
理论上的完美性并没有带来市场的热烈反应。
其不成功的主要原因在于，这种数据库产品的主要设计思想是企图用新型数据库系统来取代现有的数据库系统。
这对许多已经运用数据库系统多年并积累了大量工作数据的客户，尤其是大客户来说，是无法承受新旧数据间的转换而带来的巨大工作量及巨额开支的。
另外，面向对象的关系型数据库系统使查询语言变得极其复杂，从而使得无论是数据库的开发商家还是应用客户都视其复杂的应用技术为畏途。
二十世纪六十年代后期出现了一种新型数据库软件：决策支持系统(DSS)，其目的是让管理者在决策过程中更有效地利用数据信息。
于是在1970年，第一个联机分析处理工具——Express诞生了。
其他决策支持系统紧随其后，许多是由公司的IT部门开发出来的。
1985年，第一个商务智能系统(business intelligence)由Metaphor计算机系统有限公司为Procter &Gamble公司开发出来，主要是用来连接销售信息和零售的扫描仪数据。
同年， Pilot软件公司开始出售第一个商用客户/服务器执行信息系统——mand Center。
同样在这年，加州大学伯克利分校Ingres项目演变成Postgres，其目标是开发出一个面向对象的数据库。
此后一年， Graphael公司开发了第一个商用的对象数据库系统—Gbase。
1988年，IBM公司的研究者Barry Devlin和Paul Murphy发明了一个新的术语—信息仓库，之后，IT的厂商开始构建实验性的数据仓库。
1991年，W.H. Bill Inmon出版了一本“如何构建数据仓库”的书，使得数据仓库真正开始应用。
1991： W.H.“Bill” Inmon发表了”构建数据仓库”
二十世纪九十年代，随着基于PC的客户/服务器计算模式和企业软件包的广泛采用，数据管理的变革基本完成。
数据管理不再仅仅是存储和管理数据，而转变成用户所需要的各种数据管理的方式。
Inter的异军突起以及XML语言的出现，给数据库系统的发展开辟了一片新的天地。
如果打算为项目选择一款免费、开源的数据库，那么你可能会在MySQL与PostgreSQL之间犹豫不定。MySQL与PostgreSQL都是免费、开源、强大、且功能丰富的数据库。你主要的问题可能是：哪一个才是最好的开源数据库，MySQL还是PostgreSQL呢？该选择哪一个开源数据库呢？
在选择数据库时，你所做的是个长期的决策，因为后面如果再改变决定将是非常困难且代价高昂的。你希望一开始就选择正确。两个流行的开源数据库MySQL与PostgreSQL常常成为最后要选择的产品。对这两个开源数据库的高层次概览将会有助于你选择最适合自己需要的。
MySQL
MySQL相对来说比较年轻，首度出现在1994年。它声称自己是最流行的开源数据库。MySQL就是LAMP（用于Web开发的软件包，包括Linux、Apache及Perl/PHP/Python）中的M。构建在LAMP栈之上的大多数应用都会使用MySQL，包括那些知名的应用，如WordPress、Drupal、Zend及phpBB等。
一开始，MySQL的设计目标是成为一个快速的Web服务器后端，使用快速的索引序列访问方法（ISAM），不支持ACID。经过早期快速的发展之后，MySQL开始支持更多的存储引擎，并通过InnoDB引擎实现了ACID。MySQL还支持其他存储引擎，提供了临时表的功能（使用MEMORY存储引擎），通过MyISAM引擎实现了高速读的数据库，此外还有其他的核心存储引擎与第三方引擎。
MySQL的文档非常丰富，有很多质量不错的免费参考手册、图书与在线文档，还有来自于Oracle和第三方厂商的培训与支持。
MySQL近几年经历了所有权的变更和一些颇具戏剧性的事件。它最初是由MySQL AB开发的，然后在2008年以10亿美金的价格卖给了Sun公司，Sun公司又在2010年被Oracle收购。Oracle支持MySQL的多个版本：Standard、Enterprise、Classic、Cluster、Embedded与Community。其中有一些是免费下载的，另外一些则是收费的。其核心代码基于GPL许可，对于那些不想使用GPL许可的开发者与厂商来说还有商业许可可供使用。
现在，基于最初的MySQL代码还有更多的数据库可供选择，因为几个核心的MySQL开发者已经发布了MySQL分支。最初的MySQL创建者之一Michael "Monty" Widenius貌似后悔将MySQL卖给了Sun公司，于是又开发了他自己的MySQL分支MariaDB，它是免费的，基于GPL许可。知名的MySQL开发者Brian Aker所创建的分支Drizzle对其进行了大量的改写，特别针对多CPU、云、网络应用与高并发进行了优化。
PostgreSQL
PostgreSQL标榜自己是世界上最先进的开源数据库。PostgreSQL的一些粉丝说它能与Oracle相媲美，而且没有那么昂贵的价格和傲慢的客服。它拥有很长的历史，最初是1985年在加利福尼亚大学伯克利分校开发的，作为Ingres数据库的后继。
PostgreSQL是完全由社区驱动的开源项目，由全世界超过1000名贡献者所维护。它提供了单个完整功能的版本，而不像MySQL那样提供了多个不同的社区版、商业版与企业版。PostgreSQL基于自由的BSD/MIT许可，组织可以使用、复制、修改和重新分发代码，只需要提供一个版权声明即可。
可靠性是PostgreSQL的最高优先级。它以坚如磐石的品质和良好的工程化而闻名，支持高事务、任务关键型应用。PostgreSQL的文档非常精良，提供了大量免费的在线手册，还针对旧版本提供了归档的参考手册。PostgreSQL的社区支持是非常棒的，还有来自于独立厂商的商业支持。
数据一致性与完整性也是PostgreSQL的高优先级特性。PostgreSQL是完全支持ACID特性的，它对于数据库访问提供了强大的安全性保证，充分利用了企业安全工具，如Kerberos与OpenSSL等。你可以定义自己的检查，根据自己的业务规则确保数据质量。在众多的管理特性中，point-in-time recovery（PITR）是非常棒的特性，这是个灵活的高可用特性，提供了诸如针对失败恢复创建热备份以及快照与恢复的能力。但这并不是PostgreSQL的全部，项目还提供了几个方法来管理PostgreSQL以实现高可用、负载均衡与复制等，这样你就可以使用适合自己特定需求的功能了。
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）