spark网络通信组件

① 大数据常用组件

大数据技术通常包括许多不同的组件，这些组件可以帮助你处理和分析大量数据。
常用的大数据组件包括：
1.Hadoop：Hadoop是一个开源的分布式存储和计算框架，可以处理海量数据。
2.Spark：Spark是一个携念快渣隐悉速的大数据处理引擎，可以帮助你快速分析和处理大量数据。
3.NoSQL数据库：NoSQL数据库是面向大数据的数据库，可以快速处理大量非结构化数据。
4.流式处理引擎：流式处理引擎可以实时处理大量数据流。
5.数据仓库：数据仓库是一个大数据存储和分析平台，可以帮助你组织和管理大量数据。
6.数据挖掘和如乎机器学习工具：数据挖掘和机器学习工具可以帮助你从大量数据中发现有价值的信息。

② 科普Spark，Spark是什么，如何使用Spark

科普Spark，Spark是什么，如何使用Spark

1.Spark基于什么算法的分布式计算（很简单）

2.Spark与MapRece不同在什么地方

3.Spark为什么比Hadoop灵活

4.Spark局限是什么

5.什么情况下适合使用Spark

Spark与Hadoop的对比

Spark的中间数据放到内存中，对于迭代运算效率更高。

Spark更适合于迭代运算比较多的ML和DM运算。因为在Spark里面，有RDD的抽象概念。

Spark比Hadoop更通用

Spark提供的数据集操作类型有很多种，不像Hadoop只提供了Map和Rece两种操作。比如map, filter, flatMap, sample, groupByKey, receByKey, union, join, cogroup, mapValues, sort,partionBy等多种操作类型，Spark把这些操作称为Transformations。同时还提供Count, collect, rece, lookup, save等多种actions操作。

这些多种多样的数据集操作类型，给给开发上层应用的用户提供了方便。各个处理节点之间的通信模型不再像Hadoop那样就是唯一的Data Shuffle一种模式。用户可以命名，物化，控制中间结果的存储、分区等。可以说编程模型比Hadoop更灵活。

不过由于RDD的特性，Spark不适用那种异步细粒度更新状态的应用，例如web服务的存储或者是增量的web爬虫和索引。就是对于那种增量修改的应用模型不适合。

容错性

在分布式数据集计算时通过checkpoint来实现容错，而checkpoint有两种方式，一个是checkpoint data，一个是logging the updates。用户可以控制采用哪种方式来实现容错。

可用性

Spark通过提供丰富的Scala, Java，Python API及交互式Shell来提高可用性。

Spark与Hadoop的结合

Spark可以直接对HDFS进行数据的读写，同样支持Spark on YARN。Spark可以与MapRece运行于同集群中，共享存储资源与计算，数据仓库Shark实现上借用Hive，几乎与Hive完全兼容。

Spark的适用场景

Spark是基于内存的迭代计算框架，适用于需要多次操作特定数据集的应用场合。需要反复操作的次数越多，所需读取的数据量越大，受益越大，数据量小但是计算密集度较大的场合，受益就相对较小（大数据库架构中这是是否考虑使用Spark的重要因素）

由于RDD的特性，Spark不适用那种异步细粒度更新状态的应用，例如web服务的存储或者是增量的web爬虫和索引。就是对于那种增量修改的应用模型不适合。总的来说Spark的适用面比较广泛且比较通用。

运行模式

本地模式

Standalone模式

Mesoes模式

yarn模式

Spark生态系统

Shark ( Hive on Spark): Shark基本上就是在Spark的框架基础上提供和Hive一样的H iveQL命令接口，为了最大程度的保持和Hive的兼容性，Shark使用了Hive的API来实现query Parsing和 Logic Plan generation，最后的PhysicalPlan execution阶段用Spark代替Hadoop MapRece。通过配置Shark参数，Shark可以自动在内存中缓存特定的RDD，实现数据重用，进而加快特定数据集的检索。同时，Shark通过UDF用户自定义函数实现特定的数据分析学习算法，使得SQL数据查询和运算分析能结合在一起，最大化RDD的重复使用。

Spark streaming: 构建在Spark上处理Stream数据的框架，基本的原理是将Stream数据分成小的时间片断（几秒），以类似batch批量处理的方式来处理这小部分数据。Spark Streaming构建在Spark上，一方面是因为Spark的低延迟执行引擎（100ms+）可以用于实时计算，另一方面相比基于Record的其它处理框架（如Storm），RDD数据集更容易做高效的容错处理。此外小批量处理的方式使得它可以同时兼容批量和实时数据处理的逻辑和算法。方便了一些需要历史数据和实时数据联合分析的特定应用场合。

Bagel: Pregel on Spark，可以用Spark进行图计算，这是个非常有用的小项目。Bagel自带了一个例子，实现了Google的PageRank算法。

End.

