a280966503的博客

Spark SQL中的DataFrame类似于一张关系型数据表。在关系型数据库中对单表或进行的查询操作，在DataFrame中都可以通过调用其API接口来实现。可以参考，Scala提供的DataFrame API。　　本文中的代码基于Spark-1.6.2的文档实现。一、DataFrame对象的生成　　Spark-SQL可以以其他RDD对象、parquet文件、json

Spark算子的作用下图描述了Spark在运行转换中通过算子对RDD进行转换。 算子是RDD中定义的函数，可以对RDD中的数据进行转换和操作。 输入：在Spark程序运行中，数据从外部数据空间（如分布式存储：textFile读取HDFS等，parallelize方法输入Scala集合或数据）输入Spark，数据进入Spark运行时数据空间，转化为Spark中的数据块，通过Blo

从名字就可以看出这是笛卡儿的意思，就是对给的两个RDD进行笛卡儿计算。官方文档说明：Return the Cartesian product of this RDD and another one, that is, the RDD of all pairs of elements (a, b) where a is in `this` and b is in `other`.

spark中，不论spark-shell还是spark-submit，都可以设置memory大小，但是有的同学会发现有两个memory可以设置。分别是driver memory 和executor memory。从名字上大概可以猜出大概。具体就是说driver memory并不是master分配了多少内存，而是管理多少内存。换言之就是为当前应用分配了多少内存。executor me

最近在升级一个框架的时候，发现某个流式计算程序每隔一定的时间就会出现GC overhead limit exceeded的错误问题。这个问题肯定是内存不够，但是初始设置的内存是够的啊，于是进行各种内存优化，如将变量定义在循环体外等控制，但是发现只是将这个间隔时间往后推了一下而已。还是没有找到症结所在。后来再分析了下，可能是哪些变量占了内存

每一台host上面可以并行N个worker，每一个worker下面可以并行M个executor，task们会被分配到executor上面去执行。Stage指的是一组并行运行的task，stage内部是不能出现shuffle的，因为shuffle的就像篱笆一样阻止了并行task的运行，遇到shuffle就意味着到了stage的边界。CPU的core数量，每个executor可以占用一个或多个co

一个CPU core同一时间只能执行一个线程。而每个Executor进程上分配到的多个task，都是以每个task一条线程的方式，多线程并发运行的spark-submit \--master spark://master1:7077 \  //spark的master地址--class com.dyy.spark.WordCount \ //运行的jar包class--num-executors ...

 公司最近的spark集群由原来的standalone迁移到spark on yarn了，在迁移相关的程序时，发现调整还是有一些的，以下分别是两个版本提交的部分shell命令，从命令可以看出其区别，这个区别主要是spark on yarn的工作方式不太一样，造成提交的方式也不太一样。    standalone方式的脚本为:[java] view plain copyspark-submit --...

目前Apache Spark支持三种分布式部署方式，分别是standalone、spark on mesos和 spark on YARN，其中，第一种类似于MapReduce 1.0所采用的模式，内部实现了容错性和资源管理，后两种则是未来发展的趋势，部分容错性和资源管理交由统一的资源管理系统完成：让Spark运行在一个通用的资源管理系统之上，这样可以与其他计算框架，比如MapReduce，公用一...

Shuffle横跨Map端和Reduce端，在Map端包括Spill过程，在Reduce端包括copy和sort过程

Action动作含义reduce(func)通过func函数聚集RDD中的所有元素，这个功能必须是课交换且可并联的collect()在驱动程序中，以数组的形式返回数据集的所有元素count()返回RDD的元素个数first()返回RDD的第

TransformationRDD中的所有转换都是延迟加载的，也就是说，它们并不会直接计算结果。相反的，它们只是记住这些应用到基础数据集（例如一个文件）上的转换动作。只有当发生一个要求返回结果给Driver的动作时，这些转换才会真正运行。这种设计让Spark更加有效率地运行。 常用的Transformation：转换含义map(fun

实时查看来自各个省份的ip访问的详情，根据这一需求，通过flume/logstack实时采集nginx的日志到生产到kafka，再通过spark实时消费分析保存到redis/mysql中，最后前端通过百度的echart图实时的显示出来。 首先，得有一份ip归属地的规则表，可以本地的文档，也可以是分布式的在多台机器上的（如hdfs）。 ip规则表部分如下：1.0.1.0|1.0.3.25

在使用spark读取kafka数据时，当spark升级到2.0之后，出现如上问题：之前遇到了，当时在工程里面添加了org.apache.spark.Logging类，能够运行。但是在后期使用过程中，又遇到了相同的问题，为了一劳永逸，今天彻底把问题解决。开发环境：Idea intelligent14 + spark-2.1.0 + kafka在Idea中安装scala

关于点的问题是用string.split("[.]") 解决。关于竖线的问题用 string.split("\\|")解决。关于星号的问题用 string.split("\\*")解决。关于斜线的问题用 sring.split("\\\\")解决。关于中括号的问题用 sring.split("\\[\\]")解决。

从50多分钟到3分钟的优化某推荐系统需要基于Spark用ALS算法对近一天的数据进行实时训练, 然后进行推荐. 输入的数据有114G, 但训练时间加上预测的时间需要50多分钟, 而业务的要求是在15分钟左右, 远远达不到实时推荐的要求, 因此, 我们与业务侧一起对Spark应用进行了优化.另外提一下, 该文最好与之前我写的另一篇blog  一起看, 因为一些细节我不会再在该文中描述

一. 数据倾斜的现象多数task执行速度较快,少数task执行时间非常长，或者等待很长时间后提示你内存不足，执行失败。二. 数据倾斜的原因常见于各种shuffle操作，例如reduceByKey,groupByKey,join等操作。数据问题key本身分布不均匀(包括大量的key为空)key的设置不合理spark使用问题shuffle时的并发

程序中可能会使用到spark提供的累加器功能，可是如果你不了解它的运行机制，有时候会带来一些负面作用（错误的累加结果）。下文会介绍产生错误结果的原因，并提供一种解决办法。新博客地址Accumulator简介Accumulator是spark提供的累加器，顾名思义，该变量只能够增加。 只有driver能获取到Accumulator的值（使用value方法），T

一. 数据倾斜的现象多数task执行速度较快,少数task执行时间非常长，或者等待很长时间后提示你内存不足，执行失败。二. 数据倾斜的原因常见于各种shuffle操作，例如reduceByKey,groupByKey,join等操作。数据问题key本身分布不均匀(包括大量的key为空)key的设置不合理spark使用问题shuffle时的并发

首先先来看一看broadcast的使用代码:val values = List[Int](1,2,3)val broadcastValues = sparkContext.broadcast(values)rdd.mapPartitions(iter => {  broadcastValues.getValue.foreach(println)}) 

本人搭建好的hadoop环境为在CentOS7上搭建的hadoop-2.8.2的HA环境1.将apache-hive-2.3.2-bin.tar.gz包拷到服务器上，并使用tar -zxvf apache-hive-2.3.2-bin.tar.gz命令进行解压2.进入解压好的apache-hive-2.3.2-bin目录找到conf目录，将hive-default.xml.temp

./sbin/start-master.sh -master启动

在spark-on-yarn下cluster模式中显示ResourceManager：负责集群中所有资源的统一管理和分配，它接收来自各个节点（NodeManager）的资源汇报信息，并把这些信息按照一定的策略分配给各个应用程序（实际上是ApplicationManager）。NameNode：SecondaryNameNode：DataNode：NodeManager：CoarseGrainedE...