【Spark 深入学习 01】 Spark是什么鬼？

经过一段时间的学习和测试，是时候给spark的学习经历做一个总结了，对于spark的了解相对晚了写。春节期间（预计是无大事)，本博准备推出20篇左右spark系列原创文章（先把牛吹出去再说） ，尽量将枯燥无味的技术讲的通俗易懂- r.kelly

 

 

      2013年的时候第一次听说spark这么个神器，那时候它还幼小，没什么人鸟它，但是它强大基因注定了它不是个凡夫俗子， 故事就是从那一小撮人群中开始的。

一、Spark何许人也

    姓名：Spark

    性别：未知

    出生地：加州大学伯克利分校AMP实验室

    出生年月：2009年，2010年他被AMP实验室公诸于世（正式开源），2013年6月被Apache开源组织收为干儿子， 它干爸决定重要培养，花了不少资源把他调到了尖子班（Apaceh顶级项目）

    父母亲：

     里面有帅气小伙如  Reynold Xin，中文名字辛湜（Shark作者），也有神一样的大牛，如横跨工业界和学术界的操着罗马尼亚口音的 matei zaharia（加州大学伯克利分校amp实验室博士)

   七大姑八大姨：各个国家的知名公司都是，如BAT、YAHOO、4QUANT- （瑞士一家公司，专注视频和图片分析公司）

 有好多好多，不愿意列举了，可以去官网http://spark.apache.org/powered-by.html

 

二、高贵的基因

 

1.spark是什么鬼-分布式计算框架

    Mapreduce也是分布式计算框架，但是Spark要多加2个字，分布式内存计算框架，牛就牛在内存这块。MR分布式计算框架比较会偷懒，干活干着干着就把活放着休息（写到磁盘），而Spark则不偷懒，一直干不停（数据都在内存），随叫随到，从不犹豫，并且Spark干活也比较有方法，爱动脑子（DAG）。

   所以和它的堂兄MapRedcue比起来，有如哪些不同点呢：

  （1）Spark脑子聪明、不偷懒- 中间结果不输出磁盘

     MR喜欢将中间结果写到磁盘上，MR做事又喜欢将一件事情分层几个环节来做（多个stage，执行的时候讲多个stage串联起来），每个环节都把中间结果写到磁盘，下个stage又从磁盘拿出来，难免啰嗦、麻烦效率低（MR做事比较死板，一板一眼按流程挨个做(一个任务分为多个stage串行执行)）。

    Spark相对机灵一点，事先评估好做事情的策略和方法，哪些事情可以放在一起，哪些不放在一起，方法策略定好后（所有动作抽象为有向五环图执行计划DAG），再动手干,规划好的事情可以挨个做，也可以同时做，活不离手（数据在内存），当然有时候拿不过来了，也可以放一放手（写到磁盘上），下次再要做的时候再拿起来继续。

    但是显然spark的缺点也明显了，内存，你的数据一致放在内存，哪有那么多内存让你败啊，如果和其他一样需要消耗内存的服务在一起，肯定要打个你死我活。MR就不会，别人想多点内存，他一点都不在意，谁要谁拿去，哥不稀罕。

   

   （2）脾气不好-spark容错比maprduce要差

     有点才华的人脾气都大啊，spark比较有个性，脾气确实不咋地。如果活干着干着失败了，spark暴怒之下就要从头再来（做事太急，急的都不知道自己在哪里跌倒了-因为数据在内存，需要重新计算），而MR则不会从头再来，他哪里跌倒哪里爬起来，因为做事情慢，所以也是有条不紊（知道在哪里跌倒了-数据在磁盘）。

   其实两个人都有比较好的脾气- 好的容错能力，但是他们对比起来，MR容错能力略好一点。

   

   （3）相处能力（与其他组件的兼容性）

      spark可以自己单干，也可以在yarn上一伙人干，吃饭也不挑剔-（数据源可以是HDFS支持的各类文件格式），还可以通过jdbc和odbc和家族之外人共事（与传统BI工具）

     mr内心是这样想的：这有什么好拿出来炫耀的，我也可以做到。确实他们两兄弟在这一点上是旗鼓相当的。

  （4）身体健康（安全性）

 

   · 血型- 编程语言

    spark的选型是scala，mapreduce的血型是java，从血型看，scala更厉害一点，scala血型的人擅长干体力活（处理数据），并且也支持其他血型（java，python，sql），尤其是对sql的支持，比mapreduce不知道强了多少倍。java血型更适合处理综合性的复杂事情，并不是很擅长干体力活，并且干活时的套路太多了（写个mr程序各种框架套着）

     Spark 更易于编程，同时也包含交互式模式；Hadoop MapReduce 不易编程但是现有的很多工具使其更易于使用。

    · 免疫能力-安全机制

      毕竟大哥就是大哥，年龄在那里摆着呢，免疫能力当然更好一点-具备所有 Hadoop 支持的安全机制，同时也整合了其它基于 Hadoop 的安全项目， 比如  Knox 网关和  Sentry。志在解决 Hadoop 安全的  Rhino 项目也只是在添加 Sentry 支持时添加了 Spark 支持。否则 Spark 开发者们只能自己去提升其安全性了。

        Spark 则略显不足。 授权验证由共享秘钥机制支持，网络用户接口则通过 servlet 过滤器和事件日志保护。Spark 可以运行在 YARN 上并配合使用 HDFS， 这也就意味着它同时还拥有 Kerberos 认证授权验证，HDFS 文件许可机制和节点间的加密机制。

 