③ spark和hadoop的区别

直接比较Hadoop和Spark有难度，因为它们处理的许多任务都一样，但是在一些方面又并不相互重叠。

比如说，Spark没有文件管理功能，因而必须依赖Hadoop分布式文件系统(HDFS)或另外某种解决方案。

Hadoop框架的主要模块包括如下：

• Hadoop Common

• Hadoop分布式文件系统(HDFS)

• Hadoop YARN

• Hadoop MapRece

虽然上述四个模块构成了Hadoop的核心，不过还有其他几个模块。这些模块包括：Ambari、Avro、Cassandra、Hive、 Pig、Oozie、Flume和Sqoop，它们进一步增强和扩展了Hadoop的功能。

Spark确实速度很快(最多比Hadoop MapRece快100倍)。Spark还可以执行批量处理，然而它真正擅长的是处理流工作负载、交互式查询和机器学习。

相比MapRece基于磁盘的批量处理引擎，Spark赖以成名之处是其数据实时处理功能。Spark与Hadoop及其模块兼容。实际上，在Hadoop的项目页面上，Spark就被列为是一个模块。

Spark有自己的页面，因为虽然它可以通过YARN(另一种资源协调者)在Hadoop集群中运行，但是它也有一种独立模式。它可以作为 Hadoop模块来运行，也可以作为独立解决方案来运行。

MapRece和Spark的主要区别在于，MapRece使用持久存储，而Spark使用弹性分布式数据集(RDDS)。

性能

Spark之所以如此快速，原因在于它在内存中处理一切数据。没错，它还可以使用磁盘来处理未全部装入到内存中的数据。

Spark的内存处理为来自多个来源的数据提供了近乎实时分析的功能：营销活动、机器学习、物联网传感器、日志监控、安全分析和社交媒体网站。另 外，MapRece使用批量处理，其实从来就不是为惊人的速度设计的。它的初衷是不断收集来自网站的信息，不需要这些数据具有实时性或近乎实时性。

易用性

支持Scala(原生语言)、Java、Python和Spark SQL。Spark SQL非常类似于SQL 92，所以几乎不需要经历一番学习，马上可以上手。

Spark还有一种交互模式，那样开发人员和用户都可以获得查询和其他操作的即时反馈。MapRece没有交互模式，不过有了Hive和Pig等附加模块，采用者使用MapRece来得容易一点。

成本

“Spark已证明在数据多达PB的情况下也轻松自如。它被用于在数量只有十分之一的机器上，对100TB数据进行排序的速度比Hadoop MapRece快3倍。”这一成绩让Spark成为2014年Daytona GraySort基准。

兼容性

MapRece和Spark相互兼容;MapRece通过JDBC和ODC兼容诸多数据源、文件格式和商业智能工具，Spark具有与MapRece同样的兼容性。

数据处理

MapRece是一种批量处理引擎。MapRece以顺序步骤来操作，先从集群读取数据，然后对数据执行操作，将结果写回到集群，从集群读 取更新后的数据，执行下一个数据操作，将那些结果写回到结果，依次类推。Spark执行类似的操作，不过是在内存中一步执行。它从集群读取数据后，对数据 执行操作，然后写回到集群。

Spark还包括自己的图形计算库GraphX。GraphX让用户可以查看与图形和集合同样的数据。用户还可以使用弹性分布式数据集(RDD)，改变和联合图形，容错部分作了讨论。

容错

至于容错，MapRece和Spark从两个不同的方向来解决问题。MapRece使用TaskTracker节点，它为 JobTracker节点提供了心跳(heartbeat)。如果没有心跳，那么JobTracker节点重新调度所有将执行的操作和正在进行的操作，交 给另一个TaskTracker节点。这种方法在提供容错性方面很有效，可是会大大延长某些操作(即便只有一个故障)的完成时间。

Spark使用弹性分布式数据集(RDD)，它们是容错集合，里面的数据元素可执行并行操作。RDD可以引用外部存储系统中的数据集，比如共享式文件系统、HDFS、HBase，或者提供Hadoop InputFormat的任何数据源。Spark可以用Hadoop支持的任何存储源创建RDD，包括本地文件系统，或前面所列的其中一种文件系统。

RDD拥有五个主要属性：

• 分区列表

• 计算每个分片的函数

• 依赖其他RDD的项目列表

• 面向键值RDD的分区程序(比如说RDD是散列分区)，这是可选属性

• 计算每个分片的首选位置的列表(比如HDFS文件的数据块位置)，这是可选属性

RDD可能具有持久性，以便将数据集缓存在内存中。这样一来，以后的操作大大加快，最多达10倍。Spark的缓存具有容错性，原因在于如果RDD的任何分区丢失，就会使用原始转换，自动重新计算。

可扩展性

按照定义，MapRece和Spark都可以使用HDFS来扩展。那么，Hadoop集群能变得多大呢?

