spark

数据倾斜 在执行shuffle操作过程中，map端按照key分配数据输出，reduce端同样也按照key进行拉取、聚合。通常每一个key对应的数据量不对等，经常出些某些key数据量比其他key多很多。这种现象导致的后果，轻则拖慢job执行时间（执行时间由最慢的task决定），重则直接OOM（数据量太大，处理完成前不能回收内存） 原因 我觉得是两个必要条件，缺一个都不发生数据倾斜，而我们打破其中一个或全部打破来解决数据倾斜。 每个key对应的数据量天然不均 发生shuffle操作 那么怎么定位代码中哪里出现了数据倾斜？ 凭经验猜测会发生shuffle的算子 运行慢时。若是client模式，查看本地日志，当前还在运行的Stage、Task是哪个；若是cluster模式，查看UI，主要确定Stage中Task的数据量 报OOM时查看log抛错堆栈，可以定位到某一行代码，从而知道哪一个stage，哪个一个算子。 解决办法 数据源预处理 业务中，hive文件或其他数据源文件大小不均，有大有小。小文件处理很快，而大文件处理慢。如果提前对数据源数据进行一定的清洗、过滤、去重、重分区等操作，将原来不均匀的数据重新均匀放在多个文件中。 同理，针对key分布不均的情况，可以考虑将Spark 运算中业务时效不敏感的shuffle操作提前放到ETL进行预处理（比如预聚合、逻辑压缩等

对于大数据计算框架而言，Shuffle阶段的设计优劣是决定性能好坏的关键因素之一。本文将介绍目前Spark的shuffle实现，并将之与MapReduce进行简单对比。本文的介绍顺序是：shuffle基本概念，MapReduce Shuffle发展史以及Spark Shuffle发展史。 （1） shuffle基本概念与常见实现方式 shuffle，是一个算子，表达的是多对多的依赖关系，在类MapReduce计算框架中，是连接Map阶段和Reduce阶段的纽带，即每个Reduce Task从每个Map Task产生数的据中读取一片数据，极限情况下可能触发M*R个数据拷贝通道（M是Map Task数目，R是Reduce Task数目）。通常shuffle分为两部分：Map阶段的数据准备和Reduce阶段的数据拷贝。首先，Map阶段需根据Reduce阶段的Task数量决定每个Map Task输出的数据分片数目，有多种方式存放这些数据分片： 1） 保存在内存中或者磁盘上（Spark和MapReduce都存放在磁盘上）； 2） 每个分片一个文件（现在Spark采用的方式，若干年前MapReduce采用的方式），或者所有分片放到一个数据文件中，外加一个索引文件记录每个分片在数据文件中的偏移量（现在MapReduce采用的方式）。 在Map端，不同的数据存放方式各有优缺点和适用场景。一般而言

Spark Knowledge NO.2 11.RDD缓存： Spark可以使用 persist 和 cache 方法将任意 RDD 缓存到内存、磁盘文件系统中。缓存是容错的，如果一个 RDD 分片丢失，可以通过构建它的 transformation自动重构。被缓存的 RDD 被使用的时，存取速度会被大大加速。一般的executor内存60%做 cache， 剩下的40%做task。 Spark中，RDD类可以使用cache() 和 persist() 方法来缓存。cache()是persist()的特例，将该RDD缓存到内存中。而persist可以指定一个StorageLevel。StorageLevel的列表可以在StorageLevel 伴生单例对象中找到。 Spark的不同StorageLevel ，目的满足内存使用和CPU效率权衡上的不同需求。我们建议通过以下的步骤来进行选择： 如果你的RDDs可以很好的与默认的存储级别(MEMORY_ONLY)契合，就不需要做任何修改了。这已经是CPU使用效率最高的选项，它使得RDDs的操作尽可能的快。 如果不行，试着使用MEMORY_ONLY_SER并且选择一个快速序列化的库使得对象在有比较高的空间使用率的情况下，依然可以较快被访问。 尽可能不要存储到硬盘上，除非计算数据集的函数，计算量特别大，或者它们过滤了大量的数据。否则

