Spark从入门到放弃——初识Spark（一）

Spark追根溯源

  存在即合理，一个新事物的崛起必然有他的历史原因这里我们就浅谈一下Spark出现的原因；故事要从谷歌的三驾马车说起，就是打开大数据的大门的三篇论文；
  1. 2003年发bai表du了《The Google File System》，后来的HDFS；
  2. 2004年发表了《MapRedaoce: Simplified Data Processing on Large Clusters 》，后来的MapReduce；
  3. 2006年发表了《Bigtable: A Distributed Storage System for Structured Data》，后来的Hive及Hbase；

图1 Hadoop 1.X版本的基础架构    以三驾马车为指导思想，2011年发布了Hadoop1.0版本，开启大数据解决方案的具体实施策略，2012年发布稳定版，最基础的架构如图1，最早就只有HDFS和MapReduce两个模块；

  HDFS作为分布式存储文件，总体上没有毛病，解决了当时一台电脑装不下的大文件问题，还是很优秀的；
  当然MapReduce也很优秀，基于数据集计算，面向数据能解决当时的大数据计算得到一些大数据支持的理论用于管理和决策，但是他的弊端也渐渐暴露出来了；

• 基本运算规则是从文件系统中获取数据，然后进行计算，最后将结果存回文件系统，是一个一次性的计算，即每次结果都要输出磁盘，不适合于数据挖掘和机器学习这样的迭代计算和图形挖掘计算，举个最简单的例子，计算数学里面的PI=3.4159,无限迭代MapReduce就非常头疼；
• 大量的和磁盘交互，效率非常低；
• 计算算子单一，只有Map和Reduce，稍微复杂的逻辑就需要大量代码为代价实现，书写相对较复杂；
• 这么多毛病，他不是开源的吗？全世界程序员优化不就行了，最大的毛病来了，MapReduce和Hadoop紧密耦合在一起，当时而言，要用HDFS必须用MapReduce，因为Hadoop 1.X的MapReduce的JobTracker和TaskTracker既要负责资源调度管理，又要负责任务调度和执行，即资源调度和任务调度也是耦合在一起的，非常头疼；

  很多人很头疼，那最头疼的且付出了行动的人群中，加州大学伯克利分校的people就是其中一群，既然你HDFS这么优秀，又耦合让人头疼的MapReduce，那我另外起一套计算框架；
  2013年6月发布了Spark，注意，此时还是Hadoop1.x版本，所以这一版本的Spark是基于Hadoop1.x的版本，采用自己的方式改善了Hadoop1.x的问题，改用基于内存计算，加大效率，并采用Scala语言开发，Scala是基于函数编程的，天生就是语法糖函数调函数，那函数调函数在做什么呢，不就是迭代吗？所以Spark天生就擅长迭代计算，而且中间结果又可以缓存到内存，真的是太香的，Spark初代的架构如图2，目前我们用于本地测试的local和Standalone模式很像；资源管理交给Master和Worker，任务执行交给Driver和Execute，Driver和Master之间也用ApplicationMaster隔离，这样资源和任务也解耦了；
  注意：Master和Worker不一定有，如果启动Spark On Yarn，即采用Yarn上来跑Spark，那么资源管理就是Yarn的ResourceManager和NodeManager，这个后续再细讲，是目前Spark生产环境用得最多的一种模式，需要重点掌握！

