spark访问高德

⑴ 大数据分析Apache Spark的应用实例

在考虑Hadoop生态系统中的各种引擎时，重要的是要了解每个引擎在某些用例下效果最佳，并且企业可能需要使用多种工具组合才能满足每个所需的用例。话虽如此，这里是对Apache Spark的一些顶级用例的回顾。

一、流数据

Apache Spark的关键用例是其处理流数据的能力。由于每天要处理大量数据，因此对于公司而言，实时流传输和分析数据变得至关重要。Spark Streaming具有处理这种额外工作负载的能力。一些专家甚至认为，无论哪种类型，Spark都可以成为流计算应用程序的首选平台。提出此要求的原因是，Spark Streaming统一了不同的数据处理功能，从而使开发人员可以使用单个框架来满足其所有处理需求。

当今企业使用Spark Streaming的一般方式包括：

1、流式ETL –在数据仓库环境中用于批处理的传统ETL(提取，转换，加载)工具必须读取数据，将其转换为数据库兼容格式，然后再将其写入目标数据库。使用Streaming ETL，在将数据推送到数据存储之前，将对其进行连续的清理和聚合。

2、数据充实 –这种Spark Streaming功能通过将实时数据与静态数据相结合来充实实时数据，从而使组织能够进行更完整的实时数据分析。在线广告商使用数据充实功能将历史客户数据与实时客户行为数据结合起来，并根据客户的行为实时提供更多个性化和针对性的广告。

3、触发事件检测 – Spark Streaming使组织可以检测到可能对系统内部潜在严重问题的罕见或异常行为(“触发事件”)并做出快速响应。金融机构使用触发器来检测欺诈性交易并阻止其欺诈行为。医院还使用触发器来检测潜在的危险健康变化，同时监视患者的生命体征-向正确的护理人员发送自动警报，然后他们可以立即采取适当的措施。

4、复杂的会话分析 –使用Spark Streaming，与实时会话有关的事件(例如登录网站或应用程序后的用户活动)可以组合在一起并进行快速分析。会话信息还可以用于不断更新机器学习模型。诸如Netflix之类的公司使用此功能可立即了解用户在其网站上的参与方式，并提供更多实时电影推荐。

二、机器学习

许多Apache Spark用例中的另一个是它的机器学习功能。

Spark带有用于执行高级分析的集成框架，该框架可帮助用户对数据集进行重复查询，这从本质上讲就是处理机器学习算法。在此框架中找到的组件包括Spark的可扩展机器学习库(MLlib)。MLlib可以在诸如聚类，分类和降维等领域中工作。所有这些使Spark可以用于一些非常常见的大数据功能，例如预测智能，用于营销目的的客户细分以及情感分析。使用推荐引擎的公司将发现Spark可以快速完成工作。

网络安全是Spark 机器学习功能的一个很好的商业案例。通过使用Spark堆栈的各种组件，安全提供程序可以对数据包进行实时检查，以发现恶意活动的痕迹。在前端，Spark Streaming允许安全分析人员在将数据包传递到存储平台之前检查已知威胁。到达存储区后，数据包将通过其他堆栈组件(例如MLlib)进行进一步分析。因此，安全提供商可以在不断发展的过程中了解新的威胁-始终领先于黑客，同时实时保护其客户。

三、互动分析

Spark最显着的功能之一就是其交互式分析功能。MapRece是为处理批处理而构建的，而Hive或Pig等SQL-on-Hadoop引擎通常太慢，无法进行交互式分析。但是，Apache Spark足够快，可以执行探索性查询而无需采样。Spark还与包括SQL，R和Python在内的多种开发语言接口。通过将Spark与可视化工具结合使用，可以交互地处理和可视化复杂的数据集。

下一版本的Apache Spark(Spark 2.0)将于今年的4月或5月首次亮相，它将具有一项新功能- 结构化流 -使用户能够对实时数据执行交互式查询。通过将实时流与其他类型的数据分析相结合，预计结构化流将通过允许用户针对Web访问者当前会话运行交互式查询来促进Web分析。它也可以用于将机器学习算法应用于实时数据。在这种情况下，将对旧数据进行算法训练，然后将其重定向以合并新的数据，并在其进入内存时从中学习。