据称雅虎有一套42000个节点组成的Hadoop集群，可以说扩展无极限。最大的已知Spark集群是8000个节点，不过随着大数据增多，预计集群规模也会随之变大，以便继续满足吞吐量方面的预期。

安全

Hadoop支持Kerberos身份验证，这管理起来有麻烦。然而，第三方厂商让企业组织能够充分利用活动目录Kerberos和LDAP用于身份验证。同样那些第三方厂商还为传输中数据和静态数据提供数据加密。

Hadoop分布式文件系统支持访问控制列表(ACL)和传统的文件权限模式。Hadoop为任务提交中的用户控制提供了服务级授权(Service Level Authorization)，这确保客户拥有正确的权限。

Spark的安全性弱一点，目前只支持通过共享密钥(密码验证)的身份验证。Spark在安全方面带来的好处是，如果你在HDFS上运行Spark，它可以使用HDFS ACL和文件级权限。此外，Spark可以在YARN上运行，因而能够使用Kerberos身份验证。

总结

Spark与MapRece是一种相互共生的关系。Hadoop提供了Spark所没有的功能特性，比如分布式文件系统，而Spark 为需要它的那些数据集提供了实时内存处理。完美的大数据场景正是设计人员当初预想的那样：让Hadoop和Spark在同一个团队里面协同运行。

然后看这篇文章：Link



注：对下面这一段持保留意见：

此外我们这里还要讲到的是一个关于spark的重要误区—“spark是基于内存的技术”。它不是基于内存的技术；spark是一个管道式的执行引擎，而且在shuffle的过程中会将数据写入磁盘(比如说，如果我们想针对某个字段做聚合操作)、如果内存不够的话也一样会内存溢出(但是内存可以调整)。因此，spark之所以比MapRece快主要是因为它是管道式处理方式而不是有些人说的“基于内存的优化”。当然，spark在内存中做了缓存来提高性能，但这不是spark真正工作快的原因。

现在，我们再来完整比对一下：

1. MapRece可以被Spark Core替换？是的，它会随着时间的推移被替代，而且这种替代是合理的。但是spark目前还不是特别成熟能完全替代MapRece。此外，也没有人会完全放弃MapRece,除非所有依赖MapRece的工具都有可替代方案。比如说，想要在pig上运行的脚本能在spark上执行还是有些工作要做的。

（注：Pig是一种数据流语言，用来快速轻松的处理巨大的数据，雅虎推出的，现在正在走下坡路。Pig可以非常方便的处理HDFS和HBase的数据，和Hive一样,Pig可以非常高效的处理其需要做的，通过直接操作Pig查询可以节省大量的劳动和时间。当你想在你的数据上做一些转换，并且不想编写MapRece jobs就可以用Pig.）

2. Hive可以被Spark SQL替换？是的，这又是对的。但是我们需要理解的是Spark SQL对于spark本身来说还是比较年轻的，大概要年轻1.5倍。相对于比较成熟的Hive来说它只能算是玩具了吧，我将在一年半到两年之内再回头来看Spark SQL.。如果我们还记得的话，两到三年前Impala就号称要终结Hive,但是截止到目前两种技术也还是共存状态，Impala并没有终结Hive。在这里对于Spark SQL来说也是一样的。

3. Storm可以被Spark Streaming替换？是的，可以替换。只不过平心而论storm并不是Hadoop生态系统中的一员，因为它是完全独立的工具。他们的计算模型并不太形同，所以我不认为storm会消失，反而仍会作为一个商业产品。

4. Mahout可以被MLib替换？公平的讲，Machout已经失去了市场，而且从过去的几年来看它正在快速失去市场。对于这个工具，我们可以说这里是Spark真正可以替换Hadoop生态系统中的地方。 (注：同意！Spark的ML非常好用！要好好学！)

因此，总的来说，这篇文章的结论是：

1.不要被大数据供应商的包装所愚弄。他们大量推进的是市场而不是最终的真理。Hadoop最开始是被设计为可扩展的框架，而且其中很多部分是可替换的：可以将HDFS替换为Tachyon（现在新的名字是Alluxio），可以将YARN替换为Mesos，可以将MapRece替换为Tez并且在Tez之上可以运行Hive。这将会是Hadoop技术栈的可选方案或者完全替代方案？倘若我们放弃的MR（MapRece）而使用Tez,那么它还会是Hadoop吗？

2. Spark不能为我们提供完整的技术栈。它允许我们将它的功能集成到我们的Hadoop集群中并且从中获益，而不用完全脱离我们老的集群方案。

3. Spark还不够成熟。我认为在过三到四年我们就不会再叫“Hadoop栈”而是叫它“大数据栈”或者类似的称呼。因为在大数据栈中我们有很广泛的选择可以选出不同的开源产品来组合在一起形成一个单独的技术栈使用。