qq_24365213的博客

基于Spark通用计算平台，可以很好地扩展各种计算类型的应用，尤其是Spark提供了内建的计算库支持，像Spark Streaming、Spark SQL、MLlib、GraphX，这些内建库都提供了高级抽象，可以用非常简洁的代码实现复杂的计算逻辑、这也得益于Scala编程语言的简洁性。这里，我们基于1.3.0版本的Spark搭建了计算平台，实现基于Spark Streaming的实时计算。我

从Spark-1.2.0开始，Spark的Shuffle由Hash Based Shuffle升级成了Sort Based Shuffle。即Spark.shuffle.manager从Hash换成了Sort。不同形式的Shuffle逻辑主要是ShuffleManager的实现类不同。 　　在org.apache.spark.SparkEnv类中：// Let the user speci

ExternalSorter的注释这个类的注释提供了关于它的设计的很多信息，先翻译一下。这个类用于对一些(K, V)类型的key-value对进行排序，如果需要就进行merge，生的结果是一些(K, C)类型的key-combiner对。combiner就是对同样key的value进行合并的结果。它首先使用一个Partitioner来把key分到不同的partition，然

前言借用和董神的一段对话说下背景：shuffle共有三种，别人讨论的是hash shuffle，这是最原始的实现，曾经有两个版本，第一版是每个map产生r个文件，一共产生mr个文件，由于产生的中间文件太大影响扩展性，社区提出了第二个优化版本，让一个core上map共用文件，减少文件数目，这样共产生corer个文件，好多了，但中间文件数目仍随任务数线性增加，仍难以应对大作业，但hash shu

Spark性能调优之Shuffle调优    • shuffle过程中常出现的问题常见问题一：reduce oom?    问题原因：       reduce task 去map端获取数据，reduce一边拉取数据一边聚合，reduce端有一块聚合内存（executor memory * 0.2）,也就是这块内存不够    解决办法：           

[Spark性能调优] 第四章 : Spark Shuffle 中 JVM 内存使用及配置内幕详情本课主题 JVM 內存使用架构剖析Spark 1.6.x 和 Spark 2.x 的 JVM 剖析Spark 1.6.x 以前 on Yarn 计算内存使用案例Spark Unified Memory 的运行原理和机制 引言Spark 从1.6.x 开始对 JV

hive on spark 是由cloudera推动的，所以相关资料在cloudera上https://www.cloudera.com/documentation/enterprise/latest/topics/admin_hos_oview.html

本文原文出处: http://blog.youkuaiyun.com/bluishglc/article/details/50945032 严禁任何形式的转载，否则将委托优快云官方维护权益！Spark的官方文档再三强调那些将要作用到RDD上的操作，不管它们是一个函数还是一段代码片段，它们都是“闭包”，Spark会把这个闭包分发到各个worker节点上去执行，这里涉及到了一个容易被忽视的问题：闭包的“

http://blog.youkuaiyun.com/u011007180/article/category/6394993

最近为了测试延云YDB在高并发请求和持续性请求情况下的表现，发现了spark的不少关于内存泄露的问题，这些问题均在延云YDB提供的SPARK版本中得以修正，现将问题总结如下。1.    高并发情况下的内存泄露很遗憾，spark的设计架构并不是为了高并发请求而设计的，我们尝试在网络条件不好的集群下，进行100并发的查询，在压测3天后发现了内存泄露。a)    在进行大量小SQL的

DAGScheduler将任务提交到TaskScheduler之后，接下来由TaskScheduler负责任务的调度。TaskScheduler是一个trait（接口类），它的实现类是TaskSchedulerImpl。具体内容包括：1、出现shuffle输出lost要报告fetch failed错误2、碰到straggle任务需要放到别的节点上重试3、为每个TaskSet

1. Spark CoreSpark Core (一) 什么是RDD的Transformation和Actions以及Dependency?Spark Core（二）Driver上的Task的生成、分配、调度Spark Core（三）Executor上是如何launch taskSpark Core（四）用LogQuery的例子来说明Execut