2.spark骨架如何

基于对MR的理解，回忆一下分布式计算碰到的几个典型问题

（1）分布式情况下，资源如何分配，谁负责分配资源，资源都在哪里 ？

（2）分布式情况下，任务如何分配，任务哪里来，谁分配任务，分给谁？

（3）分布式情况下，任务执行的时候，如何跟踪任务进度，谁统一汇总任务执行情况，下面的人如何回报任务？

（4）分布式情况下，任务执行的时候，如何跟踪资源动态使用情况，谁负责统计所有资源情况，各个节点怎么回报资源给统计的人？

其实分布式计算框架，就这点破事，折腾不出什么新鲜花样，基于对上面问题的思考，看看spark是怎么解决的。

（1）资源分配问题：ClusterManager负责资源分配，怎么分配由ClusterManager自己选择分配算法，资源都在Worker上面（一帮干活的兄弟），ClusterManager首先必须知道各个兄弟有什么资源，任务一旦来了（来了就需要消耗资源），ClusterManager根据实际情况切分任务，各个兄弟都摊派出一些资源（磁盘、内存、网络）来处理任务【一级分配】

（2）任务分配问题：任务分配可以有多种方式和策略，如基于YARN，MESOS来安排任务的分配和任务执行时对任务的监控，任务来源很明显就是Driver app提交过来的。

（3）如何跟踪执行的任务：任务的执行最后会落实到worker上，所以任务跟踪必须是work和YARN等反馈，让yarn来统一管理任务的执行情况，任务来了之后，worker内部也要调配人马，组织以一个的executor来分解任务，从而提升任务执行的效率，能并行的并行，不能 的就串行，但是每一个executor执行的情况都要汇总起来，统一由worker的某个服务一起回报给yarn，driver app（交互界面可以看到任务执行的进度）。

（4）如何跟踪资源的使用情况:Spark 的工作节点。对 Spark 应用程序来说，由集群管理器分配得到资源的 Worker 节点主要负责以下工作：创建 Executor ，将资源和任务进一步分配给 Executor ，同步资源信息给 Cluster Manager 。

 

3.spark的各个身体器官

· 心脏 - spark core

人心脏停止跳动就死掉了，spark的心脏是spark core，所有的功能都是建立在这基础之上，

a.负责与下面的人打交道：与文件系统如HDFS，

b.负责与上面的人打交道：应用程序开发

c.管理自家财产：如内存、CPU等

d. 管理自己事物：如任务的管理等

凡是要交互的功能，都和spark core有千丝万缕的联系，没有它，全都得挂

·  嘴巴 - spark sql

外界通过spark sql可以快速传达要spark做什么，并且这是一个懂得BI方言的嘴巴，很容易和传统的BI家族进行交互，是外部和spark打交道的重要入口。

· 一个一直张开的嘴巴-spark streaming

有时候spark sql做事有点磨叽，spark streaming 就来解决，一个一直张开的嘴巴从来就不关闭，一直吃吃吃....永不停歇。

· MLLIB

SPARK的开挂技能，spark很聪明，它知道有些人的脑子不够用，写不出来那些牛逼的机器学习算法，所以他准备好了葵花宝典，写不出来不要紧，按照葵花宝典就可以写出来了，分类、回归、聚类、协同等等，可扩展的Spark机器学习库，由通用的学习算法和工具组成，包括二元分类、线性回归、聚类、协同过滤、梯度下降以及底层优化原语。用于机器学习和统计等场景

·GRAPHX

开挂技能，处理图计算的宝典，直接用就可以了。GraphX是用于图计算和并行图计算的新的（alpha）Spark API。通过引入弹性分布式属性图（Resilient Distributed Property Graph），一种顶点和边都带有属性的有向多重图，扩展了Spark RDD。为了支持图计算，GraphX暴露了一个基础操作符集合（如subgraph，joinVertices和aggregateMessages）和一个经过优化的Pregel API变体。此外，GraphX还包括一个持续增长的用于简化图分析任务的图算法和构建器集合。

 

4.参考资料

1.http://www.tuicool.com/articles/RbUbuiQ

2.辛湜专访-http://www.csdn.net/article/2013-04-26/2815057-Spark-Reynold，

3.加州大学伯克利分校amp实验室博士matei zaharia：spark的现状和未来.pdf-http://www.open-open.com/doc/view/53c1d9db9c4d4df58c6eb8d148739a8a

4.UC Berkeley AMPLab -- 是实验室也是孵化器https://zhuanlan.zhihu.com/p/21350352?refer=bittiger

5.spark官网

转载于:https://www.cnblogs.com/licheng/p/6815248.html