图2 Spark初代架构

  题外话：Spark的出现很好的弥补了MapReduce的不足，当然HDFS还是可以作为Spark的文件数据源的，到了2013年10月（晚于Spark），Hadoop官方也忍不了了，Hadoop官方也着手于改善Hadoop1.x的弊端，发布了Hadoop2.x版本，最大的亮点就是新增Yarn模块，将资源调度和任务调度解耦，基础架构如图3，任务调度管理Driver 和TaskExecute,资源调度管理ResourceManager和NodeManager，资源调度管理和任务调度管理通过中间隔离的ApplicationMaster和Container解耦，不同类型的任务类型用不用的ApplicationMaster，这样就相当于开放了接口，可把只要符合Yarn架构的计算框架都可以兼容进来，我Hadoop只负责给你们分配资源管理和调度，至于任务调度管理，你们计算框架自己安排，此理念延续至今，这就是为啥兴起的计算框架都可以On Yarn的原因，如Spark On Yarn，Flink On Yarn！

  细心的小伙伴已经发现，为啥spark初代框架和后来改善的Hadoop2.x yarn框架这么像呢？其实真实原因就是天下文章一大抄，哈哈，就是这么简单哈，优秀的地方，肯定都是相互借鉴的，接下来我们正式开始了解下Spark！

图3 Hadoop2.x Yarn调度初代架构

Spark版本

  Spark是Apache开源的顶级项目，官网地址,目前也一直不断更新迭代，截至本博客发布时间(20201202)最新版本是Spark 3.0.1 released (Sep 08, 2020),因为公司目前生产用的是Spark2.4.7,所以后续的教程都是以Spark2.4.7为主；

   讲解版本：Spark2.4.7

什么是Spark

   Apache Spark is a fast and general-purpose cluster computing system. It provides high-level APIs in Java, Scala, Python and R, and an optimized engine that supports general execution graphs. It also supports a rich set of higher-level tools including Spark SQL for SQL and structured data processing, MLlib for machine learning, GraphX for graph processing, and Spark Streaming.

  以上是Spark官网原话，翻译翻译就是Spark是一个计算快并且通用的集群计算系统。它提供了Java、Scala、Python和R的高级api，以及一个支持有向无环图执行的优化引擎。它还支持一组丰富的高级工具，包括结构化数据处理的SparkSQL、用于机器学习的MLlib、用于图形处理的GraphX以及实时流计算的SparkStream；
  Spark的各个组件参考图1，接下来我们先简单依次介绍它们;

图4 Spark软件栈

Spark Core

  Spark Core即Spark内核，实现了Spark的基本功能，包含任务调度，内存管理，错误恢复，与存储系统交互等等模块，Spark2.X后内核提供了两组最常用的API定义，即Low-Level APIs常用的代表有RDDs和Distributed Varibales,当然RDDs在Spark1.X就有了，全称Resilient Distributed Dataset(弹性分布式数据集)，表示分布在多个计算机节点上可以并行操作的数据元素集合，是Spark主要抽象；另一组API是Structured APIs,主要代表有Datasets, DataFrames , SparkSQL,而三者间又有必然的联系，因为这些API主要是用来处理结构化数据的，所以通常情况下， SparkSQL读取进来的数据，默认就是一个 DataFrames，而 DataFrames又是特殊的Datasets，区别就在于，Datasets没有列的概念，即数据是一行一行的， DataFrames有明确的列名，就类似与一张关系二维表；详情后续我们再谈；

  总之，创建和操作这些数据集合的API都是由Spark Core提供的；

Spark Streaming

  Spark Streaming是Spark提供的对实时数据流失处理的模块，比如网页服务器的日志，网页用户行为埋点日志收集，Spark Streaming提供操作数据流的API，并且和Spark Core中的RDD API十分相似，也一样的支持容错和弹性，这样只要你学好了RDD的API，就能轻松应对内存或者磁盘的离线计算，也能运用自如实时数据流；

MLib

  MLib,全称Machine Learning library(机器学习程序库)，提供常用的机器学习算法，包括分类，回归，聚类，协同过滤等等，同时也支持模型评估，数据导入等功能，另外，MLib还支持更底层的机器学习原语，包括一个梯度下降的优化算法，因此在集群上可以轻松的伸缩；
  此项为专业的机器学习提供，一般行业数据计算较少接触到，除非涉及数据的算法训练；