前言继基础篇讲解了每个Spark开发人员都必须熟知的开发调优与资源调优之后，本文作为《Spark性能优化指南》的高级篇，将深入分析数据倾斜调优与shuffle调优，以解决更加棘手的性能问题。数据倾斜调优调优概述有的时候，我们可能会遇到大数据计算中一个最棘手的问题——数据倾斜，此时Spark作业的性能会比期望差很多。数据倾斜调优，就是使用各种技术方案解决不同类型的数据

// Subscribe to 1 topic 从数据库读取偏移量。todoval words = spark .readStream .format("kafka") .option("kafka.bootstrap.servers", "host1:port1,host2:port2") .option("subscribe", "topic1") .load()

这篇文章只是为了阐述Spark Streaming 意外Crash掉后，如何保证Exactly Once Semantics。本来这个是可以直接给出答案的，但是我还是啰嗦的讲了一些东西。前言其实这次写Spark Streaming相关的内容，主要是解决在其使用过程中大家真正关心的一些问题。我觉得应该有两块：数据接收。我在用的过程中确实产生了问题。应用的可靠性。因为SS是7*

一、垃圾回收算法标记-清除（Mark-Sweep）:此算法执行分两阶段。第一阶段从引用根节点开始标记所有被引用的对象，第二阶段遍历整个堆，把未标记的对象清除。此算法需要暂停整个应用，同时，会产生内存碎片。复制（Copying）:此算法把内存空间划为两个相等的区域，每次只使用其中一个区域。垃圾回收时，遍历当前使用区域，把正在使用中的对象复制到另外一个区

1.安装anconda2.安装spark3.vi ~/.bashrc 文件，添加以下内容：export PYSPARK_DRIVER_PYTHON=ipython2 # As pyspark only works with python2 and not python3export PYSPARK_DRIVER_PYTHON_OPTS="notebook --ip=m01"

一个 Streaming Application 往往需要7*24不间断的跑，所以需要有抵御意外的能力（比如机器或者系统挂掉，JVM crash等）。为了让这成为可能，Spark Streaming需要 checkpoint 足够多信息至一个具有容错设计的存储系统才能让 Application 从失败中恢复。Spark Streaming 会 checkpoint 两种类型的数据。Meta

val data = KafkaUtils.createDirectStream[String, String, StringDecoder, StringDecoder]( ssc, kafkaParams, TopicsSet)会创建一个DirectKafkaInputDStream并加入到ssc自身维护的流程图变量ssc.graph.addInputStream(this)然后进行d

首先区分下AppMaster和Driver，任何一个yarn上运行的任务都必须有一个AppMaster，而任何一个Spark任务都会有一个Driver，Driver就是运行SparkContext(它会构建TaskScheduler和DAGScheduler)的进程，当然在Driver上你也可以做很多非Spark的事情，这些事情只会在Driver上面执行，而由SparkContext上牵引出来的代

cache()与persist()：会被重复使用的(但是)不能太大的RDD需要cache。cache 只使用 memory，写磁盘的话那就叫 checkpoint 了。 哪些 RDD 需要 checkpoint？运算时间很长或运算量太大才能得到的 RDD，computing chain 过长或依赖其他 RDD 很多的 RDD。 实际上，将 ShuffleMapTask 的输出结果存放到本地

前言在大数据计算领域，Spark已经成为了越来越流行、越来越受欢迎的计算平台之一。Spark的功能涵盖了大数据领域的离线批处理、SQL类处理、 流式/实时计算、机器学习、图计算等各种不同类型的计算操作，应用范围与前景非常广泛。在美团•大众点评，已经有很多同学在各种项目中尝试使用 Spark。大多数同学（包括笔者在内），最初开始尝试使用Spark的原因很简单，主要就是为了让大数据计算作业的执

1.文档编写目的CDH 自带的Spark 不支持Spark Thrift，因为spark-assembly jar中缺少Hive thrift相关的依赖包，导致CDH用户没法使用JDBC的方式连接Spark并使用Spark SQL。Apache Spark 1.6之后spark-assembly jar 中包含了 Hive 相关的依赖包了，而恰好 CDH5.13 的