原博文来自于：　　http://blog.csdn.net/u012297062/article/details/52207934 感谢！ 使用 Spark SQL中的内置函数对数据进行分析，Spark SQL API不同的是，DataFrame中的内置函数操作的结果是返回一个Column对象，而DataFrame天生就是"A distributed collection of data organized into named columns.",这就为数据的复杂分析建立了坚实的基础并提供了极大的方便性，例如说，我们在操作DataFrame的方法中可以随时调用内置函数进行业务需要的处理，这之于我们构建附件的业务逻辑而言是可以极大的减少不必须的时间消耗（基于上就是实际模型的映射），让我们聚焦在数据分析上，这对于提高工程师的生产力而言是非常有价值的Spark 1.5.x开始提供了大量的内置函数，例如agg： [plain] view plain copy def agg(aggExpr: (String, String), aggExprs: (String, String)*): DataFrame = { groupBy().agg(aggExpr, aggExprs : _*) } 还有max、mean、min、sum、avg、explode、size、sort_array

Spark第一个程序开发WordCount Java版本 package cn.spark.java.core; import java.util.Arrays; import java.util.Iterator; import org.apache.spark.SparkConf; import org.apache.spark.api.java.JavaPairRDD; import org.apache.spark.api.java.JavaRDD; import org.apache.spark.api.java.JavaSparkContext; import org.apache.spark.api.java.function.FlatMapFunction; import org.apache.spark.api.java.function.Function2; import org.apache.spark.api.java.function.PairFunction; import org.apache.spark.api.java.function.VoidFunction; import scala.Tuple2; /** * zgf * java本地测试WordCount程序 */ public class WordCountJavaLocal {

Spark SQL是用于结构化数据处理的一个模块。同Spark RDD 不同地方在于Spark SQL的API可以给Spark计算引擎提供更多地信息，例如：数据结构、计算算子等。在内部Spark可以通过这些信息有针对对任务做优化和调整。这里有几种方式和Spark SQL进行交互，例如Dataset API和SQL等，这两种API可以混合使用。Spark SQL的一个用途是执行SQL查询。 Spark SQL还可用于从现有Hive安装中读取数据。从其他编程语言中运行SQL时，结果将作为Dataset/DataFrame返回，使用命令行或JDBC / ODBC与SQL接口进行交互。 Dataset是一个分布式数据集合在Spark 1.6提供一个新的接口，Dataset提供RDD的优势（强类型，使用强大的lambda函数）以及具备了Spark SQL执行引擎的优点。Dataset可以通过JVM对象构建，然后可以使用转换函数等（例如：map、flatMap、filter等），目前Dataset API支持Scala和Java 目前Python对Dataset支持还不算完备。 Data Frame是命名列的数据集，他在概念是等价于关系型数据库。DataFrames可以从很多地方构建，比如说结构化数据文件、hive中的表或者外部数据库，使用Dataset[row]的数据集

Spark 特点 减少Disk IO Spark 将资源文件（jar 等），缓存在driver 本地文件服务的内存里，当Executor执行任务时直接从 Driver 的内存中读取 增加并行度 多个stage 之间允许串行也可以并行 避免重新计算 当stage 中某个分区的task 失败，会重新对此stage 调度，但重新调度时会过滤掉已经成功执行的分区task 较为灵活的内存管理策略 四个部分 onheap 存储内存 onheap 执行内存 offheap 存储内存 offheap 执行内存 执行内存和存储内存之间可以互相借用 Spark 模块设计 SparkContext Spark 应用程序的提交和执行都离不开 SparkContext， SparkSession的底层实现依赖于 SparkContext SparkEnv SparkEnv 是 Spark 中 task 允许时所必须的组件 Spark 基本架构 Cluster Manager Yarn 模式下，为 ResourceManager StandAlone 模式下， 为master worker Yarn 模式下，为 NodeManager 来源： CSDN 作者： zhixingheyi_tian 链接： https://blog.csdn.net/zhixingheyi_tian/article/details

1 Storm 介绍 Storm 是由 Twitter 开源的分布式、高容错的实时处理系统，它的出现令持续不断的流计算变得容易，弥补了 Hadoop 批处理所不能满足的实时要求。 Storm 常用于在实时分析、在线机器学习、持续计算、分布式远程调用和 ETL 等领域。 在 Storm 的集群里面有两种节点：控制节点 (Master Node) 和工作节点 (Worker Node) 。控制节点上面运行一个名为 Nimbus 的进程 , 它用于资源分配和状态监控；每个工作节点上面运行一个 Supervisor 的进程，它会监听分配给它所在机器的工作，根据需要启动 / 关闭工作进程。 Storm 集群架构如下图所示： 图 1 Storm 集群架构 Storm 集群中每个组件具体描述如下： l Nimbus ：负责在集群里面发送代码，分配工作给机器并且监控状态，在集群中只有一个，作用类似 Hadoop 里面的 JobTracker 。 l ZooKeeper ： Storm 重点依赖的外部资源， Nimbus 、 Supervisor 和 Worker 等都是把心跳数据保存在 ZooKeeper 上， Nimbus 也是根据 ZooKeeper 上的心跳和任务运行状况进行调度和任务分配的。 l Supervisor ：在运行节点上，监听分配的任务，根据需要启动或关闭工作进程 Worker

Spark streaming 和kafka 处理确保消息不丢失的总结 接入kafka 我们前面的1到4 都在说 spark streaming 接入 kafka 消息的事情。讲了两种接入方式，以及spark streaming 如何和kafka协作接收数据，处理数据生成rdd的 主要有如下两种方式 基于分布式receiver 基于receiver的方法采用Kafka的高级消费者API，每个executor进程都不断拉取消息，并同时保存在executor内存与HDFS上的预写日志（write-ahead log/WAL）。当消息写入WAL后，自动更新ZooKeeper中的offset。 它可以保证at least once语义，但无法保证exactly once语义。原因是虽然引入了WAL来确保消息不会丢失，但有可能会出现消息已写入WAL，但更新comsuer 的offset到zk时失败的情况，此时consumer就会按上一次的offset重新发送消息到kafka重新获取一次已保存到WAL的数据。这种方式还会造成数据冗余（WAL中一份，blockmanager中一份，其中blockmanager可能会做StorageLevel.MEMORY_AND_DISK_SER_2，即内存中一份，磁盘上两份），大大降低了吞吐量和内存磁盘的利用率。现在基本都使用下面基于direct

  Spark Streaming对实时数据流进行分析处理，源源不断的从数据源接收数据切割成一个个时间间隔进行处理；    流处理与批处理有明显区别，批处理中的数据有明显的边界、数据规模已知；而流处理数据流并没有边界，也未知数据规模；   由于流处理的数据流特征，使之数据流具有不可预测性，而且数据处理的速率还与硬件、网络等资源有关，在这种情况下如不对源源不断进来的数据流速率进行限制，那当Spark节点故障、网络故障或数据处理吞吐量下来时还有数据不断流进来，那将有可能将出现OOM进而导致Spark Streaming程序崩溃；   在Spark Streaming中不同的数据源采用不同的限速策略，但无论是Socket数据源的限流策略还是Kafka数据源的限流策略其速率（rate）的计算都是使用PIDController算法进行计算而得来；   下面从源码的角度分别介绍 Socket数据源 与 Kafka数据源 的限流处理。 速率限制的计算与更新   Spark Streaming的流处理其实是基于微批处理(MicroBatch)的，也就是说将数据流按某比较小的时间间隔将数据切割成为一段段微批数据进行处理；   StreamingContext调用Start()启动的时候会将速率控制器（rateController）添加到StreamingListener监听器中；