GraphX

  GraphX顾名思义，就是处理数据结构图的程序库，如社交网络的朋友关系，进行图的并行计算，是对Spark RDD API的一种扩充，支持对图的各种操作，如进行图的分割subgaraph和操作所有的顶点mapVertices；以及一些常用的图算法，如PageRank;
  此项为专业的图计算人员提供，一般行业数据计算较少接触到；

Spark运行模式

  目前Spark运行的常用模式有以下几种，开源学习的话，建议学习Spark on Yarn模式;

1. 本地运行模式，即local模式，常用于程序单机测试；
2. 独立运行模式，即Standalone模式，采用Spark自带的资源管理器的一种主从结构，常用于测试以及临时数据处理；
3. Spark on Yarn模式，即采用Yarn作为Spark的资源管理器，同时Spark on Yarn又分为两种模式，Yarn的俩种模式：一种为 client;一种为 cluster,可以通过- -deploy-mode 进行指定，也可以直接在 - -master 后面使用 yarn-client和yarn-cluster进行指定，俩种模式的区别：在于driver端启动在本地(client),还是在Yarn集群内部的AM中(cluster)；其中Spark on Yarn 的cluster模式应该是国内开源用的最多的模式。
4. Spark on Mesos，即采用Mesos作为资源管理器，在国外用的比较多，相对于Yarn，Mesos较为细力度一点，Yarn是当你申请了一份资源(包含CPU，内存等)后，即使后续实际没有用到这么多资源，也不会做处理，Mesos则是如果后续使用到的资源没有这么多，则可以回收一部分；
5. Spark on EC2，EC2则是亚马逊云的资源管理的应用系统，属于商业软件；
6. 其他模式，一些云产品的自己的产品，其实底层都是Yarn和Mesos的影子；

Spark支持的文件系统

  Spark支持任何hadoop分布式文件系统（HDFS）的文件为分布式数据集，但是hdfs并非Spark的必要条件，它也支持实现了hadoop接口或者类似接口的文件系统，如hadoop的 hive，hbase；国人的骄傲Tachyon分布式文件系统；云产品（二次开发的hdfs），如Amazon S3，AliYun OSS等，当然，也支持本地文件；
  当然，对于开源学习来说，建议学习Hadoop系列的文件系统，常用的hdfs文件，hive，hbase和spark的交互还是很紧密的，spark支持的常用hadoop输入格式包括txt，json文件，csv文件，SequenceFile，Avro，Parquet，Orc等，一般正式环境用Parquet比较多，也是spark运算完后生成文件的默认格式；

  以上就是Spark的功能模块和核心组件，当初，Spark的伟大梦想，一站式解决计算的所有，一开始不被人看好，现在基本都实现了，结构数据的spark sql，dataframe，dataset，rdd等批处理，流式计算的spark streaming，机器学习MLib以及GraphX，以及目前仍在扩建的生态圈，可以说是非常的成功的项目；

Spark与其它计算框架的对比优缺点

  一项技术的兴起，必然是革了另一项技术的命或者是在某一领域有了重大突破了，单纯讨论一项技术的优缺点，难免有些闭门造车，自吹自擂，这里就简单聊聊spark和其他常用的计算框架的对比，看看她究竟革了谁的命，又有没有可能将被谁革命；

• 优点快:人如其名，spark，像星火一样一闪而过，就计算完成了，这里说的其实是对比与Hadoop MapReduce,Spark的诞生正是因为当初加州伯克利大学RAD实验室一些研究人员觉得MapReduce在迭代和交互计算时效率低下，纵观全球又没有更好的产品，于是就自己写一个吧而诞生的，spark抛弃了MapReduce反复落地磁盘交互的里面，采用内存计算的里面，加上有向无环图（DAG）的加持以及高效的容错机制，使得相比于MapReduce有10~20倍的提升，极端情况下还有100倍的提升（具体可参考官网主页吹牛逼的图片，哈哈）！

图5 spark运算速度宣讲（极端情况下）

