原文链接<https://0x0fff.com/spark-misconceptions/>
Spark Misconceptions
image.png
目前，媒体大肆宣传Apache Spark框架，它也一点一点地成为“大数据”领域的下一个重大事件。 要证明这一点，最简单的就是查看谷歌趋势图：
image.png
我在这里展示了过去的两年里Hadoop和Spark的(搜索热度趋势）。 可以看到Spark在终端客户中越来越受欢迎，他们（终端客户）正在通过互联网查看有关Spark的更多信息。 鉴于围绕这项技术的大肆宣传，它被许多神话（myths）和误解（misconceptions）所包围，许多人将其视为解决Hadoop问题的银弹（sliver bullet），其性能（相对于Hadoop）提高100倍。
在本文中，我将介绍有关此技术的主要误解，以便为期望在其系统中应用此框架的技术人员设定特定级别的期望（expectations）。 我想说，误解的主要根源是市场上一些专家提出的谣言和过度简化（oversimplifications）。 Spark文档足够清晰，可以反驳所有内容，但需要多阅读。 所以，我要讨论的主要误解是：
-
Spark是一种内存技术（in-memory technology)。
-
Sparkb比Hadoop快10-100倍。
-
Spark为市场上的数据处理引入了全新的方法。
image.png
第一个也是最流行的关于Spark的误解是“Spark是内存技术”。完全没有，并没有一个Spark开发者正式声明这一点！ 这些是基于对Spark计算过程的误解的谣言。
但是，让我们从头开始。 我们称什么样的技术为内存技术？ 在我看来，这项技术允许您将数据保存在RAM中并有效地处理它。 我们在Spark看到了什么？ 它没有内存数据持久化的选项，它有可插拔的用于不同的持久性存储系统的连接器，如HDFS，Tachyon，HBase，Cassandra等，但它没有本机持久化的代码，既不用于内存也不用于 磁盘存储。 它能做的一切就是缓存数据，这不是“持久化”。 基于连接器提供的源持久存储的其他可用数据，可以轻松地删除缓存数据并在以后重新计算。
接下来，一些人抱怨即使给出上述信息，Spark也会处理内存中的数据。 当然可以，因为您没有处理数据的其他选择。 OS API中的所有操作都允许您将块设备中的数据加载到内存中，然后将其卸载回块设备。 如果不将数据加载到内存中，您无法直接在HDD上计算内容，因为现代系统中的所有处理基本上都是内存处理。
鉴于Spark允许您使用LRU淘汰规则的内存缓存，您可能仍然认为它是内存技术，至少在您处理的数据是在内存中。 但是，让我们转向RDBMSs市场，并从那里拿出2个例子 - Oracle和PostgreSQL。 您认为他们如何处理数据？ 它们使用共享内存段作为表页的池，所有数据读取和数据写入都通过此池。 此池还具有LRU淘汰规则以从中淘汰非脏(nod-dirty)表页（并且如果脏页太多则强制检查点进程）。 因此，通常现代数据库也可以有效地利用内存中的LRU缓存来满足他们的需求。 为什么我们不认为Oracle或PostgreSQL是内存解决方案？ 那么Linux IO，你知道所有IO操作都通过OS IO缓存，这是同一个LRU缓存吗？
image.png
甚至更多，你认为Spark会在内存中的处理所有转换吗？你可能会感到失望，但Spark的核心“shuffle”将数据写入磁盘。如果您在SparkSQL查询中有一个“group by”语句，或者您只是将RDD转换为PairRDD并按key调用它，则会强制Spark根据key的哈希值在分区之间分配数据。 “shuffle”过程包括两个阶段，通常称为“map”和“reduce”。 “Map”只计算key（或其他你手动设置的分区函数）的哈希值，并将数据输出到本地文件系统上的N个单独文件，其中N是“reduce”端的分区数。 “Reduce”端轮询数据的“map”端并将其合并到新分区中。因此，如果您拥有M个分区的RDD并将其转换为有N个分区的Pair RDD，则会在集群的本地文件系统上创建M * N个文件，并保存特定RDD的所有数据。有一些优化可用于减少文件数量。还有一些工作经过预先排序然后在reduce端进行“合并”，但这并没有改变这个事实，即每次你需要“shuffle”你的数据，你把它放到硬盘驱动器上。
最后，Spark不是内存技术。 他是允许您有效利用内存中的LRU缓存，并在内存满状态下进行可能的磁盘淘汰。 它没有内置的持久化功能（既不在内存中也不在磁盘上）。 并且它在“shuffle”过程中将所有数据集数据放在本地文件系统上。
下一个误解是“Spark比Hadoop快10到100倍”。 让我们参考关于这个主题的早期报告（presentations）之一：http：//laser.inf.ethz.ch/2013/material/joseph/LASER-Joseph-6.pdf。 它表示Spark的目标是支持迭代作业，这是机器学习的典型。 如果您参考Apache网站上的Spark主页，您将再次看到Spark闪光的示例：
image.png
而且，这个例子是关于称为“Logistic回归”的机器学习算法。 大多数机器学习算法的基本部分是什么？ 他们多次在同一数据集上重复迭代。 这里是带有LRU淘汰的内存缓存才是Spark真正闪耀的地方！ 当您连续多次迭代扫描同一数据集时，您只需要在第一次访问它时才读取它，之后您只是从内存中读取它。 这真的很棒。 但不幸的是，我认为他们正在以一种棘手的方式运行这些测试 - 在Hadoop上运行它们不利用HDFS缓存功能（http://hadoop.apache.org/docs/r2.3.0/hadoop-project-dist/hadoop-hdfs/CentralizedCacheManagement.html）。 当然他们没有义务，但我认为使用这个选项，性能差异将减少到大约3x-4x（因为更高效的实现，没有中间数据放在HDD上，更快的任务启动时间）。
image.png
在企业领域进行基准测试的悠久历史告诉我一件事：永远不要相信基准。 对于任何两个相互竞争的系统，您会发现十几个示例，其中SystemA比SystemB更快，而十几个示例中SystemB比SystemA更快。 您可以信任的（当然，有一些消息）是独立的基准测试框架，如TPC-H - 它们是独立的，并且正在尝试准备基准，这将涵盖显示解决方案的真实性能的大多数情况。
总的来数，Spark比Hadoop快有如下原因：
-
任务启动时间更快。 Spark fork线程，MR启动一个新的JVM。
-
更快的shuffle。 Spark在shuffle期间仅将数据放在HDD上一次，而MR是2次。
-
更快的工作流程。 典型的MR工作流是一系列MR作业，每个作业在迭代之间将数据保存到HDFS。 Spark支持DAG和流水线操作，这使得它可以在没有中间数据实现的情况下执行复杂的工作流程（除非您需要“shuffle”）。
-
缓存。 这是值得怀疑的，因为目前HDFS也可以利用缓存，但一般来说Spark缓存非常好，特别是它的SparkSQL部分以优化的面向列的形式缓存数据。
与Hadoop相比，所有这些都为Spark提供了良好的性能提升，对于短期运行的工作来说，实际上可以达到100倍，但对于实际生产工作负载，它最多不会超过2.5倍-3倍。
最新的神话，非常罕见：“Spark为市场上的数据处理引入了全新的方法”。 事实上，Spark并没有引入革命性的新东西。 他们擅长实现高效的LRU缓存和数据处理流水线的想法，但它们并不孤单。 如果您对这个问题持开放态度，您会注意到它们通常实现了与MPP数据库早先引入的几乎相同的概念：查询执行流水线操作，没有中间数据实现，表页的LRU缓存。 如您所见，一般来说Spark支柱（pillars）与Spark之前市场上存在的技术相同。 但当然，向前迈出的一大步是Spark在开源中实施它们并将它们提供给广泛的国际社区免费使用，大多数公司都没有准备好为企业MPP技术付费，同时仍然缺乏相似的水平的技术(lacking the similar level of performance)。
最后，我建议你不要相信你从媒体上听到的一切。 相信主题专家，他们通常最适合询问的人。
网友评论