四、雾计算

尽管大数据分析可能会引起广泛关注，但真正激发技术界想象力的概念是物联网(IoT)。物联网通过微型传感器将对象和设备嵌入在一起，这些微型传感器彼此之间以及与用户进行通信，从而创建了一个完全互连的世界。这个世界收集了大量数据，对其进行处理，并提供革命性的新功能和应用程序供人们在日常生活中使用。但是，随着物联网的扩展，对大量，种类繁多的机器和传感器数据进行大规模并行处理的需求也随之增加。但是，利用云中的当前分析功能很难管理所有这些处理。

那就是雾计算和Apache Spark出现的地方。

雾计算将数据处理和存储分散化，而不是在网络边缘执行这些功能。但是，雾计算为处理分散数据带来了新的复杂性，因为它越来越需要低延迟，机器学习的大规模并行处理以及极其复杂的图形分析算法。幸运的是，有了Spark Streaming等关键堆栈组件，交互式实时查询工具(Shark)，机器学习库(MLib)和图形分析引擎(GraphX)，Spark不仅具有雾计算解决方案的资格。实际上，随着物联网行业逐渐不可避免地融合，许多行业专家预测，与其他开源平台相比，Spark有可能成为事实上的雾基础设施。

现实世界中的火花

如前所述，在线广告商和诸如Netflix之类的公司正在利用Spark获得见识和竞争优势。其他也从Spark受益的着名企业是：

Uber –这家跨国在线出租车调度公司每天都从其移动用户那里收集TB级的事件数据。通过使用Kafka，Spark Streaming和HDFS构建连续的ETL管道，Uber可以在收集原始非结构化事件数据时将其转换为结构化数据，然后将其用于进一步和更复杂的分析。

Pinterest –通过类似的ETL管道，Pinterest可以利用Spark Streaming即时了解世界各地的用户如何与Pins互动。因此，当人们浏览站点并查看相关的图钉时，Pinterest可以提出更相关的建议，以帮助他们选择食谱，确定要购买的产品或计划前往各个目的地的行程。

Conviva –这家流媒体视频公司每月平均约有400万个视频供稿，仅次于YouTube。Conviva使用Spark通过优化视频流和管理实时视频流量来减少客户流失，从而保持一致的流畅，高质量的观看体验。

何时不使用Spark

尽管它具有通用性，但这并不一定意味着Apache Spark的内存中功能最适合所有用例。更具体地说，大数据分析Apache Spark的应用实例Spark并非设计为多用户环境。Spark用户需要知道他们有权访问的内存对于数据集是否足够。添加更多的用户使此操作变得更加复杂，因为用户必须协调内存使用量才能同时运行项目。由于无法处理这种类型的并发，用户将需要为大型批处理项目考虑使用备用引擎，例如Apache Hive。

随着时间的流逝，Apache Spark将继续发展自己的生态系统，变得比以前更加通用。在大数据已成为规范的世界中，组织将需要找到最佳方式来利用它。从这些Apache Spark用例可以看出，未来几年将有很多机会来了解Spark的真正功能。

随着越来越多的组织认识到从批处理过渡到实时数据分析的好处，Apache Spark的定位是可以在众多行业中获得广泛而快速的采用。

⑵ Spark内存管理详解（下）——内存管理

弹性分布式数据集（RDD）作为Spark最根本的数据抽象，是只读的分区记录（Partition）的集合，只能基于在稳定物理存储中的数据集上创建，或者在其他已有的RDD上执行转换（Transformation）操作产生一个新的RDD。转换后的RDD与原始的RDD之间产生的依赖关系，构成了血统（Lineage）。凭借血统，Spark保证了每一个RDD都可以被重新恢复。但RDD的所有转换都是惰性的，即只有当一个返回结果给Driver的行动（Action）发生时，Spark才会创建任务读取RDD，然后真正触发转换的执行。