• 优点使用简单：写过MapReduce都知道，那东西还真不是一般人写的，每次实现一个功能，都要继承Mapper类，重写map方法 ，继承Reducer类，重写reduce方法，再自定义JobRun类在main函数去调用这些，算子单一，只有map，reduce，遇到复杂的计算，只能反复用这两个算子；而spark则不同，rdd算子丰富，组合方便，采用语法糖的scala语言或者python写的话更是简简单单，java稍微难一点，因为java不支持匿名函数，需要定义匿名内部类去重写该类的匿名函数；

  以上是优点是针对MapReduce的，有人说MapReduce不是后续也有hive的出现，使用hivesql可以代替MapReduce写的繁琐吗？一样的spark也有sparksql，总体还是快于hivespark，因此可以基本说spark rdd革了MapReduce的命，sparksql革了hivesql的命，注意不是革了hive哈，hive本身作为元数据管理还是很好用，目前也还在使用中。

• 缺点 流式计算的瑕疵:总体而言，spark在离线数据或者近线数据领域，大数据量处理也游刃有余，但是spark的流式计算采用Micro-Batching理念，即流是批的特例，因此流式计算就是微批处理，数据一小批的不断处理，这种理念能解决99%的流式计算，有个致命的缺点，那就是这种理念必须要攒批，一次必然存在攒批的时间误差，因此剩下的1%的难题，被Native-Streaming里面解决，认为批是流的特例，批处理只不过是个有界的流处理，即有结束的流式处理，因此此领域，spark正在受到冲击，以对手flink为主，当然flink的批处理还没有spark那么稳定；
  

图6 流批的本质

`

Spark简史

  目前spark早已经是Apache的顶级项目，这里就记录一些大的变更吧，具体有兴趣的可以官网的新闻页:http://spark.apache.org/news/index.html;

• 2009年作为研究项目在加州大学伯克利分校RAD实验室（AMPLab的前身）诞生，主要是解决Hadoop MapReduce在迭代和交互计算上效率低下的问题；
• 2010年3月开始开源；
• 2011年AMPLab开始基于spark开发更高层的组件，扩展生态圈，如shark（spark sql的前身），spark streaming等；
• 2013年6月,Spark接受进入Apache孵化器
• 2013年12月，Spark 0.8.1发布支持Scala 2.9，YARN 2.2，Standalone部署模式下调度的高可用性，shuffle的优化等；
• 2014年02月，Spark 0.9.0发布增加了GraphX，机器学习新特性，流式计算新特性，核心引擎优化（外部聚合、加强对YARN的支持）等； （2013年6月——2014年02月，短短8个月，一个这么牛逼的项目就脱产服务于全世界了，博主是觉得很牛逼的很赞的，期间还是很感谢这些优秀大佬们的付出的，让我们能这么轻松的使用，还开源不收费，大家一起好好修炼，争取能为这Spark的发展贡献一点自己的力量，当然也不局限于Spark啦！）
• 2014月05月，Spark 1.0.0发布，增加了Spark SQL；
• 2015年03月，Spark 1.3.0发布，该版本发布的最大亮点是新引入的DataFrame API，对于结构型的DataSet，它提供了更方便更强大的操作运算。。除了DataFrame之外，还值得关注的一点是Spark SQL成为了正式版本，这意味着它将更加的稳定，更加的全面;
• 2016年07月，Spark 2.0.0发布，该版本主要更新APIs，支持SQL 2003，支持R UDF ，增强其性能。300个开发者贡献了2500补丁程序；
• 2016年12月，Spark 2.1.0发布，这是 2.x 版本线的第二个发行版。此发行版在为Structured Streaming进入生产环境做出了重大突破，Structured Streaming现在支持了event time watermarks了，并且支持Kafka 0.10。此外，此版本更侧重于可用性，稳定性和优雅(polish)，并解决了1200多个tickets;
• 目前（20201209），Spark 3.0.1 发布；