Spark基础解析

一. 介绍spark之前我们先说一下hadoop:
Hadoop历史：

2003、2004Google发表2篇论文
2011年发布1.0版本
2012年发布稳定版
2013年10月发布2.x 版本(1.2和2.0版本的根本区别是yarn)

左边用来存储数据右边用来计算数据

mr的缺点：
1.mr是基于数据集的计算，所以是面向数据的，基本运算规 则从存储介质中获取(采集)数据，然后进行计算，最后将结果保存到介质中 。当前mr功能比较单一，制作采集计算和存储，基本面临的需求是一次性需求即单节点足需求。实际情况下大量数据并且会有一些迭代的概念及上一次的计算结果要交给下一次计算，mr没计算一次都是一个job，第一个job计算完了之后再启下一个他俩不是连在一块的(第一个job计算完之后第二个job再去取)他俩是两个个体。所以不适合数据挖掘和机器学习以及图形挖掘计算这样的迭代计算。
2.mr是基于文件存储介质的操作，所以性能很慢，多个job之间都需要文件存储介质，大量IO性能慢
3.mr和hadoop紧密耦合在一起即hadoop不能替换掉mr即无法动态替换，扩展性差，违背ocp开发原则

在2.X版本中将第三个缺点改了，加入了yarn这个资源调度的概念(跟存储关系不大，主要是用来做计算的)：

1.0版本中Job Tracker的任务太重了，又要调度Task Tracker的任务，又要做资源交互。这样就会导致其性能变慢，yarn就把他们的职责分开,RM(资源管理器,管理的是有多少内存啊，cpu等)用来调度资源，那么谁来调度任务呢？AM(Application Master应用管理器，管理的是调度执行的任务)
资源和计算如果直接关联还是会有耦合性，所以又提供了Driver,将资源调度和任务调度完全解耦合(yarn强大之处) Driver和Task相关联，RM和NM关联；但是计算和资源之间没有直接的关系，他俩之间靠AM起到中间连接的作用
例：如果想做一个计算发现资源不够了，要告诉AM,AM找到RM
那么如果没有耦合性的话，任务调度那块就可以变化，所以导致计算框架是可插拔的
那么Driver和RM之间没有耦合性，Task和NM相应的也应该没有耦合性，Container也将Task计算和资源分开了(Container其实就类似于当前电脑的虚拟机，虚拟机中可以换不同的系统，对外层的计算机没有影响，但是会占用一定的资源来做计算但是又让真正的计算和外部的资源又没有直接的关系所以降低了耦合性，增强了扩展性)
yarn的架构：

二、Spark
spark历史：
2013年6月发布
spark是基于hadoop1.X架构思想，采用自己的方式改善hadoop1.X中的问题
spark计算基于内存(迭代式计算里面的每个任务之间的数据是基于内存的就意味着每次计算可能也要保存成文件，hadoop是一次性计算，spark天生就是迭代式计算，因为他是scala写的(面向函数式编程，函数调函数，大量计算在里面可以不断的去递归循环))并且基于scala语言开发天生适合迭代式计算
1.1spark基础架构:

如图所示，上方为spark的架构图，spark的组件可以分为四个部分，driver、cluster Manager、worker和executor
根据clusterManager的不同，spark可以分成四种不同的运行模式，standalone、local cluster、spark on yarn 和spark on mesos

（上面只是计算框架，存储框架仍然要用Hadoop的所以实际操作中是spark+hdfs这两个框架融合在一起靠的就是yarn，即yarn和spark作为一个计算框架，hdfs作为一个存储框架）

standalone模式：
standalone模式既独立模式，自带完整服务，可单独部署到一个集群中，无需依赖其他任何资源管理系统，只支持FIFO调度器。从一定程度上说，它是spark on yarn 和spark on mesos 的基础。在standalone模式中，没有AM和NM的概念，也没有RM的概念，用户节点直接与master打交道，由driver负责向master申请资源，并由driver进行资源的分配和调度等等。

localCluster模式：
standalone模式的单机版，master和worker分别运行在一台机器的不同进程上