Task在启动之初读取一个分区时，会先判断这个分区是否已经被持久化，如果没有则需要检查Checkpoint或按照血统重新计算。所以如果一个RDD上要执行多次行动，可以在第一次行动中使用persist或cache方法，在内存或磁盘中持久化或缓存这个RDD，从而在后面的行动时提升计算速度。事实上，cache方法是使用默认的MEMORY_ONLY的存储级别将RDD持久化到内存，故缓存是一种特殊的持久化。 堆内和堆外存储内存的设计，便可以对缓存RDD时使用的内存做统一的规划和管理 （存储内存的其他应用场景，如缓存broadcast数据，暂时不在本文的讨论范围之内）。

RDD的持久化由Spark的Storage模块 [1] 负责，实现了RDD与物理存储的解耦合。Storage模块负责管理Spark在计算过程中产生的数据，将那些在内存或磁盘、在本地或远程存取数据的功能封装了起来。在具体实现时Driver端和Executor端的Storage模块构成了主从式的架构，即Driver端的BlockManager为Master，Executor端的BlockManager为Slave。Storage模块在逻辑上以Block为基本存储单位，RDD的每个Partition经过处理后唯一对应一个Block（BlockId的格式为 rdd_RDD-ID_PARTITION-ID ）。Master负责整个Spark应用程序的Block的元数据信息的管理和维护，而Slave需要将Block的更新等状态上报到Master，同时接收Master的命令，例如新增或删除一个RDD。

在对RDD持久化时，Spark规定了MEMORY_ONLY、MEMORY_AND_DISK等7种不同的 存储级别 ，而存储级别是以下5个变量的组合 [2] ：

通过对数据结构的分析，可以看出存储级别从三个维度定义了RDD的Partition（同时也就是Block）的存储方式：

RDD在缓存到存储内存之前，Partition中的数据一般以迭代器（ Iterator ）的数据结构来访问，这是Scala语言中一种遍历数据集合的方法。通过Iterator可以获取分区中每一条序列化或者非序列化的数据项(Record)，这些Record的对象实例在逻辑上占用了JVM堆内内存的other部分的空间，同一Partition的不同Record的空间并不连续。

RDD在缓存到存储内存之后，Partition被转换成Block，Record在堆内或堆外存储内存中占用一块连续的空间。 将Partition由不连续的存储空间转换为连续存储空间的过程，Spark称之为“展开”（Unroll） 。Block有序列化和非序列化两种存储格式，具体以哪种方式取决于该RDD的存储级别。非序列化的Block以一种DeserializedMemoryEntry的数据结构定义，用一个数组存储所有的Java对象，序列化的Block则以SerializedMemoryEntry的数据结构定义，用字节缓冲区（ByteBuffer）来存储二进制数据。每个Executor的Storage模块用一个链式Map结构（LinkedHashMap）来管理堆内和堆外存储内存中所有的Block对象的实例 [6] ，对这个LinkedHashMap新增和删除间接记录了内存的申请和释放。

因为不能保证存储空间可以一次容纳Iterator中的所有数据，当前的计算任务在Unroll时要向MemoryManager申请足够的Unroll空间来临时占位，空间不足则Unroll失败，空间足够时可以继续进行。对于序列化的Partition，其所需的Unroll空间可以直接累加计算，一次申请。而非序列化的Partition则要在遍历Record的过程中依次申请，即每读取一条Record，采样估算其所需的Unroll空间并进行申请，空间不足时可以中断，释放已占用的Unroll空间。如果最终Unroll成功，当前Partition所占用的Unroll空间被转换为正常的缓存RDD的存储空间，如下图2所示。

在 《Spark内存管理详解（上）——内存分配》 的图3和图5中可以看到，在静态内存管理时，Spark在存储内存中专门划分了一块Unroll空间，其大小是固定的，统一内存管理时则没有对Unroll空间进行特别区分，当存储空间不足是会根据动态占用机制进行处理。

由于同一个Executor的所有的计算任务共享有限的存储内存空间，当有新的Block需要缓存但是剩余空间不足且无法动态占用时，就要对LinkedHashMap中的旧Block进行淘汰（Eviction)，而被淘汰的Block如果其存储级别中同时包含存储到磁盘的要求，则要对其进行落盘（Drop），否则直接删除该Block。
存储内存的淘汰规则为：

落盘的流程则比较简单，如果其存储级别符合 _useDisk 为true的条件，再根据其 _deserialized 判断是否是非序列化的形式，若是则对其进行序列化，最后将数据存储到磁盘，在Storage模块中更新其信息。

Executor内运行的任务同样共享执行内存，Spark用一个HashMap结构保存了任务到内存耗费的映射。每个任务可占用的执行内存大小的范围为 1/2N ~ 1/N ，其中N为当前Executor内正在运行的任务的个数。每个任务在启动之时，要向MemoryManager请求申请最少为1/2N的执行内存，如果不能被满足要求则该任务被阻塞，直到有其他任务释放了足够的执行内存，该任务才可以被唤醒。

执行内存主要用来存储任务在执行Shuffle时占用的内存，Shuffle是按照一定规则对RDD数据重新分区的过程，我们来看Shuffle的Write和Read两阶段对执行内存的使用：

在ExternalSorter和Aggregator中，Spark会使用一种叫AppendOnlyMap的哈希表在堆内执行内存中存储数据，但在Shuffle过程中所有数据并不能都保存到该哈希表中，当这个哈希表占用的内存会进行周期性地采样估算，当其大到一定程度，无法再从MemoryManager申请到新的执行内存时，Spark就会将其全部内容存储到磁盘文件中，这个过程被称为溢存(Spill)，溢存到磁盘的文件最后会被归并(Merge)。

Shuffle Write阶段中用到的Tungsten是Databricks公司提出的对Spark优化内存和CPU使用的计划 [4] ，解决了一些JVM在性能上的限制和弊端。Spark会根据Shuffle的情况来自动选择是否采用Tungsten排序。Tungsten采用的页式内存管理机制建立在MemoryManager之上，即Tungsten对执行内存的使用进行了一步的抽象，这样在Shuffle过程中无需关心数据具体存储在堆内还是堆外。每个内存页用一个MemoryBlock来定义，并用 Object obj 和 long offset 这两个变量统一标识一个内存页在系统内存中的地址。堆内的MemoryBlock是以long型数组的形式分配的内存，其 obj 的值为是这个数组的对象引用， offset 是long型数组的在JVM中的初始偏移地址，两者配合使用可以定位这个数组在堆内的绝对地址；堆外的MemoryBlock是直接申请到的内存块，其 obj 为null， offset 是这个内存块在系统内存中的64位绝对地址。Spark用MemoryBlock巧妙地将堆内和堆外内存页统一抽象封装，并用页表(pageTable)管理每个Task申请到的内存页。

Tungsten页式管理下的所有内存用64位的逻辑地址表示，由页号和页内偏移量组成：

有了统一的寻址方式，Spark可以用64位逻辑地址的指针定位到堆内或堆外的内存，整个Shuffle Write排序的过程只需要对指针进行排序，并且无需反序列化，整个过程非常高效，对于内存访问效率和CPU使用效率带来了明显的提升 [5] 。

Spark的存储内存和执行内存有着截然不同的管理方式：对于存储内存来说，Spark用一个LinkedHashMap来集中管理所有的Block，Block由需要缓存的RDD的Partition转化而成；而对于执行内存，Spark用AppendOnlyMap来存储Shuffle过程中的数据，在Tungsten排序中甚至抽象成为页式内存管理，开辟了全新的JVM内存管理机制。

Spark的内存管理是一套复杂的机制，且Spark的版本更新比较快，笔者水平有限，难免有叙述不清、错误的地方，若读者有好的建议和更深的理解，还望不吝赐教。